I like to use a display with spark. LCD or otherwise. What are some suggestions for displays that are compatible and leave enough pins for other uses.
Are you looking for alphanumeric (eg. 2 lines of 16 chars) or graphic (eg 128 x 64 pixels) display? How big do you want it? Do you need touch or not?
For alphanumeric, from 16x2 to 20x4 characters, the cheapest and most common type use a HD44780 controller. These need at least 6 lines to control. However, you can also get them with I2C or serial “backpack” adaptors for only a little more. These would only need 1 or 2 lines to control. In fact if you are using other i2c devices in your project, then a display with an i2c adaptor would need no extra lines at all.
2 Likes
For graphic, one of the cheapest & most common is 128x64 with KS0108 controller (actually 2 controllers). These need quite a few more lines, maybe 11, to control. This could be reduced by use of a couple of inexpensive serial-to-parallel ics like 74hc595, or an i2c port expander. Serial/i2c backpacks are available for these also.
Warning: I don’t know about other types, but the KS0108-based 128x64 displays won’t run on 3.3V. You need 5V to get good contrast.
1 Like
Thanks for the input. I probably should have said what displays were people using with spark core.
I have used the color touch screen on the arduinos, but they used so many ports and memory.
I guess I will go after an i2c version, don’t need color but need multiple line alpha, touch would be good.
Any other ideas would be appreciated.
The LCD used with the Spark Core, as an example, was a 16x2 LCD with a serial backpack. For example.
If you can port a library, another cheap option is to use monochrome LCDs used on phones (Nokia 3310 - I know, this is pre historic). I also don’t see a problem using any standard LCDs that are controlled via SPI.
If you really want touch and don’t mind extra cost, 4D systems makes very nice interlligent displays that use standard serial communications. They have several programming models to simplify UI development. Their libraries, however, may need modifying but their tech support is extremely supportive and may even do it for you, if not guide you.
Another interesting display that supports I2C and SPI and has touch is sold by BuyDisplay on eBay. The price for the large sizes is very reasonable. I have not tried one yet but I definitely expect to.
For less resolution and no touch I have used a cheap 128x64 LCD combined with an “add-on” controller from Digole. This add-on not only does I2C, SPI and serial communciations but adds on-board graphical processing based on the famous U8GLIB libraries. Doing this on-board saves a bunch of code space (about 22K bytes on UNO for example), is fast and for less than $10 is a good deal. I have used it along with their OLED units (with that controller built-on) and I am very satisfied.
Hope that helps!
4 Likes
@peekay1223 Thank you for your suggestions. Now that I know my unit is coming from Spark. I went for the “4.3 inch LCD Module TFT Display,Controller RA8875,Touch Panel,I2C,Serial SPI” per your suggestion on Ebay.
I will try to remember to update what I find, most likely late December.
I look forward to your findings!
Hi all, I’m coming from the Electric Imp community. We use this LCD there: https://www.sparkfun.com/products/9067
In fact, one of my coworkers wrote this lib/driver in Squirrel code: https://github.com/asm/imp_serial_display_driver/blob/master/driver.nut
Has someone done something similar to this in Spark JS? (btw is there a name for the language)
cc @zachary
I just realized that this isn’t like Electric Imp. You’re coding in C++, right?
Yep the Core is C/C++, and specifically has the Arduino libraries, so if you want to control LCD screens, there are plenty of Arduino examples that should work out of the box on a Spark Core.
1 Like
Currently I’m working on an extensible TFT and LCD “library” for Spark. (Obviously it can’t be a real library yet, instead I’ll have a set of functions you can paste into your code that include generic drawing and font functions along with driver functions that support specific LCD, OLED and TFT display chipsets.
This is being ported from my Work in Progress Display and UI Library for Energia, Arduino and Chipkit. [The idea behind that is, instead of having a generic drawing library (UTFT, GFX, etc.) and attaching a display directly to your MCU (Arduino, etc.) over SPI, you have an additional MCU attached to the display, talking to it over an 8 or 16-bit bus, which contains all the fonts, bitmaps and UI elements. Your MCU talks to the display MCU over SPI or I2C and simply tells it what elements need to be displayed where. Thus allowing low power MCUs (or ones short on I/O pins) to drive inexpensive 2.8" to 7" TFT displays at very high frame rates (it takes an Arduino Uno just over 1 second to refresh a 2.8" TFT over SPI).]
Anyway, while working on the Display MCU portion of the project, I’ve basically created an entire generic drawing library from scratch and, after reading over the Core Firmware Reference tonight, I shouldn’t have any problem porting it over to Spark. Initially it will support a few ILI*, SSD* and HX8 based TFT displays, which is what you see on all of the inexpensive Chinese displays from eBay. If anyone is interested in helping me test this out, let me know what model(s) of LCDs you have. I’ll get a GitHub setup for it.
If you want to play it safe with plenty of resources and tutorials, you can try Adafruit’s:
Tutorial here:
@peekay123 Do you think AdaFruit’s code in their github that is based on the RA8875 will work with this display?
See https://github.com/adafruit/Adafruit_RA8875
Yes, I believe it should work though I have not verified it thoroughly against the sample code on buy-display.com. The Adafruit display timing values may need to be adjusted (copied from the buy-display examples). Nothing major I suspect.
Make sure when you order the display, you indicate which interface you want to use, etc. In your case, I believe it was I2C. However, the Adafruit library is specifically written for SPI so if you want I2C, a number a changes will need to be made for it to support it.
Cheers!
timb, it sounds like you are doing what Digole’s backpack does with a PIC processor. Their displays can handle serial, I2C and SPI while the PIC does the parallel interface to the LCD or OLED. I believe they based their graphic firmware on U8gLib, with similar commands and the ability to upload up to four U8gLib compatible fonts to the controller. However, a built-in menu system like M2tklib (designed to work with U8gLib) in not included. Also, it is primarily designed for 160x128 displays and smaller (it can also handle character-only displays). I believe this is the best backpack out there for small text/graphic displays.
I certainly believe there is room for improvement. What kind of functionality are you including? I have not received my Spark Cores yet but when I do, I would be interested in helping. I presently have an Adafruit ST7565 Positive LCD (128x64) with RGB backlight and an ILI9341 based 320x240 LCD as well.
Hi,
I’m not sure how much this will help, but we sell a 128x128 Colour OLED board for the Arduino.
Have a look at Colour OLED Breakout Board which we managed to get kickstarted (and how we found out about the Spark Core).
We are currently selling them for ÂŁ29.99 however, there is no code for the Spark Core yet, as we just received ours!
Kind regards
James
Ah, another Digole fan, nice! I’ve been using their displays for just about a year and really like them. I made a Raspberry Pi I2C driver for them and was actually able to squeeze just under 30FPS animation over that interface. You’re right, they are the best backpacks out there from a cost to performance ratio.
Regarding planned functionality, that depends on what we’re talking about!
Generic Graphics Library: This is what will be used as a base for the graphics backpack and also what I’m porting to the Spark Core. It will include all your basic drawing functions; lines, circles, rectangles, individual pixels, bitmap graphics, fonts, filled shapes and eventually (if the Spark is fast enough) shadow and transparency support!
Graphics Backpack: Essentially, this will be similar to what 4D Systems offers. The plan is to have a web based UI designer, where you can arrange buttons, bitmaps, text, etc. plus add “touch points” and then download a file of that screen and place it on an SD card. You can make as many screens as the backpack’s memory can hold. Your Arduino, Launchpad or whatever will talk to the backpack over I2C or SPI and can call those screens up. If the display has a touchscreen, the backpack will interrupt your MCU anytime a “touch point” is tapped. The MCU will also be able to send raw drawing commands to the backpack as well, or dynamically change the position of screen elements. I’ll be making up several backpack boards that fit 2.8" to 5" displays commonly found on eBay. The backpack source and Gerber files will be fully Open Source (BSD License and Public Domain, respectively).
Hopefully that all makes sense?
So! My spark core came in this afternoon and the first thing I did was to start porting the ILI9320 driver and generic drawing library from MSP430/Energia to the Spark Core. I started around 8pm and two hours later I had it running! It shouldn’t really have taken that long, but I spent quite a bit of time chasing my tail.
The first problem was that you apparently have to save your code in the IDE before compiling it, or at least it seems that way. I was making change after change and it was compiling and uploading but the changes didn’t appear to be sticking (I put a few lines of code in void(loop) to do nothing but toggle a pin every 500ms and my logic analyzer wasn’t showing anything). Finally I reloaded the IDE page and noticed that none of my changes had been saved in the file; made all my code changes again, saved, compiled/flashed and boom, the display lit up like a Christmas Tree!
Next I started optimizing some code and after an upload the LCD stopped working. I reverted the change and still nothing… I spent a good 30 minutes trying to find out what I must have inadvertently messed up until I realized the MOSI wire to the LCD had popped off. (The wire between the Spark and Logic was still hooked, which is why I could see the data.)
Now… Performance! Well, with my alpha quality beta code, I can fully refresh the display in about 500ms, compared to the MSP430@16MHz which takes about 2500ms. (This is over SPI.)
1 Like