Re: eLua-dev Digest, Vol 35, Issue 41
Locked
|
On Fri, Jun 17, 2011 at 12:00 PM, <[hidden email]> wrote: Send eLua-dev mailing list submissions to Hello,
Sure, I too was able to confirm this with stub code. What I can't figure out is why it never appears in Certainly, there is a very good possibility of the problem emanating from the delta delay. I have also obtained "MY ERROR: header exchange failed" in addition to the "no data received when attempting to read" error. I have also tried building on Gnu/Linux. The response is identical. The ./luarpc instance, while executing rpc.connect("/dev/ttyUSB0") takes me to an infinite waiting state. (Despite its posix compliance, which was tested successfully on mac ?) Have you encountered this before ?
Awaiting your response.
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
 
|
Dado Sutter |
Re: eLua-dev Digest, Vol 35, Issue 41
|
|
Hello,
Thiago, can you add to this thread with the results of your work on testing/fixing/enhancing rpc for the ESC event demos ? Best Dado On Fri, Jun 17, 2011 at 11:40, Raman Gopalan <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Yeah, if anyone has any notes on LM3S + LuaRPC with recent sources
that would be helpful. I'll do some further testing today including doing some double-checking on Linux. As noted before, I can see the MCU _reply_ with a similar looking LRPC header to what it was sent, I believe around 70 uS after it receives it. Is there a mandatory minimum delay between ending rx and beginning tx with these chips? I can't seem to find an indication of whether they should be running in full or half duplex, though I would figure half is sufficient in this case. I don't understand why the data is getting lost and I'm not sure if there's an easy way to instrument the Windows drivers to look at exactly what the FTDI chip+drivers think of this transmission (i.e.: is it ignored, is the something wrong with timing, etc..). At this point after fiddling with the Windows implementation a bit, I'm a little lost. If I can get it to do the same thing on Linux, that might help narrow things down. I might also start trying to add some artificial time delays between data transmissions, but that seems like a kluge working around something broken if that works as a solution. On Fri, Jun 17, 2011 at 10:50 AM, Dado Sutter <[hidden email]> wrote: > Hello, > Thiago, can you add to this thread with the results of your work on > testing/fixing/enhancing rpc for the ESC event demos ? > > Best > Dado > > > > > On Fri, Jun 17, 2011 at 11:40, Raman Gopalan <[hidden email]> wrote: >> >> >> On Fri, Jun 17, 2011 at 12:00 PM, <[hidden email]> >> wrote: >>> >>> Send eLua-dev mailing list submissions to >>> [hidden email] >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> or, via email, send a message with subject or body 'help' to >>> [hidden email] >>> >>> You can reach the person managing the list at >>> [hidden email] >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of eLua-dev digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: eLua-dev Digest, Vol 35, Issue 34 (James Snyder) >>> 2. Re: Redefining the I2C Lua interface (was: I2C for LM3S >>> devices) (Martin Guy) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Thu, 16 Jun 2011 16:06:57 -0500 >>> From: James Snyder <[hidden email]> >>> To: "eLua Users and Development List (www.eluaproject.net)" >>> <[hidden email]> >>> Subject: Re: [eLua-dev] eLua-dev Digest, Vol 35, Issue 34 >>> Message-ID: <[hidden email]> >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> On Wed, Jun 15, 2011 at 5:32 AM, Raman Gopalan <[hidden email]> >>> wrote: >>> > Thanks for your reply. Now that I know for sure that the bug has >>> > nothing >>> > to do with my platform setup, I will try to build up test cases to >>> > corner >>> > the >>> > bug. I will keep the posix vs win serial implementation in mind. If I >>> > stumble >>> > upon something interesting, I will certainly keep the community posted. >>> > >>> > Awaiting your update. >>> > >>> > Raman >> >> Hello, >>> >>> What's odd here is that I did hook up a scope to both Rx and Tx lines >>> and at least at the MCU it appears to be sending back the initial >>> handshake reply. >> >> Sure, I too was able to confirm this with stub code. >> >>> >>> What I can't figure out is why it never appears in >>> the buffer in Windows. There's plenty of buffer space allocated >>> beforehand. One difference I notice in timing between POSIX and >>> Windows is that it seems to send the connection request byte and >>> header as one "packet" whereas with windows there is a couple >>> millisecond delay between the sending of the connection request byte >>> and the 8 header bytes. Additionally, there appears to be a longer >>> delay in responding to the single 9 byte POSIX send vs the separated >>> Windows 1 + 2ms + 8 byte send. I haven't looked at timing on an STM32 >>> platform yet to see how it differs if at all but I wonder if this >>> might be related to timing? >> >> Certainly, there is a very good possibility of the problem emanating from >> the >> delta delay. I have also obtained "MY ERROR: header exchange failed" in >> addition to the "no data received when attempting to read" error. >> >> I have also tried building on Gnu/Linux. The response is identical. The >> ./luarpc >> instance, while executing rpc.connect("/dev/ttyUSB0") takes me to an >> infinite >> waiting state. (Despite its posix compliance, which was tested >> successfully on mac ?) >> >> Have you encountered this before ? >>> >>> It has definitely worked in the past on this platform. I may start >>> trying to find the last working version and then use git bisect to >>> find what change caused the current problem. >> >> Awaiting your response. >>> >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Fri, 17 Jun 2011 02:40:32 +0200 >>> From: Martin Guy <[hidden email]> >>> To: Bogdan Marinescu <[hidden email]> >>> Cc: "eLua Users and Development List \(www.eluaproject.net\)" >>> <[hidden email]> >>> Subject: Re: [eLua-dev] Redefining the I2C Lua interface (was: I2C for >>> LM3S devices) >>> Message-ID: <BANLkTi=[hidden email]> >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> On 16 June 2011 19:20, Bogdan Marinescu <[hidden email]> >>> wrote: >>> > In one of my applications I actually read the >>> > whole content of a serial EEPROM (32KB (not Kb)) into a file in the >>> > filesystem. Reading the whole data and writing it in one step is simply >>> > not >>> > good enough because I'd need too much memory for the operation, so >>> > instead >>> > I'm reading it in chunks of 256 bytes. >>> >>> Thanks. Yes, you would need to do the reading of the blocks at Lua >>> level as separate I2C transactions as you describe. >>> >>> > I just feel that the I2C >>> > interface introduces limitations that shouldn't be there ... >>> >>> The advantage of making the eLua APIs match the I2C protocol >>> definition is that you can be sure to implement the API on any >>> hardware, can be sure to drive any device, and be sure that users can >>> only talk valid I2C language, however they call it. >>> It's also a way of teaching learners exactly what valid I2C protocol >>> means. >>> >>> I'm working on the assumption that modelling the eLua APIs on the I2C >>> specification is the best way to guarantee that we will be able to >>> drive all master interfaces and talk to all slave devices, including >>> those we do not know, or that have not been produced yet. >>> >>> On one hand, the spec does say that I2C does not impose a limit on the >>> amount of data present in one transfer. >>> On the other, ir doesn't say that it's mandatory for a master to be >>> able to handle infinite length transfers. >>> >>> > Absolutely. I'm not using EEPROM as an example because I want to model >>> > our >>> > I2C platform interface after it, it's just an use case I'm quite >>> > familiar >>> > with in practice and I can use it to detect limitations in our >>> > interface. So >>> > far it's doing a pretty good job :) >>> >>> I confess that starting a 32-megabyte transfer in one function call, >>> then reading the data of one packet in 256-bytes chunks with separate >>> function calls is not a usage scenario that I had thought of. >>> >>> Here's another nightmare for you. I just found a device that eats >>> infinite-length data packets for lunch. >>> It's an 8-bit ADC/DAC device >>> http://www.nxp.com/documents/data_sheet/PCF8591.pdf >>> that can perform both analog-to-digital or digital-to-analog >>> conversion in the same time it takes to transmit or receive one byte >>> and it can send you an infinite amount of data, or you can send *it* >>> an infinite amount of data in one I2C read or write packet, assuming >>> that you can consume or generate it fast enough: one sample every >>> 90us, i.e. every nine 100kHz bus clocks == 11,111 samples per second. >>> To do audio, you'd have to be able to make a Lua-to-C-to-Lua >>> transition in 90 us so as not have glitches in the output or miss >>> samples on input. At 100 MHz CPU clock and 4 cycles per instruction, >>> that's something like 250 instructions, which sounds possible in >>> assembler. Could you make a round trip from the Lua interpreter to C >>> and back in that sort of time and do something useful with the data? >>> Would you want to? :) >>> >>> >> My own problem with i2c.probe(id, address) is that AVR32 cannot send >>> >> empty data packets. >>> >>> > This is getting ridiculous. At this point I wish they kept the I2C >>> > engine >>> > from their 8 bit AVR MCU line. Besides not being able to to DMA >>> > transfers >>> > (although I'm not sure if this is still true for XMEGAs) it was much >>> > better >>> > than what they offer in the AVR32 IMO. >>> >>> It gets worse. A different ADC instead >>> http://www.ti.com/lit/gpn/ads7823 >>> when you just send it a single zero data byte, that means "power up >>> and convert 4 samples from analog to digital". I suppose, as it's a >>> slave device, that one case is harmess, but what might other devices >>> do? Anyway, there's nothing I can do about that. >>> >>> The only difference the AVR32 limitation makes to us is that it >>> suggests adding i2c_master_probe( id, slave_address ) to the C >>> platform interface, so that AVR32 can do it's brain-damaged thing >>> sending a 0 byte, while allowing other platform can do something more >>> healthy. If that were implemented at a higher level as send(id, >>> address, NULL, 0, true), the AVR32 would have to either fail that >>> always because it can't do it (making probe() unusable) or send a >>> single zero data byte when the user asked for none. I'm not sure which >>> is worse. >>> >>> I guess that's why they call it TWI, not I2C. Unfortunately, I have >>> this to work with :( >>> >>> Is it too much to limit the data transfer size to the RAM you want to >>> dedicate to one message? >>> Implementing a multi-function stop-and-go interface frightens me. >>> >>> M >>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >>> End of eLua-dev Digest, Vol 35, Issue 41 >>> **************************************** >> >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |