Search Results

Hi, yes, you could calculate the stack size because the stack size depends on how much subroutines are called and how much local variables do you have. You can also find a minimum stack size value in the CPU/compiler specific embOS manual. But the easiest way is to use a task stack which is large enough and check then with embOSView how much stack was maximum used. Regards, Til

Heap managment with GCC can be different, it depends on where stack and heap are located in your RAM and how the sbrk() function is implemented. So it's less related to OS or not but moreover to the actual implementation. Please let me know if I can be of any further help. Regards, Til

Hello Michael, do you work with the latest embOS trial versions from our website? embOS CortexM Atollic V3.88 embOS CortexM GNU V3.86i Which start project do you use for Cortex M3? The easiest way to evaluate embOS Cortex M for GCC compiler is to use embOS Cortex M emIDE. emIDE is a free IDE which can be downloaded from emide.org. embOS Cortex M emIDE can be downloaded from our website. Regards, Til

Hello Michael, Regarding first issue: embOS uses the PendSV Exception for the task switch. It comes with the PendSV Handler in the library. Thus you must not include your own PendSV Handler in your project. I don't know how you built your project, you should work with our start project, they work out of the box. Regarding second issue: Please be aware that the GNU heap managment for malloc() requires a lot of heap space defined in the linker file. Without having your project it's hard to say wha…

Hello Harsh, the stack size is the maximum used stack size not the currently used! The actual stack size depends on how much sub functions are called because the return address is stored on the task stack. It also depends on how much local variables you use, they are also stored on the task stack. Best regards, Til

Hello Pavel, embOSView with RX runs via serial communication. Since the RPBR62N has no uart connector you cannot use it. But you can use printf() with HEW. You need some additional files which are part of the embOS shipment but also be generated by the HEW project generator. These files enables the printf() functionality, you will see the output in the HEW terminal window. The files are named lowsrc.c, lowsrc.h and lowlvl_DebugConsole.src. Do you use Renesas compiler or KPIT GCC compiler? I will…

Hello, we don't have the CMSIS RTOS Layer yet but we could create it on request, of course. Best regards, Til

Hello Jan, the return value is a signed integer value. We calculate all internal timings with signed values, so it also works over 0x7FFFFFFF. Even the step from 0xFFFFFFFF to 0x00 is no problem and all timings are handled correctly. Quote: “Is there a possibility to set the time of the OS?” There is no API function for setting the system tick. Best regards, Til

Hello, the embOS software timer timing is based on the system tick. The system tick is generated by a hardware timer which increments the system tick per default every 1 msec (you can also work with other system ticks, e.g. 100 usec or 10 msec). This means that the following could happen: You call StartTimer() 50 usec before the next hardware timer interrupt occurs. In this case the time between StartTimer() and the callback function is not 1 msec but around 50 usec. Please have a look in the ge…

Hello, unfortunately that's not possible but you could use the filter to decrease the amount of trace entries. Best regards, Til

Hello Vincent, Quote: “I think that the function OS_Sendstring(void) in bold in the sample of program is not correctly defined. By that, when OS_UART=-1, the function OS_SendString and OS_Send1 are called in my application and I have case where OS_TxActive is not reset to zero and block the application in an infinite loop” If you have set OS_UART=-1 OS_SendString() is an empty function which wil never set OS_TxActive = 1. Please don't post any of our generic sources here. I deleted that part fro…

Helllo Vincent, OS_Send1() is called from OS_SendString(). Do you have any call to OS_SendString() in your application? We are not aware of any bugs with OS_SendString()/OS_Send1(). Regards, Til

Hello Mike, you can do the port on your own very easily but we can do it also as a paid service. The effort is 2-5 days (depends on your application). We also think that GCC is a great alternative to IAR because: - You can get the GCC compiler (as also workbench like Eclipse) at no charge - You are not depend on IAR regarding license issues (e.g. you have a new colleague who also wants to work with the compiler/toolchain) - You can use GCC on any PC without the need to transfer a license - Since…

Hello Vincent, sorry for late reply. Yes, this will work, you could check in an interrupt routine if interrupts are reenabled (I flag in program status word). Your interrupt routine should look like: C Source Code (6 lines) Regards, Til

Hi Vincent, which interrupt priorities do you use for Uart RX and TX interrupt? Please be aware that the current running interrupt can only be nested by other interrupts with a higher interrupt priority. Best regards, Til

Hello, I just checked it with ST-Link/V2 and it works without any problems. I guess you did not enable "Use flash loader(s)" in IAR settings -> Debugger -> Download. This option is not necessary for J-Link since J-Link uses it's own internal flash loaders but for ST-Link this option must be enabled. Could you please check this and let me know if this solves your problem? Best regards, Til

Hello, yes, that could be an issue, please let me check it and contact you directly by email. Best regards, Til

Hello Shopitham, No, embOS is not POSIX compliant. Regards, Til

Hello, with which embOS ARM Keil MDK version are you working? Could you please ensure that the define OS_VIEW_USE_UART in RTOSInit.c is set to 1? Otherwise J-Link DCC communication is used instead of Uart communication Could you also please ensure that you use a debug configuration? If not embOSView communication is disabled. Regards, Til

Hello Simon, the common way is to keep your interrupt routine as short as possible and to do the work in a task. You could revceive in your Uart interrupt rouine one byte and put it in a mailbox. A uart receive task could wait for new data from this mailbox. If there is no new data the task is suspended and comsumes no CPU load. Binary semaphore makes no sense here. You could also use a queue instead of the mailbox, but the mailbox is faster. It depends on your application if you want send the c…