19 lines for input or output

After 15 Jan 2007 firmwares here include the dl4huf driver that controls
all 19 gpio and led lines as input or output (and other modes)

Summary of I/O commands for reference
(based on the dl4huf README)
(see pull down menu (9) for pin connections)

NB if you want to try out the latest firmware with all the functions go to the pull down menu item 2
- the text and downloads below here are of historical interest! (For pre 15 Jan 07 files)

I will tidy this page up when I make them inputs too - CAN YOU HELP?!

Still pre-alpha level work in progress!

I have been in contact with ThKr1S who posted at norocketscience to whom many thanks.

He has modified the programs led.c and led.h that are found in arch\mips\am5120 in the Midge Kamikazi toolchain

He included them in his Amilda tool chain and built a fimware.bin file for his router that may be downloaded from the actual router at http://wasse632.speed.planet.nl/leds.php
There is a copy here for when his router is off-line.(10 LED version - see below for 15 version)

I loaded that and it worked fine. The 10 lights on my Sweex flash in a pattern controlled by a C program led_app.c.
Since TheKr1S uses the Edimax print server version of the board he also has 2 USB activity lights and they can all be controlled from his web page.
See his demo at http://wasse632.speed.planet.nl/leds.php

His notes imply that the three LEDs on the GPIO lines will also be controlled by his led.c driver and that the reset switch input will no longer allow a signal to be input.
However, I find the 4 GPIO lines can be used as inputs or outputs even when the test program led_app.c. is running the flashing LEDs

What I did

Open the led.zip file (also available here)
go to arch\mips\am5120 of your built Midge Kamikazi tool chain and replace the original files led.c and led.h with the one modified by TheKr1S

Rejoin the instructions at :-

Recompile the kernel (still being in
..../trunk/openwrt/build_mipsel/linux-2.4-adm5120/linux-2.4.32)
gmake

I did not do this -
mknod -m666 /dev/led0 c 166 0
since led0 166 0 is present in /dev anyway

I compiled the program led_app.c as per the note about my first "hello world" program in my instructions

I put led_app in the /bin directory on the USB stick - no other changes were made to the stick.
I loaded the new firmware into the Sweex.
All the Ethernet status LEDs came on and I could still control the 3 GPIO LEDs from the web page.

I typed led_app in the terminal and all the 10 ethernet lights started the flash routine!

20 May 06
The firmware from my toolchain including the new led.c drivers is

vmlinuz for RAM

midge-ttyS1-96-newLED-19may.bin for Flash

replace the www directory in /var/ in THE ORIGINAL STICK with this www directory for USB stick

24 May 06
The firmware from my toolchain including the "15 led" led.c drivers is

vmlinuz for RAM

midge-ttyS1-96-15LED-24may.bin for Flash

replace the www directory in /var/ in THE ORIGINAL STICK with this www directory for USB stick
(sorry - yet to have all 15 LED added on the web page)

You can use these even without connecting the 5 extra LEDs (of course)

23 Jun 06
4 lines in or out - 15 lines out - 2 serial ports
The stick now has a web page that demonstrate inputs and outputs using the first 4 gpio
- also various tests of sending strings to the second serial port - including non printing ASCI strings for my servo driver chip
(This is here as my backup of my current experiments - you are welcome to test and improve!)

complete USB memory stick contents........vmlinuz - for testing in RAM
firmware for saving to flash.........the modified S05mkdev script for etc/init.d/ on the stick (now included in the USB stick file system)

I have now discovered why I only had one live ethernet port at port3

I now have a hub of all 5 ethernet ports set to one IP (192.168.0.2)
This is how to do it

29 Aug 06 - see a summary here
- it seems there are some problems with the compressed memory stick files
My Fedora 5 GUI archive utility refuses to include empty folders in the compressed file.

These empty folders should be added to the stick -
dev
jffs
lost+found
mnt
proc
sys

One user has added the empty folders to the stick and it works OK.

As a Mac User I refuse to go to the command line if possible (!)
(Looks like the Fedora testers do not test their GUI compression tool)
So to work round Fedora deleting empty folders I put a dummy text file into each of them.
I opened the latest working USB memory stick in Fedora 5 - did Control-A to select all the files
then right clicked and chose "Create Archive" - then saved stick31aug06.tar.gz to a folder on the PC.

To test the new archive I took a newly formatted memory stick (ext2) - copied the archive file to it (I keep a backup on the stick)
I right clicked on this archive file and chose "extract here" - a folder full of the files for the stick is created.
I opened the folder, selected all the files and dragged them to the stick root - then deleted the empty folder.
The new stick files (stick31aug06.tar.gz) work fine on my Sweex with midge-ttyS1-96_23June.bin

The default address is 192.168.0.3

//led5on.c

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <sys/ioctl.h>
#include <errno.h>int main(int argc, char** argv)
{
int led_fd = 0;
int f_status = 1; led_fd = open("/dev/led0",O_RDWR);
ioctl(led_fd, 1, 5); // switch on led 5

}

//led_fd = open("/dev/led0",O_RDWR);
//ioctl(led_fd, command, param);

//three commands are implemented:
//0 : switch off the led indicated in param
//1 : switch on the led indicated in param
//2 : get the states of all leds. store the states in a uint32 pointed by param
//examples:
// ioctl(led_fd, 0, 2); // switch off led 2
// ioctl(led_fd, 1, 12); // switch on led 12compile as above and put into usr/bin on the stick

the script - - - pg-led5on.sh - - in cgi-bin/rs232ws#!/bin/sh
LED5ON=/usr/bin/led5on
echo 'You turned LED5 on'
$LED5ON

(and the same for off)

20May06
now see the C program led_set.c from TheKr1S for a professional effort
to whom many thanks

NB the binary /usr/bin/led_setnew in the current "distro" works as below
but /usr/bin/led_set does not, remove it from the stick and rename led_setnew as led_set
(the source led_set.c above works OK when compiled) - 18 Nov 06

compile as above
put into /usr/bin

in the terminal type, for example
led_set on 7
to turn LED 7 on

led_set off 11
turns LED 11 off etc etc

NB if the LED numbers above are set to 1 or 2 the GPIO lines 1 (pin151) or 3(pin149) are also switched.
so they can be controlled two ways,
The led_set program set to LED zero does not switch the power LED
not sure about the reset line

Using the four GPIO (General Purpose Input/Output) Pins

The ADM 5120 data sheet shows pins 148,149,150 and 151 to be GPIO

In the Sweex router pin 148 is wired to the Power Status LED
Pin 150 is wired to the reset switch and serves as a data input.

Pins 149 and 151 are unused and may be connected to external equipment
I connected to mine using the same technique as for the second serial port.

Once booted Midge does not make use of the power LED or the reset switch.
So with very little modification you can have four pins that can be inputs or outputs.

The russian site - http://adm5120.narod.ru/led.htm - reports:-

148 GPIO_0---240ohms---|>|------| Ground ----this is led0---(the power LED)
149 GPIO_1---|>|------470ohms---| 3.3Volts------------------------this is led1 edited 20 May
150 GPIO_2---|SWITCH|-----------| Ground-------------this is the reset switch
151 GPIO_3---|>|------470ohms---| 3.3Volts ------------------------this is led3 edited 20 May

|>| represents an LED
I chose 470ohms to keep the extra power demand low

A listing of the /dev directory reveals

crw-r--r-- 1 root root 166, 0 Jan 1 02:00 led0
crw-r--r-- 1 root root 166, 1 Jan 1 02:00 led1
crw-r--r-- 1 root root 166, 2 Jan 1 02:00 led2
crw-r--r-- 1 root root 166, 3 Jan 1 02:00 led3

So leds 0 1 2 and 3 may be controlled - Do not confuse these with the Ethernet status leds - read the data sheet

Control and Measurement

LED Status

To determine the status of an LED in a Telnet session type, for led0 as an example :-
cat</dev/led0
the router responds with one of:-
LED BLINK 1000
LED ON (actually it is off)
LED OFF (actually it is on)

Control the LED states - GPIO pins 148, 149, 151

to turn the power LED (led0) on
echo "LED OFF" > /dev/led0 (the GPIO pin 148 goes high [+3.3V])
to turn the power LED off
echo "LED ON" > /dev/led0 (the GPIO pin 148 goes low [0V])
to flash the power LED for 200 msec period
echo "LED BLINK 200" > /dev/led0

to turn the GPIO pin149 LED (led3) on
echo "LED ON" > /dev/led3 (the GPIO pin 149 goes low [0V])
to turn the power LED off
echo "LED OFF" > /dev/led3 (the GPIO pin 149 goes high [+3.3V])
to flash the power LED for 200 msec period
echo "LED BLINK 200" > /dev/led3

Similarly for GPIO pin151 LED led1

you receive
1
if switch is open (pin 150 high)
0
if switch is closed (pin 150 low)

(please - If any of the above are typed wrongly please email me)

Electrickery said
---------------------
From some simple experiments, I get the impression the lines can be used as input and output at the same time, with some limitations. When you put /dev/led2 (this is the pin connected to the reset switch) on, reading the switch via /dev/switch always returns 0, key pressed or not. With /dev/led2 off (echo "LED OFF" > /dev/led2), the actual key status becomes visible.
----------------------------------------

So to test the GPIO 1 to 3 as inputs do this -
echo "LED OFF" > /dev/ledx
mknod /dev/gpiox c 167 2
cat /dev/gpiox
you receive in the terminal window -
1 if input is high (i.e. pulled high by the internal current source - SEE BELOW *)
0 if input is low (pulled to ground by an external switch or transistor)

I have tested this on
GPIO[1] which is pin149 and called led1 in /dev set x=1 above
GPIO[2] which is pin150 and called led2 in /dev set x=2 above
GPIO[3] which is pin151 and called led3 in /dev set x=3 avove

What to wire them to
The data sheet says the GPIO lines are BIDIRECTIONAL
The circuit board connects the RESET line to ground (pressed) or leaves it floating (internal pull up)
When a pin is "ON" and able to drive an LED via a 220ohm resistor connected to +3.3volts it is at 0 volts
So even in the "ON" state you can safely short it to ground - * BUT NOT TO 3.3 volts
You detect the state of the switch in the "OFF" state when the pin, if not pulled to ground by your circuit, is at 3.3 volts.
(In that state there must be an internal current limit since it survives a short to ground!)

Please email me if you find printed confirmation of all of this - there is nothing in the my data sheet about output stage schematics and current limits.
In the GPIO section it also includes the ethernet status LEDs and says they are also BI (bidirectional) but in the LED section it says they are O (outputs)

The following worked for me - try at you own risk

GPIO[1, 2 or 3] line--------collector--NPN transistor--emitter----------ground
Connect transistor base to 2.2Kohm resistor then connect the other end of the resistor to LOW (0V) or HIGH(+3.3V or +5V)
or connect the output of an open collector logic gate to the GPIO line.
NEVER connect GPIO lines 1, 2 and 3 to HIGH via zero resistance
pull them low - but let them float high

NB! GPIO[0] (the power led line) IS DIFFERENT
In the GPIO section of the data sheet it says GPIO[0] (the power LED pin 148 called led0 in /dev) is "internal pulled up"
the others (1, 2, and 3) are "internal pulled down".
I think that means that in the "ON" state the 1, 2 and 3 lines are connected internally to the collector of an NPN transistor the emitter of which is connected to earth and is in a conducting state.
When the internal transistor is not conducting an internal current limited current source pulls the line up to 3.3Volts.
BUT FOR GPIO[0] EVERYTHING IS "UPSIDE DOWN"!
You can drive GPIO[0] from the collector of a pnp transistor with it's emitter connected to +3.3volts.
Connect the base to 2.2Kohm and apply high or low to the other end of the resistor.

GPIO[0] line--------collector--PNP transistor--emitter----------+3.3V NOT 5V
Connect transistor base to 2.2Kohm resistor then connect the other end of the resistor to LOW (0V) or HIGH(+3.3V) NOT 5V
NEVER connect GPIO line 0 to LOW via zero resistance
pull it high - but let it float low

There must be typos in the above!- please email me

Go to Project page