Practical project specifications of hard real-time system

I am looking for Practical project specification for hard real time system before writing any code. I am trying to better understand RTOS and the use cases. Blinky LED’s is clearly not a time critical application with no real deadline and does not require an FreeRTOS.

can anyone share hard real time project specification ?

High fidelity motor control while simultaneously communicating over http, canbus, and a local human interface.

1 Like

I searched on google by name “High fidelity motor control” but I am not able to create specification for this project. What are the hard time constraint in the project. What are deadline?

Commutation event will be the deadline, if you commutate later than the deadline you will reverse the motor torque and stall it.

1 Like

I want to know more about this project. Do you have any link explaining about the time limit of tasks in project.

I am trying to find out what is the time limit for each task and if the deadline is missed then What are consequences

I’ve just given you a hypothetical application that has both hard real time requirements (i.e. motor control), soft real time requirements (i.e. user interface), and some in between. There are lots of ways you can do motor control and the consequences of missing a deadline could only be stated for a real application.

1 Like

i thought you made the project but never mind i can get more help from hypothetical situation.

It will be more helpful for me, if you can further explore this hypothetical question like would you please tell me which task is to be given which priority? What would be the time limit for each task? What happens if a task exceeds the deadline?

This complete hypothetical situation will make it easier for me to understand how to prioritize tasks and set deadlines in project.

I appreciate your time and effort

This is a device with 8 seven-segments display (the display should never have visual artifacts), a 4-key keypad (the device must be always responsive), rotary sensor (you can’t miss a single ongoing pulse!). The device must report to a PC (in real time) via USB. Besides, it must receive simple commands (and execute them as soon as possible) and data updates (for example, system parameters) via WiFi (ESP8266, for example). Think of it a smart odometer.

Have fun!

1 Like

I don’t understand here what is the deadline for each task and how to set the priority of all the tasks

I agree. I wouldn’t consider Xavier’s use case hard real time either. Cobus’ is definitely a better place to start from.

1 Like

Try it and then we can discusse it :slight_smile:

You don’t appear to understand what hard real time means. You may want to look up the definition of that term.

1 Like

Yes, I know ;), but this example is good enough for a newbie, and even better, he can build it and program it in his lab with common components!. While developing this project he’ll understand a lot of concurrency and real time concepts (and problems). Be humble :slight_smile:

Here is another simple example. I used to do a lot of work on Video systems. Sometimes we need to either create an analog video signal or construct a text overlay on top of the video signal. Here is a project that does this and does a decent job at explaining the technology.

Since the position and color of the text overlay is determined by the precise timing when it is created there is a hard realtime requirement to sync the actions with the video signal.

http://www.hpcc.ecs.soton.ac.uk/dan/pic/video_PIC.htm

There are a lot of more complicated systems with hard real-time requirements. Things that come to mind are hard drive magnetic head controllers, controllers for visual effects like lasers using in light shows and cellular phones, the 3GPP GSM specifications require very precise timing for when time slots start and end and if you violate these you interfere with other users.

1 Like

Just for fun, one application where blinking an LED is timing critical is on fiber optic cables when you are building communication systems. I once worked on some DWDM systems with Marconi, lots of hard real-time requirements when you have 64 channels of communication on the same fibre and you need to make and break connections using MEMS mirrors …

1 Like

As far as i understand we can’t send all lines at once so we should send evena line first and then odd line. If we send all the lines at once the screen will appear blurry.

I can’t figure out what are the time critical tasks in your system and what is the time limit for each task.

Richard Barry wrote:

High fidelity motor control while simultaneously communicating over http, canbus, and a local human interface.

That is exactly what we use FreeRTOS for. Our customers use it in 3D printers. CNC machines, laser cutters and similar devices. GitHub - Duet3D/RepRapFirmware: OO C++ RepRap Firmware

1 Like

If you want to understand this you need to understand how the analog video signal works, from your description you have no idea. It is true if you want to put text on the screen getting the pixel timing wrong will make the overlay fuzzy/blurry, but the real time work is generally around the horizontal and vertical sync times.

The analog video signal is a critical timing specification, it specifies that a horizontal sync signal will be generated roughly at 15.7kHz. There would thus be a Horizontal sync task that creates this sync at precisely the right time. It is also customary to transmit control data like colorburst data during this period, it could be the same task or a different one that does this. (note this is every 6.369 microseconds.). This, and the vertical sync time which is once per frame (20ms) is usually the only time the microcontroller has time to do communications to receive new data to put on the screen.

You probably have a comms task that will receive and process the data but it has a deadline to complete the work before the next horizontal or vertical sync ends.

If you are interested in this use case you can read the page I linked it is nicely explained.

1 Like

Looking at the image you linked, We have 12us of synchronisation just before we draw any image on the screen itself. we then have 52us in which to draw one line of image data.

PIC16F84 has 68bytes of memory. Operating at 12Mhz. It can be performed 156 instructions in 52us

I am trying to figure out what are the consequences of limited memory with low speed on screen