VHDL 360, Post Place and Route Simulation

• Compile Simulation Libraries
• Post PAR Simulation

Post Place and Route Simulion

View more presentations from amraldo

Running uCOS-III under Microsoft Windows

uCOS-III the Real-Time Kernel

uCOS-III is Micrium's newest RTOS, designed for developers who need to save time on their current and next embedded sytem projects. In addition to the features inherent in μC/OS-II, μC/OS-III also manages an unlimited number of application tasks, and features an interrupt disable time of near zero. For more details, you can check its data sheet.

uCOS-III Win32 Simulation

Win32 port allows uCOS-III to run under Microsoft Windows. The port relies on Windows' process and thread management features; the uCOS-III Win32 port does not turn Windows into a real-time operating system! It was developed for didactic purposes to teach the basics of real-time operating systems with an insight to OS internal implementation. This approach was chosen, because it is much easier access PCs rather than to proprietary embedded systems. Powerful PC-based development tools like Microsoft Visual Studio are available free of charge as compared to costly embedded system cross-compilers and debuggers. Thus real-time system mechanisms can be studied with uCOS-III under Win32 providing a soft real-time-environment on PCs. If the basic functionality of the application is working correctly, the application can be easily ported to an embedded system later in the lab.

Figure 1 shows the relationship between the user application, uCOS-III the underlying Windows system.

Figure 1: Application / uCOS-III / Windows Vista Relationship

As a result of this hierarchy, µC/OS-III tasks are really Windows threads and their stacks are converted to Windows thread stacks. The system ticker is driven by the high resolution multi-media timer if WIN_MM_TICK is defined in os_cpu.h. Otherwise it is driven by sleep(), the system coarse timer. A more realistic real-time effect can be achieved by using the multi-media timer since it has finer granularity (1ms) than the system coarse timer.

Critical sections are implemented using the Win32 API.

Fortunately, the underlying architecture is transparent to the application programmer and all µC/OS-III application code can utilize various features using traditional documented µC/OS-III function calls.

Since µC/OS-III is an infinite loop by nature, it should be noted that the processor utilization under windows will remain close to 100% while µC/OS-III is running. This is normal operating behavior for infinite loop consol based programs under Windows.

uCOS-III Win32 Simulation with Windows
To run this test, you have to install Microsoft Visual C++ 2008 Express. You can get it here.

Once you open the project, it will look as shown in Figure 2.

Figure 2: MS Visual C++ 2008 Express Project Structure

The directories used are:

1. uC/CPU: generic and Win32 specific uC/CPU headers
2. uC/LIB: compiler independent uC/LIB library functions
   
3. BSP: header files for BSP
4. uCOS-III: version 3.01.2 of uCOS-III
5. App: example application

After building the project, once you run it you get the output shown in Figure 3.

Figure 3: uCOS-III for Windows

VHDL 360, Structural Description

• How to Create Your Generic DU?
• Generic Clause
• Exercise 1: N Input OR Gate
• Exercise 2: N Input AND Gate
• Structural Description
• Structural Modeling
• Component Instantiation
• Exercise 3: Use T-FF to Create a 2-Bit Counter
• Testbench
• Stimulus Generation
• Monitors
• Generate Statement
• Exercise 4: Create N-Bit Shift Register
• VHDL Configurations

Building Hierarchy

View more presentations from Mohamed Samy.

uCOS-III VS uCOS-II (API Changes)

Introduction
This is the fifth and the last post about the comparison between uCOS-II and uCOS-III. The whole five posts can serve as a guide for migrating from uCOS-II to uCOS-III.

In this post, I will try to summarize the API changes themselves. I wont go in the details of the APIs' arguments but I will try to hint the differences on a higher level. Changes in APIs were aiming at having more consistent code.

Changes in Critical Sections
Macros defined to control a critical section are redefined and moved to CPU.H.

General Changes in APIs

• Accept APIs are removed. They are now built in Pend APIs.
• Naming APIs are removed. Names are defined during Creation APIs.
• Posting APIs are combined into a single API where all options are built in a single Post API.
• The type OS_EVENT is no longer used. Instead new types were added.
  
• Query APIS are removed because they are rarely used.
• All object handles should be created by the application prior to its creation. Number of objects are no more defined during compilation.

Changes in Event Flags APIs
Changed APIs are OSFlagCreate, OSFlagDel, OSFlagPend, OSFlagPendGetFlagsRdy, and OSFlagPost.

Changes in Message Mailboxes APIs
No direct implementation of message mailboxes APIs. You can view a mailbox as a message queue with a single message. Thus, message queues APIs are used to emulate message mailboxes APIs.

Changes in Memory Management APIs
Changed APIs are OSMemCreate, OSMemGet, and OSMemPut.

Changes in Mutual Exclusion Semaphores APIs
Changed APIs are OSMutexCreate, OSMutexDel, OSMutexPend, and OSFlagPost. OSMutexPendAbort is added in uCOS-III.

Changes in Message Queues APIs
Changed APIs are OSQCreate, OSQDel, OSQPend, OSQPost, and OSQPendAbort.

Changes in Semaphores APIs
Changed APIs are OSSemCreate, OSSemDel, OSSemPend, OSSemPost, OSSemPendAbort, and OSSemSet.

Changes in Task Management APIs
Changed APIs are OSTaskChangePrio, OSTaskCreate, OSTaskDel, OSTaskResume, OSTaskRegGet, OSTaskRegSet, OSTaskSuspend, and OSTaskStkChk.
Removed APIs, others than mentioned above in the general changes section, are OSTaskDelReq, and OSTaskCreateExt.
Added APIs are OSTaskQFlush, OSTaskQPend, OSTaskQPendAbort, OSTaskQPost, OSTaskSemPend, OSTaskSemPendAbort, OSTaskSemPost, OSTaskSemSet, and OSTaskTimeQuantaSet.

Changes in Time Management APIs
All APIs are changed.

Changes in Timer Management APIs
All APIs are changed except for OSTmrSignal is removed.

Changes in Miscellaneous APIs
Changed APIs are OSInit, OSSchedLock, OSSchedUnlock, and OSVersion.
Changed and renamed APIs are OSPendMulti, and OSStatTaskCPUUsageInit.
Added APIs are OSSchedRoundRobinCfg, and OSSchedRoundRobinYield.

Changes in Hook and Port APIs
Changed APIs are OSTaskStkInit, OSTaskCreateHook, and OSTaskDelHook.
Changed and/or renamed APIs are OSInitHook, OSIdleTaskHook, and OSStatTaskHook.
Added APIs are OSGetTS, and OSTaskReturnHook.
Deleted APIs are OSInitHookEnd, and OSTCBInitHook.

uCOS-III VS uCOS-II (Variable Name Changes)

Introduction
In the fourth post, I will hint out the changes in variables' names in uCOS-III compared to uCOS-II. The changes are made to be more consistent with the coding convention.

These changes can be noticed by comparing OS.H in uCOS-III compared to uCOS-II.H in uCOS-II.

Changes

• OSCtxSwCtr in uCOS-II is renamed to OSTaskCtxSwCtr in uCOS-III and containing the same information.
• OSCPUUsage in uCOS-II is renamed to OSStatTaskCPUUsage and containing the same information.
• OSIdleCtr and OSIdleCtrMax in uCOS-II are renamed to OSIdleTaskCtr and OSIdleTaskCtrMax respectively in uCOS-III and containing the same information.
• OSIntNesting and OSSchedNesting in uCOS-II is renamed to OSIntNestingCtr and OSSchedLockNestingCtr in uCOS-III and containing the same information.
• OSTaskCtr in uCOS-II is renamed to OSTaskQty in uCOS-III and containing the same information.
• OSTCBCur and OSTCBHighRdy in uCOS-II are renamed to OSTCBCurPtr and OSTCBHighRdyPtr respectively in uCOS-III and containing the same information.
• OSTime and OSTmrTime in uCOS-II are renamed to OSTickCtr and OSTmrTicckCtr respectively in uCOS-III and containing the same information.
  

An Interview with Jean J. Labrosse

Introduction

Few days ago, we were honored by the visit of Jean J. Labrosse to our blog. I grasped the chance and agreed with him to have an interview with him. The interview was focused on various aspects. I tried to get the best out of it for all embedders and Micrium fans.

About Jean J. Labrosse

He founded Micrium in 1999. He is a regular speaker at the Embedded Systems Conference in Boston and Silicon Valley, and other industry conferences. He is the author of many books on embedded design. The most two famous books are MicroC/OS-II, The Real-Time Kernel and Embedded Systems Building Blocks, Complete and Ready-to-Use Modules in C. He holds a BSEE and MSEE from the university of Sherbrooke, Quebec, Canada.

Micrium Story

Q: How did Micrium Start?
I had written the uC/OS book (1992), the Embedded Systems Building Blocks book (1996) and then revised uC/OS after getting feedback from hundreds of people around the world. This thus became uC/OS-II (1998). I revised the uC/OS-II book in 2002 which is now the current version of that book. Of course, the code has evolved since then but the book has remained the same.

Since about 1994, I was receiving a lot of inquiries about pricing for licensing uC/OS and uC/OS-II for use in embedded systems. This made me decide to start a company (August 1999) to sell licenses and called it Micrium. By the way, Micrium comes from ‘Micro’ and ‘ium’ (at the time, I liked the sound of ‘ium’ as in Pentium). I wanted to have a company name that didn’t mean anything specific so that I would not be tied to the ‘uC/OS’ brand since I thought I would expand the product offering to a TCP/IP stack and other modules (which we now have). It turns out that ‘ium’ means ‘the universe of’ just like Planetarium means the universe of planets, aquarium means the universe of fishes so, Micrium means the ‘Universe of Micros’. So, I started Micrium to better support the products that I would offer through Micrium. There are currently close to 30 people working for Micrium and we plan to hire more people in 2011 and beyond.

Micrium Markets

Q: What industries do you see that Micrium products can play a role in as a backbone software solution platform?
This is difficult to answer because we are in just about every kind of products you can imagine. However, we are quite popular in medical products, avionics, industrial controls, consumer electronics, etc.

Micrium Business Models

Q: Why the business model followed for uCOS-II was not followed for the rest of Mcirium products?
Simply because it’s more difficult to ensure that companies developing products with our software would not always license the software for use. There are many countries that unfortunately don’t believe in paying the licensing fees we ask for and instead prefer stealing the software. If we were to provide the source code for all our products how can we ensure that companies and Engineers would remain honest and properly license our software? I, for one would ‘love’ to be able to expose all our software as we did with uC/OS-II but the practical reality is unfortunately different.

Micrium Role in facing the Embedded Designers Challenges

Q: What are the challenges embedded developers face and how Micrium is aiding its customers to face them?
One of the biggest challenges for embedded engineers is to overcome the tendency to go for free stuff! The internet is nice in that you can find all kinds of information from people willing to provide some of their knowledge for free. I am one of those individuals who has provide insights into how real-time kernels work and I’m glad to have contributed to the Engineering community. However, I quickly realized that it’s a lot of work to ensure that the software is 100% bug free and clean. I started Micrium to add additional products and improve on the quality of those products. Of course, as the company grew from just myself so did the expenses (office, computers, software, Engineer, sales, etc. etc.) and thus it’s difficult to compete against free stuff because Micrium’s software cost a lot to develop.

Another challenge is managing complexity of ever growing embedded applications. As clean and as documented as our software is, it’s still complex to put everything together because of the numerous combinations of CPUs, compilers, modules and evaluation boards we support. At Micrium, we work hard to make complicated things simpler to use. Most customers deal with a few different CPUs for years. We work with hundreds of CPUs on a regular basis. We try to provide ‘generic’ solutions so that customers can concentrate on the actual product they are developing.

Micrium Coping with Future Trends in Embedded Market

Q: What are the trends Micrium forsee in embedded markets and coping with?
There are a lot of trends in the industry these days and it’s easy to get sucked into most of them. There used to be Fuzzy Logic (lasted only a couple of years), Linux was and still is a big buzz, Multicore, Hypervisors, etc.

Interestingly enough, it’s difficult for some Engineers and companies to adopt an RTOS or even a simple kernel running on a single processor. Life gets a lot more complicated when you get into multicore and hypervisors. In other words, if you are not convinced about using a kernel, how can you possibly make the switch to adopting processors with multiple cores? Also, there are a LOT of embedded applications that are still candidates for running kernels and other middleware a single core. This is especially true since many MCUs now have plenty of Flash and are getting there with RAM to use an RTOS. BTW, by RTOS I mean the kernel and other modules such as TCP/IP, USB, File System, GUI, etc.

So, to answer your question, I think anything multicore is here to stay. We are starting to see multicore MCUs (Cortex-M0 and Cortex-M4 by NXP). The NXP chip is a good example of the use of multicore on an MCU. Run on the Cortex-M0 to conserve power, enable the Cortex-M4 when you need additional performance. The biggest challenge with multicore is developing applications that makes use of these cores and especially finding efficient ways to debug them. It’s already very challenging to debug a single core application, the problem gets multiplied when you deal with multicores.

Micrium vs Others

Q: What specializes Micrium compared to its competitors?
We have a lot of differentiators. The quality of our source code, the documentation (books), the numerous classes we do at trade shows, the broad reach of chips we support, the creation of unique products like uC/Probe, the reasonable prices for high quality software, the FAA/FDA certification of some of our products, the great reputation we have in the industry and more.