PCA9564 parallel bus to i2c-bus controller

Projects Networking, Protocols, and Devices
1

Hello,

I am thinking about implementing a PCA9564 for a problem i am having with a system of arduino ATMega2560s. Basically, i am using this to communicate between 64 slave devices and one master device, however each slave device has 8 I2C slave I/O expanders (MCP23017). I am having alot of issues getting this to work, so my thought is to use the PCA9564 to add another I2C bus, that will go just from micro controller (ATMega2560) and the master...

If you have experience with a PCA9564, are similar device, if i would please get some starter code, or pointer, that would be helpful.

Thanks,
Mike Zylla

2

What exactly is the problem? How do you think this will solve it?

From your description, you are planning to swap the start of the I2C bus from the Mega to the PCA9564. I doubt that is where the problem lies. How much wire do you have (in total interconnecting all the slaves)? There is a maximum length and 8 and especially 64 slaves will exceed it.

3

adwsystems is right, I get the same feeling.

16 pins per MCP23017, 8 of them per slave and 64 slaves. That is 8192 pins.
Can you tell what your project is about ?
The most common way is to make something that is modular.
The I2C bus might not be the best choice for this. Suppose you want to reset all pins, that might take half a second.
Perhaps shift registers can be used or led strips or wireless modules.

Wiring 8192 pins can be a problem as well.

4

Here is some more information:

This project’s objective was using modern integrated circuits (ICs) to replace Multiplexer (MUX)logical boards in a circuit continuity verification machine. Specifically, the PCB design and BOM of replacement boards would be developed for production. The change was motivated by the need to detect voltages applied to a larger quantity of inputs than the original MUX boards could handle. The original design consisted of 64 boards connected in series with 160 input pins per board, all reporting to a single interface computer. The 10,240 pins formed a “bed of nails” array whose geometry is indispensable for the operation of the verifier machine necessitating the replacement boards to have a pin footprint similar to the originals.
Antiquated components within the MUX cards limited the number of pins that could be read simultaneously (fanout capability) to 1,500 pins. New uses for the verification machine require a minimum fanout capability of 2,500 simulations pins and requested additional functionality in the design.

The the MC, an ATMega2560 was choosen, using the Arduino to prototype.

Final design can be divided into four discreet sections: the replacement boards, a single master controlling board, communication between boards and the computer interface between the master controlling boards. Each of the replacement boards must be capable of voltage fanout reaching 2,500 pins and be able to detect voltage and source 5 volts at any of its pins on command. Each board is composed of one ATMega 2560 micro controller, which is in I2C bussed communication with eight MCP23017 I/O expanders. The microcontroller acts as a local master of the I/O expander, which are used to add 128 additional interfaces per board, reducing the number of necessary microcontrollers and by effect the cost per board. Furthermore, these I/O expander have high gate impendence, and low current draw, which enables the fan-out of the system to be some 300,000 pins. This protocol is a method of expressing all the read inputs pins as a single absolute number, Absolute Number = (Card Number * 160) + Pin Number + 1, where Card Number is bounded from 0 through 63. From a single integer the excitation status of all pins can be deciphered since every combination of simultaneously excited pins results in a unique value.

One attempted solution was SPI:
The communication strategy allows both the individual replacement boards to communicate with the master, spending data, and for the master card to communicate with each individual replacement board. SPI, or Serial Peripheral Interface bus was chosen for this task, as it is a synchronous communication interface that facilitates this form of communication, without interfering with existing on-board communication.

The master controlling board is responsible for interfacing between a network of 64 individual replacement boards, and the controlling computer. A key specification of this master controlling board is the ability to communicate with modern day computers, using a standard communication interface like USB. To reduce cost, and the number of items on the BOM, the master board is identical to the other 64 boards save for the USB port. The true difference is unique programming on this board that allows it to perform its unique operations. The function of this board is twofold. It takes information from all 64 individual replacement boards and communicates the complied information to a PC over an onboard USB port, and does the reverse, by sending commands from the PC to any individual board.
The interface between the PC, and the master controlling board is a PC based console application. This application requires the master controlling board to have clearly defined commands for operations for sourcing and reading across a given pin. These commands are hardcoded into the firmware of the master controlling board. A simple interface was built using a Java executable, which allows user inputs to control the operating mode of the entire system, send specific inputs and display specific outputs.
The final design phase was testing and validating this design. This was done by mocking up the design on a breadboard with MCP23017 and an Arduino Mega2560, to verify the hardware. In order to verify both the hardware and software this bread board design was tested through a variety of conditions. First voltage was applied to all 160 input pins, to verify they would read. Then voltage was a applied to random pins, to simulate any possible combination of text fixtures. Additionally, voltage was applied to a resistor place inline between two GPIOs.

5

What i was thinking of doing is using the PCA9564 to create another communication line, to isolate the MCP23017 I2C bus, and the rest of the circuit.

I don't think length will be an issue, as I2C can handle lengths up to 10M.

6

The I2C bus can do 0.5 meters.
0.5 meters for 64 Slaves, that is 8 millimeters per Slave :o

Thanks for explaining the project. That is a lot of pins. The I2C is a slow bus and in my opinion not suitable for this task. Using cascaded shift registers is more straightforward, with some input protection.

64 Slaves in software might be a problem as well.

Try to make the project flexible and allow to replace the Arduino Mega 2560 with an Arduino Due.

The I2C bus was invented by Philips to store the settings in a EEPROM inside a television on the same pcb board.

7

Another concept that may be missed is the highest I2C address is 128 (7 bit) or 1024 (10 bit). As I recall 7 bit address is much more popular.

I love the fact you are planning to blow your capability wide open, by a factor of 100 (?), to 300k pins. I2C is slow, to read in all that data will take some time. I suggest a two-for-one change to your plan. Add a layer of modularity, rather than trying to get all the pins back to one Arduino, bring them back to several smaller Arduinos then use a higher speed bus to transfer from the small Arduinos to a larger one. If you use a Mega you can use Serial1, 2, and 3 and pull back three at a time using Serial TTL.

Without using the PCA9564, how many slaves can you get to work? How many slaves do you need? Divide the second by the first to get the number of “reader” Arduinos you would need.

8

Another concept that may be missed is the highest I2C address is 128 (7 bit) or 1024 (10 bit). As I recall 7 bit address is much more popular.

I love the fact you are planning to blow your capability wide open, by a factor of 100 (?), to 300k pins. I2C is slow, to read in all that data will take some time. I suggest a two-for-one change to your plan. Add a layer of modularity, rather than trying to get all the pins back to one Arduino, bring them back to several smaller Arduinos then use a higher speed bus to transfer from the small Arduinos to a larger one. If you use a Mega you can use Serial1, 2, and 3 and pull back three at a time using Serial TTL.

Without using the PCA9564, how many slaves can you get to work? How many slaves do you need? Divide the second by the first to get the number of “reader” Arduinos you would need.

9

I thought I2C could do up to 10 meters, if clock rate was 9600 and had pull up resistor.

The boards are only 1.5 inches apart in the machine, and the master will be very close by as well, so total distance of I2C bus would be 1.4 meters.

What is the advantage of the Arduino Duo? Haven't heard of it before, though it is probably too late in the game to change now.

If I2C won't work, any other communication methods that you guys can recommend? I could do a big parallel cable, or ribbon, as well...

10

I think the may thing i am trying to fix is a mix of communication and multi-master issues.

So this is what works:
-1 Arduino ATMega2560 talking with 8x MCP23017 (it is the master of those devices)

-1 ATMega2560 master talking with 12 ATMega2560 slaves (over I2C).

The problem is, as i perceive it, is that we need to some how get the data (and pass commands) to the 64 sets of ATMega2560 micro controller, with 8x MCP23017 per set...

11

Instead of starting at the beginning, start at the end. Start with what is known or fixed and work from there. The arduino to use appears to be flexible.

It sounds like the final slaves are decided. How many can you get working at once? Is that enough? Probably not. So how can you connect a bunch of those “modules” (arduino-slave combos) do you need? How to connect them together to your Arduino Mega data concentrator becomes the next question. Preferably a method faster than I2C.

This could reduce the Arduino needed to a cheaper mini. Also the arrangement allows for multiple size systems using the same arduino-slave module and only having to reprogram or reconfigure the concentrator head.

12

An Arduino with 8 cascaded MCP23017 is okay at the end level. However, I think that shift registers are better than I2C devices.
The most used shift register is the '595' for shifting out: https://www.arduino.cc/en/Tutorial/ShiftOut and the '165' for shifting in: Arduino Playground - ShiftRegSN74HC165N.

Sometime a wireless option is choosen, even if the modules are only centimeters apart from each other. In this case I would not use a wireless option.

It is possible to have a circular chain-link with a serial port. Every Arduino reads the RX and sends it to TX, meanwhile filtering the messages that are for that Arduino board.
The disadvantage is that a software layer is needed and if a wire breaks, all the modules behind it can not be reached.
The advantage is the strong high/low signal, that is very reliable, and adding more modules is easy.
This should only be done with a hardware serial port. A SoftwareSerial would introduce too many problems.

With diodes or extra logic it is possible to have a single serial bus, instead of a chain-linked bus.

The RS-485 is an industrial standard for multiple nodes on a serial bus. Because it is a good standard, it is also used when the distance is very short.

Adding extra hardware makes a project less reliable. But since you are thinking about 64 modules (it is a lot) it can be more reliable with an extra layer in between.
Perhaps a bunch of Arduino Mega 2560 boards in the middle which control the lower level Arduino boards.

In my opinion, the best option is probably a single Arduino board and many modules with normal logic TTL chips (shift registers). Every module can have many shift registers, for example 32 chips for 256 input pins. The communication is the clock and data signals, like a SPI bus. The clock speed has to be lowered to make it reliable.
I think that modules with normal logic chips is the most reliable option. The digital signals are strong high/low signals, which is always better and faster than the weak open-drain I2C signals.
Since the Arduino Mega 2560 or Arduino Due have many pins, it is possible to have a number of different busses.

The more I think about it, the more I prefer a single Arduino board. When you have 64 Arduino boards, and you need to change a communication protocol for all of them, that is a lot of work. I also dislike the I2C bus for this more and more. What if you finished your project and it turns out it is too slow ?

13

I don't know that i get away from using a micro controller on each board, as each board is required to source and read all of the inputs. Since the maximum number of MCP23017 on a single board is 8 devices, that limits the number of GPIOs to 128. We need to 160 total, thus the micro controller is there to act as the brain box and read an additional 32 pins.

I tried some shift register, however had alot of issues with them to work. i did try 47HC589.....

I do like the RS-485 idea...

14

I missed it back in post #9. That is along the lines of what I was thinking. Can you get one Arduino to talk with the 8 MCP23017s?

Depending on how “much” of the Mega is used, you may be able to drop to a smaller less expensive Arduino model (such as a Uno, Nano, or Mini).

15

I can get the ATMega2560 to talk to the 8 MCP23017 I/O expanders.

The plan is to just use arduinos for the prototyping, and to actually build the embedded system on a PCB. the ATMega2560 is cheap enough, as a micro controller, they are about $10

16

The next step is to decide how many of those you need (12?) and how are you going to transfer the data back to the master Arduino. When selecting a data transfer method remember that you need to consolidate 12 I2C data rate sets. To minimize backlog and delays, the consolidating protocol should be faster (10-12x?) than the I2C data transfer rate.