I'm back! (Finally)
Locked
|
I had a few bumps in the road lately (got layed off at work...) but I am
back on track a bit now ready to do more STM32 work (I asked for the kit since they were not going to use it anymore, and they gave it to me!). Does anyone have any suggestions or ideas for me? I was thinking about trying to port Dados pong to it... And of course fix up the I2C module. We should maybe start a discussion on what modules need to be done etc that are on the list that maybe I or others could work on? Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20081210/3ce95a8e/attachment.html |
|
|
Hello Mike ! Nice to have you back ! Someone of this list arranged to lay
you off at work :) :) :) The current version of Pong depends only on a PutChar (on RIT display it is called stringdraw() ) function to draw the ball and the paddle. If you have pixel resolution to position it, instead of just lines x columns, your ball will move smootly too. The driver/wrapper was implemented in a module called "disp", which is not good because it is platform-dependend. Also, the Lua code now requires (yes, with require() ) a Lua module, called LM3S, that introduces the Luminary Micro onboard goodies, like the buttons, leds and some utility functions. This module is easially adaptable for your board devices (or external components connected to it). I've been playing also with a version that implements everything in C and it would be nice if we could load it dinamically (we don't have dinamically loadable C modules, yet), only if the board is an LM3S platform. So, as you can see, I've been playing a lot with different ways to write modules, none of them to definitive yet. We must bring some more discussion to the list, to show the pros & cons of each approach. Teo and Ives has been working on a GPS module, 100% Lua (for now), with lots of good points to discuss here too. We will have to write add an INT handler for it (UART Rx), even not beeing a generic INT module for eLua yet, as well as circular queues for the input stream (just for fun, once GPS Rx doesn' t really need it :) I also need a Counter module, to read an RGB+Pan light sensor and, again, I'll probably write it in C, over the Luminary Micro low level lib for Timers and GPIO. It will not be a generic Counter module for eLua yet but it should do the work for a small project here. These many possibilities for eLua module architectures may confuse users at first but they are actually very versatile and I hope to write about it on the wiki asap. Pedro is working on a PID module, 100% Lua and it will work over ADC and DAC modules, that eLua also needs. Some other games are comming too :) as they are great for my students to learn Lua, eLua, real-time programming and, last but not least, to have fun !! :) Me and Bogdan have received an AVR32 board too, the EVK1100 and Bogdan will begin to port eLua to it soon, with some possible issues due to what Atmel has done to Newlib. Downhere, I will see what I can do for the Legos NXTs, as soon as the classes are over and I can put my hands again on a kit :) :) So welcome back and send us your ideas ! :) Best Dado On Wed, Dec 10, 2008 at 17:53, Mike Panetta <panetta.mike at gmail.com> wrote: > I had a few bumps in the road lately (got layed off at work...) but I am > back on track a bit now ready to do more STM32 work (I asked for the kit > since they were not going to use it anymore, and they gave it to me!). > > Does anyone have any suggestions or ideas for me? I was thinking about > trying to port Dados pong to it... And of course fix up the I2C module. We > should maybe start a discussion on what modules need to be done etc that are > on the list that maybe I or others could work on? > > 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/20081210/ca600b61/attachment.html |
|
|
Dado,
Actually, we HAVE pixel resolution with the RIT display, we simply do not use it (yet). (we can achieve that with the draw() function, where we can "draw" a given matrix in the (x,y) position, a.k.a. offset, of the display) --Pedro Bittencourt On Wed, Dec 10, 2008 at 8:31 PM, Dado Sutter <dadosutter at gmail.com> wrote: > Hello Mike ! Nice to have you back ! Someone of this list arranged to > lay you off at work :) :) :) > The current version of Pong depends only on a PutChar (on RIT display it > is called stringdraw() ) function to draw the ball and the paddle. If you > have pixel resolution to position it, instead of just lines x columns, your > ball will move smootly too. > The driver/wrapper was implemented in a module called "disp", which is > not good because it is platform-dependend. Also, the Lua code now requires > (yes, with require() ) a Lua module, called LM3S, that introduces the > Luminary Micro onboard goodies, like the buttons, leds and some utility > functions. This module is easially adaptable for your board devices (or > external components connected to it). I've been playing also with a version > that implements everything in C and it would be nice if we could load it > dinamically (we don't have dinamically loadable C modules, yet), only if the > board is an LM3S platform. > So, as you can see, I've been playing a lot with different ways to write > modules, none of them to definitive yet. We must bring some more discussion > to the list, to show the pros & cons of each approach. > Teo and Ives has been working on a GPS module, 100% Lua (for now), with > lots of good points to discuss here too. We will have to write add an INT > handler for it (UART Rx), even not beeing a generic INT module for eLua yet, > as well as circular queues for the input stream (just for fun, once GPS Rx > doesn' t really need it :) > I also need a Counter module, to read an RGB+Pan light sensor and, > again, I'll probably write it in C, over the Luminary Micro low level lib > for Timers and GPIO. It will not be a generic Counter module for eLua yet > but it should do the work for a small project here. > These many possibilities for eLua module architectures may confuse users > at first but they are actually very versatile and I hope to write about it > on the wiki asap. > Pedro is working on a PID module, 100% Lua and it will work over ADC and > DAC modules, that eLua also needs. > Some other games are comming too :) as they are great for my students to > learn Lua, eLua, real-time programming and, last but not least, to have fun > !! :) > Me and Bogdan have received an AVR32 board too, the EVK1100 and Bogdan > will begin to port eLua to it soon, with some possible issues due to what > Atmel has done to Newlib. Downhere, I will see what I can do for the Legos > NXTs, as soon as the classes are over and I can put my hands again on a kit > :) :) > So welcome back and send us your ideas ! :) > > Best > Dado > > > On Wed, Dec 10, 2008 at 17:53, Mike Panetta <panetta.mike at gmail.com>wrote: > >> I had a few bumps in the road lately (got layed off at work...) but I am >> back on track a bit now ready to do more STM32 work (I asked for the kit >> since they were not going to use it anymore, and they gave it to me!). >> >> Does anyone have any suggestions or ideas for me? I was thinking about >> trying to port Dados pong to it... And of course fix up the I2C module. We >> should maybe start a discussion on what modules need to be done etc that are >> on the list that maybe I or others could work on? >> >> 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/20081210/ee4bd472/attachment-0001.html |
|
|
We also have loadable modules, at least on STM32. Take a look at
modcommon.c in the modules dir, function luaopen_mod, and the lua_lcd.c file in platform/stm32/ for an example of how its used. At the end of the file I create a luaL_reg struct with a single entry that gets placed in a special location in memory via the linker script and the section attribute. luaopen_mod uses the package.preload table entry to push a handler to call the luaopen_lcd init function when someone does a require 'stm3210lcd'. So while the FLASH space is always used for the module, the RAM space required for the module table and etc are not loaded until someone calls require. Comments on this methodology are very welcome! Mike On Wed, Dec 10, 2008 at 6:34 PM, Pedro Bittencourt < pedrobittencourt87 at gmail.com> wrote: > Dado, > > Actually, we HAVE pixel resolution with the RIT display, we simply do not > use it (yet). > > (we can achieve that with the draw() function, where we can "draw" a given > matrix in the (x,y) position, a.k.a. offset, of the display) > > --Pedro Bittencourt > > > > On Wed, Dec 10, 2008 at 8:31 PM, Dado Sutter <dadosutter at gmail.com> wrote: > >> Hello Mike ! Nice to have you back ! Someone of this list arranged to >> lay you off at work :) :) :) >> The current version of Pong depends only on a PutChar (on RIT display >> it is called stringdraw() ) function to draw the ball and the paddle. If you >> have pixel resolution to position it, instead of just lines x columns, your >> ball will move smootly too. >> The driver/wrapper was implemented in a module called "disp", which is >> not good because it is platform-dependend. Also, the Lua code now requires >> (yes, with require() ) a Lua module, called LM3S, that introduces the >> Luminary Micro onboard goodies, like the buttons, leds and some utility >> functions. This module is easially adaptable for your board devices (or >> external components connected to it). I've been playing also with a version >> that implements everything in C and it would be nice if we could load it >> dinamically (we don't have dinamically loadable C modules, yet), only if the >> board is an LM3S platform. >> So, as you can see, I've been playing a lot with different ways to >> write modules, none of them to definitive yet. We must bring some more >> discussion to the list, to show the pros & cons of each approach. >> Teo and Ives has been working on a GPS module, 100% Lua (for now), with >> lots of good points to discuss here too. We will have to write add an INT >> handler for it (UART Rx), even not beeing a generic INT module for eLua yet, >> as well as circular queues for the input stream (just for fun, once GPS Rx >> doesn' t really need it :) >> I also need a Counter module, to read an RGB+Pan light sensor and, >> again, I'll probably write it in C, over the Luminary Micro low level lib >> for Timers and GPIO. It will not be a generic Counter module for eLua yet >> but it should do the work for a small project here. >> These many possibilities for eLua module architectures may confuse >> users at first but they are actually very versatile and I hope to write >> about it on the wiki asap. >> Pedro is working on a PID module, 100% Lua and it will work over ADC >> and DAC modules, that eLua also needs. >> Some other games are comming too :) as they are great for my students >> to learn Lua, eLua, real-time programming and, last but not least, to have >> fun !! :) >> Me and Bogdan have received an AVR32 board too, the EVK1100 and Bogdan >> will begin to port eLua to it soon, with some possible issues due to what >> Atmel has done to Newlib. Downhere, I will see what I can do for the Legos >> NXTs, as soon as the classes are over and I can put my hands again on a kit >> :) :) >> So welcome back and send us your ideas ! :) >> >> Best >> Dado >> >> >> On Wed, Dec 10, 2008 at 17:53, Mike Panetta <panetta.mike at gmail.com>wrote: >> >>> I had a few bumps in the road lately (got layed off at work...) but I am >>> back on track a bit now ready to do more STM32 work (I asked for the kit >>> since they were not going to use it anymore, and they gave it to me!). >>> >>> Does anyone have any suggestions or ideas for me? I was thinking about >>> trying to port Dados pong to it... And of course fix up the I2C module. We >>> should maybe start a discussion on what modules need to be done etc that are >>> on the list that maybe I or others could work on? >>> >>> 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/20081210/da3e3611/attachment.html |
|
|
Welcome back Mike! Sorry to hear about your problems, but you seem to be
back on track now, which is a Good Thing :) IMO the most urgent things right now are ADC/DAC modules. It's not that hard to write them, the harder part is the platform interface. We need to extract the common ADC/DAC features from our platforms so far (and I'm not talking just about simple things like adc_setup/adc_sample, but also more complex things, like having an ADC channel "coupled" with a timer channel so it can do periodic sampling automatically (some MCUs can do this directly in hardware, so you don't need to setup an interrupt handler and handle it in software). This is a very desirable feature, but if it can be found on only very few platforms we won't place in the platform interface, but somewhere else. Also, what kind of triggers can the ADC use? And other things that I can't think of right now). We should also continue on the I2C route, of course, going deeper in both the platform interface specification and the Lua module interface (I remember having a discussion about this a while ago but it fade away, maybe it's best to resume from that point, except I can't really find it right now :) ). Best, Bogdan On Thu, Dec 11, 2008 at 4:05 AM, Mike Panetta <panetta.mike at gmail.com>wrote: > We also have loadable modules, at least on STM32. Take a look at > modcommon.c in the modules dir, function luaopen_mod, and the lua_lcd.c file > in platform/stm32/ for an example of how its used. > > At the end of the file I create a luaL_reg struct with a single entry that > gets placed in a special location in memory via the linker script and the > section attribute. luaopen_mod uses the package.preload table entry to push > a handler to call the luaopen_lcd init function when someone does a require > 'stm3210lcd'. > > So while the FLASH space is always used for the module, the RAM space > required for the module table and etc are not loaded until someone calls > require. > > Comments on this methodology are very welcome! > > Mike > > > On Wed, Dec 10, 2008 at 6:34 PM, Pedro Bittencourt < > pedrobittencourt87 at gmail.com> wrote: > >> Dado, >> >> Actually, we HAVE pixel resolution with the RIT display, we simply do not >> use it (yet). >> >> (we can achieve that with the draw() function, where we can "draw" a given >> matrix in the (x,y) position, a.k.a. offset, of the display) >> >> --Pedro Bittencourt >> >> >> >> On Wed, Dec 10, 2008 at 8:31 PM, Dado Sutter <dadosutter at gmail.com>wrote: >> >>> Hello Mike ! Nice to have you back ! Someone of this list arranged to >>> lay you off at work :) :) :) >>> The current version of Pong depends only on a PutChar (on RIT display >>> it is called stringdraw() ) function to draw the ball and the paddle. If you >>> have pixel resolution to position it, instead of just lines x columns, your >>> ball will move smootly too. >>> The driver/wrapper was implemented in a module called "disp", which >>> is not good because it is platform-dependend. Also, the Lua code now >>> requires (yes, with require() ) a Lua module, called LM3S, that introduces >>> the Luminary Micro onboard goodies, like the buttons, leds and some utility >>> functions. This module is easially adaptable for your board devices (or >>> external components connected to it). I've been playing also with a version >>> that implements everything in C and it would be nice if we could load it >>> dinamically (we don't have dinamically loadable C modules, yet), only if the >>> board is an LM3S platform. >>> So, as you can see, I've been playing a lot with different ways to >>> write modules, none of them to definitive yet. We must bring some more >>> discussion to the list, to show the pros & cons of each approach. >>> Teo and Ives has been working on a GPS module, 100% Lua (for now), >>> with lots of good points to discuss here too. We will have to write add an >>> INT handler for it (UART Rx), even not beeing a generic INT module for eLua >>> yet, as well as circular queues for the input stream (just for fun, once GPS >>> Rx doesn' t really need it :) >>> I also need a Counter module, to read an RGB+Pan light sensor and, >>> again, I'll probably write it in C, over the Luminary Micro low level lib >>> for Timers and GPIO. It will not be a generic Counter module for eLua yet >>> but it should do the work for a small project here. >>> These many possibilities for eLua module architectures may confuse >>> users at first but they are actually very versatile and I hope to write >>> about it on the wiki asap. >>> Pedro is working on a PID module, 100% Lua and it will work over ADC >>> and DAC modules, that eLua also needs. >>> Some other games are comming too :) as they are great for my students >>> to learn Lua, eLua, real-time programming and, last but not least, to have >>> fun !! :) >>> Me and Bogdan have received an AVR32 board too, the EVK1100 and Bogdan >>> will begin to port eLua to it soon, with some possible issues due to what >>> Atmel has done to Newlib. Downhere, I will see what I can do for the Legos >>> NXTs, as soon as the classes are over and I can put my hands again on a kit >>> :) :) >>> So welcome back and send us your ideas ! :) >>> >>> Best >>> Dado >>> >>> >>> On Wed, Dec 10, 2008 at 17:53, Mike Panetta <panetta.mike at gmail.com>wrote: >>> >>>> I had a few bumps in the road lately (got layed off at work...) but I am >>>> back on track a bit now ready to do more STM32 work (I asked for the kit >>>> since they were not going to use it anymore, and they gave it to me!). >>>> >>>> Does anyone have any suggestions or ideas for me? I was thinking about >>>> trying to port Dados pong to it... And of course fix up the I2C module. We >>>> should maybe start a discussion on what modules need to be done etc that are >>>> on the list that maybe I or others could work on? >>>> >>>> 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 >> >> > > _______________________________________________ > 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/20081211/dc97700f/attachment-0001.html |
|
|
In reply to this post by Bittencourt
On Wed, Dec 10, 2008 at 21:34, Pedro Bittencourt <
pedrobittencourt87 at gmail.com> wrote: > Dado, > > Actually, we HAVE pixel resolution with the RIT display, we simply do not > use it (yet). Errr :) We HAVE pixel resolution with the RIT display and we DO use it in Pong. We have even overcome the issue of even-column-number-addressing-only, because of the way they pack their pixels (two per byte with the nibble indicating the gray/intensity). > (we can achieve that with the draw() function, where we can "draw" a given > matrix in the (x,y) position, a.k.a. offset, of the display) Yeap, This is what is done in Pong :) But with the stringDraw function (instead of imageDraw()) --Pedro Bittencourt Best Dado > > > > On Wed, Dec 10, 2008 at 8:31 PM, Dado Sutter <dadosutter at gmail.com> wrote: > >> Hello Mike ! Nice to have you back ! Someone of this list arranged to >> lay you off at work :) :) :) >> The current version of Pong depends only on a PutChar (on RIT display >> it is called stringdraw() ) function to draw the ball and the paddle. If you >> have pixel resolution to position it, instead of just lines x columns, your >> ball will move smootly too. >> The driver/wrapper was implemented in a module called "disp", which is >> not good because it is platform-dependend. Also, the Lua code now requires >> (yes, with require() ) a Lua module, called LM3S, that introduces the >> Luminary Micro onboard goodies, like the buttons, leds and some utility >> functions. This module is easially adaptable for your board devices (or >> external components connected to it). I've been playing also with a version >> that implements everything in C and it would be nice if we could load it >> dinamically (we don't have dinamically loadable C modules, yet), only if the >> board is an LM3S platform. >> So, as you can see, I've been playing a lot with different ways to >> write modules, none of them to definitive yet. We must bring some more >> discussion to the list, to show the pros & cons of each approach. >> Teo and Ives has been working on a GPS module, 100% Lua (for now), with >> lots of good points to discuss here too. We will have to write add an INT >> handler for it (UART Rx), even not beeing a generic INT module for eLua yet, >> as well as circular queues for the input stream (just for fun, once GPS Rx >> doesn' t really need it :) >> I also need a Counter module, to read an RGB+Pan light sensor and, >> again, I'll probably write it in C, over the Luminary Micro low level lib >> for Timers and GPIO. It will not be a generic Counter module for eLua yet >> but it should do the work for a small project here. >> These many possibilities for eLua module architectures may confuse >> users at first but they are actually very versatile and I hope to write >> about it on the wiki asap. >> Pedro is working on a PID module, 100% Lua and it will work over ADC >> and DAC modules, that eLua also needs. >> Some other games are comming too :) as they are great for my students >> to learn Lua, eLua, real-time programming and, last but not least, to have >> fun !! :) >> Me and Bogdan have received an AVR32 board too, the EVK1100 and Bogdan >> will begin to port eLua to it soon, with some possible issues due to what >> Atmel has done to Newlib. Downhere, I will see what I can do for the Legos >> NXTs, as soon as the classes are over and I can put my hands again on a kit >> :) :) >> So welcome back and send us your ideas ! :) >> >> Best >> Dado >> >> >> On Wed, Dec 10, 2008 at 17:53, Mike Panetta <panetta.mike at gmail.com>wrote: >> >>> I had a few bumps in the road lately (got layed off at work...) but I am >>> back on track a bit now ready to do more STM32 work (I asked for the kit >>> since they were not going to use it anymore, and they gave it to me!). >>> >>> Does anyone have any suggestions or ideas for me? I was thinking about >>> trying to port Dados pong to it... And of course fix up the I2C module. We >>> should maybe start a discussion on what modules need to be done etc that are >>> on the list that maybe I or others could work on? >>> >>> 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/20081211/2e33f851/attachment.html |
|
|
In reply to this post by Mike Panetta
On Thu, Dec 11, 2008 at 00:05, Mike Panetta <panetta.mike at gmail.com> wrote:
> We also have loadable modules, at least on STM32. Take a look at > modcommon.c in the modules dir, function luaopen_mod, and the lua_lcd.c file > in platform/stm32/ for an example of how its used. Thanks ! I'll take a look... At the end of the file I create a luaL_reg struct with a single entry that > gets placed in a special location in memory via the linker script and the > section attribute. luaopen_mod uses the package.preload table entry to push > a handler to call the luaopen_lcd init function when someone does a require > 'stm3210lcd'. > > So while the FLASH space is always used for the module, the RAM space > required for the module table and etc are not loaded until someone calls > require. > > Comments on this methodology are very welcome! Great too ! Roberto has been trying to tell me there's a right way to do that in Lua but I haven't had time to learn it yet :( You have probably figured it out already !!! > Mike > Best Dado > > > On Wed, Dec 10, 2008 at 6:34 PM, Pedro Bittencourt < > pedrobittencourt87 at gmail.com> wrote: > >> Dado, >> >> Actually, we HAVE pixel resolution with the RIT display, we simply do not >> use it (yet). >> >> (we can achieve that with the draw() function, where we can "draw" a given >> matrix in the (x,y) position, a.k.a. offset, of the display) >> >> --Pedro Bittencourt >> >> >> >> On Wed, Dec 10, 2008 at 8:31 PM, Dado Sutter <dadosutter at gmail.com>wrote: >> >>> Hello Mike ! Nice to have you back ! Someone of this list arranged to >>> lay you off at work :) :) :) >>> The current version of Pong depends only on a PutChar (on RIT display >>> it is called stringdraw() ) function to draw the ball and the paddle. If you >>> have pixel resolution to position it, instead of just lines x columns, your >>> ball will move smootly too. >>> The driver/wrapper was implemented in a module called "disp", which >>> is not good because it is platform-dependend. Also, the Lua code now >>> requires (yes, with require() ) a Lua module, called LM3S, that introduces >>> the Luminary Micro onboard goodies, like the buttons, leds and some utility >>> functions. This module is easially adaptable for your board devices (or >>> external components connected to it). I've been playing also with a version >>> that implements everything in C and it would be nice if we could load it >>> dinamically (we don't have dinamically loadable C modules, yet), only if the >>> board is an LM3S platform. >>> So, as you can see, I've been playing a lot with different ways to >>> write modules, none of them to definitive yet. We must bring some more >>> discussion to the list, to show the pros & cons of each approach. >>> Teo and Ives has been working on a GPS module, 100% Lua (for now), >>> with lots of good points to discuss here too. We will have to write add an >>> INT handler for it (UART Rx), even not beeing a generic INT module for eLua >>> yet, as well as circular queues for the input stream (just for fun, once GPS >>> Rx doesn' t really need it :) >>> I also need a Counter module, to read an RGB+Pan light sensor and, >>> again, I'll probably write it in C, over the Luminary Micro low level lib >>> for Timers and GPIO. It will not be a generic Counter module for eLua yet >>> but it should do the work for a small project here. >>> These many possibilities for eLua module architectures may confuse >>> users at first but they are actually very versatile and I hope to write >>> about it on the wiki asap. >>> Pedro is working on a PID module, 100% Lua and it will work over ADC >>> and DAC modules, that eLua also needs. >>> Some other games are comming too :) as they are great for my students >>> to learn Lua, eLua, real-time programming and, last but not least, to have >>> fun !! :) >>> Me and Bogdan have received an AVR32 board too, the EVK1100 and Bogdan >>> will begin to port eLua to it soon, with some possible issues due to what >>> Atmel has done to Newlib. Downhere, I will see what I can do for the Legos >>> NXTs, as soon as the classes are over and I can put my hands again on a kit >>> :) :) >>> So welcome back and send us your ideas ! :) >>> >>> Best >>> Dado >>> >>> >>> On Wed, Dec 10, 2008 at 17:53, Mike Panetta <panetta.mike at gmail.com>wrote: >>> >>>> I had a few bumps in the road lately (got layed off at work...) but I am >>>> back on track a bit now ready to do more STM32 work (I asked for the kit >>>> since they were not going to use it anymore, and they gave it to me!). >>>> >>>> Does anyone have any suggestions or ideas for me? I was thinking about >>>> trying to port Dados pong to it... And of course fix up the I2C module. We >>>> should maybe start a discussion on what modules need to be done etc that are >>>> on the list that maybe I or others could work on? >>>> >>>> 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 >> >> > > _______________________________________________ > 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/20081211/2bfa9f41/attachment.html |
|
|
> Great too !
> Roberto has been trying to tell me there's a right way to do that in Lua > but I haven't had time to learn it yet :( > You have probably figured it out already !!! > I think you might be talking about different things. Mike it talking about his load-on-demand mechanism (which is nice BTW), while you're probably talking about how to set the paths? I still wait for the day when I'll have enough time to implement loadable C modules in eLua ... :( Best, Bogdan > > > >> Mike >> > > Best > Dado > > > > > > > >> >> >> On Wed, Dec 10, 2008 at 6:34 PM, Pedro Bittencourt < >> pedrobittencourt87 at gmail.com> wrote: >> >>> Dado, >>> >>> Actually, we HAVE pixel resolution with the RIT display, we simply do not >>> use it (yet). >>> >>> (we can achieve that with the draw() function, where we can "draw" a >>> given matrix in the (x,y) position, a.k.a. offset, of the display) >>> >>> --Pedro Bittencourt >>> >>> >>> >>> On Wed, Dec 10, 2008 at 8:31 PM, Dado Sutter <dadosutter at gmail.com>wrote: >>> >>>> Hello Mike ! Nice to have you back ! Someone of this list arranged to >>>> lay you off at work :) :) :) >>>> The current version of Pong depends only on a PutChar (on RIT display >>>> it is called stringdraw() ) function to draw the ball and the paddle. If you >>>> have pixel resolution to position it, instead of just lines x columns, your >>>> ball will move smootly too. >>>> The driver/wrapper was implemented in a module called "disp", which >>>> is not good because it is platform-dependend. Also, the Lua code now >>>> requires (yes, with require() ) a Lua module, called LM3S, that introduces >>>> the Luminary Micro onboard goodies, like the buttons, leds and some utility >>>> functions. This module is easially adaptable for your board devices (or >>>> external components connected to it). I've been playing also with a version >>>> that implements everything in C and it would be nice if we could load it >>>> dinamically (we don't have dinamically loadable C modules, yet), only if the >>>> board is an LM3S platform. >>>> So, as you can see, I've been playing a lot with different ways to >>>> write modules, none of them to definitive yet. We must bring some more >>>> discussion to the list, to show the pros & cons of each approach. >>>> Teo and Ives has been working on a GPS module, 100% Lua (for now), >>>> with lots of good points to discuss here too. We will have to write add an >>>> INT handler for it (UART Rx), even not beeing a generic INT module for eLua >>>> yet, as well as circular queues for the input stream (just for fun, once GPS >>>> Rx doesn' t really need it :) >>>> I also need a Counter module, to read an RGB+Pan light sensor and, >>>> again, I'll probably write it in C, over the Luminary Micro low level lib >>>> for Timers and GPIO. It will not be a generic Counter module for eLua yet >>>> but it should do the work for a small project here. >>>> These many possibilities for eLua module architectures may confuse >>>> users at first but they are actually very versatile and I hope to write >>>> about it on the wiki asap. >>>> Pedro is working on a PID module, 100% Lua and it will work over ADC >>>> and DAC modules, that eLua also needs. >>>> Some other games are comming too :) as they are great for my students >>>> to learn Lua, eLua, real-time programming and, last but not least, to have >>>> fun !! :) >>>> Me and Bogdan have received an AVR32 board too, the EVK1100 and >>>> Bogdan will begin to port eLua to it soon, with some possible issues due to >>>> what Atmel has done to Newlib. Downhere, I will see what I can do for the >>>> Legos NXTs, as soon as the classes are over and I can put my hands again on >>>> a kit :) :) >>>> So welcome back and send us your ideas ! :) >>>> >>>> Best >>>> Dado >>>> >>>> >>>> On Wed, Dec 10, 2008 at 17:53, Mike Panetta <panetta.mike at gmail.com>wrote: >>>> >>>>> I had a few bumps in the road lately (got layed off at work...) but I >>>>> am back on track a bit now ready to do more STM32 work (I asked for the kit >>>>> since they were not going to use it anymore, and they gave it to me!). >>>>> >>>>> Does anyone have any suggestions or ideas for me? I was thinking about >>>>> trying to port Dados pong to it... And of course fix up the I2C module. We >>>>> should maybe start a discussion on what modules need to be done etc that are >>>>> on the list that maybe I or others could work on? >>>>> >>>>> 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 >>> >>> >> >> _______________________________________________ >> 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/20081211/6b603db2/attachment-0001.html |
|
|
In reply to this post by BogdanM
Hello,
On Thu, Dec 11, 2008 at 06:11, Bogdan Marinescu <bogdan.marinescu at gmail.com>wrote: > Welcome back Mike! Sorry to hear about your problems, but you seem to be > back on track now, which is a Good Thing :) > > IMO the most urgent things right now are ADC/DAC modules. It's not that > hard to write them, the harder part is the platform interface. We need to > extract the common ADC/DAC features from our platforms so far (and I'm not > talking just about simple things like adc_setup/adc_sample, but also more > complex things, like having an ADC channel "coupled" with a timer channel so > it can do periodic sampling automatically (some MCUs can do this directly in > hardware, so you don't need to setup an interrupt handler and handle it in > software). This is a very desirable feature, but if it can be found on only > very few platforms we won't place in the platform interface, but somewhere > else. Also, what kind of triggers can the ADC use? And other things that I > can't think of right now). This is where I am now, trying to learn the pros and cons of each module implementation aproach, in my still-hard-to-find-exclusive-time-for-eLua-dev-and-studies :( I'll keep learning from you guys !!! :) ADC/DCA are certainly very important additions to eLua now and you have my vote here too. The PID module will be a natural consequence and will finally be tested. But some of our platforms do not have DACs, so we should provide a way to map them thru SPI too. How would this be handled in this module approach ? We should also continue on the I2C route, of course, going deeper in both > the platform interface specification and the Lua module interface (I > remember having a discussion about this a while ago but it fade away, maybe > it's best to resume from that point, except I can't really find it right now > :) ). Could we begin to discuss a general Interrupt handling module strategy for eLua too ? Or we will stay with custom (platform-dependent) solutions for now ? > Best, > Bogdan > Best Dado > > > On Thu, Dec 11, 2008 at 4:05 AM, Mike Panetta <panetta.mike at gmail.com>wrote: > >> We also have loadable modules, at least on STM32. Take a look at >> modcommon.c in the modules dir, function luaopen_mod, and the lua_lcd.c file >> in platform/stm32/ for an example of how its used. >> >> At the end of the file I create a luaL_reg struct with a single entry that >> gets placed in a special location in memory via the linker script and the >> section attribute. luaopen_mod uses the package.preload table entry to push >> a handler to call the luaopen_lcd init function when someone does a require >> 'stm3210lcd'. >> >> So while the FLASH space is always used for the module, the RAM space >> required for the module table and etc are not loaded until someone calls >> require. >> >> Comments on this methodology are very welcome! >> >> Mike >> >> >> On Wed, Dec 10, 2008 at 6:34 PM, Pedro Bittencourt < >> pedrobittencourt87 at gmail.com> wrote: >> >>> Dado, >>> >>> Actually, we HAVE pixel resolution with the RIT display, we simply do not >>> use it (yet). >>> >>> (we can achieve that with the draw() function, where we can "draw" a >>> given matrix in the (x,y) position, a.k.a. offset, of the display) >>> >>> --Pedro Bittencourt >>> >>> >>> >>> On Wed, Dec 10, 2008 at 8:31 PM, Dado Sutter <dadosutter at gmail.com>wrote: >>> >>>> Hello Mike ! Nice to have you back ! Someone of this list arranged to >>>> lay you off at work :) :) :) >>>> The current version of Pong depends only on a PutChar (on RIT display >>>> it is called stringdraw() ) function to draw the ball and the paddle. If you >>>> have pixel resolution to position it, instead of just lines x columns, your >>>> ball will move smootly too. >>>> The driver/wrapper was implemented in a module called "disp", which >>>> is not good because it is platform-dependend. Also, the Lua code now >>>> requires (yes, with require() ) a Lua module, called LM3S, that introduces >>>> the Luminary Micro onboard goodies, like the buttons, leds and some utility >>>> functions. This module is easially adaptable for your board devices (or >>>> external components connected to it). I've been playing also with a version >>>> that implements everything in C and it would be nice if we could load it >>>> dinamically (we don't have dinamically loadable C modules, yet), only if the >>>> board is an LM3S platform. >>>> So, as you can see, I've been playing a lot with different ways to >>>> write modules, none of them to definitive yet. We must bring some more >>>> discussion to the list, to show the pros & cons of each approach. >>>> Teo and Ives has been working on a GPS module, 100% Lua (for now), >>>> with lots of good points to discuss here too. We will have to write add an >>>> INT handler for it (UART Rx), even not beeing a generic INT module for eLua >>>> yet, as well as circular queues for the input stream (just for fun, once GPS >>>> Rx doesn' t really need it :) >>>> I also need a Counter module, to read an RGB+Pan light sensor and, >>>> again, I'll probably write it in C, over the Luminary Micro low level lib >>>> for Timers and GPIO. It will not be a generic Counter module for eLua yet >>>> but it should do the work for a small project here. >>>> These many possibilities for eLua module architectures may confuse >>>> users at first but they are actually very versatile and I hope to write >>>> about it on the wiki asap. >>>> Pedro is working on a PID module, 100% Lua and it will work over ADC >>>> and DAC modules, that eLua also needs. >>>> Some other games are comming too :) as they are great for my students >>>> to learn Lua, eLua, real-time programming and, last but not least, to have >>>> fun !! :) >>>> Me and Bogdan have received an AVR32 board too, the EVK1100 and >>>> Bogdan will begin to port eLua to it soon, with some possible issues due to >>>> what Atmel has done to Newlib. Downhere, I will see what I can do for the >>>> Legos NXTs, as soon as the classes are over and I can put my hands again on >>>> a kit :) :) >>>> So welcome back and send us your ideas ! :) >>>> >>>> Best >>>> Dado >>>> >>>> >>>> On Wed, Dec 10, 2008 at 17:53, Mike Panetta <panetta.mike at gmail.com>wrote: >>>> >>>>> I had a few bumps in the road lately (got layed off at work...) but I >>>>> am back on track a bit now ready to do more STM32 work (I asked for the kit >>>>> since they were not going to use it anymore, and they gave it to me!). >>>>> >>>>> Does anyone have any suggestions or ideas for me? I was thinking about >>>>> trying to port Dados pong to it... And of course fix up the I2C module. We >>>>> should maybe start a discussion on what modules need to be done etc that are >>>>> on the list that maybe I or others could work on? >>>>> >>>>> 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 >>> >>> >> >> _______________________________________________ >> 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/20081211/7b850ad1/attachment.html |
|
|
In reply to this post by BogdanM
On Thu, Dec 11, 2008 at 11:32, Bogdan Marinescu
<bogdan.marinescu at gmail.com>wrote: > > I think you might be talking about different things. Mike it talking about > his load-on-demand mechanism (which is nice BTW), while you're probably > talking about how to set the paths? > Nope, the search path for Lua modules issue is solved and committed to trunk. The new version of Pong illustrates it's use. But I haven't check Mike's implementation yet and I thought it was for dinamically loading C modules. > > I still wait for the day when I'll have enough time to implement loadable C > modules in eLua ... :( > Time is short downhere too :( But eLua is moving faster and faster each day ! :) > Best, > Bogdan > Best Dado > > > >> >> >> >>> Mike >>> >> >> Best >> Dado >> >> >> >> >> >> >> >>> >>> >>> On Wed, Dec 10, 2008 at 6:34 PM, Pedro Bittencourt < >>> pedrobittencourt87 at gmail.com> wrote: >>> >>>> Dado, >>>> >>>> Actually, we HAVE pixel resolution with the RIT display, we simply do >>>> not use it (yet). >>>> >>>> (we can achieve that with the draw() function, where we can "draw" a >>>> given matrix in the (x,y) position, a.k.a. offset, of the display) >>>> >>>> --Pedro Bittencourt >>>> >>>> >>>> >>>> On Wed, Dec 10, 2008 at 8:31 PM, Dado Sutter <dadosutter at gmail.com>wrote: >>>> >>>>> Hello Mike ! Nice to have you back ! Someone of this list arranged >>>>> to lay you off at work :) :) :) >>>>> The current version of Pong depends only on a PutChar (on RIT >>>>> display it is called stringdraw() ) function to draw the ball and the >>>>> paddle. If you have pixel resolution to position it, instead of just lines x >>>>> columns, your ball will move smootly too. >>>>> The driver/wrapper was implemented in a module called "disp", which >>>>> is not good because it is platform-dependend. Also, the Lua code now >>>>> requires (yes, with require() ) a Lua module, called LM3S, that introduces >>>>> the Luminary Micro onboard goodies, like the buttons, leds and some utility >>>>> functions. This module is easially adaptable for your board devices (or >>>>> external components connected to it). I've been playing also with a version >>>>> that implements everything in C and it would be nice if we could load it >>>>> dinamically (we don't have dinamically loadable C modules, yet), only if the >>>>> board is an LM3S platform. >>>>> So, as you can see, I've been playing a lot with different ways to >>>>> write modules, none of them to definitive yet. We must bring some more >>>>> discussion to the list, to show the pros & cons of each approach. >>>>> Teo and Ives has been working on a GPS module, 100% Lua (for now), >>>>> with lots of good points to discuss here too. We will have to write add an >>>>> INT handler for it (UART Rx), even not beeing a generic INT module for eLua >>>>> yet, as well as circular queues for the input stream (just for fun, once GPS >>>>> Rx doesn' t really need it :) >>>>> I also need a Counter module, to read an RGB+Pan light sensor and, >>>>> again, I'll probably write it in C, over the Luminary Micro low level lib >>>>> for Timers and GPIO. It will not be a generic Counter module for eLua yet >>>>> but it should do the work for a small project here. >>>>> These many possibilities for eLua module architectures may confuse >>>>> users at first but they are actually very versatile and I hope to write >>>>> about it on the wiki asap. >>>>> Pedro is working on a PID module, 100% Lua and it will work over ADC >>>>> and DAC modules, that eLua also needs. >>>>> Some other games are comming too :) as they are great for my >>>>> students to learn Lua, eLua, real-time programming and, last but not least, >>>>> to have fun !! :) >>>>> Me and Bogdan have received an AVR32 board too, the EVK1100 and >>>>> Bogdan will begin to port eLua to it soon, with some possible issues due to >>>>> what Atmel has done to Newlib. Downhere, I will see what I can do for the >>>>> Legos NXTs, as soon as the classes are over and I can put my hands again on >>>>> a kit :) :) >>>>> So welcome back and send us your ideas ! :) >>>>> >>>>> Best >>>>> Dado >>>>> >>>>> >>>>> On Wed, Dec 10, 2008 at 17:53, Mike Panetta <panetta.mike at gmail.com>wrote: >>>>> >>>>>> I had a few bumps in the road lately (got layed off at work...) but I >>>>>> am back on track a bit now ready to do more STM32 work (I asked for the kit >>>>>> since they were not going to use it anymore, and they gave it to me!). >>>>>> >>>>>> Does anyone have any suggestions or ideas for me? I was thinking >>>>>> about trying to port Dados pong to it... And of course fix up the I2C >>>>>> module. We should maybe start a discussion on what modules need to be done >>>>>> etc that are on the list that maybe I or others could work on? >>>>>> >>>>>> 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 >>>> >>>> >>> >>> _______________________________________________ >>> 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/20081211/8843a8a8/attachment-0001.html |
|
|
In reply to this post by Dado Sutter
> This is where I am now, trying to learn the pros and cons of each module
> implementation aproach, in my > still-hard-to-find-exclusive-time-for-eLua-dev-and-studies :( I'll keep > learning from you guys !!! :) > ADC/DCA are certainly very important additions to eLua now and you have my > vote here too. > The PID module will be a natural consequence and will finally be tested. > But some of our platforms do not have DACs, so we should provide a way to > map them thru SPI too. How would this be handled in this module approach ? > This is a very good question, and I'm thinking about it. I imaigned a few ways, but none of them seem to be good enough, so I'll keep on thinking. > Could we begin to discuss a general Interrupt handling module strategy for > eLua too ? Or we will stay with custom (platform-dependent) solutions for > now ? > We should begin to discuss an interrupt handling strategy, no doubt about it. The simplest and less intrusive way is to use standard Lua hooks, most like lua.c handles "ctrl+c". We might need to modify the code a bit, but nothing major. Should be fairly simple actually, I just didn't have a chance to try it yet. Best, Bogdan > > >> >> >> On Thu, Dec 11, 2008 at 4:05 AM, Mike Panetta <panetta.mike at gmail.com>wrote: >> >>> We also have loadable modules, at least on STM32. Take a look at >>> modcommon.c in the modules dir, function luaopen_mod, and the lua_lcd.c file >>> in platform/stm32/ for an example of how its used. >>> >>> At the end of the file I create a luaL_reg struct with a single entry >>> that gets placed in a special location in memory via the linker script and >>> the section attribute. luaopen_mod uses the package.preload table entry to >>> push a handler to call the luaopen_lcd init function when someone does a >>> require 'stm3210lcd'. >>> >>> So while the FLASH space is always used for the module, the RAM space >>> required for the module table and etc are not loaded until someone calls >>> require. >>> >>> Comments on this methodology are very welcome! >>> >>> Mike >>> >>> >>> On Wed, Dec 10, 2008 at 6:34 PM, Pedro Bittencourt < >>> pedrobittencourt87 at gmail.com> wrote: >>> >>>> Dado, >>>> >>>> Actually, we HAVE pixel resolution with the RIT display, we simply do >>>> not use it (yet). >>>> >>>> (we can achieve that with the draw() function, where we can "draw" a >>>> given matrix in the (x,y) position, a.k.a. offset, of the display) >>>> >>>> --Pedro Bittencourt >>>> >>>> >>>> >>>> On Wed, Dec 10, 2008 at 8:31 PM, Dado Sutter <dadosutter at gmail.com>wrote: >>>> >>>>> Hello Mike ! Nice to have you back ! Someone of this list arranged >>>>> to lay you off at work :) :) :) >>>>> The current version of Pong depends only on a PutChar (on RIT >>>>> display it is called stringdraw() ) function to draw the ball and the >>>>> paddle. If you have pixel resolution to position it, instead of just lines x >>>>> columns, your ball will move smootly too. >>>>> The driver/wrapper was implemented in a module called "disp", which >>>>> is not good because it is platform-dependend. Also, the Lua code now >>>>> requires (yes, with require() ) a Lua module, called LM3S, that introduces >>>>> the Luminary Micro onboard goodies, like the buttons, leds and some utility >>>>> functions. This module is easially adaptable for your board devices (or >>>>> external components connected to it). I've been playing also with a version >>>>> that implements everything in C and it would be nice if we could load it >>>>> dinamically (we don't have dinamically loadable C modules, yet), only if the >>>>> board is an LM3S platform. >>>>> So, as you can see, I've been playing a lot with different ways to >>>>> write modules, none of them to definitive yet. We must bring some more >>>>> discussion to the list, to show the pros & cons of each approach. >>>>> Teo and Ives has been working on a GPS module, 100% Lua (for now), >>>>> with lots of good points to discuss here too. We will have to write add an >>>>> INT handler for it (UART Rx), even not beeing a generic INT module for eLua >>>>> yet, as well as circular queues for the input stream (just for fun, once GPS >>>>> Rx doesn' t really need it :) >>>>> I also need a Counter module, to read an RGB+Pan light sensor and, >>>>> again, I'll probably write it in C, over the Luminary Micro low level lib >>>>> for Timers and GPIO. It will not be a generic Counter module for eLua yet >>>>> but it should do the work for a small project here. >>>>> These many possibilities for eLua module architectures may confuse >>>>> users at first but they are actually very versatile and I hope to write >>>>> about it on the wiki asap. >>>>> Pedro is working on a PID module, 100% Lua and it will work over ADC >>>>> and DAC modules, that eLua also needs. >>>>> Some other games are comming too :) as they are great for my >>>>> students to learn Lua, eLua, real-time programming and, last but not least, >>>>> to have fun !! :) >>>>> Me and Bogdan have received an AVR32 board too, the EVK1100 and >>>>> Bogdan will begin to port eLua to it soon, with some possible issues due to >>>>> what Atmel has done to Newlib. Downhere, I will see what I can do for the >>>>> Legos NXTs, as soon as the classes are over and I can put my hands again on >>>>> a kit :) :) >>>>> So welcome back and send us your ideas ! :) >>>>> >>>>> Best >>>>> Dado >>>>> >>>>> >>>>> On Wed, Dec 10, 2008 at 17:53, Mike Panetta <panetta.mike at gmail.com>wrote: >>>>> >>>>>> I had a few bumps in the road lately (got layed off at work...) but I >>>>>> am back on track a bit now ready to do more STM32 work (I asked for the kit >>>>>> since they were not going to use it anymore, and they gave it to me!). >>>>>> >>>>>> Does anyone have any suggestions or ideas for me? I was thinking >>>>>> about trying to port Dados pong to it... And of course fix up the I2C >>>>>> module. We should maybe start a discussion on what modules need to be done >>>>>> etc that are on the list that maybe I or others could work on? >>>>>> >>>>>> 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 >>>> >>>> >>> >>> _______________________________________________ >>> 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/20081211/5074b004/attachment.html |
|
|
On Thu, Dec 11, 2008 at 11:41, Bogdan Marinescu
<bogdan.marinescu at gmail.com>wrote: > > > This is a very good question, and I'm thinking about it. I imaigned a few > ways, but none of them seem to be good enough, so I'll keep on thinking. > Would you mind to bring your considerations to the list and share your thoughts ? I'm sure it would be very helpfull for us all ! :) > We should begin to discuss an interrupt handling strategy, no doubt about > it. The simplest and less intrusive way is to use standard Lua hooks, > Yeap, my first guess too but I couldn't find a way to use it yet, without modifying some of Lua's internals. (and I don't want to bother Roberto with this .......... yet :) > most like lua.c handles "ctrl+c". We might need to modify the code a bit, > but nothing major. Should be fairly simple actually, I just didn't have a > chance to try it yet. > Is there a thing different from "nothing major" for you nowadays ? :-o :) > Best, > Bogdan > Best Dado > > > >> >> >>> >>> >>> On Thu, Dec 11, 2008 at 4:05 AM, Mike Panetta <panetta.mike at gmail.com>wrote: >>> >>>> We also have loadable modules, at least on STM32. Take a look at >>>> modcommon.c in the modules dir, function luaopen_mod, and the lua_lcd.c file >>>> in platform/stm32/ for an example of how its used. >>>> >>>> At the end of the file I create a luaL_reg struct with a single entry >>>> that gets placed in a special location in memory via the linker script and >>>> the section attribute. luaopen_mod uses the package.preload table entry to >>>> push a handler to call the luaopen_lcd init function when someone does a >>>> require 'stm3210lcd'. >>>> >>>> So while the FLASH space is always used for the module, the RAM space >>>> required for the module table and etc are not loaded until someone calls >>>> require. >>>> >>>> Comments on this methodology are very welcome! >>>> >>>> Mike >>>> >>>> >>>> On Wed, Dec 10, 2008 at 6:34 PM, Pedro Bittencourt < >>>> pedrobittencourt87 at gmail.com> wrote: >>>> >>>>> Dado, >>>>> >>>>> Actually, we HAVE pixel resolution with the RIT display, we simply do >>>>> not use it (yet). >>>>> >>>>> (we can achieve that with the draw() function, where we can "draw" a >>>>> given matrix in the (x,y) position, a.k.a. offset, of the display) >>>>> >>>>> --Pedro Bittencourt >>>>> >>>>> >>>>> >>>>> On Wed, Dec 10, 2008 at 8:31 PM, Dado Sutter <dadosutter at gmail.com>wrote: >>>>> >>>>>> Hello Mike ! Nice to have you back ! Someone of this list arranged >>>>>> to lay you off at work :) :) :) >>>>>> The current version of Pong depends only on a PutChar (on RIT >>>>>> display it is called stringdraw() ) function to draw the ball and the >>>>>> paddle. If you have pixel resolution to position it, instead of just lines x >>>>>> columns, your ball will move smootly too. >>>>>> The driver/wrapper was implemented in a module called "disp", >>>>>> which is not good because it is platform-dependend. Also, the Lua code now >>>>>> requires (yes, with require() ) a Lua module, called LM3S, that introduces >>>>>> the Luminary Micro onboard goodies, like the buttons, leds and some utility >>>>>> functions. This module is easially adaptable for your board devices (or >>>>>> external components connected to it). I've been playing also with a version >>>>>> that implements everything in C and it would be nice if we could load it >>>>>> dinamically (we don't have dinamically loadable C modules, yet), only if the >>>>>> board is an LM3S platform. >>>>>> So, as you can see, I've been playing a lot with different ways to >>>>>> write modules, none of them to definitive yet. We must bring some more >>>>>> discussion to the list, to show the pros & cons of each approach. >>>>>> Teo and Ives has been working on a GPS module, 100% Lua (for now), >>>>>> with lots of good points to discuss here too. We will have to write add an >>>>>> INT handler for it (UART Rx), even not beeing a generic INT module for eLua >>>>>> yet, as well as circular queues for the input stream (just for fun, once GPS >>>>>> Rx doesn' t really need it :) >>>>>> I also need a Counter module, to read an RGB+Pan light sensor and, >>>>>> again, I'll probably write it in C, over the Luminary Micro low level lib >>>>>> for Timers and GPIO. It will not be a generic Counter module for eLua yet >>>>>> but it should do the work for a small project here. >>>>>> These many possibilities for eLua module architectures may confuse >>>>>> users at first but they are actually very versatile and I hope to write >>>>>> about it on the wiki asap. >>>>>> Pedro is working on a PID module, 100% Lua and it will work over >>>>>> ADC and DAC modules, that eLua also needs. >>>>>> Some other games are comming too :) as they are great for my >>>>>> students to learn Lua, eLua, real-time programming and, last but not least, >>>>>> to have fun !! :) >>>>>> Me and Bogdan have received an AVR32 board too, the EVK1100 and >>>>>> Bogdan will begin to port eLua to it soon, with some possible issues due to >>>>>> what Atmel has done to Newlib. Downhere, I will see what I can do for the >>>>>> Legos NXTs, as soon as the classes are over and I can put my hands again on >>>>>> a kit :) :) >>>>>> So welcome back and send us your ideas ! :) >>>>>> >>>>>> Best >>>>>> Dado >>>>>> >>>>>> >>>>>> On Wed, Dec 10, 2008 at 17:53, Mike Panetta <panetta.mike at gmail.com>wrote: >>>>>> >>>>>>> I had a few bumps in the road lately (got layed off at work...) but I >>>>>>> am back on track a bit now ready to do more STM32 work (I asked for the kit >>>>>>> since they were not going to use it anymore, and they gave it to me!). >>>>>>> >>>>>>> Does anyone have any suggestions or ideas for me? I was thinking >>>>>>> about trying to port Dados pong to it... And of course fix up the I2C >>>>>>> module. We should maybe start a discussion on what modules need to be done >>>>>>> etc that are on the list that maybe I or others could work on? >>>>>>> >>>>>>> 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 >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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/20081211/45af7652/attachment-0001.html |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |