HD44780 non-blocking code without BUSY signal?

[poorchava]

Hi,

I'm developing an application where i need some pretty fast response times and I cannot afford to have a delay loop in LCD library code. The application is also very constrained for controller pins, so the R/W line of LCD is not accessible.

I figured that the code would need some periodically called service function with a state machine that checks is the time delay has elapsed and if so, then switch pins or do whatever else, change state, set next delay and return from function. I'd also have to make some sort of "task list" for the state machine to do (eg. a list of characters to display).

Has anyone of you guys come across anything like that and could share a link? I mean I could write that code myself, but I thought that since HD44780 LCDs are so ubiquitous, then something like that must have already been written by someone and I won't have to deal with that myself.

[nessatse]

How about running your time critical stuff in a timer ISR and your LCD and other UI stuff in the foreground?

[gxti]

Or the other way around. If you establish that X time between commands works reliably, then setup a timer that fires every X, and turn the ISR on when you need to write characters and off when you're done. If your microcontroller has DMA you might even be able to get the timer to directly trigger a DMA transfer.

Not that it's relevant to your question, but when I last wrote HD44780 code I tried to make use of the BUSY flag and found that it was cleared well before the display was really ready for more. I did buy the modules off aliexpress though so odds are they're fakes and the cloners just don't care. On the plus side, the interface hardware is simpler when it's write only.

[poorchava]

Yeah, interrupts will be utilized quite heavily, so this is an option, but on the other hand a lot of interrupts means a lots of problems with proprities and situations when an interrupt is interrupting another interrupt that had interrupted other interrupt which interrupted main code, eg. total mess.

The idea with interrupt making an LCD call every X time is similar to what i have described, but having a delay counter and decrementing every milisecond or so has an advantage that I can decrement multiple counters in one ISR, even for stuff that is happening less often. In general I need to make devote as little time at once for all low priority operations as possible, because this is a software controlled high-power SMPS, which means that non-deterministic execution time for almost anything = kaboom.

[mazurov]

That's how I did that using PIC24 EPMP peripheral -> https://www.circuitsathome.com/mcu/driving-a-character-lcd-using-pic24-enhanced-parallel-master-port. From app.point of view access to the LCD is write to a queue so no delays. One timer interrupt is used with two intervals, one for fast commands, other for slow.

[Edited the numbers]

Without a PMP/EPMP-type peripheral you'd have to bit-bang the bus, ~2.5us per cycle every 40us or so. You may want to experiment with modern LCDs, some will work with faster E; however, I'm yet to see one which would tolerate a sub-100ns E.

[Rufus]

Has anyone of you guys come across anything like that and could share a link? I mean I could write that code myself, but I thought that since HD44780 LCDs are so ubiquitous, then something like that must have already been written by someone and I won't have to deal with that myself.

If you don't need to display a cursor an efficient and convenient scheme is to continuously dump a frame buffer to the LCD one character at a time.

On a 16 MIPs processor a function to dump the next character will run in 3-4 us. Calling the function at a few hundred Hz from a timer interrupt uses a fraction of a % of processor time and whatever you place in the frame buffer automatically appears on the LCD faster than the glass can display it.

Much easier to use than gotoxy() and print(this) type schemes. The main downside is the LCD uses the memory access address as the cursor display address so you can't use the hardware cursor. It isn't that hard to write a blinking cursor in the frame buffer if you really need one.

[nctnico]

The idea with interrupt making an LCD call every X time is similar to what i have described, but having a delay counter and decrementing every milisecond or so has an advantage that I can decrement multiple counters in one ISR, even for stuff that is happening less often. In general I need to make devote as little time at once for all low priority operations as possible, because this is a software controlled high-power SMPS, which means that non-deterministic execution time for almost anything = kaboom.

Then do the SMPS stuff in an interrupt and poll everything else. Thats the way I have made similar systems. Have a tick counter in the SMPS interrupt so you can time less critical things.

[22swg]

I used a PIC161847 as an I2C / LCD interface , it can do all the controller stuff and buffer the data and spare IO pins.. 

[rob77]

and what about offloading the LCD stuff to a second micro ? interrupt driven data reception and let it slowly drive the LCD atmega8 is dirt cheap and more than enough for that you will just send the data from the primary micro when it's not in the time critical code and simply don't care more about the lcd - the second micro will do that.

[nctnico]

A second micro is a very bad idea (process synchronisation, fault handling). If a microcontroller runs out of steam then you have to move to a faster/bigger one.

[free_electron]

kinda funny how, after all those years, nobody has made an lcd controller that has a much faster timing. should be perfectly doable. same instruction set , just way faster.

[rob77]

A second micro is a very bad idea (process synchronisation, fault handling). If a microcontroller runs out of steam then you have to move to a faster/bigger one.

i'm not talking about multiprocessing on several micros - just offloading the LCD to a second micro... i don't know what process synchronization you need to pass few bytes over a very simple bus e.g. 4 bit bus + strobe + ack. (and you don't even need to catch the ack on the master)

i would do it the following way:
4 bit data bus - 4 output pins on the master - 4 input pins on slave
strobe - output on master - ext. interrupt on slave (rising edge INT trigger)
ack - input on master - output on slave

master:
is ACK low ? if yes spit out 4 bit and pulse strobe - then simply don't care
if ACK is high then try during the next "noncritical window"

slave:
main loop - setting ack low if it's high + sending over the fifo's content (if there is anything in the fifo) to the LCD
ISR on slave
set ACK hi
read 4 bits into a fifo
return from interrupt

now explain me please what process synchronization you need with the secondary micro i'm more than happy to learn something

[22swg]

Rob77 I'm with you my PIC backpack ( previous post ) is I2C but could easily be parallel , serial or SPI , Host  just sends the LCD slave the line,position,"string" and gets on with priority tasks...  no need for any delays, sync or hand shake , Init on power up with LCD line / character 1x8 to 4x20, custom characters , fixed messages saved in EE . it also accepts HD44780 commands .

[mikerj]

A second micro is a very bad idea (process synchronisation, fault handling). If a microcontroller runs out of steam then you have to move to a faster/bigger one.

There is nothing wrong with offloading tasks like this to a second small micro.  What fault handling or synchronisation issues would it cause over and above bit bashing the the HD44780 interface?

There are several vendors that make piggyback boards for HD44780 displays that allow you to write data over SPI, I2C or (more commonly) async.

That said, a low priority timer interrupt and a FIFO buffer seem like the simplest option.   Main loop writes data to FIFO and the timer interrupt deals with presenting the data to the display and toggling the E line.  Some intelligence needs to be built in to timer interrupt so it can determine the re-load value of the timer based on the current display operation.

[nctnico]

A second micro is a very bad idea (process synchronisation, fault handling). If a microcontroller runs out of steam then you have to move to a faster/bigger one.

There is nothing wrong with offloading tasks like this to a second small micro.  What fault handling or synchronisation issues would it cause over and above bit bashing the the HD44780 interface?

Built it and you will find out  Think about what the main controller should do if the slave controller is not responding. Besides that you'll need to maintain two pieces of software for one product and program and test two controllers during production.

[rob77]

A second micro is a very bad idea (process synchronisation, fault handling). If a microcontroller runs out of steam then you have to move to a faster/bigger one.

There is nothing wrong with offloading tasks like this to a second small micro.  What fault handling or synchronisation issues would it cause over and above bit bashing the the HD44780 interface?

Built it and you will find out  Think about what the main controller should do if the slave controller is not responding. Besides that you'll need to maintain two pieces of software for one product and program and test two controllers during production.

actually i did it several times - '51 with external memory as main micro (main program + user interface) and secondary micros to offload sensors and actuators.

so i would expect a different answer than build it and you'll see we all want to learn something

regarding your comment on not responding slave ... when the slave is not responding , it means there is a catastrophic failure and the main micro has to complete an emergency shutdown or switch to an emergency/safety mode - turn the whole system into a safe state to minimize the risk of further damage. (similar thing like your car's ECU does in case of abnormal behavior of any subsystem)

[mikerj]

A second micro is a very bad idea (process synchronisation, fault handling). If a microcontroller runs out of steam then you have to move to a faster/bigger one.

There is nothing wrong with offloading tasks like this to a second small micro.  What fault handling or synchronisation issues would it cause over and above bit bashing the the HD44780 interface?

Built it and you will find out  Think about what the main controller should do if the slave controller is not responding. Besides that you'll need to maintain two pieces of software for one product and program and test two controllers during production.

I've worked on numerous projects that have distributed systems like this, you are greatly exaggerating the issue in this case.  For starters the HD44780 is also a controller, what happens if that stops responding? Does it make any difference whether it's driven from the primary micro or a slave device in that case (in fact it would actually be worse if driven from the primary micro which polled the busy pin).

If a simple slave device stops responding then it probably hasn't been made robust enough.  If the code has been written properly there is less chance of such a simple application hanging than the very complex primary processor in the OP's system.

As I said before this could probably be handled through the one micro with suitable software design and is the way I would go, but discounting distributed system because one of the controllers might stop responding is just daft.

[free_electron]

A second micro is a very bad idea (process synchronisation, fault handling). If a microcontroller runs out of steam then you have to move to a faster/bigger one.

There is nothing wrong with offloading tasks like this to a second small micro.  What fault handling or synchronisation issues would it cause over and above bit bashing the the HD44780 interface?

Built it and you will find out  Think about what the main controller should do if the slave controller is not responding. Besides that you'll need to maintain two pieces of software for one product and program and test two controllers during production.

I guess the engi eers at agilent must be real nitwits then. Take good ol 34401 multi eter for example.
An 8051 controls display and keyboard
A different 8051 does uart and gpib
An 80196 does the metering part.

Many agilent machines use three or four processors each woth their own function.
There is no risk for deadlock in a display controller : fire and forget.
It works even better is you use dpram as a mailboxes. You never need to wait for anything.

[nctnico]

Now try and update the firmware 

[rob77]

Now try and update the firmware 

please stop with your hypothetical issues... it's not funny

offloading to slave micro-controllers is a common approach and it has more benefits than drawbacks... that's a sheer fact.

regarding your hypothetical firmware update issue:
1. if you have few easy tasks tightly bound to hardware offloaded to a slave micro - you'll most likely never ever need an FW update for that slave micro  (unless the author of the code is incompetent of course )
2. FW updates are needed for bug fixes and new features - those are for the main program which is not distributed - so in vast majority of cases we're talking about a FW update for the main micro/CPU only.

[nctnico]

Now try and update the firmware 

please stop with your hypothetical issues... it's not funny

offloading to slave micro-controllers is a common approach and it has more benefits than drawbacks... that's a sheer fact.

Source?
I have seen it go wrong too many times! Including difficulties with doing the initial firmware programming. With old and slow microcontrollers you often had no choice when you ran out of speed. In the past I have seen very convoluted designs using two 8051-ish controllers and shared memory between a video display unit to make a terminal (Wyse VT100 IIRC). Nowadays modern (ARM) controllers have so much processing power that using more than one controller is no longer necessary in most cases.

The last time I used more than one controller in a system was when I needed to design several boards in a relatively noisy environment (several DC-DC converters for a total of 12kW) and had not enough pins on the backplane connector to do SPI over RS485.  Using more than one controller required having a communication protocol and some form of error handling in case a board didn't respond in time or when the board itself detected an error. IOW: a lot more work than when I had used one controller.

[poorchava]

Ok, so the controller is a popular STM32F103 running at 72MHz - plenty of processing power. LCD is hooked up to normal GPIO ports and the hardware will not be changed. I'll probably time everything to PWM or ADC interrupts and leave the less critical stuff free-running in the main loop.

If I was designing the hardware I'd probably use some low budget uC like STM32F030 or some attiny to deal with user interface and just flog the info over hardware spi or uart.

[Rufus]

Now try and update the firmware 

offloading to slave micro-controllers is a common approach and it has more benefits than drawbacks... that's a sheer fact.

For an HD44780 interface it is a complicated and expensive solution which saves you nothing but having to figure out how to manage the timing of writing to a HD44780 without wasting zillions of processor cycles.

The frame buffer approach I posted earlier requires 6 pins on the processor the same as your slave processor suggestion and consumes about 0.1% of available processor cycles on a PIC24F at 16 MIPS.

[free_electron]

Now try and update the firmware 

if you a coder cannot write an error free program that takes character from a serial port and writes it to an lcd display HE IS AN IDIOT, should be fired on the spot and should be barred from programming or touching a microcontroller and/or soldering iron for life !

really ? update the program ?

let's analyse this for a second shall we ?
- if an interrupt comes: take the byte form the uart
- if the byte is 255 then the next byte is a command , if the byte is 254 the next byte is a character. (essentially if you receive 255 you toggle RS high , if you receive 254 you toggle RS low , if it is anything else you put it on the databus and cycle the WR strobe fo the display.

The bloody program can be 20 instructions in assembly.

Now, since the program is so small : the same program, when idle, simply scans the keypad and if a key hit is detected, debounces it and sends a single character out through the uart.
That is an endless for-next loop detecting a key , waiting a few cycles to detect the key is still valid , spit out a character , wait a few more cycles and then repeat if still the same , or continue with the next scan if key was released.

There's another 50 instructions.

Easily done in a simply cheapo pic processor. offloads the main cpu.
In the 34401 multimeter they use a VFD display that needs its own scanning. So in the idle loop you perform the display  scanning.

i'm willing to bet the code in that 8051 is barely 500 bytes. Heck they use a MASK programmed 8051, not a flash , not an eprom , not even an otp. a MASK programmed one ! they don't need to update that code as it is bug-free.

[takes beer-crate, puts it down , gets on it and starts ranting]

This is the key problem causing the sorry state a lot of firmware is in these days. It sort of works, slap it in and ship it, we'll release bug fixes and updates later. Gone are the days of software where the programmer knew every in and out of his hardware and instruction set. gone are the days where a programmer would write bullet proof code, test the snot out of it and then be confident to have it cast in mask programmed rom.

It's all uniform drab slapped together from crap libraries written by some dolt that doesn't know any better.

Want an example ? Blu-ray and DVD players. Every time you buy a new disk this junk needs to connect to the internet for a 'software update'. I'm not even talking crypto encumbered stuff here. just its base firmware.

Take a modern DVD player , pop in a dvd disk. these machines have dual core processors running 800MHz these days with a 20 megabyte flash attached. They run effing linux ! [mandatory eyeroll] It sits there chewing for 30 seconds on the disk before it even shows the splashscreen.

the people writing such code should be tarred , feathered and have these dvd player shoved up their 'behind' sideways and put in stockades on public display.

i have an old daweoo dvd player. it has a stupid 16Mhz motorola 68000 and a little 8051 that does the keys, display and ir code. the EPROM (NOT  FLASH !: one time programmable eprom) is a 27c512 ... it plays any DVD disk, even the latest release, without a single hiccup. close the tray and 3 seconds later you have an image. hit play and within a second the movie plays.

My latest greatest blu ray takes a minute before i get it to play.  an then i need to sit there swearing at it becasue there is first the spinning disk splashscreen ,then the unskippable  fbi warning , then the unskippable intro animation and then they gonna shove some previews of 'coming soon' movies down your throat (that you have already seen multiple times as you bough this disk 3 years after it was first released ,) that you can't skip either. Talk about taking the fun out of a movie night... Sometimes i want to fling the remote at the tv.

all because of the massive software overhead created by nitwit programmers that can only take massive, unoptimised (because all that shit needs to portable and reusable) third party libraries and kludge it together. if it contains bugs .. we'll fix it in the field afterwards through update.

We have the same shit in cars . toyota has had massive problems with engine controllers going crazy. A third party analysed the entire code and found 700 ! bugs. it is a miracle of programming that it worked right at all.
 I just read Renault has to recall a bunch of cars because the cruise control systems can activate by themselves and go full throttle. you can't even shut them down. 3 people were killed because of it. oops, we haven't gotten that bit quite right yet , bring it in we'll update the software ....

really ? this is what the world has come to ? uniform crap ?

[steps off beercrate and goes for a walk to cool down...]

Really, if you cannot guarantee the correct functioning of something as simple as a little coprocessor doing some menial task that makes the main processors code easier you are in the wrong playing field. go back to toying with your Crapberry Pie and hard-whino.

[rob77]

If you don't need to display a cursor an efficient and convenient scheme is to continuously dump a frame buffer to the LCD one character at a time.

On a 16 MIPs processor a function to dump the next character will run in 3-4 us. Calling the function at a few hundred Hz from a timer interrupt uses a fraction of a % of processor time and whatever you place in the frame buffer automatically appears on the LCD faster than the glass can display it.

Much easier to use than gotoxy() and print(this) type schemes. The main downside is the LCD uses the memory access address as the cursor display address so you can't use the hardware cursor. It isn't that hard to write a blinking cursor in the frame buffer if you really need one.

Now try and update the firmware 

offloading to slave micro-controllers is a common approach and it has more benefits than drawbacks... that's a sheer fact.

For an HD44780 interface it is a complicated and expensive solution which saves you nothing but having to figure out how to manage the timing of writing to a HD44780 without wasting zillions of processor cycles.

The frame buffer approach I posted earlier requires 6 pins on the processor the same as your slave processor suggestion and consumes about 0.1% of available processor cycles on a PIC24F at 16 MIPS.

calling from timer interrup @ few hundred HZ is definitely not 0.1% - you still have to dump the frame buffer to the slow LCD during each cycle, so don't tell me it's 0.1% at few 100s HZ with a 16MIPS micro.  0.1% from 16MIPS is 16K instructions per second  - at 500HZ it's 32instructions per cycle.... 32 instructions for a function call + return from function + actual dump of the frame buffer to the LCD..... common

but otherwise the idea is very elegant and i actually like it   

regarding the saving nothing with the slave micro.... it's saving CPU cycles on the main micro and decreasing the risk of running into timing issues.

regarding the cost.... if the extra $5 will make me confident that i'll not run into issues with timing.. then that $5 is well spent (the $5 is the extra micro + stuff around it and few square cm on the board). of course for mass production it's expensive, but for one-off or small batch it's much cheaper than 1 man-day of troubleshooting and "hunting"  for CPU cycles in software;)