Multi Pic Control Board

[shawn]

Hello,
I've got a few questions if anyone could toss out some ideas or answers.

I am still in the process of building a modbus rtu slave controller and a I can foresee a problem. I have the software for communicating on the modbus 485 network working but only with a master and one slave. I am getting no bus collisions and all is fine. However I can see in the future that when I get multiple devices on the network my pic is going to be pretty busy dealing with network (bus) traffic and not have a lot of time for anything else.
So my thought was that I was going to have 2 pics on my control board, one for communication duties and one for running the control board (inputs, outputs, math, and so on). My thought was to have the pic for the communications receive bus traffic on 1 usart and transfer important data to the controller pic with the 2 usart. Problem is, that most pics don't have 2 usart and I did not realize this until after my idea.
I am going to use a 18F8722 for my controller pic and I have not decided what pic to use for my communication Pic. The reason why I want to use usart is because I understand pretty well how to use the on board hardware and interrupts for them. I realize that the 18F8722 does have 2 Usarts but the 18F8722 is a little bit over kill for just handling communications on the 485 network, and it is a bit expensive.
I searched awhile and saw an interesting thread on using entire ports to transfer data but could not rap my head around how to do this.

All I want to transfer between pics is first, an address of 1 word size and then a value(variable) of 1 word size. I don't need long strings of characters or anything like that just heres an address and heres the value. Or heres the address whats the value.

However I get this accomplished I would like to do it with on interrupts and hardware on the pic instead of commands like serout or serin. Stuff like that kind of leaves the pics hanging.

Any suggestions or Help would be appreciated. Links
Thanks
Shawn

[Charles Linquis]

I have found that saving money on hardware is the most expensive thing you can do. I use 18F8723's for some pretty mundane tasks, simply because by using that part, I don't have to worry about codespace, or speed, or what peripherals it doesn't have, and then spend time working around the limitations.

It can be rewarding to build a complete system with a device that has only has 2K of FLASH, but very few outside of this group will recognize your brilliance. I would just use both serial ports of a second 8722 and be done with it.

That said, I have recently become a fan of I2C, now that I have a good interrupt-driven slave working. I2C is handy because it doesn't generate an interrupt if the address doesn't match. It is also fast ~200Kbaud.

For device-device transfers using a port, you can use a method that I once used:
Connect two ports together, use one more line as a "ACK" line and two more to connect to each other's PORTB.0. When one device wants to speak
to the other, he checks the ACK line for a "high" (bus empty), places the data on the port, and toggles the interrupt (of the other device). The other device's ISR pulls the ACK line low, grabs the data, and then lets the ACK line go high (it is driven open-collector, and has a pullup). Whenever a device isn't sending data, its port is tri-stated. You can even use a couple more lines to indicate the type of data being transferred. It is a little messy, but it does work. I used it when I had an application similar to yours - that needed 4 UARTS, so I "lashed together" two 8723's.

[Jerson]

I have the software for communicating on the modbus 485 network working but only with a master and one slave. I am getting no bus collisions and all is fine. However I can see in the future that when I get multiple devices on the network my pic is going to be pretty busy dealing with network (bus) traffic and not have a lot of time for anything else.

First of all, you cannot get collisions in a well behaved modbus environment. An occasional hiccup may occur due to false interpretation by multiple slaves. Modbus RTU is typically a master-slave protocol and unless queried, a slave will not reply.

Usually there is only a single master and multiple slaves. This kind of load is easily handled by any PIC with a hardware UART and I do not think you need another comms processor for that.

If you are trying to do a peer-peer network which is also called a multi-master topology, you can anticipate collisions to be the norm. For this, you need to implement CSMA/CD on your PIC. Again, this is no big deal for a microcontroller running reasonable baud rates like 9600/19200.

For the small packet sizes you talk of, I do not think you need bother with the comms processor for your CPU.

This is my way of thinking. YMMV

Cheers