Which would be faster? I2C or Addressing?

I am not even sure this is the right forum to post this, but here it goes...

Right now for most "standard" Arduinos, the common practice is to develop shields and "stack" them for more functionality; this has led to interesting issues, the main one being the question of "what boards use what pins and is there a conflict" (ok, maybe that is two questions).

To get around this (but you don't see it much), you could just use I2C (or alternatively, SPI - but it would require more pins), and each board would have its own address. However, for some reason, you don't see this done much for most shields.

So what about an alternative scheme? What if you used several digital pins on the Arduino; let's say 13 pins. One of those pins should be one of the interrupt pins. Of the other 12, specify 8 as data, and 4 as "address" (16 possible addresses). With this scheme, you could stack up to 16 boards with an 8 bit data path, and an interrupt pin for reading purposes (a board could toggle it to indicate data was waiting to be read). Each board could have jumpers, pads, or some other method to set its address different from other boards that are connected.

Does the general gist of this scheme make sense...? Basically creating an addressable bus for the Arduino; I could also see having a shield on which there are "slots" into which cards could be plugged (maybe four slots), or has a cable to run to a "backplane" which has more slots. I could also see a multiplexing scheme used where you could have wider data and/or address paths. Of course, a library would need to be created to handle all of this...

A question, though, would be whether such a scheme would be faster or slower than just using I2C or SPI? Its just an idea I was rolling around in my head; I have no need or incentive to implement it any time soon, but I wanted to get people's thoughts on its feasibility and practicallity anyway...

:)

What you are describing is a standard address bus / data bus structure of microprocessors (as opposed to the micro controller that is the arduino).

The problem here is that the whole model of the arduino is PIN based rather than byte based. You can use direct port access but you can't get a whole byte free on a 168 so you have to split it up into at least two bytes. You then have and address decoder on the 4 bits address bus and a latch or tri state buffer on the data lines. This is standard multiplexing I/O, people have been using it for years. I2C is very slow with 100KHz clock pulses and 10 bits per transfer you can only get a maximum of 10K bytes per second data transfer and often slower. SPI on the other hand is much faster as the clock signal can be generated by the hardware and go at half the lock speed. In our case 8MHz. So with no start and stop bits to get in the way you can get just under 1M bytes per second transfer. Your addressing method is going to be of this order of data transfer but it will be a bit slower due to having two port accesses per byte.

The problem with a universl shield like this is that most shields make use of pins that have special hardware behind them in the arduino, like I2C uses analogue 4 & 5 and SPI is restricted to the pins 13, to 10 because that is where the shift register hardware is brought out. Similarly there is only two interrupt pins and then a pin change interrupt function, this means for a shield that needs them you are limited to the number shields you can have.

So the ports on the ATMega8/168/328 are only 6 bits wide? I knew port D was, but all of them? Maybe I need to go re-read the datasheet...

That kinda nixes a few other ideas I had, at least from a speed point of view...

:(

port B is also since 2 of its pins are used on the crystal

It is a basic limitation that any shield (other then proto-shields) will hardwire to certain I/O pins for their own purpose, therefore creating possible conflicts with other shields and/or taking up a processor internal hardware peripheral resource, even if the the resource is not being used by the shield.

About the only way I can think of that a shield designer might help with this 'problem' , it that all hardwired I/O pin connections to the Arduino pins be designed where you could easily cut traces and wire to other pins that are not in conflict with the rest of the system.

Lefty