From: David P. <sig...@gm...> - 2010-09-27 15:59:15
|
We solved our problem by changing the calls to tcsetattr() that changed the Mark/Space parity to use TCSANOW, place a microsleep of 250u in between the address byte (with wakeup bit set) write() and the tcsetattr() Space parity reset, then sending the remaining bytes of the packet. We're now getting roughly 1ms inter-character delay between the wakeup-bit byte and the next non-wakeup-bit byte, with an inter-character delay of only .5ms between the normal bytes. On Sat, Sep 25, 2010 at 8:54 AM, David Pedersen <sig...@gm...> wrote: > Isn't UART_USE_FIFO the standard for serial comms? Why would it not be > set? I'm using the pre-built image set > omap3-palmtop-image-overo-201008132038. > > > On Wed, Sep 22, 2010 at 11:18 PM, R. P. McMurphy <log...@gm...>wrote: > >> Have you checked that the FIFO is enabled? I cant imagine any other >> reason to have delays between characters. In our system we use a >> 3.6864Mhz clock with no delays between characters, the 64byte FIFO >> works great on both UART1 (ttyS0?) and UART2 (ttyS1?). >> >> On 9/23/10, David Pedersen <sig...@gm...> wrote: >> > Hi Dave, >> > >> > Thanks for responding! To answer your question, we're using 1 start >> bit, 8 >> > data bits, a ninth 'wakeup' bit, and 1 stop bit, and are using the >> CMSPAR >> > flag and PARODD to set & clear the wake-up bit. The first byte we send >> is >> > an address byte, which MUST have the ninth bit set, and any remaining >> bytes >> > in the packet must NOT have the ninth bit set. All of this works >> > perfectly. Our only trouble is the inter-character delay, which is >> causing >> > the connected device to timeout and cease responding. >> > >> > My understanding is that the ttyS0 port on the overo is not a true >> hardware >> > port, and I'm wondering if that could be the source of the trouble. I >> also >> > understand that ttyS1 IS a hardware port, but is redirected to the >> bluetooth >> > subsystem rather than the 40-pin chestnut connector. I've found Nabble >> > posts that indicate the port can be redirected to the 40-pin connector, >> but >> > the information is unclear and seems incomplete. >> > >> > Bottom line is that I need a way to solve the inter-character delay >> > problems, whether by adjusting a setting somewhere, or changing to a >> > different port. Do you have any experience with anything like this or >> know >> > of someone who does? >> > >> > Thanks, >> > Dave >> > >> > >> > On Wed, Sep 22, 2010 at 12:08 AM, Dave Hylands <dhy...@gm...> >> wrote: >> > >> >> Hi David, >> >> >> >> On Tue, Sep 21, 2010 at 11:52 PM, David Pedersen <sig...@gm...> >> >> wrote: >> >> > We have to write the first byte with a wakeup bit set, basically mark >> >> > parity, and then the rest of the message must be sent with space >> parity. >> >> > From 2 or 3 bytes, up to 20 or 30 bytes total in each message. The >> >> > first >> >> > byte is being sent independently, then the rest of the stream is sent >> >> with a >> >> > single write() call, however, surprisingly, the inter-character delay >> is >> >> > greater with the multiple-byte write! Strange. We're seeing about >> >> 14.5ms >> >> > on the single byte, mark parity write, and 15ms delay between the >> bytes >> >> sent >> >> > together. >> >> >> >> Hmmm. >> >> >> >> Are you sending 7-bit characters with parity? If so, then you may want >> >> to configure the uart to send 8-bit characters with no parity and >> >> calculate the parity yourself using a lookup table. >> >> >> >> I'm not familiar with the OMAP UARTs, but all of the UARTs I've worked >> >> with will send a FIFO worth of data completely in HW. I guess you >> >> might have to look into the driver to figure out what's going on. >> >> >> >> If you're changing the parity settings, I would expect that it needs >> >> to allow the FIFO to drain before changing settings. It's also >> >> possible that if the HW doesn't support mark/space parity it might be >> >> doing something funky in the driver. >> >> >> >> It's also possible that the FIFO might not be enabled. >> >> >> >> -- >> >> Dave Hylands >> >> Shuswap, BC, Canada >> >> http://www.DaveHylands.com/ >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Start uncovering the many advantages of virtual appliances >> >> and start using them to simplify application deployment and >> >> accelerate your shift to cloud computing. >> >> http://p.sf.net/sfu/novell-sfdev2dev >> >> _______________________________________________ >> >> gumstix-users mailing list >> >> gum...@li... >> >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> >> > >> >> >> ------------------------------------------------------------------------------ >> Start uncovering the many advantages of virtual appliances >> and start using them to simplify application deployment and >> accelerate your shift to cloud computing. >> http://p.sf.net/sfu/novell-sfdev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > |