Which multi-PIC mid-range comms protocol?

Hi there,

Used up all the good resources of a PIC16F886 to make a high resolution ADC (well, soon to be built, but gone through all the required PIC resource allocation), now I need to talk to another 16F886 (28pin) or 16F887 (40pin) PIC for RTC (32kHz watch xtal) and system control.

The ADC chip already taken the EUSART for serial comms to PC option. That leaves the other comms module:

" Master Synchronous Serial Port (MSSP) Module supporting 3-wire SPI (all 4 modes) and I2C Master and Slave Modes with I2C Address Mask " -- 16F886 datasheet

for talking to other chips and PICs.

I'm after suggestions for which master / slave inter-chip protocol is easy, reliable for local (within a couple feet) comms. Gotchas, pointers?

I'm programming in assembler with the MPLAB environment at this time.

Thanks in anticipation, Grant.

Reply to
Grant
Loading thread data ...

On a sunny day (Wed, 11 Aug 2010 09:43:09 +1000) it happened Grant wrote in :

If you dream up some protocol, you can put everything on the same RS232 (OR the outputs). This is sort of what I do in my PIC LED color controller.

For example PIC1 listens to commands starting with ctrlA, PIC 2 to commands starting with ctrB, etc. And each can reply with a sequence like ctrlX There are a zillion ways.

115200 Bd is fast enough. The alternative is to have a software RS232 output, as I am doing in a PIC project I am doing now. You can still use interrupt on input too. I have even done I2C in a PIC in software using an interrupt pin, emulating a PCF8574 I/O expander (and cheaper then one :-) ).
Reply to
Jan Panteltje

project I am doing now.

MODBUS/RTU on a balanced twisted pair( 485 ) works well, the MODBUS supports 31 devices.. A well known protocol, why reinvent the wheel?

Reply to
Jamie

Implementing MODBUS/RTU packet timing to the specification is a PITA. It demands tight character-to-character timing and measurement of interpacket timings. This prevents using the built-in FIFO's in the serial chips, and the timing is practically impossible to implement on a PC due to the unpredictable interrupt latencies introduced by operating system.

Been there - bit badly by that.

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

Not where I'm heading, more likely a tiny serial usb gateway to PC for control and data logging, and separately SPI or IIC to other chips, I don't need rs485 to talk a foot or two between chips for this project set.

Grant.

Reply to
Grant

Oh really, we've never had any issues implementing that in small devices. I really don't see the problem? The master is the one that sends data to a specific device and also makes request for the device to return data. The slave device does not tx nothing until its asked too. And that, obviously doesn't happen until the request what to send it fully received in the slave. If a master can not get it's shit together by then, something is being done wrong!

Oh well, have a good day!

Reply to
Jamie

MODBUS RTU is pretty crap and everyone puts in options to adjust the timing requirements or just plain ignores them.

I implemented a master talking to a commercial HMI panel. All worked fine until I tested the comms were reliable by breaking and reconnecting the serial link.

About 1 in 3 times it hung up with the HMI not responding and if you left it long enough the HMI would come up with some mal-formed error message that didn't make sense and that the manufacturers said they had no knowledge of.

It turns out that instead of following MODBUS specifications and taking any silence of more than 3.5 character times (at 38k4 baud) as an indication of frame start it ignored silences of over 100ms and considered the retry packets I was sending every 100ms to be part of the same mal-formed frame which (I assume) it kept storing for 2-3 minutes till it ran out of memory and crashed. After increasing the delay between retry packets to 200ms it all worked fine.

That HMI 'adjusted' the MODBUS RTU timing requirements by a factor of over

100 with no option to change it and no documentation.
Reply to
nospam

Strange, we use CRC in our packets. in an industrial environment, you have to expect some noise on the line.. a retry normally solves errors.. if it gets so bad that you have lots of retries and CRC's are failing then, you really have a serious problem.. Using a balanced twisted pair helps. parallel tracks on PCB also help.

Have a good day..

Reply to
Jamie

The panel maker clearly did no understand that two different timeouts are required in the slave, one waiting for the first character (possibly infinite) and a much shorter inter character timeout for the rest of the message.

Apparently the programmer had only one time out and in order to avoid timeouts waiting for the first character, the timeout was increased several times :-).

In practice, there are only a few critical timing issues with Modbus and they are related to slaves on 2 wire multidrop network.

Assuming slaves X and Y are on the same 2 wire bus with a master M and possibly other slaves. The master communicates with slave X by sending the request message. Slave Y also hears the request, but since it is not addressed to it, it will ignore it. Then it hears an other frame with the X address. Slave Y does not know if it is retransmission from the master to X or a reply from X (since you can not always determine this from the syntax of the message). Anyway, slave Y ignores this message too.

Slave Y must _reliably_ detect the end of that (apparently reply frame) from X and immediately after that be prepared to new commands, which might be addressed to Y.

The standard method requires that there is at least a 3.5 character silent time before the master sends the next frame and that each slave must be able to detect such short gaps reliably. If this gap detection fails for one reason or other, the reply from slave X and the master to Y request is appended into the receiver buffer. The CRC check will hopefully detect that something is wrong and no reply is generated.

Since the master did not get a response within timeout time, it resends the command, which is now processed cleanly, even with inaccurate end of frame detection. If the gap detection fails almost constantly, the master must repeat each request once after the timeout period, slowing the scan rate significantly, if gap detection on all slaves is bad.

If the master performs multiple operations with the same slave before switching to the next slave, the extra timeout only occurs, when switching from X to Y.

On a "4-wire RS-485" network, the slaves only hear master requests and there are pauses as long as the slave responses on the other pair (or master timeouts), so the gap detection is far less critical.

For point to point connections, the gap detection can be even more inaccurate, since a slow end-of-frame detection only reduces the throughput gradually.

If accurate timing is not available (or destroyed by inaccurate ethernet/serial converters), the slaves can always listen to all traffic on the 2-wire RS-485 bus and syntactically decode all frames (assuming the master does not use some vendor specific function codes, when accessing special slave Z).

Since you can not tell from the start of the frame, if a frame is a request to slave X or a response from X and hence these require a different decoding, you would have to first try to decode as the shorter alternative and after CRC checks and other heuristic checks determine if this was indeed the case or use the longer format and read more and try to decode it that way.

A third method is to perform the CRC check after each character is received and assume the end-of-frame was detected. However, this method gives surprisingly often premature end-of-frame detections. Thus, when you get a preliminary CRC match, you need to perform a heuristic analysis, if this really could be a valid message.

The last two methods may have problems when adding (or powering up) a slave in the middle of a transfer, since it may take a while, before the slave understands about frames and the first time the powered up slave is addressed, ther could be a timeout, which would force synchronization.

The syntax checker method suffers from unknown vendor specific function codes. The cumulative CRC method also suffer from these, as the heuristic checks can not be performed when a preliminary CRC match is detected.

Reply to
Paul Keinanen

project I am doing now.

Hmmm. I might have use for an I/O expander IF it is cheaper than another uC. Not sure which protocol i would use, i am looking at millisecond or less coordination.

Reply to
JosephKK

Kind of highlights the fact that the original PC used an 8048 or similar to talk to the keyboard. As did a lot of the (desktop / workstation / test controllers) computers of the era. The reason is the same.

Reply to
JosephKK

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.