I added this creepy character inspired - again - by Terraria that follows the player around, then comes down and attacks. Easy to kill (for now) and only one. OS is good as ever but RAM is running low. I really should optimize. What I need is dynamic memory allocation. Well, here is a video on my Terra progress:
The internet seems to think that arduino memory allocation functions (malloc/free etc) dont work well. Is this true? Any alternatives?
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
what if I had some kind of special ram that was external to the uC that supported virtual memory?
Are you sure? yes | no
I was thinking about the allocation problem, and the fragmentation that requires reshuffling blocs to avoid the swiss cheese memory effect...
And one thing I thought would be useful in your case is a "realloc callback" or something like that, the allocating thread could provide an optional callback address to call when the reallocation is required (to consolidate the free space). Hmmmm interesting :-)
Are you sure? yes | no
The problem is that in your case, you can't just move allocated blocks once they are allocated. The caller may have used the address in various parts of the program, and this pointer must be updated everywhere, at a time when it is not used. Only the application, not the OS, can know where it is going to be used next, so the application must update the pointer itself.
Obviously, if badly implemented, it can create serious and damaging bugs...
Are you sure? yes | no
I guess that's why the x86 architecture uses segments ;)
Have everything addressed WRT 0x0000, but then offset that address by the segment address e.g. 0x1000. The x86 does that automatically, but it wouldn't be hard to implement similar in software (though would require a macro/function-call and some math every time a memory-location is accessed)... Or maybe not, actually... Isn't there a load-indirect *with offset*? hmmm...
LDD Rd, Z+q, where q is 0 to 63... could be usable, somehow. So segment sizes of 64 bytes?
Are you sure? yes | no
You might be on to something there... Though I doubt segments were *ever* used for free space consolidation.
Segments failed anyway because each one couldn't go further than 64K.
Are you sure? yes | no
Got RAM allocation/Deallocation to work - will include in next log
Are you sure? yes | no
malloc can be ... complicated...
particularly because you'll end up with fragmentation and there is no way to consolidate free space across various tasks in a flat, shared, non protected, non-virtualised address space. it's not the malloc() that is hard, in fact, but the free() that doesn't turn your RAM into swiss cheese.
Are you sure? yes | no
What if I was allocating/deallocating huge blocks of RAM (Like, say, 6KB)
Are you sure? yes | no
increasing granularity helps, sure. Rounding up also prevents the creation of tiny unused fragments, at the cost of actual memory usage : if you have a 256 bytes allocation granularity and request 100, you waste precious RAM.
I'd recommend to look at various implementations because this subjects can fill entire books, and won't fit in a comments section.
You could also increase the quantity of RAM ;-)
Are you sure? yes | no
If doing huge/fixed-size blocks like that, being that they take such a huge percentage of the overall, it might be safer to just handle it explicitly as part of your "OS"(?). But don't trust my opinion on the matter, I consider malloc risky-business on small uC's, so haven't really learned its intricacies.
Are you sure? yes | no