Arduino shields addressing and limits

Hello all,

I am very new to the Arduino game, although I have lots of experience with hardware programming at the 8086/80386 level. I have some extremely stupid questions that I didn't manage to find a clear answer online. Would you mind wasting a minute on these? Also I'm not sure I posted in the right part of this forum, apologies if not.

*** bus connectivity ***

The arduino main boards all have some kind of pins for connectivity with add-on "shields" (that I like to call daughter boards). The daughter board is alway stacked right on top of the main board, and most daughter boards have pins that transforms into sockets on the other side of the PCB. Hence I assume that one can stack daughter boards one on top of another. Is that correct?

If so, how are the different daughter boards addressed? Is it some kind of simple address+register protocol similar to the ISA bus that was very popular back in the '80? What is the limit of daughter boards that could be stacked on top of a single main board? Let's assume that I would like to build a router of of an Arduino board, by starting with an Arduino Uno and stacking up 4 ethernet "shields" on top of it. Would that work? Will the eth library figure out which interface is which?

*** hardware ***

My understanding is that Arduino boards come in a variety of shapes and colors, with each potentially using a different SOC. Hence I would think that there is no binary compatibility between the various Arduino boards, and everything must be recompiled specifically for the target SOC each time. Does it mean that distributing an Arduino program or library in binary form is simply impossible?

*** documentation ***

Finally, what would be the best source for documentation about the Arduino hardware architecture, bus protocols that it uses, etc?

Arduinos don't have address and data bus, only digital I/O pins. A couple of serial bus interfaces exist, with the most important UART, SPI and I2C, or derived industry standard networks (CAN...). SPI devices need a CS signal, I2C and OneWire devices have serial addresses, which are mostly factory determined. The most frequently used I/O chips are shift registers and port expanders, or specialized sensor, driver or coprocessor chips.

Stacking shields is possible only as long as the shields use different controller pins or one of the buses. More flexible are PCB modules that can be placed and wired as required. If configurable, the used pins have to be mentioned in the code, in a module driver constructor or in the setup() function.

Distribution of binaries does not make much sense. Either you distribute an entire system with a specific pre-programmed controller, or you supply the libraries in source code, so that everybody can make these work within his own system, on his own controller type.

See the controller data sheets for hardware details and protocols.

DrDiettrich:
Arduinos don't have address and data bus, only digital I/O pins.

Hello DrDiettrich, thank you for your kind and extensive explanations. It is clear to me now that Arduino uses only primitive I/O ports to communicate with its daughter boards. By looking at the PCB of an Arduino board I had noticed "A0", "A1", etc addressing lines, and that mislead me into thinking that some smart addressing might be going on here.

The A0 etc. are also usable as Analog inputs.

By looking at the PCB of an Arduino board I had noticed "A0", "A1", etc addressing lines, and that mislead me into thinking that some smart addressing might be going on here.

A0, A1, and so on are the analog inputs and are not related to any address bus.

Some Arduino models have address buses (p.e. Mega2560) but they are extremely seldom used in the Arduino world (i am not aware of any usage).

It is clear to me now that Arduino uses only primitive I/O ports to communicate with its daughter boards.

This is not completely correct. As DrDiettrich already wrote, all Arduino boards support serial buses (some of them, p.e. I2C are used in the PC world too) which are not that primitive.