AVR TWI/I2C Interfacing

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I started a new thread because the old one was mostly no longer applicable. For background on what I'm doing, click here. Simply, I have an 8 conductor cable running to the end of a 40 foot track. At the end of that track, I need to have up to 5 sensors being able to be read, and up to 5 seven segment LED displays being driven, as well as +5v and Gnd to power everything down there. Simple, straight forward. uC is the Atmega324.

I'm looking at the SAA1064 to drive 4 seven segment displays. It's a TWI device, and seems pretty awesome. Two part question: is there a comparable device that can do 5 displays? Is there a comparable device for super cheap that can run a single display? I guess it's not a big deal, I just see it being a major waste of a chip like this to only drive one display (when it could be driving up to 4).

I'm looking for a decent chip to read my sensor inputs. Someone suggested the 74HC165 could do the trick for me, and can be interfaced with 3 wires. Not the same protocols, but it looks pretty simple to use, so that may not be such a big deal. People also seem to speak favorably about the PCF8574, which happens to be a TWI device.

This means that theoretically I would only need +5V, GND, SDA, SCL running to the end of my track right? Any suggestions? also, does anyone have an experience using CVAVR with TWI? I can't seem to find any useful examples or libraries. I'm fairly new to microcontrollers, so try not to be too harsh. :wink:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I2C is designed to be inter-integrated-circuit bus. So you would expect cable lengths of less than 0.5m

You are expecting to use 12m which is pushing it a bit. You also seem to have some fairly high switching currents in your ribbon cable if you are multiplexing LEDs.

The same argument would apply to SPI as well, but for a hobby project by all means try it. I would suggest that you re-initialise and update your display regularly.

CV has no library support for TWI. It does provide a perfectly adequate bit-bashed I2C library, as it does have for using a 74C165.

You can use a MAX7219 to handle up to 8 displays. It is a SPI device.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not use a 2nd AVR at the other end? And then just run a standard USART link between the two. The second AVR can easily manage all your sensors and displays. I imagine something like a tiny2313 would be more than capable.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using an Atmega324 as my main processor, and I have been advised to use another uC to run an LCD display 'backpack'. The Atmega only has two USARTS, one of which is already being used for the FTDI USB chip. Doesn't that leave me out of USART access, or am I able to do something else here? I was multiplexing the LED's with the DIP switches for configuration. If I use another 8bit expander (74HC165 or the PCF8574) then there's no need for me to multiplex the LED's.

Couple minutes of looking around gives me this. The datasheet says that it can boost ranges by up to 50m. Anyone have any experience / advice with buffer chips?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Anyone have any experience / advice with buffer chips?
We have used these before but only out to about 10m and at 200kHz. We used cat5 cable and also ran some other signals down it. Worked pretty well though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

peret wrote:
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.

That would be...mostly fine I think, since I was already planning on a separate chip for the backpack. A separate chip at the end of the track To handle the 5 lane sensors, and the 5 LCD displays, wouldn't be TOO much more tasking I suppose. Though what I can drive from a Tiny is a different story.

peret wrote:
Apart from that it's very simple, reliable and easily extended - it's the system used in every vending machine.

Your definition of simple and mine may be VERY different. I AM pretty new to this AVR micro controller business. Haha. I will do some digging / research into it tomorrow.

The sensors need to be able to be polled every 1/10000 of a second. That doesn't become a problem for a serial bus does it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I2C length depends on the capacitance of the cable - I don't have the specs to hand but the buffer chips got round that problem for me.

C. H.
-------------------------------------------------------------------
It's only waste if you don't use it!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jepael wrote:

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.

What do you mean by 'stiff'? I assume you mean 1% of better? Or no?
P82B715 Reference wrote:

-The loading at Lx/Ly due to the other standard buses is 133 pF each. For
just one remote module the cable capacitance may then be up to
(2660 - 133) = 2530 pF. For typical twisted pair or flat cables, as used for telephony or
Ethernet (Cat5e) wiring, that capacitance is around 50 pF to 70 pF / meter so the
cable could, in theory, be up to 50 m long. From practical experience, 30 m has
proven a safe cable length to be driven in this simple way, up to 100 kHz, with the
values shown. Longer distances and higher speeds are possible but require more
careful design.

This seems to allow Cat5e cable quite nicely, but I wouldn't get the data rate I require?

Peret: do you have more information on this multi-drop serial bus idea?

I'm a little worried that it may be getting too complex. The ability to read those sensors with a high degree of accuracy (as mentioned 10000 times / second or more) has me worried that any sort of separate chip solution is not going to work for me. My standard practice so far has been to write the value of the PORT with the loane sensors to a variable, and then to check it against each lane mask at my 'leisure' for a match.

I would LOVE to be able to drive an LCD display above each lane for placing, but am worried about pin count / timing accuracies. If only they made 10 pin ethernet cables. I could have my +5V, Lanes 1-5, GND, and some spare pins to make a serial bus to drive the displays.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

altontoth wrote:

What do you mean by 'stiff'? I assume you mean 1% of better? Or no?

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A theory. Tell me if this works / makes sense. My Cat5 cable has 8 wires. As previously mentioned, +5 and GND are mandatory. This leaves 6 wires available. Instead of trying to mess around with 100 different chips and methods of communications to get the speeds I need, I tie the 5 lane sensors directly back the the main controller, and use the single left over pin as follows:

A small controller, down at the end of the track, is able to control the 5 lane displays for finish order. It is also able to (potential future), display times of each lane on a second set of displays. The idea is that as soon as the main controller begins timing, it drives that spare pin high, which is tied to the second, smaller, controller. The second controller begins timing / ALSO monitoring the lane sensors ('listening in', if you will). As soon as it detects a lane seonsor has been crossed, it is able to assign a finish order and display it on the screen. IF it is timing as well as the main controller, then it can calculate race times for each lane and put them up on the small screens, while the main controller does its own calculations.

Good? Bad? Ugly? Confusing? Haha.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suppose I can have two 'modules'. The problem is that, for logistical purposes, the computer with the USB connection is usually at the head of the track, where the start gate trigger, start sensor, and a manual start switch are located, along with the potential multi-line LCD (stand alone usage). Hm. Some great many ideas to ponder. A question: If I do drive a pin high, are the delays between timing starting at the first controller and timing starting at the second controller going to be more than negligible? I doubt it, but would that difference calculate to a different number on displays at either track end with two separate controllers timing to 0.0001 second accuracy?

Edit: The other thing too is that this system is meant to be slightly modular / expandable. The displays at the end of the track aren't going to be part of it originally, just the lane sensors.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

altontoth, you need to do a bit of systems analysis. This is a race, right? You want to time each "runner" from start to finish. Can you think how odd it would be if in an athletic event, each runner in a race had his own timekeeper at the finish line, each with his own stopwatch? You want ONE timekeeper at the end, to time ALL the "runners", otherwise you greatly complicate matters by needing to keep all the timers synchronized. One single AVR at the end is the way to go, which kicks off with a single start signal and reads all the sensors. Then it can send the results back at its leisure for display on whatever hardware you like.