LCD disables interrupt...

[rikotech8]

When I compile this code I get this warning;
Warning 216 Interrupts disabled during call to prevent re-entrancy(@delay_ms1)
Warning 216 Interrupts disabled during call to prevent re-entrancy(lcd_sent_nibble)
Warning 216 Interrupts disabled during call to prevent re-entrancy(lcd_send_byte)
and my program is never being interrupted.
Here is my code:

[Mike Walne]

Printing and writing to LCDs in ISRs is inherently a bad idea.

With ISRs you need to get in, get out ASP.

In other words, set a flag and print/write LCD in main.

The real reason for your problem is that the LCD routines include delays.

You're thus calling for delays both in main and the ISR, hence the recursion problem.

Mike

[gpsmikey]

You may also find you need a delay before the "lcd_init()" call - those things typically tend to wake up quite a bit slower than the processor does - sometimes a second or more.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[rikotech8]

Ok but I want to print my text with slower frequncy then my while(true) cycle has. My while(true) cycle overflows every 1mS but I want to update my lcd text every 100mS. So if I put printf inside main I will have updating every 1ms which I don't want to.
Thats why I use timer interruption to call printf with diferent frequency that I want.
_________________
A person who never made a mistake never tried anything new.

[Mike Walne]

One of the arts of engineering is to find ways round this sort of problem.

For starters, try things the other way round:-

Use the interrupt to initiate your fast (1ms) loop.
Then (as I suggested) put the LCD code in main with the 100ms delay.
OR
Time everything in multiples of 1ms chunks.

Mike

[Ttelmah]

As has been said, just use a counter.

However as a comment, most text LCD's won't update at 10Hz. They commonly have a 'refresh time' (time between receiving new data and displaying it), of 250mSec.
Cut the rate you update the display to no faster than 4Hz.

Best Wishes

[rikotech8]

Thanк you guys for the useful advices!
I thinк I am going to use counter which will increase its value every cycle. So every 100th cycle I will text my massage thus I will avoid interruption.
_________________
A person who never made a mistake never tried anything new.

[sabonjuan]

Hi, i have the same trouble, but i can not put a flag on main because i have a lot of functions very long, and with a lot of user interface. this warning can cause many problems later or just a warning?
Copy my interruptions code (sorry, i don't write on english very well)

[Mike Walne]

[sabonjuan]

Thank you mike, I added this code that I thought would be useful, but now i think that may confuse.
My problem is I can not put a flag in the interrupt for lcd_reinit what the code is run on the main, because i have a lot of processes that shows information, and do not return to main until this process finish. I can not add all the code because is too long.
Exist any other chance for remove this warnings? or, this warning can give me any error on the future?

Sorry i am using google translate.

Thank you Mike!
_________________
Abuelito dime tu, abuelito dime tu!
TU!!!
Gracias abuelito!

[Ttelmah]

In your case, not really.....

Think about it for moment. Imagine you are writing to the LCD in the main code, and while inside this routine (so LCD lines are being controlled by the main code at this point), you call an interrupt that also tries to write to the LCD. The LCD is half way through a write, and suddenly starts to try to do another....
Anything like this that controls hardware, has to block any other function from controlling the same hardware at the same time.

Now for other types of things, there are ways of avoiding this. The delay for example, can avoid problems by having two sets of delay code. But when dealing with a single set of hardware, no, it can't be avoided....

There is a solution, but it gets slightly more complex.

Some time ago, I had to write a message to an LCD, from inside an interrupt handler, and also do messages from other parts of the code. Like you, because of the nature of the code, I wanted to retain the ability to actually trigger the display from the interrupt, wherever the main code 'was' at the time. The solution I used, was a 'message queue' (buffer). I got rid of the standard LCD code, and instead did a version that wrote one character to the LCD, if one was waiting, from inside a 200Hz interrupt. Now if you look at the timing diagrams for conventional LCD's, all commands take less than 5mSec (1.64mSec worst case for a CLS). So the interrupt can simply write one character to the LCD, without checking timings etc.. The only code that had interrupts disabled, was the routine to write characters to the buffer (which took a few uSec only). So 'main' puts it's messages into the buffer, and the interrupt does the same. Interrupts are disabled while main writes to the buffer, but the delay is tiny. This way the code doesn't have to wait for the slow LCD.
Messages have to be complete 'entities' for this to work (so for instance, a 'goto', followed by the characters to write).

Best Wishes