I'll be happy to send them back regardless of whether it turns out to be suitable for these devices. There are certainly micros with more RAM.
Not that many. Then again, there are a lot of devboards with external RAM and they are much more suitable for this kind of treatment :)
Umm, you're playing a bit of Russian Roulette here. Since your
device doesn't have an MMU, you'll only notice a stack overflow
because some unrelated part of memory gets corrupted. Of course
this can happen with the main C stack, too.
Yes, Mike is right about this. Basically the only protection we have is that we declare a stack size and we forbid our break to get past that, but if the stack itself grows below its intented limit we have a problem. And it generally manifests itself with a complete freeze. I think there are ways to detect this problem (at least partially) with dlmalloc by activating some internal consistency checks, but I didn't test this yet. I also think you can ask the compiler to do some stack checking work for you (at least on ARM where you have a register than can be used as a "stack limit"), but again, I didn't test this. I probably should :)
It's hard to determine the absolute minimum amount of C stack
space needed by your app. You need to find the worst offenders and
round up generously:
- Most of the string.* functions need at least BUFSIZ bytes
(usually 4K or 8K).
- The Lua parser may need quite a bit of stack space depending on
the maximum syntactic nesting level.
- Some functions from the C library can be surprisingly expensive
in terms of C stack space usage (e.g. gethostbyname).
Those are helpful pointers, I suppose I'll have to think about this a little and maybe do some checking on the newlib functions we're using. For one part, I do know that we are using a rather small BUFSIZ of 256 for Newlib.
There are helpful, thank you. This is how we deal with them for now:
- BUFSIZ is currently 128 in eLua (seems awfully small, but it does the job for now).
- some of the larger Lua parser structures that are traditionally allocated on the stack are allocated on the heap in eLua. This fragments the heap a lot, obviously, but thanks to dlmalloc it isn't such a big problem in practice. Still, this doesn't help that much when too much nesting is involved.
Right now we have 2K of stack for architectures with 64K of RAM or less and 8K for the lucky boards with external RAM. Seems to work well on practice, at least for what we tried on eLua so far (which, fortunately, is small enough).
Best,
Bogdan
