What are some suggested displays (LCD) with Spark Core

Hardware
21

timb, great insight on the new IDE! I like your backpack concept and have a few questions. First, did you consider exploiting the WiFi to provide remote display capability? Second, what about defining “sprites” and doing BLE-type operations to move them around, etc. Is that the “dynamically change the position of screen element”?

One thing I don’t like about the 4D is that unless you are programming in raw serial, it is impossible to change the appearance of screen elements (eg. color) without creating multiple versions of that element. It would be a good feature to have that ability at a higher level. One thing I do like about 4D is their pre-defined Visi-Genie objects which makes creating screens very easy.

For me, the more “intelligence” that’s shifted to the backpack, the better. User interfaces take up a bulk of the code and the thinner it is, the better IMO.

:smile:

22

I’ve got a several page design document that lays out how the system will work, various commands, etc., so I’m going to try to condense it a bit for you. :smile:

Regarding exploiting the WiFi: I’m not building the Graphics Backpack around the Spark Core, because it doesn’t have enough I/O for a 16bit bus. The plan is for the MCU on the Backpack to be an MSP430F5529 @ 25MHz, if I can squeeze enough performance out of it. Otherwise I’ll use a Tiva C or STM32.

I had thought about making a version of the Backpack with a CC3000 on it, which would essentially turn it into a wireless display, but I could add a footprint on the Backpack for the Core. That way you could plug it in and boom, fully wireless display! Perhaps add a Lithium Ion charger and gas gauge as well, plus the standard pack connector (or at least the footprint for the parts). So the backpack would still have its own MCU, but the core would dock right onto the board and be a fully self contained unit! :grin:

Regarding the backpack programming features: Essentially, instead of using software like 4D Systems does, I’ll setup a nice little HTML5/CSS3/AJAX webpage where you’ll be able to do all the design and configuration at. Like the Visi-Genie objects, I’ll have a good number of pre-made widgets available; buttons, text input blocks, keyboards, text displays, dials, gauges, bar graphs, 7-segment number displays, analog & digital clocks, popup menus plus some other stuff I’m probably forgetting. In addition you’ll be able to upload static and animated PNG files (which will be converted server side to [most likely] RLE encoded arrays), plus you’ll be able to draw basic shapes (circles, squares, rectangles and lines).

Each widget/object will have unique ID (user editable) assigned to it so that the host MCU (Arduino, Launchpad, Spark Core) can change any property of it (text/number, color, size, position, opacity and whether it’s displayed or hidden). Each “screen” will also have a unique ID so the host can switch between them; I think layer is a better term for it.

So, each layer will contain widgets and objects, all of which can be hidden, shown and fully modified on the fly by the host MCU. When you download your finished design from the webpage, each layer will be a separate file (most likely they’ll all be zipped together for you server side). At this point you’ll dump the files onto an SD card, put it in the display and one of two things will happen—(A) You’ll keep the card installed and the display’s MCU will load the active layer into its own memory on the fly—or—(B) The MCU will copy all the files into onboard FRAM and pull the active layer from there. Option B should be a lot faster but will require a parallel bus (plus the timers to handle it) so it might not be feasible; A might have to suffice, I’ll just have to do some testing.

Something just occurred to me, if you have a Spark Core plugged into the Backpack, you could download all the data directly from the editor website to the Backpack! You make all your screens and stuff, enter your Core’s ID and then the website would install some special firmware that would allow it to pass the data straight through to the Backpack’s MCU, which would write it directly to the onboard SD Card. Damn, that would be killer.

Okay, this post has gotten a bit long (hey, you asked for it) so I’ll just talk about one more thing real quick: User Input. Since most of these inexpensive eBay TFT displays include resistive touch panels, I plan to fully support them on the Backpack itself. Any widget/object can be flagged as touchable; since the Backpack already knows the coordinates of the various widgets and objects on the screen, it takes nothing for it to respond when those areas are tapped.

The host MCU will talk to the Backpack via Serial, I2C and SPI plus I’ll also have an optional IRQ line so the user doesn’t have to continually poll an interrupt register on the Backpack.

Okay, I think that about covers the basics. Seem like a good, sane set of features? I’d be happy to go into more specifics if you have any questions. :smile:

1 Like
23

@timb just wanted to say thanks for reporting the bug that ‘flash’ doesn’t save your code first; we’ll fix this ASAP.

24

I like it! You will have a lot more bandwidth and room to play with the Tiva C or SMT32. My gut tells me the 4D displays may do some file buffering off the SD to make their objects animation smoother. In the same vain, your animated PNG approach could do the same. The layer concept could be cool if you can have more than one layer on-screen at a time, especially with transparency.

One of the issues I see with the 4D is that it is ONLY serial and I have seen users wanting a very customized UI via the serial/gfx environment not get the performance they want for smooth animation, especially for larger displays. The use of SPI, combined with a fast processor and a solid file/frame buffering approach could really address that.

The use of the Spark Core would make it amazing, especially for remote programming and displaying. I really like your web IDE concept, especially since it is OS independent.

Let’er rip!

:smile:

25

Awesome, thanks. It’s sort of a PITA needing to save the document first. Ideally you guys won’t have it auto-save before flashing. Saving should be 100% manual if you don’t have a versioning system in place. (Is that planned? I’d love the thing to autosave for crash/disconnection protection, but have my manual saves actually be a “commit” that’s fully versioned, so I can see each of my saves from the first to the last. Flashing/Building should just pull the code right from the editor and not commit a new revision or be processed as an auto-save.)

26

Version control is planned; we’d like to run it off of Git, and even have a Github integration. That’s definitely later down the road, though.

28

Git would be nice, but being able to view (and roll back to) each manual save is a crucial feature that needs to be implemented sooner, rather than later. On a PC, I can just do a Save As… to keep multiple versions, if my OS doesn’t natively support it (i.e., OS X Mavericks).

There’s a pretty neat, lightweight code editor for OS X called “CodeRunner” (available on the App Store) that has a neat little tabbed interface, supports OS X versioning, does syntax highlighting and, most importantly, supports custom scripts for compiling and running the app. I think I’ll setup a script that uses the Cloud API to upload, compile and flash a source file to the Core, so I can have versioning right now.

(Perhaps I could have it parse a /Custom Libs/ section of the app source and concatenate the libraries and source all together in one big file before upload, to get around having to keep everything in one big file for now.)

Anyway, I digress…

29

I think the Tiva C series might offer a high-speed memory bus option, if so I could add onboard SRAM or something and cache all the assets from the SD Card on initial power up.

Like I briefly mentioned before, I think FRAM would be absolutely ideal for this use if I had a chip with a high speed memory interface. The issue is, it’s kind of expensive in larger sizes… So I’m thinking, maybe instead of copying all the SD Card data, it would just cache assets for the currently visible layer, and any layers the host MCU instructs it to pre-cache (which could be done in the background). I dunno, I’ll have to think about this some more (suggestions welcome), but I know for sure at the very least the currently visible stuff has to be kept in some form of RAM, because you can’t be doing a slow SPI read from an SD Card 30+ times a second.

So far as layers go, I want to add dynamic transparency for widgets, objects and layers, but that will be a down the road feature I’m sure, as it gets really complicated when you have all these objects freely floating around, being computed on the fly. See, the 4D Systems stuff and MikroE’s Visual TFT software provide transparency support for each screen/layer, however, it’s baked in at the time you generate the code for that screen, which means elements can’t be moved on the fly, same goes for shadows. So, dynamic GUI candy will come at some point, but I see no reason the web editor can’t support a static model from the get go, for those that want it!

So after playing around in DipTrace a bit tonight, I’m fairly confident I can make one Backpack board that can accommodate three different sets of female header to support the following: Spark Core, Launchpad Booster Pack and Arduino Shield, If I do that then I’d have one big row of user solderable male header pins on one edge of the Backpack, which would breakout all the I/O pins from whatever MCU the Backpack Shield/Booster/Spark it was docked to.

Though, I’m not sure how many people would really need a display like this to be a Shield, unless maybe they’re prototyping and just want to stack a lot of stuff without wires running everywhere. Then again, 4D Systems doesn’t even offer a real LCD Shield, just a crappy little straight-through adapter you plug a wiring harness into…

At the very least, I will add a footprint onto the Backpack for the Core. Then the end user could just solder down two rows of female headers for the Core to plug into!

In other news, I’ve got drawing routines working on the Core now! The first thing I had working (night before last) was just continually flood filling the screen with random colors over and over again. I got that optimized a bit, which gave me a nice little speed bump. Tonight I started working on drawing shapes! I’ve got some high speed circle drawing going on (very simple code, too) in addition to two out of 4 sides of a rectangle. :sparkles:

By the end of the weekend, I’d like to have basic drawing elements in place (geometric shapes and attributes for them like line thickness, line color and fill color) in addition to either basic fonts or bitmaps.

1 Like
30

timb, I think the issue with the FRAM vs other RAM comes down to cost. You will have to compete with 4D and others (buy-display has some “dumb” RA8875 LCD modules). Nonetheless, caching is not an option. Sounds like you’re on the right track. As for transparency and sprites, I agree with the baked-in concept. Adding the dynamic capability later would be a big differentiator.

I remembered this funded kickstarter project you may want to look, if only for inspiration or curiosity.

One thing I notice missing in most graphics libraries is polar-coordinate based stuff, such are arcs, radials, etc. These are REALLY useful for drawing analog instruments, etc. You may want to consider adding this.

:smile:

31

Wow. I expected to spend all Saturday figuring this out, but it took 5 minutes.

I bought a 16x2 3.3V LCD with serial backpack from Sparkfun.

Connect 5V (it’s really 3.3V), GND and your Core’s TX to their RX.

I read their directions, except that you don’t need to include any headers, and you can call all the begin and write methods directly on Serial1.

That’s about all there is to it. It works.

1 Like
32

Topfunky, if you want to do graphics, [Digole][1] has some great serial displays that are just as easy to use. I have not received my Spark Cores yet but as soon as I do, I will be adapting their library. I ordered their new OLED 160x128 serial display and I look forward to using it.

:smile:
[1]: http://www.digole.com/

33

Thanks for the tip! A graphical display is definitely next on my list after I figure out how to build a transmogrifier and a time travel machine with my Spark Core.

34

I second the recommendation for Digole’s serial displays. You can find them on eBay as well, where some ship straight from Canada (as opposed to Hong Kong).

Another option for a nice, easy to use graphics LCD is the Nokia 5110 84x84 SPI LCD. They’re almost universally supported on pretty much every platform known to man! You can even use them as a console display for Linux on the Raspberry Pi/Beagle Bone via the FBTFT project! I might take a crack at porting that library over this evening when I need a break for working on my library.

35

Yeah, like I said, it would be nice because of the speed, non-volatile nature and essentially unlimited R/W cycles. I just checked the price, and it’s pretty outrageous once you go over 1Mbit (~$50). I think the best way to do it is just use cheap as dirt SRAM and load assets off the SD Card on startup. After thinking about this last night, I had an interesting thought: Generally, all of these LCD controllers support an 8080 style memory interface mode; 8, 16 or 18 bit data bus plus command/data, read and write lines. Essentially, data is clocked in and out of the LCD’s (built-in) GRAM (Graphics RAM) through this interface. After doing some reading, it appears you can drop SRAM on this same bus, give it a read command and the LCD a write command; this way the memory directly clocks the data into the LCD. For speed, that would be the way to do it.

Speaking of the Gameduino 2, that FTDI EVE chip was something I had initially looked at for this project, but it only supports LCDs that have 18-bit RGB inputs, which not a lot of these modules you find on eBay have. Well, let me rephrase that: They do have an RGB interface, but it’s not exposed on the PCBs they’re attached to. Here’s a good example: I’ve got a HY28A LCD from Haoyu, which uses an ILI9620 driver chip. If you check the datasheet, it supports 8/16/18-Bit i8080, 18-Bit RGB, RGB+VSYNC and SPI modes. The variations of the 8080 modes and SPI are selected by shorting 4 special signals. while RGB mode is selected if the HSYNC signal isn’t grounded.

Now, on the back of the board the LCD is mounted to, they have headers on both sides of the board, with the touch panel and LCD SPI outputs, plus D0-D17. One would think they’d have some 0-Ohm resistors or solder bridges to select the mode, right? Nope. They physically sell two versions of the board. One with just SPI hooked up and one in 16-Bit mode. From the outside, both boards are physically identical, same silkscreens, same number of headers. Literally the only difference is how many of the flex cable pins they solder to the board (and which mode selection pins they solder together). Le Sigh
Apparently they make a newer version of the boards now with an ILI9625C, that does have the interface mode selectable on the back, so you can change it between SPI or 8080 parallel mode yourself. However, despite having 6 or 7 of the header pins free (marked NC), they still don’t break out the VSYNC, HSYNC and DOTCLK signals, making it unusable in RGB interface mode… Facepalm
Now, I’m sure I can get just the LCD and put it directly on the Backpacks I’m making, but it’s kind of a pain in the ass for prototyping.

Anyway, that Gameduino 2 is pretty cool, though I’d preferred it if the board had some buttons, two analog sticks and maybe an Arduino Due processor on-board. That way you’d have a powerful, all in one DIY game creation platform. Though, for what it is ($60 Arduino compatible FTDI EVE powered 4.3" LCD) it’s pretty good!

I’m actually still considering that FTDI chip instead of rolling my own, as it has a ton going for it: 256KB RAM for assets, MIDI and WAV playback, lots of widgets and alpha blending. I’ll get an Evaluation kit and find out one way or another. Even with the EVE chip, you could still cache the assets from the SD Card to the built-in RAM, and use the web editor for building screens.

Without this being a long, rambling post (oaky, longer) I’ll just say this with regards to coordinates, plots, radials: I agree and have that high on the priority list. If I go with my own chip, I’ll need the it for analog gauges, clocks and so one. Plotting a waveform will be great too as I can se a lot of uses for that. (I’ve got a simple Electronic Programmable Load project that I’m putting in a case and adding a display to; this would make a sweet display for it, especially with the ability to plot a waveform to show the discharge curve of various batteries or whatever.)

36

I almost backed the Gameduino but I already had too much on my plate. For the price (like the Spark Core), it was a steal of a deal and included the LCD! Using the EVE process is a great idea. I would love to see it doing instrumentation using its “widgets”. The built-in video and JPG decoders along with sound make it very compelling. Keep me posted!

:smile:

37

Did you see Digole has a 1.8" Color OLED screen out now?

Looks pretty slick! They’re using a pretty beefy 64MHz PIC18F26K20 as well. $30 is a damn good price, too!

38

I was away from this post trying to earn money to support this stuff and I get back and this post has exploded, it was an amazing read.

Update on my project. I did order the 4.3 display from buydisplay and put on spi but it will be 2-6 weeks to get here and was hoping to work on it over Christmas break. So I ordered from adafruit a 2.2 display spi so I can learn and play once my spark core comes.

1 Like
39

I pre-ordered one when they were on special for $15 and got it yesterday. VERY nice. Even at $30, it’s worth the price! I use the Digoles with serial since it uses a single pin (Tx) and runs at 115Kbaud. I will be playing with the SPI and I2C modes at some point. One thing I like is the ability to download up to 4 fonts (U8glib compatible) and a start screen graphic into the display. I would HIGHLY recommend this unit to anyone… along with the Spark Core of course!

:smile:

1 Like
40

We’ve just got back some prototype shields we’ve designed to use the Sparkcode and our OLED module. Thought you might like to see a couple of pictures. We’re hoping to get these out on sale early in the new year.
If you’re interested, keep an eye out on our web site

OLED Shield(Populated) OLED Shield (Unpopulated)

James

2 Likes
41

Awesome! Can’t wait to buy one :slight_smile: