In a great move for all embedded lovers, Jean J. Labrosse has announced a day ago that uCOS-III source code is now available for as well as its 6 books in PDF format.
Furthermore, colleges and universities can use it for free.
You can check Jean J. Labrosse announcing it here.
The source code can be downloaded from here.
The books are available from here.
The big question is "Why after a 2 years of release its source code is made available?"
If you have an answer, please share.
Thursday, August 11, 2011
Monday, June 13, 2011
SECC: Embedded SW Training July 2011
SECC is organizing the following courses in the:
From 3 to 21 July 2011
Schedule , Fees & Instructors:
Registration:
Please fill in & submit your registration form at:
before end of Sunday June 19, 2011
Outline :
Kindly find attached the courses outline
About Training :
§ Training day starts from 9:00 AM to 4:00 PM
§ The courses will be held at the Smart Village – Building B121 - Km 28 Cairo-Alex desert Road.
About fees:
After you receive SECC confirmation email:
- The fees will be paid at: Smart Village - SECC premises - B121 – ITIDA Building
- Attention Mr. Ahmed Anany – room 1017, tel.: 35345250, mobile:0101709913
Cancellation Policy |
· Only 5 working days before the beginning of the course, the applicant can be totally refunded. · Other than that there is no refund |
For any further information please don't hesitate to contact us
Ø Mr. Mohammed Bhady : 35345226
Ø Mr. Mahmoud Mansour : 35345122
An Interview with Richard Barry
Introduction
 |
| Fig1: FreeRTOS Logo |
About Richard Barry
Richard Barry is the founder of FreeRTOS organization, director of Real Time Engineers Ltd., and head of innovation in WITTENSTEIN. Richard Barry graduated with 1st Class Honorsin Computing for Real Time Systems. He's been directly involved in the start up of several companies, primarily working in the industrial automation and aerospace and simulation markets.  |
| Fig 2: Richard Barry in his lab |
Q: FreeRTOS, how did the idea start? How did the idea of the company start?
FreeRTOS originated from a consulting project I did a long time ago. I was asked to research RTOS solutions, with the aim of recommending a replacement for an RTOS that was used in an existing product. It had been decided that the existing RTOS should be changed because of the royalty based licensing model it used.
During the research, I concluded that the application only required a simple, small, solution, and the existing commercial solutions did not represent good value. So, I then looked at open source solutions as an alternative, but found these cumbersome to configure, build, and understand - especially on a Windows (as opposed to Linux) host. My customer and I were both Windows-centric.
I ended up recommending one of the commercial options as ‘best fit’ rather than a ‘perfect fit’ solution. The project showed me there was a gap in the market – if, indeed, you can call giving software away for free a market. I thought there must be a lot of engineers going through the same process I had gone through, and coming to the same conclusion, and that these engineers would benefit from a Windows friendly, robust, easy to use, documented, supported, open source solution. I therefore created FreeRTOS with the intention of it being just that, and also, I must admit, because I'm a geek at heart and it was fun.
I had no intention of taking it further than writing it, and publishing it on the web. When I set it wild on the internet though, it seemed I had been right - there was demand for it - and some eight years later this has been proven by the results of the latest EETimes Embedded Market Survey.
Yes, I saw a gap in the market, and successfully filled it, but there was also some luck, as around that time the low cost microcontroller market was evolving such that the time was just right for FreeRTOS.
FreeRTOS is extremely liberally licensed, you can use it in commercial applications without risking your own propitiatory IP (provided that IP is outside of the kernel itself). All the same, I was often asked for commercial licenses, training and commercial support contracts. I partnered with WITTENSTEIN high integrity systems to meet the commercial and legal need which I could not address myself. High Integrity Systems are a safety company, and used their knowledge, skill set, and investment to get SafeRTOS certified. SafeRTOS was originally derived from FreeRTOS, so it was a mutually beneficial arrangement.
WITTENSTEIN also add options for FreeRTOS users by providing the code fully integrated with other embedded software components such as TCP/IP stacks, file systems, USB stacks, etc. This is done under the OpenRTOS brand. FreeRTOS also provides integrated solutions, with free components.
FreeRTOS is intended to provide a resource for engineers, and the business model requires very modest commercial support, in part due to the high level of participation by the engineering community. It is not our goal to become, or indeed would it be possible to become, the next Wind River or Green Hills.
During the research, I concluded that the application only required a simple, small, solution, and the existing commercial solutions did not represent good value. So, I then looked at open source solutions as an alternative, but found these cumbersome to configure, build, and understand - especially on a Windows (as opposed to Linux) host. My customer and I were both Windows-centric.
I ended up recommending one of the commercial options as ‘best fit’ rather than a ‘perfect fit’ solution. The project showed me there was a gap in the market – if, indeed, you can call giving software away for free a market. I thought there must be a lot of engineers going through the same process I had gone through, and coming to the same conclusion, and that these engineers would benefit from a Windows friendly, robust, easy to use, documented, supported, open source solution. I therefore created FreeRTOS with the intention of it being just that, and also, I must admit, because I'm a geek at heart and it was fun.
I had no intention of taking it further than writing it, and publishing it on the web. When I set it wild on the internet though, it seemed I had been right - there was demand for it - and some eight years later this has been proven by the results of the latest EETimes Embedded Market Survey.
Yes, I saw a gap in the market, and successfully filled it, but there was also some luck, as around that time the low cost microcontroller market was evolving such that the time was just right for FreeRTOS.
FreeRTOS is extremely liberally licensed, you can use it in commercial applications without risking your own propitiatory IP (provided that IP is outside of the kernel itself). All the same, I was often asked for commercial licenses, training and commercial support contracts. I partnered with WITTENSTEIN high integrity systems to meet the commercial and legal need which I could not address myself. High Integrity Systems are a safety company, and used their knowledge, skill set, and investment to get SafeRTOS certified. SafeRTOS was originally derived from FreeRTOS, so it was a mutually beneficial arrangement.
WITTENSTEIN also add options for FreeRTOS users by providing the code fully integrated with other embedded software components such as TCP/IP stacks, file systems, USB stacks, etc. This is done under the OpenRTOS brand. FreeRTOS also provides integrated solutions, with free components.
FreeRTOS is intended to provide a resource for engineers, and the business model requires very modest commercial support, in part due to the high level of participation by the engineering community. It is not our goal to become, or indeed would it be possible to become, the next Wind River or Green Hills.
FreeRTOS Markets
Q: What industries do you see that FreeRTOS and its related products can play a role in as a backbone software solution platform?
It would be easier to list which industries it is not used in. FreeRTOS has had 150,000 downloads in the last two years. It is found everywhere. Even I am surprised about some of the places it turns up.
FreeRTOS Business Model
It would be easier to list which industries it is not used in. FreeRTOS has had 150,000 downloads in the last two years. It is found everywhere. Even I am surprised about some of the places it turns up.
FreeRTOS Business Model
Q: Why the business model followed for FreeRTOS was not followed for the related products?
FreeRTOS does not, yet, provide related products, unless you include the
kernel aware debugger plug-ins, but they are also provided for free download. I provide integration with other open source components though, but again, they too are available for free download.
FreeRTOS does not, yet, provide related products, unless you include the
kernel aware debugger plug-ins, but they are also provided for free download. I provide integration with other open source components though, but again, they too are available for free download.
FreeRTOS Role in facing the Embedded Designers Challenges
Q: What are the challenges embedded developers face and how is FreeRTOS and its related products are aiding their customers to face them?
There are lots of well documented ‘typical’ challenges faced by embedded
engineers. For example, reducing time to market. FreeRTOS addresses that particular challenge by providing “out of the box” examples for each of the 50 or so officially supported FreeRTOS ports. Another typically quoted challenge is cost reduction – well there the instant free download provided by FreeRTOS is an obvious benefit – you don’t even have to part with any personal information to get the code, just take it.
However, I think one of the primary challenges that FreeRTOS aids in addressing, is how to migrate a software design pattern from one that is appropriate for low cost, low resource, 8/16-bit microcontrollers, to a design pattern that is appropriate for one of the new generation of low cost, 32-bit architectures. The low cost 32-bit architectures come with a lot more RAM, Flash, and a greater number of peripherals. That in turn, inevitably, leads to larger, more complex, and more feature rich software requirements. FreeRTOS, along with the FreeRTOS tutorial books, provides an easy solution for engineers that are not familiar with the software challenges this poses. In fact, I would go as far as to say, FreeRTOS provides an easy solution even for engineers that are familiar with these challenges.
There are lots of well documented ‘typical’ challenges faced by embedded
engineers. For example, reducing time to market. FreeRTOS addresses that particular challenge by providing “out of the box” examples for each of the 50 or so officially supported FreeRTOS ports. Another typically quoted challenge is cost reduction – well there the instant free download provided by FreeRTOS is an obvious benefit – you don’t even have to part with any personal information to get the code, just take it.
However, I think one of the primary challenges that FreeRTOS aids in addressing, is how to migrate a software design pattern from one that is appropriate for low cost, low resource, 8/16-bit microcontrollers, to a design pattern that is appropriate for one of the new generation of low cost, 32-bit architectures. The low cost 32-bit architectures come with a lot more RAM, Flash, and a greater number of peripherals. That in turn, inevitably, leads to larger, more complex, and more feature rich software requirements. FreeRTOS, along with the FreeRTOS tutorial books, provides an easy solution for engineers that are not familiar with the software challenges this poses. In fact, I would go as far as to say, FreeRTOS provides an easy solution even for engineers that are familiar with these challenges.
FreeRTOS Coping with Future Trends in Embedded Market
Q: What are the trends you forsee in embedded systems and coping with?
Again there are a lot of well documented trends. Machine to machine communications, smart metering, hand held devices, near field communications, to name just a few. The trend I am most interested in,
though, and the one that is relevant to all the above and more, is the trend towards lower costs in 32-bit processing solutions, and lower costs in tools for 32-bit microcontrollers.
though, and the one that is relevant to all the above and more, is the trend towards lower costs in 32-bit processing solutions, and lower costs in tools for 32-bit microcontrollers.
FreeRTOS vs Others
Q: What specializes your products compared to others?
That is a difficult question. From a technical perspective, what is to differentiate one kernel solution from another – don’t they all do the same thing? Each will do better than others for some criteria, while simultaneously doing worse than others for other criteria. You have to choose the best for your particular application.
If I was to try and answer that question, I would probably have to talk about non technical attributes. For example:
That is a difficult question. From a technical perspective, what is to differentiate one kernel solution from another – don’t they all do the same thing? Each will do better than others for some criteria, while simultaneously doing worse than others for other criteria. You have to choose the best for your particular application.
If I was to try and answer that question, I would probably have to talk about non technical attributes. For example:
- Code quality, which can be quantified in a number of ways. I know of
several people who have done independent analysis of the code, in various ways, and have satisfied themselves of its robustness and quality.
- FreeRTOS is a truly cross platform defacto standard. It will not lock
you into any architecture, or any toolchain. It supports 27 architectures (that is, architectures, not devices) and 17 tool chains. Take your pick, mix and match, and don’t lose the time invested when you move onto your next project. Not only that, but whatever you do, it need not cost you anything. Even the time investment required can be lower than with commercial solutions.
- The FreeRTOS open source model is (somewhat) innovative in a way that
is beneficial to users. For example, FreeRTOS is “moderated open source”. This means that, when you download FreeRTOS, the code is truly free and open source to you. However, contributions back to FreeRTOS are made publicly available while simultaneous kept separate from the ‘official’ code. This allows the FreeRTOS project to strictly control the quality of the code, ensuring a robust product. It also provides assurance to end users that their open source choice has no
unintentional or unknown IP contamination.
- The business model allows users the freedom to access, use, evaluate,
distribute, etc. the code, completely free of charge. However, they have the security of knowing there is a third party infrastructure there
should they ever need commercial licensing or support contracts.
- FreeRTOS is professional grade and robust, yet still free. Users can have the confidence in knowing that SafeRTOS, which originated from FreeRTOS, has been independently certified by TUV SUD for use in safety
critical systems.
- I am told, and have not attempted to quantify, that the support provided with FreeRTOS is better and faster than that provided with many commercial products.
- FreeRTOS has a *massive* user base.
Final Word
Q: Any final word to embedded developers all over the globe?
I would recommend finally putting the old and repetitive “buy or build yourself” RTOS question away. There is a free, documented, widely ported, and supported option just a few mouse clicks away, so why would you do either?
I would recommend finally putting the old and repetitive “buy or build yourself” RTOS question away. There is a free, documented, widely ported, and supported option just a few mouse clicks away, so why would you do either?
Monday, May 9, 2011
Introduction to C Programming Course
- Introduction to C
- Variables and Datatypes
- Blocks and Compound Statements
- Control Flow
- Modular Programming
- Variable Scope
- I/O
- Pointers and Memory Addresses
- Arrays and Pointers Arithmetic
- Search and Sorting Algorithms
- User Defined Datatypes
- Data Structures
- Callbacks
- Hash Tables
- Using External Libraries
- Creating Libraries
- Standard Libraries
Introduction to C Programming
View more presentations from amraldo
Saturday, April 30, 2011
Introduction to Embedded Systems
- Introduction
- Embedded Hardware
- Embedded Software
- Embedded Development Tools
Introduction to embedded systems
View more presentations from amraldo
Friday, April 22, 2011
New Software Timers in FreeRTOS under MS Windows
SW Timers
Embedded applications need to schedule future events. This can be accomplished using timers and timers' services.
Timers are an integral part of any real-time system. A timer can be seen as an event scheduling according to a predefined time value in the future, exactly like setting an alarm clock.
Embedded systems that have time-sensitive activities use 2 types of timers; hard-timers and soft-timers. Hard timers are based on physical timers on the chip that directly interrupt the CPU. A hard-timer is a must in case of an application demanding high precision and predication. On the other hand soft-timers are scheduled through a software facility that enables soft-timer's maintenance, installation, and removal.
SW Timers in FreeRTOS
Starting from FreeRTOS V7.0.0, FreeRTOS added the soft-timers feature. FreeRTOS timers have 2 modes of operations; autorelaod and 1-shot modes. Whenever a timer timeouts, a callback function is executed. This service is implemented as a FreeRTOS kernel task and a FreeRTOS queue. This task is assigned a stack size and priority defined the macros configTIMER_TASK_STACK_DEPTH and configTIMER_TASK_PRIORITY respectively. The timers APIs are implemented through the queue. Whenever a task calls a timer API it send s a command to the timer task through the timers queue. This task continually gets the next expire time, either process the expired timer or blocks until a timer expires or it receives a command and processes it. Like any other FreeRTOS service, this service is highly configurable. In order to use it you have to:
- Define configUSE_TIMERS to 1
- Define configTIMER_TASK_PRIORITY and configTIMER_STACK_DEPTH
- Define configTIMER_QUEUE_LENGTH
- Add FreeRTOS/Source/timers.c to your application.
- Use the timers in your application
Demoing the SW Timers under MS Windows
Last year, I showed how to run the industrial PC port under MS Windows. Recently, FreeRTOS team made a windows simulator. Unlike the PC port that used Open Watcom and 80x86 assembly, it uses MS VC or MingW and Windows APIs.
The following steps shows how to test the SW timers with the FreeRTOS MS Windows simulator:
- Download MS VC++ 2010 Express edition from here.
- After Installing the compiler, download FreeRTOS from here.
- Open the project using MS VC and here you go.
Monday, April 18, 2011
Introduction to ARM Cortex M3 and STM32 - Part II
This is the second post after the first tutorial.
- STM32 System Architecture
- Peripherals
- Low Power Operation
- Safety Features
- The Flash Module
- Development Tools
Monday, March 21, 2011
My Cooperation with CooCox
About CooCox
CooCox is an embedded lovers’ family, who:
- Focus on providing free and open embedded development tools to ARM Cortex M3/M0 developers
- Dedicated to sharing free and open available examples and solutions with embedded developers
- Devoted to creating a contributing & sharing communication platform, from where developers can get any resources he wants while developing
CooCox Products
Coocox provides the following tools:
The CoIDE is is an IDE that integrates a web based IDE with a debugging tool. The CoOS is a RTOS thats tuned and suited well for the Cortex M3/M0 microcontrollers.The CoLinkEx is the successor of the CoLink. Unlike CoLink which was a a JTAG HW debugger only, CoLinkEx supports SW debugging as well. CoFlash is a stand alone Flash programming SW. CoAssistant is a register assistant that can be used to debug the core registers. COX is a definition of a group of interface functions to unify access to peripherals.
Gifts from CooCox
I was lucky that I got a contact with CooCox team. We had a friendly agreement to cooperate together with the goal of adding values to the CooCox community. CooCox has sent me the following:
- STM32F103RBT6 Evaluation Board x 1 pcs
- Nuvoton M051 Evaluation Board x 1 pcs
- Nuvoton NUC120 Tiny Board x 2pcs
- Nuvoton M051 Tiny Board x 3 pcs
- CoLinkEx LPC1114 Kit x 1 pcs
Friday, March 18, 2011
VHDL 360, FPGA Programming
- Creating Project
- Importing VHDL Files
- Assigning FPGA Pins
- Creating Programming File
- Configuring the Device
- Selecting the Programming File
- Programming the FPGA
Fpga programming
View more presentations from amraldo
Friday, February 25, 2011
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.
Figure 1: Application / uCOS-III / Windows Vista Relationship
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:
Figure 3: uCOS-III for Windows
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 RelationshipAs 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 StructureThe directories used are:
- uC/CPU: generic and Win32 specific uC/CPU headers
- uC/LIB: compiler independent uC/LIB library functions
- BSP: header files for BSP
- uCOS-III: version 3.01.2 of uCOS-III
- App: example application
Figure 3: uCOS-III for Windows
Friday, February 18, 2011
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.
Wednesday, February 16, 2011
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
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.
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.
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.
Thursday, February 10, 2011
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
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.
Friday, February 4, 2011
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.
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.
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.
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.
Monday, January 24, 2011
VHDL 360, Modeling Finite State Machines (FSMs)
- What is a FSM?
- State Machine
- Moore FSM
- Moore Implementation
- Mealy FSM
- Mealy Implementation
- FSM in VHDL
- Next State Logic
- Current State Logic
- Assigning Moore Outputs
- Assigning Mealy Outputs
- Moore vs. Mealy
- FSM Tips
- Example
- Exercise 1: Simple Control Unit
- State Machine Encoding
- Exercise 2: Traffic Light Controller
Modeling FSMs
View more presentations from Mohamed Samy.
Sunday, January 23, 2011
uCOS-III VS uCOS-II (Conventions)
Introduction
This is the third post out of five posts under the same topic. In the first post, I pointed out the difference in features. In the second post, I summed up the difference between the two kernels in terms of file names and contents. In this post, I will summarize changes in the conventions. They can be summarized into 3 categories.
Introduction of CPU.H
A notable change is the use of the CPU specific data types. In uCOS-II, data types were defined in OS_CPU.H. In uCOS-III, these definitions are defined in CPU.H. Every data type is prefixed with "CPU_".
Exceptions are OS_STK and OS_CPU_SR, they are renamed to CPU_STK and CPU_SR respectively.
In addition, in uCOS-II we had the OS_STK_GROWTH changed to CPU_CFG_STK_GRWOTH in uCOS-III and stored in CPU.H.
Introduction of "CFG" as Acronym
This is another convention added to define configuration options
Introduction of OS_CFG_APP.H
Some configuration options are configurable at the application level not at the kernel level as the case of uCOS-II. The application programmer only needs to define them during his application compilation rather than being defined in uCOS-II compilation which might not be accessible by the application programmer. These options plus new ones are defined in the OS_CFG_APP.H.
This file now contains configurations for maximum number of messages, ISR stack, idle tasks, ISR handler task, statistics task, ticks, and timers.
A notable change in these configurations that the word "TICKS_PER_SEC" is now replaced by "RATE_HZ". Frankly speaking, it became less confusing!
Changes in OS_CFG.H
The remaining configurations in OS_CFG.h are either renamed, moved, or removed. Additional configurations are added to that file. These modification are summarized as follows:
This is the third post out of five posts under the same topic. In the first post, I pointed out the difference in features. In the second post, I summed up the difference between the two kernels in terms of file names and contents. In this post, I will summarize changes in the conventions. They can be summarized into 3 categories.
Introduction of CPU.H
A notable change is the use of the CPU specific data types. In uCOS-II, data types were defined in OS_CPU.H. In uCOS-III, these definitions are defined in CPU.H. Every data type is prefixed with "CPU_".
Exceptions are OS_STK and OS_CPU_SR, they are renamed to CPU_STK and CPU_SR respectively.
In addition, in uCOS-II we had the OS_STK_GROWTH changed to CPU_CFG_STK_GRWOTH in uCOS-III and stored in CPU.H.
Introduction of "CFG" as Acronym
This is another convention added to define configuration options
Introduction of OS_CFG_APP.H
Some configuration options are configurable at the application level not at the kernel level as the case of uCOS-II. The application programmer only needs to define them during his application compilation rather than being defined in uCOS-II compilation which might not be accessible by the application programmer. These options plus new ones are defined in the OS_CFG_APP.H.
This file now contains configurations for maximum number of messages, ISR stack, idle tasks, ISR handler task, statistics task, ticks, and timers.
A notable change in these configurations that the word "TICKS_PER_SEC" is now replaced by "RATE_HZ". Frankly speaking, it became less confusing!
Changes in OS_CFG.H
The remaining configurations in OS_CFG.h are either renamed, moved, or removed. Additional configurations are added to that file. These modification are summarized as follows:
- DEBUG is replaced with DBG
- Naming configurations are removed as in uCOS-III objects are named during creation.
- In uCOS-III, all kernel objects are allocated during run-time. All configurations related to maximum number of objects are removed. This is really aids saving RAM and is not necessary to over allocate objects.
- Width of event flags is determined in uCOS-III by the data type OS_FLAG defined in OS_TYPE.H instead of OS_FLAG_NBITS used in uCOS-II.
- No query services are available in uCOS-III. All query configurations are removed.
- Accept functionality is now emulated in pend functionality through an option. All accept configurations are removed.
- Different posting functionality are now combined in a single post functionality. Extra posting configurations are removed.
- All configuration to support uC/OS-View are removed. This product is obsolete.
Friday, January 14, 2011
VHDL 360, Synthesis Examples
- Introduction
- Synthesize and Learn
- Combinational Logic
- Latch Inference
- Sequential Logic
- Flip-flop Interference
Synthesis Examples
View more presentations from Mohamed Samy.
Thursday, January 13, 2011
VHDL 360, Data Types and Operators Continued
- Operators
- Operators Precedence
- Logical Operators
- Addition Operators
- Relational Operators
- Shift Operators
- Multiplication Operators
- Miscellaneous Operators
- Aggregate
- Attributes
Data types and Operators Continued
View more presentations from Mohamed Samy.
Tuesday, January 11, 2011
VHDL 360, Synthesis Using ISE
- New Project
- Project Setting
- Import Files to ISE
- Synthesize Design Unit
- View RTL
- Synthesis Report
Synthesis Using ISE
View more presentations from amraldo.
Sunday, January 2, 2011
VHDL 360, Data Types and Operators
- Data Types
- Scalar Types
- Composite Types
- Exercise 1: Modeling a 16x16 ROM Memory
- Exercise 2: Modeling 1024x8 RAM Memory
Data types and Operators
View more presentations from Mohamed Samy.
Subscribe to:
Posts (Atom)