I have experienced problems in the past with 4-bit mode. There was nothing wrong with the code. The procedure that worked was to call the initialization routine twice.

 

I use the 4 bit mode, but with the I2C interface all the time now.


So you only need 2 pins, plus 5V and gnd.
And a number of displays, or other I2C devices can be run on the same pair of pins too as long as the addresses are different.
That may be worth a look.

 

If you want to take that route you can do it with 1 pin plus Vcc and GND.
UART signalling, 1-wire. I have implemented an addressable Manchester phase encoded signalling.

 

I have experienced problems in the past with 4-bit mode. There was nothing wrong with the code. The procedure that worked was to call the initialization routine twice.

Which points to possibly not a long enough wait at power up. These displays require quite a long time to initialize.

Bob

 

I have experienced problems in the past with 4-bit mode. There was nothing wrong with the code. The procedure that worked was to call the initialization routine twice.

I would take that as evidence of a code problem.

Not to initiate another long discussion, but some people believe that the Hitachi chip comes up natively in 4-bit mode. That is, one can use 4-bit commands to set 8-bit mode, but one does not need to use 8-bit commands to set 4-bit mode..

 

I use the 4 bit mode, but with the I2C interface all the time now.
View attachment 193442
View attachment 193441
So you only need 2 pins, plus 5V and gnd.
And a number of displays, or other I2C devices can be run on the same pair of pins too as long as the addresses are different.
That may be worth a look.

Can you still read the display when using I2C?

 

Can you still read the display when using I2C?

I do not think so. But I have never had a need to read the displays as yet.

EDIT: Looking at the circuit, I think you actually could if you want to. The R/W pin is driven, so if you write the code, it should be readable.
https://www.electroschematics.com/arduino-i2c-lcd-backpack-introductory-tutorial/ has info.

 

Thanks for the response.

I have at times wanted to read, modify, and write a position -- like scrolling a GLCD or erasing only the remainder of a line. Also, I tend to use the busy flag rather than fixed delays when relevant.

 

hi,
I have never had a problem using the 4Bit mode on these G/LCD's, also I use the Busy/Ready bit.
E

 

I always wonder this: say you start checking the busy flag of an LCD that is not working. You risk to get stuck forever there...unless your error checking structure is robust enough. Anyone?

 

That hypothetical problem potentially occurs at every branch point or for that matter delay. So far, my pacemaker has not got hung up.

 

hi at,
Any program action that waits for an input, should have a 'time out' escape route, this could be a simple loop counter or a Interrupt/Timer.
E

Update:
On my radio linked data logger, I use a 8 pin PIC 12F628 that monitors the RX and TX activity etc... , if the Time Out occurs It Resets the main MCU.
Works fine.
E

 

Any program action that waits for an input, should have a 'time out' escape route, this could be a simple loop counter or a Interrupt/Timer.

Or, as a (superior) alternative, don't use blocking routines that wait for input.

 

hi j,
Its a radio receiver link [HC12] which expects data reception every 2 seconds ,the RX MCU then combines the received data with local data and retransmits the combined data on a different radio channel to a 'master' receiver'.
Trying a 'software' approach did not give the required performance due occasional interference from other TX/Rx users in the area.

So I adopted an approach which worked well on my commercial products, you may know of the IC's that monitor a number of lines the MCU uses as part of the programs operation and generates a Reset if they are absent for a given time period.

So monitoring the TX and RX and the SD card data integrity of the main MCU, by using a small PIC, its possible to give the system a reliable Reset operation.
Running now for over 3 years, 24/7, with minimal problems.

E

 

Or, as a (superior) alternative, don't use blocking routines that wait for input.

Is that really practical with synchronous routines such as SPI? It seems a timeout, such as WDT is reliable and has a place.

 

Is that really practical with synchronous routines such as SPI? It seems a timeout, such as WDT is reliable and has a place.

SPI can be configured for buffers and interrupts (and/or DMA on some devices) so blocking waits for word transfers should be the last option for efficient high speed operation. Most of my small embedded devices use SPI mode displays in an FSM that never waits for individual I/O(s).

 

hi,
Never seen a program written yet that can guarantee when 'glitched' by noise or a component tolerance failure,that will not get into a 'forever loop' which is outside the main programs software time out loops.
In a critical MCU project I would always add a hardware device time out reset, in addition to any software time out resets.

E

 

hi,
Never seen a program written yet that can guarantee when 'glitched' by noise or a component tolerance failure,that will not get into a 'forever loop' which is outside the main programs software time out loops.
In a critical MCU project I would always add a hardware device time out reset, in addition to any software time out resets.

E

Correct. There is no solution to the 'Halting Problem' in a Turing machine but that's really a separate issue IRT blocking I/O functionality.

 

hi,
Never seen a program written yet that can guarantee when 'glitched' by noise or a component tolerance failure,that will not get into a 'forever loop' which is outside the main programs software time out loops.
In a critical MCU project I would always add a hardware device time out reset, in addition to any software time out resets.

E

I've got tens of thousands of product in use in the field running with no WDT for up to 30 years.

None "hang up". Ever.

 

hi j,
Congrats, so have I, worldwide.
My MCU products also did not hang up, using HW and SW 'anti-hanging' routines.
Guess we both know what we are doing, good to hear.

E