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:

https://youtu.be/6SR7anr_Xi4

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.

If you search MQTT and ESP8266 on the intraweb, most likely all hits can be traced back to the great work done by TuanPM. However Tuan’s code is based on Espressif’s NON-OS SDK. There has been some great debates about embedded programming with-or-without an OS. To me programming with OS vs NON-OS is like programming with C vs Assembly. I like programming in C, so I wrote a new MQTT client for Espressif’s RTOS SDK.

The source code is published at https://github.com/baoshi/ESP-RTOS-Paho

Here are some notes:

• The code is based on the Eclipse Paho project, specifically the embedded C client.
• Socket-level APIs used, the code is thread-safe.
• Many error handlings were added to the original Paho client, including time-out for most of the network functions. These are designed to work with an RTOS to support automatic error correction at various abused conditions.
• I’m compiling using the “Unofficial ESP8266 DevKit“. Other toolchain such as esp-open-sdk can be used as well (adjust pathes in Makefile).
• Skeleton code for connecting a MQTT broker is as follows:

[code]
struct Network network;
MQTTClient client = DefaultClient;
MQTTPacket_connectData data = MQTTPacket_connectData_initializer;
unsigned char mqtt_buf[100];
unsigned char mqtt_readbuf[100];

NewNetwork(&network);
ConnectNetwork(&network, MQTT_HOST, MQTT_PORT);
NewMQTTClient(&client, &network, 5000, mqtt_buf, 100, mqtt_readbuf, 100);
data.willFlag = 0;
data.MQTTVersion = 3;
data.clientID.cstring = mqtt_client_id; // you client’s unique identifier
data.username.cstring = MQTT_USER;
data.password.cstring = MQTT_PASS;
data.keepAliveInterval = 10; // interval for PING message to be sent (seconds)
data.cleansession = 0;
MQTTConnect(&client, &data);
[/code]

To subscribe to a MQTT topic, use

[code]
MQTTSubscribe(&client, "/mytopic", QOS1, topic_received);
[/code]

The parameter topic_received is a callback function handling the received message:

[code]
// Callback when receiving subscribed message
LOCAL void ICACHE_FLASH_ATTR topic_received(MessageData* md)
{
int i;
MQTTMessage* message = md->message;
dmsg_puts("Received Topic ");
for (i = 0; i t; md->topic->lenstring.len; ++i)
dmsg_putchar(md->topic->lenstring.data[i]);
dmsg_puts(", Message ");
for (i = 0; i < (int)message->payloadlen; ++i)
dmsg_putchar(((char*)message->payload)[i]);
dmsg_puts("rn");
}
[/code]

To publish a MQTT topic, use

[code]
char msg[PUB_MSG_LEN];
MQTTMessage message;
message.payload = msg;
message.payloadlen = PUB_MSG_LEN;
message.dup = 0;
message.qos = QOS1;
message.retained = 0;
MQTTPublish(&client, "topic", &message);
[/code]

The demo project included in the library shows how the MQTT related functions can be organized inside a FreeRTOS task and interact with other tasks, such as retry connection after server error, WiFi error, etc. The following diagram may be helpful to understand the code. (Imaging how this can be done using NON-OS SDK)

As Espressif had just teased us with the new ESP32 chip and RTOS is rumored to be the default SDK, I hope this piece of code will be useful.

The post ESP8266 MQTT client on RTOS appeared first on Digital Me.

The new utility, named ST2Makefile, is available on https://github.com/baoshi/ST2Makefile

My limited testing shows it works for most example projects in ST’s library package, as well as STM32CubeMX exported projects. One thing needs tweaking could be that some ST’s example project contains duplicated source files. If you receive error message such as “Symbol already defined in XXX” during linking, please check the SRCS section for any duplicated source entries.

The usage is changed a little since CubeMX2Makefile.py, now you should run:

[code light=”true”]
ST2Makefile.py <TrueSTUDIO project location>
[/code]

where you can identify TrueSTUDIO project location by locating “.project” and “.cproject” files inside it.

As usual, some useful resources:

Useful links

ST2Makefile: https://github.com/baoshi/ST2Makefile
ARM GCC: https://launchpad.net/gcc-arm-embedded

My packaged GNU Make for Win32: https://ba0sh1com.files.wordpress.com/2020/09/2c1c9-make.zip

The post TrueSTUDIO STM32 project to GCC Makefile converter appeared first on Digital Me.

UPDATE

Always get update from https://github.com/baoshi/CubeMX2Makefile The code is now based on SW4STM32 project output. Thanks various contributors to make this possible.

Deprived off electronics lab back in Singapore, a Chinese new year holiday here in Shanghai home is perfect for some software projects. I have little exposure with Python but after two days of Googling (through VPN) and copy/paste, a crude CubeMX2Makefile utility is ready, available at https://github.com/baoshi/CubeMX2Makefile (OOP aficionados please forgive my spaghetti styled code. It works is it?)

As the name suggests, the program converts STM32CubeMX project into a GNU Makefile. Here is a mini-HOWTO:

1. Create a STM32CubeMX project, configure pins, peripherals and MiddleWare, then edit project settings as follows: (choose SW4STM32 instead of TrueStudio in the picture below)

   

   Make sure the Tool/IDE selection is TrueSTUDIO 4.3.1 (as of STM32CubeMX 4.6.0), and note down the “Toolchain Folder Location”. I found it necessary to empty the old “Toolchain Folder” before each code generation, otherwise the project file just keep growing regardless of settings (this could be a bug in STM32CubeMX). See update below.

2. Download the project from the Github repo below, extract files to a folder, say “C:CubeMX2Makefile”. Install Python 2.7 Win32 from www.python.org

   [code light=”true”]
   c:CubeMX2Makefile>dir /b
   .gitattributes
   .gitignore
   CubeMX2Makefile.py
   CubeMX2Makefile.tpl
   readme.md
   [/code]

3. From command prompt, execute CubeMX2Makefile.py, e.g,

   [code light=”true”]
   c:CubeMX2Makefile>CubeMX2Makefile.py R:411ProjTestF4
   File created: R:411ProjTestF4Makefile
   [/code]

4. Cd into “Toolchain Folder Locaiton”, make project, i.e.,

   [code light=”true”]
   R:411ProjTestF4>make
   …
   arm-none-eabi-size build/TestF4.elf
   text data bss dec hex filename
   5876 12 1056 6944 1b20 build/TestF4.elf
   arm-none-eabi-objcopy -O ihex build/TestF4.elf build/TestF4.hex
   [/code]

   Refer to blog and below links for ARM GCC and make utility installation. It will be much easier to import the Makefile project into Eclipse CDT for code editing and debugging.

Useful links

CubeMX2Makefile: https://github.com/baoshi/CubeMX2Makefile

STM32Cube: http://www.st.com/stm32cube

ARM GCC: https://launchpad.net/gcc-arm-embedded

My packaged GNU Make for Win32: https://ba0sh1com.files.wordpress.com/2020/09/2c1c9-make.zip

The post STM32CubeMX GCC Makefile project appeared first on Digital Me.

The modules I’m targeting are ESP-07 and ESP-12, both having identical pinout but only differ in antenna type. I choose these two because they have all the I/O available, and using same edge castellation (half vias) connectors which is easy to work with.

The modules are 16mm tall, easily occupies 4 rows (2 rows on each side) on a breadboard. Therefore my first design requirement is to minimize real estate on the breadboard. To do this I made some custom pin headers by modifying from SMT pin header.

I removed pair of pins from both ends and replace with through hole pins. This little touch strengthens the bounding between pin header and the board. If otherwise on my first version I can easily pull up all the pads when lifting the board up from breadboard. With this design, I maintain 4 rows occupation on the breadboard, that leaves another 6 rows for wiring.

The boot mode of ESP-8266 is often another source of confusion. The table below summarizes different boot modes during power on or reset:

In firmware flashing mode, user is able to update new firmware from UART0 using FLASH_DOWNLOAD_TOOLS or esptool.py.

The board is designed for ESP8266 developers so reset and flash must be made easily accessible. I designed a simple circuit that only uses one button to perform these two tasks:

During idle state, internal pull-up in the ESP8266 RESET pin turns on Q1. Q2 cut off so GPIO0 remains high due to GPIO0 internal pull-up. At the same time, C1 discharges from R2 and Q1. When user presses SW1, RESET goes low immediately. Meanwhile, Q1 turns off and 3.3V power charges C1 through R1 and R2. If user releases SW1 quickly and the voltage across C1 has not reached Q2’s threshold voltage, Q2 remains off and ESP8266 enters normal running mode. However if user holds SW1 long enough before releasing, Q2 will turn on, pull GPIO0 low. At the moment user releases SW1, RESET goes high but GPIO0 will be held low for a while due to C1 have to discharge through R2 and Q1. The choice of C1 and R2 are such that it keeps GPIO0 low long enough for ESP8266 to enter program mode.

The board also includes a 3.3V LDO (AMS-1117 3.3) and a UART header using FTDI Basic pin out. Below is my programming hardware. (Yes I’m writing OLED driver, which will be release right after).

The schematic and board are designed using KiCad BZR 5312. Windows binary is available at http://kicad.nosoftware.cz/. I have uploaded the schematic and PCB onto my GitHub page at

https://github.com/baoshi/ESP-Breakout

At the moment I’m trying to sell extra boards on Tindie. Please visit my store

Product link -> https://www.tindie.com/products/Ba0sh1/esp8266-esp-0712-full-io-breadboard-adapter/

This is my first attempt to generate some income via hobbyist project. Please support if you also want to join the ESP8266 fun!

Thanks

The post ESP8266 breadboard adapter and I’m on Tindie appeared first on Digital Me.

Digging into BLE upgrade for Macbook Air Late 2010 results in many solutions. The best resource seems to be the “Continuity-Activation-Tool” project, which is made to enable “Continuity” feature on old Mac computers. Since “Continuity” depends on BLE, I suppose this will work with Lightblue Bean. For my model of Macbook, the suggestion is either to add a USB dongle or replace the Airport Extreme card. My poor Macbook only has two USB ports, so replace the Airport Extreme card seems to be the way to go.

The suitable replacement Airport Extreme card with BLE is BCM94360CS2. It can be purchased from eBay or Taobao at reasonable price (~US$20). The kind seller also included a Pentalobe screw driver in the package, which proves to be a life saver later.

For record purpose here are the screenshot of Bluetooth and WiFi page in “System Information” before replacement:

Open the back cover of Macbook Air *REQUIRES* the pentalobe screw driver, and never assume a multi-head screw driver set will contain one.

The original Airport Extreme card has a mouthful BCM943224PCIEBT2 model number. There are two ipx antenna connectors on board, assuming one for Bluetooth and one for WiFi.

My Macbook Air has 11 inch screen. The card placement is different from most online pictures which are for 13inch model. On the 13 inch model the card has longer edge parallel to the casing, but for 11 inch it is perpendicular. It is also reported on many online resources that the antenna cable has to be rerouted to reach the new card. It seems unnecessary for my 11 inch model. I can easily fit the two cables.

At the moment I have no idea which antenna is to fit into which socket. But my random connecting seems to be working. Also noted that the new card is longer than the old one, so the mounting hole is no longer fit. However the socket is tight enough to keep the card in place.

I assemble the back cover and turn on power. Not surprisingly everything “just works”. No error and no “install driver” kinds of message at all. Even the Wireless LAN password and Bluetooth paired devices list are preserved. Here are the system information after replacement:

The Bean Loader seems to be happy with the new card as well.

As a “side effect”, the “Continuity” feature works without any tweaking, together with the “AirDrop” functionality. The replacement worth every cents of it!

The post Macbook Bluetooth upgrade for LightBlue Bean appeared first on Digital Me.

http://youtu.be/h-lI6ucDg8M

The application is made with ESP8266 RTOS SDK. SSD1306 based OLED panel is connected on GPIO4/5 using software emulated I2C. I rushed this out last night and the code is in a mess now.To prevent bad influence I’ll release the code after I reorganize them.

The post Happy New Year from ESP8266 appeared first on Digital Me.

Wish you a very Merry Christmas.

http://youtu.be/aww5O6wBgbw

VFDuino, Arduino compatible Vacuum Fluorescent Display module. Open source release imminent.

The post Season’s Greeting from VFDuino appeared first on Digital Me.

The AVR chip I’m talking about is Atmel ATTiny2313, in SOIC-20 package. To make the development board, I bought some 28 pin SOIC/SSOP to DIP adapters. These adaptors usually come in double sided design. Corresponding pins on both sides are connected via the plated through holes at edges.

I made a 2×3 AVR programming header by pulling off pins (longer ones) from a double-row right angle pin header and reinsert them into the plastic base. A needle nose pliers is very handy for this purpose.

Both the programming header and the chip are soldered onto the SOIC side of the adaptor board. The programming header is taking pin 1-3 and 26-28. ATtiny2313 is taking pin 5-14 and 15-24 (numbering according to adaptor board).

Since the corresponding pads at both sides are electrically connect, it is easy to wire the programming header from the back side or the adapter, using enamel wires and some kapton tape. These pads are 0.5mm pitch so a really fine solder tip is necessary (I use Metcal STTC-126).

Finally install the pins for breadboarding, a minimalism AVR development board is ready to roll. (Picture of ATTiny2313 and ATTiny85 boards below).

The post Minimalism AVR development board appeared first on Digital Me.

1. The device’s MISO (or DOUT) pin uses open-drain output. This is usually true because open-drain allows multiple SPI slaves to share the same MISO line.
2. In the communication protocol, the slave device always waits for the master to send fixed number of bytes (commands) from  MOSI, then returns a fixed number of bytes to MISO. Some devices which transmit and receive data simultaneously cannot be used in half-duplex mode.
3. The slave ignores whatever appears on the MOSI pin when transmitting data to the master. This is usually not mentioned in the datasheet. However, if the slave device mandates a CS or STROBE signal to be asserted at the beginning of each data exchange, we can usually assume this is true. Reason being that the slave device is using CS to reset its internal state rather than always listening and parsing command byte(s) from the master.

Half-duplex wiring of STM32 SPI is as follows:

In particular, MOSI and SCK are configured as “Alternate Function” mode. Hardware CS (NSS) management must be disabled and user shall manually control CS using GPIO output. R2 is pull-up resistor as required by SPI. R1 works as protection resistor in case STM32 MOSI pin somehow enters into push-pull output mode. The SPI setup code is as follows:

[code]
void SPI_Configure()
{
SPI_InitTypeDef SPI_InitStructure;
// Enable SPI1 clock
RCC_APB2PeriphClockCmd(RCC_APB2Periph_SPI1, ENABLE);
// SPI1 configuration
SPI_InitStructure.SPI_Direction = SPI_Direction_1Line_Tx; // Initially Tx
SPI_InitStructure.SPI_Mode = SPI_Mode_Master;
SPI_InitStructure.SPI_DataSize = SPI_DataSize_8b;
SPI_InitStructure.SPI_CPOL = SPI_CPOL_High; // Clock steady high
SPI_InitStructure.SPI_CPHA = SPI_CPHA_2Edge; // Data write on rising (second) edge
SPI_InitStructure.SPI_NSS = SPI_NSS_Soft;
SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_64;
SPI_InitStructure.SPI_FirstBit = SPI_FirstBit_LSB;
SPI_InitStructure.SPI_CRCPolynomial = 7;
SPI_Init(SPI1, &SPI_InitStructure);
SPI_RxFIFOThresholdConfig(SPI1, SPI_RxFIFOThreshold_QF);
SPI_Cmd(SPI1, ENABLE);
}
[/code]

Line 7 sets the SPI peripheral to half-dulex transmission mode. Line 17 sets the SPI FIFO buffer threshold to quarter full. This is new in STM32F0 with 4-byte SPI FIFO buffer. SPI_RxFIFOThreshold_QF meaning that the SPI_I2S_FLAG_RXNE flag will be set as soon as 1 byte (quarter buffer) is shifted into receiving FIFO. SPI master sending data to slave is as simple as:

[code]
void send_byte(uint8_t val)
{
GPIO_ResetBits(GPIOA, GPIO_Pin_4); // CS low
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET); //wait buffer empty
SPI_SendData8(SPI1, val);
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_BSY) == SET); //wait finish sending
GPIO_SetBits(GPIOA, GPIO_Pin_4); // CS high
}
[/code]

The following code demonstrates master sends 1 byte command to slave and reads 1 byte back.

[code]
uint8_t send_and_read_byte(uint8_t cmd)
{
uint8_t result;
GPIO_ResetBits(GPIOA, GPIO_Pin_4); // CS low
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_TXE) == RESET); //wait buffer empty
SPI_SendData8(SPI1, cmd);
while (SPI_I2S_GetFlagStatus(SPI1, SPI_I2S_FLAG_BSY) == SET); //wait finish sending
// Read receiving FIFO until it is empty
while (SPI_GetReceptionFIFOStatus(SPI1) != SPI_ReceptionFIFOStatus_Empty)
SPI_ReceiveData8(SPI1);
SPI_BiDirectionalLineConfig(SPI1, SPI_Direction_Rx);
while (!(SPI1->SR & SPI_I2S_FLAG_RXNE)) ; // wait data received
GPIO_SetBits(GPIOA, GPIO_Pin_4); // CS high
SPI1->CR1 |= SPI_Direction_Tx; // Set Tx mode to stop Rx clock
result = SPI_ReceiveData8(SPI1);
return result;
}
[/code]

Immediately after one byte is sent, the program empties all stale data in the FIFO (line 9, 10), then sets SPI direction to receiving mode (line 11). As soon as SPI enters into receiving mode, STM32 will continuously generate clock on SCK pin until receiving mode is disabled. Along with the clock toggling, data are shifted from MOSI pin into receiving FIFO, and SPI_I2S_FLAG_RXNE flag is set once 1 byte of data is received (line 12). The program then disables CS (line 13, to disable slave output) and switches SPI back to transmitting mode (line 14, to stop the clock). These two steps must be executed fast enough before the next clock is sent out to prevent the slave device enter into any undefined state. Timing is very critical here especially when SPI clock is high. To receive multiple bytes from the slave, put line 9-15 into a loop but disable CS only after all data are read. Important thing is to always disable receiving mode immediately after FIFO is quarter full, and verify using a scope or logic analyser to ensure exact 8 clocks are send in-between each reading.

The post HOWTO: Use STM32 SPI half duplex mode appeared first on Digital Me.