I suggest checking the schematic, available in documentation.
My understanding is that the rx and tx pins are brought directly out to the 3.5mm connector,
in which case your ftdi cable (aka sparkfun) should work fine.
No promises from my end, but I don't see how you can hurt anything.
Make sure you have a good ground wire, and try it.
Let us know if it works.
1 of 1 people found this helpful
No !! See page 16 of the 27 pages of the Galileo Schematic. There is a Maxim MAX3232 RS232 transceiver (U3B2) in line with the TX & RX lines from the processor. That is, the 3.5 mm jack is at RS232 levels so you cannot directly mate a FTDI CMOS/TTL level cable to this connector. Most FTDI cables are operating @ 3.3 volt levels so you will not be able to use this directly with this 3.5 mm connector (interfaces with UART1).
The other UART is UART0 (see page 21 of the 27 pages of the Galileo Schematic). However, this UART0 is connected to a level shifter (TXS0108E) which level shifts (without a direction pin) the 3.3 volt TX & RX lines to 5 volt swings. We have used this part in the past and had horrible quality of signal results. Have not checked this part for signal quality as applied on this design. Again, since the voltage levels are 5 volt swings, you must confirm if your FTDI cable is capable of supporting such levels - likely the cable will not work since it expects 3.3 volts. If the cable is reported to be '5 volt tolerant' then you will be fine. Otherwise, take caution.
Moving forward, we will offer a direct connect and affordable cable for the 3.5 mm to USB for the Galileo but this project is a few weeks out. Post back if you are interested. In the meantime you could build your own using a mix of parts.
Message was edited by: Kumar
Just checked the following technical details URL for your FTDI debug cable for the Raspberry PI: http://elinux.org/RPi_Serial_Connection and note the 3.3 volt swings for the TX & RX lines. So 100%, not recommended to use this cable with either the UART1 (RS232 voltage level swings = is charge pump based so likely will swing -6v to +6v = not suitable for your CMOS interfaced cable) or UART0 (5 volt swing) on the Galileo. Disclaimer: Reading some posts that the FTDI UARTs are 5 volt tolerant. If this is accurate, then yes, you can use with UART0 (the one with the TXS level shifter in series). However, not clear on how to redirect your debug info to this port - perhaps someone else can supply the details. Write back with specifics on which cable you own and ideally what the markings are on the FTDI chip if they can be read. We can ping FTDI (USA) for assistance to confirm the part is 5 volt tolerant before you attempt this project. They are great for tech support.
Thanks mon2. I had seen in the schematic that it was connected to an RS232 chip so didn't hook it up.
I have 2 USB FTDI adapters, both based off the Silicon labs CP2102 chip. i could also run it through an arduino serial ports if need be.
I tried it at 115200 but got nothing with CP2102, so will now be down to figuring out the software side of it. Sadly it does not seem as simple as changing the boot parameters passed in the grub.cfg.
But I can't easily debug what is going on without a serial cable, don't even know if it is booting sometimes when it does not appear on the network! I have an RS232 to USB adapter on its way and will throw together a cable for the galileo when the adapter arrives.
A FTDI to usb adapter though is a lot cheaper and easier though, so getting that working would be awesome.
See the above schematic for a suggestion how you may be able to use your existing cable (3.3 volt levels) to snoop the boot log data. Note also that your FTDI cables will contain the FTDI USB controllers (not SiLabs CP2102). They are both very strong in the market but FTDI is a bit more mature.
Based on your posts and Raspberry PI use of the same cable, you are operating at 3.3 volt swings. The above schematic, if you have the patience and are comfortable to solder to the small referenced traces should allow you to use the existing cable.
Connect your RXD pin + ground only to the Galileo and this idea should work. Cannot offer recommendations on where to mate the RXD pin as the boards are at work. Can review on Monday if you wish to proceed to test this idea.
I don't see anywhere to attach into the RXD line, soldering onto the trace on the chip would be very difficult, pin width is very very thin. From what i can see, the trace goes straight into the processor so no other points one could connect to.
Am also trying to avoid killing my board, which given my soldering skills (and iffy iron) would be a distinct possibility with parts that small.
I am still curious on the front of using UART0, I don't see a reason hardware wise it cant be used? Perhaps at a lower speed?
Am trying to get my head around all this for an upcoming hackathon (sponsored by Intel?) next weekend using Galileo and got my own a little early. Will need a solution by then, will be a room of developers asking the same question..
From the following webpage:
found the BSP Source code -> reviewed the grub.conf file as follows:
Have you tried to change the above to reads as ttyS0 ? Please do so and then monitor the TX & RX pins using your 3.3 volt USB cable to see if that works for you.
Also when you test this idea, please note the level shifter that is applied to the UART0 since the level shifting voltage is +5 volts.
I tried this with no success. Tried with screen on a mac and putty on windows, nothing.
I also tried just writing straight out to it once Linux had booted (and I had ssh via ethernet). I used
echo "hello" > /dev/ttyS0 with no success.
Nothing seems to be coming through for some reason? Might there be something else in software disabling the serial port?
Hmm. As soon as we can, will do some testing with the logic analyzer to see if any data spits out of the same UART0.
Q: What is a fair price for a cable for this Galileo unit for USB to 3.5mm RS232 ? We value your feedback.
We are in talks with our overseas cable mfr and wish to be fair yet competitive with the end product. This cable would directly connect to the 3.5 mm jack; 1.8 m in length. In noting the many reported issues on making your own custom cable and/or sourcing a compatible one, we wish to offer a finished product to support the Galileo Makers.
More products are in development to support this platform.
I have since tested the FTDI cable. Booted the Linux OS up (tested it with SPI version), plugged in via USB to laptop and uploaded a simple serial sketch (using Serial1)
I was then able to read the serial string coming from the Galileo like a normal Arduino, but with my FTDI adapter.
The decided to try it with the OS, using
echo hello > /dev/ttyS0
and listening on the other end, nothing.
Have just come back, done some digging and found this
It looks to be the key. It seems we have to first enable the UART pins. We also need to enable the 5v chip for the conversion, which we do with GPIO 4.
One I did that, poof, am now able to clearly communicate over /dev/ttyS0 via my FTDI adapter back to a normal computer.
Will do a few more tests to see if we can get this working with the OS console.
Also, on the RS232 cable, I wouldn't want to be paying more than £5-£7 max. Seeing as a normal micro USB cable can be purchased for £0.50. Wouldn't want to have it too expensive, especially seeing as the Galileo is aimed at education establishments and makers as opposed to businesses.
Intel would have a monopoly though on it, I have for example found it near impossible to find an RS232 to 3.5mm cable here in the UK without paying expensive postage from somewhere like the US or China.
Amazon lists a DB9 to 3.5mm cable for $2.95 plus shipping. This should work with any serial to USB converter cable, of which there are many:
Generally speaking, you should be able to reconfigure it to use the ttyS0 instead of S1 for Linux console by editing the grub.conf (for the earlycon, i.e. boot messages part) and /etc/inittab (for console itself) files. But I'm not sure how would you setup the GPIOs/mux respectively before the earlycon is initialized... Console may be simpler - you can insert the script, which would do the necessary adjustments before console is spawned.
Another thing to take care of probably would be clloader (wrapper, which receives and runs sketches from Arduino IDE and from the /sketch folder) - which redirects one of the Arduino Serial* objects to these pins and may block the necessary GPIOs, but this is relatively minor compared to the above (and after all it may not be blocking them at all)