HD44780 non-blocking code without BUSY signal?

[Rufus]

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

You 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.

[amyk]

Having an MCU in the feedback loop of an SMPS is just asking for trouble.

[mikerj]

Now try and update the firmware 

If 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?

[mikerj]

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.

Agreed.  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.

[nctnico]

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 ?

You 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.

Having an MCU in the feedback loop of an SMPS is just asking for trouble.

Not 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.

[rob77]

Not 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.

CAPABLE and SUITABLE are 2 very different things
even a sports car is capable of plowing, but a tractor is suitable for that

[mikerj]

Not 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.

I'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.

[free_electron]

You 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 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 developer

it'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.

[nctnico]

You 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 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 developer

it'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.

I 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.

[free_electron]

I hope your employer is not reading along!

That 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.

[dannyf]

- 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.

[bobcat]

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.