Appearantly the breakout board, “ESP_Module_Testboard”, is little bit too wide for breadboard use, (leaving one row on each side), I decided to make a quick development board. The end result looks like this.

Some notes about the board:

• Pin “EN” has a 10k pull-up resistor. The reset button pulls “EN” down. ESP31 does not come with a RESET pin, it seems EN does the same.
• Pin “IO0” has a 10k pull-up resistor. The “IO0” pin pulls it down. Low level on IO0 during reset allows the ESP31 to enter programming mode. This is very much the same as ESP8266. I am not sure if the pull-up resistor is needed because it seems there is one built-in. Nevertheless I just put one for safety reason.
• The red board is a FTDI USB-Serial converter. The board is set to 3.3V I/O. The orange color jumper wire from FTDI board is to get 5V power from USB, feed through an AMS1117-3.3 to power the ESP31 module. I used a 100uF output tantinium capacitor. It seems this setup is not good enough. I’ll explain later.

With the board on hand, it is now time to setup development environment. There are excellent guides at http://www.instructables.com/id/Beginners-ESP32-Guide-to-Assembly-Testing/, as well as LadyAda’s live show https://www.youtube.com/watch?v=HCGHb0OVz1s

New year is around the corner and I am so eager to continue my new year greeting video “series”. It natually envolves into this:

And the source code too: https://github.com/baoshi/ESP32-XMAS

Again some notes about the source code:

• The TFT screen contains 128×160 pixels, at 16bit/pixel it amounts to 40kB/frame, or 320kbits/frame. The SPI bus is running at 13.3MHz, that works out around 40fps. Due to some coding overhead the fastest I can achieve is about 25fps. But again becaused of the latency at WiFi side, I’m currently running the screen at 10fps. That is only 400kB/s for WiFi traffic, which is significantly slower than the claimed 140Mb/s rated speed. Of course there is huge room for improvement at software side.
• The ESP31 seems to take more power than it’s predecessor ESP8266. The above mentioned AMS1117-3.3 cannot provide enough juice. The phenomenon is garbaged output from serial port, lost WiFi connection, or failed with exception after reset. It could be a thermal issue. I ended up using a lab power supply then all the problems are gone. My supply registered 170mA when WiFi is active. Of course it includes the LCD comsumption. I will do some further investigation at a later time.
• I encouontered some WiFi abnormalities that the connection speed slows down significantly from time to time. Reset the chip will resolve the issue. For the time being I havn’t fully dig into it.
• Other than these, ESP31 (ESP32 Beta) and the current SDK (1.1.0) seems quite stable.

To all my readers or viewers I take this oppotunity to wish you a Merry Christmas and Happy New Year. See you next year.

The post First sight into ESP32 appeared first on Digital Me.

Being not too much dedicated to Arduino, I have to quickly put up something demo-able. And since I’ve been playing with display devices often, I decided to make an Arduino graphics project. After two weeks, I finished my first Arduino game — FlappyDuino (thanks SG Makers William Hooi for inventing the name).

The project hardware is really simple. It only contains an Arduino Pro Mini, a ST7735 SPI TFT panel and a distance sensor (Sharp GP2Y0A21YK0F, which I used before in Project Crystal). I have put the KiCAD schematic, PCB and Arduino sketch code at https://github.com/baoshi/FlappyDuino. Feel free to download and criticise my code.

Lazy me also think a video is worth thousands of words.

Happy Birthday Arduino!

The post FlappyDuino – Arduino Day 2014 celebration appeared first on Digital Me.

Background information

STemWin is available at http://www.st.com/web/en/catalog/tools/PF259225 (Do not complain if the link does not work. ST did great SEO job by changing URL regularly. Google is your friend…). Basically STMicroelectronics licensed it from SEGGER and distribute the library in binary form. At the time I’m writing this post STemWin is at verison 1.1, corresponding to SEGGER emWin v5.22. The license term for STemWin is pretty obscure according to my English standard. But as far as I can interpret the usage of STemWin with STM32 micro controllers is free for both commercial or non-commercial cases. SEGGER emWin is also available from NXP, carrying a similar license, or from Keil MDK-ARM. The later requires a professional license which is far deeper than my pocket.

The Truly LCD costs as low as $4  from taobao. I suspect it is some sort of left-overs from mobile phone manufacture. The seller told me he has 10K+ ready stock. The LCD controller is Himax HX8352C. I erroneously assume that emWin supports HX8352 and HX8352B so it should support HX8352C, until I wire up the LCD and the garbage churns out.

As a sincere RTFM user I looked into STemWin documentation. There is a chapter “29.7.20 GUIDRV_Template – Template for a new driver”, roughly 1/3 page long, talking about how to write a display driver. Don’t blame SEGGER or ST for not providing more details. SEGGER charges €1,100 for the source code of a driver. They need to make a profitable business after all. And the 1/3 page paragraph proves to be very useful indeed.

For impatients or who want to criticise my code straight away, please jump to GUIDRV_HX8352C

Bare metal LCD driver

Before interfacing the LCD panel with emWin, it is always necessary to make the panel work with bare metal code first. My testing hardware is on a STM32F103RCT6 minimalism board. The reason I choose a 64-pin RCT6 instead of a 100-pin monster is that I wanted to test GPIO to LCD driver performance. If a 100-pin device is used, we can drive LCD using FSMC port and it will be much easier. My LCD wiring is as follows :

We’ll need to implement the following functions for hardware accessing:

void lcdReset(void);
void lcdInit(void);
void lcdWriteData(uint16_t data);
void lcdWriteReg(uint16_t data);
uint16_t lcdReadData(void);

As the name suggests, these functions handles LCD reset, LCD initialization and read/write data/register from/to the LCD controller. Implementation of these functions is as simple as following the LCD datasheet. My actual implementation is within the GitHub repository linked below. A simple main() function to test the LCD interface:

// Note: This code assumes 16-bit parallel interface and HX8352C controller.
void main(void)
{
    lcdInit(); // Internally calls lcdReset()
    lcdWriteReg(0x0002);
    lcdWriteData(0x0000);
    lcdWriteReg(0x0003);
    lcdWriteData(0x0000);
    lcdWriteReg(0x0006);
    lcdWriteData(0x0000);
    lcdWriteReg(0x0007);
    lcdWriteData(0x000);
    // Write data
    lcdWriteReg(0x0022);
    lcdWriteData(0xFFFF);
    while(1) {}
}

This shall display a white dot at coordinate (0, 0). If it works, congratulations you’re halfway towards success. If it doesn’t, look into the controller datasheet and debug your software/hardware.

Looking into a template driver

STemWin comes with some sample codes for various ST development boards, but display driver is not one of them. Since the limited documentation actually tells us the sample driver is called GUIDRV_Template, try Google “GUIDRV_Template.c” will lead you to the same file at ST forum. (I try not to host the file here as I’m not sure about its license.) Another way to obtain this file is download the trial version of MDK-ARM, as bonus you’ll have all other emWin samples.

Now look at the template driver. The only thing it exposes to the public is a structure GUIDRV_Template_API, which consists a number of function pointers:

/*********************************************************************
*
* GUI_DEVICE_API structure
*/
const GUI_DEVICE_API GUIDRV_Template_API = {
    //
    // Data
    //
    DEVICE_CLASS_DRIVER,
    //
    // Drawing functions
    //
    _DrawBitmap,
    _DrawHLine,
    _DrawVLine,
    _FillRect,
    _GetPixelIndex,
    _SetPixelIndex,
    _XorPixel,
    //
    // Set origin
    //
    _SetOrg,
    //
    // Request information
    //
    _GetDevFunc,
    _GetDevProp,
    _GetDevData,
    _GetRect,
};

The documentation actually tells us that among all the functions , we only need to adapt the _GetPixelIndex and _SetPixelIndex. That is more or less correct. I show you how.

Quick and Dirty emWin driver

Go to GUIDRV_Template.c, find _GetPixelIndex and _SetPixelIndex. SEGGER already put the comments there saying “Write into hardware … Adapt to your system”, so adapt them as follows

// Note: Pseudo code below, adapt to your implementation
static void _SetPixelIndex(GUI_DEVICE *pDevice, int x, int y, int color)
{
   //Draw_Pixel(x,y,PixelIndex);
   // Move cursor
   lcdWriteReg(0x0002);
   lcdWriteData(HIBYTE(x));
   lcdWriteReg(0x0003);
   lcdWriteData(LOBYTE(x));
   lcdWriteReg(0x0006);
   lcdWriteData(HIBYTE(y));
   lcdWriteReg(0x0007);
   lcdWriteData(LOBYTE(y));
   // Write data
   lcdWriteReg(0x0022);
   lcdWriteData(color);
}

static unsigned int _GetPixelIndex(GUI_DEVICE *pDevice, int x, int y)
{
    U16 reads[3];
    //PixelIndex = ili9320_GetPoint(x,y);
    // Move cursor
    lcdWriteReg(0x0002);
    lcdWriteData(HIBYTE(x));
    lcdWriteReg(0x0003);
    lcdWriteData(LOBYTE(x));
    lcdWriteReg(0x0006);
    lcdWriteData(HIBYTE(y));
    lcdWriteReg(0x0007);
    lcdWriteData(LOBYTE(y));
    // Start read data
    lcdWriteReg(0x0022);
    lcdReadData(reads[0]);
    lcdReadData(reads[1]);
    lcdReadData(reads[2]);
    // Pack RGB into RGB565, see HX8352C datasheet for 16-bit interface read
    PixelIndex = ((reads[1] & 0xF800) | ((reads[1] & 0x00FC) << 3) | (reads[2] >> 11));
}

To let emWin use the template driver, LCDConf.c must be provided. Sample LCDConf.c can be found inside STemW

in folder, modify LCD_X_Config like this:

....
//
// Physical display size
//
#define XSIZE_PHYS 240
#define YSIZE_PHYS 400
....
void LCD_X_Config(void)
{
    ....
    pDevice = GUI_DEVICE_CreateAndLink(GUIDRV_Template_API, GUICC_565, 0, 0);
    ....
}

....

int LCD_X_DisplayDriver(unsigned LayerIndex, unsigned Cmd, void * pData)
{
    ....
    switch (Cmd)
    {
    case LCD_X_INITCONTROLLER:
    {
        lcdInit();
        return 0;
    }
    ....
    }
    ....
}

Added other necessary files (GUIConf.c, various header files, etc) into project, write a test main as

void main(void)
{
    ....
    // Setup STM32 system (clock, PLL and Flash configuration)
    SystemInit();
    // Necessary for STemWin to authenticate that it is runing on STM32 processor
    RCC_AHBPeriphClockCmd(RCC_AHBPeriph_CRC, ENABLE);
    GUI_Init();
    GUI_DispString("Hello world!");
    ....
}

And you’re golden.

Re-organisation code

Thanks for following me till this point. I must apologise that I did not prepare any ready examples  that you can modify on top. I deem providing such an example not necessary because all what we’ve been doing is “quick and dirty”. If you look into the SEGGER provided drivers and examples, you will find that the hardware interfacing, the LCD drawing primitives and the LCD panel configuration are nicely segregated into different modules. This enables SEGGER to distribute the LCD drawing primitives as hardware independent binary “drivers” without restrict the actual panel and hardware connectivity. Although I have no intention to distribute the custom driver in binary form, adopting such architecture will ensure optimal readability and portability.

Let’s go back look at the GUIDRV_Template_API structure. We have already implemented the drawing functions. The remaining 4 functions, namely _GetDevFunc, _GetDevProp, _GetDevData, _GetRect, are critical for emWin core to query necessary information from the driver. The reference implementation in GUIDRV_Template.c involves a lot of runtime settings, e.g., VRAM, panel dimension and orientation, so that user is able to configure the binary driver using external code. Since I’m working on a single panel and I’m open source,  these settings can be hard-coded (SEGGER called it compile-time). With some debug tracing it is not hard to figure out how these functions are called by emWin, and a calling digram of emWin initialization is as below:

I have organized the functions as SEGGER’s other binary driver, with GUIDRV_HX8352C.c handles all the controller interfacing, LCDConf.c links controller module with the hardware interface, and HX8352C_GPIO handles GPIO hardware access to the LCD controller.

Driver optimization

Now look at the template driver’s drawing functions. We already have _GetPixelIndex and _SetPixelIndex. The remaining 4 functions, _DrawBitmap,  _DrawHLine,  _DrawVLine and  _FillRect, are implemented as repeatedly calling  _GetPixelIndex and _SetPixelIndex, which is very inefficient. The correct way of writing these functions is to utilize the LCD controller’s hardware clipping mechanism, and fill GRAM directly. 

A lower level of optimization targets at improving GPIO driving efficiency. For this part I have referenced Andy Brown’s excellent stm32plus library. Most GPIO driving functions are implemented as ARM assembly to ensure correct timing. Andy further introduced a way of fast GPIO writing by utilizing data already on the databus and toggle WR signal repeatedly. This is very useful when doing block filling or line drawing. When all these optimization I have archived 8,846,000 pixel/second filling rate with 72MHz processor clock.

Performance can be further enhanced with a higher pin count STM32 processor using FSMC port access.

GUIDRV_HX8352C

The source for this driver is available at GitHub. Several notes:

1. Demo application is from SEGGER.
2. The building environment is Eclipse + GNU Make + ARM GCC, as described in my previous blog.
3.  The STM32 development board is from taobao. I choose this because it uses 4 wire SWD interface, saving many I/O pins.
4. Theoretically the driver supports emWin “multi-layer” or “multi-display”. But I have not tested it yet.
5. Panel orientation is hard-coded in LCDConf.h, to maintain the compatibility with other emWin drivers.
6. Due to the limited LCD GRAM and RAM in STM32 processor, not all emWin examples are usable. The video below shows those I’ve been able run on a STM32F103RCT6.

The post HOWTO: Write a display driver for SEGGER emWin appeared first on Digital Me.