Bit Banging

[Jon Wilder]

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).

 

[bhodder]

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).

I did see that and accounted for it.

 

[Jon Wilder]

Are you sending 1 byte, then having the PIC wait 10 bit times before sending the next byte?

 

[bhodder]

Are you sending 1 byte, then having the PIC wait 10 bit times before sending the next byte?

Hi Jon,

I have got the program running on the PIC now but I send 80 6f c8 b6 b6 06 d7 and it sends back f8 fb fe fb fe ff. What would cause that?

 

[OlPhart]

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. <<<)))

 

[bhodder]

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. <<<)))

The problem is that because I am dealing with J1708, I need to use the hardware usarts, one to receive the data and one to send the new message signal and forward the data.

 

[bhodder]

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. <<<)))

It is definitely a timing issue. How can I correct for this?

Blake

 

[OlPhart]

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... <<<)))

 

[bhodder]

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... <<<)))

Hi, J1708 is the protocol for the diagnostics on the commercial trucks. it is async and 9600. Now the data is received on one USART and then sent out of the PIC on the other. Do I still need to make it so one is so much faster than the other?

Blake

 

[OlPhart]

Ok, got a better view now. Find a way to make the J1708 send a known pattern. Attach some type of readout, or use the debug/programmer to read PICs' RAM. (I don't do PIC so I don't know its' facilities) Write a short routine to record the USART bytes to RAM. Work the USART parameters until you repeatedly see exactly what the input pattern is. Half the problem done.

Then add a routine to send out the RAM pattern (or any known test pattern) to whatever the PIC feeds. Work the output USART until pattern is received correctly.

That you know it's async @ 9600, high speed oversampling isn't necessary. If your application can tolerate it, I'd receive/buffer the entire input block, Then send it out. Input vs output bit rates can make continuous operation Real Interesting. Good Hunting... <<<)))