Jon Wilder
Active Member
I just noticed a typo in my code. The function void DataSndUSART(unsigned char data)...make sure it says void DataSendUSART(unsigned char data) (I forgot the "e" in Send).
Last edited:
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
I just noticed a typo in my code. The function void DataSndUSART(unsigned char data)...make sure it says void DataSendUSART(unsigned char data) (I forgot the "e" in Send).
Are you sending 1 byte, then having the PIC wait 10 bit times before sending the next byte?
Timing is off. When I'm debugging this process (used in several projects) I send easy, obvious patterns: $00, $ff, $00 or $55, $aa, $55 or $18, $00, $18 then combinations thereof. These make it more obvious which end is losing sync (or never got it). If possible, send a burst one way and look at what's received. Sending out & back makes it a Lot tougher to find the problem.
I've found the I2C protocol a great serial method. It'll take some time getting the routines right (BTDT2), but once done, it's deterministic (not timing dependent) and much faster than any async (no start or stop bits, short to no pause between bytes...). G.H. <<<)))
Timing is off. When I'm debugging this process (used in several projects) I send easy, obvious patterns: $00, $ff, $00 or $55, $aa, $55 or $18, $00, $18 then combinations thereof. These make it more obvious which end is losing sync (or never got it). If possible, send a burst one way and look at what's received. Sending out & back makes it a Lot tougher to find the problem.
I've found the I2C protocol a great serial method. It'll take some time getting the routines right (BTDT2), but once done, it's deterministic (not timing dependent) and much faster than any async (no start or stop bits, short to no pause between bytes...). G.H. <<<)))
That you're dealing with hardware USARTS, make sure your clocking methods are either synchronizable (one is an integer multiple of the other) or one is SO much faster that it can oversample the other (presuming async). I hope there's a way to separate these pieces so you can see intermediate stages. Testing/debugging enmasse is difficult at best.
I didn't catch what protocol is used: async at ?baud or what. I'm not familiar w/J1708 unless it's the JTAG spec for lowlevel chip access. I seem to mem using something like this to access underneath the corrupted bootloader of a Linksys router that had bricked, but that was a year+ ago and I think it was a sync protocol. G.H... <<<)))