USB Serial Support

[Spenser309]

Hi,

My name is Spenser, I am an ECE undergrad at Baylor and my group is trying to make a data acquisition system for the solar power system on the roof of the engineering building.  We are thinking of using a SheevaPlug as the heart of the system.  Its main goal would be to take in serial data and store it in a database.  Furthermore, we would like it to host a PHP based website that will let us visualize the data.  My questions are as follows.

1.) Does this version of Linux support usb FTDI devices (USB to Serial)?  I know that Ubuntu on my laptop supports it but will the stock kernel on this device support them.
2.) I have heard problems about SD cards dying out very quickly in SheevaPlugs.  Is it wise to store important data on SD card? 

Spenser

[UnaClocker]

I never tried the USB-serial with the original kernel, but it's very easy to upgrade to one of the pre-compiled kernels provided here on this forum.
My primary file system is on an SD-Card. I have zero problems with it. I think some people have simply encountered defective cards. That or a bad brand. People use SD cards for professional photography where they can't afford to lose a photo due to a memory failure, SD cards don't normally fail.
Sounds like a cool project you're working on, I've been looking into finding a small (30watt or so) solar panel to keep a single SLA battery charged so I can run my Sheeva/Router/&Cable modem completely off-grid. If you publish any info about your setup online, I'd be interested in reading about it.

[birdman]

2.) I have heard problems about SD cards dying out very quickly in SheevaPlugs.  Is it wise to store important data on SD card? 

Mine's been in use for 6 months with no problems.  You should always have backups of your data, though (which is not specific to SD cards on Plugs).

[MarkF]

Does this version of Linux support usb FTDI devices (USB to Serial)?  I know that Ubuntu on my laptop supports it but will the stock kernel on this device support them.

Like the others here, I didn't let the default kernel last long enough to know this.  I'll be receiving another plug in the next two days.  I'll test this and report back.

I have heard problems about SD cards dying out very quickly in SheevaPlugs.  Is it wise to store important data on SD card?

If this is a major concern, you could use a small (<<100Gig) rotating media attached and powered via USB instead of, or to augment, the SD card.  For example, I currently use an 8 Gig SD card (root FS and applications) and a USB attached 32 Gig SSD (music only) to serve all my music via a plug.

The majority of the equation of how long flash (built-in, SD, attached via USB, what ever) will last is how often a particular flash sector goes through the erase/write cycle.  If wear leveling algorithms are used in the FS or the device, this concern can be reduced dramatically.  Using other methods (aligning partitions on sector boundaries, choosing "smart" cylinder/head/sector and partition size values, etc) can also help a lot.

You say you'll be writing the data to a database.  Will this database be on the plug or somewhere else on the network?  If it will be somewhere else, the wear on the plug's media could be minimal.  If the database is on the plug, are you going to use a "standard" database or one of the ones designed for embedded systems?  Most embedded database systems can be optomized for fewer writes to help with flash life.

EDIT: I just tested my FTDI based USB to Serial converter on a "raw" plug and though the drvicr was rcognized (I got new USB stuff in /dev) I don't see a /dev/ttyusbX device.  Therefore, I can't say it works with the original kernel and modules.

[Spenser309]

I guess I'll be rebuilding my kernel.  Luckily this isn't the first time.  Used to work for an embeded Linux company.

SD for storage is still on the table.

About, the embedded databases.  Which databases are available and free (beer and speech)?  I'll admit I haven't done a google search yet, but I'd like your input as to which ones work well and can be used with the PHP and C languages.

We have not decided if the DB will be local (SD) or remote (don't want to deal with sysadmins to much).  However, we know we want to use some network storage for the export files so we may have the ability to host the data base on NFS/SMB.  Performance wise we should be fine as the readings only come in every 5 min or so.

[MarkF]

Warning: The following is a bit "stream of consiousness".  My blood sugar is low and this is what happens.  Sorry.

Another possible topology is: One plug outside accepting the serial data with only an SD card and a second plug inside handling a USB attached rotating media for the DB.  The outside plug acquires the data and sends it inside to be stored.  This would allow you to use mysql, SQLite or some other free and small DB/SQL engine inside (no "elements" problems) on rotating media (no wear problems).  I believe PHP and C have SQL bindings so if you get a DB with an SQL interface, they should be integratable. (<-- is that a word? )

On the embedded DBs, one of the projects I worked on in the past used an in-memory/persistant store hybrid data base much like McObject's eXtremeDB Fusion.  It was not free.  If you think their products may be what you want, try contacting McObject.  They MAY allow you a single reduced rate or free "educational" license.  It never hurts to ask.

If your data only comes in once every 5 minutes, that figures out to 12/hour or 288/day.
That is 3472 days or ~9.5 years before an SD with 1,000,000 write cycles life time would fail.
I'm thinking you will graduate, or at least be long gone, before this fails.  What do you think?

[chunkyks]

1) In the default globalscale plug install, ftdi and pl2303 modules are missing; the first accounts for 75% of USB serial devices, and the second accounts for 20% of USB serial devices. The odds are good that it won't work.

2) But the plug installer neatly fixes that by installing a new kernel that supports them. It's worth noting that the ionics plug comes with working versions of both those modules.

3) I actually wrote an ftdi->pty userland proxy using libftdi. It's part of obdgpslogger. If you download and build it while libftdi-dev is installed, you'll find a program called "obdftdipty" that connects to your FTDI device, and opens a posix pty; you don't get quite as much control as you do with a "real" /dev/ttyUSB0 device, but you can communicate just fine.

Protip: Ubuntu 9.10 has [or had, I haven't checked recently] a badly broken ftdi kernel module; my userland proxy works around that, too.

Gary (-;

[Spenser309]

chunkyks,

I'm going to use an Arduino for data acquisition and control and would like to be able to load new firmware from the embedded system.  I am unfamiliar with the difference between a pty and a tty, will a pty give me the ability to reset the Arduino from the embeeded system and load new firmware?

I really like your obdgpslogger program, it looks very interesting and I may have to try it after I finish this project.

Thank you for your help and I appreciate the input.

Spenser

[chunkyks]

Basically you'll have the ability to send and receive data [ie, "echo reset > /dev/pts/5", "dd if=/dev/pts/7 bs=1 count=5" and similar], but you won't be able to change terminal settings on the device ["stty -F /dev/ttyUSB0 ispeed 115200 ospeed 115200" or similar]. For example, speed cannot currently be set on the fly; obdftdipty connects at a specified speed and you can't change it.

If you reset and upload firmware to the arduino via regular commands, you should be ok.

All this isn't to say that using ftdi_sio isn't a technically superior solution, you get all the control that's possible by using a "real" driver as opposed to my mickey-mouse userland proxy, but... the proxy works great for my needs.

Gary (-;