Hi all,
I am programming an embedded SoC. It has a serial port on the development board which I can use by redirecting stdout to the serial port.
Since we moved to linux I had to find a tool for this: minicom. But I cannot get this working. I was able to configure the Bps/parity but the status stays offline.
Does anyone has any suggestions?
Thanks Kristof
-- Any errors in spelling, tact or fact are transmission errors.
What is a "SoC"?
So how about the specifics? Just exactly *how* are you connecting the serial ports?
Could be the cabling between the serial ports, or the configuration of minicom.
How is anybody supposed to tell you how to set it up without knowing at least something about what *it* is?
I can tell you that minicom is sometimes a little tricky to configure. Here's a proceedure that works:
1) Su to root. 2) Invoke "minicom -s". 3) Get the "configuration" menu by typing in two characters, ^A and then O. 4) Position the highlight on the menu list by using the up or down arrow keys and type a to select an option to configure. 5) You may not need to change anything in the first two areas listed, "Filenames and path" and "File transfer protocols". But look at them to see what options are available, for future reference. You do want to set the appropriate entries in "Serial port setup" and in "Modem and dialing" where at least you want to delete all of the modem init strings to avoid sending them at start up. "Screen and keyboard" probably do not need any changes. 6) Save the settings to either default, or to some named configuration, such as "port0" or perhaps use the device's name. 7) Exit minicom. 8) Exit root. 9) Invoke minicom, as "minicom" to get the default config, or as "minicom port0" to get the port1 configuration.Fire up minicom and see if it will talk to whatever you have connected to the serial port. With a modem it wouldn't make any difference what the bit rate is set to, as modems automatically adjust. But with some kind of an unknown device connected, you probably need to specifically set virtually every port parameter correctly to get it to work. You may have something you want sent as an "init string", but it certainly won't be the same as a modem would take, which is what minicom has by default.
-- Floyd L. Davidson Ukpeagvik (Barrow, Alaska) floyd@barrow.com
A "System On a Chip".
--=20 Josef M=F6llers (Pinguinpfleger bei FSC) If failure had no penalty success would not be a prize -- T. Pratchett
Minicom manual says offline/online relates to using Unix sockets. I use minicom to talk to our dev boards via ttyS0 and it works but status is always offline. HTH.
Neil
... "system on chip"
-- > What this country needs is a dime that will buy a good five-cent bagel.
... what type of serial cable are you using?
-- > Every solution breeds new problems.
How is that more informative that SoC?
What is it the OP is dealing with? Not in marketing terms, but in terms of his question about how to connect to it using a serial port.
-- Floyd L. Davidson Ukpeagvik (Barrow, Alaska) floyd@barrow.com
I suppose you are looking for a way to activate RTS/CTS Try looking at stty -rtscts or this
man stty
HTH Regards Marco Cavallini ============================================== Koan s.a.s. - Software Engineering (x86 and ARM) Linux and WinCE solutions for Embedded and Real-Time Software Klinux : the embedded distribution for industrial applications - Microsoft Windows Embedded Partner - Intel PCA Developer Network member Via Pascoli, 3 - 24121 Bergamo - ITALIA Tel. (++39) 035-255.235 - Fax (++39) 178-223.9748
On a sunny day (18 Jan 2005 00:33:26 -0800) it happened "Kristof Loots" wrote in :
You have had some good suggestions on minicom, however if you want to implement your own serial stuff for that board, something like this in C: (do a 'man stty')
FILE *pptr;
system("stty -F /dev/ttyS0 sane"); system("stty -F /dev/ttyS0 clocal cread -crtscts ignpar ignbrk 19200");
/* send argv[]1 to ttyS0 */ sprintf(temp, "echo %s > /dev/ttyS0", argv[1]); pptr = popen(temp, "w"); pclose(pptr);
Receiving may be similar... Perhaps from an other thread.. to avoid writing a polling loop..?
Minicom should work. I use mostly kermit for serial communication. Install kermit and then:
$ kermit set carrier-watch off set line /dev/ttyS0 set speed 38400 connect
Then control-\ C will escape you back into the kermit command shell.
You can put the commands into a file called .kermrc in your home directory and they will be automatically executed as you start up. tip and cu are other simple serial communication programs.
Petter
-- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
I don't find anything about that in the minicom manual.
Generally, "online/offline" is commonly a reference to whether the DCD modem control line on the serial port has been asserted. And a quick look at the source code for minicom confirms that is exactly what it indicates on the minicom status line.
But minicom also has another twist, that I had no idea existed until I looked at the source code. If the status line "Online/Offline" indicator is in lower case, that indicates the status is actually that of the DCD line. If it is in upper case, "ONLINE/OFFLINE", minicom thinks there is no true DCD line (as indicated by the configuration, see the "Modem and dialing parameters setup" menu, option R) and an emulated DCD is considered to be asserted if the minicom dial command has succeeded; DCD is then cleared by anything which would cause or indicates the connection to be terminated.
The essense of the above is that if you have a non-modem device on a serial port, and do *not* use the DCD line, the status line will always say "Offline", by default. If you set the configuration to indicate no DCD line, it will say "OFFLINE" unless you use a successful dial command to enable your remote device.
-- Floyd L. Davidson Ukpeagvik (Barrow, Alaska) floyd@barrow.com
... gives you the opportunity to do a search out on the web for more information :))
in a nutshell, they're doing embedded systems programming - the result of which (the software) gets burned to a chip which resides on some device's board. at least that's how i've done embedded programming. basically, you do your programming on a standalone system, such as a PC, then connect to the board/chip using a serial cable, and finally you burn the software to the chip across the serial cable.
-- > Everything is worth precisely as much as a belch, the difference
We have an FGPA (let's say a programmable chip) with a powerpc in it. We can write hardware code (comes in the FPGA) and software (runs on ppc). We can also use IO peripherals to talk to the world like serial interface, usb, LCD, ...
With the abbility to program hardware (fast execution), software (high flexibility) we can design nice systems. Hence "system on chip"
Kind regards, Kristof
-- Any errors in spelling, tact or fact are transmission errors.
We have an FGPA (let's say a programmable chip) with a powerpc in it. We can write hardware code (comes in the FPGA) and software (runs on ppc). We can also use IO peripherals to talk to the world like serial interface, usb, LCD, ...
With the abbility to program hardware (fast execution), software (high flexibility) we can design nice systems. Hence "system on chip"
Kind regards, Kristof
-- Any errors in spelling, tact or fact are transmission errors.
We have an FGPA (let's say a programmable chip) with a powerpc in it. We can write hardware code (comes in the FPGA) and software (runs on ppc). We can also use IO peripherals to talk to the world like serial interface, usb, LCD, ...
With the abbility to program hardware (fast execution), software (high flexibility) we can design nice systems. Hence "system on chip"
Kind regards, Kristof
-- Any errors in spelling, tact or fact are transmission errors.
That won't affect minicom at all, as it does its own termios configuration.
-- Floyd L. Davidson Ukpeagvik (Barrow, Alaska) floyd@barrow.com
That *still* isn't providing useful information concerning the question! Except for the last phrase, "finally you burn the software tot he chip across the serial cable", it has no significance.
The information needed is *what* the device is that is connected to this serial cable. Is it a full fledged UART? Or does it emulate one sufficiently that we can act as if it is a UART? Is it a modem? Does it take some specific set of commands, require initialization? Is it configurable, or does it have some odd set of defaults (the number of times I've seen folks asking how to get a serial line to work at 14.4kbps because some fool device is actually locked at that speed is just amazing!)
Other details need to be given too. Such as just what kind of a cable is this "serial cable"? Is it commercially manufactured or home grown, and how many of the RS-232 leads are implemented?
Otherwise, we're all just guessing at how to configure minicom or anything else.
-- Floyd L. Davidson Ukpeagvik (Barrow, Alaska) floyd@barrow.com
That would probably not work _within_ minicom...
Start with the things that Floyd said, but without your board connected. Instead make a short between Pin 2 & 3 of your serial Port (at the PC and afterwords at the end of the cable). And make sure that you have "NO" on both 'Hardware-Flowcontrol' ans 'Software-Flowcontrol' in the "serial port setup" menue. Those are the defaults, but better be sure... Then, you must be able (in the main window) to press some keys and see them coming back on the screen. And 'not' to come back if you open the short.
If not, the fault is on the PC side:
- is the serial port enable'd in the BIOS?
- the ports COM1 and COM2 in DOS-Speak are named ttyS0 and ttyS1 in Linux-Speak... Linux _is_ case-sensitiv...
- is the motherboard of ATX-Type OR did you use the cables that came with the board? => there are 2 or more versions of those!
Just guessing, Holger
We have an FGPA (let's say a programmable chip) with a powerpc in it. We can write hardware code (comes in the FPGA) and software (runs on ppc). We can also use IO peripherals to talk to the world like serial interface, usb, LCD, ...
With the abbility to program hardware (fast execution), software (high flexibility) we can design nice systems. Hence "system on chip"
Kind regards, Kristof
-- Any errors in spelling, tact or fact are transmission errors.
We have an FGPA (let's say a programmable chip) with a powerpc in it. We can write hardware code (comes in the FPGA) and software (runs on ppc). We can also use IO peripherals to talk to the world like serial interface, usb, LCD, ...
With the abbility to program hardware (fast execution), software (high flexibility) we can design nice systems. Hence "system on chip"
Kind regards, Kristof
-- Any errors in spelling, tact or fact are transmission errors.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.