Microcomputer Systems 1

Microcomputer Systems 1 Visual DSP Kernel (VDK)

VDK Module Outline • What is the VDK? • Why Do We Need a Kernel? • VDK Concepts and Features • How to Create a Project with VDK support • Debug Capabilities • Summary/Conclusion Veton Këpuska

What is VDK? • The Visual DSP Kernel is a pre-emptive kernel designed to run efficiently on Analog Devices family processors • Included with VisualDSP++ development tools Veton Këpuska

What is VDK? • VDK is a collection of libraries and it’s associated support files, for example header files. • Lean kernel designed to quickly get something up and running quickly at no cost. Third party kernels and OS’s are more full featured. However, VDK does provide all the necessary hooks and mechanisms to fully implement almost any conceivable applicatiation. • Even though the kernel is described as a pre-emptive kernel, other scheduling methods can be defined…round robin, co-operative, etc Veton Këpuska

Why is Kernel needed? • A simple application that does only one task may not need a kernel • i.e. Blind processing of a “super loop” • If you have more than one task, an application could be structured in a couple of ways: • Respond to an event • Events change execution state • Assign tasks a given priority and execute high priority tasks more often • These approaches get difficult when • You need to preserve the state of a task • Low priority tasks may steal processing time longer than anticipated Veton Këpuska

Additional Clarification • “Super Loop” – some applications can be run as one big loop. For example, application code starts execution at “_main”. In some simple systems, it is possible to put a “while(1)”loop in main. All functions are executed in sequential order and once execution hits the bottom of the loop, the program resumes from the top. • “Respond to an event” – is known as an event driven kernel. For example, the system can spend all its time in an idle loop waiting for an external interrupt to happen. Once the interrupt is triggered, the code jumps to the service routine which then jumps to the processing routine. Once processing is down, the execution flow returns to the idle loop. • In a typical multi threaded system, a thread (task) could be interrupted at any point. At some time later when the thread continues execution it will be necessary to continue from where it was interrupted. In order for this to work, it is necessary for the thread to restore it’s state to what it was prior to being switched out. In other words the code must be re-entrant…VDK handles this automatically. Veton Këpuska

What does Kernel do for a User? • Automatic preservation of task/system state • Assign a scheduling method to tasks • Provides synchronization abilities • Frees architect from having to design ‘control code’ Veton Këpuska

What does Kernel do for a User? (cont.) • The state of each thread is stored on it’s own stack • VDK allows the architect to define the scheduling type…can be round robin, co-operative, true pre-emptive, or a combination of these techniques • ”Synchronization” capabilities refers to the various “signals” (Semaphores, Messages, Events, Device Flags)…see next slide notes for further examples • By using any kernel, it frees the developer from writing his own kernel and/or control code. He/she can focus on the application/algorithm design. Veton Këpuska

VDK Domain Concepts • Application code executes in one of two domains • 1 Thread Domain • 2 Interrupt Domain • Applications and algorithms execute in the thread domain under control of the VDK Kernel • Interrupts execute outside this domain and priority is implemented in hardware • Thread execution is halted while in the interrupt domain • Device drivers are a bridge between the two domains Veton Këpuska

VDK Domain Concepts (cont.) • The separation of domains is very real and the architect needs to realize how to segment his application so that appropriate functions operate in the appropriate domain. The architecture of VDK strictly enforces the concept of these domains. • Thread Domain – All data processing and user interface should operate within the Thread domain. Thread domain has the least priority in the system and is under control of the C run time and VDK scheduler. The scheduler determines what thread needs to be run based on if it has all it’s necessary resources, if it has the appropriate priority level, etc. • Interrupt Domain – priority of interrupts is set up in hardware through MMRs. ISRs operate outside the C run time. While in an ISR, NOTHING in the thread domain (even the scheduler) will execute. Therefore, it is recommended that ISRs be as short as possible. Only do what is necessary (i.e. an ADC might trigger a hardware interrupt. The isr then copies the data from the ADC and copies it to a memory location. The isr posts a flag that it has copied new data, then exits. IF an interrupt is written in C/C++ then a C run time is created for the ISR adding time to the amount spent in the ISR. Even though a c run time is created, the scheduler will still not run while program execution is in the isr. This can have system wide effects as NO other thread will execute. • Device Drivers – Device drivers aren’t specified to run in the thread or interrupt domain. In reality, the execute on the stack of whoever calls it. Device drivers allow a thread to read from a hardware resource. The device driver then interfaces to the specific hardware on behalf of the thread. More on device drivers later. Veton Këpuska

VDK Concepts & Definitions • Threads • A segment of code and it’s related variables/data • Each thread has its own stack and executes in supervisor mode • Interrupts • Priority based in hardware • Strongly recommend writing in assembly but C/C++ is supported • Signals • Semaphores, Events, Device Flags, and Messages • Used to synchronize activity • Device Drivers • Threads do not communicate with hardware directly • Hide the details of the hardware Veton Këpuska

Domain Model • Thread Domain • Under control of scheduler • Device Driver • Interface bridge between Thread and ISR domains • ISR Domain • Priority set in hardware using event controller configuration registers • Executes outside of schedulers control Veton Këpuska

Threads • Thread types defined at project creation • Each thread has a unique ThreadID • Each thread has its own stack • Programmers responsibility not to overflow • The heap for the stack and thread data can be specified Veton Këpuska

Threads (cont.) • Threads are created by instantiating a thread type. Thread types are defined at project creation. For a simple example, in an audio processing application one could have 3 thread types: • ThreadIN, • responsible for interfacing to a device driver to read an ADC • ThreadProcess, • audio algorithm(s)…maybe reverb and some EQ. • ThreadOut. • responsible for taking the processed data and writing it to a device driver that in turn sends the data out to an audio DAC • Messages could be used to transfer the data between the threads and also act as a synchronization method. For example, ThreadProcess could be pending on a message from ThreadIn, and ThreadOut could be pending on a message from ThreadProcess. • Using this technique, thread Process wouldn’t run until ThreadIn sent it valid data. Also, ThreadOut wouldn’t send data to the output device driver until it was finished processing. • Heap – simply an area of memory used for memory allocation (i.e. calls to malloc()) • Stack – an area used for local variable storage, parameter passing, return address, save state information, etc. Veton Këpuska

Semaphores • Signals are used to synchronize thread activity • A semaphore is a token that threads can post or acquire • i.e. relay race – second runner can not run until it has the baton • Semaphores can be periodic • allows given tasks to be scheduled on a fixed interval Veton Këpuska

What are Semaphores? • Semaphores are simply a token or key that a thread can make available (post) or wait for it to become available (pending). • Example: • Two threads may share a common memory buffer. • One would not want both threads possible trying to read/and or modify the data simultaneously. • A semaphore can be a way to ensure only one thread has access to the data…in order to read the data, the thread must first get the semaphore. • A periodic semaphore is a way to ensure that a given thread executes on a regular basis. • Example: • One may want a “user interface update” thread that runs 30 times per second. • A periodic semaphore can be the mechanism to ensure this happens. Note that it doesn’t guarantee “EXACTLY” when it will run…it only ensures that the thread waiting on the semaphore is moved to the ready queue. • Non blocked higher priority threads will execute first. In this particular example, the designer may choose to give the “user update guarantee” thread a very high priority level ensuring it takes priority over other system tasks. Veton Këpuska

Events and Event Bits • Events are used to synchronize thread activity to the system • Used to convey various system states to threads • Similar to semaphores but can convey several combined system states at once Veton Këpuska

Semaphores vs. Events • A semaphore can be thought of as a mechanism to synchronize a single requirement. • Example: a data buffer being ready, a dependant thread has finished execution, etc. • Events are a mechanism to describe that a combination of states have occurred. • Example, Data buffer is full, board one has powered up, initial configuration is loaded, user has initiated some process. When all of these events have occurred, the Event is said to evaluate true. • Events can also be configured so that if ANY of the event conditions are true, then it will evaluate to TRUE. • Event bits are the string of bits representing events in the system that are evaluated against a user provided mask. The result of comparing the event bits and mask is what is used to determine a true or false. Veton Këpuska

Messages & Inter-thread Communication • Inter-thread communication • Transfer information between threads • i.e. Thread A sends some data for processing to Thread B • Application views single and multi- processor systems the same Veton Këpuska

Messages (cont.0 • Messages are used to transfer data between threads. • Messages by default contain 2 words that are used as a pointer to a data buffer in memory. • Optionally, if the message can be contained within the 2 words, then no additional data buffer is necessary. Veton Këpuska

Interrupts • Execute using hardware priorities • Spend as little time as necessary and only do the minimal processing required in ISR • Any registers used by an ISR must be saved and restored • ISRs can be written in assembly, C or C++ • C/C++ not recommended but included for flexibility Veton Këpuska

Interrupts (cont.) • ISR priority is configured in hardware by mapping the system interrupt source into the core interrupt controller which is accessed through MMRs. • For example: • One could have SPORT0 map to IVG7 and RTC map to IVG8. • IF IVG8 and IVG7 were active at the same time, then IVG7 (SPORT0) would execute first (assuming nested interrupts were enabled). • Also, if the system were in the RTC ISR when the SPORT0 ISR was set, then program execution flow would jump to the SPORT0 ISR (because it has higher priority IVG7 vs IVG8)…again assuming nested interrupts were enabled. • In order to enable nested interrupts, one needs to push the RETI register onto the stack. For example: SP--=RETI; //This will enable nested interrupts…don’t put in if you want to disable //nested interrupts // SP is the stack pointer, // RETI is the return address // This statement: // 1) push-es the return address on to the stack, then // 2) decrements the stack for the next value to be pushed // 3) after pushing the RETI register, re-enables all interrupts Veton Këpuska

Device Drivers • Device drivers bridge the gap between the thread and interrupt domains • How threads communicate with hardware • Provides a black box view to the application • A device driver is a single function with multiple entry points • Initialization • Activation • Open • Close • SyncRead • SyncWrite • IOCtl Veton Këpuska

Device Drivers (cont.) • More information on programming paradigm for device drivers referred to as “Device Drivers and System Services” can be found in the device drivers programming manual. • The easiest way to understand a device driver is through an example. Lets say ThreadIN needs to read data from an ADC. At a 10000 foot view (there are some things left out), the following loosely describes the chain of events: • ThreadIn issues a read call to the ADC device driver • The device driver (which likely does not yet have the data) indirectly causes ThreadIN to block • The device driver itself will now block and other non blocking threads are able to move from the ready queue to the run queue • At some point in time, the ADC triggers a hardware interrupt • The ADC ISR is executed and the isr copies the data to a memory buffer, it then sets a flag that causes the ISR rescheduler to run, which in turn calls the Activation routine in the Device Driver, the ISR then exits • Some point in time later, the device driver is put on the run queue and is entered through the Activate() entry point, the activate function typically posts a flag back to ThreadIN. This flag indicates that the data is now accessible from the device driver. • at a later point in time, the Threads(ThreadIN) read call to the device driver returns the valid data from the ADC. Veton Këpuska

Creating Project using VDK • VDK support is added from the project wizard in Visual DSP++ • Visual DSP++ creates all the necessary project files and skeleton code Veton Këpuska

Auto-generated Framework • Automatically Added • Input.cpp • Output.cpp • Relay.cpp • Volcalc.cpp • VolRamp.cpp • Kerenel Files folder Veton Këpuska

System Node System Control Thread Configuration Veton Këpuska

Visual DSP++ and Kernel • When building a VDK project and additional TAB is added to the project window labeled KERNEL. All things related to the configuration of the Kernel, threads, signals, etc are configured here. Any necessary code is generated and automatically added to your project including skeleton code for any thread types defined. Veton Këpuska

Debugging VDK Code • Debugging Integrated in to Visual DSP++ • VDK Status window • State of each object, active thread, resource management, etc • VDK History window • Graphical display of system events • Useful when used with Trigger points Veton Këpuska

VDK Status Veton Këpuska

VDK History Window Veton Këpuska

VDK Summary • Provides a comprehensive set of services reducing the need to create your own control code • Allows for rapid prototype of system • Easy to move applications/algorithms across ADI processor families • Well integrated with the IDDE for efficient editing and debug Veton Këpuska

Veton Këpuska

Microcomputer Systems 1