Sunday, December 31, 2017

ESP32

Expressif comes out with ESP32, a more powerful successor to the popular ESP8266.  The ESP-WROOM-32 module can be purchased for under $5.   It is a 25.5 x18 x 3.1 mm PCB with printed antenna, and 38 castellation pins with 1.27mm (0.05") pitch.  A very nice pinouts diagram can be found here.


The ESP32-D0WDQ6 supports 802.11n WiFi (2.4GHz) and Bluetooth v4.2.  It contains dual Xtensa 32-bit LX6 cores (240MHz), 448KB ROM and 520KB SRAM.  ESP-WROOM-32 has 4MB QSPI Flash.  ESP32 can address up to 16MB external Flash.   Parts of the internal SRAM (32KB for each core) serve as the cache for the slow SPI Flash.

There is also a development board which adds a 3.3V regulator and CP2102 USB to serial bridge chip.   It has the more convenient 0.1" pitch pins.  Or we can wire up like this,



Using Arduino is probably a good way to start.  The support for esp32 is not included in Arduino by default; it can be installed following the instructions here .

IO0 has to be pulled low to enter the serial bootloader mode.  esptool.py uses RTS for EN and DTR for IO0.  For the ESP32 development board, CP2102 USB to serial bridge chip handles entering the bootloader mode.  Here it is done manually.  The connections are as follows,
  • GND - GND
  • 3V3 - 3.3V
  • TXD0 - RX
  • RXD0 - TX
  • EN - Pull up 
  • IO0 - Pull down
When EN is float, the current draw is about 5mA.  If EN is low, the current draw is 0mA.  When IO0 is pulled low, the current draw is about 17mA.

We test with the example code WiFiScan, which compiles without a problem.
Sketch uses 480294 bytes (36%) of program storage space. Maximum is 1310720 bytes.

Global variables use 36800 bytes (12%) of dynamic memory, leaving 258112 bytes for local variables. Maximum is 294912 bytes.
sptool.py v2.1
Connecting........
Chip is ESP32D0WDQ6 (revision 1)
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 8192 bytes to 47...

Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 13109.4 kbit/s)...
Hash of data verified.
Compressed 14128 bytes to 9213...

Writing at 0x00001000... (100 %)
Wrote 14128 bytes (9213 compressed) at 0x00001000 in 0.1 seconds (effective 983.4 kbit/s)...
Hash of data verified.
Compressed 481440 bytes to 299651...

Writing at 0x00010000... (5 %)
Writing at 0x00014000... (10 %)
Writing at 0x00018000... (15 %)
Writing at 0x0001c000... (21 %)
Writing at 0x00020000... (26 %)
Writing at 0x00024000... (31 %)
Writing at 0x00028000... (36 %)
Writing at 0x0002c000... (42 %)
Writing at 0x00030000... (47 %)
Writing at 0x00034000... (52 %)
Writing at 0x00038000... (57 %)
Writing at 0x0003c000... (63 %)
Writing at 0x00040000... (68 %)
Writing at 0x00044000... (73 %)
Writing at 0x00048000... (78 %)
Writing at 0x0004c000... (84 %)
Writing at 0x00050000... (89 %)
Writing at 0x00054000... (94 %)
Writing at 0x00058000... (100 %)
Wrote 481440 bytes (299651 compressed) at 0x00010000 in 3.9 seconds (effective 976.6 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 122...

Writing at 0x00008000... (100 %)
Wrote 3072 bytes (122 compressed) at 0x00008000 in 0.0 seconds (effective 6060.6 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting...
Not sure how the max memory sizes come about.   The program works.  The current draw is about 110mA@3.3V.
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:956
load:0x40078000,len:0
load:0x40078000,len:13076
entry 0x40078ad0
Setup done
scan start
scan done
10 networks found
1: ...

As the ESP chips gain popularity, many online resources are available,
The data sheet and the reference manual are still missing lots of information.  For instance, there is no performance data on the ADC and DAC.

Friday, December 22, 2017

LCD Pixels

Some pictures of LCD pixel structures.


  • 1.8" TFT LCD 128 x 160


  • Samsung TV 32" 1920 x 1080
  • Sony 4K TV 49"
  • Monitor 
  • Monitor 21" 1920 x 1080 
  • Laptop 15" 1920 x 1080 
  • Pad 7" 1920 x 1200 (323 ppi or 80um/pix)

Friday, December 15, 2017

1.8" 128 x 160 TFT LCD

An 1.8" 128 x 160 TFT LCD can be purchased for around $3.  The one that I got has the marking of "KMR-1.8 SPI".  It claims to be ST7735R based.  ST7735R is a 262K 18-bit color TFT controller/driver by Sitronix.   ST7735R is a chip with large aspect ratio (10 x 0.7 mm); it has 759 pads (including 396 source and 162 gate driver output pins) and supports a number of interfaces, parallel and serial.
The one IC on the back appears to be a voltage regulator.  Based on the top marking "65Z5", it is at least similar to Torex XC6206, which regulates to 3V/250mA from max input of 6V.  There is an un-populated jumper between input and output.  I suppose it is used to bypass the regulator.  The soldering job is not great; I had to clean up a little.

The backlight LED takes 23mA at 3V.

The header pins are
  1. GND
  2. VCC
  3. NC
  4. NC
  5. NC
  6. RESET
  7. A0
  8. SDA
  9. SCL
  10. CS
  11. SCK
  12. MISO
  13. MOSI
  14. SD_CS
  15. LED+
  16. LED-
LED+, SD_CS,  MOSI and SCK have 4.7-Ohm series resistors.  LED- is shorted to GND.  The display is advertised to work with Arduino, but it appears to take only 3V input.

There is some confusion as to how the signals should be connected.  The SPI signals are connected to the SD card socket.  SDA/SCL seem like I2C signals, but according to the ST7735R data sheet, the 4-wire SPI (SPI4W) mode, RESET, CS, D/C, SDA and SCL are used.   A0 is the D/C (data/cmd) pin.  It does not seem to follow I2C protocol.    However, SDA is bidirectional.

The SD card pin out is as follows
  1. SD_CS
  2. MOSI
  3. GND
  4. VDD
  5. SCK
  6. GND
  7. MISO
  8. NC
  9. NC
The SD card VDD supply range is 2.7 to 3.6V.  As far as I tell, the SD SPI is unrelated to the display SPI.

The Adafruit-ST7735 library can be used to test.   It has the option of using software or hardware SPI.   The software option worked, but the hardware option did not work.  The wiring is as follows,
  • CS -D10
  • RST - D8
  • A0 (DC) - D9
  • SCL - D13
  • SDA - D11
  • LED+ - 3v3
  • VCC - 5V
  • GND - GND
I used 1600-Ohm resistors in series for 5V to 3V conversion.  I wonder if that might cause some problem.  The  display input pins do not cause the 5V signal level to drop as I expect with ESD protection diodes.  Could the input be 5V tolerant?  The I/O voltage is specified as 1.65 to 3.7V according to the data sheet and the operating voltage is 2.3 to 4.8V.  5V would be stressing it.  I power the Arduino nano with the USB, so the actual voltage is 4.7V (after the diode).  It is possible that the 3V from the regulator is not actually used by the display, but only for the SD card.

People have reported that the display can also run on Orange Pi.  The device is supported by notro's fbtft, with built-in support for Adafruit 1.8".  The wiring is as follows,
  • LED+ - GPIO18 (12)
  • SCL - SCLK (23)
  • SDA - MOSI (19)
  • CS - CE0 (24)
  • A0 - GPIO24 (18)
  • RST - GPIO25 (22)
  • VCC - 3.3V (1 or 17)
  • GND - GND (6,9,14,20,25,30,34 or 39)
The Orange Pi 40-pin header is compatible with the Raspberry Pi.  If different pins are used for RST  DC, and LED, they have to be specified on the drive parameter gpios.  The numbering refers to GPIO_GENn.  The GPIO18 controls the backlight, but it probably is incapable of sourcing 20-30mA LED drive current.   To load the driver, 
sudo modprobe fbtft_device name=adafruit18
But it did not work; the kernel message is as follows
[ 163.068275] fbtft_device: SPI devices registered:
[ 163.068296] fbtft_device: spidev spi0.0 33000kHz 8 bits mode=0x00
[ 163.068305] fbtft_device: 'fb' Platform devices registered:
[ 163.068374] fbtft_device: Deleting spi0.0
[ 163.068799] fbtft_device: GPIOS used by 'adafruit18':
[ 163.068815] fbtft_device: 'reset' = GPIO25
[ 163.068822] fbtft_device: 'dc' = GPIO24
[ 163.068829] fbtft_device: 'led' = GPIO18
[ 163.068836] fbtft_device: SPI devices registered:
[ 163.068845] fbtft_device: fb_st7735r spi0.0 32000kHz 8 bits mode=0x00
[ 163.075420] fb_st7735r spi0.0: fbtft_request_gpios: gpio_request_one('reset'=25) failed with -22
The problem I think is the GPIO numbering is different from RPi.  GPIO18,24,25 are invalid on OPi.  These pins should be GPIO1,5,6 respectively and have to be specified.
  • LED+ - GPIO1 (12)
  • SCL - SCLK (23)
  • SDA - MOSI (19)
  • CS - CE0 (24)
  • A0 (DC) - GPIO5 (18)
  • RST - GPIO6 (22)
  • VCC - 3.3V (1 or 17)
  • GND - GND (39)
sudo modprobe fbtft_device name=adafruit18 gpios=reset:6,dc:5,led:1 speed=16000000 fps=25 rotate=90
[  150.480421] fbtft_device:  SPI devices registered:
[  150.480440] fbtft_device:      spidev spi0.0 33000kHz 8 bits mode=0x00
[  150.480449] fbtft_device:  'fb' Platform devices registered:
[  150.480517] fbtft_device: Deleting spi0.0
[  150.481116] fbtft_device:  GPIOS used by 'adafruit18':
[  150.481128] fbtft_device:    'reset' = GPIO6
[  150.481135] fbtft_device:    'dc' = GPIO5
[  150.481142] fbtft_device:    'led' = GPIO1
[  150.481148] fbtft_device:  SPI devices registered:
[  150.481158] fbtft_device:      fb_st7735r spi0.0 16000kHz 8 bits mode=0x00
[  151.462000] graphics fb8: fb_st7735r frame buffer, 160x128, 40 KiB video memory, 4 KiB buffer memory, fps=25, spi0.0 at 16 MHz
The data sheet specifies the min serial clock cycle time is 66ns for write and 150ns for read.   Even for just writing, the max clock frequency is 15MHz.   Even though the driver seemed to load correctly, I was unable to display anything.   Lowering the SPI clock rate did not help.

I need to go back to see why I was not able to run the display with hardware SPI.

ucglib is another library to try, https://github.com/olikraus/ucglib .  Again the software SPI works, but hardware SPI does not.

I powered both the arduino and  the display with 3.3V.  The hardware SPI worked.  (I mistakenly used D12 as DC, which compounded the problem.  D12 is MISO.)  Even the software SPI behaved a little better (without the some flicking).   So the hardware is fine running 3.3V (drawing about 55mA).

Orange Pi is running at 3.3V, so there are still some configuration issues.  One possibility is the GPIO numbering.   In the GPIO driver, the number is given by (position of letter in alphabet - 1) * 32 + pin number.  Pin 12 is PD14  would be 110.  So I made the following connections,
  • LED+ - 3.3V
  • SCL - SCLK (23)
  • SDA - MOSI (19)
  • CS - CE0 (24)
  • A0 (DC) - GPIO7 (29)
  • RST - GPIO8 (31)
  • VCC - 3.3V (1)
  • GND - GND (39)
The driver is loaded with
sudo modprobe fbtft_device name=adafruit18 gpios=reset:8,dc:7,led:1 speed=16000000 fps=25 rotate=90
[  256.212355] fbtft_device:  SPI devices registered:
[  256.212376] fbtft_device:      spidev spi0.0 33000kHz 8 bits mode=0x00
[  256.212387] fbtft_device:  'fb' Platform devices registered:
[  256.212462] fbtft_device: Deleting spi0.0
[  256.212916] fbtft_device:  GPIOS used by 'adafruit18':
[  256.212930] fbtft_device:    'reset' = GPIO8
[  256.212938] fbtft_device:    'dc' = GPIO7
[  256.212946] fbtft_device:    'led' = GPIO1
[  256.212953] fbtft_device:  SPI devices registered:
[  256.212964] fbtft_device:      fb_st7735r spi0.0 16000kHz 8 bits mode=0x00
[  257.122269] graphics fb8: fb_st7735r frame buffer, 160x128, 40 KiB video memory, 4 KiB buffer memory, fps=25, spi0.0 at 16 MHz
Run fbset -i -fb /dev/fb8
mode "160x128"
    geometry 160 128 160 128 16
    timings 0 0 0 0 0 0 0
    nonstd 1
    rgba 5/11,6/5,5/0,0/0
endmode
Frame buffer device information:
    Name        : fb_st7735r
    Address     : 0
    Size        : 40960
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 0
    YPanStep    : 0
    YWrapStep   : 0
    LineLength  : 320
    Accelerator : No
It is tested with a self portrait,
sudo fbi -d /dev/fb8 -T 1 -noverbose -a KMR18.jpg

The frame buffer can be directly written to, e.g.
dd if=/dev/zero of=/dev/fb8 bs=2 count=20K
dd if=/dev/random of=/dev/fb8 bs=2 count=20K
To run console, map a tty to the fb with con2fbmap 2 8 .  The login prompt displays when switched to tty2.

The next step is to run X windows on it.  I created X11 config file and run startx as the second display.  The X Window did  run on the display; but the X Windows on the HDMI display disappears.   

To start the display on boot, add the kernel module to /etc/modules and parameters to /etc/modprobe.d/fbtft_device.conf . 

Sunday, December 10, 2017

Flashlight using AA and 14500 batteries

I've built a number of LED lights myself.  But you can purchase a 1000LM Cree Q5 LED flashlight for less than $2.  What I found intriguing is that the flashlight is capable of running on both a regular alkaline AA battery or 14500 lithium ion battery. The AA battery voltage range is 0.9 to 1.5V, and the Li+ battery is 2.5 to 4.2V.  And the white LED forward voltage is about around 3.3 to 3.7V.  So the regulator has to be capable of both stepping up and down.  While there are circuits that can do that, I'm curious how it is done on an inexpensive flashlight.

I was able to find pictures of retail circuit boards for LED, like this one
A search for the driver IC turns up Nanjing Micro One Electronic ME2106.  The packaging is SOT-89-5 with an extended pad for VOUT, which enhances the thermal performance.  The typical application circuit looks like this,
However, ME2106 is a step-up converter with constant current output.  The IC is capable of starting at 0.8V.    The current is set by an external resistor with 200mV feedback voltage.  So the current sensing resistor appears to be 0.27 Ohm, which sets the current to 740mA.  The CREE Q5 LED is spec'ed with 3.3V@350mA, 3.5V@700mA, and 3.7V@1000mA.  The Q5 is cool white with min flux of 107 lm, increasing to 180 lm @700mA and 240 lm @1000mA.  So the advertised 1000 lm is probably bogus.  Since ME2106 is not capably of stepping down.  When the battery voltage exceeding 3.5V, the battery voltage applies to the inductor, the diode, the LED and the resistor in series.  The drop across the diode is over 0.4V and may be another 0.2V across the resistor and inductor; there is enough drop to bring the voltage across the LED down to 3.6V from the 4.2V peak battery voltage.  The efficiency is still over 80%.

Saturday, December 2, 2017

OrangePi Prime Armbian

When I installed Armbian on the OPiP half a year ago, the builtin wifi was not supported.  I tried again with the later build, Armbian_5.34.171121_Orangepiprime_Ubuntu_xenial_next_4.13.14_desktop,  Release: Ubuntu 16.04.3 LTS, Kernel: "Linux orangepiprime 4.13.14-sunxi64 #246 SMP Mon Nov 20 01:58:09 CET 2017 aarch64 aarch64 aarch64 GNU/Linux".  The builtin WiFi works out of box.  The WiFi support has been added.
[ 7.303430] r8723bs: module is from the staging directory, the quality is unknown, you have been warned.
[ 7.312103] RTL8723BS: module init start
[ 7.312112] RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40
[ 7.312114] RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40
[ 7.381290] RTL8723BS: rtw_ndev_init(wlan0)
[ 7.382437] RTL8723BS: module init ret =0
While the WiFi works fine, but the builtin Bluetooth is not working.  A USB Bluetooth adapter works and can be used to attach Bluetooth keyboard/mouse.

The HDMI display works OK, but does not always configure correctly.

With the addition of the WiFi, the OPiP is very usable, as I can type this blog on it.  I think Armbian is the better distribution than what the vendor provides.  Armbian support for H5 is still experimental.

armbian-config is a useful tool to configure the system, in particular the peripherals, I2C, SPI, etc.

I built KiCad from the source on OPiP like I did on OPi PC.  It took about 8 hours, still a long time, but an improvement over OPi PC.  It was with the max CPU frequency set to 1.37GHz.  Again it is not platform for developing large software.

While OPi Prime is more capable than OPi PC, it is not fast enough to a desktop replacement but likely an overkill for most embedded applications.  I would certainly prefer two OPi PC over one OPi Prime at the same cost.