Dear Sir/Madam I configured my RTOS tick on 25us in order to read sensors fast. but in other hand i need to have for example 50 seconds delay in my program.So i use
void os_tmr_call(U16 ifo)
and
os_tmr_create(U16)
;U16 lenght is 65536 and as you know maximum delay is 65536 X 25us = 1.63 S if i will be able to use U32 in os_tmr_create problem will be solved but i can't. Also i don't want to stop program in a line.I mean i don't want to use for example
for(i=0;i<50;i++)os_dly_wait(40000);
and just want to use virtual timer or something like that.
Could you please tell me how can i increase delay time to 50 S or more base on 25us tick ?
I'm not sure about what you mean when you talk about a mutex here.
A mutex is something used to synchronize access to some data or some peripherial. So in this case, it isn't obvious if you are actually meaning a mutex, to synchronize I/O between multiple threads. Or if you might mean a multiplexer, which allows multiple I/O signals to share the same set of I/O pins.
You should plan your hardware carefully, based on what cost it will be for the software to interface with the hardware. It's seldom good to mix fast and slow I/O in ways where you can't take advantage of your chips ISR for the fast tasks. Or where the mixing will disable your ability to use whatever hardware acceleration the processor might support.
When selecting what chip to use, you need to plan for the actual coding that will follow. When interfacing external functionality to the selected chip, you need to plan for the actual coding that will follow. So when a team work on a project, the hw guys and the sw guys needs to be involved and share views/knowledge all through the project to make sure the end product will be able to work well. And the component price needs to be balanced against the usability of the selected components.
In this case, you might be able to let your ISR both service the sensor and perform other output - so the other parts of the program might write to a global variable what output state they want and the ISR then mirrors that output state at the same time as it accesses the sensors.
But if that is practical or not really depends on exactly how your I/O is connected. And exactly how fast you need to control different I/O. And how long time it will take for the ISR to touch the different I/O signals needed to either service the sensors or to control whatever other I/O that you need to synchronize the access to. Each individual ISR call should end quickly to avoid latency issues with other interrupts or with high-priority tasks. And the total time consumed by all the ISR processing must be low enough that the remaining CPU time is enough for the business logic - i.e the main loop or the set of OS tasks. Only you will know how fast you can make that ISR - and how often you need the interrupt to happen.
Thank you for your ideas.They are very useful.I used mutex because i must to read 8 pins ic buffer for reading about 30 sensors and simultaneously i must to write about 40 outputs with these 8 pins buffer.timing is very important in this case so mutex guaranties access blocking to this I/O peripheral from another part of codes.
"timing is very important in this case so mutex guaranties access blocking to this I/O peripheral from another part of codes."
But the big question is: "should there be another part of the codes"?
It's common to write code like layers of an onion. So you have "kernel" code taking care of I/O. And then other code that makes use of this "driver layer". And at the top you have business logic that processes received data and produces new output data.
In a layered approach, you should see if you need more than one single function for accessing this group of signals.
A mutex implies that you need to synchronize between multiple OS tasks. But if all the signals needs to be accessed with critical timing it's very strange that you would let multiple tasks - that will obviously run at different timing - share the access to the signals.
Yes in this projects I have 10 tasks and one of them reads and writes I/O and i used mailbox for accessing data in this task between another tasks.but as i said before i configured Tick time on 25us and you advised i can do read the sensors in ISR and increase tick time around 1khz in order to increase delay time in os_tmr_create();
If only one task is using the IO, then you don't need any mutex - a mutex is only needed to synchronize access between multiple threads.
And a mutex can not be used to synchronize between an ISR and a tread, since the OS can't make the thread release the mutex if the ISR wants access.
Ok Thank you for your last answer.this is very important note.