Hi,

I want to have up 16 Peggy 2.3 boards mounted side-by-side to make both static and scrolling text and designs. Though it is alluded to in the Peggy 2 description that it's doable I can't find any information to make it happen.


What cables are needed to connect them?
Does each controller need to be programmed (sounds almost impossible to coordinate)?
Do / can the boards talk to each other?
How does each controller know where it is in the line and are all the LEDs considered at once or are they board specific?

Physically, the Peggy 2 tiles side-to-side without any gap, for as many as you care to assemble and fit together.

On the software side, that's another story. There are a number of different possible approaches, which will work with varying degrees of budget, difficulty, and performance. It also depends-- strongly --on what you want the final behavior to be.


To answer your questions in general,

>What cables are needed to connect them?
Depends on what interface you use. Generally, it will be hand wired, rather than using existing cables.

>Does each controller need to be programmed (sounds almost impossible to coordinate)?
Yes, each needs to be programmed. However, depending on what you're doing, coordination may or may not be an issue.

>Do / can the boards talk to each other?
The boards can talk to each other, over the I2C interface, but they are not pre-programmed to do so.

>How does each controller know where it is in the line
The boards are all identical. They won't know their order unless you (1) assign each a unique ID and (2) use that ID in the code somewhere.

> and are all the LEDs considered at once or are they board specific?
The LEDs are normally considered to be board specific. Depending on the architecture of your overall setup, you could arrange it such that the whole LED set is one contiguous grid.



Now, some possible approaches, and not an exhaustive list:

1. You can use the I2C interface to stream full-frame data to the full set of boards.

I2C is a multipoint serial protocol, meaning that you can use the same data bus to connect all of the boards together. You can probably hook 16 boards together this way with good success. However, the total data bandwidth is relatively low. I2C has a maximum bit rate of 400kHz in this context. It takes 625 bits of data to specify the state of the Peggy, whether each LED is on or off at a given moment. For 16-level grayscale data (4-bit), it takes 2500 bits of data.

So, to specify the full state of 16 Peggy 2 boards in monochrome takes 625*16 = 10,000 bits, meaning that you could refresh the full data set at a theoretical maximum of 40 Hz, probably closer to 20 Hz in practice. This is probably just fine for a lot of applications. In grayscale, closer to about 5 Hz, probably *not* acceptable, unless it's a static image that only needs to change every few seconds.

To implement this, you would need an external controller, e.g., a PC, and a high-speed I2C interface, probably a dedicated device. Each Peggy would need to be set up with I2C receiving code and a unique ID number such that it would only listen for and display data for that board.


2. You can use the I2C interface to send commands to the full set of boards.

For certain applications, it's possible to program each Peggy 2 to display data presented as a set of commands, rather than as a bitmap. For example, if you wanted to use the set of Peggy boards as a readerboard, displaying just text, then you only really need to send each board 1-3 letters that fit on the screen and the appropriate horizontal offset. As that's much faster to send, it would be easier to set up for high-speed operation.

To implement this, you would need an external controller, e.g., a PC, and a medium-speed I2C interface, for example, an Arduino board. Each Peggy would need to be set up with I2C receiving code and a unique ID number such that it would only listen for and display data for that board.


3. You can use the I2C interface to have one Peggy send commands to the rest.

For simple data (e.g., commands, line drawing routines, etc. ) that doesn't require high data rate or holding the entire 16-peggy LED grid contents in memory, you can skip the external controller, and have one Peggy in the group act as the controller.

To implement this, one Peggy is set up as the I2C master, and sends data to the others. The other Peggy boards would need to be set up with I2C receiving code and a unique ID number such that it would only listen for and display data for that board.


4. Independent serial data streams. (Highest speed streaming option)

Your data resides on a PC. From your PC, you have a high-speed serial interface (e.g., SPI, maybe direct USB ) to an external interface that processes the data stream from your computer into 16 independent serial data streams, each of which goes to a Peggy board. Each Peggy runs the same program, and they do not need to have separate ID numbers-- it's just that each Peggy is wired to the correct port to receive serial data in the right order.

This is the easiest version to implement on the Peggy side-- you can use existing code, or code with very little modification. However, it will need some unusual hardware to split the data stream into those independent serial parts. There *may* be hardware like this on the market already, or (if you're into that kind of thing) you could build one.


5. Independent programs.

If you just wanted to have a "slide show" of a small number of consistent frames of data, or a *very* short looping video clip (up to 280 frames of mono data or 70 frames of 4-bit grayscale), you could do it by storing the full program in the flash memory of each Peggy. Designate one Peggy as the master, to send a sync pulse once in a while to keep them all synchronized.



Again, these are just a few of the ways to do it. There are quite a few others, but the "correct" approach will depend on your requirements, skill, patience, and budget.