lcd using slave avr

hamedhamedi · Joined: 12 Feb 2012 Posts: 70

Hi
In many industrial cotroll board,the lcd drive with a slave microcontroller.
I didnot find why it is,unless i get found that lcd is very slow.
Now i want to use a 2*16 lcd with a real time hardware use to drive mosfet.the delay in my code get a very dangerous condition.so i want to use a slavemicrocontroller to display 6 single variabe.
I dont know how to comunicate with slave microcontroller tosend 6 single variable!
One way is spi,another is i2c.but i dont know which one is easier to send 6 single variable.
And also i dont know who to identify the ariable from each other inslave!
Any idea and sample code will help me.
Regards

(BASCOM-AVR version : 2.0.7.8 )

bzijlstra · Posted: Fri Jan 30, 2015 12:02 am Post subject: i2c LCD...

In the Bascom-Arduino part of this forum. There you can find a piggy-back board for i2c.

With an adapted library.

And perhaps a search for the other questions.

Have fun
Ben Zijlstra

hamedhamedi · Joined: 12 Feb 2012 Posts: 70

Thanks.
Can it improves the time of writing to lcd or it just reduce pinout?
Regards

snipsnip · Joined: 10 Feb 2014 Posts: 66 Location: Melbourne

Is the slave processor on board or remote?
If remote - how far?
Hardware uart?
How many spare io pins on each processor?
6 x separate variables (byte,word,long etc?) or 6 x single length separate variables?

How slow is the LCD? are you using CLS / better to just overwrite.
How much time do you have to send the data?

Just some thoughts
cheers
Simon

hamedhamedi · Joined: 12 Feb 2012 Posts: 70

Hi snipsnip
thank you

[/quote]Is the slave processor on board or remote? If remote - how far?

JC · Joined: 15 Dec 2007 Posts: 482 Location: Cleveland, OH

I think you should think about the overall structure of your program, and if it is possible to "speed it up".

Using a serial connected slave LCD is certainly possible, but you would have to use a hardware I2C or SPI or USART module in order to see any real speed gains.
If you used a software I2C, SPI, or USART, it would be slower than just outputting data to the LCD itself, connected directly to the micro.

If the critical timing part of the program is interrupt driven, then writing to an LCD in the Main Loop should not impact the critical processing.

If the LCD routine is too long as it is outputting a 16 character string for each line, then one could certainly break this up and output one character at a time.
There are several ways to do this, but there is some overhead no matter which approach is taken.
A typical approach is an interrupt driven buffer.

Several additional thoughts:
If you do elect to use a slave uC, don't discount the USART.
Bascom already has the ability to do interrupt driven, ring buffered USART communications, making this easy.
You would still need to be very careful in how the program was structured, however, so that this did not slow down the time critical code.

Also, note that the Xmegas run at 32 MHz, giving you twice the processing power of a 16 MHz AVR.
The Xmegas also have priority interrupts.
The time critical code could use the high priority interrupt, the LCD display routines, could use the low priority interrupt, to either send data over a serial communications link, or just to feed the LCD one character at a time, (via a once every 1 mSec interrupt, or similar).

Remember that LCDs are "slow" in terms of the micro running in the MHz clock range, and the human eye is very slow.
One can have a "slow" LCD driver routine that is still so fast that the human can't tell the difference.

JC