HD44780 non-blocking code without BUSY signal? - Page 1
Forum section: electronics / general

author: poorchava
author_rank: Super Contributor
timestamp: July 15, 2014, 09:28:33 pm
content: 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.

author: nessatse
author_rank: Regular Contributor
timestamp: July 15, 2014, 09:52:09 pm
content: How about running your time critical stuff in a timer ISR and your LCD and other UI stuff in the foreground?

author: gxti
author_rank: Frequent Contributor
timestamp: July 15, 2014, 09:59:45 pm
content: 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.

author: poorchava
author_rank: Super Contributor
timestamp: July 15, 2014, 10:10:23 pm
content: 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.

author: mazurov
author_rank: Frequent Contributor
timestamp: July 16, 2014, 01:12:43 am
content: 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.

author: Rufus
author_rank: Super Contributor
timestamp: July 16, 2014, 03:27:50 am
content: Quote from: poorchava on July 15, 2014, 09:28:33 pmIf 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 16, 2014, 06:29:31 am
content: Quote from: poorchava on July 15, 2014, 10:10:23 pmThen 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.

author: 22swg
author_rank: Frequent Contributor
timestamp: July 16, 2014, 08:40:43 am
content: I used a PIC161847 as an I2C / LCD interface , it can do all the controller stuff and buffer the data and spare IO pins..

author: rob77
author_rank: Super Contributor
timestamp: July 16, 2014, 09:19:03 am
content: and what about offloading the LCD stuff to a second micro ? interrupt driven data reception and let it slowly drive the LCDatmega8 is dirt cheap and more than enough for thatyou 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 16, 2014, 07:39:55 pm
content: 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.

author: free_electron
author_rank: Super Contributor
timestamp: July 16, 2014, 08:06:09 pm
content: 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.

author: rob77
author_rank: Super Contributor
timestamp: July 16, 2014, 10:11:22 pm
content: Quote from: nctnico on July 16, 2014, 07:39:55 pmi'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 slavestrobe - output on master - ext. interrupt on slave (rising edge INT trigger)ack - input on master - output on slavemaster:is ACK low ? if yes spit out 4 bit and pulse strobe - then simply don't careif 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 LCDISR on slaveset ACK hiread 4 bits into a fiforeturn from interruptnow explain me please what process synchronization you need with the secondary microi'm more than happy to learn something

author: 22swg
author_rank: Frequent Contributor
timestamp: July 17, 2014, 08:33:03 am
content: 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 .

author: mikerj
author_rank: Super Contributor
timestamp: July 17, 2014, 09:37:06 am
content: Quote from: nctnico on July 16, 2014, 07:39:55 pmThere 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 17, 2014, 09:59:18 am
content: Quote from: mikerj on July 17, 2014, 09:37:06 amBuilt it and you will find outThink 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.

author: rob77
author_rank: Super Contributor
timestamp: July 17, 2014, 01:21:31 pm
content: Quote from: nctnico on July 17, 2014, 09:59:18 amactually 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 seewe all want to learn somethingregarding 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)

author: mikerj
author_rank: Super Contributor
timestamp: July 17, 2014, 01:34:04 pm
content: Quote from: nctnico on July 17, 2014, 09:59:18 amI'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.

author: free_electron
author_rank: Super Contributor
timestamp: July 17, 2014, 02:23:30 pm
content: Quote from: nctnico on July 17, 2014, 09:59:18 amI guess the engi eers at agilent must be real nitwits then. Take good ol 34401 multi eter for example.An 8051 controls display and keyboardA different 8051 does uart and gpibAn 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 17, 2014, 05:38:42 pm
content: Now try and update the firmware

author: rob77
author_rank: Super Contributor
timestamp: July 17, 2014, 06:58:38 pm
content: Quote from: nctnico on July 17, 2014, 05:38:42 pmplease stop with your hypothetical issues... it's not funnyoffloading 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 17, 2014, 07:58:29 pm
content: Quote from: rob77 on July 17, 2014, 06:58:38 pmSource?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.

author: poorchava
author_rank: Super Contributor
timestamp: July 17, 2014, 08:41:13 pm
content: 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.

author: Rufus
author_rank: Super Contributor
timestamp: July 17, 2014, 08:53:31 pm
content: Quote from: rob77 on July 17, 2014, 06:58:38 pmFor 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.

author: free_electron
author_rank: Super Contributor
timestamp: July 17, 2014, 09:08:35 pm
content: Quote from: nctnico on July 17, 2014, 05:38:42 pmif 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.

author: rob77
author_rank: Super Contributor
timestamp: July 17, 2014, 09:51:52 pm
content: Quote from: Rufus on July 16, 2014, 03:27:50 amQuote from: Rufus on July 17, 2014, 08:53:31 pmcalling 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..... commonbut otherwise the idea is very elegant and i actually like itregarding 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;)

author: Rufus
author_rank: Super Contributor
timestamp: July 17, 2014, 11:13:04 pm
content: Quote from: rob77 on July 17, 2014, 09:51:52 pmYou send the next byte of the frame buffer or even half a byte. Writing a nibble to an HD44780 needs to wait 100ns setup time and 1us strobe time, at 16 MIPS those delays are about 18 instructions and on average it doesn't take much more than 18 instructions to figure out what to write. The system probably has a timer interrupt you can hook the code into anyway so at 300Hz you are likely within the 0.1% I claimed. A 16x2 LCD with nibble writes needs 68 writes for a complete frame - 300Hz gives a 4.4Hz frame rate - depending on the LCD type that's faster than the glass responds.

author: amyk
author_rank: Super Contributor
timestamp: July 17, 2014, 11:28:51 pm
content: Having an MCU in the feedback loop of an SMPS is just asking for trouble.

author: mikerj
author_rank: Super Contributor
timestamp: July 18, 2014, 07:11:40 am
content: Quote from: nctnico on July 17, 2014, 05:38:42 pmIf updating the firmware on slave processors was a requirement that that would be built into the design. The systems I have worked on had exactly this requirement and it worked as intended. Why are you so fixated on coming up with reasons why this wouldn't work, have you had a bad experience on a poorly designed system in the past?

author: mikerj
author_rank: Super Contributor
timestamp: July 18, 2014, 07:33:22 am
content: Quote from: rob77 on July 17, 2014, 09:51:52 pmAgreed. If your primary micro has DMA then you could transfer an entire frame to the display with almost zero overhead, but even if you transfer a byte at a time then the overhead will be tiny. If possible I would go for an async interface so you don't have to worry about chip selects etc. This also means you could tie the interface straight into a PC for logging or just debugging.

author: nctnico
author_rank: Super Contributor
timestamp: July 18, 2014, 09:22:07 am
content: Quote from: free_electron on July 17, 2014, 09:08:35 pmYou obviously never have to deal with customers who want something different later on... Say for some reason you need custom characters or scrolling which you didn't implement because the first specification didn't need those. In that case you'll need to update the firmware. No, this is not some hypothetical situation; this happens all the time. I have designed several add-on boards containing a microcontroller which can be updated by the main CPU (which receives updates over internet). Updates are not to fix bugs but to add features like changing sensitivity, altering the frequency of a key-beep, etc.Quote from: amyk on July 17, 2014, 11:28:51 pmNot really. An ARM is perfectly capable of handling an SMPS. In one of my designs I use one ARM controller to control two SMPSes and two class-D output stages. When the customer wanted the design changed from voltage control mode to current control mode all what was needed was to change a few lines of code.

author: rob77
author_rank: Super Contributor
timestamp: July 18, 2014, 12:48:23 pm
content: Quote from: nctnico on July 18, 2014, 09:22:07 amCAPABLE and SUITABLE are 2 very different thingseven a sports car is capable of plowing, but a tractor is suitable for that

author: mikerj
author_rank: Super Contributor
timestamp: July 18, 2014, 01:59:19 pm
content: Quote from: nctnico on July 18, 2014, 09:22:07 amI've seen this done successfully many times, though it's not something I would feel comfortable with in a commercial product. Microcontrollers tend to be far more sensitive to radiated or conducted EMC issues than a dedicated switcher IC, and the consequences of the micro going haywire would be much worse than e.g. a slaved controller messing up a display.

author: free_electron
author_rank: Super Contributor
timestamp: July 18, 2014, 02:57:25 pm
content: Quote from: nctnico on July 18, 2014, 09:22:07 amIn that case i tell the customer : you change the spec ? you cough up the dough to alter the system. Here is how many hours it will cost to develop and test and how many parts you are wasting int he process. Three things can happen- they learn very quickly- they go banckrupt because of their stupidity- they go with another developerit's all fine to me. Not my circus, not my monkeys.simple no ?that is another massive problem : customers that have no clue what they want , and even lesser a clue what they need to do what they want. i don't deal with idiots like that. plain and simple.you come to me with a specification, i design according to your specification. you alter it during development or after : cough it up : here is the bill for the additional time and effort.in case of that display controller it would not be a problem. i designed the transport to be such that you can do anything. byte 255 means : set command/data pin high ,254 means set it low. so you have access to the entire lcd display data and command set. two consecutive 255 characters escape the 255 and two consecutive 254 escape the 254. so you can do anything. there is not going to be an 'afterwards you realise' because you have full access.things like this require talking to your customer , figuring out what he needs and helping him. if you are forward thinking you make sure not to create any bottlenecks.the functions offloaded on little support cpu's are simple enough that they can be cast in stone without later having to 'update' the code.very frequently that code does a task that would encumber the main processor too much in splitting its time. things like receiving and buffering a serial stream or a gpib stream. scanning a vfd display from a string.in power supplies: let's say you have a programmable 4 channel power supply with fully isolated outputs. you will need a local controller per channel , talking over opto isolators to the earth referenced logic that has the gpib port.that is how the 6624 family does it. local 68c705 cpu controlling the local adc and dacs ( the regulation loop is analog ) and listening and reporting to the host controller. the host drives the lcd, scans keypad and talks listens over gpib.There are tons of examples of distributed systems using local coprocessors to do tasks and they work perfectly fine.Take a telephone exchange. Every phone line has its local cpu (and DSP to process audio , do the a-law or mu law encoding and create the 32 bit transport frame) running a small program. every board serving 48 homes has a local cpu talking to the line SLIC's. I have developed such SLIC's including the DPS and processor code (8051 core)Every rack has 15 or 16 boards and a rack controller. the rack controllers have auxiliary cpus monitoring line voltage, fan speed and other stuff (ATCA for example uses I2C interfaces to a distributed grid.NONE of that firmware is updatable. it all sits in mask rom (also because of radiation hardening).Have you ever known a telephone exchange crash because of a bug ? it doesn't happen ! And that is a system containing thousands of distributed cpu's and dps all running code. working perfectly fine. If you walk in to a central office ( ahuge building housing hundreds of 24 inch racks having thousands of boards , each having 48 or 96 DSP's to serve their lines.There is billions of lines of code running , time scheduled, distributed. it does not crash ! Why ? because it is developed properly.If the guys that did the moonlanding would have used code and hardware like it is designed now the saturn 5 would have turned into a ball of goo at ignition.

author: nctnico
author_rank: Super Contributor
timestamp: July 18, 2014, 03:27:20 pm
content: Quote from: free_electron on July 18, 2014, 02:57:25 pmI hope your employer is not reading along! The SMPS project I mentioned a few posts earlier is a perfect example where flexibility saved the day. That project went from 15W to 30W to 70W of required output power. I just scaled the design accordingly. My customer was racing against several competitors to get a product ready which complied with new government regulations. The regulations changing from voltage to current controlled operation killed the competition of my customer.@mikerj: The biggest risk with any switched mode power supply is saturation of the inductor. If the circuit has current limiting in hardware (a simple flip-flop) then there is not much which can go wrong. Before writing values into the PWM registers I have the software test whether the values are within the limits.@poorchava: A simple trick to reduce the amount of time waiting is to test for busy before writing a value. That way the software can prepare the next character or do something else before having to wait until the display is ready.

author: free_electron
author_rank: Super Contributor
timestamp: July 18, 2014, 04:00:24 pm
content: Quote from: nctnico on July 18, 2014, 03:27:20 pmThat is how ASIC silicon is designed !You come with a spec. The design is done according to spec. You alter the spec afterward : that incurs development cost and a new maskset. Masksets are a few million dollar. You learn very quickly not to come with half specs or 'we'll fix that later' designs.

author: dannyf
author_rank: Super Contributor
timestamp: July 19, 2014, 10:49:09 am
content: - I cannot afford to have a delay loop in LCD library code-I am not sure about that. You sure have some slow processes running and the LCD routines can be part of that.state machines are nice as long as the number of states ate limited to a few. Otherwise, it becomes difficult to track.I have never seen LCD routines done that way and have never found it necessary.

author: bobcat
author_rank: Regular Contributor
timestamp: August 11, 2014, 06:13:51 pm
content: You could set up a timer that sets a global flag when the interrupt is processed. In your main loop, check the flag and then do your LCD housekeeping tasks when it is set. This minimizes time spent in the interrupt and allows you to complete other task while waiting.