Program cycle.

[James144]

Hello I started working on my school project with ChibiOS and STM32F4 discovery few weeks ago. I´m absolute newbie. I have already tested reading and writing IO, ADC, PWM, making threads, but nothing complex. So maybe someone with more experience could give me an advice with this:

Im trying to make program which will work in cycle: Reading inputs(DI,AI), Main program(calling subroutine), Setting outputs(DO), Communication in backcround. Something like PLC cykle.


What is the best way to make program like this? How to use semaphores, mutex, threats atp. Im asking this because doing mistake at the beginning of desing, create a lot of problems in future.


Thank you very much and sorry for my english.

[Giovanni]

It is a simple loop application, probably you will not need any threading from what I can see.

I can suggest an approach, try writing down the "requirements" for your application and start from that for your design analysis. A requirement is a small tagged paragraph that describes a specific aspect of your application, for example:

MYAPP12: The input sensor shall be read ten times per seconds.
MYAPP13: Communication shall be performed in background without affecting the main loop.
MYAPP14: ...
etc

Keep them short and unambiguous. Once you have the full list of your requirements we can start thinking to how to translate those into a design.

Giovanni

[Vic20]

The system requirements are not clear enough to give a proper response.

How real-time is the system?

Do the measures need to be done a exact intervals? What is the interval time?

That could need, at least one GPT.

Do the outputs need to be generated also at exact intervals?

Does the jitter matter to you?

What kind of communication? Serial, TCP/IP...

Does it need user interaction using buttons or an LCD for instance?

As a first approximation I would use a thread for communication that uses a mutex to protect the shared memory area with the main program and a semaphore for the a data update signal.
The main thread could do all the normal cycle.
If there is some need for user interaction a part from the communication it could be done in another thread.

As a general rule I would put anything that could block or could be slow in a thead independent with the main loop thread.

Best regards

Vicente