|
|
View previous topic :: View next topic |
Author |
Message |
osu1177
Joined: 10 Feb 2011 Posts: 14
|
|
Posted: Fri Mar 02, 2012 1:42 pm |
|
|
Hi asmallri,
I understand the basic principles of creating a software UART, but without a master or slave, if chip A is sending information to B, and B is sending information to A at the same time, how do you prevent a loss of data without buffering the data into a shift register (such as in hardware UARTS) ?
How would you create 6 full duplex software UARTS? Or even one for that matter? |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Fri Mar 02, 2012 3:24 pm |
|
|
osu1177 wrote: | Hi asmallri,
I understand the basic principles of creating a software UART, but without a master or slave, if chip A is sending information to B, and B is sending information to A at the same time, how do you prevent a loss of data without buffering the data into a shift register (such as in hardware UARTS) ?
How would you create 6 full duplex software UARTS? Or even one for that matter? |
Separate ring buffers are required for each transmit buffer and each receive buffer. If you want 6 software UARTS then you would have six transmit ring buffers and six receive ring buffers.
Each software UART would also have its own transmit and receive shift register for serializing in and out the current byte
The software UART mechanism I am talking about is not the simple CCS style UART. Instead it uses a timer based interrupt handler. The timer (Tick Timer) would run at multiples of the bit time (say 4 times the bit time).
Break the problem into transmit and receive handling. Every 4th bit time is a Transmit BIT where the next bit is serialize out. I use a transmit state machine to determine the current state which basically emulates the hardware logic. You would have six transmit state machines, one per SW UART. I usually synchronize all transmitting. i.e. on the 4th Tick the next bit of all SW UARTs is sent.
The trickiest part of the receive logic when using multiple SW UARTS is start bit synchronization. I use a receive state machine for each SW UART to determine the current state. Looking at it from a single SW UARTs perspective, in the initial state you are looking for a start bit. If you detect a possible start bit condition you move to the verify start bit state which means on the very next timer tick you check to see if the start bit condition still exists. If it does you have a valid start bit. You now sample the data bits every subsequent 4th tick.
I have used this technique to implement 1 HW and three software UARTs on a PIC18F with all ports operating at 115200 full duplex. However, when doing this the interrupt handler was coded in assembler (the CCS compiler was not aware that a high priority handler was implemented). The user application was restricted to using low priority interrupts.
If you do this on a PIC24 and above it is much simpler. Because only 9600 baud software UARTS is required the interrupt handler could be readily coded in C. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
osu1177
Joined: 10 Feb 2011 Posts: 14
|
|
Posted: Tue Mar 06, 2012 1:53 pm |
|
|
Hi Andrew,
I think I understand the concept: you are suggesting that I use 6 ports to output 1 bit every 4 instruction cycles, doing this 8 times for a single byte. It feeds this into 6 individual shift registers, which can later transmit the accumulated byte at the desired baud. The receiving shift register must be clocking in values at the selected transmit rate (in this example, once every 4 instruction cycles), constantly looking for the start bit, and when its present, it reads the incoming signal.
Assuming I have understood you correctly, it brings up a few questions. Firstly, why the need for 2 separate buffers (you mentioned a ring buffer, and then a shift register). Did you mean that there was simply one FIFO shift register? Or do you suggest using a ring buffer AND a shift register, per UART port? IF this is what you mean, then why? Isn't one enough?
Also, what buffer chips do you use? So far in my research, I cannot find a suitable buffer whose price, when multiplied by 6, is still cheaper than an additional PIC chip....
In any case, I highly appreciate your insight into this very clever approach. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|