Which Communication protocol to use

[lerameur]

Hello,

I want to communicate between two pic chip. I would like to know which command to use that create the most stable and reliable wired connection.
I am not sure which one to use between Serout, Serout2, Hserout, I2C ...

Can somebody suggest me one, and possibly the receiving pic can send back a validation number to confirm it has received all the information.
Also does someone has an example of this ?
thanks

K

[mackrackit]

I would go with HSERIN/HSEROUT, then you can use interrupts.
http://www.picbasic.co.uk/forum/show...097#post107097

[lerameur]

Great thanks

[Demon]

A lot of I2C techniques discussed recently in this thread:
http://www.picbasic.co.uk/forum/showthread.php?t=10141

Robert

[Charlie]

If absolute reliability is required, then some type of error detection and/or correction should be used. ALL physical interface types are prone to an error every now and then. Choice of method depends on what overhead you are prepared to pay. A Hamming code generator is fairly easy to implement, but cuts your thoughput in half. More common is CRC which for relatively low computational overhead is very good at detecting errors so you can ask for a retransmission. Simplest is a checksum. Or send things twice and compare received results... lots of ways to get around errors, so just pick a convenient protocol for other reasons like how far you want to send data, how much bandwidth is available, etc.

[Demon]

Yup, and checksum does not have to be nasa-type complexity either.

There are simple techniques on google (maybe even on these forums).

Robert

[tenaja]

Your decision also depends upon the specific PICs you are using, and the goals. Reliability of all are going to be similar. People are often more "warm and fuzzy" with HSerin because RS232 is comfortable, common, and simple. However, hardware based I2C is faster than HSerIn communication... (1 Mb/s or more vs. about 125Kb/s with Hserin--if you tune for high speed HSerIn), and they also have interrupts available, although Les does not have a demo of it... but the benefits of i2c do not help if the PICs do not have I2C master and slave.

Hserin can be simultaneous bidirectional, but i2c is one direction at a time. SPI allows simultaneous bidirectional communication at rates faster than i2c , at the expense of an extra pin or two.

Checksums are as reliable as your method. If you repeat every byte with an inverted value, you have great reliability but slow speed. You can add every "n" bytes together to generate a checksum, and your error will be proportional to "n" and the truncation size. Using 1 byte has very low error, 2 has slight chance, 256 greater chance...but still far better than no checksum.

Anyway, a generic "what's better" question cannot be answered without a list of requirements. Simplicity: go with HSerin. Speed: go with SPI. Moderate speed & fewer pins: I2C.

If battery life is an issue, then use HSerIn and crank up the cpu and go with fast transmission then slow it back down (or sleep it) for battery savings. Faster transmissions often use more "instantaneous" current, but for a shorter period of time so the battery lasts longer.

EDIT: I forgot to mention; if you are using the INTOSC, or separate crystals on the PICs, HSerIn is only as reliable as the oscillator speed; PIC's do NOT match the consistency promised in the datasheets!!!! Trust me, they vary GREATLY fro batch to batch. It is easy to tune one or two, but if you want to build a lot of boards, you could spend a lot of time developing a robust tuning system so they communicate reliably at higher speeds.