View Full Version : Precision 256 Byte FIFO Buffered Full Duplex Serial Drivers
I decided to rewrite Chip's Full Duplex serial driver to make·it little more straight forward and a little more precise.
So... here are the results...
The new·drivers are·capable of any baud rate between 300 bps·(or zero) and 115.2 Kbps, pretty much the same as Chip's driver. However, I added 256 byte·input and output·circular FIFO buffers for large data transfers.
The buffers act as standard FIFO buffers (first in first out) and allow for 255 bytes to added into them before the driver starts to throw away·any or ignore data without being emptied. Why 255 bytes? Well, the algorithm works by computing the distance between the newest piece of data and the oldest piece of data in the buffer. If the distance is (0 - 0) or (256 - 256) then the driver cannot tell if the buffers are full or not so it always assumes in those cases that the buffer is empty. That is why the max is capped at 255 bytes.
In additon to adding 256 byte FIFO buffers I also removed the multitasking coding used in Chip's driver and used coditional coding instead. The newer driver·updates itself at twice the baud rate now inorder to lock on to any·data being sent and to precisely transmit data.·The timing is now very precise.
Now, the driver is coded for simplicity and without self caluculation code. So if you want to inverse the bytes or whatnot you need need to edit the asm yourself. This driver was written for the purpose of communication to and from the computer at a very fast speed using large buffers. So the driver assumes that there is a pull up on the rx line and drives the tx lines itself.
Anyway, that's about it. Have fun with it.
Post Edited (Kye) : 1/9/2009 6:19:10 PM GMT
The driver·is also up on the object exchange.
01-08-2009, 11:02 AM
I am new to the serial Com and was searching the post and found your serial driver.
I began using is and I like it a lot, But after trying to implement it I ran into an issue.
I have working code using the simple FullDuplexSerialPlus object and it works fine in both Hyper terminal and Labview.
When I replaced FullDuplexSerialPlus your Driver with the same baud rate setting. The Terminal window also works fine and spits out the same exact text as the FullDuplexSerialPlus. But Labview has issues with the data stream and gives errors.
I was wondering if you had any suggestion on how your driver handles things differently than FullDuplexSerialPlus. It seams to me to be a timing issue but not sure......
This is an example of the Hyper terminal Output(2 loops of Data):
01-08-2009, 03:58 PM
I've been using SPIN sofar, but now I'm working with an application where I need some assembler-knowledge so I'm struggling to learn the basics.
Please bear with me for asking some newbie-questions about the logic in your driver:
In the initialization section: shr baudrate, #1
I assume this divides baudrate by two, but why? To loop twice as fast?!
In the receive setup section:
mov receiverCounter, #19 Why 19?
In the receive packet section:
test receivercounter, #1 wc
if c jmp #send why jump to send if odd parity?
shr receiverBuffer, #1
test receiverPin, ina wc can you explain the logic in these three lines?!
muxc receiverBuffer, #$100
In the transmit setup section:
or transmiterBuffer, #$100 What does this do, and why?
shl transmiterBuffer,#1 Why?
mov transmiterCounter, #19 Why 19?
In the transmit packet section:
test transmiterCounter, #1 wc
if_c jmp #loop why jump to send if odd parity?
shr transmiterBuffer, #1 wc
muxc outa, transmiterPin can you explain the logic in these two lines?!
Except these I think I know what's going on, so I would be very thankful if you have time to help me sort this out
Please tell me what exactly is happening... I am not familar Lab view.
Also, are you using the·FIFO buffers correctly? They only accept a·certaint amount of data and need to be checked.
And what platform are you using? My drivers are made purposely to be streamlined so if they aren't running on the hyra platform they may require modification.
I divide the baud rate by two so the driver can update itself twice as fast. Basically, for whatever baud rate you set the driver to run at the driver will then update itself and 2 times that baud rate. This isn't needed for the transmiting part of the driver. But this·allows the receiving part to catch any data that's been sent by checking the receving line at twice the speed of the baud rate. When the driver then sees the start bit it then locks onto the data and samples it after that.
Now, I use 19 as my constant for my loops beacuse my driver samples or sends bits during even or odd times, the idea is that 19 should allow the driver then to·start receiving again·right after it finishes receiving. The same being said for transmiting. That being said the driver can send or receive data back to back.
Now, you also cut some of my receiving and transmiting code out. Some of the code adds the start and stop bits and some of the code removes the start and stop bits. The testing and shifting and muxing parts are how the driver samples the lines to receive or·send data. Using the test command with a bit mask of the·pin you want allows you to get the state of that pin into c. Which can then be writen into a variable using muxc.
Anyway, please tell me of problems your having and I will address them.
Post Edited (Kye) : 1/9/2009 6:17:34 PM GMT
Okay, I went back and did some testing.
The driver receives data and sends data just fine in half duplex and full duplex modes. The circular FIFO buffers also work properly on the transmiting and receiving sides.
Also, the FIFO buffers work as expected and block data when they are full.
Now, the drivers can send and recieve data back to back. Meaning that if a data stream starts and whatever you are using to capture data from the drivers does not pickup the start bit from the first byte sent... then the rest of the·data stream will appear as if·it were garbage because of the high data transfer rate.·This is because the bytes are sent back to back... and their is no time for the receiving application to reset itself.
This is also true for the receiving side of the drivers. If you bytes are recevied back to back and the start bit was missed then the data will also appear as garbage. However, the receiver in the driver will catch everything, so this should not be an issue for receiving.
Be aware of transmiting however. Make sure whatever application you are using is ready to receive the data.
Post Edited (Kye) : 1/9/2009 6:30:56 AM GMT
The driver as been updated. Check it out now, I added some nice features.