LCD_screen Library Suite

Hi!

Here's the 2nd release of the library which includes bug fixes (font size), and enhancements (touch).

A new library called button provides the basics for buttons management. It works hand-in-hand with the Serial_LCD library.

Enjoy :slight_smile:

Lookin' good, I'm still nowhere near using my displays yet but am paying attention :slight_smile:


Rob

Nice, I wish I had seen this before I wrote my own library, although I needed the goldelox SGC command set.

I did implement all of the SD card functions in the 4D command reference (my thread is at the bottom of the first page ATM) but I didn't really find anything unusual about them compared with any of the rest of the commands. The only one that needed any special handling was ReadSector, for which I found I needed to increase the Rx buffer to be much larger or else I would lose 75% of the block (which in turn would cause my version of nacAck() to lock forever, so I added a simple timeout to prevent the worst case).

@extent,

Thank you for sharing!

I haven't investigate the SD card functions yet, so I'll pick them from you library :slight_smile:

@all,

Here's the link to the thread about extent's 4D library.

Main difference lies on the 2-byte coordinates for the 320x240 screen versus 1-byte coordinates for the smaller than 255 pixel screens.

Ya SGC commands for both generations of chips are identical in almost every case. The other one that I remember that's different are some of the control flags, like the goldelox does not support the landscape setting.

Hi!

Here's a real model where the touch-screen acts as a dashboard to manage the stepper motor. The model combines an Arduino board and fischertechnik building blocks.

For more details, please read

On the Arduino side, an I2C stepper controller.

On the fischertechnik side, a stepper motor model.

Enjoy :slight_smile:

I noticed in the example file that you draw your own buttons using your button.h/button.cpp. Was just wondering why you chose to do it that way instead of using the button drawing commands built into the 4D Serial language?

Hi!

Actually, for two main reasons

  • there's no size management, since

4D LABS—PICASO-SGC Command Set—Software Interface Specification:
the size of the button is automatically calculated and drawn on the screen with the string text relatively justified inside the button.

  • there's no built-in touch-screen management for the button
    boolean check();

Best regards,

I guess they thought auto sizing is a good idea, which on occasion it is, but I think fixed button sizes are better most of the time.


Rob

Thanks for the reply. Just starting out with your library - it makes it all fairly easy.

Hi!

I bought a more powerful Arduino-like board with a 80 MHz controller: the chipKIT UNO32.

Porting my Serial_LCD.h library for the from Arduino to the chipKIT UNO32 wasn't a major task, provided some precautions:

  • Coping with implicit types as int, which don't mean the same on a 8-bit environment and a 32-bit one: all variables require explicit types.
  • Adding full support to the chipKIT UNO32 hardware second serial port, without loosing the software emulated serial port.
  • Making the main Serial_LCD.h library immune from hardware / software serial port: I added an abstraction layer.
  • Trying to understand why an #if #include statement doesn't work.
  • Dealing with over-speed, a 80 MHz board working with a 12 MHz display.

Enjoy :wink:

CAUTION The latest NewSoftSerial release 11 is required for the abstraction layer. Although the library is now named SoftwareSerial, rename it to NewSoftSerial.

See NewSoftSerial 11 (beta) | Arduiniana

nice, the bump up to 230400 baud on the hardware serial port really helps frame rates as well.

I got around needing a serial proxy by just passing a reference to the Stream object type. Both the Arduino hardware serial ports and NewSoftSerial (beta 11 and newer) are of this type, so you can setup whatever kind of serial port you want, pass it to your constructor and everything just works.

@extent,

Thank you for the tip about the stream type of the new NewSoftSerial.

However, because NewSoftSerial relies heavily on AVR intricacies and interrupts, it is not compatible with chipKIT.

I'll give a try to the beta 11.

Best regards,

Hi!

Thanks to the 4D Labs support, the new release 6 implements sound playing.

Actually, the 4D Labs ?LCD-32PT(SGC) 3.2” Serial LCD Display Module requires up to 250 mA, more than the Arduino built-in regulator could provide, when it plays sound.

Read the full report with video and sound!

A clear extension for buttons is a dialog window.

Release 7 features a modal dialog window with

  • 1 icon
  • 1 title
  • up 3 lines of text
  • up to 3 buttons
  • screen is saved before the dialog opens and restored after

I provide the library with an example and a video. Enjoy :wink:

Graphic intensive use of the LCD display with the fast 80 MHz chipKIT board overloads the screen micro-controller.

Especially, sent and received messages overlap and the ACK / NACK protocol is lost :(.

Hence a solution to protect the serial connection from overload and obtain an nicely synchronised conversation.

The library reaches release 8 with overload protection :).

I received a lot of mails and messages about the Serial_LCD library.

Among them, some deal with basics, as connection, hence this post.

Here's the general layout: an Arduino Uno and the µLCD-32PT(SGC) screen.

Follow to step-by-step guidance so it just works!

I think I figured out what may happen to matinzk.

CAUTION The latest NewSoftSerial release 11 is required for the abstraction layer. Although the library is now named SoftwareSerial, rename it to NewSoftSerial.

See NewSoftSerial 11 (beta) | Arduiniana

I placed the code of the library on http://github.com/rei-vilo/Serial_LCD.

The Serial_LCD library release 9 can now address 3 serial port implementations:

  • hardware serial,
  • software serial, with NewSoftSerial release 11
  • I2C serial, through the SC16IS750

The three classes are derived from the Stream class with specific functions overwritten. Code and example are available on GitHub.

But including all those classes on the proxySerial library —and on the main program— is rather inelegant and redundant.

So the idea would be to declare the serial port on the main program only and pass the objet on to the proxySerial.

What to use : Callback? Reference? Functor? Unfortunately, such advanced concepts are out of my reach.

I greatly appreciate your help!

Thank you :slight_smile: .