Embedded Tips from Amr Ali

uCOS-III Source Code and Books are Now Available for Free

2011-08-11T00:59:00.000-07:00

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.

SECC: Embedded SW Training July 2011

2011-06-13T01:45:00.000-07:00

SECC is organizing the following courses in the:

Embedded Software Training Track

From 3 to 21 July 2011

Schedule , Fees & Instructors:

http://www.secc.org.eg/Schedule/Embedded_Software/Embedded_Schedule_2011.pdf

Registration:

Please fill in & submit your registration form at:

http://www.secc.org.eg/Embedded_Registration.asp

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

2011-06-13T01:42:00.000-07:00

Introduction

Fig1: FreeRTOS Logo

Few days ago, we were honored by a visit of Richard Barry to our blog. We asked him to have an interview for our blog. He agreed. The interview focused on various aspects. I tried to get the best out of it for all embedders and FreeRTOS fans.

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 Honors

in 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

FreeRTOS Story

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.

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

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 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.

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.

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:

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?

Introduction to C Programming Course

2011-05-09T11:16:00.000-07:00

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

Introduction to Embedded Systems

2011-04-30T16:00:00.000-07:00

Introduction
Embedded Hardware
Embedded Software
Embedded Development Tools

Introduction to embedded systems

View more presentations from amraldo

New Software Timers in FreeRTOS under MS Windows

2011-04-22T06:57:00.000-07:00

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.

But if hard-timers are more accurate than their soft counterparts, why are they used? The answer is in their nature. The can be programmed with timeouts of course granularity. In addition, the high-precision is not always needed in most of embedded systems. Another prevailing reason is reducing system interrupt overhead. Facilities of soft-timers are built using only 1 hardware-timer.

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.

Introduction to ARM Cortex M3 and STM32 - Part II

2011-04-18T11:48:00.000-07:00

This is the second post after the first tutorial.

STM32 System Architecture
Peripherals
Low Power Operation
Safety Features
The Flash Module
Development Tools

Introduction to stm32-part2

View more presentations from amraldo

Introduction to ARM Cortex M3 and STM32 - Part I

2011-04-18T11:42:00.000-07:00

Introduction
Cortex Overview
CMSIS

Introduction to stm32-part1

View more presentations from amraldo

You can find the second part here.

My Cooperation with CooCox

2011-03-21T12:19:00.000-07:00

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

VHDL 360, FPGA Programming

2011-03-18T14:43:00.000-07:00

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

VHDL 360, Post Place and Route Simulation

2011-02-25T10:03:00.000-08:00

Compile Simulation Libraries
Post PAR Simulation

Post Place and Route Simulion

View more presentations from amraldo

Running uCOS-III under Microsoft Windows

2011-02-25T07:57:00.000-08:00

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:

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

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

2011-02-18T11:41:00.000-08:00

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)

2011-02-16T10:19:00.000-08:00

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)

2011-02-10T09:06:00.000-08:00

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

2011-02-04T05:40:00.000-08:00

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.

VHDL 360, Modeling Finite State Machines (FSMs)

2011-01-24T12:26:00.000-08:00

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.

uCOS-III VS uCOS-II (Conventions)

2011-01-23T12:15:00.000-08:00

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:

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.

VHDL 360, Synthesis Examples

2011-01-14T14:51:00.000-08:00

Introduction
Synthesize and Learn
Combinational Logic
Latch Inference
Sequential Logic
Flip-flop Interference

Synthesis Examples

View more presentations from Mohamed Samy.

VHDL 360, Data Types and Operators Continued

2011-01-13T13:10:00.000-08:00

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.

VHDL 360, Synthesis Using ISE

2011-01-11T14:48:00.000-08:00

New Project
Project Setting
Import Files to ISE
Synthesize Design Unit
View RTL
Synthesis Report

Synthesis Using ISE

View more presentations from amraldo.

VHDL 360, Data Types and Operators

2011-01-02T10:53:00.000-08:00

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.

VHDL 360, Write More Complex Models Continued

2010-12-31T08:38:00.000-08:00

While Loop
For Loop
Exercise 1: Serial In Parallel Out
Wait Statement
Conversion Functions
Lab 1.a: Write the Code for a Fibonacci Sequence
Lab 1.b: Write the Code for Knight Rider LEDs

Writing more complex models (continued)

View more presentations from Mohamed Samy.

uCOS-III VS uCOS-II (File Names and Contents)

2010-12-31T05:19:00.000-08:00

Introduction
This is the second post out of five under the same topic. In the first post in the comparison, I pointed out the difference in features. In this post, I will point the difference in file names and contents in both kernels. Difference can be summed up to 13.

Changes in File Names and Contents
1- os_app_hooks.c is added to uCOS-III for convenience so the user can add application hooks. Copy this file to the application directory and edit the contents of the file.
2- os_cfg_app.h is added to uCOS-III. In old uCOS-II, all configurations were stored in os_cfg.h. In uCOS-III, application specific configurations are moved from os_cfg.h to os_cfg_app.h.
3- os_cfg_r.h used in uCOS-II as a starting point for configuring the kernel is now changed to os_cfg.h in uCOS-II. The new file is reserved for configuring non-application specific kernel features.
4- Porting files are the same but some variables and function names are changed.

OSIntNesting to OSIntNestingCtr
OSTCBCur to OSTCBCurPtr
OSTCBHighRdy to OSTCBHighRdyPtr
OSInitHookBegin to OSInitHook
OSTaskStatHook to OSStatTaskHook
OSTaskIdleHook to OSIdelTaskHook
OSInitHookEnd and OSTCBInitHook are removed
OSTaskStkInit in the new kernel has different arguments. Instead of taking the task's stack start address, it takes the task's stack size and its stack base address. This implies a slight change in this function code in uCOS-III.

5- os_dbg.c is a must in uCOS-III compared to its counter part, os_dbg_r.c, in uCOS-II.
6- os_int.c is added to uCOS-III to support the new feature called interrupt queuing in uCOS-III. This feature allows posting calls from ISRs to be deferred to a task level handler. The goal behind this feature is to reduce interrupt latency.
7- os_pend_multi.c is added to uCOS-III to allow tasks to pend on multiple kernel objects. The old code was written in os_core.c in uCOS-II.
8- os_prio.c is added to uCOS-III to isolate the code that determines the highest priority task ready to run. A port developer can re-implement this file in assembly equivalent if this will improve the performance.
9- A message mailbox is simply a message queue with one entry. That's why the file os_mbox.c is no longer available in uCOS-II.
10- os_msg.c is added to uCOS-III to encapsulate the management of messages in message queues.
11- os_stat.c is added to uCOS-III to extract the statistics task code from os_core.c.
12- os_type.h is added to uCOS-III. This file is used to adapt the data types sizes to the cpu architecture rather than being assumed by the port developer as in uCOS-II.
13- os.h is added to uCOS-III to act as the main header file and replace ucos_ii.h in uCOS-II.

VHDL 360, Simulation Using ModelSim

2010-12-17T09:48:00.000-08:00

Command Line Simulation
Compile and Simulate
Add Signals to Wave
Applying Inputs
Run Simulation
Make Files
Interactive Simulation

Simulation using model sim

View more presentations from amraldo.

VHDL 360, Write More Complex Models

2010-12-17T09:01:00.000-08:00

Statements
Process Description
Sequential Assignments
Data Objects
Objects Scope
Data Objects Example
Skills Check
Case Statement
Exercise 1: 2x4 by Decoder
If Statement
Exercise 2: D FF with Synchronous Reset
Exercise 3: Simple Comparator

Writing more complex models

View more presentations from Mohamed Samy.

uCOS-III VS uCOS-II (Features)

2010-10-04T04:40:00.000-07:00

Introduction

Migrating from uCOS-II to uCOS-III was a humming question in my head and the heads of many. I started trying to answer this question with the idea that uCOS-III is totally a new kernel but with roots into uCOS-II. My survey is based on uCOS-II source code and the Win32 for uCOS-III evaluation I got recently.

Differences between uCOS-III and uCOS-II can be classified under 5 categories:

Features
Source file names and contents
Conventions
Variable names
API changes

These areas are of great importance for those who are willing to port uCOS-II applications to uCOS-III.

I will try to explain briefly each category in a separate post.

If any of my results are not accurate enough due to the lackness of uCOS-III source code, please feel free to email me at amraldo@hotmail.com to correct it in this post.

Changes in Features
uCOS-III is introduced in 2009 while uCOS-II was first introduced in 1998. For both kernels, books and source code are available. But for uCOS-III, Micrium followed a new model. The source code is made available only to licensed users.

Unlike uCOS-II, uCOS-III has no limitation on numbers of tasks (255 tasks mazimum in uCOS-II) nor on the number of tasks at each priority level. Consequently, RR scheduling was introduced in uCOS-III.

uCOS-III kept all services available except for the message mailbox. It was totally removed. Although a message mail box can be used exactly like a binary semaphore, in addition for message passing, but after all it is indeed a message queue with a single entry. Another breakthrough is that mutexes and task's suspension resumption now support nesting.

Advances in performance were considered in the design of uCOS-III compared to uCOS-II. Smaller code size, support for run-time configurability, less interrupt latency, enhanced built-in measurements, time stamping on posting APIs, optimize schedulers in assembly are dreams coming into reality.

uCOS-III is working on being a safety-critical certified software. It is compliant with
MISRA C 2004 (except for 8 rules) and the certificaion is in progress to achieve DO178B Level A, EUROCAE ED-12B, SIL3/SIL4, and IEC 61508.

VHDL 360, Create Your First Model for a Simple Logic Circuit

2010-08-27T08:21:00.000-07:00

Entity
Exercise 1: Write the Entity of a 1-bit Full Adder
Architecture
Internal Signals
Expressions & Operators
Exercise 2: Write the Architecture of a 1-bit Full Adder
With-Select
When-Else
Exercise 3: Write the Entity and Architecture of 2x4 Decoder and 4x2 Encoder using With-Select and When-Else

Create your first model for a simple logic circuit

View more presentations from Mohamed Samy.

FreeRTOS Course - Semaphore/Mutex Management

2010-07-25T06:51:00.000-07:00

Binary Semaphore
Counting Semaphore
Mutex
More about Semaphore/Mutex
Semaphore/Mutex Management APIs
Lab4: Semaphore Mutex Management

FreeRTOS Course - Semaphore/Mutex Management

View more presentations from amraldo.

Free RTOS Course - Queue Management

2010-07-03T02:19:00.000-07:00

Queues
More About Queues
Queue Management APIs
Lab 3: Queue Management

FreeRTOS Course - Queue Management

View more presentations from amraldo.

VHDL 360, Introduction to VHDL

2010-07-02T08:21:00.000-07:00

What is VHDL?
VHDL History
Uses of VHDL
Basic Design Flow
VHDL Model
Entity
Architecture
Concurrency
Simple Example

Introduction to VHDL

View more presentations from Mohamed Samy.

VHDL 360, a Contribution from the SAMs

2010-06-30T09:23:00.000-07:00

About VHDL

VHDL is a powerful language developed in the 1980's by the US department of defense, afterwards adopted by the IEEE to be a standard in 1987. Many enhancements & new features were added afterwards in the 1993, 2002 & 2008 standards...

VHDL is widely used around the word in the design & verification processes of High & Very High Scale integrated circuits design (HSI & VHSI)

About the Free Course, VHDL 360

VHDL 360 is a free course. During the course, SAMS will try to guide & teach students how to write efficient VHDL code to model digital circuits, the course outline will be as follows:

Introduction to VHDL
Writing 1st Model
Writing more complex Models
Building Hierarchy
Modeling FSMs & Memories
Code Reuse
Verification

The course is based on VHDL IEEE 1076 - 1993 standard. It is vendor independent. Any text editor and tools you have license for can be used. Any consultation with regards to tools setup or support will not be provided and trainees should consult their own vendor for any of the issues or problems they face with this regards.

Feel free to post any comments, questions, and feedback through the blog. We promise to answer your questions as soon as possible Insha'Allah.

This VHDL course is for free use as long as the original copyright is reproduced. Feel free to spread and share. Knowledge is every body's right just like air and water.

Free FreeRTOS Course - Task Management

2010-06-27T10:56:00.000-07:00

Task C/Cs
Task States and Transitions
Task Priorities
Implementing a Task
Task's Hook
Idle Task
Idle Task Hook
Task Management APIs
Lab 2: Task Management

Free FreeRTOS Course-Task Management

View more presentations from amraldo.

Free FreeRTOS Course - Introduction to FreeRTOS

2010-06-21T12:10:00.000-07:00

At the Beginning
FreeRTOS in Literature
FreeRTOS History
FreeRTOS V6.0.0
FreeRTOS Features
Related Products
Licensing
FreeRTOS Variants
Free Support
Lab 0: Getting Started

FreeRTOS Free Course

2010-06-17T09:43:00.000-07:00

FreeRTOS the Real-Time Kernel

FreeRTOS is a small, yet powerful real-time operating system developed by Richard Barry and FreeRTOS Team and described in his book "Using the FreeRTOS Real-Time Kernel – a Practical Guide". The operating system is highly CPU independent and has been ported to numerous microprocessor platforms. The source code is available via this web site. It is distributed under the GPL with an optional exception. The exception permits users' proprietary code to remain closed source while maintaining the kernel itself as open source, thereby facilitating the use of FreeRTOS in proprietary applications.

FreeRTOS is designed to be small and simple. The kernel itself consists of only three or four C files. To make the code readable, easy to port, and maintainable, it is written mostly in C, but there are a few assembler functions included where needed (mostly in architecture specific scheduler routines). The download contains prepared configurations and demonstrations for every port and compiler, allowing rapid application design.

There are two forks of this OS; OpenRTOS and SafeRTOS. OpenRTOS, which has an identical code base to FreeRTOS but with different licensing. The OpenRTOS license removes all reference to the GPL and its implications. For example, one of the conditions of using FreeRTOS in a commercial product is that the user is made aware of the use of FreeRTOS and the source code must be provided upon request. OpenRTOS doesn't have this requirement. The other spin, SafeRTOS, is based on the FreeRTOS code base but has been updated, documented, tested and audited to enable its use in safety-critical products.

About the Free Course

The course scope is to teach students how to use FreeRTOS APIs. The course is based on V6.05. The course is organized in 8 modules. They are:

· Introduction to FreeRTOS

· Kernel Structure

· Task Management

· Queue Management

· Semaphore/Mutex Management

· Co-Routine Management

· Advanced Features

· FreeRTOS Porting

The labs for these modules are available based on the 80x86 industrial ports that use the open watcom compiler and ARM 7/Cortex that use the Keil compiler. Labs are only available commercially to our customers.

Feel free to post any comments, questions, ad feedback through the blog. I promise I will answer your post within 5 working days ISA.

This free course is for free use as long as the original copyright is reproduced. Feel free to spread, share, modify, or any other verb you can do with the material. Knowledge is every body's right just like air and water.

FreeRTOS GUI

After the course, I will publish a post on how to port an open source GUI for FreeRTOS. This post will help in demonstrating the power of FReeRTOS and how easily it can be extend with middleware. I have tested it only my PC. Work is currently on progress to test it on one of STM32 boards based on the ARM Cortex M3 processors.

Adding Interrupts to uCOS-II Running on Microsoft Windows

2010-05-29T02:48:00.000-07:00

How to Simulate Interrupts?

In the past few days, I was asked that question many times. So, I decided to make a small software example to show how uCOS-II interrupts can be simulated under Windows.

I modified the uCOS-II port to support 8 interrupts at the same level of priority. Moreover, these interrupts can occur simultaneously but their ISR execution order depends on the implementation. I followed the uCOS-II tasks's priority schema with interrupts (i.e. the smaller the interrupt number, the faster it will be executed).

The implementation core is done by creating a Win32 thread as a generic IRQ handler in os_cpu.c. In addition, 2 utilities were added in the file pc.c. They are used to register and unregister user ISRs. ISRs will be written only in C.

Testing the Interrupts Implementation

My test code is based on the 1^st example in uCOS-II book. I modified this code to have 5 tasks with the highest priority to be interrupt-driven. Each task of the 5 will wait for a semaphore before printing its number on the screen. ISRs will trigger these tasks by signaling the semaphores. The test code can be found here.

To automate this test, I wrote a utility that generates these 5 interrupts randomly every 2 milliseconds. The code for this utility can be found here. I just run my test code then run the interrupt generation utility. To distinguish the interrupt-driven tasks from others, I modified their code to print their IDs in a new color scheme. The interrupt generation utility code is found here.

Fig 1 shows the application running with interrupts. Numbers with blue background are those printed by tasks driven by interrupts.

Figure 1: Example 1 Modified to Run with Interrupts

Running Timer's of uCOS-II to Measure Cycle Average Execution Time

2010-05-28T08:36:00.001-07:00

Software 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.

Software Timers in uCOS-II

Starting from uCOS-II V2.8x, uCOS-II added the soft-timers feature. uCOS-II timers have 2 modes of operations; periodic and 1-shot modes. Whenever a timer timeouts, a callback function is executed. This service is implemented as a uCOS-II task. This task is assigned a stack size and priority defined the macros OS_TASK_TMR_STK_SIZE and OS_TASK_TMR_PRIO respectively. This task is signaled from the tick ISR at a constant rate defined by the macro OS_TMR_CFG_TICKS_PER_SEC. Whenever signaled, it updates the soft timers created by the user and make calls to callback functions if they expire. The design structure used for timers implementation is wheel spoke. Like any other uCOS-II service, this service is highly configurable. In order to use it you have to:

1. Define OS_TMR_EN to a value greater than zero

2. Define OS_TASK_TMR_STK_SIZE and OS_TASK_TMR_PRIO

3. Define frequency of timers update through OS_TMR_CFG_TICKS_PER_SEC

4. Enable hooks

5. Modify OSTimeTickHook to signals the timers manager task as explained here

6. Use any of timers management APIs in your application

Measuring Execution Time

To test the execution time of a cyclic task, you should use the OSTimeGet API at its start and end to measure the execution time. You should accumulate the total execution time and the number of cycles executed in order to calculate average cycle execution time. The soft-timer will be used to calculate this average at periodic rates. A code example is can be found here.

Fig 1 shows the result of running that code.

Figure 1: Timer Measuring Execution Time

Running FreeRTOS with Microsoft Windows Vista in 1 Hour

2010-04-29T04:02:00.000-07:00

About FreeRTOS

FreeRTOS is a real-time operating system for embedded systems, being ported to several microcontrollers. It is distributed under the GPL with an optional exception. The exception permits users' proprietary code to remain closed source while maintaining the kernel itself as open source, thereby facilitating the use of FreeRTOS in proprietary applications.

Another related project is OpenRTOS, which has an identical code base to FreeRTOS but with different licensing. The OpenRTOS license removes all reference to the GPL and its implications. For example, one of the conditions of using FreeRTOS in a commercial product is that the user is made aware of the use of FreeRTOS and the source code must be provided upon request. OpenRTOS doesn't have this requirement.

SafeRTOS is a derivative version of FreeRTOS that has been analyzed, documented and tested to meet the stringent requirements of the IEC 61508 safety standard. Complete safety lifecycle documentation artifacts have been created and independently audited to verify IEC 61508 SIL 3 conformance.

FreeRTOS and Windows Simulation

Can the Industrial PC port run under Windows? The answer is yes. In FreeRTOS, there is an x86 port that can run in a dos emulation box. But you should take care that it is a simulation and won't give you the correct response. In addition, there is an ARM port that can be simulated within Keil.

Steps to Run the x86 Port Under Microsoft Windows

1. Download the latest FreeRTOS from here

2. Unpack it under C Drive

3. Download the OpenWatcom tools for windows from here and install it under C drive

4. Open the Open Watcom project in the FreeRTOS/Demo/PC directory - it is called rtosdemo.wpj

5. In main.c, comment the line "vStartComTestTasks( mainCOM_TEST_PRIORITY, serCOM1, ser115200 );" or you will get errors about COM1 not available

Figure 1: FreeRTOS Running Under Microsoft Windows Vista

Next

I think the next step is to make a complete free course about FreeRTOS. This tutorial will serve as a starting point to build complete labs based on windows simulation. I hope, they will be a success like the uCOS-II courses I made earlier.

uC/TCP-IP Book Companion Software Now Available From Micrium Website

2010-04-27T00:38:00.000-07:00

uC/TCP-IP

uC/TCP-IP is a compact reliable, and high-performance stack that was built from the ground up by Micrium. Unlike other available TCP/IP stacks, Micrium's µC/TCP-IP has the quality, scalability, and reliability that translate into a rapid configuration of required network options, remarkable ease-of-use, and rapid time-to-market. This stackis described in the book "uC/TCP-IP The Embedded Protocol Stack". The stack is highly CPU independent and has been ported to numerous devices. The software provided together with the book and via the web site may be evaluated. Windows evaluation is also available via this link.

uC/TCP-IP Win32 Simulation

The uC/TCP-IP allows you to test your application on a PC even before your target HW is ready. Many tutorials are freely available for developing and debugging applications on top of uC/TCP-IP. These tutorials include:

1. uC/TCP-IP Socket Programming

2. uC/TCP-IP Win32 Simulation

3. Writing, Debugging, and Testing Ethernet Device Drivers

Running uCOS-III with Microsoft Windows Soon?

2010-04-21T06:28:00.000-07:00

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. While uCOS-III includes many of the same features you're already familiar with in uCOS-II, there are some important differences. For example, it also manages an unlimited number of application tasks and features an interrupt disable time of near zero. With round-robin scheduling, uCOS-III allows multiple tasks to run at the same priority level. uCOS-III puts greater control of the software in your hands, yet maintains Micrium's ease-of-use, ease-of-integration, short learning curve, unsurpassed documentation, and clean code.

uCOS-III x86 Win32 Simulation?

The tutorial is made available here.

Running uCOS-II and uC/GUI on Mini STM32 (ARM Cortex M3)

2010-04-10T05:16:00.000-07:00

Development Environment

I decided to test the two gifts, I earlier had from micro4you. These gifts were a Mini STM32 board and a Colink ARM USB JTAG. In addition, I use RVMDK4 as a cross compiler. In order to run this demo successfully, you should have a full version of this tool.

Installing Colink Driver

1. Go to http://www.ftdichip.com/Documents/InstallGuides.htm

2. Follow the installation guide matching your OS

3. Or go to http://www.ftdichip.com/Drivers/D2XX.htm to install the driver directly

Installing Colink ARM USB for RVMDK

1. Go to http://www.coocox.org/

2. Click on "Download Colink for MDK"

3. Save CooCox_Colink_MDK_Plugin_V1.81_Setup.exe to your PC

4. Run CooCox_Colink_MDK_Plugin_V1.81_Setup.exe and follow the installation. Install the plug-in in the same directory where Keil (RVMDK) is installed.

For screenshots for step 4, you can refer to http://www.coocox.org/CoLinkGuide/Installation.htm.

Testing the Application Using Colink

1. Open your project using RVMDK. The project contains uC/GUI demo application, uC/GUI ported to my TFT LCD, and uCOS-II ported to my board.

2. Build the target

3. Configure that target options to use the Colink for debugging and flash programming

For screenshots for step 3, you can refer to http://www.coocox.org/CoLinkGuide/Use.htm.

4. Make sure that the flash settings are STM32F10x On-Chip Flash 128K and the download function is Erase Sectors

5. Connect the board to its USB power cable and Colink ARM USB JTAG

6. Download the compiled program to the flash

7. Run the demo

Repeat steps from 2 to 7 with different configurations. To change demos running:

1. Open GUIDEMO.c

2. For the variable _apfTest, just comment the demos you want to stop and uncomment the demos you want run

3. Save the file

4. Repeat steps from 2 to 7

Next Steps

1. Run every possible demo of uC/GUI on the board

2. Use Arabic fonts with Arabic orientation for the complete demo finished above

My 2nd Visit to Anzma

2010-04-07T03:09:00.000-07:00

About the Visit

My visit, this time, was more focused on uCOS-II. I challenged their students to finish a 4-hours lab based on the example, I developed earlier. The goal was to finish the lab in 4 hours and with maximum 8 questions. They were 5 students. Amazingly, the first finished his work after 2 hours only. It ran successfully from the first time. Other 3 students finished after 3 hours and half while the last finished just before the given time.

It was a great transition for the students and they gain confidence in themselves to code in a multi-task style. They proved the effectiveness and efficiency of Anzma's RTOS courses. In less than 16 hours, students were able to program a real application using uCOS-II.

Figure 1 shows me and the students after finishing the lab.

Figure 1: From the left to the right (Khaled, Ahmed, Me, Islam, Ahmed, and finally the champ Ibrahim)

Another Gift from Micro4you

2010-04-03T07:16:00.000-07:00

About Micro4you

Micro4you studio is an established engineering design house in Thailand. Mirco4you was established in 2005. I had good connections with its CEO. We knew each other through www.edaboard.com; the famous forum for electrical and electronic engineering.

Micro4you sells cheap electronic components that proved to be useful for embedded engineers; especially these with low experience. Micro4you sells development boards, sensors, debuggers, peripheral boards …

Why Micro4you Did Send me the Gift?

After I sent Somboon Sopee, Micro4you CEO, the uCOS-II example I developed for Anzma, he tested it on the same board. The code ran successfully with no problems. He liked it and decided to send me gifts from his shop from a time to time. In return, he wants me to run examples using his stuff and publish them on my blog.

About the Gift

On April 3^rd,2010, I received a nice board. This boardcan be found here. Figure 1 shows this board.

Figure 1: STM32 Board with 2.8" TFT Module

On-board resources:

CPU: STM32F103RBT6; (LQFP64-pin, on-chip integrated 128K flash, 20KRAM, 16Bit A / D; PWM, CAN, USB and other resources)
2.8-inch TFT true color touch screen module, color touch module configuration ADS7843 (or RSM1843 instead) controller
SD card (SPI mode) can be used to store pictures, in support of AT45DBxxx of a DATA FLASH (can be used for storage)
USB interface, make USB experiment
RS232 interface (ISP download), make RS232 communicate experiment
AD adjuster
Standard ARM JTAG 20 pin
RTC
Four users LED lights, a power indicator light, a USB communication indicator
Two user keys
8MHz crystal, 32.768KHz crystal
USB power supply or power supply by JLINK
All I / O port through the standard pitch leads 2.54MM Board Size: 82MM X 55MM

Board software:

MDK 3.5 fully licensed
JLink for ARM 4.06
Complete STM32 documentation of the firmware library
Image2LCD for converting jpeg images to data that the LCD can understand
Board documentation, schematics, data sheets…
Test software for the board peripherals
uCOS-II and uC/GUI ported to the board with a demo
USB library with different demos to show how to use the USB port to control an audio speaker, joystick mouse, mass storage, virtual com…

What to Do with the Gift?

To start, I have to test the Colink cable with the board and download different demos to get started with it. A big problem, I face, is that everything on the CD is Chinese!!!

Somboon must be kidding :)

Running uCOS-II with Microsoft Windows

2010-03-28T00:52:00.000-07:00

uCOS-II Win32 Simulation with Windows
Most of the previous tests of the Win32 ports were never done, until writing this document, with Windows Vista and Windows 7. Lately, I have tested the previous work I have done in here and here on Windows 7 and Windows XP. It worked successfully on Windows 7 and Windows XP.