Software UART driver

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.