I may have some of my information off, (I don't actually own an Arudino yet) but I plan on buying the Arudino 101 which I understand is 32 bit, and I was going to use this Library for the LCD called LiquidCrystal LiquidCrystal - Arduino Reference. It says it works in 4 bit or 8 bit mode.
Does this mean DB0-DB7 has to at least have 4 or 8 wires etc, or does the Arudino have to be 8bit.
I am kinda confused on what the library means by 4/8 bit mode.
The LCD has parallel data bus 8 bits wide. It means 8 wires for data for communication with the controller, but it is able to use just 4 bit communication mode. It this case just 4 wires are needed and just 4 dedicated pins on controller, so 4 pins are saved but transfer speed is at half.
4 or 8 bits it doesn't matter with the controller/Arduino if it is 8 or 32....
. . . so 4 pins are saved but transfer speed is at half.
Actually the difference in transfer speed is almost negligible especially when the time the LCD controller takes to actually process the data is figured in.
Don
Yes, like that.
32 bit refers to program memory, it means the cpu instructions operate on a 32 bit bus. I/O is independent of this, so you can chose to 4 or 8 bit mode.
Just remember, even in 4 bit mode, the LCD still requires 3 (from memory) control lines, so total IO pin count would be 7. In 8 bit mode, it would be 11 IO pins.
It is actually easier to code for 8 bit mode, but given that the libraries already exist then its easier to wire it up for 4 bit mode!
Just remember, even in 4 bit mode, the LCD still requires 3 (from memory) control lines, . . .
Actually it only requires 2 (from experience) control lines since the vast majority of time the R/W line is tied to GND and delays are used in place of reading the busy flag.
The ability to save a bit of program execution time by reading the busy flag is offset by the fact that your entire program may crash if the LCD (which may be a relatively unimportant system component) fails. There's also the fact that extra program code is required which is not provided by many libraries.
Don
floresta:
Actually it only requires 2 (from experience) control lines since the vast majority of time the R/W line is tied to GND and delays are used in place of reading the busy flag.The ability to save a bit of program execution time by reading the busy flag is offset by the fact that your entire program may crash if the LCD (which may be a relatively unimportant system component) fails. There's also the fact that extra program code is required which is not provided by many libraries.
Don
With Arduino, particularly on the AVR processors, using BUSY can actually be slower than not using it for regular instructions (the ones other than clear & home)
The reason is that the code implementation of the digital i/o functions (pinMode(), digitalRead(), digitalWrite() ) in the standard AVR core code are so slow.
Assuming in 4 bit mode and you have a minimal custom BUSY read function, you would have to:
Then you can start to poll the BUSY line.
Which is 1 digitalRead per "look" (which can be done while E remains high)
Then when BUSY is gone, then you have drop E (1 digitalWrite)
That is a minimum of 9 digital i/o functions to look at BUSY.
the Arduino digital i/o functions often take a bit over 6us so you are looking at least 36+ us just to do a single poll and 6us per "look" waiting for the BUSY to change.
And that is before looking at any other code overhead including extra "smarts" to not get hung polling.
From my testing , by the time you have a proper BUSY polling function, it ends up being a bit slower than busy loop on the AVR processors using the the standard Arduino digital i/o functions, particularly if the library code is smart enough allow the LCD to execute commands while the AVR is freed up to do other things vs doing to dumb/blind wait.
If the code choses to bypass the slow Arduino provided digital i/o functions and instead uses raw port i/o, things change quite a bit as AVR raw port i/o is 50X faster.
But doing AVR raw port i/o is not portable and creates maintenance issues.
In my hd44780 library, while it does support using r/w for reading LCD display ram, I opted not to use BUSY, and instead used a smart wait for execution delays which allows the Arduino processor to run in parallel with LCD instruction processing.
While this isn't quite as fast as using BUSY with AVR raw port i/o it is portable across all the processors and is much faster than code that uses the typical blind wait execution delays.
-- bill