Shell Command port also used by application - Embedded

This is a discussion on Shell Command port also used by application - Embedded ; On this Embest SBC2410-II that I have been working on with Linux pre-installed by Embest, there is a serial port that functions as a Shell Command port. I would like to use this port for my application without rebuilding the ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Shell Command port also used by application

  1. Shell Command port also used by application

    On this Embest SBC2410-II that I have been working on with Linux pre-installed
    by Embest, there is a serial port that functions as a Shell Command port. I
    would like to use this port for my application without rebuilding the kernel.
    Here is the original startup script in /etc/init.d/rcS:


    #! /bin/sh

    PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:
    runlevel=S
    prevlevel=N
    umask 022
    export PATH runlevel prevlevel

    #
    # Trap CTRL-C &c only in this shell so we can interrupt subprocesses.
    #
    trap ":" INT QUIT TSTP

    #SCSI modules

    #Input modules
    /sbin/insmod /lib/input.o
    /sbin/insmod /lib/keybdev.o
    /sbin/insmod /lib/mousedev.o
    /sbin/insmod /lib/evdev.o

    #Charactor modules

    /bin/ln -s /dev/fb/0 /dev/fb0
    /bin/ln -s /dev/vc/0 /dev/tty1
    /bin/ln -s /dev/sound/dsp /dev/dsp
    /bin/ln -s /dev/sound/mixer /dev/mixer
    /bin/ln -s /dev/scsi/host1/bus0/target0/lun0/part1 /dev/sda1


    /bin/mount -t proc none /proc
    /bin/mount -t tmpfs none /tmp
    /bin/mount -t tmpfs none /var

    /bin/mkdir -p /var/lib
    /bin/mkdir -p /var/run
    /bin/mkdir -p /var/log

    #Usb devices
    /sbin/insmod /lib/hid-core.o
    /sbin/insmod /lib/usbmouse.o
    /sbin/insmod /lib/usbkbd.o
    /sbin/insmod /lib/mmcsd_core.o
    /sbin/insmod /lib/mmcsd_slot.o
    /sbin/insmod /lib/mmcsd_disk.o


    /etc/rc.d/init.d/netd start
    /etc/rc.d/init.d/httpd start
    /etc/rc.d/init.d/leds start

    /sbin/ifconfig lo 127.0.0.1
    /sbin/ifconfig eth0 192.168.1.230
    /sbin/route add default gw 192.168.0.1
    /bin/qtopia &

    /bin/hostname -F /etc/sysconfig/HOSTNAME

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    What I would like to do is to modify this script so that the enabling of the
    /dev/tty0 port as a Shell Command port is optional - the option being determined
    by the pressing of a pushbutton on the board during bootup which I know how to
    read in an application. This brings up several questions:

    1. Is there a line in the above startup script that enables the /dev/tty0 port
    as a Shell Command port? Or is there a line I could insert to disable that
    port?

    2. Is there a better way to share a serial port between an application and a
    Shell Command port? I would need a way of interrupting the boot-up to take
    control in case my application is bombing. Without access to that serial port,
    I can't replace the application. Also my application needs to run the serial
    port at a different baud rate than the one the Shell Command port is currently
    configured for.


    Robert Scott
    Ypsilanti, Michigan

  2. Re: Shell Command port also used by application

    > I
    > would like to use this port for my application without rebuilding the kernel.


    hat are you trying to accomplish ? Use the serial port with an
    application (started from the command line) or with a daemon (that has
    no user interface ?

    With an application, can't you simply use the standard in and out data
    streams for the serial data ?

    With a daemon: if you don't start a shell (usually done by the init
    process, mostly by means of inittab) the serial port should be free for
    other use.


    If you want both (switching the serial port between a shell and your
    application, I suppose you need to modify (inittab and/or) the startup
    shell scrips so that the shell starts your application after other
    initializations. If your application exits the shell is ready to
    communicate again.

    -Michael

  3. Re: Shell Command port also used by application

    > I
    > would like to use this port for my application without rebuilding the kernel.


    hat are you trying to accomplish ? Use the serial port with an
    application (started from the command line) or with a daemon (that has
    no user interface ?

    With an application, can't you simply use the standard in and out data
    streams for the serial data ?

    With a daemon: if you don't start a shell (usually done by the init
    process, mostly by means of inittab) the serial port should be free for
    other use.


    If you want both (switching the serial port between a shell and your
    application, I suppose you need to modify (inittab and/or) the startup
    shell scrips so that the shell starts your application after other
    initializations. If your application exits the shell is ready to
    communicate again.

    -Michael

  4. Re: Shell Command port also used by application

    On Sat, 23 Feb 2008 11:50:49 +0100, Michael Schnell
    wrote:

    >> I
    >> would like to use this port for my application without rebuilding the kernel.

    >
    >hat are you trying to accomplish ? Use the serial port with an
    >application (started from the command line) or with a daemon (that has
    >no user interface ?


    The board has a frame buffer LCD and a matrix keypad that is scanned by my
    software. This provides the user interface to my application.

    The board actually has 3 serial ports. Only one of them (the Shell port) is
    fully buffered to RS-232 voltage levels. The other two serial ports are
    unbuffered logic level and inverted, coming directly from the microprocessor
    pins. In order to use either of the unbuffered ports I have to use an
    additional interface chip, like the Maxim MAX232, to convert them to real
    RS-232. So far I have been using one of those other ports to drive a laser
    engraving machine using a little interface board with a MAX232 chip on it for
    development. But for the production model I would like to eliminate the
    interface board and just use the one good RS-232 port that is currently used by
    the Shell.

    During development, I use the Shell port extensively, to load updates to my
    application, and to run the application. But during production my application
    will be launched by the startup script, and will not need the Shell port at all.
    So that is why I am wondering if I can use it to drive the laser engraving
    machine. But whatever I do, I want to maintain the ability to power-up in a
    mode where the Shell port does have control, because otherwise I would not be
    able to change my application if something goes wrong. Is there something
    equivalent to hitting "CNTL-C" during an MS-DOS boot-up to grab control away
    from an AUTOEXEC.BAT? If not, then my solution is to use a pushbutton on the
    board to condition the startup-script to either go directly to my application or
    go directly to the Shell port. I can write a tiny application that reads the
    pushbutton and returns and exit code to the startup script.

    >With an application, can't you simply use the standard in and out data
    >streams for the serial data ?


    I don't know. Aren't these streams ASCII formatted? The laser engraving
    machine needs to be driven by some absolute binary data that might not come
    through as standard output. I already have a non-Shell port working fine using
    open("/dev/stty1",...). I would like to do the same with the Shell port.

    >With a daemon: if you don't start a shell (usually done by the init
    >process, mostly by means of inittab) the serial port should be free for
    >other use.


    What should I look for to find this initialization?

    >If you want both (switching the serial port between a shell and your
    >application, I suppose you need to modify (inittab and/or) the startup
    >shell scrips so that the shell starts your application after other
    >initializations. If your application exits the shell is ready to
    >communicate again.


    This is risky. If my application has a bug and never exits, then I will never
    be able to get control of the Shell port to correct it. No, my method of
    getting to a Shell port must work by preventing the launching of my application.


    Robert Scott
    Ypsilanti, Michigan

  5. Re: Shell Command port also used by application

    On 2008-02-23, Robert Scott <---@---> wrote:

    > On this Embest SBC2410-II that I have been working on with
    > Linux pre-installed by Embest, there is a serial port that
    > functions as a Shell Command port.


    Do you have to log in on the port, or does a shell prompt just
    show up on it?

    > I would like to use this port for my application without
    > rebuilding the kernel.


    I don't see why you'd have to rebuild the kernel.

    > Here is the original startup script in /etc/init.d/rcS:


    [...]

    > What I would like to do is to modify this script so that the
    > enabling of the /dev/tty0 port as a Shell Command port is
    > optional - the option being determined by the pressing of a
    > pushbutton on the board during bootup which I know how to read
    > in an application. This brings up several questions:


    It doesn't look to me like that script has anything to do with
    what you're asking about.

    > 1. Is there a line in the above startup script that enables
    > the /dev/tty0 port as a Shell Command port?


    No.

    > Or is there a line I could insert to disable that port?


    I don't think that script is the right place to look.

    > 2. Is there a better way to share a serial port between an
    > application and a Shell Command port?


    Better than what?

    > I would need a way of interrupting the boot-up to take control
    > in case my application is bombing.


    By "take control" you mean log in on the serial port?

    > Without access to that serial port, I can't replace the
    > application. Also my application needs to run the serial port
    > at a different baud rate than the one the Shell Command port
    > is currently configured for.


    If you see a login prompt, there's probably a getty being
    started on that port. I don't know how your system is startup
    works , but that is often done by a line in a file called
    /etc/inittab. If you don't want a getty started on that port,
    comment out the line in /etc/inittab that starts it.

    If you do that, you're not going to be able to log in on that
    port.

    If you'r startup system has different "boot levels", you can
    edit the /etc/inittab file so that the getty is started only
    for certain boot levels (e.g. boot level 1). Then you could
    set it up so that your app is only started for a different boot
    level (boot level 3).

    Then you use your bootloader to tell the kernel what boot level
    you want -- that will determine whether a getty starts on the
    serial port or whether your application starts on the serial
    port.

    --
    Grant


  6. Re: Shell Command port also used by application

    Robert Scott wrote:

    > The board has a frame buffer LCD and a matrix keypad that is scanned by my
    > software. This provides the user interface to my application.
    >
    > The board actually has 3 serial ports. Only one of them (the Shell port) is
    > fully buffered to RS-232 voltage levels. The other two serial ports are
    > unbuffered logic level and inverted, coming directly from the microprocessor
    > pins. In order to use either of the unbuffered ports I have to use an
    > additional interface chip, like the Maxim MAX232, to convert them to real
    > RS-232. So far I have been using one of those other ports to drive a laser
    > engraving machine using a little interface board with a MAX232 chip on it for
    > development. But for the production model I would like to eliminate the
    > interface board and just use the one good RS-232 port that is currently used by
    > the Shell.
    >
    > During development, I use the Shell port extensively, to load updates to my
    > application, and to run the application. But during production my application
    > will be launched by the startup script, and will not need the Shell port at all.
    > So that is why I am wondering if I can use it to drive the laser engraving
    > machine. But whatever I do, I want to maintain the ability to power-up in a
    > mode where the Shell port does have control, because otherwise I would not be
    > able to change my application if something goes wrong.


    Sharing the port seems pretty dicey. Why not just swap them? Use the
    first port (with the RS323 level translators on the board) to always
    talk to the engraver and put the shell console on one of the raw TTL
    ports. That way, you use your level translator dongle for development
    and the product ships without any excess hardware. I'm sure someone here
    can tell you how to do that in linux but it doesn't sound like it should
    be hard to map the shell to whatever port you want.

    Bob

  7. Re: Shell Command port also used by application

    On Sat, 23 Feb 2008 09:51:06 -0800, Bob wrote:

    >
    >Sharing the port seems pretty dicey. Why not just swap them? Use the
    >first port (with the RS323 level translators on the board) to always
    >talk to the engraver and put the shell console on one of the raw TTL
    >ports. That way, you use your level translator dongle for development
    >and the product ships without any excess hardware. I'm sure someone here
    >can tell you how to do that in linux but it doesn't sound like it should
    >be hard to map the shell to whatever port you want.


    Perfect! I didn't know that was possible, but if it is, it solves everything
    with minimum risk. Now if I can just figure out where the serial port for the
    Shell is assigned...

    In answer to Grant Edwards:

    >Do you have to log in on the port, or does a shell prompt just
    >show up on it?


    It just shows up.

    >..I don't know how your system is startup
    > works , but that is often done by a line in a file called
    > /etc/inittab


    I looked and there is no file by that name in /etc or anywhere else.

    Here is what streams out of the Shell Console on power-up:.................
    .................................................. .......

    VIVI version 0.1.4 (root@localhost.localdomain) (gcc version 2.95.3 20010315
    (release)) #0.1.4 Sun Jul 2 18:43:06 EDT 2006
    MMU table base address = 0x33FBC000
    Succeed memory mapping.
    +---------------------------------------------+
    | S3C2410X USB Downloader ver R1.11 SEP/03/02 |
    +---------------------------------------------+
    FCLK=200MHz,DMA mode
    USB: IN_ENDPOINT:1 OUT_ENDPOINT:3
    FORMAT: +++
    NAND device: Manufacture ID: 0xec, Chip ID: 0x76 (Samsung K9D1208V0M)
    Could not found stored vivi parameters. Use default vivi parameters.
    Press Return to start the LINUX/Wince now, any other key for vivi
    Copy linux kernel from 0x00050000 to 0x30008000, size = 0x00100000 ... done
    zImage magic = 0x016f2818
    Setup linux parameters at 0x30000100
    linux command line is: "noinitrd root=/dev/mtdblock/0 init=/linuxrc
    console=ttyS0"
    MACH_TYPE = 193
    NOW, Booting Linux......
    Uncompressing
    Linux............................................. ................... done,
    booting the kernel.
    Linux version 2.4.18-rmk7-pxa1 (root@localhost.localdomain) (gcc version 2.95.3
    20010315 (release)) #1 Thu Nov 2 17:15:00 CST 2006
    CPU: ARM/CIRRUS Arm920Tsid(wb) revision 0
    Machine: Samsung-SMDK2410
    Security risk: creating user accessible mapping for 0x08000000 at 0xe0000000
    Security risk: creating user accessible mapping for 0x10000000 at 0xe0100000
    On node 0 totalpages: 16384
    zone(0): 16384 pages.
    zone(1): 0 pages.
    zone(2): 0 pages.
    Kernel command line: noinitrd root=/dev/mtdblock/0 init=/linuxrc console=ttyS0
    DEBUG: timer count 15626
    Console: colour dummy device 80x30
    Calibrating delay loop... 99.94 BogoMIPS
    Memory: 64MB = 64MB total
    Memory: 62360KB available (1545K code, 415K data, 144K init)
    Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
    Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
    Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
    Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
    Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
    POSIX conformance testing by UNIFIX
    Linux NET4.0 for Linux 2.4
    Based upon Swansea University Computer Society NET3.039
    Initializing RT netlink socket
    CPU clock = 200.000 Mhz, HCLK = 100.000 Mhz, PCLK = 50.000 Mhz
    Initializing S3C2410 buffer pool for DMA workaround
    S3C2410 USB Controller Core Initialized
    USB Function Character Driver Interface - 0.5, (C) 2001, Extenex Corp.
    usbctl: Opened for usb-char
    usbctl: Started for usb-char
    Starting kswapd
    devfs: v1.10 (20020120) Richard Gooch (rgooch@atnf.csiro.au)
    devfs: boot_options: 0x1
    ttyS%d0 at I/O 0x50000000 (irq = 52) is a S3C2410
    ttyS%d1 at I/O 0x50004000 (irq = 55) is a S3C2410
    ttyS%d2 at I/O 0x50008000 (irq = 58) is a S3C2410
    Samsung 320x240 LCD
    Samsung 320x240 LCD
    Console: switching to colour frame buffer device 40x30
    Installed S3C2410 frame buffer
    pty: 256 Unix98 ptys configured
    leds initialized
    touchpanel: installed
    S3C2410 Real Time Clock Driver v0.1
    block: 128 slots per queue, batch=32
    Uniform Multi-Platform E-IDE driver Revision: 6.31
    ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
    eth0: cs8900 rev K(3.3 Volts) found at 0xd0000300
    cs89x0 media RJ-45, IRQ 37
    PPP generic driver version 2.4.1
    Linux video capture interface: v1.00
    SCSI subsystem driver Revision: 1.00
    scsi0 : SCSI host adapter emulation for IDE ATAPI devices
    UDA1341 audio driver initialized
    NAND device: Manufacture ID: 0xec, Chip ID: 0x76 (Samsung K9D1208V0M)
    bon0: 00000000-00030000 (00030000) 00000000
    bon1: 00030000-00130000 (00100000) 00000000
    bon2: 00130000-03ffc000 (03ecc000) 00000000
    usb.c: registered new driver usbdevfs
    usb.c: registered new driver hub
    usb-ohci.c: USB OHCI at membase 0xe9000000, IRQ 26
    usb.c: new USB bus registered, assigned bus number 1
    hub.c: USB hub found
    port #1 suspened!
    port #0 alived!
    hub.c: 1 port detected
    usb.c: registered new driver usblp
    printer.c: v0.8:USB Printer Device Class driver
    usb.c: registered new driver ov511
    ov511.c: v1.48a for Linux 2.4 : OV511 USB Camera Driver
    usb.c: registered new driver serial
    usbserial.c: USB Serial support registered for Generic
    usbserial.c: USB Serial Driver core v1.4
    Initializing USB Mass Storage driver...
    usb.c: registered new driver usb-storage
    USB Mass Storage support registered.
    NET4: Linux TCP/IP 1.0 for NET4.0
    IP Protocols: ICMP, UDP, TCP, IGMP
    IP: routing cache hash table of 512 buckets, 4Kbytes
    TCP: Hash tables configured (established 4096 bind 4096)
    NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
    NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com
    yaffs: dev is 7936 name is "1f:00"
    VFS: Mounted root (yaffs filesystem).
    Mounted devfs on /dev
    Freeing init memory: 144K
    Using /lib/mmcsd_core.o
    Warning: loading mmcsd_core will taint the kernel: non-GPL license - Not GPL,
    Proprietary License
    See http://www.tux.org/lkml/#export-tainted for information about tainted
    modules
    Using /lib/mmcsd_slot.o
    Warning: loading mmcsd_slot will taint the kerneM: non-GPL licenMe - Not GPL,
    PrCprietary Licens/
    See http://Sww.tux.org/lkmlD#export-tainted for informationSabout tainted
    modules
    lot initialized
    Using /lib/mmcsd_disk.o
    Warning: loading mmcsd_disk will taint the kernel: non-GPL license - Not GPL,
    Proprietary License
    See http://www.tux.org/lkml/#export-tainted for information about tainted
    modules
    /etc/rc.d/init.d/OILFILMs start

    Please press Enter to activate this console. [30/Dec/2003:21:49:42 +0000] boa:
    server version Boa/0.94.13
    [30/Dec/2003:21:49:42 +0000] boa: server built Feb 28 2004 at 21:47:23.
    [30/Dec/2003:21:49:42 +0000] boa: starting server pid=32, port 80

    [root@Embest /]$



    Robert Scott
    Ypsilanti, Michigan

  8. Re: Shell Command port also used by application


    > I don't know. Aren't these streams ASCII formatted?


    The "streams" (op pipes) are just streams of bytes. If the shell starts
    a program (and is to wait on it to finish), it hooks it's input and
    output stream to the input and output stream of the program it starts.
    The origin / destination of theses streams can be (e.g.) serial ports,
    TCP/IP ports ("Telnet"), files or other processes (piping).

    -Michael

  9. Re: Shell Command port also used by application

    On Sat, 23 Feb 2008 22:05:29 +0100, Michael Schnell
    wrote:

    >
    >> I don't know. Aren't these streams ASCII formatted?

    >
    >The "streams" (op pipes) are just streams of bytes. If the shell starts
    >a program (and is to wait on it to finish), it hooks it's input and
    >output stream to the input and output stream of the program it starts.
    >The origin / destination of theses streams can be (e.g.) serial ports,
    >TCP/IP ports ("Telnet"), files or other processes (piping).
    >


    Thanks. That's good to know. But another reason for totally switching off the
    Shell console, or at least switching to a different serial port, is that on
    power up, the stream of reporting data that comes out of that port during
    boot-up may do bad things to the laser engraver machine that is connected to
    that port. I'm really looking now for a way to change the configuration so that
    the Shell Console starts out attached to /dev/ttyS1 instead of /dev/ttyS0

    Robert Scott
    Ypsilanti, Michigan

  10. Re: Shell Command port also used by application

    Good point.
    I'm sure that it's quite easy to do what you intend.

    Let us know about your results.

    -Michael

  11. Re: Shell Command port also used by application

    Good point.
    I'm sure that it's quite easy to do what you intend.

    Let us know about your results.

    -Michael

  12. Re: Shell Command port also used by application

    I just realized that I obviously can't totally eliminate any boot-up reporting
    from the /dev/ttyS0 port and switch everything to the /dev/ttyS1 port without
    rebuilding the VIVI boot loader. So the solution is probably more than just a
    configuration file change. Like it or not, I'm going to have to get out the
    JTAG interface and learn how to re-flash the boot loader. I did find somewhere
    on the Internet an indication that the VIVI boot loader passes to the kernel
    which port it should use for the Shell Console.


    Robert Scott
    Ypsilanti, Michigan

  13. Re: Shell Command port also used by application

    > I just realized that I obviously can't totally eliminate any boot-up reporting
    > from the /dev/ttyS0 port


    You should be able to define Kernel parameters in the configuration of
    the boot loader. here it should be possible to define the tty port that
    is use for Kernel startup output.

    -Michael

+ Reply to Thread