19 lines for input or output
15 Jan 2007 firmwares here include the dl4huf
driver that controls
all 19 gpio and led lines as input or output (and other modes)
commands for reference
(based on the dl4huf README)
(see pull down menu (9) for pin connections)
status of all lines
lines (x = 0 to 22)
make a line output
echo "led switch 1" > /dev/gpiox
and only then do -
echo "led off" > /dev/gpiox
echo "led on" > /dev/gpiox
echo "led blink 1000" > /dev/gpiox blinks gpiox with 1s pulse
cat /dev/gpiox see "led on" or "led off" or "led blink xxx"
make line input
echo "led switch 0" > /dev/gpiox
cat /dev/gpiox - see 0 for off, 1 for on
= 8 to x = 22
(the original LEDs) there are other modes
echo "led switch 9" > /dev/gpiox see the ethernet line activity (set to LINK_ACT )
echo "led switch 13" > /dev/gpiox set to FLASH
input or output mode do -
echo "led invert" > /dev/gpiox
(Earlier notes stated that some lines were FIXED in invert or normal modes - in fact they can be controlled -
normal : on = high-level (3.3V) on the pin, LED is wired between GPIO and GND
used on Sweex/Edimax Power-LED
invert : on = low-level (0V) on the pin , LED is wired between GPIO an +3.3V
used on Sweex/Edimax Switch-LEDs)
To input to a gpio line do not connect zero ohms between the line and 0V or 3.3V
- put at least 470ohms in series (in case the line has been set to output mode in error)
NEVER connect to 5V directly
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
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
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
| 25th May
06 - I connected the 5 LED lines on the CPU that are not used - see this
TheKr1S kindly modified led.c again to include all 15 LEDs - the latest led.c is here
Rejoin the instructions at :-
the kernel (still being in
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
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
the www directory in /var/ in
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!)
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
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.
folders should be added to the stick -
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
#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
// 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
echo 'You turned LED5 on'
(and the same for off)
now see the C program led_set.c from TheKr1S for a professional effort
to whom many thanks
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
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
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
To determine the status of an LED in a Telnet session type, for led0 as an example :-
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)
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
if switch is open (pin 150 high)
if switch is closed (pin 150 low)
(please - If any of the above are typed wrongly please email me)
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.
to test the GPIO 1 to 3 as inputs do this -
echo "LED OFF" > /dev/ledx
mknod /dev/gpiox c 167 2
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 which is pin149 and called led1 in /dev set x=1 above
GPIO which is pin150 and called led2 in /dev set x=2 above
GPIO 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 (the power led line) IS DIFFERENT
In the GPIO section of the data sheet it says GPIO (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 EVERYTHING IS "UPSIDE DOWN"!
You can drive GPIO 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 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