Search Results
Search results 61-80 of 322.
This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.
-
Hello Marek, Quote: “Is it possible to get the CMSIS-rtos solution as support from you?” Yes, sure. Are you looking for CMSIS-RTOS v1 or CMSIS-RTOS v2? arm-software.github.io/CMSIS_5/RTOS/html/index.html arm-software.github.io/CMSIS_5/RTOS2/html/index.html We have support for both versions but they are sold separately. Quote: “Is your solution compatible only with some specific embOS version (oldest which we are using is 3.88)?” CMSIS RTOS v1 layer can be used with any embOS version. CMSIS RTOS …
-
Hi Markus, Quote: “In the RL78 embOS manual it is described that zero-latency interrupts must not execute any embOS function. Therefore it is not allowed to call the functions OS_EnterIntStack resp. OS_LeaveIntStack, is that correct?” Yes, that's correct. Quote: “This means that all tasks must preserve some space on their stack for the zero-latency interrupts because the switching is not allowed. Depending on the zero-latency ISR implementation this can afford large stacks for all tasks...” Unfo…
-
Quote: “ If I'm correct, my watchdog in Idle loop is efficient for: -> trapped in OS_Error(), -> infinite loops without OS_Delay() consuming all the resource, ” Yeah, that's it. Usually you don't have the debug code and OS_Error() in your release firmware. Although you can do so, of course! But in that case you could also directly reset your microcontroller in OS_Error().
-
Dear JLuc, Quote: “In my mind, if any task is blocked, the idle loop is not reached anymore and the hardware watchdog is triggered.” There could be situations where one task is not running as expected but OS_Idle() still gets executed. Also triggering the watchdog in OS_Idle() only does not help because there could be a task which runs for a long time and therefore you don't reach OS_Idle() on time. I guess you think of situations only where the CPU "stops" in a task and no further code gets exe…
-
Hello Bryan, i am not aware of such an issue but please let me double check tomorrow (I am not in office right now). We will contact you directly by email or phone. I am pretty sure we can solve your issue tomorrow. Quote: “This mentions making the buffer size larger than the sum of all messages, but it doesn't state HOW MUCH LARGER. Any clue?” The queue data buffer contains the messages and some additional management information. Each message has a message header containing the message size. Th…
-
[SOLVED] Will OS_EnterRegion()/OS_LeaveRegion() prevent a software timer from running its handler?
PostHi Kenny, Yes, embOS software timer are executed from within the scheduler. Therefore you should keep your critical regions with OS_EnterRegion()/OS_LeaveRegion() as short as possible. Best regards, Til
-
Hi Gautam, do you have an embOS license or are you working with an embOS trial version? You can also contact our embOS support directly per email. Please find the email address in the embOS manual in chapter "Support". OS_InitKern() does not call OS_Delay() at all. I don't see your call to OS_Delay() in your code snippet. Please be aware OS_Delay() can only work after the hardware timer was initialized and interrupts are enabled. This is usually done in OS_InitHW(). If you call OS_Delay() in mai…
-
Hi, from the embOS manual: Quote: “pfResetFunc may be used to perform additional operations inside a callback function prior to the reset of the microcontroller.” The reset function is optional and gives the chance to react on such a situation. You could e.g. write a message in a log file or set a piece of hardware in safe state before resetting the μC. The basic idea is that one hardware watchdog is not enough for an RTOS with multiple tasks. If you would trigger the hardware watchdog in one ta…
-
The best and easiest solution would be to use our RTOS embOS instead of FreeRTOS or ThreadX. embOS is already prepared to run perfectly out of the box with SystemView. If you are working on non commercial projects you can use the embOS trial version. And if you are working on commercial products please contact us and we'll find a quick and inexpensive solution for you. Best regards, Til
-
Hi Martin, we are using signed time values and calculate timeouts with subtractions. This make it's easy to handle overflows which means all timing functions just works (even if there is an overflow). Quote: “I always need to check for timer overflows myself when working with time differences?! ” No, you don't have to check anything by yourself. You can just use embOS API like e.g. OS_Delay() and it will always works. Best regards, Til
-
Hi Scott, basically that should be doable since we already disable the interrupts while modifying the task event bit mask. You will need to define OS_TASK_EVENT as a 64 bit unsigned in e.g. your project settings while working with the embOS sources. But please contact us directly by email. That makes it easier to discuss the details. Best regards, Til
-
HI Benjamin, the embOS Simulation simulates 100% the embOS API and can be adapted to your requirements. It is possible to use the complete Windows API inside the simulation, thus you can easily communicate with other applications or hardware. I am not sure if I understood the last question correctly but I guess it's about using the same application in simulation and target hardware? Please be aware only the embOS API is simulated but not e.g. the STM32 peripherals. Anyhow we can help you to setu…