Interacting with multiple serial devices

Basically, I want Arduino to output to a Serial LCD, store information to a USB flash drive, and communicate with a computer or a second Arduino via a wireless signal. Also it will need to have some sensor inputs and basic buttons for inputs from a user, not sure how many buttons at the moment, but at LEAST two, probably more like four. Also possibly some LED's to light up here and there...

As I understand it, all these tasks are more or less best done through a serial connection (excluding the simple buttons and LEDs of course).

*My questions: * Is it possible? (I think it is based on addressing packets to specific hardware, but its slow?) What's the best way to do it and/or suggestions on how to do it? (mind you I already have a serial LCD, the other hardware has yet to be purchased)

None of the serial connections need to be particularly fast, they're actually second order compared to the button/sensor inputs. The sensor inputs are by far the most important, and need to be read as often as possible while maintaining a reasonable output to the LCD and/or wireless and/or USB. USB data needs to be written only as fast as Arduino runs out of memory for storage. USB data needs only to be read after all the data is collected, in fact, it might not even need to be read by the Arduino at all, but rather by a computer for simple data-logging. Precision trumps accuracy.

In the case of using two Arduino for the wireless aspect of it. I would need one to write to an LCD and a couple of LED's only. The other, theoretically only would need to output to a laptop, but seeing as how I'd like this to be standalone, it would probably also have it's own LCD and also the USB storage for when our laptop invariably runs out of battery.

For specific information on my application: (this gets long)

This is my first project and it is relatively simple.

I need a "stopwatch" for essentially a drag racing strip, something that is triggered by one sensor at the beginning and another at the end. Basic requirements are that the trigger is by a sensor that is much more accurate and repeatable than a stopwatch that is controlled by a person.

We actually have this system in place by wiring infrared sensors (the sort you find in a store to signal someone entering the store) into a stopwatch. The problem we have is that at low speeds the car can trigger these sensors more than once, so we also need a debounce filter, preferably one that is even programmable for various different situations. Also it only reads to .01 seconds, we would prefer .001

This is relatively simple and actually the LCD display and sensors have cost quite a bit more than the Arduino itself, yet the Arduino is the real key to the project...funny how that is.

Anyways, I have all the stuff to make that work and some rudimentary code in place that will get it working (will be making a thread in the 'exhibition' section within a week or two) but I'm looking towards the future...

I recognize the power of Arduino and the sorts of hardware out there, as such I've become increasingly more interested in using Arduino for a data-logging/telemetry system.

At first, this will only be recording lap data. That is, the Arduino will only read lap times. The first thing to do to make it more complicated is to have it read sector times, as well. These are checkpoints out on the lap so that you know how fast you complete certain sections of the track (this is not for a drag racing strip, this is for tracks that are continuous). A lot can be done with that data. I would like lights to light up in the drivers face if its the fastest lap so far, or fastest section. I would like Arduino to remember which laps were fastest. On a more complicated level, it could do very simple data calculations such as average lap time and standard deviation. Arduino itself only needs to remember a select few bits of information: fastest lap, fastest time for each section, average lap time, standard deviation, but all the data should be saved in a raw format to memory somewhere (USB flash drive?). On that note, I don't know mathematically if you can calculate standard deviation and averages and all that stuff by taking a known average and standard deviation and factoring in the new lap time... I assume it's possible... worst case scenario I have it be a rolling average. On that note, we rarely do more than 20 laps at a given time. There will probably never be more than 5 checkpoints and/or sectors, so really there will only be about 100 pieces of recorded data in at the base level of this project.

Thats what I want to start. In the future I see telemetry so that the driver and the pit crew see the same information (although the pit crew would probably get more detailed info, due to then not being proccupied by driving) I see more complex data logging from a variety of sensors. Possibly even some control over variables on the car.

Currently, I have an Arduino Diecimila. Since things will be mounted on a race car, I will most likely be using an Arduino Mini, when the time comes. Similarly tiny wireless devices are desired. Range should be ~600 feet outdoors. Less is acceptable if it can be made to send the data when it's within range and not when it's out of range (for example, sends the data when the car is driving by the pits), but not when it's 1/2 way around the track).

Thanks for your help, and taking the time to read this!


You could maybe use a EEPROM to store data?

I2C on arduino is tough since I could find no tutorial. Thanks for the link! I’ve got some 1k IC’s but cannot read or write to them yet but might make it work now or I’ll get the ones in your link.

The spi eeprom seems to work better but I’ve not ordered any chips yet.

This is an SDCard in SPI mode but not quite working yet. Has links to a cool SDCard connector though. (floppy connector)

I2C on arduino is tough since I could find no tutorial.

Look for TWI (two wire interface). I2C is a proprietary name, TWI is what Atmel calls it. Arduino provides the Wire library (#include <Wire.h>)

There are examples on the site (their library is called TwoWire, but it’s the same as Arduino’s Wire).

Just today I got a toy example working: a slave Arduino generating a sequence of characters, with a master Arduino reading them via I2C and printing them on the serial port. Not terribly useful, but a good first step. It is doable.


I2C on arduino is tough since I could find no tutorial.

This article contains a useful introduction to TWI/i2c for the arduino.

Nothing there worked with an at24c01 i2c eeprom. I tried that link and others. I'll probably go with the large capacity SPI flash since it's much more capable and I know someone has made that specific part work.


If I think it's safe to do so I'll offer the parts I have if someone will promise to make 'em work and post the results in an understandable manner.

I2C on arduino is tough since I could find no tutorial.

This article contains a useful introduction to TWI/i2c for the arduino.

in general, are 2 serial devices able to communicate to the arduino at the same time?

I've found the stuff about software serial... theoretically could use that for the LCD and the hardware one for the wireless... that's what I might end up doing, but I've also seen stuff (look at the Atmega168 data sheet) about serial addressing, but I don't know how it works or how to use it.

So it seems like you can communicate with a lot of serial devices (through addressing and "virtual" serial ports) but only one at a time... generally not a big deal if you set your code up right...

Since I'm doing a timing system, I can assume that for at LEAST a second after taking a reading we're not going to need to take a second one, I can ouput all the info to my serial devices (I would imagine it can do it in a second or less) then go back to listening for another signal. Also, if I need to take information in, I can do it at that point.

That works for me, in a broader spectrum and for other applications, I don't know.

Also I still know nothing about how to actually implement all that stuff... but it seems possible.