Need help writing to custom bus protocol

[iso9001]

Hi,

I'm working on a project that requires me to read in and write on a 1 wire serial communiction. Its a stupid old system that was proprietary and no one has done anything like it I beleive. Its very similar to OBD2 VPW but not exact, uses different timings, voltage, data length, crc etc

The problem I have is my board has to be taking adv readings and toggling/checking digital pins on a timed basis (my shortest event is every 2ms). So while I'm doing all this other stuff I'm finding it difficult to find the time to read in this bus and when I go to write out to it, I block the chip from doing anything till I'm done bit banging the signal out.

For example, my write code (which is WAY more important then reading, but I'de like to do both):

// S = 200us
// L = 400us

//Start writing
output_high(BUS); delay_us(L); //1
output_low(BUS); delay_us(L); //0
output_high(BUS); delay_us(S); //0
output_low(BUS); delay_us(L); //0
output_high(BUS); delay_us(S); //0
output_low(BUS); delay_us(S); //1
output_high(BUS); delay_us(S); //0
output_low(BUS); delay_us(S); //1
... etc etc
output_high(BUS); //done

//go back to doing stuff now,

I know it doesn't seem like much, but those uSeconds add up. I think this should be possible without using delays.


I'm trying to figure out a way to not block the chip while I'm writing. My longest side task takes me 30us. So I spend a lot of time in the main loop not doing anything, I figure maybe I could set a flag like WRITE_DATA=TRUE, and then have a few bytes of data stored somewhere I could passively bit bang out.

I know this is possible but I've had a hard time figuring out what I need to do,

Anyone have any suggestions ?? A passive read() part is next,
Thanks!

(using pic 16F87X but could switch if needed)

[newguy]

I had a similar issue. I have two processors - one is concerned with the user interface, and the other is locked away in a vault. They communicate via CAN bus.

The user interface processor has an IR decoder to allow 'pass through' of IR commands from a standard remote control. The user can use the remote to be able to control some A/V equipment locked away in the vault. The user interface processor receives/decodes/compresses the IR bitstream and sends it to the remote processor via the CAN bus. Once all information necessary to reconstruct the IR bitstream has been received by the remote processor, it then starts to "beam" that information to the A/V equipment.

This is where our situations are similar. I couldn't use an approach that involved delays because this processor also communicates with many other processors, and requests for information can come at any time and must be serviced immediately (more or less). When those requests come, they can't interfere with the IR transmission either because that would result in a miscommunication with the A/V equipment (and that can't be tolerated).

What I did was set up a rather complicated but very robust algorithm involving a timer interrupt. The general idea is that you load the data that must be transmitted, set the output pin appropriately, and set the timer to go off at the appropriate time (which for you appears to be either 200 us or 400 us). You also load the next timer value at this point in time as well to speed things along the next time the interrupt occurs. When the timer interrupts, you toggle the state of the output pin, reload the timer with the value you 'set aside' earlier, and load the timer value for next time. This goes on until you're done sending the information.

There is a rather small latency between when the interrupt fires and the processor actually gets around to servicing the interrupt, but this time should be more or less the same no matter what the processor is doing. The net effect is that the timing accuracy on your output waveform is relatively good. There will be some jitter, but that will be relatively small.

I can't really elaborate more as this is proprietary stuff, but you should get the idea.

[iso9001]

Hey newguy,

Yea I know what your talking about, thats kind of what I had planned.

If I'm in a 20us delay for my adc and the timer goes off it will still jump to the timer_isr right ? I don't know if I've ever had to check what happens to an interupt request when the pic is in a loop, pretty sure it would jump...

Hmmmmmm..... I could set that up.

Are you setting a flag in the interupt that the main loop checks later and changes the data or are you doing all the work (shifting next data bit, reloading timer, changing output state) there inside the isr? I could do the later although I think its against recommended practice, and I'd have to make my data global.

I'll have to think about this for a bit, I'll certainly try it tho.

One thing is I can see it handeling the writes, reads may be another issue tho.

[newguy]

[Mark]

Use the CCP for your transmission. Create a state machine and load a CCP value that represents your delay time. Somewhere in your code you would start the transmission. The would reset the state machine and enable the CCP interrupt. Now your program can resume operation and the transmission will be handled by the interrupt.