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 ?
You do realize that a short time quanta for the OS is not the only way to control how handle fast sampling of a sensor?
I'd say that having a really short time quanta is actually a quite bad idea.
A much better route is to program a timer to generate a timer interrupt at your required frequency. Then in the ISR you start a sensor conversion. Let the sensor generate an interrupt when the data is available and pick up the result. Or pick up the result on the next timer interrupt just before you start the next conversion.
Each time you do get an answer, you can place the data in a queue and have a thread pick it up. If you want it to be picked up quickly, you can trig an event. Or you can use a mailbox and send the data. Or, if there is no need to react instantly, you can have a thread poll the queue n times/second and see how many samples that are available for processing.
Another thing to realize - sometimes a program might need to have delays that are longer than what a timer can handle. The trivial way to solve it is to use a software counter. So if the timer can measure up to 1 second, and you need a 30 second delay, you can wake up 30 times update the software counter - when it has reached 30 (or zero if you decrement) then your 30 seconds have passed.
So don't expect to be able to create all your delays as a single delay. Much embedded applications may make use of a 1kHz timer interrupt. Each interrupt represents 1ms. But the ISR can increment a 1ms counter integer each time. When that counter reaches 1000, 1 second has passed. So the ISR can reset the 1ms counter, and instead increment a 1-second counter. And with a 32-bit integer for the 1-second counter, you can get that 1kHz interrupt to solve delays of over 100 years. Not enough? So count 24*3600 seconds, and then increment a 1-day counter. Then your program can use a 32-bit integer to keep track of a delay of over four billion days...
Don't spend your time getting stuck. Spend your time looking for opportunities. Be creative. Experiment. Before we got our 8-bit microprocessors, people managed to go to the moon. So a 16-bit limitation for the OS delay function can hardly be seen as a big problem to overcome.
Thank you in advance for your good and complete answer .For your first answer i have problem because i used some shift registers instead of FPGA and i lose time in each reading sensors and my device should respond fast to any sensors changing state.in one of my tasks i read sensors and write output and i use mutex for doing that so if i want to read them in ISR interrupt i must use mutex because reading and writing are on a same bus or pins.Can we use mutex in ISR or not?
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.