Software UART driver

Started by Daniel Doron November 10, 2014
On 2014-11-11, David Brown <david.brown@hesbynett.no> wrote:

> My record for bit-banged uarts is 38.4 kBaud on a 9.8 MHz processor.
I did 57.6K on a ~1 MHz processor, but it was tx only. Still, it worked great for printf() output while bringing the board up. IIRC, on that same processor, I did a 1200 Bell-202 modem (rx and tx) using a counter/timer, but I used a hardware UART for that. -- Grant Edwards grant.b.edwards Yow! Th' MIND is the Pizza at Palace of th' SOUL gmail.com
On 2014-11-11, Vladimir Ivanov <none@none.tld> wrote:

>> Trying to do it from Linux (and with a very old kernel on a slow >> processor) is going to be difficult unless he can dedicate a high >> priority timer interrupt to the job. With a timer interrupt with fairly >> low jitter, it should be fine, even with Linux running. If possible, >> the interrupt code and the relevant data should be put in internal ram >> so that cache misses do not slow it down. > > If possible, OP could try FIQ with highest priority and write own > small handler in assembler, using the FIQ banked registers for speed. > No kernel API usage at all, just plain FIFO (ring buffer) somewhere > in memory for lowest overhead. > > All the implications with kernel disabling the interrupts remain.
The kernel never uses and never disables the FIQ. It runs completely outside of kernel awareness and control.
> As a very quick test, I'd put short FIQ code that simply toggles > GPIO, and then check visually how bad the jitter goes under load.
Been there, done that. The FIQ jitter does not change noticably under load. Any interactions with normal kernel code have to be done very carefully, since you can't use any of the kernel's normal synchronization mechanisms. -- Grant Edwards grant.b.edwards Yow! And then we could sit at on the hoods of cars at gmail.com stop lights!
On 11/11/2014 1:06 AM, Daniel Doron wrote:
>> Are you already using the 3 on chip USARTs on the 9263? If not how about >> just using one of them as a serial device from Linux. > > yes. using all of them already. >
How about the TWI or SPI ports ?? Will you need two way communication ?? Creating a real time serial data in a non-realtime operating system seems doomed to failure. Thinking out loud, to send serial data bytes: how about the SPI data port acting as the 8-bit serial data. As the SPI port holds the state of the last bit sent, three bytes 0x01,(Txdata>,0x80. Setting the SPI baud rate timer for 104.166 uSec would give you ~9600 board. Update time between byte would be ~.83 mSec. The SPI holding register will keep the bytes side-by-side. RxData will be much harder.