stm32 | STM32 stuff

I had the same problem, man. I want to transplant tflite to the development board of CEVA. There is no problem in compiling. In the process of running, there is also an error in AddBuiltin(full_connect). At present, the only possible situation I guess is that some devices can not support tflite.

OpenOcd manual explains how to select a specific port number inside the configuration file as shown in image below:

Since HAL_SPI_Receive is already using HAL_SPI_TransmitReceive (github stm32f4 spi driver) to send dummy data to generate clock, you can use that fact and ditch the HAL_SPI_Transmit, and use the receive function like this:

You have an error somewhere else. Maybe you simply do not use this linker script (you forgot to add or change the name in the command line)

I have compiled it and linked it without any problems with CubeIDE (I use 100 and 100 in the buffer declarations as I do not know the values of your macros [100x100 = 0x2710])

The ST-LINK probe you have doesn't provide a virtual serial port functionality. It's a debugger/programmer using the SWD protocol.

I'm not familiar with using STM32 with Arduino framework, but in order to use Serial class of the Arduino framework, you probably need to access one of the hardware serial ports of STM32F103.

In this case, you need an external USB - Serial converter which works with 3.3 volts logic levels and connect it to the relevant serial port pins of your Blue Pill board.

Some ST-LINK models also provide embedded USB - Serial converter interface along with the SWD functionality. But even if you have one of those, you still need to physically connect ST-LINK serial pins into the Blue Pill serial pins.

Let's focus on TX only and assume that we don't use interrupts and handle all the transmission with the tools provided by the RTOS.

µC UART hardware generally have a transmit shift register (TSR) and some kind of data register (DR). The software loads the DR, and if the TSR is empty, DR is instantly transferred into TSR and TX begins. The software is free to load another byte into DR, and the hardware loads the new byte from DR to TSR whenever the TX (shift-out) of the previous byte finishes. Hardware provides status bits for querying the status of DR & TSR. This way, the software can using polling method and still achieve continuous transmission with no gaps between the bytes.

I'm not sure if the hardware configuration I described above holds for every µC. I have experience with 8 & 16-bit PICs and STM32 F0, F1, F4 series. They are all similar. UART hardware doesn't provide additional hardware buffers.

Now, back to RTOS... Obviously, your TX task needs to be polling UART status bits. If we assume that UART baud rate is 115200 (which is a common value), you waste ~90 µs of polling for each byte. The general rule of RTOS is that if you are waiting for something to happen, your task needs to be blocked so other tasks can run. But block on what? What will tell you when to unblock? For this you need interrupts. Your task blocks on task notification, (ulTaskNotifyTake()), and the interrupt gives the notification using xTaskNotifyGive().

So, I can't imagine any other way without using interrupts. But, the method mentioned above isn't good either. It makes no sense to block - unblock with each byte.

There are 2 possible solutions:

1. Move TX handling completely to interrupt handler (ISR), and notify the task when TX is completed.
2. Use DMA instead! Almost all modern 32-bit µCs have DMA support. DMA generates a single interrupt when the TX is completed. You can notify the task from the DMA transfer complete interrupt.

On this answer I've focused on TX, but using DMA is the proper way of handling reception (RX) too.

When the desired stream is activated, the relevant registers can no longer be configured. Only in dual buffer mode can memory addresses 0 and 1 be updated according to the bit CT function. You must first deactivate the relevant channel and then apply the changes.

I have found a way to use the USB port for communication. This is done using STM32CubeIDE

1. Launch STMCubeIDE software.
2. Select the USB_OTG_FS and set as device only mode.
3. Then in middleware tab select the Class for FS IP as Communication device class(virtual com port).
4. Set the clock frequency for USB as 48MHz.
5. Generate the project.
6. Read the usbd_cdc_if.c file
7. Include the usbd_cdc_if.h in the main and send some data using CDC_Transmit_FS
8. In Ubuntu, open a terminal and search for two ACM ports using ls /dev/tty, ACM0 and ACM1/ACM2 (which are STLINK-V3 and Virtual ComPort)
9. Test using serial terminal (like Serial Monitor of Arduino IDE).

I took your program (your first parentheses is redundant, so I removed):