Forum Replies Created
The “SAFETY CRITICAL USE” section that flags certain configuration parameters with #error directives is a result of feedback from Validated Software, a Micrium partner that offers certification deliverables (targeting DO-178C and other safety-critical standards) for the uC/OS-II kernel. The parameters contained in this section simply reflect the build that Validated Software uses to generate deliverables. Validated, for example, does not enable the statistics task (OS_TASK_STAT_EN) when building the kernel for a certified system. This does not mean that alternate definitions for “SAFETY CRITICAL USE” parameters are not allowed in a safety-critical system, only that compatibility with deliverables from Validated requires use of the provided definitions. For more information on the logic behind the individual parameter definitions stipulated by “SAFETY CRITICAL USE,” the best option would be to consult with the team at Validated Software: http://www.validatedsoftware.com.
Micrium does not currently have a project configured to run out of DDR memory on that board. However, it is typically the case that migrating a project from internal RAM to an external device requires not just linker command file changes, but the addition of initialization code (to establish, for example, the memory device’s timing parameters) as well. Did you add initialization code for your DDR memory to your new project?
The latest µC/OS-III port files, which can be found in a number of example projects on the Micrium Download Center, should build without any errors or warnings in Embedded Workbench for ARM v8.1x. A dialog, indicating that the project is “in an old format” will appear if an attempt is made to open any of these examples in the 8.1x IDE, but it should be possible in that case to automatically update the project by clicking the Yes button.
Micrium’s engineers have used the v8.1x IDE extensively with µC/OS-III and have yet to encounter any major issues. Example projects prepared by the engineers should begin appearing on the Web site shortly.
- This reply was modified 2 years, 3 months ago by Matt Gordon.
What version of µC/Probe are you using? v4.1 of the tool (which is currently available for download) allows access to individual struct members. When a struct is selected on the left side of the Symbol Browser, its fields should appear in the Struct Configuration pane on the right side.
Micrium currently offers two highly efficient and reliable real-time kernels, µC/OS-II and µC/OS-III, both of which have impressive track records. µC/OS-II was released in 1998, and, in part because of the numerous certifications it has achieved as part of aerospace, medical, and industrial controls products, it has become a favorite of developers in safety-critical fields. Building on the success of µC/OS-II, Micrium released µC/OS-III in 2009. The newer kernel offers many of the time-tested services available from its predecessor, along with a number of new features, such as built-in performance measurement facilities, dynamic tick support, and mechanisms for stack overflow avoidance. Additional information on both kernels can be found here.
Next week, a third kernel, µC/OS 5, will be added to the mix, with the official release of the Micrium OS. The OS—a title that encompasses a number of software modules, including the new kernel—is being made available with an innovative tool named Platform Builder that automates the creation of projects incorporating Micrium’s software. Additional information on the upcoming OS release is available here.
- This reply was modified 2 years, 5 months ago by Matt Gordon.
Unfortunately, I don’t know of anyone within Micrium who’s tried to run µC/OS-II and MicroPython. Certainly, there are Micrium users who have experience writing µC/OS-II-based applications in languages other than C—I often work with customers whose applications are written entirely in C++, and Micrium’s partner MicroEJ enables Java applications to run on the kernel. I wouldn’t be surprised if there are developers who have run MicroPython with Micrium kernels, but I couldn’t say for certain whether or not that combination is viable.
- This reply was modified 2 years, 5 months ago by Matt Gordon.
Projects for a number of Eclipse-based IDEs, including the Atollic tools for ARM processors, can be found in Micrium’s Download Center. The compiler used by Atollic is gcc, so the files contained in the projects for that IDE should be suitable for any other versions of Eclipse that are likewise gcc-based.
Micrium does not currently have official implementations of Kermit, XMODEM, or YMODEM. However, there is support for file transfer—by TFTP, for example— in Micrium’s software.
There is no automatic mechanism for freeing the TCB involved in a task delete call. The kernel gives application code the responsibility of allocating a TCB prior to each create call, and it similarly shifts responsibility for freeing TCBs to the application in systems that utilize the task delete function. Of course, the easiest way to ensure that task deletion and the associated TCB de-allocation are synchronized is to perform both in the same task, with de-allocation immediately following the delete. When it’s not possible for the delete and de-allocate code to share a task, it can be helpful to use a semaphore or event flag to signal the task handling the de-allocation upon completion of the delete operation.
Although Micrium doesn’t have any examples for hardware platforms based on the OMAP 3 family, the Download Center’s EVM-AM3517 project incorporates the Cortex-A8 port files that would be needed to run the µC/OS-II kernel on an OMAP 3 board. A kernel-based example project for such a board could be put together by combining the kernel’s code (including both the previously mentioned port and the hardware-independent kernel code found in the AM3517 example) with a simple BSP. Since µC/OS-II’s only peripheral requirement is for a periodic interrupt source, a BSP for a project incorporating the kernel often comprises just a handful of code, most of which can be taken from non-kernel-based examples.
The BSP code required for µC/OS-II generally includes a few routines to set up interrupt hardware as well as startup code to initialize clocks and other essential hardware components before the application software begins running. Although a bootloader for µC/OS-II could have similar scope and capabilities to U-Boot, it’s possible to get by with much simpler boot code. In fact, many existing µC/OS-II and µC/OS-III examples utilize startup routines provided by the semiconductor manufacturers for bare-metal projects.
At the moment, there are no official Micrium examples targeting AM335x devices. However, the support team is always at work on new projects, and TI’s Sitara family is one possible target of the team’s future work.
App_SerPrintf() is a function added to many of Micrium’s example projects in order to allow application code to output helpful messages to users. As this function is considered to be example code, and not core Micrium software, it is typically not subject to the same level of scrutiny and testing as, say, a µC/OS-III API function. In most environments, a relatively simple way for Micrium’s developers to implement App_SerPrintf() is with the standard library function printf().
Of course, the fact that App_SerPrintf() lies outside of Micrium’s core modules does not mean that any thread-safety issues the function might impose can be completely ignored, so the question of whether or not printf() is safe for multi-task systems is still an important one, and the short answer to this question is “no.” Generally speaking, application developers cannot assume that the printf() implementation provided with their development environment will operate without problems in the presence of multi-tasking. However, this rule does not hold for all printf() implementations and all multi-tasking systems.
For developers whose multi-task application code is based on one of Micrium’s kernels—µC/OS-II and µC/OS-III—there are actually several safe options for printf(). That’s because Micrium has worked with tool-chain providers, including IAR, to develop interface code that helps library functions safely manage resources in a multi-task environment. With this code included in a Micrium-based project, an application can invoke printf() (or any other standard library routine) without the possibility for data corruption that otherwise accompanies library calls. Further details on the measures that must be taken to make library calls safe for multi-task environments can be found in Micrium’s online documentation.
Micrium has already developed ports for the Cortex-M0 core on which the Cypress PSoC 4 M-Series devices are based. (In fact, Micrium has supported the Cortex-M processor family since it was first announced.) Example projects targeting the CY8CKIT-044 and developed using PSoC Creator are available from Micrium’s Download Center.
What version of Windows are you using? Also, would it be possible for you to provide a screenshot of the charts?
Usage of both stream and datagram sockets within a single application shouldn’t cause any problems for the stack. Would it be possible for you to post the code that is producing the NET_SOCK_ERR_CONN_SIGNAL_TIMEOUT error?