Serial Interface - multiple UARTs in Assembler

Cluso99

Hi All,

While I await my proto board delivery (cannot wait) I am starting to work on how to implement my design.

My design requires multiple ports, full-duplex, TXD & RXD only, and checking start and stop bit(s) (i.e. checking for framing errors).·4800 baud although·up to 38kb or 57kb would be nice. UARTs·normally sample at 16x baud rate.

The only code I have found waits for a start bit and then starts counters to shift in the bits at the centre of bit time.

Q1. Has anyone done a·multiple UART with framing checks ?

I envisage one COG dedicated to handling the multiple UARTs and passing the data between Hub memory.

I thought I would use classic buffers in Hub memory utilising·head and tail pointers. The UART COG would be responsible for maintaining the head pointers for the receive buffer and the tail for the transmit buffer. The other COG(s) running the terminal applications would maintain the opposite pointers.

Q2. Under the above scenario, I don't see any need to use locks for reading the pointers. Is my assumption correct ?

Q3. As the COGs have different time slice access to the Hub memory, there should be no impact to the other COGs while continually accessing hub memory. Is my assumption correct ?

Thanks in advance.


·

Ken Peterson

Do you find it necessary to do 16 samples per bit?

Q1: I've done framing checks, it's just a matter of checking the stop bit and the parity bit (if applicable) and rejecting the byte if they aren't valid. You can also set a flag if you need feedback.
Q2: I dont' think the Full Duplex Serial object uses locks.
Q3: That is correct. Only one cog accesses the hub at a time.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Peter Jakacki

Hi Cluso,

I have an assortment of various drivers including multiple uarts in a single cog but I probably need to test them properly and dress them up a bit. What do you mean when you say that the only code you found shifts in bits at the centre of the bit time? This is how uarts in general shift in data and allows for timing errors etc. Framing checks are normal as well, well they should be, I check for stop bits and/or parity if that's what you mean.

There is no need for locks as whatever pointer or data that one side writes is what the other side reads. This means however that pointers should not be updated unless the data has been read or written already of course. So it's not so much of a correct assumption on your part, just more of a redundant one I think [noparse]:)[/noparse]

A3: Thanks to Parallax for keeping it simple and reliable, slow maybe, but reliable.

I am in the process of honing my serial drivers and fixing up any little problems but especially getting the timing nice and even at higher baud rates (above 115.2K). This stuff needs a lot of cycle counting and measuring with the scope to get it right. The multiple uarts/cog drivers aren't spec'd to operate at higher baud rates but should be fine at 38.4K and under, maybe even 57.6K. That may all change for the better when I get to adjust the timings though.

Some features that I use regularly are:
XON/XOFF (could easily add CTS/RTS)
RS-485 with programmable release time (usually 2 bits after the last stop)
Large buffers (allocated at compile time for now)
Parity
Programmable data length (also means programmable stop bits)
Character timers (sense idle conditions etc for various bus protocols)
Auto Rx and Tx Checksums

I will try to release a dual comport driver shortly depending on how I manage seeing that I'm snowed under with so many new prop designs. Too much hardware, not enough software! Can't wait to spend some quality time on software.

*Peter*

P.S. I just checked your location and I see you're on the Gold Coast. Catch up to me around Surfer's on Thursday if you like.

Cluso99

Thanks Ken & Peter.

The sample codes do not wait for the beginning of a character because when the cog starts it is possible to be in the middle of a received character.

UARTs usually scan at 16 times the baudrate. This allows for about +-45% jitter. I also need to ensure when the COG starts that it is not in the middle of a character (easy enough).

I was going to use a PIC. When I saw some of the things being done on the propeller, I thought it would be much better and more fun. I am used to Risc machines that store return addresses in branch (goto) instructions and don't have stacks as such.

I helped design a product based on the first available UART in a chip (about 1972-3) - No micros then!!·Later I coded a serial·interface (bi-phase running at about 17.5uS) on a MC68705P3 running at 4MHz (instructions 3-4uS a piece). And it had to resynchronise on each transition. All in 1.7KB memory and interfaced to another MC68705P3 to handle to rest of the job. It communicated to an ICL minicomputer. The various models had slightly different timings, hence the resynchronisation. Later on I coded a modem control chip with the MC69705P3 with "AT" command set and once again had to deal with synchronisation as the Apple //c was out of spec. Since the project was sale by Apple Computer in Australia it had to work with all their models.· The MC68705P3 is a 28 pin UV erasable microchip and doesn't have a UART.

Peter: We live on our catamaran "Blue Magic"·(as pictured) at Hope Island Marina. See my website www.bluemagic.biz for my email. I am usually online most of the day until late.
·

Ken Peterson

I recently worked on a wireless device using the 315MHz transmitter/receiver pair sold at Sparkfun. Whenever the transmitter is not sending, the receiver spits out a lot of garbage. So when the transmitter started sending I would first send a few $F0 bytes at the beginning of the message to byte-align the receiver. With 8N1, $F0 comes over as 0000011111 (LSB first), which makes it easy to align on the start bit. The receiver would wait until it received $F0, then ignore additional $F0 bytes until it received something else (start of message).

In my application, both transmitter and receiver were crystal controlled, so jitter isn't that much of an issue. It might be an issue if you are trying to use the internal clock on the propeller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Cluso99

Ken,

I will be using a xtal. I don't have control of the data being received, so I will have to try and synchronise, probably by waiting for an idle period (stop) exceeding the character length, or a <cr>. Fortunately, I know what I am receiving is sentences, terminated with <cr> with gaps in between transmissions. They are·mostly NMEA instruments.

I am hoping to have 8 tx/rx pairs (i.e. 8 UARTs), one of which will be connected to a USB via either a FT2232 or an CP2102. I may have to use a separate GOG for the USB (because it will be fast), but I expect the others will be able to be performed by a single COG.

Regards,
·