So I came up with this simple flow of the program that could be done without RTOS but I'm using it for the sake of learning.

The generic idea is to get the user input over UART, and if it's something regarding data query, the data query task wakes up, reads the sensor data, wakes up the other task to transfer the data over to RX module.

In other words, I have ulTaskNotifyTake() in, say, a Data Task which waits on a notification from a UART task. Upon receiving an input over the UART regarding the query of this data, the UART task would call xTaskNotifyFromISR() from the UART's ISR waking up the Data Task, which would query the sensor data...and so on.

Does the generic flow sound OK? I'm still going through a bunch of FreeRTOS docs on APIs but that's a raw image that I thought of. Any suggestions are appreciated.

enter image description here

  • \$\begingroup\$ i think that you need to go ahead and try your idea ... come back if you encounter any problems ... it is pointless to be asking your question at this stage because it is an opinion based question, which is not on topic here \$\endgroup\$ – jsotola Aug 5 at 16:50
  • \$\begingroup\$ true, but I was trynna get things straight prior to implementing \$\endgroup\$ – Pokloha Aug 5 at 16:52
  • \$\begingroup\$ @Pokloha What else is your software supposed to do? Because if the only thing you need to do is accept requests for data and respond to them with a reported value, I've no idea why FreeRTOS is involved at all. It's just way, way too simple. \$\endgroup\$ – jonk Aug 5 at 20:53
  • \$\begingroup\$ like I mentioned, I am using rtos for learning purposes; I previously did it before in bare-metal where I was constantly waiting till a meaningful value was inputted and then serviced the request along with sending the data over to a receiver. In what way could rtos be worth using for a similar use case? \$\endgroup\$ – Pokloha Aug 5 at 22:15
  • \$\begingroup\$ @Pokloha Well, first off you probably don't need an operating system with a focus on "real time" features. In fact, you'd be a lot better off with something quite simple. (It would take me two days, completely from scratch using C and assembly, to write an O/S with threads, inter-task messages, round robin and priority support, and semaphore and sleep queues.) What an O/S buys, and it is worth the trouble often, is simplicity and relative easy maintenance of code. The separate stacks in each thread buy you a lot in that regard and it is worth having. \$\endgroup\$ – jonk Aug 6 at 1:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.