5

Background: I'm trying to replace the electronics for a ice hockey scoreboard. The old electronics had the following issues:

  • It stop working. I have since discovered that a couple of diodes and capacitors had burnt out.
  • The controller was wired. We want to get rid of the wire running down the length of the rink.
  • The connectors for the controller gave lots of issues. I have had to re-soldered them countless times.

Photo of Scoreboard

The scoreboard is approximately 3.5 meters across.

I plan to stick a Raspberry Pi at the scoreboard. I plan to put a wifi usb dongle that support ap mode, and run hostapd. Scorekeepers can then connect to the Raspberry Pi via a web interface from a tablet/laptop.

I plan to replace the incandescent bulbs with LEDs, possibly OSRAM LR G5AP-BZCZ.

I originally planed to use i2c GPIO extenders. But I have since learnt that the wiring for a i2c bus need to be as short as possible. This would mean that I would need a lot of cabling from the gpios to the leds. Hence I arrive at my question.

Question: I would like to have AVR microprocessor for each 7 segment or each 2 7 segments who's job is a GPIO extender. These would be placed physically near to the LEDs. I would like to communicate from Raspberry Pi to the multiple AVR microprocessors over a common serial bus.

I have read that RS-485 can have multiple host on a bus. And as my communication is in one direction (output from the Raspberry Pi,) I hope that this can make the solution simpler.

Can the Raspberry Pi and AVR do RS-485 using there existing serial interfaces? What circuitry is needed to do this?

vicatcu
  • 22,499
  • 13
  • 79
  • 155
Gary van der Merwe
  • 151
  • 4

3 Answers3

5

There are standard RS422/RS485 transceiver ICs available

Here you'' find many pages of RS485 related ICs at Digikey

You can use standard asynchronous serial data using RS485 if desired. "Rolling your own" multistation code should not be too hard [tm], but it's an oft invented wheel - there will be many people already offering software (much for free) that does this.

The CAN bus lives on top of RS485, but is probably overkill for what you want.

Superb application note

AN-218 Implementing a RS-485 Multi-drop Network

This is targeted at ZBASIC but is liable to be of direct relevance to your application.

  • This application note describes how to interface ZX devices with a RS-485 multi-drop network. RS-485 networks are used by many industrial applications including process control, building automation and even the control of lights at a concert. A RS-485 header board and example hookup is provided to explain the simple hardware required to get started with networking ZX devices. The software included with this application note gives a sample application and a reusable set of APIs to send and receive messages on a RS-485 network. Here is a table of contents to help with document navigation.

Here you find ...

RS485 Multidrop Wiring Diagram & RS232 - RS485 comparison

They say -

  • RS485 is sometimes termed as RS485 Multidrop LAN since it can connect several devices in a LAN network environment. These devices are all connected to a single pair wire. Transmit and receive share the same two wires.

  • Officially the RS485 specification allows only 32 nodes (devices) on the LAN. However, I.C. manufacturers have developed RS485 drivers capable of allowing 128 to 255 nodes on an RS485 LAN. We use these next generation RS485 drivers in our products. This means that you can use our Converters and Remote I/O devices in more expansive situations.

enter image description here

Useful tutorial Wikipedia - RS485

Lots of ideas here from G's image search

Russell McMahon
  • 147,325
  • 18
  • 210
  • 386
  • This is probably the right category of approach, however I'd just point out that RS485 transceivers may not actually be necessary for these distances. Even if it were bidirectional the AVR's can tristate their serial transmit pins and the distance and data rate are not all that high. However, if the lighting elements themselves are considered as a potential source of noise, then the differential transceivers add a safety margin. – Chris Stratton Apr 30 '13 at 14:41
1

While others are addressing your posed question, I want to address your concerns about i2c. 3.5 meters is right under 11.5 feet. Looking at the board, thats probably only 10 feet (3m) from the rightmost digit to the leftmost digit. Now consider that you can put the RPi dead center, and a i2c master doesn't have to be at the beginning of a physical bus, that's really 5 feet on either side of the bus. Frankly, any paultry i2c bus can do 3m by itself. I've personally done 10m. And that's without going into bus extenders. You can get kilometers and miles using i2c buffers, or even double/triple a regular bus with i2c multiplexers.

By wiring the RPI in the middle of the bus, you get no issues with voltage drop at 1.5m. Using twisted pair (ethernet cat 5/5e) would be fine, but you can get even better performance with cat 6 (shielded twisted pair). At most, you might have to slow down the bus, but for your application? You don't need to update any given thing more than once or twice a second (the time clocks).

Even better, the RPI Model B, Rev 2 (the latest) has two real i2c buses on it. You could access the second bus as well.

In short, you can use i2c without a single problem. (Heck, depending on how the existing lights are wired, you probably don't even need to run the i2c bus along the length of the board.) Certainly less expensive or complicated as using multiple microcontrollers and implementing RS485.

Passerby
  • 72,580
  • 7
  • 90
  • 202
0

Since your communication is only from the Raspberry Pi to the AVRs, you can use RS-232. An RS-232 transmitter can feed several RS-232 receivers with no problems. You could probably also just use the logic levels direct from the Pi UART to the AVR UARTs, although using RS-232 levels may make debugging easiers.

Peter Bennett
  • 57,014
  • 1
  • 48
  • 127