Latest eLua developments
Locked
|
I'm interested in getting ADC working on LM3S to try a few things out. ?Since I see that you're intending to work on buffering, perhaps I'll wait for your changes?
Are there any areas where work might be beneficial, but might not conflict with the changes you're planning to make? ?I'd like to trial using eLua for controlling some devices. ?For this, I'll need to be able to use the following: - reading encoders - reading ADC - SPI output to control some digital potentiometers - (wish list) having an RPC mechanism, or an easy way to ship data/make procedure calls between microcontroller and a desktop. The rest is pretty much project specific code for doing some PID etc.. ?One could argue the encoder reading is userland as well, but I believe the LM3S6965 has some sort of hardware facility. ?I'd be willing to work on things related to these in order to try out this functionality. ?Any thoughts? ----- Original Message ----- From: "Bogdan Marinescu" <bogdan.marinescu at gmail.com> To: "eLua development list" <elua-dev at lists.berlios.de> Sent: Wednesday, January 7, 2009 2:31:30 PM GMT -06:00 US/Canada Central Subject: [eLua-dev] Latest eLua developments First of all, I apologise for the huge svn commit message. Hope I'll keep them shorter in the future. Common code from all backends was factored out in src/common.c, and each backend's platform_conf.h/platform.c fils were updated for this. Take a look at any of them, it's quite easy to understand what happened there. There's a new feature available for all platforms: virtual timers. Currently implemented for LM3S, AVR32 and AT91SAM, they're a very good way to get long delays (especially on platforms with 16-bit timers) if accuracy is not an issue. It's easy to use them: declare VTMR_NUM_TIMERS and VTMR_FREQ_HZ in platform_conf.h, then call cmn_virtual_timer_cb() from a timer interrupts that happens at a frequency of VTMR_FREQ_HZ. You use these timers just as the regular timers, but their IDs are not 0, 1, ..., but rather tmr.VIRT0, tmr.VIRT1... Tested on: everything but LPC2888 (can't burn it right now, but there's no reason for it to fail) and STM32 ( Mike , please test the new image on your board, I can't do that). To come (in order of priority, in an ideal world): - more AVR32 (PWM, external memory) - Lua Tiny Ram patch (hopefully you're gonna love this one :) ) - fix eLua stack overflow(s) (yes, we have those) - new XMODEM implementation (the current one is GPL, thus it prevents us from changing the license to BSD). - generic buffering system for "char" devices (UART, SPI, I2C, ADC...) ... and many others. If only I had the time ... Best, Bogdan _______________________________________________ Elua-dev mailing list Elua-dev at lists.berlios.de https://lists.berlios.de/mailman/listinfo/elua-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090107/6954b25b/attachment.html |
|
|
On Thu, Jan 8, 2009 at 12:02 AM, James Snyder <jbsnyder at fanplastic.org>wrote:
> I'm interested in getting ADC working on LM3S to try a few things out. > Since I see that you're intending to work on buffering, perhaps I'll wait > for your changes? > No, you shouldn't wait for my changes, as I have no idea when I'll be able to implement them. What we should do, however, is come up with a suitable platform interface for the ADC subsystem (just like we have for PIO, UART, timers and so on). This is something I've been delaying for a bit too long, so I solemnly promise to come up with a proposition by tomorrow EOD, then we'll refine it and then you'll be able to implement your drivers. The buffering part shouldn't interfere with your work at all; on the contrary, it should help it (especially if you do ADC via interrupts, although at this point you probably don't have that many reasons to use interrupts). > Are there any areas where work might be beneficial, but might not conflict > with the changes you're planning to make? I'd like to trial using eLua for > controlling some devices. For this, I'll need to be able to use the > following: > > - (wish list) having an RPC mechanism, or an easy way to ship data/make > procedure calls between microcontroller and a desktop. > Heh, that would be cool indeed :) But I don't have anything really ready in that area, just some fuzzy ideas. > The rest is pretty much project specific code for doing some PID etc.. One > could argue the encoder reading is userland as well, but I believe the > LM3S6965 has some sort of hardware facility. I'd be willing to work on > things related to these in order to try out this functionality. Any > thoughts? > We need to put platform-specific functionality in platform-specific modules. More on that tomorrow (once again). Best, Bogdan > ----- Original Message ----- > From: "Bogdan Marinescu" <bogdan.marinescu at gmail.com> > To: "eLua development list" <elua-dev at lists.berlios.de> > Sent: Wednesday, January 7, 2009 2:31:30 PM GMT -06:00 US/Canada Central > Subject: [eLua-dev] Latest eLua developments > > First of all, I apologise for the huge svn commit message. Hope I'll keep > them shorter in the future. > > Common code from all backends was factored out in src/common.c, and each > backend's platform_conf.h/platform.c fils were updated for this. Take a look > at any of them, it's quite easy to understand what happened there. > > There's a new feature available for all platforms: virtual timers. > Currently implemented for LM3S, AVR32 and AT91SAM, they're a very good way > to get long delays (especially on platforms with 16-bit timers) if accuracy > is not an issue. It's easy to use them: declare VTMR_NUM_TIMERS and > VTMR_FREQ_HZ in platform_conf.h, then call cmn_virtual_timer_cb() from a > timer interrupts that happens at a frequency of VTMR_FREQ_HZ. You use these > timers just as the regular timers, but their IDs are not 0, 1, ..., but > rather tmr.VIRT0, tmr.VIRT1... > > Tested on: everything but LPC2888 (can't burn it right now, but there's no > reason for it to fail) and STM32 (*Mike*, please test the new image on > your board, I can't do that). > > To come (in order of priority, in an ideal world): > > - more AVR32 (PWM, external memory) > - Lua Tiny Ram patch (hopefully you're gonna love this one :) ) > - fix eLua stack overflow(s) (yes, we have those) > - new XMODEM implementation (the current one is GPL, thus it prevents us > from changing the license to BSD). > - generic buffering system for "char" devices (UART, SPI, I2C, ADC...) > > ... and many others. If only I had the time ... > > Best, > Bogdan > > > > > _______________________________________________ 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/20090108/8edcb1c1/attachment.html |
|
|
Sounds good. I was going to base whatever code I was going to write
on the style used for other modules. I'm considering an opportunity to both learn the hardware and software, as well as to build something functional. While the RPC stuff is a bit more out there, and I might not bother soon. I'd be interested in some discussion there. There are projects for doing this sort of thing on a microcontroller like Firmata, which uses a MIDI-like messaging scheme: http://firmata.org/wiki/Protocol Higher level RPC mechanisms might be nice for readability, but they probably are expensive in terms of encoding and decoding. There are a billion RPC systems out there, I would definitely avoid XML, but perhaps something like JSON-RPC might not be terrible if this route were approached: http://en.wikipedia.org/wiki/JSON-RPC That said, you'd have to encode everything in text, which means large numbers could require a huge number of bytes to transfer. As far as ideals one might want out of such a protocol (just brainstorming here): - simple, hopefully easily read by both machine and user/programmer - low ram and cpu requirements - efficient? - should everything be binary? - minimal code needed for encoding and decoding - easily accommodates standard microcontroller functionality (accessing peripherals), but is extensible - works over various communication methods (serial, tcp/ip, etc..) - in band or out of band bulk data transfer (file uploads, logged data downloads, etc..) - something here maybe for sending byte code to be executed? - maybe an auth mechanism to prevent loading arbitrary code over tcp/ ip? *shrug* On Jan 7, 2009, at 4:15 PM, Bogdan Marinescu wrote: > On Thu, Jan 8, 2009 at 12:02 AM, James Snyder > <jbsnyder at fanplastic.org> wrote: > I'm interested in getting ADC working on LM3S to try a few things > out. Since I see that you're intending to work on buffering, > perhaps I'll wait for your changes? > > No, you shouldn't wait for my changes, as I have no idea when I'll > be able to implement them. What we should do, however, is come up > with a suitable platform interface for the ADC subsystem (just like > we have for PIO, UART, timers and so on). This is something I've > been delaying for a bit too long, so I solemnly promise to come up > with a proposition by tomorrow EOD, then we'll refine it and then > you'll be able to implement your drivers. The buffering part > shouldn't interfere with your work at all; on the contrary, it > should help it (especially if you do ADC via interrupts, although at > this point you probably don't have that many reasons to use > interrupts). > > Are there any areas where work might be beneficial, but might not > conflict with the changes you're planning to make? I'd like to > trial using eLua for controlling some devices. For this, I'll need > to be able to use the following: > > - (wish list) having an RPC mechanism, or an easy way to ship data/ > make procedure calls between microcontroller and a desktop. > > Heh, that would be cool indeed :) But I don't have anything really > ready in that area, just some fuzzy ideas. > > The rest is pretty much project specific code for doing some PID > etc.. One could argue the encoder reading is userland as well, but > I believe the LM3S6965 has some sort of hardware facility. I'd be > willing to work on things related to these in order to try out this > functionality. Any thoughts? > > We need to put platform-specific functionality in platform-specific > modules. More on that tomorrow (once again). > > Best, > Bogdan > > ----- Original Message ----- > From: "Bogdan Marinescu" <bogdan.marinescu at gmail.com> > To: "eLua development list" <elua-dev at lists.berlios.de> > Sent: Wednesday, January 7, 2009 2:31:30 PM GMT -06:00 US/Canada > Central > Subject: [eLua-dev] Latest eLua developments > > First of all, I apologise for the huge svn commit message. Hope I'll > keep them shorter in the future. > > Common code from all backends was factored out in src/common.c, and > each backend's platform_conf.h/platform.c fils were updated for > this. Take a look at any of them, it's quite easy to understand what > happened there. > > There's a new feature available for all platforms: virtual timers. > Currently implemented for LM3S, AVR32 and AT91SAM, they're a very > good way to get long delays (especially on platforms with 16-bit > timers) if accuracy is not an issue. It's easy to use them: declare > VTMR_NUM_TIMERS and VTMR_FREQ_HZ in platform_conf.h, then call > cmn_virtual_timer_cb() from a timer interrupts that happens at a > frequency of VTMR_FREQ_HZ. You use these timers just as the regular > timers, but their IDs are not 0, 1, ..., but rather tmr.VIRT0, > tmr.VIRT1... > > Tested on: everything but LPC2888 (can't burn it right now, but > there's no reason for it to fail) and STM32 (Mike, please test the > new image on your board, I can't do that). > > To come (in order of priority, in an ideal world): > > - more AVR32 (PWM, external memory) > - Lua Tiny Ram patch (hopefully you're gonna love this one :) ) > - fix eLua stack overflow(s) (yes, we have those) > - new XMODEM implementation (the current one is GPL, thus it > prevents us from changing the license to BSD). > - generic buffering system for "char" devices (UART, SPI, I2C, ADC...) > > ... and many others. If only I had the time ... > > Best, > Bogdan > > > > > _______________________________________________ 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 -- James Snyder Biomedical Engineering Northwestern University jbsnyder at fanplastic.org http://fanplastic.org/key.txt ph: (847) 644-2322 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090107/49f21b2a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090107/49f21b2a/attachment-0001.pgp |
|
|
This one should be a good starting point:
http://q12.org/lua/index.html It's small, yet very functional. It doesn't handle recursive tables well, but lots of people (me included) can live with that. Other thoughts: - the whole thing should be completely independent of the physical transport. Because of this, the packaging of the actual RPC data would vary greatly from a transport to the other (it doesn't make much sense to add error checking or sequence numbers for TCP/IP, but it would make sense for a serial connection). But this concerns just the transport layer, not the RPC subsystem itself. - "easily read by the programmer" generally means some sort of markup language, which is everything but efficient. I generally go "binary all the way" and just write some simple protocol analyzers if really needed. XML and friends are good for desktops, but extremely messy on embedded because of the relatively high memory requirements. XML tends to be highly overused, which is something I really want to avoid in eLua, given its embeddedness (yes, I know that's not actually a word :) ). - auth mechanism: good idea, didn't think about that. Some embedded-targeted encryption algoritms (like XXTEA) could probably be used here. - bytecode execution should be easy with Lua as long as both systems have the same data types/endianess, and moderately difficult if not so. The main problem here is serializing/deserializing Lua types, and the Lua RPC package in the link above does just that, and it doesn't look too difficult. Best, Bogdan On Thu, Jan 8, 2009 at 1:42 AM, James Snyder <jbsnyder at fanplastic.org>wrote: > Sounds good. I was going to base whatever code I was going to write on the > style used for other modules. I'm considering an opportunity to both learn > the hardware and software, as well as to build something functional. > While the RPC stuff is a bit more out there, and I might not bother soon. > I'd be interested in some discussion there. There are projects for doing > this sort of thing on a microcontroller like Firmata, which uses a MIDI-like > messaging scheme: > http://firmata.org/wiki/Protocol > > Higher level RPC mechanisms might be nice for readability, but they > probably are expensive in terms of encoding and decoding. There are a > billion RPC systems out there, I would definitely avoid XML, but perhaps > something like JSON-RPC might not be terrible if this route were > approached: http://en.wikipedia.org/wiki/JSON-RPC > That said, you'd have to encode everything in text, which means large > numbers could require a huge number of bytes to transfer. > > As far as ideals one might want out of such a protocol (just brainstorming > here): > - simple, hopefully easily read by both machine and user/programmer > - low ram and cpu requirements > - efficient? > - should everything be binary? > - minimal code needed for encoding and decoding > - easily accommodates standard microcontroller functionality (accessing > peripherals), but is extensible > - works over various communication methods (serial, tcp/ip, etc..) > - in band or out of band bulk data transfer (file uploads, logged data > downloads, etc..) > - something here maybe for sending byte code to be executed? > - maybe an auth mechanism to prevent loading arbitrary code over tcp/ip? > > *shrug* > > > > On Jan 7, 2009, at 4:15 PM, Bogdan Marinescu wrote: > > On Thu, Jan 8, 2009 at 12:02 AM, James Snyder <jbsnyder at fanplastic.org>wrote: > >> I'm interested in getting ADC working on LM3S to try a few things out. >> Since I see that you're intending to work on buffering, perhaps I'll wait >> for your changes? >> > > No, you shouldn't wait for my changes, as I have no idea when I'll be able > to implement them. What we should do, however, is come up with a suitable > platform interface for the ADC subsystem (just like we have for PIO, UART, > timers and so on). This is something I've been delaying for a bit too long, > so I solemnly promise to come up with a proposition by tomorrow EOD, then > we'll refine it and then you'll be able to implement your drivers. The > buffering part shouldn't interfere with your work at all; on the contrary, > it should help it (especially if you do ADC via interrupts, although at this > point you probably don't have that many reasons to use interrupts). > > >> Are there any areas where work might be beneficial, but might not conflict >> with the changes you're planning to make? I'd like to trial using eLua for >> controlling some devices. For this, I'll need to be able to use the >> following: >> >> - (wish list) having an RPC mechanism, or an easy way to ship data/make >> procedure calls between microcontroller and a desktop. >> > > Heh, that would be cool indeed :) But I don't have anything really ready in > that area, just some fuzzy ideas. > > >> The rest is pretty much project specific code for doing some PID etc.. >> One could argue the encoder reading is userland as well, but I believe the >> LM3S6965 has some sort of hardware facility. I'd be willing to work on >> things related to these in order to try out this functionality. Any >> thoughts? >> > > We need to put platform-specific functionality in platform-specific > modules. More on that tomorrow (once again). > > Best, > Bogdan > > >> ----- Original Message ----- >> From: "Bogdan Marinescu" <bogdan.marinescu at gmail.com> >> To: "eLua development list" <elua-dev at lists.berlios.de> >> Sent: Wednesday, January 7, 2009 2:31:30 PM GMT -06:00 US/Canada Central >> Subject: [eLua-dev] Latest eLua developments >> >> First of all, I apologise for the huge svn commit message. Hope I'll keep >> them shorter in the future. >> >> Common code from all backends was factored out in src/common.c, and each >> backend's platform_conf.h/platform.c fils were updated for this. Take a look >> at any of them, it's quite easy to understand what happened there. >> >> There's a new feature available for all platforms: virtual timers. >> Currently implemented for LM3S, AVR32 and AT91SAM, they're a very good way >> to get long delays (especially on platforms with 16-bit timers) if accuracy >> is not an issue. It's easy to use them: declare VTMR_NUM_TIMERS and >> VTMR_FREQ_HZ in platform_conf.h, then call cmn_virtual_timer_cb() from a >> timer interrupts that happens at a frequency of VTMR_FREQ_HZ. You use these >> timers just as the regular timers, but their IDs are not 0, 1, ..., but >> rather tmr.VIRT0, tmr.VIRT1... >> >> Tested on: everything but LPC2888 (can't burn it right now, but there's no >> reason for it to fail) and STM32 (*Mike*, please test the new image on >> your board, I can't do that). >> >> To come (in order of priority, in an ideal world): >> >> - more AVR32 (PWM, external memory) >> - Lua Tiny Ram patch (hopefully you're gonna love this one :) ) >> - fix eLua stack overflow(s) (yes, we have those) >> - new XMODEM implementation (the current one is GPL, thus it prevents us >> from changing the license to BSD). >> - generic buffering system for "char" devices (UART, SPI, I2C, ADC...) >> >> ... and many others. If only I had the time ... >> >> Best, >> Bogdan >> >> >> >> >> _______________________________________________ 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 > > > -- > James Snyder > Biomedical Engineering > Northwestern University > jbsnyder at fanplastic.org > http://fanplastic.org/key.txt > ph: (847) 644-2322 > > > _______________________________________________ > 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/20090108/ffaa913e/attachment.html |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |