Fred's Home Page

About me
csh is bad
Help out
KRoC/Linux (old)
occam upgrades
occam tutorial
Projects (PhD)
Quick gdb
UNIX crashcourse
WG / WGBuilder

Hardware projects

[ rs422-mark-II | distributed | silly-board | bits ]

Distributed fun -- Mark II

After a while, um, possibly years, of non-action on the RS422 bus, I've finally gotten around to re-building the whole lot. The following picture shows the general idea:

RS422 device bus

The RS422 bus operates in half-duplex. This makes the RS232/RS422 bridge slightly complicated, as the PCs use of the hardware flow-control lines isn't entirely helpful. In principle, before the PC sends data to the serial port, it will assert RTS and wait for the corresponding CTS signal. Unfortunately, the PC always keeps RTS asserted unless its FIFO becomes full, etc.

RS232-RS422 bridge

The solution is a bit hackish, but works. The software at the PC end doesn't use hardware flow-control directly, but instead uses the RTS line to indicate that it wants to transmit. This signal is used to select TX/RX on the MAX487 (RS422 interface). After the data has been written, this signal is cleared to put the bridge back into `receive' mode. This isn't terribly easy either, since Linux will buffer written data in the kernel. However, `tcsetattr()' can be used to ensure that the data has been written to the serial port.

The system is driven by some control software on the PC. The main function of this is to act as an interface between client applications and the device bus. In the old version (using Atmel AT90S1200's), devices were pre-programmed with their ID (programmed into EEPROM). The new devices (using AT90S2313's) have a hard-coded 4-byte `MAC' address, that is intended to be wholly unique. All of the devices in our house have addresses in the `80xxxxxx' range.

The structure of individual devices is mostly constant -- not much wiring is required for interfacing with the RS422 bus.

general device structure

When connected up this way, each device has 11 free I/O pins, including the two interrupt lines, that should be enough for most things. The ``test device'' has 8 LEDs wired up to `PORTB'. The ``remote IR remote'' uses `PORTB' to connect to an AT90S1200 that generates the IR carrier signal (36 - 40 kHz). One of the spare `PORTD' pins is used to switch the carrier signal into an IR LED.

The temperature sensor units are now self-calibrating, using a MAX4053 anlogue switch to select between 0.3v, 0v and the temperature signal. This feeds the voltage-to-frequency circuit whose output is connected to an interrupt pin on the AT90S2313. The control software that monitors the temperature devices (`s2c_tsensed') periodically recalibrates the devices. The self-calibration is intended to solve the problem of (mild) voltage-drop along the wire -- any device that needs 5v exactly should power itself locally. The second interrupt pin is also counted, but the control software doesn't do anything with this value, yet.

8-character display device

One fun device is the `4-character display'. This uses a DLR2416 to display up to 4 ASCII characters. The attached AT90S2313 holds a string of up to 44 characters that is scrolled across the display. Since only 7-bits of each character are useful to the display, the high-bit is used to `pause' scrolling. The display can either be scrolled, or be static. Scroll-speed and character offset are set-able. Here is a schematic for the 4-character display.

This has now become an `8-character display'. Think that'll do for now as the LED display units aren't that cheap. Any more width would require either an AVR with more I/O, or more logic on the board.

So, some software, etc:

Older stuff:

To assemble the AVR sources you'll need avrasm. Then download to the device using an appropriate tool. You'll probably want to edit the EEPROM file to change the `MAC' address. This is held in the first 4 bytes, followed by 14 bytes containing the device string, and 2 bytes containing the firmware version.

The remote IR transmitter isn't quite working at the moment, for whatever reason -- under investigation.. Other devices that still need to be built include the AVR programmer and `pulse counter' (for the electricity and gas meters). Also found some cute LCD modules on the RS website, at a more favourable cost than the VFD modules (although VFDs are extremely cute..), so might try one of these sometime. The AT90S8515 has enough memory to hold a reasonable message..

8-character display device

Here is a `photo' of the 8-character display device in action:

The various client utilities are used to interact with the devices. Currently, in this place, `s2c_list' produces:

    0    00000000  host device     0.1
    1    80010000  test device     1.0
    2    80030000  remote IR tx    1.0
    3    80020001  temp. sensor    1.0
    4    80080001  8char-display   1.0
    5    80020002  temp. sensor    1.0
    6    80020003  temp. sensor    1.0
         80090001  12char-dpy      1.0
	 80100001  16char-dpy      1.0

I'm still programming devices using my old/existing AT90S8515 that lived on the old RS422 bus. This 8515 is programmed using a normal PC parallel-port and avrprog. It should be noted that Atmel no longer `do' the AT90S8515, the `mega' version has relaced it. The AT90S1200 and AT90S2313 are still produced, though. I've got a few AT90S8515's left before I switch over to the ATmega8515 for this. Here is the relevant software for this stuff:

  • sermond.c (54.5k) PC-side control software for the old RS422 bus. Note, this sofware is a real hack, which is why I re-wrote it...
  • parprog.asm (31.6k) program for the AT90S8515 `parallel programmer'. This does various things: programs AVRs, interfaces with the PC via RS232 and the 8515's UART, talks to the RS422 bus from some other pins
  • parprog.eeprom (128 bytes) `parallel programmer' EEPROM
  • rs422code.asm (5.2k) this is some bit-banging RS422 interface code, needed by `parprog.asm'

More things will appear on this page as local development progresses..

Distributed fun

Not much real info here yet, but some will appear at some point, along with code, circuit diagrams, etc.

I've botched together a distributed device system, using RS422, some Atmel AVR's, Maxim MAX487E's and the bits to measure the temperature (sensor and V-to-F circuit).

The bus is managed with a 3-byte (42-bit) protocol. Because it's only half-duplex one device is the bus master and the others are all slaves (this can change dynamically however). Each bus device is assigned an ID in the range 0 to 126, and placed in-line on the bus. In the current setup, the bus-master is device 0 and the two temperature sensor devices are 15 and 17.

Sat on device 0 is an RS232 link into the SGI (only because the PC ran out of serial ports..). A bit of software talks to device 0, which in turn talks to the RS422 bus devices. The commands implemented so far are PING/PONG, READ-TEMP and AUX1 (to control 2 random LEDs on the temp-sensor boards). Ultimately, the software reports the temperature every few seconds to a file which ends up being graphed by MRTG. Here's what happened in the last 24 hours or so:

temperature graph

The blue line is the temperature in the room with the bulk of the kit/networking in it, the green "line" is the temperature of the front room, where telly, etc. lives.

So, some action shots. Here's device 0, with RS422 and RS232 lines coming out of it (amongst the blur somewhere):

rs422-dev-00 (host interface)

Then boards 15 and 17, which are essentially the same circuit (slightly differently arranged however). 15 is in the machine room, 17 is in the front room:

rs422-dev-15 (temperature) rs422-dev-17 (temperature)

Device 0 also has the parallel programmer for the little atmel chips (at90s1200/2313) on it, hence some of the excessive wiring. At some point they'll get commited to real soldered boards and put in little boxes, time and money permitting.

Silly board

blurry photograph of hardware
(the second processor is not plugged in here)

The board contains two Atmel AT90S1200A chips, one Maxim MAX233CPP chip, two Maxim MAX483CPA chips and two voltage regulators. The regulators are fairly obviously placed, they're at the top, just right of the middle. the AT90S1200A chips are placed vertically in the middle of the board. The MAX233 is sat on the left. The MAX483s are on the right of the lower AT90S1200A. The other connectors include two power connectors (top-left corner), one serial port connector (below power connectors), one 8-pin dual RS-422 connector (bottom-right) and a 24-pin bus connector. There are also various jumper blocks dotted around to enable the 12v rail and terminate/loop the RS422 lines. The whole thing cost me approx. 30 quid, and about 6 hours to solder it together. This is my version of the board (designed and built by me). Dave designed the predecessor, but it's serial interface doesn't work properly. Credit to Dave for finding the Atmel/Maxim chips used on the prototype and helping me with some soldering/electrical issues.


These are some images and stuff for the old board (pictured above). Most recent stuff is at the top of this page.

Atmel AT90S1200

Atmel AT90S1200A

The Atmel chips are the processors, they contain 1k of flash ram and 64 bytes of EEPROM each. This isn't masses, but enough to get a sensible amount of code in each of them. Since there is no real memory, the chips have to be programmed before hand. I've got a seperate programmer which runs off the parallel port and grabs power from the smaller of the two power connectors. The two chips are connected together via 4 pins on each. They're orientated so that one can trigger the external interrupt pin on the other, so some asynchronous communication can occur. The top chip drives the bus connector and the MAX233 RS-232 transceiver. The other one drives the MAX483 RS-422 chips and three LEDs (bottom-left). The chips can run at 16MHz, but I'm running them off the built-in 1MHz clock. Plans are afoot to build some clock-stuff onto the board, along with a reset button.

MAX233 chip

Maxim MAX233

This chip does the RS-232 serial communications. All it really does is convert between RS-232 levels and CMOS levels. It's nicer than the smaller MAX232 since it needs no external capacitors, which makes it easier to wire up. It still needs 1 uf decoupling capacitor though (blob on the left of the chip).

MAX483 chips

Maxim MAX483

The MAX483s drive the RS-422 serial line. This is a balanced line affair, so you can have up to 32 devices over about 1000 feet of cable. Maxim's RS-485 drivers can have 256 devices and 4000 feet of cable, but the bits are more expensive. Since I've only got this board at the moment, there are some terminating resistors and loop-back wires (selected with some jumpers).

Last modified: 2010-10-17 22:06:52.000000000 +0100 by Fred Barnes [ls] [plain]
Page generated: Sun Apr 28 11:39:32 2013
Valid XHTML 1.0! Valid CSS!