12 January 2011

What, actual numbers?

Binary clocks are lots of fun, but most people appreciate base ten.  I used to have a binary clock on my desk at work, and people would ask, "What is that?"  Before they could recover from the cognitive dissonance caused by the short answer ("It's a clock, can you tell what time it is?"), I'd rattle off the time to them, down to the second.  They'd check their watches and shake their heads.  I'd say, "It's binary.  You can read binary?  This is a computer company..."  (Actually it was a BCD clock, but that was a finer point I usually didn't want to get into.)

In order to move on with the clock project, we'll need to add hardware, namely a display, and software to run it.  I always like to test things out by themselves to make sure I understand them before using them in conjunction with other components.  This is called unit testing.  The only objective here is to understand how to hook up a display and talk to it, so that we can make it display whatever we want.

I chose to use a Sparkfun 7-segment serial LED display.  This seems to be a simple enough display, not very imposing, just four digits.  Appearances are deceiving.  This display can communicate in two different ways (!) and it uses the same microprocessor as the Arduino (!!) to manage the communications and drive the LEDs.  So maybe not so simple.  Witness the abundant, ummm, grousing in the forums regarding defective displays of various type and manufacture.  There seem to be lots of displays that just don't work correctly right out of the box, they just display gobbledegook and otherwise behave strangely.  Well like I said, not so simple, we are not dealing with a light bulb here.  Several things have to be done correctly.  Wiring it up for starters, and then getting the software right.  Depending on how a display communicates, there may be a couple or many parameters that have to be correctly set, and if any one of them is off, then we won't get anything useful on the display.

Now I certainly had my share of gobbledegook at first with this display.  But I assumed (correctly ;-) that the display was OK and that the trouble was in my program, and indeed it was.  Bit of a learning curve.  Maybe by reading this, yours will be shorter.  Anyway, I like this display a lot.  I can operate it in either communications mode and it works nicely.  So let's get on with it and demonstrate both methods.

The first method is sometimes called just "serial" communication, or (better) "serial TTL" communication.  This is a variation of the RS-232 communication standard that uses the 0-5 volt levels associated with transistor-transistor logic (TTL) integrated circuits.  For two devices to communicate in two directions, serial TTL requires two wires, one to send on and one to receive on.  One device's send line is the other's receive line and vice versa.  Since we will only be sending commands to the display (it's polite and never talks back), we'll only need to connect a single wire to the display in addition to the power connections.  Note that you will see the abbreviations RX and TX for receive and transmit.

The second method is called a Serial Peripheral Interface bus or SPI.  This is similar to serial TTL in that there are two lines for receive and transmit, but there are two more lines, one called a (serial) clock, and one called slave select.  The clock is used to time and synchronize the data bits sent over the receive and transmit lines.  But they're not called that; when you invent a new communication protocol, you need new terminology, so SPI doesn't use transmit and receive, but Master In Slave Out (MISO) and Master Out Slave In (MOSI).  One big difference is that SPI can connect more than two devices on the same set of wires (which is what makes it a bus): One master and one or more slaves.  Of course they cannot all talk at the same time, or things would get all confused.  So to ensure polite conversation (one at a time, please!) each slave device has a slave select line which the master controls to tell the slave that it's ok to communicate back to the master.

There are pros and cons to the two methods.  SPI can send data faster, but requires more wires.  For this project, there really isn't much advantage to one method over the other, since we won't be pushing the limits of either.  But it's a great learning opportunity to become familiar with both methods, so we will do just that!

With that as background, check out my sketch demonstrating serial TTL communication.  I tried to include lots of comments, not just on the software, but also a description of how to wire up the hardware.  This sketch can use either the Arduino SoftwareSerial library which comes with the Arduino software, or the NewSoftSerial library which has many improvements (see my Arduino Libraries and Hardware page for a link to download NewSoftSerial).  I've read a lot of less-than-flattering comments on the SoftwareSerial library.  In fact I'm not sure if they still apply, whether issues have been addressed, or whether it has just sort of been abandoned and is no longer being actively developed.  Many people prefer the NewSoftSerial library instead, which works the same from a programming standpoint.  I tried both, and they both work fine for this project, but this is a simple project not likely to test library limitations.

Display connected for serial TTL communication.  Note only one wire for the data and two for power.

Yet to come: SPI comments, picture, link to sketch...

No comments:

Post a Comment