Search Results

Dear Vakaras, I'm glad to announce that the requested functionality will be included with upcoming versions of embOS. That is, V5.06 and later will include a OS_DEBUG_RemoveObjName() function, which may then be used in combination with e.g. OS_free(MailboxName). Best regards, Martin

Dear ptiguitardenver, Thanks for your inquiry. With embOS, users may choose between two distinct approaches: mailboxes and queues. While mailboxes work on fixed size messages only, a queue with embOS does in fact accept messages of variable size and will handle those dynamically. That, however, does not mean one single message may wrap around the ring buffer: Instead, if no sufficient space for the particular message is available at the end of the buffer, embOS will try to store the entire messa…

Hello Christian, Thank you for your inquiry. We do in fact provide appropriate layers for both the CMSIS-RTOS v1.0.2 and CMSIS-RTOS v2.1.0 API, but also, as you already noticed, do not recommend to use them in a product for several reasons (limited number of features, decreased performance, etc). If their usage in a product is mandatory, however, as it seems in your case, there is no restriction on mixing the CMSIS-RTOS API with native embOS API. Therefore, it's perfectly possible to use CMSIS-R…

Dear Vakaras, Thank you for your inquiry. Calling free() on MailboxName is not possible at this particular time. It may, however, be reassigned for any other object by calling OS_DEBUG_SetObjName() on MailboxName again. Please let me know if I can be of any further help. Best regards, Martin

Hi PTepe, Thanks for your feedback, we'll consider this case solved then. Quote from PTepe: “In my EmbOS version I don't have OS_TIME_Getus64() but I do the substraction and now I'm also sure what the return range of OS_GetTime32() is. ” This function was called OS_GetTime_us64() with previous versions of embOS. Since V5.00, it's called OS_TIME_Getus64(). Best regards, Martin

Dear shal, It seems the hardfault was caused by an unaligned memory access. Does your application use the STM32F7's external SDRAM? If so, the hardfault is probably related to the hardware's memory specifications. This is for the reason that the STM32F7's SDRAM is mapped to 0xC0000000 - 0xC03FFFFF. That area, however, is specified as device memory type according to the ARMv7-M architecture. This means that all accesses to this area must be naturally aligned, whereas any unaligned access will cau…

Hi Lior, Thanks for your inquiry. However, this is not an issue, but instead is working as intended. Please refer to the embOS manual on OS_Delay(): Quote: “The actual delay (in basic time intervals) will be in the following range: t - 1 ≤ delay ≤ t , depending on when the interrupt for the scheduler occurs.” To elaborate on this, please imagine the following, examplary scenario: - The SysTick is configured to occur at every 1000 timer cycles. - At the moment OS_Delay(1) is called by the applica…

Hi Guillermo, The embOS STM32Cube expansion is not natively managed by STM32CubeMX and thus cannot be installed as a new library. Instead, it's intended for stand-alone usage. Hence, you may unzip the package to your STM32Cube installation directory (or any other destination of your choice), start with the contained projects, and also modify, expand and re-generate the projects. Please let me know if I can be of any further help. Best regards, Martin

Hi Vincent, Thanks for getting back at this. For an easier communication, I will contact you by email in a few minutes. Best regards, Martin

Hi Allan, Thank you for your inquiry. I'm not quite familiar with openVG and thus cannot give specific advise on that. Generally speaking, however, there isn't many differences between a super-loop application and an embOS application with 1 task only. One of these differences is the hardware initialization performed by embOS, which configures a hardware timer to periodically generate an interrupt as a time basis for the OS, and may furthermore include modifications to the clock and PLL configur…

Hi Vincent, As said above, the limit is imposed by embOS. There's no limit on the embOSView side of communications. We have, however, decided to lift this limit in upcoming versions of embOS: While the upcoming release V4.30, unfortunately, has already been scheduled and thus will not include any changes to this, we will gladly introduce the respective changes with the subsequent embOS release V4.32. Of course, we will notify you once that version becomes available. Best regards, Martin

Hi Owain, I had contacted you via email while you were providing this additional information. Hence, with your approval, I'd like to suggest to continue this conversation via email. Still, to answer to your recent remarks: Quote from Owain: “ But it seems to be connecting to some kind of simulated target. "embOS start project (embOS) on ST32F207ZG"” This information is included in one of the source files contained with one of our start projects. Particularly, this is contained in the source file…

Dear Owain, Thanks for your inquiry. The "Systemview module not configured" message usually is issued when SystemView was not initialized on the target side, e.g. through a call to SEGGER_SYSVIEW_Conf(). With embOS V4.261 for Cortex-M and IAR, a call to SEGGER_SYSVIEW_Conf() is included with OS_InitHW() inside the source file RTOSInit.c. Hence, I'd like to ask whether you had updated your RTOSInit.c as well when updating to the most recent embOS version? In case that call was already included wi…

Dear majk, Thanks for your inquiry. It's correct that IAR has performed changes to the runtime model with more recent versions of the IAR workbench for V850, and that we have not yet updated our embOS port to reflect those changes. However, we can of course perform an according update to our software within short time. Could you please contact us directly via Email to discuss further details? Best regards, Martin

Hi Vincent, Thank you for your inquiry. This limit is currently imposed by embOS, for an appropiately sized buffer is required on the target side. For a default that fits most cases, 50 tasks were then deemed appropriate in order to keep memory consumption to a minimum. I'm sorry this proves to be insufficient to you now. We'll consider changing this for upcoming releases of our software. Best regards, SEGGER Support embOS Martin PS: If you're a registered embOS customer, please also consider co…

Quote from rutvij trivedi: “Its probably my 7th post here and i don't understand why any of them haven't been answered by segger peoples.” Dear rutvij trivedi, I'm sorry you did not receive an answer to your questions. Please be aware, however, that this forum is not monitored by SEGGER technical support personnel as per its terms of use. Instead, its primary purpose is to allow for communication between users. That is, while SEGGER technical support might occasionally participate in forum discu…

Dear Christian, Thanks for your inquiry. embOS does offer several means to solve this situation, one of which is task events. Using these, task1 were to suspend itself using "OS_WaitEvent(BITMASK)", and could subsequently be resumed through calling "OS_SignalEvent(BITMASK, &task1_ControlBlock)" from within the ISR. More information may also be found inside the User & Reference Guide for embOS, Chapter 10 "Task events". Please let me know if I can be of any further help. Best regards, SEGGER - Su…

HI hibiscusblau, It seems the assembler confuses "--cpreproc" (2 hyphens) with "-c" (1 hyphen). Can you please check the number of hyphens on your command line? Best regards, Martin Edit: I just noticed I had the second hyphen missing in my post as well, probably causing this issue in the first place. I have subsequently corrected my post. Please kindly excuse any inconvenience caused!

Quote from hibiscusblau: “If I try to put you code: generic HardFault handler (https://www.segger.com/downloads/appnote…aultHandler.zip) is generating some errors. ” Dear hibiscusblau, Since you are using Keil, I assume the observed errors refer to the preprocessor directives contained in HardFaultHandler.S. This is due to the fact that by default Keil does not preprocess assembly files. To enable preprocessing of assembly files, please add --cpreproc to your assembler options. Does this solve t…

Dear Josema, Thank you for your inquiry. The observed issue has already been addressed with the most recent releases of the embOS plug-ins, e.g. plug-in version 7.10.2.1 for use with V7.1 to V7.4 of the IAR Embedded Workbench for ARM, and plug-in version 7.50.2.1 for use with V7.5 and later. Our most recent plug-in releases are publicly available for download at segger.com, but will of course be included in upcoming releases of embOS for Cortex-M and IAR as well. Please let me know if I can be o…