View previous topic :: View next topic |
Author |
Message |
JBM
Joined: 12 May 2004 Posts: 54 Location: edinburgh, Scotland
|
2-way data, one wire |
Posted: Sat Dec 10, 2005 6:06 am |
|
|
I've got a particular application which needs to send data in two dircetions bewteen two PICs, over one wire. To make things more difficult, the I/O pin on one of the controllers (the slave) has to be B7, so no INT_EXT solution for me.
I have a solution atm in which every data transaction sees the master send a byte, followed by the slave sending one back (even if it's a dummy byte), but it's not very flexible or reliable.
It's a master/slave system, sending small (<100 bytes) amounts of data, so massive datarates aren't necessary, but 9600 or thereabouts would be nice.
Lastly, I repeat that there is NOTHING I can do to change the fact that I have to use B7.
Thanks in advance.
-JBM |
|
![](templates/subSilver/images/spacer.gif) |
dyeatman
Joined: 06 Sep 2003 Posts: 1924 Location: Norman, OK
|
|
Posted: Sat Dec 10, 2005 8:11 am |
|
|
You might still use #int_rb depending on what you have on R4-R6. Apparently you are not using ICSP either since B7 is NOT available. The FAQ has info on using int_rb and PIC to PIC comms. |
|
![](templates/subSilver/images/spacer.gif) |
JBM
Joined: 12 May 2004 Posts: 54 Location: edinburgh, Scotland
|
|
Posted: Sat Dec 10, 2005 9:03 am |
|
|
I'll clarify my problem - the PIC is in a custom packaging (out of my control) which has 5 connectors -Vcc, Vss, MCLR, B7 and one connector to both B7 and CLKIN (B7 and CLKIN are connected withing the packaging). This allows both programming, and data I/O. That's the plan.
Any ideas anyone? |
|
![](templates/subSilver/images/spacer.gif) |
Douglas Kennedy
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Sat Dec 10, 2005 10:33 am |
|
|
Well you've looked at a char handshake to provide the snychronization that says which of the two pics can talk. The issue with this is if the synchronization is broken it is hard to recover.
Idea to consider
The DALLAS ONE WIRE ( aka touch pin) allows more than one slave on the one wire bus ( actually its two wires since there must be a common ground). The communications line is wire ored ( you'll need an open drain pin for the touch pin on each PIC)... the master PIC can always gain control with a long duration reset pulse ... the slave must acknowledge with a shorter duration presence signal. The line since it is wire ored can be brought low by either PIC at any time. The duration of the low will indicate the synchronized state the line must be in. Each PIC must monitor how long the line is low. Very short lows represent a true zero but a long low is an interrupt. The line is pulled up so a logic one is written by floating the pin. If the other PIC is pulling low it will win so your code needs to detect that it was stomped on and start a timer to measure the duration of the low.
Look at touch.c maybe it will give you ideas as to how to mimic the master timed pulse the slave should not be too hard to mimic either.. |
|
![](templates/subSilver/images/spacer.gif) |
JBM
Joined: 12 May 2004 Posts: 54 Location: edinburgh, Scotland
|
|
Posted: Sat Dec 10, 2005 10:59 am |
|
|
I was afraid someone would say onewire. I've used it a lot to interface to DS sensors, (as a master) but i've never implemented a slave device. I'm not sure I want to go there but if there's no other way.... |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Sat Dec 10, 2005 11:20 am |
|
|
JBM wrote: | I was afraid someone would say onewire. I've used it a lot to interface to DS sensors, (as a master) but i've never implemented a slave device. I'm not sure I want to go there but if there's no other way.... |
That was the solution that popped into my mind as well. The thing I'd be leery of is the latency in the slave when the master initiates communication.
As you are aware, the data line shared by the two PICs would be externally pulled high, and the PICs would have to interface to it in an "open drain-like" manner. When the master starts communication, it does so by pulling the data line low for a relatively long time. After that, data is written & read by the master pulling the line low, then releasing it. Depending on whether the master is writing something or the slave is responding, that dictates how long this data line is actually held low. The timing is usually on the order of 10 us or so.
I'm just concerned that 10 us wouldn't be enough time for the slave PIC to detect the condition and respond. Perhaps if you "rolled your own" 1-wire interface with extended timing conditions compared to the true Dallas specs......
Or have a run mode and a comm mode in the slave. The transition from run to comm mode being triggered by the first long "reset" pulse low from the master. In comm mode the slave suspends normal operations to focus all its time on communication, which would mean you could have bus timing close to or at the Dallas specs.
Food for thought. |
|
![](templates/subSilver/images/spacer.gif) |
Douglas Kennedy
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Sat Dec 10, 2005 1:21 pm |
|
|
About two years back I wrote code so that a slave pic could be on the same dallas one wire as other true dallas devices with a PIC as the master. This is more complex than needed here since the PIC slave had to participate in match rom and search rom commands.
Basically for this situation I'd borrow the data bit timing from Dallas why experiment when its done already. I'd use the extended low time as the alternative to the interrupt pin you are denied due to design constraints outside your control. Theres no need for match rom or search rom since there is only one slave. The send and receive byte routines in touch.c are equivalent master or slave so all that is needed is the long low pulse and its detection at both ends via possibly a timer overflow interrupt. As long as the low exceeds at least the time to send two bytes it will be detectable and distiguishable from two hex00 bytes. I'd stay with the Dallas timing using the presence pulse timing for the interrupt. The asumption here is Dallas put research time into the timing choices so they may be optimal. |
|
![](templates/subSilver/images/spacer.gif) |
|