keithOk. A post or two back, I mentioned that I wanted to rework the receive UART because it wasn’t working perfect. I fixed that, and now it’s reliably receiving. I also mentioned that my sending uart code was solid.
Well, suffice to say, its not. 🙂
I was in the process of adding a checksum routine, and I couldnt get the stuff to come out right, and I thought I was screwing up my checksumming code, which is very simple. 8-bit MOD checksums are pretty easy. newchecksum = oldchecksum + newbyte. is all im doing.
My bit times were in the neighborhood of 540ns, and since I’m transmitting at 2mbps, they should have been 500ns on the nose. That extra 40ns is about 7.5% off, and I think normal spec for baudrates is about 3% tolerance max.
I transferred a large amount of data, and I was seeing about 1 error for every 3000 bytes. Thats .0003 error rate. Pretty good, but when you look at transferring 13824 bytes each time, that’s like 5 errors per track. Way too many. So lord knows how this was getting in my way earlier when I was having trouble getting a perfect track out of the drive.
The test ran 80000 bytes and 26 came back bad. The thing that threw me off was that the byte-counts were perfect even though the data was bad — I thought a UART issue might manifest itself by screwing up all the timing, I guess not.
Anyways, a new test, I ran 145,000 bytes through it and got 0 errors. Much better. Sent 10 times as much data as a normal track, and I got 0 errors. Very good.
The original test was sending just one character, because I figure if I can’t get any one character to transmit reliably then the whole thing is broke. The new test transmitted 5 different characters across the range, so it was a more robust test.
I used the scope to measure bit times, although measuring start and stop bit lengths can be a challenge due to the fact that they look like normal bits.
In any case, instant improvement in reliability, and I’m happy about that. Quick fix too.
I’m going to go back to my checksum stuff and put that in. I think knowing that there was a usb transfer error is very important in the overall scheme…..
Spoke too soon.
Turns out I’m still having reliability problems with the sending UART.
To completely skip this issue and move on to try to get something basically working, I’ve switched to using Parallax’s SERIN/SEROUT SX/B commands which they’ve improved the baudrate.
Sending it xmit up to 921600 but recv is a slow 230400. Not sure how I can take advantage of a higher baudrate unless I close and re-open the ports. Otherwise 230400 isn’t too bad. .6 seconds to transfer a track.
The problem I was having is that I was using a MOVB command in my uart which moves the particular bit onto the TXDATA port. Turns out MOVB is a 4-cycle command, and depending on the state of the BIT to transmit, either a 0 or a 1, it took different times. Like I think a zero got transmitted on the 2nd-cycle and a 1 gets transmitted on the 4th cycle. Well that’s 40ns and that 40ns is tons of error at the baudrate.
Ahh well. I will address the issue of optimization once I get this damn thing working………