Thread: How to get this to work on an ARM processor?

I looked at that, but the only builds were for the x86 and a Windows CE ARM processor. I didn't think I could compile it for the Sheeva ARM so I went out and found an open source FTDI library and built it.


Here's the libftdi description:

A library that talks to FTDI's FT232BM, FT245BM, and FT2232C type chips, including the popular bitbang mode.

libftdi project is a library that talks to FTDI's FT232BM, FT245BM, and FT2232C type chips, including the popular bitbang mode, using libusb.
What's New in This Release: [ read full changelog ]

· C++ wrapper: Reopen the device after calling get_strings() in Context:pen()
· C++ wrapper: Fixed an inheritance problem
· C++ wrapper: Relicensed under GPLv2 + linking exception
· Support for FT2232H and FT4232H
· Support for mingw cross compile
· Python bindings and minor autoconf cleanup
· Code cleanup in various places
· Fixed ftdi_read_chipid in some cases
· eeprom decode function and small cleanups
· cmake system improvements
· Fix compilation in -ansi -pedantic mode

I plugged my generic NMEA GPS into the USB port. I usually uses the FTDI USB to serial bridge in Windows. The Sheeva does seem to recognize that it is plugged in:

Code:

bugbyte@iPlug:/dev$ ls
MAKEDEV  log        pts    random   tty16  tty31  tty47  tty62  ttyp8           vcs
audio    loop0      ptyp0  rtc      tty17  tty32  tty48  tty63  ttyp9           vcs1
block    mapper     ptyp1  shm      tty18  tty33  tty49  tty7   ttypa           vcs2
btns     md0        ptyp2  snd      tty19  tty34  tty5   tty8   ttypb           vcs3
bus      mem        ptyp3  sndstat  tty2   tty35  tty50  tty9   ttypc           vcs4
cesa     mtd0       ptyp4  stderr   tty20  tty36  tty51  ttyS0  ttypd           vcs5
char     mtd0ro     ptyp5  stdin    tty21  tty37  tty52  ttyS1  ttype           vcs6
console  mtd1       ptyp6  stdout   tty22  tty38  tty53  ttyS2  ttypf           vcsa
core     mtd1ro     ptyp7  tty      tty23  tty39  tty54  ttyS3  urandom         vcsa1
crypto   mtdblock0  ptyp8  tty0     tty24  tty4   tty55  ttyp0  usbdev1.1       vcsa2
dsp      mtdblock1  ptyp9  tty1     tty25  tty40  tty56  ttyp1  usbdev1.1_ep00  vcsa3
fd       net        ptypa  tty10    tty26  tty41  tty57  ttyp2  usbdev1.1_ep81  vcsa4
full     null       ptypb  tty11    tty27  tty42  tty58  ttyp3  usbdev1.2       vcsa5
initctl  port       ptypc  tty12    tty28  tty43  tty59  ttyp4  usbdev1.2_ep00  vcsa6
input    ppp        ptypd  tty13    tty29  tty44  tty6   ttyp5  usbdev1.2_ep02  xconsole
kmem     psaux      ptype  tty14    tty3   tty45  tty60  ttyp6  usbdev1.2_ep81  zero
kmsg     ptmx       ptypf  tty15    tty30  tty46  tty61  ttyp7  usbdev1.2_ep83

When I run dmesg, I get:

Code:

USB Universal Host Controller Interface driver v3.0
usb 1-1: new full speed USB device using ehci_marvell and address 2
usb 1-1: configuration #1 chosen from 1 choice
usbcore: registered new interface driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice

I'm still sorting through gpsd to see how to read the NMEA string, so I'm not 100% sure it's working yet.

I'm still sorting through gpsd to see how to read the NMEA string, so I'm not 100% sure it's working yet.

Bust out xgps if you have it, or cgps, both come with gpsd. So long as one of *them* works, the obdgpslogger will work.

If you can't figure out how to launch gpsd, the easy way is

Code:

gpsd -N /dev/{your-gps-device, probably ttyUSB0}

Now's a great moment to try X forwarding over ssh, if you haven't already; ssh from your linux box to your sheeva, start gpsd listening on the relevant port, and type "xgps". You *should* see a graphical thing appear on your linux screen. If not, it's a few minutes futzing to make it work.

Gary (-;

Originally Posted by cgalpin

First, you can run gpspipe or xgps or something to test gpsd (or " telnet localhost 2947" and enter "r1" if you don't have those)

But yes I looked at the libftdi description which is why I warned you. Your gps is using the marvel chipset so your test is flawed. What the obd device needs is a serial port and that support is provided by kernel modules which libftdi doesn't provide.

Actually on second thought I don't think what you are seeing in the log is your GPS. You'd see it create /dev/ttyUSB0 or the like. That looks like you plug a mouse or usb stick in. Run tail -f /var/log/messages and watch as you actually insert and remove the device. But either way its not using libftdi

Yep, looks like you're right. I need to find an FTDI that I can compile on the plug to make that last link.

Bugbyte: please could you show me the output of "uname -a" ?

I'm experimenting with an ARM vm, trying to check that my stuff builds & runs.

Check out obdsim. Might mitigate a lot of your *immediate* need to get ftdi working.

Gary (-;

Linux debian 2.6.22.18 #1 Thu Mar 19 14:46:22 IST 2009 armv5tejl GNU/Linux

I just got my plug today and thats what I get.

Output is:

Code:

bugbyte@iPlug:~$ uname -a
Linux iPlug 2.6.22.18 #1 Thu Mar 19 14:46:22 IST 2009 armv5tejl GNU/Linux

I'll check out obdsim but I"m such a lamer that as far as I can tell I have to use svn to check it out, right? I've done that on the Mac before but never on the plug.