Hi, do you have other digital IOs available in your project? You can use any other spare digital IOs to control the LCD. However, you will have to initialise your LCD "variable" differently to reflect your new mapping. Let us know if you have queries as to how to set it up.

If you don't have additional or spare IOs then you should look for an IO extender.

Whoopsie, it was jus a quick hint to allow for a merge on the above code. It's 12:30 in the morning and I am bit jetlaged. Sorry folks. It was a quick snippet of one of my demo apps, but you are right there Bill I will try to be more thorough on coming posts.

I understand! Sorry but I have only seen a fraction of it :-(.

Dig around for an analog mux.

On a mobile, a bit ... to write on.

Iiudr,

The values you can find them in the LCD.h there are about 20 in total.

What I was thinking is if anybody creates more that one with this method it would consume a good range of memory. That is, you create on object for each LCD in your bus.

Perhaps you could use your protocol and limit it to a certain range of commands, or the driver/protocol could be simple but proprietary.

Also you could use the Sparkfun library and make it addressable?

Let me give it a thought.

Cheers

Hi Bill,

I need to give it a thought. For the I2C driver the intention was to have it in the constructor, considering it as an integral part of the LCD. However, only for those that are part of the backpack. This would be like a specialized method of that class.

Trying to control the backlight is a source of a lot of discussion, in the sense that: do you consider the backlight as part of the LCD or not? When you control them using a 4 bit interface, part of is it just another pin?

Anyway, I will go through your comments and give it a thought. I am sure that you chaps have given it a lot more thought than I have.

As per the RW I did give it a though, this being the main reason for not publishing the library as such. In the previous version you just defined the RW to 0x0 and bingo. Here, I need to overload the value so it is not used as a pin.

In any case, right now is not a big deal since in the library it is not used (only in the constructor) and would work.

Give this code a try see if it works, it is more generic, regardless of the LCD being used and its character map:

Code:

const uint8_t charBitmap[][8] = {
   { 0x6, 0x9, 0x9, 0x6, 0x0, 0, 0, 0 }
};

int charBitmapSize = (sizeof(charBitmap ) / sizeof (charBitmap[0]));

  // Load custom character set into CGRAM
   for ( i = 0; i < charBitmapSize; i++ )
   {
      myLCD.createChar ( i, (uint8_t *)charBitmap[i] );  // myLCD is an initialized LCD that you should have done earlier
   }

   myLCD.print ( "\x01" );
   myLCD.print ("C");  

It loads a custom character to location 0 of the LCD GCRAM.

Hi liudr,

as I thought, you've built a protocol on top of the LCD library. So to control several LCDs using a serial line, you most likely have a daisy chain with a small controller on each node.

Now the whole thing about the LCD library, is as follows:
The LCD library is a pure abstract class that implements the generic mechanisms to control a Hitachi HD44780 controller. This means that it implements sending the actual commands to the LCD that it understands. For example, the base class implements:

Code:

void LCD::blink()
{
   _displaycontrol |= LCD_BLINKON;
   command(LCD_DISPLAYCONTROL | _displaycontrol);
}

Regardless as to how the LCD is driven.

Now, each base class implements the initialization details and access mechanisms to actually write to the LCD.
In the example above, the command in every implementation, ends up calling the send. This send is in fact dependent on how you write to each LCD (4bit, 8bit, I2C, SPI or SR).

Therefore, this is not compatible with the way you send commands to the LCD, since there is someone doing these operations on each node. A different story would be if you sent to the LCD commands like: <bot><address><command>\0x80<eot>. This command would arrive to node with address <address> and write to the LCD a command of value 0x80. This would cause the cursor to position at location (0,0). You would then have to send <bot><address><data>Hello world<eot>, and would write the message.

So, what this library would understand is the <command|data><values>. To do this in the library is straight forward. However, on top of the library you have built a small link protocol, i.e. <bot><address><my message><eot>.

Not too sure if I have explained my self  .

So as a conclusion we could say that the library could be extended to process messages like: <command|data><values>, where commands are binary commands sent to the LCD and data is whatever you want to write on the LCD via a serial link, for example. Could you have a link protocol on top within the LCD library? Yes you could. In the sense that, you could have a class called "LiquidCrystal_SerialAddr. This could send LCD messages to the other end in the following format: <bot><address><my message><eot>, where <my message> ::= <command|data><value list>, where the value list for commands are the raw control commands for the LCD. The LCD driver would just need to have in the constructor the address of a remote node.

The only problem here is that you have to build on the receiving end a small "serial to LCD proxy". On the serial to LCD proxy you would have to have an intelligent processor that would  initialize the local LCD, and then read from the serial line, interpret the header, determine if its a command for this LCD, and call the send methods of the LCD accordingly. Broadcast messages, could have 0xff, how would they work: what ever comes over the serial line, I write it to the local LCD and resend it over the other serial line of the daisy chain.

What do you think? Is this in the lines of what you were thinking?

Creo que este puede ser uno de los mejores tutoriales para conectar y controlar un LCD:

http://www.ladyada.net/learn/lcd/charlcd.html

Saludos

chiva, si disculpa pero estoy en un terminal de unas pocas pulgadas, por unas pocas pulgadas y la vista ya no es lo que era... ;-)

Ya he visto, que efectivamente se puede leer, escribir, volcar a fichero, en el manual de avrdude.

Como ejemplo ponen:
avrdude -p m128 -c stk500 -U flash:r:"c:/diag flash.bin":r

Esta noche probaré en modo interactivo "-t" a ver que saco.

Chiva, leyendo el comando veo que es para verificar. Es mas, yo tengo el entorno configurado en modo verbose. Pero la pregunta que hacia era para recuperar una imagen que hay en la flash vía arvdude.

Hasta el momento las estaba recuperando vía ICSP con AVR studio. Alguno de vosotros lo ha hecho/probado?

Una pregunta, se descarga el binario por el puerto serie?

Supongo que tendré que leer el manual de avrdude.

No, tendrías que usar avrdude y un ICSP o ICSP + AVR studio de Atmel. Es la única forma que se me ocurre.

Con el ISP Lo puedes hacer, te vuelca el binario claro.

Hi Liudr,

The LCD library as it stands today is more of a driver to control LCDs than anything else. Addressing can be built on top. For the I2C class LCDs, addressing is implicit in the bus, ie. when you create the LCD object, you tell it what address the LCD is. Therefore, you can create multiple instances of each LCD.

For a serial LCD this might be different since it implies having a different protocol to manage the LCD and logic to control it. It'd be interesting to see you line of thoughts. Please do share.

I will give it a thought to see how it can fit, something like an abstract factory...