Writing commands to a microcontroller with a STM32f chip from python

Question

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 micro controller on Amazon: https://www.amazon.com/Channel-Controller-Bluetooth-steering-Raspberry/dp/B018YP228A/ref=sr_1_1_sspa?keywords=usb+servo+controller&qid=1562646724&s=industrial&sr=1-1-spons&psc=1

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.

Motor Control software with GUI: https://drive.google.com/file/d/0B8PmY6nhQadKR013T2hDQXJxaWc/view?usp=sharing

Update: Read also stalls.

>>>sc.read()  # Stalls

Answer 1

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.

Answer 2

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.