Writing commands to a microcontroller with a STM32f chip from python

Manual to the micro controller: https://drive.google.com/file/d/0B8PmY6nhQadKSVc5OE04c3ZJaFU/view?usp=sharing , where page 18-19 introduces the serial communication protocol.

The microcontroller is connected via USB to a Raspberry Pi 3b+.

I am on my Raspberry with Python 3.5.3 and pySerial. In python command line I can write:

>>>import serial  # pySerial
>>>sc = serial.Serial('/dev/ttyAMA0', baudrate=9600)


(I found the port name ttyAMA0 using dmesg | grep tty) Then

>>>sc.write(b'')  # Instantly returns 0
0
>>>recovery = [0xFF, 0x0b, 0x00, 0x00, 0x00]  # Any 5 bytes command packet.
>>>sc.write(bytes(recovery))                  # Stalls until write_timeout



I have been unsuccessful in sending any actual packet to the port, as when i write, the python command line never returns, unless I specify a write_timeout, in which case it raises the serial.serialutil.SerialTimeoutException. Does anyone have experience with controlling microcontrollers with python? Should I be using pySerial at all?

I can control it through the GUI of the Motor Control software, but I want a sort of API (Python highly preferred) to automate things.

>>>sc.read()  # Stalls


• Maybe you have not disabled flow control? Pi serial ports can be weird in a number of ways, you should first try this on a desktop Linux with a USB serial converter and get it working there, then worry about the pi (or move the USB serial over too). – Chris Stratton Jul 17 at 20:44
• Thanks Chris, I will look into that. I can add that I previously controlled a Tiny-G in a similar way from the same Pi. The Tiny-G accepts G-code commands and scripts like sc.write('G91 \n'.encode('ascii')), no issues there. – mhh Jul 17 at 22:31
• On the Pi 3 you should be using /dev/ttyS0 instead of /dev/ttyAMA0. Since this is different on different Pis you can use the alias /dev/serial0 to select the primary UART. – evildemonic Jul 17 at 23:01
• The fundamental thing to understand is that the peripheral cannot stall your write by itself. It could only do that if you had hardware flow control enabled, which 95% of the time the peripheral will not even support, causing any such stalling to be erroneous. – Chris Stratton Jul 18 at 12:07
• Why wouldn't you expect read to block? Your issues seem to be with misconfiguring the pi, not the device. – Chris Stratton Jul 19 at 13:55

The microcontroller is connected via USB to a Raspberry Pi 3b+.

This is not consistent with the serial port you're trying to use.

Both /dev/ttyAMA0 and /dev/ttyS0 are your Rpi's UART.

Try connecting to /dev/ttyUSB0.

If that won't work, try disconnecting and reconnecting your microcontroller and running $dmesg | grep tty. That should give you the right port number, but you should look for /dev/ttyUSBxx tags. According to the manual, you device uses the Silicon Labs CP210x chip, which is been reported to be working with a recent (post 2015...) Raspbian version out of the box. Note that you can also use the raw UART on the board if you connect them to the RX and TX pins (plus GND) to the hardware UART on your Rpi (in that case, of course, you'd have to use /dev/ttyS0 or /dev/ttyAMA0 as required). EDIT: On the comments below you say you have a driver problem. Apparently, the USB VID and PID of your device is not included in the driver library so it's not being loaded by default. Of course, it's up to you to choose whichever connection is more convenient for your purposes but the driver problem can be fixed easily, so I think it's a good idea to write up here too. According to your own answer, the details of your device are: VID=0003, PID=1920. With this information and the driver name (CP210x) you can follow this procedure to check if your driver can be loaded manually: First, get root permissions with: $ sudo -i


Next, move to the driver folder (note that the exact name of the folder might change, depending on the device you have, it might be cp2101

$cd /sys/bus/usb/drivers/cp210x/  And assign the VID and PID of your product to the driver's new_id file: $ echo 0003 1920 >new_id


That should make available your device as a serial port on /dev/ttyUSB0.

If you manage to make it work and want to keep it permanent (otherwise you have to load the driver manually with these steps on every reboot), you can take a look here.

• Yes I ended up going to the raw UART on the Pi after using dmesg to realize that my Pi and also my Ubuntu laptop only recognized the USB port as a "Human Interface Device". – mhh Jul 21 at 0:56
• I think the USB vendor ID is not in the driver database. You can try to load it manually with something similar to this but you'll have to change the VID and PID values and the folder. – Marcos G. Jul 21 at 5:13

I gave up on operating through the USB port.

Instead I connected it the Pi's GPIO pins following this tutorial: https://www.teachmemicro.com/raspberry-pi-serial-uart-tutorial/?fbclid=IwAR0-vV9uKcgYYwTzd2QFavY38lQjEmp0m4xJIltyy8UDvaumGwoNV3rD2C8

Rewind:

To check if it could be found by USB, I did: python3 -m serial.tools.list_ports and dmesg | grep tty The above two commands showed ttyAMA0, which was a Unicornhat I had on the pins.

watch "dmesg | tail -n 20" while plugging the USB in and out, to see what showed up. That revealed something new. hid-generic 0003:1920:0100.0002: hiddev96,hidraw0: USB HID v1.10 Device [Wit-Device Wit-Motion ] on usb-3f980000.usb-1.1.3/input0

Alternatively, dmesg | grep Wit also shows: hid-generic 0003:1920:0100.0002: hiddev96,hidraw0: USB HID v1.10 Device [Wit-Device Wit-Motion ] on usb-3f980000.usb-1.1.3/input0

After that I also concluded that the driver was most likely missing. Then I changed to using the GPIO pins, since that is suggested in the question section on the Amazon reference (see question) and the first answer and others. This lead me to the solution above.

• I have edited my answer with details to fix your driver problem, in case you want to try. – Marcos G. Jul 21 at 10:02