Cortino
Locked
 
|
Dado Sutter |
Cortino
|
|
|
Jesus Alvarez |
New Board with eLua Support - Micromint Eagle 50
|
|
|
|
John Hind |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
|
|
Jesus Alvarez |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
|
|
John Hind |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
|
|
jbsnyder |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
Noting this issue, I'm wondering if anyone has attempted to strip Lua
or eLua down to a bare minimum to see how small it can get? For situations where one may have prototyped on a device with either external flash, or more built-in flash and then wants to deploy with a less expensive part, it would be interesting to see how large eLua is when the compiler and other components that are non-essential for just running bytecode are removed? It should even be possible to still do interactive development with the compiler removed using the RPC code (similar to the tethered interactive mode supported by Python on a Chip). Another thing I've personally wondered about is whether inexpensive code or data compression algorithms might be usable? I'm not sure how one would solve the issues this would cause with needing to hook flash reads through some sort of decompression scheme. If one compresses a bin file for generic compile for lm3s6965 with gzip (NOT suggesting incorporating gzip, obviously it would need to be something very lightweight and low on RAM usage), the binary is quite a bit smaller: -rwxr-xr-x 1 jsnyder staff 218700 Aug 7 08:09 elua_lua_lm3s6965.bin -rwxr-xr-x 1 jsnyder staff 126879 Aug 7 08:09 elua_lua_lm3s6965.bin.gz The gzipped version is 58% the size of the original, so there's definitely some savings to be had in the code. Just some things that have been rattling around in my brain, but I haven't had time to check feasibility of :-) Side note: These Micromint boards look quite nice, and are more affordable for a dev board than the eval kits :-) Are you looking to produce any boards based on the 9B parts once they go into production? -jsnyder On Aug 12, 2009, at 8:39 AM, John Hind wrote: > Thanks - yes, both good products! However there is an enormous gap > in the > market between the two, at least in memory capacity. Unfortunately, > for > eLua, the single chip options are still just a little tight in > memory (both > flash and RAM) while the multi-chip ones work out too expensive (and > overkill) for the sort of radically distributed architectures I have > in > mind. Although you can certainly run eLua as an academic or > benchmarking > exercise in 256KB, as a practical engineer, I would not want my > firmware to > be occupying 9/10ths of the available memory with the application > grubbing > around in the last few KB! > > Roll on ARM chips with 1MB Flash, 512KB RAM - that would really be an > enabler! > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Jesus Alvarez > Sent: 12 August 2009 13:54 > To: eLua Users and Development List > Subject: Re: [eLua-dev] New Board with eLua Support - Micromint > Eagle 50 > > John, > > eLua with the default configuration and networking takes about 216 > KB on > the Micromint Eagle boards. There are 8 KB reserved for the > bootloader. > Swapping to the microSD card is normally not required. If your > application uses additional code beyond the remaining flash, one > alternative is to use the eLua configuration parameters to eliminate > functions that are not needed. 256 KB could be a limitation if your > eLua > application also requires a medium size RTOS. > > A constraint in the flash for the Micromint Eagle is the use of > TI/Luminary LM3S processors. They do not currently have a low cost > 512KB > flash option. Yet that has not been a significant limitation for > customer applications. A large majority of standalone 32-bit embedded > applications that we have seen work well within 256 KB flash. In fact, > most 'C' applications can even add an RTOS and still have flash left. > > We do have an AVR32-based controller in the works that will have the > option of 512 KB of flash, mainly because that option is available in > that MCU. > > For applications with larger memory footprints we also offer an ARM9 > controller with 64 MB of RAM and 512MB or 1 GB of NAND flash. It > targets > applications using Linux but could be used for standalone applications > too. A new 400 MHz model of the Electrum line in the picoITX form > factor > will be available for under $100 in about four weeks. I have not built > eLua for the ARM9 but will do at some point. > > Regards, > Jesus Alvarez > > _______________________________________________ > Elua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > _______________________________________________ > Elua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev James Snyder Biomedical Engineering Northwestern University [hidden email] http://fanplastic.org/key.txt ph: 847.448.0386 _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
smime.p7s (5K) |
|
BogdanM |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
|
|
Dado Sutter |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
|
|
BogdanM |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
|
|
jbsnyder |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
On Aug 12, 2009, at 11:42 AM, Bogdan Marinescu wrote: > On Wed, Aug 12, 2009 at 7:27 PM, James Snyder > <[hidden email]> wrote: > Noting this issue, I'm wondering if anyone has attempted to strip > Lua or eLua down to a bare minimum to see how small it can get? > > That's one of my next steps. I bet I can make it run properly in > 128k of Flash, but with quite a few tweaks: > > - (obviously) strip out any unneeded libraries > - remove the parser and run your LuaRPC that will only execute > bytecode > - maybe replace the (part of) libc with our implementation > - remove everything related to floating point (not only the math > lib, but also the floating point emulation library itself). > > I already got a very small, inexpensive AT91SAM7X128 header bord and > I'll work with that. > > For situations where one may have prototyped on a device with either > external flash, or more built-in flash and then wants to deploy with > a less expensive part, it would be interesting to see how large eLua > is when the compiler and other components that are non-essential for > just running bytecode are removed? > > Ah, OK, so we're following the same path of thought here :) > > It should even be possible to still do interactive development with > the compiler removed using the RPC code (similar to the tethered > interactive mode supported by Python on a Chip). > > OK, I swear that I wrote the first paragraph without reading your > ideas :) Once again, nice to see that we're following the same path. I think I can even shave some code off of the RPC code if I go through and think about cleaning up the way it's set up with exceptions. I have at least a few more critical todos on the list for that code, like at least making it so that it isn't necessary to open a serial link and do: lua\r rpc.server()\r to start it up. :-) > Another thing I've personally wondered about is whether inexpensive > code or data compression algorithms might be usable? > > They're kinda useless in this case, I think, as you need to > decompress your code somewhere. If you need to decompress to > internal Flash, you made the problem worse, since you now have less > space because of your compressed firmware. If you have external > Flash and/or RAM, you probably don't have a space problem in the > first place :) If you have external Flash you can execute from > there, and the case of RAM > Flash is quite rare in practice. but I was thinking of something along the lines of a mechanism that would allow in-place usage, no LZ stream type stuff with a buffer. I'm thinking something like RLE &/or additional pre-computed de- duplication with a static memory map. Dictionary size might become a problem, but I'd assume there's a balance somewhere (and someone's probably done this before). With this, you would have previously checked if there's duplicated code and the lookup would then just point to to the common definition of that. This said, I assume you need hardware to make these sorts of acrobatics reasonable. Also, it might be that a stream algorithm like ones derived from Lempel-Ziv could be useful for Lua bytecode or scripts if memory usage could be kept to a minimum. It would be pretty easy to hook the chunk loading code to apply something like this when something is on its way in or out of the VM. I think the benefits there might be worth it if, say, LZ77/LZ78 works with a rather tiny buffer size (256 bytes or 512 bytes?). Either that, or perhaps huffman coding if the entropy in code or bytecode is significantly less than 8 real bits of data per byte. *shrug* It's on my mind because I listened to this a few weeks ago, and there was some explanation of how these algorithms work: http://www.twit.tv/sn205 -- James Snyder Biomedical Engineering Northwestern University [hidden email] http://fanplastic.org/key.txt ph: 847.448.0386 _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Jesus Alvarez |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
|
|
John Hind |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
|
|
BogdanM |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
|
|
BogdanM |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
|
|
BogdanM |
Re: New Board with eLua Support - Micromint Eagle 50
|
|
| Free forum by Nabble | Edit this page |