If you want to connect to the Linux Serial console you will have to connect to the UART serial port. The RS232 shield does not connect to that port. It is used to serially connect to your Arduino sketches.
The UART connector on the Galileo board looks like an Audio Jack. You can buy or build a cable that will allow you to connect a serial cable to this connector.
There are also other methods for connecting to the Linux Console: Connecting to Galileo via Linux Console
1 of 1 people found this helpful
As far as I understand the schematics and description on the Cutedigi site, this shield actually converts the TTL serial pins to a "normal" RS-232 port with DB9 connector, so that should theoretically work.
@JohnM, you mentioned you've changed the port speed parameters in grub.conf, but I didn't see the notion of the port device name. IIRC, by default grub.conf has ttyS1, which is that RS-232 port with stereo jack as a connector.
If you haven't tried that yet, try changing that to ttyS0, which should be that port connected to pins (and subsequently to your Cutedigi shield). Let's see if something changes after that.
Thank you chofrock - I managed to connect my Galileo using the audio jack and seeing the boot process on my PC. The reason for the shield though is old RS-232 equipment is +/- 12 volts and could fry the board if connected without the shield.
I thought the shield was also a UART connection. I will test your idea though by writing a short sketch to open a serial connection and print "Hello World" and see if the old terminal gets it….
Thank you AlexT at Intel! I will also try your approach and modify the grub.conf file and change the device and see if I can get a Hello World emitted. Unless I have time later tonight, I will be traveling for the next few days but will follow up on this post with my findings on both approaches.
I appreciate the help very much!
I had time to conduct one experiment. I modified /media/realroot/boot/grub/grub.conf file and replaced ttyS1 with ttyS0 as shown below. One behavior changed, I did not see the boot process via the 3.5mm stereo jack, but when ultimately booted I got the Linux prompt via my PC with the stereo jack on PuTTY set to 9600 baud, but the RS232 terminal isn't getting any signal. Once booted is there some other configuration file that resets Linux access back to ttyS1?
Below is my grub.conf, set to ttyS0, and connects to my PC via the stereo jack using PuTTY set at 9600 baud...
When I return in a few days from travel I can try the sketch serial code experiment unless other ideas are offered… thank you… John
title Clanton SVP kernel-SPI initrd-SPI IMR-On IO-APIC/HPET NoEMU
kernel --spi root=/dev/ram0 console=ttyS0,9600n8 earlycon=uart8250,mmio32,0x8010f000,115200n8 reboot=efi,warm apic=debug rw
title Clanton SVP kernel-SPI rootfs-SD IMR-On IO-APIC/HPET NoEMU
kernel /bzImage root=/dev/mmcblk0p2 console=ttyS0,9600n8 earlycon=uart8250,mmio32,0x9000b000,115200n8 reboot=efi,warm apic=debug rw rootwait quiet
title Clanton SVP kernel-MassStorage initrd-MassStorage big-rootfs IMR-On IO-APIC/HPET NoEMU debug
kernel /bzImage root=/dev/ram0 console=ttyS0,9600n8 earlycon=uart8250,mmio32,0x8010f000,115200n8 reboot=efi,warm apic=debug rw LABEL=boot debugshell=5
Okay, that's interesting. The fact you don't see anything on the second serial port (the audio jack one) is good, that means the config change works. Now the fact that you don't see the console on the terminal attached to shield'd port is not good, but I can't think right now of any specific method of isolating where the problem is. Maybe just try to do something simple like echo test > /dev/ttyS0 after the system is booted, for starters.
Once booted is there some other configuration file that resets Linux access back to ttyS1?
Yes, there's another place to correct - /etc/inittab, look for ttyS1 there and try replacing with ttyS0.
Thank you all, so far no luck. I boot up my Galileo over SD card, connected to my PC via a 3.5mm Jack, and with the RS-232 shield connected to the terminal via a null modem cable, I have tried the below. I see the boot up process on my PC, but still no connectivity with my 9600 baud terminal which I know works as I can connect it to my Mac/Windows machines.
1. Simple echo test: echo test > /dev/ttyS0. Result: nothing appears to be happening.
2. Using $ dmesg | grep tty, I see both ttyS0 and ttyS1.
3. Using STTY -F /dev/ttyS0 I have verified baud at 9800 8N1.
4. I tried modifying /etc/inittab as well as realroot/grub/grub.conf to ttyS0 instead of ttyS1.
5. Separately, I created a short "Hello World" Arduino script, uploaded to the SD card (by removing the shield, connecting the USB micro cable using the Arduino IDE). I tried Serial.Print as well as Serial1.Print. Then powering down the board, installing the RS-232 Shield, then booting off the SD card to the last uploaded "hello world" script. No result on the terminal.
Some things I haven't tried:
1. Unplug the 3.5mm jack while communicating to the terminal - would this interfere with the RS-232 shield?
2. Is there something in the boot up process that disables ttyS0?
3. Should I make getty entries in inittab to enable ttyS0?
4. Should I be using a direct cable instead of a null modem cable? For connecting my terminal to Windows or Mac I use a null modem.
5. Try to modify other settings such as CTS/RTS, or XON/XOFF.
6. Keep googling, look for similar threads, of find ANY documentation on Cutedigi's RS-232 shield.
1 of 1 people found this helpful
Ok, there are several factors at play here, as I suspect, so let's start clean and do it step by step. I think that should be more manageable :-)
- Please get all the Linux tty settings in grub.conf and inittab back to their default values (feel free to ask if you don't recall what they are);
- Connect your shield to Galileo and your terminal to the shield. As far as cables are concerned - that pretty much depends on what type of the equipment (DTE or DCE) does that shield emulate, as far as I understand from this decription. Probably the easiest would be simply to try both with everything else unchanged;
- Boot Galileo and issue the initialization commands listed in this topic: Re: How do I access /dev/ttyS0?, either through SSH or serial console connected to that audio jack;
- Try to run echo test > /dev/ttyS0;
- Report back here if you see anything on that terminal connected to the shield (don't forget to try null modem and straight cables);
- Alternative to steps 3-4, you can try running the sketch I listed in this post (reboot Galileo if you ran the commands from step 3 already, they're not needed with the sketch and may even interfere): Re: Serial ports, theoretically you should see the message correponding to Serial1 in that sketch appearing every 5 seconds on yor terminal;
And we'll go from there.
Thank you again Alex for the above and beyond help!
1. I reset tty and grub.conf to original values by restoring the SD card with the Linux SD card image provided via Intel.
2. I connected the shield to my terminal and separately connected the 3.5mm stereo jack to my windows USB port, observed the boot process in PuttY and reached the Linux prompt.
3. I attempted the initialization commands. "echo -n 40 > /sys/class/gpio/export resulted in a failure, device in use. I was able to run echo out > /sys/class/gpio/gpio4/direction and echo 1 > /sys/class/gpio4/value. Question: Are these gpio modification required to properly activate the RS-232 cutedigi shield on Galileo such that communication is possible?
4. When I run the echo test to ttyS0, a small LED on the RS-232 briefly illuminates, it suggests signal is going to the RS-232 shield board. I also (previously, and separately) ran an Arduino sketch issuing writeln commands to serial1 with a 1 second delay and observe the RS-232 shield tiny green LED blink once per second, suggesting my code is running and signal is getting that far.
5. I attempted both straight and null modem cables. I validated 9600 8N1 on both Linux and the terminal machine.
Perhaps it's not the Galileo per se, maybe the problem is the cutedigi RS-232 shield and its operation with Galileo. My terminal, a 1978 era DEC Writer III, connects perfectly to either my Mac or Windows with a serial to USB converter cable. Yet somehow with the cutedigi RS-232 shield mounted on the Galileo, it's not achieving any evidence of connection. I don't have a scope so not sure how to diagnose or what to try further.
You are welcome :-)
Those "device in use" errors with gpios are because something else is using them. Most probably a sketch - try running "rm -f /sketch/*" command and then hitting the "sketch reset" button on Galileo, that should clean it up, IIRC.
The LED blinking is a good sigh, yeah. Now, I wonder if the DEC Writer you have requires something more than just TX/RX/GND to actually work? That shield has only these three wired and the USB-to-serial cable, which you say works ok, most probably has more, like those DTR and other pins actually connected. Quick googling didn't reveal much as to the namely requirements, unfortunately.
Let's then check the shield itself - try connecting to the shield using not the DEC but just the USB-to-serial cable, with your computer and let's see if you could see those messages coming. With software terminal emulator like Putty we can be sure nothing more than TX/RX/GND is needed.
thank you Alex. I have previously connected the DEC Writer using only TX/RX/GND (no flow control) to a PC, so it will work with just these three. I tried your test, but am not getting anything from the shield back to the computer, so my suspicion at this point is either the shield or some Linux configuration that is preventing the shield from emitting or receiving data. I might try another shield and see if I can get a different result. Another thought I had was to get a USB to micro-USB adapter and plugging my RS-232 to USB cable/converter into the Galileo's micro USB port itself, skipping the shield. The converter cable adjusts voltages down to TTL, so it seems like this might work? Thank you again for sticking with this so long! If I try a second shield and get a better result, I will inform this board.
Yes, it would help to try another shield. Researching on this issue I came across a message or two about broken Cutedigi shields, so the probablity it's just broken is non-zero.
I'd suggest you to continue trying with texting from sketch instead of messing up with GPIOs directly from Linux - that will ensure they're initialized properly and not taken by something else. My test sketch I referred to above could be a good starting point as it spits out messages both to the GS0 (USB serial==IDE Serial Monitor) and S0 (pins 0 & 1) serial ports.
As far as connecting the USB-to-serial converter to USB ports - not sure I get the idea in full, but in any case I don't think it will give you anything or at least not easily. If you think of doing the Galileo->USB host port->converter->terminal communication (instead of Galileo->pin 0&1->shield->terminal), then I guess you'll need to have a driver on the Galileo side and I'm not sure it has it (just don't know - haven't used serial-to-USB in that direction) and if it does the configuration may be non-obvious. My guess is that making the shield to work would be easier. But you're definitely free to try :-) even the wildest ideas sometimes work!
Thank you Alex. I ordered a new shield from a different supplier and will report back in a few days if that resolves the issue. John
As an update, I ordered a second shield from spark fun (RS232 Shield - DEV-11958 - SparkFun Electronics), but am still unsuccessful in establishing communications with my DEC Writer. For each RS-232 shield, I can see an LED blink very few seconds when I execute a sketch to print to serial1 with a delay loop. I now see a new blog from Sergey on configuring UART which differs a bit from the script suggested previously so I will his procedure that next!
In addition to that I'd also strongly suggest you to drop the DEC terminal for the moment and use the serial-to-USB converter to loop that back into your PC - to make sure everythign works before you connect the DEC. That way we will be able to eliminate DEC as a failure point.