I have a servo base robot arm driven by an arduino uno. between my inputs from an remote control and outputs to the servos, i am using 12 of the 14 digital pins. I would like some sort of display for some basic information such as current battery voltage and maybe servo position. The problem of course is that i only have 2 free digital pins. is there any kind of display that will use this few, or are there other options for multiplexing? I probably should have used an arduino mega for this, but do I have any options or am I just out of luck.
Are you using the other six pins?
Don
what other six pins? as far as I know the uno has 14 digital and 6 or 7 analog input pins. i am not using the analog ins, but i am reading pwm from the receiver so i need digital for that. are there other pins I don't know about?
You could use a serial lcd display and use the software serial library that only utilizes two I/O pins.
or
Lefty
I have $6 serial displays that need 2 wire + 1 input
fast 14 Mhz shifter MCU onboard
serial would be perfect. thanks. where did you get the $6 one?
-luke
they are based on a flash controller.
The serial protocol depends on additional external parts:
1 diode + 1 resistor - RDY input
1 resistor - MCLR
probably one more resistor for a data line.
I don't have Arduino code yet, but it's scheduled.
All I have is a flowchart for the bus timing.
So what I mean is they are more difficult to use than serial DIsplay with hardware serial port (9600 baud).
My protocol is faster but needs synchronization:
Test for 1, wait for 0 transition, Test for 1, start data transfer + pull data line to 1. This line needs resistor because tristate is used to signalize the display to read in data.
If you want to build your own serial shift register backpack board see these projects:
http://code.google.com/p/arduinoshiftreglcd/
http://code.google.com/p/shiftreglcd123/
Parts to build one can be pretty cheap as the resistors and diodes are just pennies
and the shift register (hc595) can be had for about $0.25 USD.
You can see my version of the circuit on the arduinoshiftreglcd project page (bills version)
that only uses 2 wires.
If you want to buy a board that is already made and ready to go, have a look
at the adafruit board:
http://www.ladyada.net/products/i2cspilcdbackpack/#download
--- bill
Just so you know, the six (6) analog pins can also be used as six(6) digital pins which the lcd library can use for the display. If I'm not mistaken they would be labled as 14-19.
Just so you know, the six (6) analog pins can also be used as six(6) digital pins which the lcd library can use for the display. If I'm not mistaken they would be labled as 14-19.
They can also be labeled as A0 - A5. There is no difference as far as basic I/O is concerned between the pins that are labeled 'digital' and those that are labeled 'analog'. This labeling is strictly Arduino nomenclature and is based on the auxiliary functions of the various pins.
Don
The key piece of information is that the Arduino "analog pins" can be used as digital pins.
And that Arduino analog pin 0 is the same as Arduino digital pin 14, analog 1 is digital pin 15, etc...
up to analog pin 5 is digital pin 19.
--- bill
I use this little fella:
http://www.hobbytronics.co.uk/i2clcd-backpack
It uses the I2C bus, just analog pins 4 and 5 plus a ground and 5volts.
It's really easy to use and comes with it's own library.
Instead of the pins that came with it, I soldered a 16 pin socket to the board.
That way I can just clip any display to it.
I'm quite the novice but it's very easy to use.
Paul
Just connect a regular LCD to a PCF8574 and then that connects to A5 & A4 on the I2C bus.
Just connect a regular LCD to a PCF8591 and then that connects to A5 & A4 on the I2C bus.
Are you sure about that part number Mike?
Don
Yes Don your right, just corrected it thanks.
I agree that an I2C I/O extender is a good way to go.
The advantage of the serial, I2C, SPI, backpack type devices such as the one mentioned on reply #11 is the ease of use. Someone else has done all the LCD specific programming for you and all you really have to do is send the desired ASCII codes to the backpack and they are displayed on the LCD. You need some special commands if you want to to clear the screen or position the cursor, but the display of messages is dead simple.
The disadvantage of the serial, I2C, SPI, backpack type devices such as the one mentioned on reply #11 is also the fact that someone else has done all the LCD specific programming. You have no control whatsoever over that code and in most cases you can't even examine it. The programmer may or may not have implemented all of the capabilities of the LCD controller and he may or may not have implemented them properly.
With an IC I/O expander you have the responsibility of implementing the LCD specific programming. This also uses some of the resources of the host controller (the Arduino) but the tradeoff is that you have complete control of the whole process. You can implement as much of the capability of the LCD controller as you need and you can be sure that it has been done correctly (or you can totally screw it up, but that's another story).
I still can't understand why there is so much emphasis on the use of shift registers for this job.
Don
floresta:
I still can't understand why there is so much emphasis on the use of shift registers for this job.Don
I can think of 3 reasons:
- works the same as the included/standard LiquidCrystal at the API level
To me this is a VERY BIG DEAL.
The shift register implementations (2wire, 3wire, and I2C)
have LiquidCrystal API compatible libraries available.
Why a LiquidCrystal API is a good thing to have:
It is a well understood API with documentation available on the Arduino site.
It also means that from a sketch perspective it doesn't matter
whether what the communications interface is.
Many of the Async Serial Interface boards do not bother to provide
a LiquidCrystal API compatible library.
Which to me is silly since it is trivial to implement one.
They expect you to write your code to their proprietary
message interface rather than use a standardized lcd library API.
While sometimes a proprietary interface can offer some added features,
using the LiquidCrystal API is better for the user as it
does not lock them into the proprietary message interface
and allows the user to easily pick and chose a display and interface and not have
to change any of the code to drive it.
i.e. when using a LiquidCrystal API, you can switch from a LCD shield
to a 2wire/3wire shift register or i2c backpack and your sketch does not change.
(only a 1 line change to the constructor)
Plus for added features like menus, scroll bars, large fonts
there are other 3rd party libraries that sit on top of the standard LiquidCrystal API.
If you have to use a custom message interface, you are locked out of being
able to use those other libraries or will have to modify them to use the custom
message interface.
(It would be easier to write a LiquidCrystal compatible library for the custom message interface)
-
Cost & Simplicity
It is a simple DIY project for many hobbyists.
A simple "2 wire" backpack can be built for about $1USD
using a proto/strip board, a 74HC595, a diode, and 1 resistor, and a couple caps for decoupling
Toss in another resistor, a cap and transistor and you can even
get backlight control.
No other low wire count interface is this easy to make for a DIY project. -
Speed
While not needed in most cases,
a 2wire or 3wire shift register interface can (depending on the library)
allow LCD updates to be faster than i2C or Asnyc serial.
With highly optimized low level bit twiddling code,
it can even be faster than the 4bit parallel code in the standard LiquidCrystal
library supplied with the IDE.
--- bill
works the same as the included/standard LiquidCrystal at the API level
Well so does the I2C option.
In fact in my version I have added some useful extra commands like put in blank spaces from the current position until a given cursor position. That makes menus easier. And a command that prints x number of spaces, to save on memory from defining large strings that just consist of blank spaces.
No other low wire count interface is this easy to make for a DIY project.
No it is the same level of complexity and cost to have an I2C chip as to have a shift register.
a 2wire or 3wire shift register interface can (depending on the library)
allow LCD updates to be faster than i2C or Asnyc serial.
No.
The limiting factor is how fast the LCD can respond to the commands. The slightly slower speed of the I2C interface does not actually slow down the rate of update of the LCD. In fact the standard library doesn't read the ready flag from the LCD and so has to insert large delays for some LCD commands where as in practice the display does not need this long to be ready. The LCD clear display can be up to twice as fast by reading the ready flag. The reason why this is not done is to save a pin, a factor that is not important when you dedicate an I2C chip to it. With shift registers you would need input and output registers.
Bill: I think we agree completely but something has been misinterpreted.
The device mentioned in reply #11 started all of this. At first glance it looks like a generic I/O expander but, when you read the datasheet, you will find that it is a backpack device that seems to use a dedicated microcontroller like many of the others. It has all of the characteristics that I mentioned in my second and third paragraphs.
Your post agrees with just about everything that I mentioned in my fourth paragraph, specifically that when you use some sort of I/O expander instead of a controller programmed by someone else "you have complete control of the whole process", including the use of a standard API.
I wasn't questioning the validity of the use of serial adapters, just look at my first sentence. What I don't understand is the emphasis on the use of the generic 74HC195 shift register for this purpose.
I think Mike was interpreting things as I did since I agree with all of his statements.
Don
Grumpy_Mike:
works the same as the included/standard LiquidCrystal at the API level
Well so does the I2C option.
We are in total agreement. In my original comment:
The shift register implementations (2wire, 3wire, and I2C)
have LiquidCrystal API compatible libraries available.
I mistyped "shift register" when I meant "serial".
meaning all the 2wire, 3wire and i2c implementations
have Liquidcrystal API libraries available.
Sorry about any confusion/mis-understanding there.
No other low wire count interface is this easy to make for a DIY project.
No it is the same level of complexity and cost to have an I2C chip as to have a shift register.
Going to have to disagree here.
While a circuit design using an i2c i/o expander chip is similar in complexity,
a shift register implementation only uses 4 components
for a total component cost (without PCB) of 24 cents
Cost Part
0.01 4.7k resistor
0.01 1N4148 diode
0.01 0.1uf cap (bypass cap for 595)
0.01 0.1uf cap (bypass cap for lcd)
0.20 74HC595
0.24
Add backlight control:
0.01 4.7k resistor
0.01 0.1uf cap
0.08 2N7000 mosfet
0.01 150 ohm resistor (lcd current limiting)
0.35 (total with backlight control and current limiting)
NOTE: the backlight circuit could be modified to cut 6 cents off the cost if it used a cheaper transistor.
I have this working today and those are the actual QTY 1 pricing prices I paid from Tayda:
http://www.taydaelectronics.com/
I would be very interested to see an i2C implementation for a component
cost of less than 24 cents or less than 35 cents with backlight control.
From a software perspective, the software to run a shift register is substantially
smaller and less complex than the code needed to run an i2C i/o expander.
(especially when you look at all the needed code including the wire library for the i2c implementation)
Don:
You and I are in total agreement. I think something I typed didn't come across
very well. (I think the part of having/using a LiquidCrystal API threw everyone)
This is my guess as to why I think the 74HC595 is popular.
It is cheap (seems to be cheaper than some of the other shift registers - hard to beat 20 cents per chip).
It is easy to find
It is easy to understand and can be debugged with a simple logic probe or even a simple LED (poorman's logic probe).
While there isn't that much to really fail with i2c especially when the hardware is wired up correctly
and there is a working library,
if something does go wrong with I2c, most folks will be out of luck trying to debug it.
Don't get me wrong, I like many of the i2c implementations
and intelligent async serial backpacks, but they typically will cost more than a DIY 595 board.
If you are buying a lcd backpack they are all about $10-20 USD and
the performance of any one of them is good enough for most applications.
a 2wire or 3wire shift register interface can (depending on the library)
allow LCD updates to be faster than i2C or Asnyc serial.No.
The limiting factor is how fast the LCD can respond to the commands. The slightly slower speed of the I2C interface does not actually slow down the rate of update of the LCD. In fact the standard library doesn't read the ready flag from the LCD and so has to insert large delays for some LCD commands where as in practice the display does not need this long to be ready. The LCD clear display can be up to twice as fast by reading the ready flag. The reason why this is not done is to save a pin, a factor that is not important when you dedicate an I2C chip to it. With shift registers you would need input and output registers.
Again, I am going to disagree here.
I have real world experience and math that I believe proves otherwise.
It isn't just about the time the LCD takes to process a command.
The time it takes to transfer the data/cmd to the lcd also matters because the lcd
can't start processing the command for the update until it actually receives the data/cmd.
The transfer time is pure latency overhead that can never be recovered
so it directly impacts how fast the LCD can be updated.
I think your are underestimating the impact of this transfer time especially
since in many cases the transfer time can be longer than the time it takes for the LCD to process
the command/data.
About the polling READY. Sure, polling READY is ideal. But it takes extra hardware to do it
(which is why it usually isn't done)
and for all but a few commands (clear, home) the needed "blind wait" is short (37uS) and
with a good library implementation it can often be hidden under
other code or the i/o transfer time. For example, with 2wire, i2c, and serial interfaces, the 37uS blind wait after
issuing a command or writing data can be eliminated or drastically reduced since it can
occur in parallel with (underneath) the transfer of the next command or data write.
There is no need to do a blind wait of 37uS if it takes longer than that to transfer the next
command/character, yet I see libraries that do this, which clearly shows the authors
don't understand the transfer/latency overheads and protocols involved.
Lets look at something more real.
Say the time of a real API call that the sketch would use:
lcd.write() to send out a character to the display.
Now lets go back and look at some real world transfer times:
A serial interface is often running at 9600 but lets assume 115200 at that rate, each character transmits
at about 87uS and this is in addition to any of the other s/w overhead from lcd.write(), the lcd library, or hardwareSerial code.
For this interface the 37uS blind delay after sending a command or data
is not needed since the serial interface can't send bytes faster than 87uS.
(The actual time for lcd.write() for Async Serial will always be longer than 87uS)
i2c using the default 400kbit/sec clock rate and 8 bit addressing is similar.
This is because with an i2c you not only have the overhead of the i2c physical layer protocol overhead
but also the overhead of using an i/o expander which requires a minimum of 2 output register
updates. (1 with E high, and then 1 with E low).
Ignoring start/end i2c overheads you have minimum of 3 bytes (i2c device addr, reg addr, data) to update
the output i/o expander latches.
And it takes two latch cycles to strobe E.
assuming you violate the LCD spec by setting E high at the same time you set the control and data lines.
If you don't violate the LCD spec it takes three latch cycles (E low with control and data lines set, E high, E back low)
So that is a minimum of 6 bytes. (assuming you want to save time by violating the spec)
At 400kbit/sec that is 120us of data bit transfer time.
There is more overhead.
(The actual time for lcd.write() for 400k i2C will always be longer than 120uS)
I believe that you can speed up i2c quite a bit but I believe that by default that the Arduino wire library
sets it to 400k/sec.
lcd.write() using an optimized 2wire implementation (not using the Arduino core teams shiftout() function)
can update the LCD in 76uS on AVR and 50us on pic32 Arduino (I have this working today).
And that is everything including strobing E and the needed blind wait.
That is the measured time of the full lcd.write() API call and returning back to the sketch.
For actual LCD commands the ascync serial interface can get slower depending on the async serial lcd backpack
message interface.
Async devices typically accept data as characters so to write a character to the display you simply
send the character.
For commands, some devices use control codes and some and need a escape code to issue a command.
For those devices that use an escape code, the latency doubles (potentially 4x for cursor positioning)
over the character write time since it takes extra bytes to perform the commands.
In the grand scheme of things it doesn't much matter.
All the devices and interface are usually fast enough for the application.
--- bill