Serial
port modifications
This is a Blog of my progress
- doing this forces me to make proper notes
- jump to the bottom for the latest story!
Objective
Be able to use ttyS0 (RS232
serial port connected to the header) to control external devices
without random terminal activity (terminal chatter) getting in the way.
Some early notes for my record
In the thread -
http://midge.vlad.org.ua/forum/viewtopic.php?t=377
Vlad says -
You can change rate by several methods:
quick: exec /sbin/getty -L ttyS0 9600 vt100
by stty (man stty on PC)
or by terminal program: minicom, picocom, microcom etc
(I think pppd also can set rate)
Thanks SergeyV for patch!
To the tool-chain I used to build the file -
that is used in the current "distro" created for myself and other external hardware user's I added SergeyV's patch -
and then created -
I modified etc/inittab (on the USB stick) as instructed in thread -
http://midge.vlad.org.ua/forum/viewtopic.php?t=407
to remove the getty lines as below at <<<<<
______________________________________________
# /etc/inittab
#
# Copyright (C) 2001 Erik Andersen <andersen@codepoet.org>
#
# Format for each entry: <id>:<runlevels>:<action>:<process>
#
# id == tty to run on, or empty for /dev/console
# runlevels == ignored
# action == one of sysinit, respawn, askfirst, wait, and once
# process == program to run
# now run any rc scripts
::sysinit:/etc/init.d/rcS
# Set up a couple of getty's
#console::respawn:/bin/sh
#::sysinit:/bin/sh
#ttyS0::respawn:/sbin/getty 115200 ttyS0
#console::respawn:/sbin/getty 115200 ttyS0 <<<<<
#ttyS1::respawn:/sbin/getty 9600 ttyS1 <<<<<
# Stuff to do before rebooting
null::restart:/etc/init.d/Kreboot
null::restart:/bin/sync
null::restart:/usr/bin/killall klogd
null::restart:/usr/bin/killall syslogd
null::restart:/bin/umount -a -r
# Stuff to do before rebooting
null::shutdown:/etc/init.d/Kshutdown
null::shutdown:/bin/sync
null::shutdown:/usr/bin/killall klogd
null::shutdown:/usr/bin/killall syslogd
null::shutdown:/bin/umount -a -r
______________________________________________
I sent the new firmware
to the Sweex and rebooted with HyperTerminal looking at ttyS0 (first rs232 port).
I saw the usual listing of activity - it got to the end of this listing as usual
then the terminal did NOT ask me to log in as root/midge.
I then typed
echo "Hello from router">/dev/ttyS0
in a Telnet session
and on HyperTerminal saw
Hello from router
So it can output text - I am not sure if I can send text in to the Sweex.
26
Oct 06
New compile
(using tool-chain with most settings as before plus as below)
I tried to do this as requested -
Start
with "make menuconfig" as usual, from the firmware directory
then go into "Kernel Configuration / Device Support"
and then into "Device specific configuration"
then edit the kernel boot options line and REMOVE "console=ttyS0"
save the new config, and build the firmware as usual.
But I saw
no reference to "console=ttyS0" or a kernel boot options line in my
menuconfig
(the one
in
http://www.sunspot.co.uk/Projects/SWEEX/files/notes.html
Block B - about half way down)
Patches included -
004-kernel-entry.patch
100-serial-rateselect-sergeyv.patch
serial.c - still set
to 9600 in irq:2 line
as requested, in
trunk/openwrt/build_mipsel/linux-2.4-adm5120/root/etc/inittab
BEFORE BUILDING the firmware the two GETTY lines were removed
like this:
#ttyS0::respawn:/bin/sh
#ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100
( I do not think this will affect my system since etc/inittab is on the memory
stick)
I edited drivers/net/adm5120sw.c and replaced
request_irq(SW_IRQ,
swdrv_ProcessInt,
SA_SHIRQ,
dev->name, dev);
with:
request_irq(SW_IRQ,
swdrv_ProcessInt,
SA_SHIRQ | SA_SAMPLE_RANDOM,
dev->name, dev);
done in main chain
The new firmwares are here -
vmlinuz for testing in RAM
TESTING
On boot the terminal gave a long string of data as usual but then went quiet
Send data out from the Sweex via ttyS0 to an external terminal device
in a Telnet session
I typed
echo "Hello from router">/dev/ttyS0
and on HyperTerminal saw
Hello from router
to suppress the trailing
newline character use
echo -n "Hello from router">/dev/ttyS0
Send
data from a terminal device via ttyS0 to the Sweex
in a Telnet session
I typed
cat /dev/ttyS0
and in that Telnet screen I could see all text typed into the Hyper-term
ttyS0 serial port session
To stop text being displayed in the Telnet window I typed Control-C in that window and saw the midge# prompt again
(The above also applies for ttyS1)
attempts to change the terminal
speed from a Telnet session failed
Sending
text from a webpage to a serial port
On the web
page on the Sweex I have a line
<a href="both_ports_out_test.cgi?page=string_to_ttyS0&string=0123456789">numbers 0 to 9</a>
both_ports_out_test.cgi is shown here
It runs the script pg-string_to_ttyS0.sh which first displays
both_ports_out_test.html
and then sends $string (in this case 123456789) to serial port ttyS0
- waits for a second for the PIC to act then displays all the PIC reply
(it uses the ramdisk to save the text and so not hit the Flash)
- and then closes the webpage
pg-string_to_ttyS0.sh #!/bin/sh |
31
Oct 06
Another compile
I now need to run two RS232 devices from the Sweex (a PIC and a radio link) both at 9600baud.
So I changed
the settings in build_mipsel/linux-2.4-adm5120/linux-2.4.32/arch/mips/am5120/serial.c
so that both ports run at 9600baud and did a new compile to create these files
vmlinuz for
RAM and midge_tty96_96_noconsole.bin
for FLASH
and just to keep things clean recompiled for ttyS0 115200 and ttyS1 96000
vmlinuz for
RAM and midge_tty115_96_noconsole.bin
for FLASH
So ONLY the baud rate differs in the above firmwares.
TESTING
I loaded midge_tty96_96_noconsole.bin
into firmware.
On reboot the boot loader message comes over at 115200baud as usual
and then all the boot reporting comes over at 9600baud. It gets to the usual
conclusion and then the terminal stays quiet and is available for control applications.
An odd thing
ttyS0 sends out text strings with CRLF added (as viewed in HyperTerminal).
If you then plug ttyS1 into the same HyperTerminal session
(same preferences settings) any string sent out has just a line feed added and
no carriage return.
I just want simple strings
so I use the -n option before the string
echo -n "Hello from router">/dev/ttyS0
and it stops both the CRLF and the LF at the end of the strings.
Another odd thing
I have an application on the Sweex that, when you click on a link, sends a character to a PIC via a serial port and then receives a reply and shows it on the webpage.
If I use ttyS1 the returned
chararacters are handled one by one.
If I use ttyS0 they only get accepted after a carriage return
(as tested on HyperTerminal so I think I am sending CRLF)
A work-around is to get the PIC to send CRLF but I would rather have both ports the same.
Observation
Connect ttyS1 to HyperTerminal
on a PC and open a Telnet session on another PC (or the same one)
type cat /dev/ttyS1
in Telnet.
Every character typed on the PC is seen in telnet. A return character causes
a carriage return but no linefeed
on both screens.
Kill
the connection with Ctrl-C in the Telnet session
Connect ttyS0 to HyperTerminal
on a PC and open a Telnet session on another PC (or the same one)
type cat /dev/ttyS0
in Telnet.
Every character typed on the PC is immediately
reflected back to the PC. (If HyperTerminal is set to echo characters
locally you see the character twice)
The string of characters typed in HyperTerminal are only
seen in the Telnet session after a return character is pressed.
A return character causes a carriage return and
a linefeed in both screens.
Do you know why this happens?
2 Nov 06
Both ports output data as they should with a C program
My anonymous email contact
(to whom all thanks!) sent me a C program that previously
I could only get to work with ttyS1.
I modified the original program (rs232io.c)
to run
ttyS1 (rs232io_ttyS1_96.c compiled
as rs232io_ttyS1_96) and
ttyS0 (rs232io_ttyS0_96.c compiled
as rs232io_ttyS0_96)
I put these into usr/bin on the memory stick
I typed
./ rs232io_ttyS1_96 testing
into a Telnet session and saw
testing
in HyperTerminal
and both the ports, ttyS0 and ttyS1, worked the same - you see exactly what
you type, no CR LF etc.
but
echo -n "Hello from router">/dev/ttyS0
does just the same - we need an input C program that goes in at a low
level.
Changing the baud rate line in the c program had no effect
3 Nov 06
Cracked it! - (by accident!) If I run rs232io_ttyS0_96.c from Telnet - ie type
rs232io_ttyS0_96 string
"string" goes out of the ttyS0 serial port and can be seen in HyperTerminal
- you just see the characters - no CRLF - just like the ttyS1 default.
I then I find ttyS0
stays in that state
so my
cat
< /dev/ttyS0 > /var/www/ramdisk/rsin &
line
in
pg-string_to_ttyS0.sh
(which stores an input string
- see above) works just as it does on ttyS1
The USB memory stick files
used on 3 Nov 06 (used with the .bin files of 31 Oct 06 above) are compressed
here as stick061103.tar.gz
(even more junk to get rid of - but all working on BOTH RS232 ports)
4 Nov 06
I now use
rs232io_ttyS0_96 to
send out all strings to ttyS0
- then the "receive string" I do after will always find ttyS0 in the
simple two way data flow state like the default state of ttyS1 (no repeats of
input characters, "wait for linefeed", etc)
This script uses rs232io_ttyS0_96
for output and
cat
< /dev/ttyS0 > /var/www/ramdisk/rsin &
to collect an input string before
sending it to the web page.
|
pg-string_to_ttyS0-get_reply.sh #!/bin/sh |
Who can change the baudrate without a re-compile!!!???
to be continued!!
USB serial port converter tests on the router
I bought a US232R-10 (FTDI chipset) from http://www.easysync.co.uk/
(Purchased for my MacBook Pro - works well on the Mac with the included driver)
I tested it on the router -
http://midge.vlad.org.ua/wiki/usb - bottom of page - did not work for me
BUT
The following compile creates a firmware that runs the USB serial adapter for a few minutes - then the router hangs.
cd /home/graham/kamikaze-200602050443/trunk/openwrt/build_mipsel/linux-2.4-adm5120/linux-2.4.32
make menuconfig
USB support --->
USB Serial Converter Support --->
<*> USB Serial Converter support
[*] USB Generic Serial Driver
<*> USB FTDI Single Port Serial Driver