Pic to Pic communication?

[Rob Martin]

I'm sure this is covered in the list somewhere but the list wont let me search "pic to pic communication" as the word pic is under 3 letters.

I want to sample a pulse in but need to sample it for upto 2 seconds. The problem is I need to do other stuff and display results every 1/2second.
I was thinking about using 2 pics and have one just sampling and producing an 8bit answer using 8pins and then reading the 8pins with a second pic?
This way the second pic always gets the lastest reading without having to waiting 2 seconds.
Any better ideas?
Could I use 1 x eeprom with one writing and one reading?
Probably not

Rob

[Melanie]

The first thing Rob is you're going to have to ask yourself a question... an I going to transfer a single BYTE (as you are implying in your mail), or is it going to be a WORD?

If you are measuring a Pulse with PULSIN, then a BYTE means you can only sample 2.55mS pulses (at 4MHz clock each tick being 10uS). If it's a WORD then 655.35mS, both of which fall short of your 2 second sampling time.

However, let's say your transfer IS a SINGLE BYTE. Nothing could be easier. The sampling (Transmitting) PIC simply puts the answer on a Port.. eg...

PortB=MySample

...and the Receiving PIC just reads in whenever it wants to from it's Port. The only possible problem is that the Receiving PIC just happens to be reading the Port as the Sample is updated by the Transmitting PIC... so a simple handshake cures that potential error like so... (in this case nine lines are required - an extra one for the Handshake)...

Transmitting PIC (assume a 16F628 for arguments sake)...

HandshakePin var PortA.0
DataPort var PortB
SampleData var Byte
. . . .
TRISA.0=1
TRISB=%00000000
CMCON=7 ' turns off comparators
DataPort=0 ' Initially DataPort will be Zero
. . . .
SampleLoop:
Gosub GetSample ' Get a sample
While HandShakePin=0:Wend ' Kill time if updates prohibited
DataPort=SampleData ' Update Data Port
Goto SampleLoop

Here, with the above example, the Transmitting PIC will update the Data Port unless it has been explicitly forbidden to do so by the Receiving PIC.

On the receive Side...

HandshakePin var PortA.0
DataPort var PortB
SampleData var Byte
. . . .
TRISA.0=0
TRISB=%11111111
CMCON=7
HandshakePin=1
. . . .
ReadData:
HandshakePin=0 ' Prohibit Port Updates
PauseUS 100 ' allow for latency
SampleData=DataPort ' Read Port
HandshakePin=1 ' Allow Port Updates

Now what we have here is the Receive PIC prohibiting the Transmit PIC from updating the Port whilst the port read is actually taking place. Now that PauseUS could in theory be removed altogether, but there is an outside chance that the Transmit PIC has just exited it's While/Wend the very moment the Receive PIC sets the HandshakePin to 0. If the PIC's are not in step, or the Receive PIC has a faster clock than the Transmit, you could encounter a scenario that the Receiver is reading the data port, just as the Transmitter is updating it. That small pause will prevent that from happening. By trial and error you could probably reduce the value quite considerably.

Melanie

[Rob Martin]

Melanie

Thanks for the prompt reply.
My idea was to transfer the 8bit data via 8pins (wasteful I know)

So if I had 2 x 16F628 20Mhz one sampling using pulsein
The other reading rs232 data in and send out to an lcd.

The one sampling the pulse would set 8 pins high or low in BCD format.

The second pic reads the rs232 then scans the 8pins and reads these as bcd. ( I am assuming I can read 8pins in ms's)
This seemed to be the quicker way than reading pulsein for between 1 > 2 seconds to get the result I want (I'm only expecting to see 1 > 5 pulses in a 2 sec period) Then read rs232 the display the results.

Hope that made sense

The problem I'm trying to over come is the pulsein sample time. I have to sample for a reasonable time to achieve a meaningful result. But I have to read the rs232 data as this comes in 3 or 4 times per second.
I don't want to be sat in a pulsein routine whilst new rs232 data is coming in.

I am assuming that PIC are not multi tasking?

Rob

[Melanie]

Depends on your definition of 'Multi-tasking'.

In as far as PICs can only excute one instruction at a time, then the answer is No.

But if you factor in all the additional hardware such as ADC's comparators, Timers, USART etc etc that can operate autonomously from your main program, then the answer is most certainly Yes.

By using PBP's PULSIN instead of say Caputure & Compare and SERIN (or SERIN2) instead of the onboard USART directly, you are relinquishing control of your PIC for long periods of time (as you have already concluded). Your skill as a programmer will decide how much you can have on the go seamlessly, and accomplish everything on one PIC or go for the simpler, but more expensive route and have two.

[Dwayne]

Hello Rob,

Rob >>
My idea was to transfer the 8bit data via 8pins (wasteful I know)

So if I had 2 x 16F628 20Mhz one sampling using pulsein
The other reading rs232 data in and send out to an lcd.

The one sampling the pulse would set 8 pins high or low in BCD format.
<<

Here is a sample of working PIC to PIC that I use. It is extremely fast. You can modify it to fit you.

The logic beind it, is to take a decimal and send each digit to the other chip. Using only two pins. You can play with the timing and speed it up tremendously. I used a 675 talking to a 648A. Tell me what you think..


The transmit still has "Test" data in it (Redundancy Number=1234), and NUmber is overwritten when a ADC is done.
Plus there are a couple of other things that could be changed. But it should work like a champ.

Dwayne


Recieve part.........
TRISa=%00110000
TRISb=%00000000
Counter var byte
Counter2 var byte
Result var byte

Pause 500
Porta.0=0
Porta.7=0
Portb=13 'clear lcd
Porta.0=1
Pause 1
Porta.0=0

'Flashes LED
Porta.1=1
Pause 1000
Porta.1=0
Counter=0

Loop3
Counter2=0
Result=0
Loop2:

if Porta.4=0 then Loop2
Result.0=Porta.5
Result=Result << 1
kt:
if porta.4=1 then kt
Counter2=Counter2+1
if Counter2 < 4 then Loop2
Result=Result+48
Counter2=0

Porta.7=1
Portb=Result
Porta.0=1
Porta.0=0

Counter=Counter+1
if Counter=16 then
Porta.7=0
Portb=1 'clear lcd
Porta.0=1
Pause 1
Porta.0=0
Counter=0
endif
Pause 3
goto Loop3
end


Tranmit part...........

ANSEL=%00111000
CMCON=%00010111
TRISIO=%00011100
ADCON0=%00001100
DEFINE ADC_BITS 10
DEFINE ADC_CLOCK 3
DEFINE ADC_SAMPLEUS 50

counter var byte
counter2 var byte
Digloop var byte
Dignum var byte
Number var word
Number=1234

Loop:
GPIO.5=1
Pause 300
GPIO.5=0
Pause 300
if GPIO.2=0 then Loop
GPIO.0=0

ADCIN 3, number
number = number >> 6




For counter = 3 to 0 step -1
DigNum=number dig counter


for counter2= 1 to 4 step 1
GPIO.1=DigNum.3
GPIO.0=1
Pauseus 50
GPIO.0=0
Pauseus 500
DigNum = DigNum << 1
next counter2
Pause 10
Next counter

Goto Loop

End

[CBUK]

why not exploit the 16f877's etc onboard USART, then you can just use the simple hsrout and hsrin commands, i think off the top of my head port c.6 and c.7 are your tx and rx. i have had great success and am running an inverter panel communications system off the pics. thats 5 data commands(bi directioinal to the inverters), a copy of the original request and an address, thats to 32 inverters!
works wonders and as a demo i tried a ping of all the pics, managed to overflow the doubleword variable and not have any missing returned packets.

as these pics have hardware USART's they can store a small amount of data (again off the top of my head 8bytes?) and so it gives a small scope for letting the pics catch up to speed (thats if you dont have any forms of hand shake or acknowlege commands).

Chris