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