Fwd: Checked in latest changes, new module loader added.
Locked
|
Forwarding to the list. Mike, let's use the list for further development
discussions, I just added you to the list. I'll take a look at your loader, it sure sounds interesting. I'm actually preparing a patch (for Lua) to make it use WAY less RAM, but if that doesn't work properly, your solution would be perfect. Thanks, Bogdan ---------- Forwarded message ---------- From: Mike Panetta <panetta.mike at gmail.com> Date: Wed, Nov 12, 2008 at 7:06 AM Subject: Checked in latest changes, new module loader added. To: Bogdan Marinescu <bogdan.marinescu at gmail.com> I just checked in my latest changes. The major additions are a platform (even board) specific lcd driver/lua module and a new lua module 'rom loader'. The object of the rom loader is to reduce the ram footprint of lua by not loading the module tables of unused modules. I hope you like it and decide to change over the generic modules to use it. I also added a small enhancement to registering constants. Instead of everyone registering their own functions to do the lookup I have a generic one in modcommon.c that can be used to do it. The only overhead is the addition of a lightuserdata type to the module table that is used to do the lookups. See modcommon.c and modcommon.h for all the details. All the code has been tested on my STM3210E-EVAL and works. (Lua is suprisingly fast on these cortex processors BTW!) None of the changes should have affected any other platform. If they did, then I did something wrong, please tell me so I can fix it. Soon I may set my LM3S8962 kit up so I can test and port some of these enhancements over to that platform as well if you want/need me to due to time constraints. If you don't like the way I did something or if you have any questions about what I did please feel free to shoot me an email. :) Thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081112/55e3f1a6/attachment.html |
|
|
Hi,
A few observations about your code: - I'm not sure I fully understand what the code in modcommon.c/luaopen_mod does. Is this some sort of "lazy initialization", in that a module is only initialized when first needed? Could you give an example of using that? - I understand what you're trying to do with modcommon.c/elua_resigter_const, but I'm afraid that it might do more bad than good at times. Simply because you're creating a new table, an operation that eats a lot of memory (at least that's what I got from my tests). You might want to do some testing and find a "point an equilibrium", i.e. find an approximation of what's the minimum number of constants you need to register with your method to make your idea save memory instead of waste memory. - This is completely my fault, but your coding style is completely different from mine. Sorry, I should've released an "eLua coding style guide" quite a while ago, but I completely forgot. I'll try to do this as soon as possible. All in all, excellent work, and I can only hope you'll keep it up! :) Best, Bogdan On Wed, Nov 12, 2008 at 10:27 AM, Bogdan Marinescu < bogdan.marinescu at gmail.com> wrote: > Forwarding to the list. Mike, let's use the list for further development > discussions, I just added you to the list. > I'll take a look at your loader, it sure sounds interesting. I'm actually > preparing a patch (for Lua) to make it use WAY less RAM, but if that doesn't > work properly, your solution would be perfect. > > Thanks, > Bogdan > > > ---------- Forwarded message ---------- > From: Mike Panetta <panetta.mike at gmail.com> > Date: Wed, Nov 12, 2008 at 7:06 AM > Subject: Checked in latest changes, new module loader added. > To: Bogdan Marinescu <bogdan.marinescu at gmail.com> > > > I just checked in my latest changes. The major additions are a platform > (even board) specific lcd driver/lua module and a new lua module 'rom > loader'. > > The object of the rom loader is to reduce the ram footprint of lua by not > loading the module tables of unused modules. I hope you like it and decide > to change over the generic modules to use it. I also added a small > enhancement to registering constants. Instead of everyone registering their > own functions to do the lookup I have a generic one in modcommon.c that can > be used to do it. The only overhead is the addition of a lightuserdata type > to the module table that is used to do the lookups. See modcommon.c and > modcommon.h for all the details. > > All the code has been tested on my STM3210E-EVAL and works. (Lua is > suprisingly fast on these cortex processors BTW!) > > None of the changes should have affected any other platform. If they did, > then I did something wrong, please tell me so I can fix it. > > Soon I may set my LM3S8962 kit up so I can test and port some of these > enhancements over to that platform as well if you want/need me to due to > time constraints. > > If you don't like the way I did something or if you have any questions > about what I did please feel free to shoot me an email. :) > > Thanks, > Mike > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081112/23f1dd21/attachment.html |
 
|
Dado Sutter |
Checked in latest changes, new module loader added.
|
|
Hello eLua rockers :)
Dear Mike, I'm pleased to meet you ! :) Thank you very much for the port and welcome to the eLua dev list. I'm also proud to announce that our RIT128x96x4 OLED driver for the LuminaMicro ARM Cortex M3 board, worked fine yesterday (!!!). I'll commit it right after discussing one or two points here on the list. Also, we bought two ATVEVK1100 boards<http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4114>, one for Bogdan and one for us, to add Atmel to our list of supported MCUs. I won't get mine before december 3rd but hopefully Bogdan will get his some two weeks from now. Best Dado On Wed, Nov 12, 2008 at 7:02 AM, Bogdan Marinescu < bogdan.marinescu at gmail.com> wrote: > Hi, > > A few observations about your code: > > - I'm not sure I fully understand what the code in modcommon.c/luaopen_mod > does. Is this some sort of "lazy initialization", in that a module is only > initialized when first needed? Could you give an example of using that? > - I understand what you're trying to do with > modcommon.c/elua_resigter_const, but I'm afraid that it might do more bad > than good at times. Simply because you're creating a new table, an operation > that eats a lot of memory (at least that's what I got from my tests). You > might want to do some testing and find a "point an equilibrium", i.e. find > an approximation of what's the minimum number of constants you need to > register with your method to make your idea save memory instead of waste > memory. > - This is completely my fault, but your coding style is completely > different from mine. Sorry, I should've released an "eLua coding style > guide" quite a while ago, but I completely forgot. I'll try to do this as > soon as possible. > > All in all, excellent work, and I can only hope you'll keep it up! :) > > Best, > Bogdan > > > On Wed, Nov 12, 2008 at 10:27 AM, Bogdan Marinescu < > bogdan.marinescu at gmail.com> wrote: > >> Forwarding to the list. Mike, let's use the list for further development >> discussions, I just added you to the list. >> I'll take a look at your loader, it sure sounds interesting. I'm actually >> preparing a patch (for Lua) to make it use WAY less RAM, but if that doesn't >> work properly, your solution would be perfect. >> >> Thanks, >> Bogdan >> >> >> ---------- Forwarded message ---------- >> From: Mike Panetta <panetta.mike at gmail.com> >> Date: Wed, Nov 12, 2008 at 7:06 AM >> Subject: Checked in latest changes, new module loader added. >> To: Bogdan Marinescu <bogdan.marinescu at gmail.com> >> >> >> I just checked in my latest changes. The major additions are a platform >> (even board) specific lcd driver/lua module and a new lua module 'rom >> loader'. >> >> The object of the rom loader is to reduce the ram footprint of lua by not >> loading the module tables of unused modules. I hope you like it and decide >> to change over the generic modules to use it. I also added a small >> enhancement to registering constants. Instead of everyone registering their >> own functions to do the lookup I have a generic one in modcommon.c that can >> be used to do it. The only overhead is the addition of a lightuserdata type >> to the module table that is used to do the lookups. See modcommon.c and >> modcommon.h for all the details. >> >> All the code has been tested on my STM3210E-EVAL and works. (Lua is >> suprisingly fast on these cortex processors BTW!) >> >> None of the changes should have affected any other platform. If they did, >> then I did something wrong, please tell me so I can fix it. >> >> Soon I may set my LM3S8962 kit up so I can test and port some of these >> enhancements over to that platform as well if you want/need me to due to >> time constraints. >> >> If you don't like the way I did something or if you have any questions >> about what I did please feel free to shoot me an email. :) >> >> Thanks, >> Mike >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081112/426bd4d6/attachment.html |
|
|
Mike Panetta |
Checked in latest changes, new module loader added.
|
|
In reply to this post by BogdanM
See below for answers. And thank you for adding me to the list :)
On Wed, Nov 12, 2008 at 4:02 AM, Bogdan Marinescu < bogdan.marinescu at gmail.com> wrote: > Hi, > > A few observations about your code: > > - I'm not sure I fully understand what the code in modcommon.c/luaopen_mod > does. Is this some sort of "lazy initialization", in that a module is only > initialized when first needed? Could you give an example of using that? Yup. I am taking advantage of the lua package.preload table to allow one to use require to pull in the module when needed. All luaopen_mod does is get the list of module entry functions from the .lua_init section and plug them into the package.preload table (see http://www.lua.org/manual/5.1/manual.html#pdf-require for why). I realised after I checked the code in that I probably could have documented it a bit better, sorry about that. It was around 1:00am my time and I was getting tired. :) Right now this may not give much of an advantage, but when we reach the point of having more available modules then used ones this could be a great advantage, as the module tables (and associated overhead) for the unused modules won't be created until they are 'require'd. Basically I am trading ROM(Flash) space for RAM under the notion that we have much more available ROM then RAM. > - I understand what you're trying to do with > modcommon.c/elua_resigter_const, but I'm afraid that it might do more bad > than good at times. Simply because you're creating a new table, an operation > that eats a lot of memory (at least that's what I got from my tests). You > might want to do some testing and find a "point an equilibrium", i.e. find > an approximation of what's the minimum number of constants you need to > register with your method to make your idea save memory instead of waste > memory. Yeah, I figured that would be the case. I have no idea how large a table is in memory, but I figured it was not insignificant. The idea was to be used in cases like the CPU module where alot of constants are used. In fact thats where I got (stole?) the idea from. :) > > - This is completely my fault, but your coding style is completely > different from mine. Sorry, I should've released an "eLua coding style > guide" quite a while ago, but I completely forgot. I'll try to do this as > soon as possible. Yeah, I need to run the files through indent. If you tell me your tab styles I can do that and put a VI macro at the end of the files so my editor uses them every time. I just kind of cranked that code out fast thinking I would fix formatting later. As for the dos formatted files, that would be because I used RIDE to edit some of the files and the editor converted the files for me :(. Also the ST Micro provided files are dos formatted I think, but we may not want to change that so that updating the FWLib from ST Micro is more straight forward. > > All in all, excellent work, and I can only hope you'll keep it up! :) Thanks :) > > > Best, > Bogdan > Thanks, Mike > > > On Wed, Nov 12, 2008 at 10:27 AM, Bogdan Marinescu < > bogdan.marinescu at gmail.com> wrote: > >> Forwarding to the list. Mike, let's use the list for further development >> discussions, I just added you to the list. >> I'll take a look at your loader, it sure sounds interesting. I'm actually >> preparing a patch (for Lua) to make it use WAY less RAM, but if that doesn't >> work properly, your solution would be perfect. >> >> Thanks, >> Bogdan >> >> >> ---------- Forwarded message ---------- >> From: Mike Panetta <panetta.mike at gmail.com> >> Date: Wed, Nov 12, 2008 at 7:06 AM >> Subject: Checked in latest changes, new module loader added. >> To: Bogdan Marinescu <bogdan.marinescu at gmail.com> >> >> >> I just checked in my latest changes. The major additions are a platform >> (even board) specific lcd driver/lua module and a new lua module 'rom >> loader'. >> >> The object of the rom loader is to reduce the ram footprint of lua by not >> loading the module tables of unused modules. I hope you like it and decide >> to change over the generic modules to use it. I also added a small >> enhancement to registering constants. Instead of everyone registering their >> own functions to do the lookup I have a generic one in modcommon.c that can >> be used to do it. The only overhead is the addition of a lightuserdata type >> to the module table that is used to do the lookups. See modcommon.c and >> modcommon.h for all the details. >> >> All the code has been tested on my STM3210E-EVAL and works. (Lua is >> suprisingly fast on these cortex processors BTW!) >> >> None of the changes should have affected any other platform. If they did, >> then I did something wrong, please tell me so I can fix it. >> >> Soon I may set my LM3S8962 kit up so I can test and port some of these >> enhancements over to that platform as well if you want/need me to due to >> time constraints. >> >> If you don't like the way I did something or if you have any questions >> about what I did please feel free to shoot me an email. :) >> >> Thanks, >> Mike >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081112/47f8eb19/attachment.html |
|
|
Mike Panetta |
Checked in latest changes, new module loader added.
|
|
In reply to this post by Dado Sutter
Thanks. :)
These cortex-m3 parts have been very impressive so far! Congrats on the Luminary OLED driver! My first choice for a port was going to be an AVR32, but based on chip prices and potential power savings I decided to go with the STM32 part. The AVR32 is definitely an impressive chip however, and I look forward to the port. One day I hope to see lua replace basic for all the medium range 'stamp' like applications out there! In fact, when I get a chance I think I am going to try and write me a PID control routine in lua and see how well it performs. Mike On Wed, Nov 12, 2008 at 4:39 AM, Dado Sutter <dadosutter at gmail.com> wrote: > Hello eLua rockers :) > Dear Mike, I'm pleased to meet you ! :) > Thank you very much for the port and welcome to the eLua dev list. > I'm also proud to announce that our RIT128x96x4 OLED driver for the > LuminaMicro ARM Cortex M3 board, worked fine yesterday (!!!). > I'll commit it right after discussing one or two points here on the > list. > Also, we bought two ATVEVK1100 boards<http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4114>, > one for Bogdan and one for us, to add Atmel to our list of supported MCUs. > I won't get mine before december 3rd but hopefully Bogdan will get his > some two weeks from now. > > Best > Dado > > > > > On Wed, Nov 12, 2008 at 7:02 AM, Bogdan Marinescu < > bogdan.marinescu at gmail.com> wrote: > >> Hi, >> >> A few observations about your code: >> >> - I'm not sure I fully understand what the code in modcommon.c/luaopen_mod >> does. Is this some sort of "lazy initialization", in that a module is only >> initialized when first needed? Could you give an example of using that? >> - I understand what you're trying to do with >> modcommon.c/elua_resigter_const, but I'm afraid that it might do more bad >> than good at times. Simply because you're creating a new table, an operation >> that eats a lot of memory (at least that's what I got from my tests). You >> might want to do some testing and find a "point an equilibrium", i.e. find >> an approximation of what's the minimum number of constants you need to >> register with your method to make your idea save memory instead of waste >> memory. >> - This is completely my fault, but your coding style is completely >> different from mine. Sorry, I should've released an "eLua coding style >> guide" quite a while ago, but I completely forgot. I'll try to do this as >> soon as possible. >> >> All in all, excellent work, and I can only hope you'll keep it up! :) >> >> Best, >> Bogdan >> >> >> On Wed, Nov 12, 2008 at 10:27 AM, Bogdan Marinescu < >> bogdan.marinescu at gmail.com> wrote: >> >>> Forwarding to the list. Mike, let's use the list for further development >>> discussions, I just added you to the list. >>> I'll take a look at your loader, it sure sounds interesting. I'm actually >>> preparing a patch (for Lua) to make it use WAY less RAM, but if that doesn't >>> work properly, your solution would be perfect. >>> >>> Thanks, >>> Bogdan >>> >>> >>> ---------- Forwarded message ---------- >>> From: Mike Panetta <panetta.mike at gmail.com> >>> Date: Wed, Nov 12, 2008 at 7:06 AM >>> Subject: Checked in latest changes, new module loader added. >>> To: Bogdan Marinescu <bogdan.marinescu at gmail.com> >>> >>> >>> I just checked in my latest changes. The major additions are a platform >>> (even board) specific lcd driver/lua module and a new lua module 'rom >>> loader'. >>> >>> The object of the rom loader is to reduce the ram footprint of lua by not >>> loading the module tables of unused modules. I hope you like it and decide >>> to change over the generic modules to use it. I also added a small >>> enhancement to registering constants. Instead of everyone registering their >>> own functions to do the lookup I have a generic one in modcommon.c that can >>> be used to do it. The only overhead is the addition of a lightuserdata type >>> to the module table that is used to do the lookups. See modcommon.c and >>> modcommon.h for all the details. >>> >>> All the code has been tested on my STM3210E-EVAL and works. (Lua is >>> suprisingly fast on these cortex processors BTW!) >>> >>> None of the changes should have affected any other platform. If they did, >>> then I did something wrong, please tell me so I can fix it. >>> >>> Soon I may set my LM3S8962 kit up so I can test and port some of these >>> enhancements over to that platform as well if you want/need me to due to >>> time constraints. >>> >>> If you don't like the way I did something or if you have any questions >>> about what I did please feel free to shoot me an email. :) >>> >>> Thanks, >>> Mike >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081112/d2a24984/attachment.html |
|
|
Dado Sutter-2 |
Checked in latest changes, new module loader added.
|
|
Hello All,
Mike, we actually have a big need of a nice PID module downhere (for the Riobotz, PUC-Rio's combat robot team and some other aplications). I begun to specify one but the speed-of-light pace that the eLua project is going on now have stopped me do go ahead now :( :( The idea would simply have the constants (or functions) easially defined in the module AND to include at least two (optionally activated) filters. I'd be very glad to discuss this here on the list and I'll gather some more involved people to express their needs too. It is definetely a very important module for eLua asap. Thanks for the iniciative !!! Best Dado On Wed, Nov 12, 2008 at 10:32 AM, Mike Panetta <panetta.mike at gmail.com>wrote: > Thanks. :) > > These cortex-m3 parts have been very impressive so far! Congrats on the > Luminary OLED driver! > > My first choice for a port was going to be an AVR32, but based on chip > prices and potential power savings I decided to go with the STM32 part. The > AVR32 is definitely an impressive chip however, and I look forward to the > port. > > One day I hope to see lua replace basic for all the medium range 'stamp' > like applications out there! In fact, when I get a chance I think I am > going to try and write me a PID control routine in lua and see how well it > performs. > > Mike > > > On Wed, Nov 12, 2008 at 4:39 AM, Dado Sutter <dadosutter at gmail.com> wrote: > >> Hello eLua rockers :) >> Dear Mike, I'm pleased to meet you ! :) >> Thank you very much for the port and welcome to the eLua dev list. >> I'm also proud to announce that our RIT128x96x4 OLED driver for the >> LuminaMicro ARM Cortex M3 board, worked fine yesterday (!!!). >> I'll commit it right after discussing one or two points here on the >> list. >> Also, we bought two ATVEVK1100 boards<http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4114>, >> one for Bogdan and one for us, to add Atmel to our list of supported MCUs. >> I won't get mine before december 3rd but hopefully Bogdan will get his >> some two weeks from now. >> >> Best >> Dado >> >> >> >> >> On Wed, Nov 12, 2008 at 7:02 AM, Bogdan Marinescu < >> bogdan.marinescu at gmail.com> wrote: >> >>> Hi, >>> >>> A few observations about your code: >>> >>> - I'm not sure I fully understand what the code in >>> modcommon.c/luaopen_mod does. Is this some sort of "lazy initialization", in >>> that a module is only initialized when first needed? Could you give an >>> example of using that? >>> - I understand what you're trying to do with >>> modcommon.c/elua_resigter_const, but I'm afraid that it might do more bad >>> than good at times. Simply because you're creating a new table, an operation >>> that eats a lot of memory (at least that's what I got from my tests). You >>> might want to do some testing and find a "point an equilibrium", i.e. find >>> an approximation of what's the minimum number of constants you need to >>> register with your method to make your idea save memory instead of waste >>> memory. >>> - This is completely my fault, but your coding style is completely >>> different from mine. Sorry, I should've released an "eLua coding style >>> guide" quite a while ago, but I completely forgot. I'll try to do this as >>> soon as possible. >>> >>> All in all, excellent work, and I can only hope you'll keep it up! :) >>> >>> Best, >>> Bogdan >>> >>> >>> On Wed, Nov 12, 2008 at 10:27 AM, Bogdan Marinescu < >>> bogdan.marinescu at gmail.com> wrote: >>> >>>> Forwarding to the list. Mike, let's use the list for further development >>>> discussions, I just added you to the list. >>>> I'll take a look at your loader, it sure sounds interesting. I'm >>>> actually preparing a patch (for Lua) to make it use WAY less RAM, but if >>>> that doesn't work properly, your solution would be perfect. >>>> >>>> Thanks, >>>> Bogdan >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Mike Panetta <panetta.mike at gmail.com> >>>> Date: Wed, Nov 12, 2008 at 7:06 AM >>>> Subject: Checked in latest changes, new module loader added. >>>> To: Bogdan Marinescu <bogdan.marinescu at gmail.com> >>>> >>>> >>>> I just checked in my latest changes. The major additions are a platform >>>> (even board) specific lcd driver/lua module and a new lua module 'rom >>>> loader'. >>>> >>>> The object of the rom loader is to reduce the ram footprint of lua by >>>> not loading the module tables of unused modules. I hope you like it and >>>> decide to change over the generic modules to use it. I also added a small >>>> enhancement to registering constants. Instead of everyone registering their >>>> own functions to do the lookup I have a generic one in modcommon.c that can >>>> be used to do it. The only overhead is the addition of a lightuserdata type >>>> to the module table that is used to do the lookups. See modcommon.c and >>>> modcommon.h for all the details. >>>> >>>> All the code has been tested on my STM3210E-EVAL and works. (Lua is >>>> suprisingly fast on these cortex processors BTW!) >>>> >>>> None of the changes should have affected any other platform. If they >>>> did, then I did something wrong, please tell me so I can fix it. >>>> >>>> Soon I may set my LM3S8962 kit up so I can test and port some of these >>>> enhancements over to that platform as well if you want/need me to due to >>>> time constraints. >>>> >>>> If you don't like the way I did something or if you have any questions >>>> about what I did please feel free to shoot me an email. :) >>>> >>>> Thanks, >>>> Mike >>>> >>>> >>> >>> _______________________________________________ >>> Elua-dev mailing list >>> Elua-dev at lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >> >> _______________________________________________ >> Elua-dev mailing list >> Elua-dev at lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > _______________________________________________ > Elua-dev mailing list > Elua-dev at lists.berlios.de > https://lists.berlios.de/mailman/listinfo/elua-dev > > An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081112/2bbfeba1/attachment-0001.html |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |