AVR Freaks

I would consider using one of your UARTs to drive a multi-drop serial bus. This can be just regular duplex serial with open collector drivers, or something a bit more reliable like RS485. You can hang everything on this, local display included, by giving every item an address. The drawback is that everything hanging on it needs to have some intelligence, since it has to recognize its address and only respond to its own commands. Apart from that it's very simple, reliable and easily extended - it's the system used in every vending machine.

Remember that VGA, DVI and HDMI cables have I2C in them, or at least the VESA DDC bus is based on I2C specs.

You can easily have a 20m HDMI cable, so I'd guess you can just try how well I2C performs if you just put long wires there.

Edit: However DDC is limited to 100kHz which means 10kilobytes/sec max or one byte per 10us.

Edit2: so there is no way you can poll your sensor 10000 times per second as that is the rate you can send bytes. Maybe you can go up to 400kHz bit clock, but still, 10000 times per second is not going to happen over I2C.

Buffer chips are nice and some even overcome the limits by converting the open collector bus to something wildly different cabling like two twisted pairs. I've only once used one, but not many manufacturers do them so usually there is no second source for a given chip.

However bus length and wire type affects capacitance, capacitance and pull-up resistors affect max speed, so there are a lot of variables.

By making the pull-up resistors as stiff as possible and choosing low capacitance cable you can determine max speed or max cable length by specification.

However even then you may relax the requirements made by specification as long as things work, if this is for your own use.

No. Not better in accuracy, just smaller in value. Normal limit for I2C devices is 3mA of sink current when pulled down to 0.3V or 0.4V volts. For 5V device this means the resistance cannot be smaller than about 1500 ohms because of the limit in current. Normally devices may be able to handle more current than the specification says is the minimum to get the voltage down, so you may be able to use smaller value resistors too. Okay, so what is the point? As the bus is charged to high voltage only through the resistor, smaller resistor value can charge the bus capacitance faster, thus allowing faster communications.

The buffer chips are capable of handling insane amount of capacitance. Then there are different speed specs of the bus, normally devices are up to 100kHz or up to 400kHz. Because a byte is transmitted as 9 bits, maximum transfer rate is 11111 or 44444 bytes per second. Taking the addressing of devices and start/stop conditions and initiating the reading, it takes several bytes on the I2C bus to receive 1 byte of data depending on how you must talk to devices.

So this just seems quite impossible to do. How about putting another AVR to the other side of the cable and use something like UART between them (logic level or RS232 level). Then have the slave AVR do the sensor polling and transmit something to the master if there is something that needs to be notified.

Since all of the important action is down at the end of the track, that's where the main time keeping controller should be, monitoring the track sensors directly. By definition, there's only one real-time event at the start of the track (the start), and it can be monitored directly over two wires. Nothing else needs to be done in real time. It doesn't matter if it takes half a second to compute the winner and update the displays, as long as the sensors are timed correctly.