mbed lcd display price

The uLCD-144-G2 from 4D Systems is a low-cost ($25 qty. 100) smart color LCD display board with a serial interface. They are also available from Sparkfun. It looks like a nice alternative to the now hard to find Nokia 6100 LCD breakout boards. It has a TTL level serial interface and a reset pin. An optional uSD card inserted in the display module"s socket can be used to load fonts, images, and play videos in response to serial commands.

In the drawing above, the pins are labeled from the uLCDs perspective with TX and RX pins. Mbed RX goes to uLCD TX and mbed TX goes to uLCD RX. So mbed TX goes to the middle pin on the connector which is the uLCD"s RX pin. The included cable seen below is plugged into the bottom row of pins and plugged into a breadboard using the male header pins for hookup. Note that on the cable silkscreen seen in the image below RX and TX have been swapped to indicate the connections needed to the microprocessor pins.

As an alternative, a two row 10-pin M/F header socket with long PCB leads can be used to make a breadboard adapter by cutting off one row of pins. The header socket plugs into the breadboard and the module plugs into the header socket. The second row of pins could also be cutoff on the LCD module itself, but this would preclude later use of the board’s GPIO pins and 3.3V supply for other projects. For more stable mounting, there are 2mm screw holes at the corners that could be used, but the header socket alone holds it rather well given the small size and weight.

The real problem on a breadboard is shorting the 3.3V pin to the reset pin. The board needs a 5V input, but it outputs 3.3V in case it is needed for external devices when it is used in standalone mode. Shorting the other 4 pins does not impede normal serial slave mode operation. Without a reset, the board typically locks up whenever mbed is reset. If the 3.3V pin is carefully bent down 90 degrees towards the center of the board and away from the reset pin, it will plug directly into a breadboard and work as seen in the photo below. The 3.3V pin could be bent back later if it is ever needed, but don’t count on this working more than once or twice before it breaks off. It would be a good idea to just leave it bent over and use a F/M flexible jumper wire to connect to it, if 3.3V from the display module is ever needed later in other projects. This might be the best solution for most users that want to plug it directly into a breadboard, avoid cutting off pins and avoid hooking it up through another connector.

If you are using an mbed plugged into an application board or other baseboard, use the cable provided with the display and stick short jumper wires in one end of the display"s cable connector and the other end of the jumper wires into the mbed header pin sockets that are found on most of these boards.

Initially, it would seem that the existing mbed cookbook 4DGL library would work with this module. It turns out that it has a different processor, Goldelox, and a different but similar command set than the earlier 4D Systems displays supported by the 4DGL mbed library. So a fork of 4DGL was required with quite a few changes in #defines for command values and baud rate divisors. Some functions are not available and some now have 16-bit arguments instead of 8. The basic features used in the demo code below work correctly and some additional work on the new library code could add other features. Support was also added for the use of printf by using the Stream base class and providing _putc and _getc virtual functions. With some minor changes (#defines for number of x and y pixels) the library should also work with the other small LCD displays from 4D systems that use the Goldelox processor. The large LCD modules and modules with touch use a different processor.

Video of demo code. A micro SD card on the LCD module is required for images and videos. The display is actually a bit more colorful and clearer than it appears in the video. Demos include text using printfs, basic graphics commands, a simple bouncing ball animation, computing the Mandelbrot set pixel by pixel, a Plasma wave BLIT, a JPEG image, and a *.wmv video clip.

The more complex Mandelbrot and Plasma wave demo code is not listed here for brevity but can be found after the code seen above in main.cpp in the uLCD144G2_demo program with the download link below.

Fork of 4DGL lib for uLCD-144-G2. Different command values needed. See https://mbed.org/users/4180_1/notebook/ulcd-144-g2-128-by-128-color-lcd/ for instructions and demo code.

The Goldelox Serial Command Manual explains the command set used in serial slave mode. It works in serial slave mode out of the box. Mbed can send it data too fast at higher baud rates and some small time delays (<=1ms) between characters in the library code are needed to avoid dropping characters when sending out some of the longer commands such as text string (perhaps a display UART buffer overflow?). Each complete command sent gets back an acknowledge character and the library code waits for it for synchronization.

After some experimentation with delays, the driver library now works up to the LCD"s maximum supported baud rate of 600,000. For extreme overclockers, the undocumented baud rates of 750,000, 1,000,000, 1,500,000 and 3,000,000 are running this demo successfully on the mbed LPC1768 with the current delay setup. On other mbed platforms, it will depend on the processor"s baud rate clock and divisor hardware. The quickest way to find out is likely to be through experimentation. The mbed serial API computes the closest possible baud rate match. The demo starts out with 9600 baud which should work on any platform. After the first demo screen, the baud rate is changed on the display and mbed with uLCD.baudrate(value). If it hangs in the demo with the message, "Change baudrate", that baud rate is not working on the platform. For fast transfers and more bandwidth, most applications should use the highest baud rate that works.

The Free 4D Workshop IDE (click "download" icon on that page and again on the next page for download) contains tools to translate fonts, images, and videos on a PC into formats used on the module’s micro SD card in response to serial display commands. This data is then stored on an unformatted uSD card mounted on the PC. Most laptops have an SD reader slot and many uSD cards come with a larger SD adapter, if not there are low cost USB to SD adapters that can be used on a PC. After writing the files, the uSD card is then removed from the PC and inserted in the display module. Serial commands from mbed can then load the fonts, images, and play video clips. For speed, the unformatted uSD card uses disk sector addresses in the serial commands and not filenames in a directory to locate this data, and files are stored in a contiguous RAW format. The procedure to create these files with the IDE tools is described in more detail in two application notes:

The module now comes with the serial mode firmware preinstalled, so it is not necessary to reprogram the module"s firmware to use these features as shown in the manuals with the special programming cable. When starting a new project in the IDE tool, be sure to select the correct LCD module and "Serial". This means that the display"s special IDE tools only need to be used to convert font, image, and video files and write them to the uSD card. The optional programming cable is not needed to write to the uSD card from the PC.

Using the 4D Workshop IDE, a Windows True Type Font was converted to RAW format and written on the unformatted uSD card. The initial steps are not intuitive, so be sure to read the font application note. The new font from the uSD card was selected and a double size "hello world" message was printed out to the display as seen in the image above. The serial commands sent from mbed are shown in the code below . The disk sector address varies depending on what files are already on the uSD card. In this case, nothing else was on the uSD card (i.e., 0,0). In addition to the new IDE tools, there is also an older free True Type Font conversion tool that can be used to generate font files for the uSD card or even C include files with font data.

Paint.net was used to resize the original jpeg image to 128 by 128. The IDEs disk partition tool, RMPet, was used to create two partitions on the uSD card, one FAT and one unformatted (50/50 on a 2G uSD) . The graphics composer tool (tool in IDE) converted the image file and created the new image file on the unformatted partition on the SD card. Windows will not be able to read files on a RAW SD card.This tool can also resize images and *.wmv videos for the display by selecting the file and clicking the "edit" button. It reported which sector address to use for the image (listed in project"s *.GC file).

JPEG, BMP, and other encoded image files could also be stored on a filesystem on mbed such as the SD card, local filesystem, or a USB flash drive. It could be read, decoded, and sent to the display using the BLIT (BLock Image Transfer) command. A fairly complex program is required to decode image files and the RAM buffers needed for decoding use most of the available RAM on mbed, so not much is left for any other purpose such as networking or the RTOS. Information on a student project that ported simple open source JPEG and BMP file decoders to mbed for use on an earlier LCD display is available on the project’s notebook page.

It takes a bit less than 1MB/sec for full screen videos and a couple minutes on a PC to initially render the video into the RAW binary format to write it to the unformatted SD card. The original video clip used in the demo was 900 frames with a play time of 30 seconds. The module"s uSD card video player will be able to support higher video frame rates than sending video data over the serial connection from mbed using the BLIT command.

This is working in the beta version of the driver that I will update in a few days after some more testing - (i.e., flush_media and write_byte needed to read in a two byte return error code from the display).

If the LCD display functions are used in multiple threads, or in a main program and an interrupt routine or callback additional steps are needed to insure mutual exclusion when accessing the LCD"s IO hardware. In general, the use of LCD commands in interrupt routines and callbacks should be avoided and all LCD commands should be placed in main. Global variables can be set in interrupt routines that code in main could check to send out any needed LCD commands.

With the RTOS, a mutex synchronization lock from the RTOS should be used to control access to the display in the case of multiple threads. In such cases, I/O devices typically need mutual exclusion locks to avoid problems. For example, one thread could be in the middle of a long LCD display command just at the point when execution switches to another thread (or interrupt routine) using the display. The display could wind up in the wrong state when a new command is sent before the first one is completed. In general, printf also contains non re-entrant code. An mbed RTOS LCD mutex lock code example (demo4) is available using a different LCD with several threads that display data in different areas of the display. If the RTOS is not being used, it is also possible to implement a mutex lock by disabling and enabling interrupts on a processor with one core.

With the 4D IDE tool it is possible to create high quality images of various instrument gauges. Each frame in the video clip stored on the uSD card shows a different gauge setting, and the display frame command can be used to select the correct frame needed for the desired gauge setting. It is possible to achieve a high update rate (higher than using graphics to redraw the gauge). There is a components page and video demoing this feature with mbed.

The module"s firmware can also be changed to work as a standalone module and a development tool IDE that supports and programs it is also available. The IDE needs a special programming cable available separately to download to the module"s flash. It might be possible to setup a serial bridge program on mbed to use in place of the special programing cable.

Not every single possible serial command is included in the library and more commands could be added. The existing commands are likely the most useful ones, but the remaining ones could be added at the expense of a bit more code memory. To aid debugging of new features, messages can be sent out on the mbed USB serial port at 115200. To enable these debug messages, change DEBUGMODE in the *.h file.

It should be possible to add support for a file system driver on the display"s SD card using the serial commands. The FATFILESYSTEM library needs a couple virtual functions to read and write disk sectors and initialize the disk to provide support for new media. It is about the same as the SD card file system driver, but it is using serial and not SPI for transfers. Might even work for an SD card with two partitions, one formatted for files and another unformatted for fonts, images, and videos.

Student projects using the LCD are shown above. They include a Pac Man game using an accelerometer, an IoT Alarm Clock with networking, an iPod-like music & video player, a Nest-like thermostat using a temperature sensor, and a Missile Command game using pushbuttons.

The contrast VO pin seems to have different behaviour on different displays, so you may need to experiment for your display to see anything. I think I"ve seen some work tied to 0V, some to 3.3V, or with a different resistor.

Some displays need a negative voltage at VO. One side of the trimpot is connected to the negative voltage instead of GND in that case. F.i. a Maxim MAX1044 can be used to generate the negative voltage.

The underlying HD44780 chip is a driver used in many LCD character displays. It might sometimes be referred to as Hitachi HD44780U. There are also several compatible clones of this chip in use (eg Samsung KS0066).

Fourth test the test will work ok for a 20*2 lcd, for example if  the text start as column 16 when it reach the end at 20 it will go fine to next line and continue the text

Manually setting clocks on all your electronic devices is such a pain. They all seem to have a different user pushbutton interface and if you don"t have the manual handy, trial and error may be required. Some clocks automatically sync using a special radio time signal from an atomic clock time standard. WWV is one such example of this radio signal that is broadcast in the United States and there are even low cost ICs available to pick up this signal, but it might take several days for them to receive a strong signal indoors. If it is not located near a window, it might not ever pick up the signal. One of the more widely used WWVB receiver modules is shown below. They are found in many battery operated automatic setting wall clocks. There are several projects available on the web using the module"s digital output with a microcontroller to set time. The newer triple frequency CMMR-8 module that can pick up WWVB, DCF77, JJY ,MSF, and HBG may be a bit easier to find. Despite a reputation as clockmakers, the frugal Swiss just pulled the plug on their HBG radio time transmitter to avoid costly antenna repairs and they now use the German DCF77 signal. The mbed time APIs can set and read the internal real time clock (RTC) and even convert the time to a character string for I/O.

Time is also provided in GPS signals. The time can be obtained by parsing the ASCII NEMA strings output by a GPS receiver, but most devices do not have a GPS receiver and GPS will not work inside a large building. Devices such as cell phones with a GSM radio module can obtain the time from the cell service provider. TV signals contain embedded data including time.

If an embedded device has a network connection, it can be used to set the time. This Internet of Things example features a clock that is automatically set to the correct time using a network time protocol (NTP) time server on the internet. It combines two existing cookbook code examples, NTP Client and Text LCD with a small amount of additional code. In addition to a text LCD display, a breakout board or baseboard with a ethernet jack is required. The Sparkfun Ethernet breakout board is used in the example seen below.

If you still get the network error message, make sure that DHCP service is enabled for your mbed. On some networks, you need to add the module"s MAC address to enable the DHCP server to give it an IP address. It times out with an error, if no IP address is returned in about fifteen seconds. If your clock sets to a strange Jul 2010 date, you may have DNS problems or a very slow network (see comments below)

Where N/C is not connected and the top left pin of the TextLCD’s header is GND and the right most pin is D7 in the LCD orientation shown in the images above. The resistor sets the contrast and some LCDs may need a different value or a contrast adjust potentiometer. See Text LCD for additional help, if needed.

(*) Note: some older LCDs may use 5V, but 3.3V is more common on current LCDs. If you cannot find a data sheet to confirm this, try 3.3V first and if the display is still blank (after double checking all other connections and code) it might need 5V. To save jumper wires, this setup uses the four bit interface to transfer ASCII characters to the LCD.

In the video above, the USB cable is plugged in to power up mbed. The code connects to the DHCP server to obtain an IP address and the LCD displays "Get IP Addr...". If the cable is not connected correctly or DHCP is not enabled for the mbed device, a network error message will appear on the LCD. Everything is OK in the video, and an IP address is obtained within a few seconds. Next the code displays "Reading Time" on the LCD and contacts an NTP server to obtain the time in UTC format and it uses this data to set the real time clock. When the time is set, the LCD briefly displays "Time Set" and then enters a infinite loop where the UTC time and date is periodically updated on the LCD.

If you wire up the Internet LCD clock demo and run it, you will also want to run the weather LCD display demo, News LCD Display and Geolocation LCD Display. They use the same exact hardware setup, so you only need to download the new code.

With battery backup of the real time clock (RTC) circuit, the time will not be lost and the clock will continue to run when the device is turned off or when a power outage occurs. A similar circuit is found on most PC motherboards and batteries can last a few years. Depending on the application, devices that have a reliable network connection and use NTP to set the clock might not need a battery backup on the clock. The Vb pin on the mbed module is a low current battery backup input for the real time clock (1.8-3.3V). Some early mbed modules with an extra diode draw a bit more current from the battery, but this has been fixed on newer mbeds. See http://mbed.org/users/chris/notebook/rtc-battery-backup-current/ for more information. This RTC battery calculator will predict battery life given the battery amp hour rating and RTC current load.

A .1f 5.5V supercapacitor such as the one seen below from VB to gnd will work for several minutes on mbed"s RTC, but it also requires several minutes to fully charge. Below around 1.8V on VB with power off, the clock stops running, but the current time is saved and it will restart. When VB drops too low with power off (<.7?), the RTC locks at Jan 1 1900 until a new set_time().

In the video, the real time clock is running and note the seconds value. Near 10, the USB cable is unplugged to remove power to the mbed module and the LCD blanks out as the blue power LED goes out. After about eight seconds at 18, the USB cable is plugged back in. As the clock value reappears on the LCD note that the clock has continued to run during power off and the time and date setting was saved. The .1f supercapacitor near the upper left corner of the LCD provided backup power to the RTC circuit. The clock was first initialized using the earlier NTP demo code, and then another program was loaded for the demo once the clock was set and running. The new code for this demo does not use NTP to set the clock at power up (this code is only the while loop at end of earlier NTP demo code). If the backup battery ever runs down too low, a set_time() command will be needed to restart the clock at power on.

The early mbed seen in the video has a diode from Vb to 3.3V that was removed in later production mbeds. See http://mbed.org/users/chris/notebook/rtc-battery-backup-current/ for more information, photos for confirmation of missing diode, and the circuit. Later production mbeds that have the diode removed from the battery backup circuit will not charge the supercapacitor. If the supercapacitor is charged, run time increases without the diode since there is a significant reverse leakage current through the diode (it was removed for increased coin cell battery life). For a quick prototype test using a supercapacitor on the newer mbeds, add the (removed) diode from Vb to 3.3V on a breadboard or jumper it to 3.3V for a few minutes to charge it and then remove the jumper. The run time can be computed using the voltage range, capacitance, and current draw using this supercapacitor calculator. In an actual device, a more complex trickle charge circuit would likely be used to both charge the supercapacitor, and provide longer run times with lower backup current (less diode leakage). Some RTC ICs like the Maxim DS12R855 have this circuit builtin.

Chapter 27 of the LPC1768 user manual contains additional details on the RTC hardware. It is possible to calibrate the clock to improve accuracy, set an alarm using hardware, and store battery backed up data in five extra general purpose registers. These features are currently not directly available using mbed I/O APIs and it will be necessary to write directly to the registers using the register names from the mbed register definition *.h file or by directly using the register"s address from the manual to use these features.

Once the RTC runs off of battery backup, user data can be saved in the five 32-bit RTC general purpose registers (GPREG0…GPREG4) that will persist across a power cycle and will also not be cleared out by a reset. This can come in handy in some embedded device applications for a small amount of non-volatile critical data. The code seen below displays the low 4-bits of data from one of these registers in the LEDs. It then increments the register value and enters an infinite while loop. Note that the register names (i.e., "LPC_RTC->GPREG0" from LPC17xx.h) are used to directly transfer data to the hardware since this operation is not currently supported by APIs.

As seen in the video above, when the RTC GP register demo code is run on an mbed with RTC battery backup power, the binary value seen in the LEDs will increment each time power is cycled on mbed. The easiest way to do this is to pull mbed’s USB cable out of your computer and plug it back in. Once power returns, the program runs again and displays the incremented value in the LEDs. A manual reset will also increment the count, since it runs the program again (but does not clear out the RTC registers). On this mbed without battery backup or the first time the program is run, all of the LEDs are on. It appears that without backup power during power off, the register values will go to all "1"s at least on this chip.

Let"s make some graphics! In this tutorial, we walk you through connecting your Serial Miniature Graphic LCD to the mbed LPC1768 and making some shapes and text. This tutorial is important as we will use the LCD in the next few tutorials, so pay close attention!

This circuit can be made with parts in the SparkFun mbed Starter Kit. Also, keep in mind that the LPC1768 box contains a USB mini-B cable for programming and power.

To follow this experiment, you would will need the following materials if you did not order the SparkFun mbed starter kit. You may not need everything though depending on what you have. Add it to your cart, read through the guide, and adjust the cart as necessary.

Before connecting the LCD to your breadboard, we recommend you carefully bend the 3.3V pin on the LCD back so that it does not short to the RESET pin. This can be accomplished with a set of needle nose pliers. You will likely never need 3.3V from the LCD, as you can get 3.3V from the VOUT pin on the LPC1768. The other pins in the second row can be shorted to pins in the first row and not affect the LCD"s operation.

For this tutorial, we will be using an mbed library. Libraries can be found under the Handbook for official, mbed-supported libraries or the Cookbook for user-created mbed libraries.

mbed.org user Jim Hamblen modified a 4D LCD library to work with our uLCD-144-G2. We copied (also known as "forked") his library for use in this tutorial.

Click "Import this library" on the right side of the page. You will be brought to the mbed Compiler and asked to import the library. Fill in a program name (e.g. "ulcd_demo") for "New Program" and click "Import."

That will bring you to the Import Wizard page. In the "Search criteria..." on the right type in "mbed" and click the "Search" button (Note: the mbed library is likely already listed, but it is good practice to know how to search for libraries).

With our libraries loaded, we can create our LCD program. Create a new file in our project by right-clicking on the "ulcd_demo" project in the left pane and selecting "New File..."

To communicate between the mbed and the LCD, we are relying on a protocol known as UART. While you can create a program that emulates UART, it is far easier to rely on the mbed"s built-in UART hardware peripherals. We are using pin 9 and pin 10, which are the TX and RX lines, respectively, of one of the LPC1768"s UART peripherals. To read more about UART and serial communications, see this tutorial.

Many software programs rely on "libraries." A library is a separate program or programs that may be called upon to perform one or several functions. We interface with libraries by linking to them in our project (the "Import" step in the mbed Compiler) and using the "#include" command in our main program. This tells the compiler to include the header file (".h"), which makes functions in the library available to us (e.g. the uLCD_4DGL class and methods, such as background_color()). Many mbed libraries can be found in the Handbook and the Cookbook.

Many simple embedded systems use the concept of "setup" and "loop" (more powerful embedded systems often use a Real-Time Operating System). For these tutorials, we rely on setting up some parameters and then looping forever within a while loop. This type of structure is known as a super loop architecture.

Now that you have learned about libraries and graphical displays, you are well on your way to becoming an mbed expert. We will be using the LCD in the coming tutorials, so don"t disconnect it yet!

hello, trying to get the onboard button on an mbed application board to allow me to clear the screen and put new info, the button currently does nothing, i am getting the first 4 parts of info on the screen however this does not change when the button is pressed, i need help to try to make this work

While we have worked hard to improve embedded development tooling in Mbed (e.g. via the Online Compiler), the development for microcontrollers is still very similar to how it was in the 90s. Compilation is slow, and flashing is even slower. When fixing a bug, you need to get the device into the exact state as it was in before encountering the bug. This makes for a very slow feedback loop, which hinders productivity and often pulls you out of the zone.

To make this feedback loop much faster, we’re releasing an alpha version of the Mbed Simulator. The simulator allows you to run your Mbed OS 5 applications directly on your computer, so that you can quickly test and verify applications without flashing them on a real board. This is a valuable learning tool, as you quickly learn how Mbed works. It is also very useful for developing complex applications. Within Arm, we have been using the simulator for work on mbed-http, the Mbed LoRaWAN stack and uTensor.

Note: The Mbed Simulator is part of Mbed Labs. The Mbed Labs projects showcase interesting side projects developed by Mbed engineers. However, these projects are not actively supported by Arm, and may be added, removed or break at any time.

The simulator comes in two flavours: an online version, which runs completely in your browser, and an offline version, which works for any Mbed OS 5 project. The easiest way to get started is to:

The simulator shows the code editor on the left. You can change the code here, and click Compile to run it in the simulator. There is a wide range of demo’ available, from peripheral demos (like the popular C12832 LCD display) to network demos. Yes, that’s right; you can use the full Mbed networking stack directly from the simulator. Select the demo in the dropdown menu and click Load. The demo loads automatically.

Unlike Fast Models, the Mbed Simulator is not fully simulating a Cortex-M device. Instead, it cross-compiles Mbed OS 5 using Emscripten. Emscripten is an LLVM to JavaScript compiler, which takes in a complex C++ project and spits out something that can be run in a web environment. Then, when something should happen with the physical board (for example, pull a pin high), the call is intercepted, and instead of toggling a register, we can toggle a graphical element on the display. This is done by adding a new target to Mbed OS.

A similar approach is taken for components. The moment that the actual communication should take place, we intercept the call and send the data to the browser. For example, with an LCD display, we intercept when the frame buffer is flushed and dump the image to a canvas instead. Everything else in the driver, from font rendering to the API, remains exactly the same. Here you can see both a real device and the simulator running the same animation:

A similar approach is taken for networking. A fake network interface is added while compiling for the simulator. When this interface opens a TCP or UDP socket, this is dispatched to a Node.js daemon (because you cannot open random sockets from the browser), and send/recv actions on this socket are then piped through. This approach allows you to run almost any Mbed OS networking example directly in the simulator, including HTTP, HTTPS (including TLS handshakes), CoAP and NTP examples.

No RTOS. This is a single-threaded environment. You can use mbed-events to make it a bit easier to deal with complex environments, but you can’t spin up multiple threads.

The alpha version of the Mbed Simulator is a great step in the right direction. It massively shortens the feedback loop when developing applications, and because it includes networking, you can use the simulator for more than just toying around. One additional use is that it gives non-embedded developers access to simulated devices for easy development. In preparation for an event, we gave our web developer access to a fake LoRaWAN device to verify that the back-end handling of LoRa events was correct, and that worked well.

We’re currently looking at ways to integrate the simulator into our other tools, perhaps in the documentation, getting started guides, or the Online Compiler. For now we’d love developers to try this out first. If you have any feedback, please raise a ticket on the GitHub project! Also keep an eye on the Mbed blog, as we’ll be publishing an article about the LoRaWAN simulator in the next few weeks.

Jan Jongboom is Developer Evangelist IoT at Arm, and the author of the Mbed Simulator. He’s always trying to force more JavaScript upon embedded developers.