TouchGFX + Free RTOS TImer and Thread

[MauFanGilaMedical]

Hello.

I'm using STM32H747XI with touchgfx designer 4.24.2 and Free RTOS 10.3.1.

In this RTOS I setup some threads(with osPriorityNormal 24) and a Periodic Timer at 400ms.

I notice that when I start this thread

	void threadEntryPoint() {

		// Pulisco la FIFO del'RX USART
		__HAL_UART_FLUSH_DRREGISTER(BARCODE_UART);

		char msg[BARCODE_LENGTH+1];

		while (;;) {

			memset(msg, 0, sizeof(msg));

			// Appena vedo il primo carattere ...
			if ( HAL_UART_Receive ( BARCODE_UART, (uint8_t*)&msg[0], 1, 50 ) == HAL_OK ) {

				// ... ricevo gli altri
				HAL_UART_Receive ( BARCODE_UART, (uint8_t*)&msg[1], BARCODE_LENGTH - 1, 50 );

				if (strchr(msg, BARCODE_SUFFIX)) {

					queue.put(msg);
				}
			}
		}
	}

Timer will not trigger.

Is the reason that I have no osDelay ? Or a priority question ?

Thankyou in advance.

[gbm]

If your UART task is the only highest priority task, then other tasks will not run at all. If it has the same or lower priority as any other task, UART data will not be received correctly. A really bad alternative. 

Basically all HAL_UART_Receive functions are close-to useless. What you need in a real world is always-enabled reception using UART interrupt and "byte received" callback (or an equivalent processing block written inside UART ISR). The simplest to write but not the most efficient way of doing this under RTOS is to put data into a queue (but that's not exactly what the queues are for - overkill) or raise a semaphore when a byte is received (may lead to losing data).

[M_Schmidt]

@gbm 
https://controllerstech.com/stm32-uart-5-receive-data-using-idle-line/
Have you looked at this example? It is the perfect implementation assuming the bar-code scanner is not continuously sending data and there are always pauses between data transmissions. No need for RTOS queues/semaphore. Just a simple flag and a large enough buffer will be sufficient for the given requirements. 

[gbm]

Yes, it could be done that way (with some problem which could be easily avoided with "byte received" callback from ISR). And semaphore is a much better idea in this case than a flag tested in a polling loop - something in direct conflict with the concept of RTOS.

With RTOS, there should be no polling loops other than the ones using OS blocking calls as their "condition".

[MauFanGilaMedical]

I read all solutions proposed to me but I prefer for now to use this solution even is not the best for CPU consumption.

I agree that use DMA unload CPU and INT load CPU just in the case a byte come from RS232 but, for question of develop time, I prefer to maintain thread solution. Thankyou @gbm , @M_Schmidt .

Here my Code.. I write a note to probe DMA o INT solution in the future.

	void threadEntryPoint(ThreadHandle<BarCodeGun> &threadHandle) {

		// Pulisco la FIFO del'RX USART
		__HAL_UART_FLUSH_DRREGISTER(BARCODE_UART);

		//tempo di attesa termine trasmissione codice a barre
		uint32_t Timeout = 10 + 10*1000 * (BARCODE_LENGTH - 1) / BARCODE_UART->Init.BaudRate;
		char msg[BARCODE_LENGTH+1];

		while (!threadHandle.isRequestToExitPending()) {

			threadHandle.wait(4);//messo perchè altrimenti l'alive timer non viene eseguito, ricorda che per riempier il buffer da 16byte ci vuole 16[byte]*10[bit/byte]/9600[bit/s] = 17ms

			switch (HAL_UART_Receive(BARCODE_UART, (uint8_t*)&msg[0], 1, 0)) { // Appena vedo il primo carattere ...

				case HAL_OK:

					// ... ricevo gli altri
					memset(&msg[1], 0, sizeof(uint8_t)*sizeof(msg)-1);
					HAL_UART_Receive ( BARCODE_UART, (uint8_t*)&msg[1], BARCODE_LENGTH - 1, Timeout );

					// ... verifico il suffisso
					if (strchr(msg, BARCODE_SUFFIX)) {

						queue.put(msg);
					}
					break;

				case HAL_TIMEOUT:

					continue;

				default:

					Error_Handler();
			}
		}

[gbm]

That has no chance to work correctly when you add some other tasks.