The ROM size is text + data = 88538, but I need to add the size of .flash_nvram to find out how much of the 512kb I’ve used? So really it’s 235614.
RAM usage is: some booking suff (irq tables, etc), the RW .data, .bss, .heap and .stack. Which should (and does) add up to 96k. The stack size is fixed in one of the config files at 8k. Given that I know there is very minimal usage of the heap (just the USB code afaik), in effect .heap is how much free RAM I have to work with? So for the teletype that is ~72kb.
Any flaws in my logic? I’d like to get this written up and put in the the README.md on the libavr32 repo, as it’s the kind of thing I keep having to lookup. And I imagine it will be useful for Ansible firmware dev too.
Not specific to avr, but I only ever use the summary output unless there’s some very specific section I care about. So really you just need to know how to interpret the text, data, and bss sizes for the most part.
I think that article pretty much sums up everything you need to know in regular usage.
been curious about this too, and agreed it would be a very useful info to have and especially so for ansible firmware dev.
been meaning to start a thread on ansible dev too (possible refactor to make adding new apps easier, scale / preset management etc) but trying to get other things out out of the way first so probably won’t get to it until a couple of weeks from now…
Which is really nice as you get a very visual layout of RAM and ROM (the ROM starts at 2147483648 / 0x80000000). It’s worth noting that .flash_nvram does not start at the end of .rodata, but instead starts at 0x80040000 as defined in config.mk.
I’ve also discovered the readelf utility. Try avr32-readelf -e teletype.elf and the even longer avr32-readelf -a teletype.elf.
i believe this is correct. did you discover anything further to indicate otherwise?
i’ve been thinking about how to improve this also, to facilitate contributions. of course the first step would be to break the individual apps out of their dual-app files. i had some now insufficient reasoning behind having things in the same file-- some idea of potential shared memory and preset-code, but that could still happen with a different scheme. let’s discuss some approaches in another thread when we feel it’s time.
Not yet. I’ll have a proper look to see what usage of [m,c,re]alloc there is in libavr32, just in case the heap is being used more than we think. Then write something detailed up on my website, and put a tl;dr on the libavr32 readme.
I can chip in a little bit to this too, I did have a quick look through the Ansible source code the other day. I think you’ll need to think of a more robust scheme for reassigning event handlers if you want something that scales to more apps. Similarly you’ll need to think about RAM usage and making sure that non-running apps are not using any, maybe a larger stack or even using the heap. The other modules in the “increasingly misnamed trilogy” have actually got enough ROM and RAM free to fit a few apps in too.
If the modules had a decent malloc implementation included then switching apps could cause the current app to be deallocated and the new one allocated. You’d then rely on malloc / the heap to take care of managing the memory instead of the apps statically allocating everything.
The apps would then need to register event handlers with whatever the module “framework” was.
A quick ag tells me the USB code does. I can’t be certain that we execute that code without more in depth delving. But if it does it every time a device is connected (or every time packets are transferred) that could lead to issues couldn’t it?
I would be rewllly surprised if it was each time a packet was transferrred, that would be incredibly inefficient. Also USB endpointd generally have fixed buffer sizes so there should be no need to allocate. At least none of the USB drivers I’ve ever dealt with have had to do that…
I’d guess it probably only needs to do it at initialization, but it could be when a device is connected, though that should also be avoidable since you should generally know exactly how much memory you need by the time you initialize the USB stack…