Fast yet reliable PIC-PIC communication?
I'm wondering what people think is the most reliable pic-pic communication that can achieve at least 14.4 kbps. The problem is, the receiving pic will have interrupts going off all the time that i suspect will mess things up? I would also prefer not to use interrupts for the comms itself.
Any ideas?
I looked at SHIFTIN/SHIFTOUT but it seems that they both generate a clock? Seems odd.
"I think fish is nice, but then I think that rain is wet, so who am I to judge?" - Douglas Adams
|
Not wanting to use an interrupt with the comms is going to be hard to not miss data.
Why not use hardware serial and an interrupt?
Dave
Always wear safety glasses while programming.
|
I just didn't want the comms interrupting the other interrupts either :-/
Perhaps I could use the hardware serial and simply poll the USART interrupt flag. The buffer should hopefully ensure that I dont miss anything. Will have to do some testing.
"I think fish is nice, but then I think that rain is wet, so who am I to judge?" - Douglas Adams
|
High low priority
Hi,
If your PIC have the option of high and low priority levels of interupts you can always put the RX as a low priority. Then the high level ones will not be blocked by the rx interupt.
/me
|
I still think you will need to use an interrupt or miss data now and then.
Are you going to use DTs instants? Not knowing the rest of the setup hard to say what the best solution is. But I will bet DTs stuff will cover it.
Dave
Always wear safety glasses while programming.
|
Yeah i'm using DT's instant interrupts. My question is tho, what happens when the RX interrupt is low priority, it is triggered, and then is interrupted by a high priority interrupt? Will the lower priority interrupt continue after the high priority one is done?
"I think fish is nice, but then I think that rain is wet, so who am I to judge?" - Douglas Adams
|
Why not use an acknowledge system...
So, pic0 sends data to pic1, when pic1 recieves the data and verifies it it whole it sends and acknoledge back to pic0...
If pic0 doesn't recieve the ACK then it re-sends after a time-out...
If PIC0 resends the same piece of data more than 3 times it does a 'crashed' cpu subroutine and then stays their waiting for user intervention...
This way, you could proberbly use some of the faster ways of communicating...
Enhansements to this would include some form of CRC checking to make sure atleast the number of bytes has been recieved...
So for example a data packet might look like this...
Byte1: To PIC #
Byte2: From PIC #
Byte3: Data Type
Byte4 to whatever: DATA
Last Byte: Number of bytes in packet including last...
So PIC1 sends and 'ACK X number of bytes' back to PIC0
Members who have read this thread : 2You do not have permission to view the list of names.
Posting Permissions
Bookmarks