5 ms·

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 th

by dfc 13y ago

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.

joezydeco 13y ago
They're real. Freescale has the drivers in the Linux kernel at drivers/serial/mxc_uart.c if you want to see for yourself. The iMX UARTs are internal to the SoC, all you need is a line driver to bring them out of the board.
- dfc 13y ago
  Can you talk about what you used the serial ports for? Was the board you used the mxc on cheaper than this one?
  - joezydeco 13y ago
    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.
cnvogel 13y ago
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. http://ntpi.openchaos.org/pps_pi/ http://ntpi.openchaos.org/pps_pi/
- dfc 13y ago
  Your comment has enough "I assume" in it that it is clear that we have different very different opionions of the world.
  - cnvogel 13y ago
    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. http://vogelchr.blogspot.de/2011/10/thunderbolt-gpsdo-pps-signal.html http://vogelchr.blogspot.de/2011/10/thunderbolt-gpsdo-pps-si... (it's a pretty busy old Pentium) 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.

by dfc 13y ago

joezydeco 13y ago

They're real. Freescale has the drivers in the Linux kernel at drivers/serial/mxc_uart.c if you want to see for yourself. The iMX UARTs are internal to the SoC, all you need is a line driver to bring them out of the board.

dfc 13y ago
Can you talk about what you used the serial ports for? Was the board you used the mxc on cheaper than this one?
- joezydeco 13y ago
  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.

cnvogel 13y ago

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. http://ntpi.openchaos.org/pps_pi/ http://ntpi.openchaos.org/pps_pi/

dfc 13y ago
Your comment has enough "I assume" in it that it is clear that we have different very different opionions of the world.
- cnvogel 13y ago
  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. http://vogelchr.blogspot.de/2011/10/thunderbolt-gpsdo-pps-signal.html http://vogelchr.blogspot.de/2011/10/thunderbolt-gpsdo-pps-si... (it's a pretty busy old Pentium) 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.