Does anyone know if the "two RS232 serial ports" is a typo?
If they are real serial ports it sounds too good to be true. They would make great S1 ntp boxes with GPSDOs. I have a sneaking suspicion that line is a typo and/or they have some whacky interdependence on USB and the lines will be riddled with jitter.
I've programmed the iMX6 serial ports and they are true serial UARTs. No USB funny business going on at all. All ports can also run in RS-485 mode with the correct pin setup.
From the diagram on the company's website, it looks like it does indeed have two RS232 ports - although they both have the "ultra mini connector". See http://utilite-computer.com/web/home for a picture.
I am not convinced that it is not rs232 over USB. I can get a DB9 to USB adapter and plug a GPS into any computer. The PPS will come in over the USB port but the jitter will make the signal useless for timing applications.
I'm working on a project where a customer wants to update an old 16-bit control panel and make it run with a touchscreen, ethernet, and H.264 A/V playback. The control panel talked over RS-485 to a motor control board that sat somewhere else in the machine.
So I took the original code, recompiled it to arm-eabi, and stuck it into an NDK library on Android 4.04. So now I have an Android UI in the foreground talking over JNI to the orignal (unmodified) control panel code in the background. All I needed to do was switch the serial driver code a bit to handle the iMX's UART setup and pthread up the old UI event loop to let it run free underneath Android.
The board I'm using is a custom-designed PCB with an iMX6 Solo (single A9 core), but we used the SABRE-SD reference design from Freescale as our starting point. For proof of concept I used a Boundary SabreLite (now called BD-SL-i.MX6) for $199. That comes with two RS232 ports with DB-9 breakout connectors.
I don't think you'll find a cheaper design than this Utilite, although they really don't have full pricing online yet. I'm guessing the $99 is for the Solo or even SoloLite and the multiple core units will be significantly more than this.
They also don't say how much RAM is on the $99 unit. "Up to 4GB" says nothing about the specs on the cheapest one. I've found I need at least 256MB to run the FSL AOSP build in a minimal form.
You seem concerned about GPS as well, this Android build from Freescale contains a driver for the Atheros Orion GPS chipset over UART. So I think they have a lot you can work with out of the box.
Others have already reported that the asynchronous serial port ("RS232") is a "native" uart (so I assume properly timed interrupts are available).
But: For the serial data of a timing GPS receiver, that fact should be completely pointless if you settle to use one of the GPIO pins (of which I assume that board has several available for your use, or at least some that can be re-purposed from other chip-functions by changing the pin-muxes) for the timing critical PPS signal.
See here for an example to connect the PPS to a raspberry-pi GPIO pin and use that function with ntp, I assume that the example could be transfered easily to the i.MX of the particular board mentioned in this thread.
I see that I should check my posts for repeating figures-of-speech... .But let me try a second (and last time) to persuade you of my arguments! :-)
But I can assure you that it's ok to have a timing GPS connected to a USB serial port, as long as you feed the timing signal to an input that supports proper PPS timestamping. Here's a graph of a Trimble Thunderbolt PPS connected to a PC's parallel port. The serial port the device connects to is a USB dongle, but that's completely irrelevant for the PPS precision.
So, up to this point, there's no speculation about using a USB serial device, while the actual timing signal is connected elsewhere, and here's where I speculate only a little:
I have no reason to assume that the generic PPS on GPIO support would be any worse than the parport- solution, because the implementation is pretty much identical (recording a timestamp in a minimal interrupt routine), especially as it's been shown to work for a conceptually similar CPU.
One caveat from the I.MX6 datasheet: "One of the five UARTs (UART1) supports 8-wire while others four supports 4-wire. This is due to the SoC IOMUX limitation, since all UART IPs are identical." http://cache.freescale.com/files/32bit/doc/data_sheet/IMX6DQ...
The pictures appear to show one port on the front and one on the back (on the left side of each) that match what I find searching for 'ultra mini serial connector', so it doesn't look like a typo.
I looked a little more and it looks like you can plug a RS232 converter into the ultra mini ports but it does the serial connection over the USB bus. This makes the serial ports useless for feeding the computer the Pulse Per Second signal from the GPS. Oh well back to the GPIO pins on the BeagleBone.
If they are real serial ports it sounds too good to be true. They would make great S1 ntp boxes with GPSDOs. I have a sneaking suspicion that line is a typo and/or they have some whacky interdependence on USB and the lines will be riddled with jitter.