18. July 2020

How to connect ESP8266 Wemos D1 to motor shield over I2C with MicroPython

ESP8266 Wemos D1 board has extension shield TB6612FNG which provides a connection to two motors.

The simplest way to get motors running is to connect the shield to ESP8266 and provide instructions to MicroPython repl so that ESP8266 can send instructions over I2C to TB6612FNG.

The first requirement to get the motor running is to have d1motor library.

You can download ZIP with patched d1motor library and sample code from here.

Original d1motor is available here: https://bitbucket.org/thesheep/micropython-d1motor/src/default/d1motor.py

Use rshell to copy the library on ESP8266 board.

unzip d1motor.zip
cd d1motor
rshell -p /dev/ttyUSB0
cp d1motor.py /pyboard/

Then start repl so that it’s possible to communicate with motor shield. You can exit repl by CTRL+X:

cd /pyboard/
repl

Insert following code:

import d1motor
from machine import I2C, Pin
i2c = I2C(-1, Pin(5), Pin(4), freq=100000)
m0 = d1motor.Motor(0, i2c)
m1 = d1motor.Motor(1, i2c)
m0.speed(5000)

By this moment motor should start roaring and rotating. Well, that would be the happy day scenario. There are several gotchas which you may encounter.

Gotcha #1 OSError: [Errno 19] ENODEV

The code might throw ENODEV error without further explanation of what went wrong. The error means that ESP8266 was not able to find motor board via I2C. You can verify the problem by entering code:

from machine import I2C, Pin
i2c = I2C(-1, Pin(5), Pin(4), freq=100000)
i2c.scan()

The correct result should be array with 48 which is 0x30.

[48]

If you get just empty array then the boards are not able to talk over I2C:

 [ ]

The most common reason for the problem is buggy version firmware in STM32F030. You must flash it according to instructions from hackday.io.

You will need UBS2TTL module to perform flashing.

Download patched firmware: motor_shield.bin

Connect by single wire RTS with 3V3 PIN – they’re next to each other.

Connect folling wires on main part of board (not part with RTS):

GND - GND
3V3 - 3V3 VCC on USB2TTL
D2 - TX
D1 - RX

Install stm32flash:

sudo apt-get install stm32flash

Unlock and flash the shield:

stm32flash /dev/ttyUSB0 -k
stm32flash /dev/ttyUSB0 -u
stm32flash /dev/ttyUSB0 -v -w motor_shield.bin

After flashing unplug wires and connect the shield back to ESP8266. Run I2C scan again and you should get the correct result:

from machine import I2C, Pin
i2c = I2C(-1, Pin(5), Pin(4), freq=100000)
i2c.scan()

[48]

Gotcha #2 Standby mode not controlled by I2C

Even after the first correction, the motors might not move and there is no voltage on A1-2 or B1-2. The problem is most likely caused by Standby mode.

Check your board and you should see STBY with 3 pins and with marking I2C and IO. You need to solder top and middle pin to enable I2C control of Standby mode. Solder them and plug the board again. Now motors should start to move.

Does it work? Congratulations.

Big thanks to community Radomir Dopieralski for d1motor.py, aarn_a and Matrix User for hints about Standby mode.

Facebook Comments

16. July 2020

systemctl Failed to list units: Access denied

During the upgrade of Debian or Ubuntu server you may encounter strange failing of scripts which are restarting services.

For some reason it’s not possible to call systemcl and any operation fails with Access denied even for root.

Here is example:

systemctl list-units
Failed to list units: Access denied

The fix to this problem it is sufficient to send TERM signal to process with PID #1:

kill -TERM 1
Facebook Comments

27. June 2020

ESP32 erase_flash failed with “Invalid head of packet”

The first step before installing MicroPython to ESP32 is to erase the flash.

I’ve installed all necessary software like esptool, but the flashing was failing with error:

esptool.py --chip esp32 --port /dev/ttyUSB0 erase_flash                                                                                                         ──(Sat,Jun27)─┘
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Invalid head of packet (0x1B)

The solution to the problem is to pres and hold BOOT button. Then start erase command mentioned above.

After the initial erase I was able to flash there MicroPython:

esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 460800 write_flash -z 0x1000 esp32-idf4-20200627-unstable-v1.12-590-g9f911d822.bin

Then it was possible to connect via rshell:

rshell -p /dev/ttyUSB0                                                                                                                                          ──(Sat,Jun27)─┘
Using buffer-size of 32
Connecting to /dev/ttyUSB0 (buffer-size 32)...
Trying to connect to REPL  connected
Testing if ubinascii.unhexlify exists ... Y
Retrieving root directories ... /boot.py/
Setting time ... Jun 27, 2020 20:46:47
Evaluating board_name ... pyboard
Retrieving time epoch ... Jan 01, 2000
Welcome to rshell. Use Control-D (or the exit command) to exit rshell.

/home/georgik/projects/esp32> cd /pyboard/
/pyboard> ls
boot.py
Facebook Comments

21. June 2020

Learn to draw with tablet online app

Learning to draw takes time. Here you can find simple online app which can help you with the task.

The current version contains line drawing exercises: vertical line, horizontal line, diagonal line /, diagonal line \, X, Y, circle, half of circle.

It’s possible to draw by mouse, tablet or by touch (e.g. mobile device screen).

Suggestions for improvement are welcome. Feel free to post them to comment section.

Facebook Comments

16. February 2020

Unable to upload Xamarin app with C/C++ code to Google Play – solution

After finishing release build of your Android application with Xamarin – Visual Studio 2019 you may experience the following error when uploading the app to Google Play Console:

Warning!
This release is not compliant with Google Play 64-bit requirement.

The following APKS or App Bundles are available to 64-bit devices, 
but they only have 32-bit native code: 1000.

Even when your application contains ARM and ARM64, it might still happen that Google refuses to accept your app and returns just the same error message.

The reason is simple: Google requires that your app with native code bundled as AAB (which is ZIP) contains also libraries for 64-bit platform. It does not matter which architecture.

The error is often caused by building application also for Intel platform because emulators on Intel are faster. There are two options to resolve the issue:

  • remove Intel platform from release build
  • add also 64-bit version for Intel platform to release build

Google is checking each platform and your .so files should be mirrored for 32-bit and 64-bit. If your bundle is not consistent then Google will refuse your application.

To fix this problem open Visual Studio 2019. Click your project in Solution Explorer. Open Properties (ALT+Enter).

Click Android Options, scroll down to Advanced button. Click Advanced button.

Uncheck all Intel platform (or check them all, based on your preference) and click Close.

Press CTRL+S to save changes. Create a new archive of your application (menu Build – Archive…)

Upload the new AAB.

If you don’t know how to switch to AAB, just go back to Android Options. Search for Android Package Format and select ‘bundle’.

Facebook Comments