gCore (II) - a dev board for portable GUI gadgets

I finally got around to making a 3D-printed enclosure for the Galaga port.  I got to use the SVG import function of OpenSCAD to make a nice curve on the enclosure sides.   The OpenSCAD and STL are up on the github repo.  I think it came out pretty well but probably should be painted...

TL;DR: I found a pair of bugs related to gCore's Real Time Clock (implemented on the EFM8 RTC/PMIC co-processor).  There's a new version of the EFM8 firmware (version 1.2) and instructions how anyone with an older board can get updated at the end of this post.  The bug is fixed in all boards shipping in Sept 2023 and beyond.

The Bugs

I added support for Caller ID to the weeBell bluetooth code.  Caller ID sends the date and time as part of the message to the phone so I also enabled use of gCore's RTC to set the system time when powered up.  During testing I noticed that the gCore RTC would lose tens of seconds per day.  This lead to an investigation that ultimately found two issues with my version 1.1 EFM8 firmware.

The first problem is that the RTC timer preset was wrong.  The RTC timer is configured to interrupt once per second and is clocked by a 32768 Hz crystal.   I set the preset to 32768.  I had missed that the Silicon Labs documentation said I should set it to 32767.  But it turns out even their documentation doesn't account for a hardware bug in the chip and it should be set to 32766.  Thankfully someone posted this to a Silicon Labs forum.  The off-by-two error lead to a timekeeping error of about -5 seconds per day.  Unfortunately I didn't see this during testing.

But that still didn't explain why I was seeing much larger errors.  Because the clock was always slow I immediately suspected the code was missing the RTC interrupt somehow.  Turns out that assumption was correct.  The RTC interrupt is not latched.  It only exists for one clock cycle (1/32768 = 30.5 uSec).  So if the code is servicing another interrupt with equal or higher priority and that service takes longer than 30.5 uSec then the RTC interrupt will be missed.

The EFM8SB2 has two levels of interrupt priority and the RTC interrupt has high priority.  But the I2C interrupt also has high priority because it occurs at least once for every byte transferred on I2C and I want to minimize clock stretching during reads.  I had done analysis and testing to characterize the I2C interrupt and thought it would always finish quickly enough.  However I committed a cardinal sin.  I added more code after the analysis and didn't re-analyze.  And now the I2C interrupt could take, under certain circumstances, more than 30 uSec to execute.

The weeBell bluetooth code polls the EFM8 via I2C fairly often, multiple times per second, looking to see if the power button has been pressed so it can turn itself off.  It's also reading the battery voltage and charge status for the GUI.  It turns out that every few hundred or thousand reads one slow I2C access would line up with the RTC interrupt and the RTC interrupt would be lost.  The RTC would lose a second.

The slow I2C ISR routine had to do with how I guarantee atomicity for multi-byte values.  The fix was to restructure the code so the atomicity was assured by non-ISR code and the ISR simply does nothing but access an array to get data for read responses.

Lots of testing later and I'm pretty confident that the RTC is now good to go.

Updating Existing Boards

I feel badly about letting this set of bugs through and want to make it right with anyone who is impacted.

Users of boards obtained before Sept 2023 who want to upgrade their EFM8 firmware from version 1.1 to version 1.2 have the following options.

1. Send the board back to me and I'll re-flash the firmware and return the board to you.  You pay shipping to me and I'll pay to ship the board back to you.
2. Use a Simplicity Labs USB Debug Adapter and the programming software in their Simplicity Studio to load the hex file from the repository onto the EFM8 by connecting three wires from the Debug Adapter to the board.
3. Use a 3.3V 32-bit Arduino board (PJRC Teensy 3/4, ESP32 or RP2040) as a programmer with a sketch in the repository to re-flash the EFM8 by connecting three wires from the Arduino to the board.

Detailed instructions are in the repo too.

The EFM8 is programmed via a C2 interface which consists of a clock, data and common ground.  These are accessible on gCore via a set of testpoints.

It's easy to use three common "Dupont" style connector wires to connect the Arduino or USB Debug Adapter to gCore without soldering.

Then after compiling and loading the sketch the firmware can be updated in just a few seconds by typing the character 'P' in the Serial Monitor and hitting return (or clicking Send).

One idea I have had is to create a set of gCore shields which like various Arduino shields and Pi Hats add hardware functionality for specific applications.  The first board is called the gCore POTS shield and was designed to let me re-imagine the BluePOT project in a more general purpose project called weeBell.

(gCore POTS shield)

The gCore POTS shield connects to gCore's IO Expansion header and contains a codec chip and the Silvertel AG1171 Ringing Subscriber Line Interface module.  These two devices allow creation of a full Foreign Exchange Service (FXS) device which simulates a central office.  Old school POTS telephones plug into the RJ11 jack.  Firmware running on gCore implements functionality necessary to ring the phone for incoming calls, detect on- and off-hook conditions, support both rotary and DTMF dialing and provide echo-cancelled audio.

(Rotary Dialing)

Currently firmware called weeBell_bluetooth allows phone calls to be answered or initiated via a paired cellphone.  I hope to create other firmwares as well.  All firmware will be included as part of the gCore Serial Programmer library making it easy to load new versions.

(Loading weeBell firmware)

I wrote a desktop app (Linux x86, Mac OS, Windows) that lets you program almost all of the demos and applications I've written for gCore without needing to build them first using Arduino or the IDF.  It accesses pre-compiled binaries from my website.  You can find it in the Downloads section of the gCore page.

The idea is to make it easy to see all the things gCore can do.  The only demos I wrote that aren't included are those where you need to include your own Wifi SSID and password in them like the LiFX LED light bulb remote control.

Unfortunately I couldn't sign the app for Mac OS or Windows because the app calls a compiled version of esptool behind the scenes to do the actual programming and I couldn't sign that so the who application bundle couldn't be signed.  This means both Mac OS and Windows will complain.  On Mac OS you'll have to go to System Preferences->Security & Privacy and tell OS X you want to run the app anyway (you may also have to tell it to allow apps from both the App Store and identified developers).  On Windows you may have tell it that the zip is ok to download.

Here it is running on Linux.

And Mac OS X

And Windows

I wanted to learn about I2S audio on the ESP32 and found a great project in github user schreibfau1's ESP32-MiniWebRadio.  He has written some amazing audio libraries and then wrapped them up in a fun project.  His code is understandable and more importantly, reasonably easy to modify so I spent a couple of days getting it running on gCore - using gCore features of course - with a cheap Sparkfun I2S breakout board for the audio out.  The port can be found here.

It connects via Wifi to a list of internet radio stations held in a file on the Micro-SD card (along with lots of graphical assets for the GUI) and can output via I2S or via SPI to the VS1053 audio decoder chip. 

It can also act as an alarm clock and playback local files in a variety of formats.  Time is normally automatically obtained from an NTP service but will fall back to gCore's battery backed RTC if necessary.

There's even a web interface!  You can select from a humungous list of internet radio stations thanks to Community Radio Browser.

MiniWebRadio really shows what the ESP32 is capable of.  It connects to the internet, provides both a GUI and web server interface, decodes a bunch of audio formats in software and decodes and displays compressed images from both the Micro-SD card and internet streams. 

Be sure to check out schreibfaul1's ESP32-audioI2S library  too.  Very, very cool.

I always loved Galaga - although I have never been very good at video games - so I was excited when I found Till Haubaum's Galaga emulator already ported to the ESP32.  It was a pretty straight forward project to port it to gCore with one hiccup that caused me to spend a few hours getting audio to work again.  One cool thing is that  gCore's fast LCD updates allow for higher FPS than the original 40 MHz ILI9341.  The project is an Arduino sketch (Arduino 1.8.19 with the ESP Arduino 2.0.6 package).  Code in a github repo.

Yesterday I received a very heavy box with the first 250 gCore boards.  I feel pretty bad for my Fedex driver because we recently got a snowstorm here in Colorado and he had to lug that box up a long, snowy driveway to deliver it.  But production quality looks great.

I got the LVGL Music Demo running on gCore.  It's running on lvgl v9.0.0 so shows how to include the LCD and touchscreen drivers on that version (which has some differences from previous releases).

Code can be found in this repository.

This demo is used to benchmark LVGL running on various platforms when they are submitted for qualification (something I'm not sure I'll do as it is $900USD as you've just read about the economics of this project).  I didn't expect gCore to work as well as some of the boards with GPUs and much higher speed interfaces to the LCD but I was disappointed in my initial results - and a bit confused.

This demo has run on a couple of other ESP32 based boards that use the ESP32 parallel interface to directly drive the LCD controller.  I expected them to be slightly faster but not over twice as fast, especially since when I put my scope on the CSN signal to the LCD I see that the code is not limited by transfer speed to the LCD.  I verified this by slowing the SPI clock speed from 80 MHz to 40 Mhz with very little difference.  There are large periods of time between transfers which indicates a lot of compute is happening in the single-threaded demo code.  Because the SPI transfers are handled by a DMA engine then I can surmise that the demo is not being slowed by the LCD update.  Since I'm running the same chip as these other boards I would expect they have the same time spent in the compute parts of the code.  I wonder if I'm missing some type of optimization but not sure what.  I'm running the ESP32 at 240 MHz with 80 MHz QIO flash access, internal RAM and  the compiler set for performance optimization.  Bears some more investigation I think.

In other news I was able to issue a PR for the gCore python ILI9488 driver into the official lv_micropython project so now it's an officially supported display in that project.

This post covers a subject I haven't seen much discussion about: The [not so great] economics of selling a board like this.  I figure I've open sourced the design, why not be open about the business aspects of it.

I designed gCore for my own needs but I always thought it - and tCam - might be interesting to other people.  However, I am a one-man shop, interested in technical issues and not in marketing, managing production and shipping logistics.  Since Group Gets specializes in selling thermal imaging modules and boards, including my tCam-Mini board (that is used in tCam), it was an easy decision to have them distribute it and they were interested too.  Plus I like the team there.  They are good people and responsive to people like me (unlike my experience with other electronics crowd funding sites).

For a development board, gCore has a lot of parts.  These are needed for the added functionality and performance but make it more expensive to build.  Especially in low volumes.  Most boards in the same category have an ESP module, LCD display, USB IF chip, and voltage regulator (5V->3.3V).  Perhaps a Micro-SD socket.  gCore adds a LiPo charger, the EFM8 co-processor, TI current monitor chip, PWM backlight CC driver and the SPI-to-parallel converter (3 chips), plus supporting components.  As opposed to boards with the ESP32 WROOM module with 4 MB flash, it has a WROVER module with 16 MB flash and an 8 MB PSRAM.  These additional parts almost double the raw component cost over simpler boards.

At qty 500 boards the ideal raw cost for parts is about $37-38/board based on US distributor pricing.  I say ideal because that's the price if there were no parts shortages, which is not the world we live in.  Unfortunately these days we either have to redesign or pay through the nose occasionally because parts brokers [scalpers] bought the parts and charge 3-10x.

A problem is that a lot of makers and DIY types are used to super inexpensive dev boards, mostly built in China, with a lot less features.  And for a lot of projects the additional capabilities and performance of gCore don't matter.  There was never a way gCore would be cheap like these boards so I also knew it would never sell in high volumes.  I also feared that people would simply look at the price and be turned off before considering the value of the extra features and performance and how those could be useful. 

Initially Group Gets was going to be responsible for building the boards using their USA contract manufacturer.  I would get a negotiated percentage as a royalty.  Of course they need to make money and they charge a certain percentage to manage production to cover their costs, as well as percentages for managing, marketing and distributing the product, plus a profit.  Unfortunately the end result was a $160/board price.  There was no way this would be interesting to anybody.

So I decided to bite the bullet and assumed responsibility of building the boards in China using a CM I have used with success in the past, TinySine.  This would theoretically result in a lower cost to build boards and Group Gets wouldn't have to add their manufacturing management overhead to the final price.  In addition I don't have to necessarily mark up the costs as much as traditional companies since a) I'm don't have the same overhead and b) I'm not looking to make a lot of money with this project.  We talked and agreed that $99 was about the highest we could expect to charge - and even then we'd have to explain the value of this board (e.g. why one would buy a high end car when a Yugo will still get you from point A to point B).

Group Gets also wanted me to have a cute box for the board to come in.  I personally am just fine if boards come to me in anti-static bags but apparently the rest of the world disagrees...  So more cost.

I worked with TinySine to deal with some parts shortages by specifying alternates and agreeing to pay for two parts from brokers.   In the end I will pay $50.18 per board before they are shipped to the USA for a build of 250 units.  The boards will be tested, programmed and come with boxes (not sure yet if they will be in the boxes or that will be something I or Group Gets does).

Shipping to the USA is a big risk at the moment because of the risk of import duties.  At the moment certain categories of goods are exempt, at least until year-end, from the Trump-era 25% import duties.  Looking through the Harmonized Tariff Schedule and trying to figure out what category a board like this falls into is a tedious affair but I think that it legitimately falls into a category that is currently exempt.  I watch with alarm, however, over the increasingly belligerent posturing between the USA and China.  If the boards can be imported without duty then shipping will add between $1-2 per board, helped by the fact that it's cheaper to ship from China to the USA than vice-versa (FedEx charged me $166 to ship the test fixture to China).  So my landed costs are going to be either around $52 or $65 per board depending if I get hit with import duties or not.

All this leads to an interesting comparison of the real costs of building boards in the USA vs. China.  The USA CM quoted a number in the low $60s per board but this was before testing (which they hadn't quoted when we changed plans) and they hadn't actually tried to buy all the parts.  Shipping costs would have been less - or potentially zero - since they are located near Group Gets.  This means that the import duties would more-or-less equalize the landed costs for this board.  The savings of using the China CM will be from Group Gets having to burden the final cost with less overhead and lower profits to make the $99 list price.

In the end, I will probably make between $15-25 per board (depending on import duties and various shipping costs).  Which means $4-6k if we sell all of the initial run of 250 boards.  And incredibly less than the time I've put into documenting and writing demo and support code for gCore.  tCam firmware and supporting software alone is hundreds or thousands of hours of effort.   But as I said initially, I didn't go into this expecting to make money.  I designed the board I wanted for the thermal imaging camera I wanted and shared it with the greater community.  It's why although I'm an embedded development professional, I'm also a maker.  However an outcome could be that Group Gets becomes not interested because it doesn't make them much money (and, of course, they have to make money to survive).

So at this point it's down to marketing.  Trying to get the board in front of as many people who might be interested as possible.  I have shared it on various forums and GG has their own strategy.  I have a couple of more demos in mind too.  They're fun to write.  Then we'll see. 

I hope this was interesting for anyone who buys boards or is thinking of making boards for this market space.  Perhaps the next time you're looking through tindie and comparing prices you'll think about this aspect of things.

LVGL supports a python binding and they provide a pair of repositories supporting it.  One contains the bindings and the other with the bindings as part of micropython.  There are even drivers for the ILI9488 LCD controller and FT6236 touchscreen controller used by gCore and since Micropython runs just fine on the ESP32 getting the lv_micropython build running on gCore is easy.  However there's room for an optimization that speeds drawing on gCore even more than the higher 80 MHz SPI clock.

The ILI9488 chip supports multiple interfaces: 8- or 9-bit SPI, 8-, 16- or 24-bit parallel or DSI/MIPI parallel.  Most micro-based systems use the 4-wire SPI interface.  gCore uses the 8-bit parallel interface.  The chip also supports either 16-bit (RGB565) or 18-bit (RGB666) pixels, but only on the parallel interfaces.  When using the SPI interface directly the chip is limited to 18-bit pixels which must be loaded with 3 bytes (8-bits each for R, G and B).  This is why you'll see a lot of drivers with an extra step of converting data from 16-bits to 24-bits or from 32-bits down to 24-bits (as is done by the default ili9XXX.py driver in the lv_micropython repository).  This is a significant performance hit.  The "ili9488" class in the driver only supports LVGL in 32-bit (RGBA8888) mode and generates an error if LVGL is configured for 16-bit pixels.  But since gCore uses the parallel interface we can avoid this.  For this reason I modified the ili9XXX.py driver to include a new class "ili9488g" that implements the following optimizations (leaving the original ILI9488 class alone).

1. Changed the default SPI peripheral to VSPI and default pins to match
2. Set a default 80 MHz SPI bus frequency
3. Added support for 16-bit pixels

The new driver will work with LVGL compiled for either 16- or 32-bit pixels.  There is a noticeable speed-up when running with 16-bit pixels and not a lot of image degradation since the ILI9488 is really only capable of 18-bit pixels.

I also got one of the demos running.

One of the nice things about LVGL on Micropython is that it's really easy to use.  The REPL makes it great for experimentation too.  Just a few lines of code to get a GUI.  For example the following code initializes LVGL and both the touchscreen and LCD drivers, and then creates and displays a button.

from ili9XXX import ili9488g

from ft6x36 import ft6x36

disp=ili9488g()

touch=ft6x36(0, 21, 22, 10000)

scr=lv.obj()

btn=lv.btn(scr)

btn.center()

label=lv.label(btn)

label.set_text('Button')

lv.scr_load(scr)

The main github repository has been updated with instructions and the new driver.