Your SlideShare is downloading. ×

RIT 2nd ARM Developer Day - Texas Instruments Presentation

665
views

Published on

Published in: Education, Technology, Business

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
665
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • The order of the agenda has some purpose…Tech overview of the bot is a good introduction to the device and good general way to start the day keeping things simple and general. By putting the assembly process after the tech overview it might help some folks understand better what they are assemblying and avoid confusion. Also this puts some “hands on” stuff in the middle of a lot of just plain lecture type slides to break things up better.We then go to the Stellaris and StellarisWare overview this is a general overview of the MCU family and different parts available from TI in the Stellaris family as well as a look at the StellarisWare package of software to support those MCU’s. Many attendees will be looking beyond the relatively narrow scope of just evalbot and just micrium.Next we introduce the RTOS and some RTOS principles this is just before the examples so it will be fresh in their minds since most of the examples are at the RTOS level.Display example is optional, digs in a little deeper and more detailed on first time opening the workspace and getting files around in IAR. A very simple hands on with a couple of breakpoints to show RTOS is performing multi-tasking.Audio example shows a code overview and then a quick hands on with more breakpoints and showing how flags pend/post will impact software tasks in the RTOSControl ExampleReal Hands On the merger of the audio and the control example for a more fun software package to take back to cubeville.
  • This is the board as delivered in the kit. 6 circular parts at top are the wheels pieces. The ones with metal rings are the outer wheel component and the one with out metal is the inner wheel component.Bumpers are on the bottom.Motor mounts are the rectangles by the wheels
  • A overview of the features of the evalbot. Mostly self explanatory.Things to highlight…On/off switch (often overlooked reason when a board won’t connect to a debugger/programmer)LM3S9B92 -> 256k flash, 96k RAM, ROM Bootloader, stellarisware in ROM, 80 Mhz, CAN, USB OHD, Ethernet MAC and PHY on chipuSD Card slot, three USB connections, host, device and debug/jtag ICDIEthernet,EM2 (TI Standard) connector for wireless TI modules.
  • Evalbot from a block diagram perspective.MCU in the middle, Blocks of this will be highlighted in the next few slides.Good to informally point out some of the same things we just had on the prev slide here for a different perspective. The verbal highlighting on this slide will be to provide a ref point for when we got into the subsets on the next few slides, having the big picture will help them see what piece we are giving details on.
  • The note at the bottom here is important. With both motors running and the MCU running full speed the device will consume significant amounts of current. Generally unpowered USB hubs should not be used to provide power.www.ti.com/lm3s9b92
  • FeaturesStereo CODEC with Integrated Mono Class-D AmplifierHigh Performance Audio DAC97 dBA Signal-to-Noise Ratio (Single Ended)16/20/24/32-Bit DataSupports Sample Rates From 8 kHz to 96 kHz3D/Bass/Treble/EQ/De-Emphasis EffectsFlexible Power Saving Modes and Performance are AvailableHigh Performance Audio ADC92 dBA Signal-to-Noise RatioSupports Rates From 8 kHz to 96 kHzDigital Signal Processing and Noise Filtering Available During RecordSeven Audio Input PinsProgrammable as 6 Single-Ended or 3 Fully Differential InputsCapability for Floating Input ConfigurationsMultiple Audio Output DriversMono Fully Differential or Stereo Single-Ended Headphone DriversSingle-Ended Stereo Line OutputsMono 1W Class-D BTL 8 Speaker DriverLow Power Consumption: 15-mW Stereo 48-kHz Playback With 3.3-V Analog SupplyUltra-Low Power Mode with Passive Analog Bypass
  • The MDI/MDI-X means a crossover cable is not needed to directly connect two devices, a standard patch cable will do the job.Emphasis here on the mac and phy on the chip. Can save as many as 17 pins that would be required on other parts where only the MAC is on chip and the user must provide a PHY.
  • TI USB mux is utilized to provide the multiple connections to host and device connectors.
  • This is the standard TI Stellaris evalkit ICDI. Provides full JTAG or SWD/SWO functions with a standard usb-mini cable. JTAG pins are available as a standard 10 pin connector if desired for use of ULINK or JLINK style programmers.In addition to the debug functions we also provide a virtual com port that ties to MCU UART0.
  • These are some of the features that make the Stellaris MCU more efficient in code execution Stellaris has single cycle flash up until the main clock reaches 50mhz. This is a performance advantage over some competitors.Stellaris Atomic operations can be performed both on a bit level in a special section of RAM as well as a pin level atomic read/modify/write in a single instruction cycle.
  • Up to now we have discussed the devices themselves (What is Stellaris). An MCU is only as good as the tools and software that support it.Stellaris team has created an extensive library of software, drivers and examples to help customers over the learning curve and directly to their value added application quickly.StellarisWare license is simple with two main restrictions: For use on TI microcontrollers and not to be combined with “viral” open source material which could compromise the restriction to use only on TI MCU’s. Primarily this restriction is aimed at unmodified GPL licenses. Most BSD style licenses are acceptable and many BSD style open source projects are demonstrated in the examples such as freeRTOS and lwIP.
  • Graphics library contains the code needed to create and interact with displays as are commonly used on eval kits and customer designs. Full set of static and interactive widgets is provided.To utilize these customer needs only to write/re-write a low level set of driver functions that directly interact with their display.
  • Stellarisware now includes an expanding set of wireless extensions.Current offering includes low power simple 2.4Ghz networks (SimpliciTI), Zigbee, and 13.56 Mhz RFID.
  • The latest version of Stellarisware is always available on the ti website. It is also present on the CD’s that come with the kits.The high level directory structure is shown. Boards -> where the board specific examples and drivers are foundBoot_loader -> customizable bootloader software for use with any Stellaris partDocs -> user’s guides, release notes etc. The primary first stop for Stellarisware docs.Driverlib -> the home of the peripheral driver library. Most Stellaris on chip peripheral API sourceExamples -> device agnostic example code such as a software uart using GPIOGrlib -> Graphics library source and library fileInc -> include files for definitions of chip peripherals and registersIQMath-> fixed point library for performance on devices without FPUSimpliciTI-> TI’s proprietary low power radio protocolThird_party-> contains the source code used in various examples that was not originally created by TI, released under various licensesTools->Provides general purpose tools. Most are windows applications to perform functions that either interact with or helped to create the examples. Makefsfile will convert standard HTML directory into C code files that can be directly used in a application and then compiled and downloaded to flash via standard methods. Sflash is specifically to work with serial flash loader, finder will find via UDP packets a Stellaris device on the networkUsblib-> the heart of the usb stack for device, host and OTGUtils->general purpose software to be compiled and run on Stellaris such as a uartprintf.c which allows use of printf like functions that output directly to the Stellaris serial port.Windows_drivers-> example windows drivers for some of the USB examples such as the USB oscilloscope
  • This is the board as delivered in the kit. 6 circular parts at top are the wheels pieces. The ones with metal rings are the outer wheel component and the one with out metal is the inner wheel component.Bumpers are on the bottom.Motor mounts are the rectangles by the wheels
  • Display example is our simplest example and runs with just two very simple tasks.As we stated earlier every task generally contains a while(1) loop or equivalent. They all generally also have some mechanism for yielding time back to the RTOS. Setup and configuration of the task, one time items are all done before the while statement in the task.Image shows the interaction and relationship between the project tasks with other tasks as well as the task interaction with the hardware of the evalbot.The following pattern holds for all of the book examples.Display example will boot up to main. Main will create the “start task”Main will then start the multi-tasking scheduler (the core/kernel of the RTOS)The “start task” will create all subsequent tasks.“start task” performs simple operations in its while loop and becomes another user taskOther tasks are now also performing their duties.For the display example in particularStart task takes over control of the LEDs which will blink on a timed schedule controlled by the RTOS timer functionalityDisplay task will rotate through messages to be shown on the screen
  • Open the example workspace located in the “\\Micrium\\Software\\EvalBoards\\TI\\LM3S9B92-EVALBOT\\IAR” DirectoryYou may see a message about workspace being created in older version of IAR. If so it is OK to move up to 6.10.2 which comes with this presentation. The original files were built with 5.40. They have been tested and run with 6.10.2 and do work.
  • One minor “gotcha” here is that if somone went too deep into the directory tree in previous (open workspace) slide then they may have a workspace that only has a single example and not all four. We want them to open the workspace with all four so that we do not have to re-open later. Attendees will use this workspace the remainder of the day.
  • Goal here is to show the project structure which is mostly repeated across all the examples. Again spending a bit more time on this now in order to save time later.Every example contains the following folder structureDouble click the example project name in the workspace explorer to expand the folder structureApp: contains the user application, app.c contains main function. App.c and app_cfg.h will be primary files of interestBSP: contains the board support package. Mostly this is all the stuff that is dependent on the board layout/schematicCFG: .h files to configure and setup the libs (uCOS libs) that are imported CPU: This contains the includes for Stellarisware Driverlib CPU specific non-RTOS driversuC/CPU Headers and micrium library that is specific for the CM3uC/LIB headers and micrium library for memory management, strings, math etcuC/OS-III The micrium core library and header files to manage it.uC/Probe Embedded side of the interface for the micrium uC/ProbeOutput: The linker will put the binaries and debug files here.
  • App.c in our examples will contain the main function as well as the primary user application stuff. This includes the application tasks that run the examples as well as the code that sets up those tasks prior to starting them and the scheduler.
  • Having run through some basic get the IDE up and running now we will go look at some code and run through it quickly. This is to introduce in terms of real code the things we just learned from the RTOS section of the lessons.If needed refer back to the RTOS slides for details of the parameters of the task create function.Primary take away here is that main is a very simple function. Turn off the interrupts, Init the OS, create a task, start the scheduler, the end.Once the scheduler starts it will run its idle task and the task we just created. The task we just created will in turn create another task to divide the work load as the programmer sees fit.NOTES from the RTOS slide for task create parameters repeated here…0) A task must be ‘created’ in order for µC/OS-III to be able to manage it. This is done by calling OSTaskCreate() and passing it a number of arguments. The first argument is the address of a ‘task control block’ which µC/OS-III uses to keep track of each task1) Each task is given an ASCII name. This allows you to easily identify each task during debugging.2) The next argument specifies the starting address of the task code (that is, the infinite loop). In C, this simply consist of specifying the name of the function.3) The caller needs to specify the priority of the task based on its importance. A low priority number indicates a high priority. The number of different priority levels is configurable with µC/OS-III. Also, you can specify any number of tasks at the same priority.4) You then need to specify the base address of the stack used for the task. Each task requires its own stack space. The size of the stack is task specific.5) You can specify the amount of time the task will run on the CPU when µC/OS-III round-robins tasks at the same priority. Specifying 0 here assumes a default value.6) Finally, you can specify options. For example, will the task perform floating-point? Do you want to zero out the task’s stack? Do you want µC/OS-III to determine the stack usage at run-time? And more
  • This task is a very simple state machine
  • At this point we move a bit beyond demonstration and show and tell. Now we want them to start getting into the code and doing things.This first example we will do a very simple set a couple of breakpoints and show how the code is bouncing from one task to another without functions calls. It is all done by the RTOS behind the scenes as far as the task itself is concerned it thinks it has continuous and total CPU control.
  • Set up the second break point in the second task. May have some trouble with single stepping depending on compiler settings. If timer tick goes off while still stepping we may go into the kernel as it tries to task switch. This is unlikely and single stepping should work. My limited testing shows that single steps work well and do not get flubbed by kernel interrupts or task switches. The step just bounces to the other task as needed.
  • Most (probably all) attendees will be familiar with IDEs and debuggers. However, a few likely will not have seen IAR before. It is pretty intuitive and simple and much like many other popular IDE’s out there.The primary areas of interest are the code area in the middle where the single step and breakpoints are primarily set. The disassembly area on the right is used only occasionally for deeper debug understanding.The debug log area will show if any errors popped up in JTAG communications at any point. It is also the area where memory windows will appear by default.The project explorer area is the same functionality as we have been using it for till now.Finally the debug controls area is a toolbar that opens up in debug mode. This gives quick easy access to single step, stop, exit, go, and other commonly used debug commands.The View menu will have options to enable memory, watch, breakpoint, register, peripheral windows and the like.
  • This is basic debug 101 stuff. Mostly inserted here for the help of those pretty new to IAR or embedded programming. This will not be covered nearly so deeply as we examine the next examples.
  • “Rinse Lather Repeat” means Have the attendees hit go a few more times to show how the code is bouncing between the two tasks simply via the RTOSThis shows very simple multi-tasking at work. Both tasks think they have full CPU access but neither does. From a coding perspective only when interacting with shared hardware or memory (including shared functions) do we need to concern with the RTOS being around and guard against multiple access.Spending some time on multitasking is worth while. For RTOS newbies it is a difficult concept. In this example one task solely controls the display, the other task solely controls the LEDs therefore no Kernel functions are required to interface and synchronize the two.Also note the green arrow shown here in the disassembly window. This will dictate whether single step mode goes by assembly single step or C single step. Click in the C area and the green arrow moves to the C language lines of code and now we single step by multiple assembly instructions but exactly one line of C.
  • If you went through the display example then this will have already been done. Therefore we spend less time on it here.This is standard windows GUI stuff.
  • Having run through some basic get the IDE up and running now we will go look at some code and run through it quickly. This is to introduce in terms of real code the things we just learned from the RTOS section of the lessons.If needed refer back to the RTOS slides for details of the parameters of the task create function. (high level below in these notes as well)Primary take away here is that main is a very simple function. Turn off the interrupts, Init the OS, create a task, start the scheduler, the end.Once the scheduler starts it will run its idle task (not shown to the user, it is behind the scenes in uC/OS Kernel) and the task we just created. The task we just created will in turn create another task(s) to divide the work load as the programmer sees fit.NOTES from the RTOS slide for task create parameters repeated here…0) A task must be ‘created’ in order for µC/OS-III to be able to manage it. This is done by calling OSTaskCreate() and passing it a number of arguments. The first argument is the address of a ‘task control block’ which µC/OS-III uses to keep track of each task1) Each task is given an ASCII name. This allows you to easily identify each task during debugging.2) The next argument specifies the starting address of the task code (that is, the infinite loop). In C, this simply consist of specifying the name of the function.3) The caller needs to specify the priority of the task based on its importance. A low priority number indicates a high priority. The number of different priority levels is configurable with µC/OS-III. Also, you can specify any number of tasks at the same priority.4) You then need to specify the base address of the stack used for the task. Each task requires its own stack space. The size of the stack is task specific.5) You can specify the amount of time the task will run on the CPU when µC/OS-III round-robins tasks at the same priority. Specifying 0 here assumes a default value.6) Finally, you can specify options. For example, will the task perform floating-point? Do you want to zero out the task’s stack? Do you want µC/OS-III to determine the stack usage at run-time? And more
  • The main task after init of the startup task is actually to suspend/resume the LED task. This could have been done in one task but this shows inter-task syncing and that one task can suspend/resume another task independent of that tasks state.
  • The actual showing of play time total and play time remaining is done in the wav functions.
  • We will now set a couple breakpoints to demonstrate the FlagPend / FlagPost mechanisms fortask synchronization actually work. Break points can be set at any time during debug as well. It is just slightly simpler to navigate the code when the extra debug views are not open in the IAR window.This flag is just after a FlagPend. Therefore it cannot be reached until after the flag has been posted. The kernel effectively causes this flag pend function only to return when the flag is posted.
  • We will also now set a breakpoint that will only be hit when we press the play button.We will see that the button is pressed, detected, flag posted and immediately the other task is made ready and obtains the CPU and the breakpoint is hit.
  • First and most likely error code here is 0x0002 or similar which basically says cannot connect to device. This is generally caused by failure to turn on the EVALBOT and have it connected and drivers installed.
  • Pressing run will not hit any of the breakpoints we just set. This is intentional and shows that the first is never reached because of the flag pend and the second is not reached because the button is not pressed.The flag post/pend that occurs with the breakpoints shows that both tasks are synced to the button event even though only one of them is actually monitoring the button directly.
  • Flags are the primary means of synchronization used in the examples in the book. MANY other mechanisms are available in the RTOS that are not shown in these examples. The concepts are similar but typically the protections offered get better and better flags are among the most basic and thus a good place to start.
  • If time permits the attendees can play with other breakpoints and singe stepping.In order to fit in flash the wave files are so short it is hard to stop them before they finish so
  • This is very similar to the input monitor task that we just looked at from the previous audio example. The only differences are in the details of what gets done at the user/app level when a button/bumper is detected.
  • Continuation of the input monitor task showing how this app responds to different inputs.
  • By default on hitting debug button we will get to a debug window and we will run to main.Our breakpoint is set to trigger as we exit from the driving forward state, so we have to press the switch to start driving forward
  • Attendee will stepp one more time beyond the line shown and the robot will start turning again.The Motor and PID tasks are governing the robot while the control task is pending on the flags. Shows again 1) how the control logic flows from state to state. State machines are pretty common method of control this simplifies them over a cyclic executive. 2) This shows how the RTOS allows other tasks to operate while this one is suspended.State machines with timing requirements are a great case study for the need for an RTOS. Doing a similar control algorithm without an RTOS would require more variables and interrupts and a lot more opportunity for failure. The RTOS isolates components.
  • Adding the waves is IAR specific function that may be of only limited use to some users. However, adding a new task and going through those steps is quite helpful to most and this in the end is a very fun little demo. Shows how using an RTOS makes adding new functionality simple and unobtrusive to the existing code.
  • Open the example workspace located in the \\Micrium\\Software\\EvalBoards\\TI\\LM3S9B92-EVALBOT\\IAR Directory
  • The wave files need to be added and accessed in two ways.We have to add them to the linker so that it can link the raw data into the flash image.We have to create a couple of variables so that we can access and track the wave file images from C code.
  • To make this as painless as possible for attendees we crated the “IAR Linker Settings.txt” file that attendees can copy/paste these settings from.--image_input=$PROJ_DIR$\\..\\audio_clips\\wave1.wav,wave_1,wave_1,4--keep wave_1--image_input=$PROJ_DIR$\\..\\audio_clips\\wave2.wav,wave_2,wave_2,4--keep wave_2--image_input=$PROJ_DIR$\\..\\audio_clips\\wave3.wav,wave_3,wave_3,4--keep wave_3--image_input=$PROJ_DIR$\\..\\audio_clips\\wave4.wav,wave_4,wave_4,4--keep wave_4--image_input=$PROJ_DIR$\\..\\audio_clips\\wave5.wav,wave_5,wave_5,4--keep wave_5Syntax here is--image_inputfilename [,symbol,[section[,alignment]]] So in this case the filename is wave1.wav, the symbol will be wave_1 the section will be wave_1 and the byte alignment of the section is 4. image_input just puts the raw binary data directly into the flash image that will get downloaded to the chip.--keep forces this symbol NOT to be included in the output even if the linker thinks it is unused. Required since we primarily access these file via pointers to the start of the section not with the symbol name.
  • Essentially these pragmas will be later used to create and initialize pointers to the beginning of the wave files.The other variables are standard C variables that all we use to pass to functions and hold the important information regarding the wave files.
  • The Task Control
  • The Task Control static CPU_STK AppTaskRobotAudioPlaybackStk[APP_TASK_ROBOT_AUDIO_PLAYBACK_STK_SIZE];
  • This is where some of the overhead and learning curve of an RTOS pays off. We just copy whole a task from an old application and paste it into the new application. We are not trying muddle in bits and parts of code into the middle of existing functions that are doing the control things that we need to govern the audio behavior. In a non RTOS environment we would be putting bits of the audio task function into the case statements of the control function.We could even easily make this new task a separate .c file which could managed in version control by another programmer who could independently make changes and bug fixes without disturbing our main application code.
  • We just copied the task function over to EX4 in the previous slides. Now we actually have to copy the code to tell the RTOS this new task exists and that it should be scheduled in with the others.
  • Tasks can share the same priority and those tasks at the same priority will get round-robin access to the CPU. Basically they take turns if both are ready at the same time and no higher priority tasks are also ready.Numerically lower values are the highest priority in uC/OS-III. In ex 2 Audio is the primary purpose so it is high priority. In our new application it is just for fun so we can make a lower priority.
  • We could create a new flag group but since all but the timer flag of this group already pertain to the sensors we care about for this new application this is simpler.The original app has the same behavior regardless of which of the two user buttons got pushed. We want different sounds for each. Thus we need more detailed data from the input monitor about which of them was pressed. FLAG_PUSH_BUTTON is set by the original app for either button.At this point we have a new flag but someone has to post that flag. To make sure the right flag gets posted we will next modify the Input Monitor Task to set these flags in addition to the original FLAG_PUSH_BUTTON. The old application task still get the data they need but our new task gets the more detailed data it needs.
  • Copy the original if statement. This original if is true if either button was pressed and the debounce condition is met.We change the condition to be unique for each button (and make a copy to have two if statements not just one)We also add our new FLAG to the Post function call in addition to the existing post of FLAG_PUSH_BUTTON we now also post the FLAG_USER_BUTTON for our specific button.
  • FLAG_USER_BUTTON_1 | FLAG_USER_BUTTON_2 | FLAG_LEFT_BUMP_SENSOR | FLAG_RIGHT_BUMP_SENSOR,
  • flags = OSFlagPendGetFlagsRdy(&err); if(flags & FLAG_USER_BUTTON_1) { } if(flags & FLAG_USER_BUTTON_1) { } if(flags & FLAG_USER_BUTTON_1) { } if(flags & FLAG_USER_BUTTON_1) { }
  • The last step to modify the application is to add the BSP function calls to actually Open and Play the files.The best way to do this is to copy the BSP functions calls that currently sit just below the close of the “if(OS_ERR_NONE==&err)” if statement.Be sure to eliminate/delete these two BSP calls that are just below line 882 in this image.The file at index 0 is the “intro” -> Human voice saying “this is the Stellaris Evalbot audio demo”File at index 3 is the “horn”File at index 1 is “boing” a fun noise for when we hit somethingFile at index 2 is “crash” another similar fun noise for when we hit something on the other side.
  • Transcript

    • 1. RIT- ARM Developer’s Day 2011 Stellaris Cortex M3 Eval-Bot Dwane Bell- Digital Applications
    • 2. Overview • Technical Overview of the Stellaris EVALBOT • Stellaris and StellarisWare Software Overview • Introduction to RTOS and Micrium µC/OS-III • Display Example • Audio Example • Control Example • Hands On: Audio and Control Merger • Stellaris EVALBOT Assembly
    • 3. MPUs – Microprocessors Embedded processing portfolio 32-bit ARM Cortex™-M3 MCUs 16-bit ultra- low power MCUs DSP DSP+ARM ARM Cortex-A8 & ARM9™ MPUs Stellaris® ARM Cortex-M3MSP430™ Sitara™ ARM Cortex-A8 & ARM9 C6000™ DaVinci™ video processors TI Embedded Processors Digital Signal Processors (DSPs)Microcontrollers (MCUs) ARM®-Based Processors OMAP™ Software & Dev. Tools Up to 80 MHz Flash 8 KB to 256 KB USB, ENET MAC+PHY CAN, ADC, PWM, SPI Connectivity, Security, Motion Control, HMI, Industrial Automation $1.00 to $8.00 375MHz to >1GHz Cache, RAM, ROM USB, CAN, PCIe, EMAC Industrial automation, POS & portable data terminals $5.00 to $25.00 Up to 25 MHz Flash 1 KB to 256 KB Analog I/O, ADC LCD, USB, RF Measurement, Sensing, General Purpose $0.25 to $9.00 300MHz to >1Ghz +Accelerator Cache RAM, ROM USB, ENET, PCIe, SATA, SPI Floating/Fixed Point Video, Audio, Voice, Security, Conferencing $5.00 to $200.00 32-bit real-time MCUs C2000™ Delfino™ Piccolo™ 40MHz to 300 MHz Flash, RAM 16 KB to 512 KB PWM, ADC, CAN, SPI, I2C Motor Control, Digital Power, Lighting, Ren. Enrgy $1.50 to $20.00 Ultra Low power DSP C5000™ Up to 300 MHz +Accelerator Up to 320KB RAM Up to 128KB ROM USB, ADC McBSP, SPI, I2C Audio, Voice Medical, Biometrics $3.00 to $10.00 Multi-core DSP C6000™ 24.000 MMACS Cache RAM, ROM SRIO, EMAC DMA, PCIe Telecom test & meas, media gateways, base stations $40 to $200.00
    • 4. The Texas Instruments EvalBot Unassembled • Board Overview & Setup – 4-inch diameter circuit board – ~ 30 minutes of mechanical assembly – Factory-installed quickstart software resides in on-chip Flash memory – Texas Instruments analog components for: • Motor Drive • Power Supply • Communications Functions
    • 5. EVAL-BOT TECHNICAL OVERVIEW
    • 6. Texas Instruments EvalBot Overview “Bump” Sensors (2) User Switches (2) I²S Audio Codec w/ Speaker Stellaris LM3S9B92-IQC80 USB-Device Connector USB-Host Connector MicroSD Socket 96x16 Blue OLED Display ON/OFF Switch DC gear-motors (2) EM2 Expansion Header (compatible w/ TI Wireless Evaluation Modules) In-Circuit Debug Interface (ICDI) Battery Power (3 AA) or USB
    • 7. EvalBot Block Diagram & Features • Evaluation board with robotic capabilities • Mechanical components assembled by user • Stellaris® LM3S9B92-IQC80 microcontroller • MicroSD card connector • I2S audio codec with speaker • USB Host and Device connectors • RJ45 Ethernet connector • Bright 96 x 6 Blue OLED display • On-board In-Circuit Debug Interface (ICDI) • Battery power (3 AA batteries) or power through USB • Wireless communication expansion port • Robot features – Two DC gear-motors provide drive and steering – Opto-sensors detect wheel rotation with 45° resolution – Sensors for “bump” detection
    • 8. Stellaris® LM3S9B92 ARM® Cortex™-M3-based microcontroller • 256-KB Flash memory • 96-KB SRAM • 80MHz processing power • 16.0-MHz crystal (Y3) for main internal clock circuit - Internal PLL configured in SW multiplies clock to higher frequencies for core and peripheral timing • Unused signals routed to either: - 20-pin EM expansion socket - 9 GPIO, PWR & GND on 0.1” pitch break-out pads - Internal MUX allow different peripherals assigned to each GPIO pad *Note – When adding external circuitry, consideration should be given to the additional load put on EvalBot’s power rails
    • 9. Audio • Texas Instruments TLV320AIC3107 CODEC • High performance audio via Class D Amplifier: – Provides higher efficiency (>80%) than Class-AB amplifiers (<60%) – Provides higher output power  louder audio – Consumes less power  longer battery life • I²S interface carries I/O audio data streams • I²C interface configures CODEC • Unused audio pins available on nearby pads (0.05” pitch)
    • 10. Ethernet • Fully integrated, on-chip 10/100 Ethernet MAC and PHY layers – Media Access Control (MAC) addresses format standards – Physical Layer (PHY) used for wiring and signaling standards – On-chip  no additional components! • TX and RX signals routed to jack as differential pair • PHY incorporates Medium Dependent Interface (MDI/MDI-X) cross over – TX & RX pairs can be swapped in software • 25.0-MHz (Y1) crystal provides accurate timebase for PHY Stellaris Integrated on single chip
    • 11. Organic LED Display • 96 x 16 OLED display w/ two push switches • Integrated controller IC w/ parallel, SPI and I²C interfaces • Only the I²C interface is used – Limited to “write only” in this mode – Pixel data cannot be read back from display USB • The LM3S9B92 microcontroller has Host, Device and OTG USB capabilities • A TI T3USB30E high-speed USB multiplexer selects between dedicated USB Host and Device connectors
    • 12. Power Supply • Powered by either: – 3 AA batteries – ICDI USB cable or USB device cable • Power source determined by – TI TPS2113 Auto Switching Power Mux – Two Schottky diodes • Power supply generated directly or indirectly from main power bus, +VS, using: – Boost converter  +12V for motor drivers – Linear drop out regulator  +3.3V for logic power (MCU)
    • 13. • Debug via an integrated In-Circuit Debug Interface (ICDI) for debugging, serial communication and power over a single USB cable *Note - ICDI USB capabilities are independent of MCU’s on-chip USB functionality • An FTDI FT2232 USB controller implements: • JTAG/SWD (synchronous serial) port on channel A – JTAG uses signals TCK, TMS, TDI, and TDO – SWD uses signals SWCLK, SWDIO and optionally, SWO for trace • SWD mode provides direction control of the bidirectional data line • Virtual COM port (VCP) on channel B – Allows Windows applications (i.e. – HyperTerminal) to communicate w/ UART0 • Serial Wire Out (SWO) – Route SWO data stream to VCP transmit channel and debug software decodes and interprets trace information from VCP – Normal VCP connection to UART0 is interrupted when using SWO Debugging
    • 14. Expansion & MicroSD • MicroSD card interfaces to the MCU using a SPI interface – Power to SD card is not controlled  do not insert/remove while powered •Evaluation Module (EM) port enables: – RF connectivity using a range of Low-Power RF EM boards from TI. • Boards support both sub 1-GHz and 2.4-GHz bands – GPIO expansion via SPI, UART and GPIO signals • Connector part numbers:
    • 15. Robotic Features • Two 12-V gear motors controlled by TI DRV8801 Full-Bridge motor driver which provides: – Direction control – Over-current protection – Short-circuit protection • Each wheel has two infra-red optical sensors which generates quadrature signal as the wheel rotates • IR emitters (D2, D3, D11, D12) each connect to a GPIO signal – GPIO outputs should be configured for 8mA drive-strength to ensure IR emitters have sufficient intensity • Detector switches – GPIO inputs should have internal pull-up resistors enabled – Optional configuration to generate interrupt when collision occurs – Dead-time insertion – Several switching schemes
    • 16. INTRODUCTION TO STELLARIS AND STELLARISWARE
    • 17. • Stellaris – Family of ARM Cortex-M3-based microcontrollers from Texas Instruments – The first Cortex-M3 silicon implementation available anywhere • Key advantages – For the first time ever, embedded microcontroller system designers can utilize 32-bit performance for the same price as their current 8- and 16-bit microcontroller designs – MCU applications starting with the Stellaris family have access to • Industry’s strongest ecosystem of silicon, tools, software, and support • “$1 to 1 GHz” instruction set compatible performance • A breadth of instruction-set compatible performance and cost that exists only in the ARM architectural community – Conceivable that you will NEVER HAVE TO UPGRADE architectures or change tools again! What is Stellaris?
    • 18. What is ARM® Cortex™-M3? • The Cortex family of ARM processors provides a range of solutions optimized around specific market applications across the full performance spectrum. • Cortex underlines ARM's strategy of aligning technology around specific market applications and performance requirements. • The ARM Cortex family is comprised of three series, which all implement the Thumb-2 instruction set to address the increasing performance and cost demands of various markets: – ARM Cortex-A Series, • Applications processors for complex OS and user applications. • Supports the ARM, Thumb and Thumb-2 instruction sets. – ARM Cortex-R Series • Embedded processors for real-time systems. • Supports the ARM, Thumb, and Thumb-2 instruction sets – ARM Cortex-M Series • Deeply embedded processors • optimized for cost sensitive applications. • Supports the Thumb-2 instruction set only Note: • ARM Code 32-bit instructions / 32-bit data • Thumb Code 16-bit instructions / 32-bit data • Thumb-2 Code mostly 16-bit & some 32-bit (25% Faster, 26% Smaller) Did You Know? Texas Instruments is the lead partner for ARM Cortex A8, R4, and M3!
    • 19. ARM® Cortex™-M3 Features •Cortex-M3 is the Microcontroller Version – Optimized for single-cycle flash usage – Deterministic, fast interrupt processing: as low as six cycles, no more than twelve – Single-cycle multiply instruction and hardware divide – Native Thumb2 mixed 16-/32-bit instruction set—no mode switching – Three sleep modes with clock gating for low power – Superior debug features including data breakpoints and flash patching – Atomic operations—read/modify/write in single instruction – 1.25 DMIPS/MHz—better than ARM7 and ARM9
    • 20. Cortex M3 core: no assembly! • Cortex-M3 has complete HW support for interrupts – Interrupt Service Routines (ISRs) are purely written in C/C++ – Interrupt setup is easily done in C/C++ • C/C++ array which contains the vectors (pointers to the C/C++ functions) • Pointer to the stack (a C/C++ array) • No boot code ASM, no system configuration ASM – ARM7 compilers normally comes with a ASM boot routine (in object form) that does setup. – For Cortex-M3, no boot routine is needed • Cortex-M3 hardware loads the stack pointer from memory and the initial PC from memory and enters as a normal C function. – User C/C++ code is all that is required. • Entire software code base can be written in C/C++ – ISRs – RTOS – Application code ASM C/C++
    • 21. Stellaris® Family Technology • ARM® Cortex™-M3 v7-M Processor Core – Up to 80 MHz – Up to 100 MIPS (at 80 MHz) • On-chip Memory – 256 KB Flash; 96 KB SRAM – ROM loaded with Stellaris DriverLib, BootLoader, AES tables, and CRC • External Peripheral Interface (EPI) – 32-bit dedicated parallel bus for external peripherals – Supports SDRAM, SRAM/Flash, M2M • Advanced Serial Integration – 10/100 Ethernet MAC and PHY – 3 CAN 2.0 A/B Controllers – USB (full speed) OTG / Host / Device – 3 UARTs with IrDA and ISO 7816 support* – 2 I2Cs – 2 Synchronous Serial Interfaces (SSI) – Integrated Interchip Sound (I2S) • System Integration – 32-channel DMA Controller – Internal Precision 16MHz Oscillator – Two watchdog timers with separate clock domains – ARM Cortex Systick Timer – 4 32-bit timers (up to 8 16-bit) with RTC capability – Lower-power battery-backed hibernation module – Flexible pin-muxing capability • Advanced Motion Control – 8 advanced PWM outputs for motion and energy applications – 2 Quadrature Encoder Inputs (QEI) • Analog – 2x 8-ch 10-bit ADC (for a total of 16 channels) – 3 analog comparators – On-chip voltage regulator (1.2V internal operation) * One UART features full modem controls
    • 22. • Royalty-free source and object code for use on TI MCU’s – Peripheral Driver Library – Graphics Library – USB Library – IQ Math Library – Wireless – In System Programming – 3rd Party Extensions – Examples – http://www.ti.com/stellarisware What is StellarisWare?
    • 23. Peripheral Driver Library • High-level API interface to complete peripheral set • Royalty-free use on TI MCUs • Simplifies and speeds development of applications • Can be used for application development or as programming example • Available as object library and as source code • Compiles on ARM/Keil, IAR, Code Red, Code Composer Studio and CodeSourcery/GNU tools • Peripheral driver library functions are preprogrammed in ROM on select Stellaris MCUs
    • 24. Primitives Radio Buttons Checkbox Canvas Push Buttons Container Security Keypad BLDC Touchscreen Motor Controller Graphics Library
    • 25. • Examples available: – Device Examples: • HID Keyboard • HID Mouse • CDC Serial • Generic Bulk • Device Firmware Upgrade • Oscilloscope – Host Examples: • Mass Storage • HID Keyboard • HID Mouse – Windows INF for supported classes • Points to base Windows drivers • Sets config string • Sets PID/VID • Precompiled DLL saves development time – Device framework integrated into USBLib USB Driver Library
    • 26. • IQmath Benefits – Math library for fixed-point processors speeds computation of floating-point values – Sin, cos, tan, arcsin, arccos, sqrt, fractional mpy, dv, etc... – Speed up processing for • motor control • servo control • audio / image encoding & decoding • fixed-point Q math • graphical rotation – Resolution adjustable based on application requirements – Achieve seamless code portability between fixed & floating point devices – http://www.ti.com/iqmath IQ Math Library
    • 27. Wireless Extensions • Stellaris 13.56 MHz RFID Wireless Kit – DK-EM2-7960R • Stellaris 2.4 GHz SimpliciTI™ Wireless Kit – DK-EM2-2500S • Stellaris Zigbee Networking Kit – DK-EM2-2520Z – http://www.ti.com/stellariswireless
    • 28. • Boot Loader – Interface options include UART (default), I2C, SSI, Ethernet, USB – Customizable code in the Stellaris Peripheral Driver Library with full applications examples – Preloaded in ROM on select Stellaris Microcontrollers • Serial Flash Loader – Bootloader like code programmed into flash on devices without a bootloader in ROM – Interface options include UART or SSI • JTAG and SWD Interface – Standard compliant interface to traditional debug environment – Always present never required on Stellaris • LM Flash Programmer – Windows GUI + Command Line Interface the above In System Programming
    • 29. Third Party Extension • Many application examples use third party code – ‘.StellarisWarethird_party ’contains any required third party source code files and information – Each ‘third_party’ directory contains all required information • Documentation, source code files, etc – Example projects using any ‘third_party’ directly links the required source code ‘*.c’ and header ‘*.h’ from the relevant ‘third_party’ directory.
    • 30. • StellarisWareboards => Each kit has its own folder • Each kit folder contains… – ‘Readme’ giving details of the project – Project files for supported compilers – Project source code files – Compiler specific ‘library’ output directories • .StellarisWareboardsEVMProjectewarm – IAR • .StellarisWareboardsEVMProjectgcc – CodeRed • .StellarisWareboardsEVMProjectrvmdk – Keil • .StellarisWareboardsEVMProjectsourcerygxx – CodeSourcery • .StellarisWareboardsEVMProjectccs – Code Composer • All project that use the driver library reference – Driver library ‘library’ file from ‘.StellarisWaredriverlibcomplier’ – Driver Library header ‘*.h’ file from ‘.StellarisWaredriverlib’ • Other related files – ‘.StellarisWareinc’ • Device specific headers ‘lm3sxxxx.h’ – ‘.StellarisWareexamplesperipherals’ • Device agnostic software examples Examples
    • 31. Download and Install • Where to get it? – http://www.ti.com/stellarisware – Evaluation Kit CD’s • Installation – Typical Windows Installer program – Default install directory C:StellarisWare
    • 32. NOW YOU GET YOUR KITS  32
    • 33. The Texas Instruments EvalBot Unassembled • Open Your Boxes • Remove the green board  • WE WILL NOT BE ASSEMBLING IN THIS CLASS
    • 34. EVALBOT Assembly- on your own time • Full instructions available in printed form in EVALBOT Kit
    • 35. 1/30/2015 35 Board Set Up • Using the supplied USB cable: – Connect the miniB (smaller) end of the USB cable to the connector labeled “ICDI” on the EvalBot – Connect the larger, USB-A cable to a free USB port on your host PC *Note – Must be connected to a powered USB port/hub • Once connected to PC, press the “ON/RESET” button next to the display • You will be prompted with the Windows Found New Hardware Wizard • Select “No, not at this time” • Click Next
    • 36. 1/30/2015 36 Board Set Up • You will now be prompted from where to install the software • Select “Install from a list of specific location (Advanced)” • Click Next
    • 37. 1/30/2015 37 Board Set Up • Select “Search for the best driver in these locations” • Check “Include this location in the search” • Click Browse and navigate to the FTDI-Stellaris directory created when you unzipped the software package • Click Next This example depicts what it would look like if you unzipped the software into the root of your C: drive.
    • 38. 1/30/2015 38 Board Set Up • Windows finishes installing the drivers for “Stellaris Evaluation Board A” • Click Finish • Windows will automatically prompt you to install “Luminary Micro ICDI Stellaris Evaluation Board B” and “Stellaris Virtual COM Port” • Follow the same instructions as before to install drivers for these devices • If completed correctly all FTDI drivers will be installed, enabling: – Debugger access to the JTAG/SWD interface – Host PC access to the Virtual COM Port
    • 39. INTRODUCTION TO RTOS AND MICRIUM OS
    • 40. Agenda • RTOSs and Real-Time Kernels – A brief introduction • Micriµm - µC/OS-III – Summary of features – Scheduling and Context Switching – Synchronization – Message Passing – Other Services
    • 41. RTOS vs Real-Time Kernels
    • 42. What is a Real-Time Kernel? • Software that manages the time of a CPU • Performs multitasking – ‘Switches’ the CPU between tasks – Highest priority task runs on the CPU – Round-robins tasks of equal priority • Provides valuable services to an application: – Task management – Synchronization – Mutual exclusion management – Message passing – Memory management – Time management – Soft-timer management – Other
    • 43. What is a Real-Time Kernel? Task Event Event Each Task Infinite Loop Task High Priority Task Low Priority Task Task Task Task Task Task Importance Task Task
    • 44. Preemptive Kernels ISR Low-priority task High-priority task ISR Interrupt occurs ISR completes and the kernel switches to the high-priority task Via a kernel call, the ISR makes the high priority task ready The kernel switches to the low-priority task Time
    • 45. What is µC/OS-III? • A third generation Real-Time Kernel – Has roots in µC/OS-II, the world’s most popular Real-Time Kernel • µC/OS-II’s internals were described in the book: “MicroC/OS-II, The Real-Time Kernel” (1998) • A new 850+ page book: – “µC/OS-III, The Real-Time Kernel” – Describes µC/OS-III’s internals – The book comes with: • A Cortex-M3 based evaluation board − Featuring TI’s LM3S9B92 • Links to download: − Sample code to run µC/OS-III − IAR’s 32K KickStart tools − A trial version of µC/Probe – Companion EVALBOT • 4 Example projects
    • 46. µC/OS-III Summary of Key Features • Preemptive Multitasking – Round-robin scheduling of equal-priority tasks • ROMable • Scalable – Adjustable footprint – Compile-time and run-time configurable • Portable – All µC/OS-II ports can be adapted to µC/OS-III • Rich set of services – Task Management, Time Management, Semaphores, Mutexes, Message Queues, Soft Timers, Memory Management, Event Flags and more
    • 47. µC/OS-III Summary of Key Features • Real-Time, Deterministic – Reduced interrupt and task latency • Built-in Performance Measurement – Measures interrupt disable time on a per-task basis – Measures stack usage for each task – Keeps track of the number of context switches for each task – Measures the ISR-to-Task and Task-to-Task response time – And more • Cleanest source code in the industry • Consistent API • Run-Time argument checking
    • 48. Typical µC/OS-III Tasks void MyTask (void *p_arg) { Do something with ‘argument’ p_arg; Task initialization; for (;;) { Wait for event; /* Time to expire ... */ /* Signal/Msg from ISR ... */ /* Signal/Msg from task ... */ /* Processing (Your Code) */ } } Task (Priority) Stack (RAM) CPU Registers Variables Arrays Structures I/O Devices (Optional)
    • 49. ‘Creating’ a Task • You create a task by calling a service provided by the kernel: OSTaskCreate(OS_TCB *p_tcb, CPU_CHAR *p_name, OS_TASK_PTR p_task, void *p_arg, OS_PRIO prio, CPU_STK *p_stk_base, CPU_STK *p_stk_limit, OS_STK_SIZE stk_size, OS_MSG_QTY q_size, OS_TICK time_slice, void *p_ext, OS_OPT opt, OS_ERR *p_err); Task Control Block Task Name Task Start Address Stack Priority Options Time Slice Stack Size Stack Limit
    • 50. The µC/OS-III Scheduler Using Count Leading Zeros (CLZ) •The Cortex-M3 has a CLZ instruction – Makes scheduling much faster … ex. with 64 priorities 0 0 0 0 0 0 00 0 0 0 0 0 0 00 310 0 0 0 0 1 1 00 1 1 1 0 1 1 11 [0] [1] 32 5 Ready Priority = 37 32 63 if (ReadyTbl[0] == 0) Prio = CLZ(ReadyTbl[1]) + 32; else Prio = CLZ(ReadyTbl[0]); ReadyTbl[] Zeroes
    • 51. The µC/OS-III Ready List Multiple Tasks At Same Priority Lowest Priority Highest Priority
    • 52. Context Switch ARM Cortex-M3 for µC/OS-III • (1): Current task’s CPU registers are saved on current task’s stack • (2): CPU’s SP register is saved in current task’s TCB • (3): New task’s SP is restored from the new task’s TCB • (4): CPU registers are restored from the new task’s stack
    • 53. Resource Management (Mutual Exclusion Semaphore) Delta TS
    • 54. Synchronization (Semaphores) Delta TS
    • 55. Synchronization (Event Flags) Delta TS
    • 56. Message Passing (Message Queues) Delta TS
    • 57. Other µC/OS-III Features •Task Management – Suspend/Resume a task – Delete a task •Time Management •Software Timers •Fixed-Size Memory Partitions •Pending on Multiple Objects •And more.
    • 58. EXAMPLE: SIMPLE DISPLAY
    • 59. Simple Display Example • The following example introduces the concept of tasks by displaying various strings on the OLED display on a rotational basis. The example uses the two tasks listed below: • Display Task shows one of three messages for 5 seconds, clears the display for 1 second and displays the next message Start Task Display Task Pushbuttons and Bump Sensors Displays Speakers LEDs EVALBOT Board • Start Task initializes the timer and LED status such that the LED toggles once per second
    • 60. Open Example Workspace • File->Open->Workspace… • MicriumSoftwareEvalBoardsTILM3S9B92-EVALBOTIAR
    • 61. Set uCOS-III-Ex1 to be active project • Right Click on project name in the workspace pane • Select “set as active”
    • 62. Project Structure •Click on the ‘+’ next to project Name, or double click project name to expand project files structure.
    • 63. Open app.c •Double click on the ‘app.c’ file to open.
    • 64. main () in app.c Disable all interrupts to the CPU Initialize the µC/OS-III operating system Create the AppTaskStart task Start multitasking (i.e. – give control to µC/OS-III
    • 65. Startup Task *Note – You MUST start multitasking before initializing the ticker These lines of code are used to set up the SysTick timer built into the Cortex-M3 core Initialize the µC/CPU services Initialize CPU peripherals and signals used with the LM3S9B92 Enable & reset the Ethernet controller Power down PHY Determine nbr SysTick increments Determine SysTick reference frequency Initialize µC/OS periodic time source
    • 66. Startup Task Cont’d Delays task to cause code to execute every ~1 sec Compute CPU capacity Initializes amount of time interrupts are disabled Initializes the µC/Probe modules Initializes on-board LEDs Initializes other task and objects used Task body – nearly always an infinite loop Toggles LEDs once per second
    • 67. Robot Display Task Set the inifnite loop for this task Delays task to cause code to execute on periodic basis Rotates through screen display options (cases 1-5)
    • 68. Set a breakpoint in Startup Task Double Click to the left of line where breakpoint is desired
    • 69. Set a breakpoint in Display Task Double Click to the left of line where breakpoint is desired
    • 70. Download and Debug Example 1 • You must connect EVALBOT and be sure the EVALBOT Power is ‘ON’ Click the download and debug button. IAR will build as needed then start debug
    • 71. Debug Mode DisassemblyC Code Debug Log Debug controls Project Explorer
    • 72. Select ‘GO’ Command from debug toolbar •Selecting the ‘GO’ icon will release the CPU and let it run freely until a breakpoint is hit
    • 73. Breakpoint Hit •The first breakpoint is hit in the Startup task •Click ‘GO’ again to continue code execution
    • 74. Breakpoint Two Hit • Now we have progressed in the code execution and come to the second breakpoint • Note that this is in the display task which is never directly or indirectly called from the startup task. The OS is switching between the tasks • Rinse, lather, repeat
    • 75. EVALBOT Display Next Steps • For more information on how to use the OLED display… – Examine bsp_display.c – For simple displays this type of low level driver is usually sufficient – For more complex displays (DK-LM3S9B96) a driver like this one is built by the user as an interface between Graphics Library and the physical display
    • 76. That’s all we have time for! Thank you! For the remainder of the examples and copy of this presentation, please make sure to leave your email address with us! 1/30/2015 “TI Proprietary Information - Strictly Private” or similar placed here if applicable 76
    • 77. BACKUP
    • 78. Using Audio with the EvalBot
    • 79. Audio Demo Overview • The following example demonstrates how µC/OS-III, in conjunction with the EvalBot, can be used to create an audio control application: • Several small audio tracks are loaded into the LM3S9B92 microcontroller’s Flash memory – Sound driver supports most WAV file formats – Combined file size must not exceed 200kB • Bump sensors are used select an audio track: – Left bump sensor – previous track – Right bump sensor – next track • Two user pushbuttons control audio playback – “SWITCH 1” begins audio playback – “SWITCH 2” stops audio playback • When audio is playing, EvalBot flashes on-board LEDs at a 5Hz rate to indicate that audio playback is active • OLED display shows title of current track, defined by the user, and time status
    • 80. EVALBOT Audio Demo Tasks •AppTaskRobotStart – low level init and creation of other tasks then resume/suspend of LED Playback task. •AppTaskRobotAudioPlayback – play WAV files through the TLV320AIC3107 Audio CODEC •AppTaskRobotInputMonitor – monitor button and bump sensor events •AppTaskRobotDisplay – display track title and playback status on display •AppTaskRobotPlaybackLED – blink LEDs while playback is active
    • 81. Initializes timer Start, stop, previous, and next track Starts or stops toggling LEDs Controls data on display Relays UI info to Control Flag Group Flag for Pushbuttons, Bump sensors, and timer
    • 82. Open EVALBOT Workspace •Open the EVALBOT Workspace: File->Open- >Workspace… – MicriumSoftwareEvalBoardsTILM3S9B92- EVALBOTIAR • Set uCOS-III-Ex2-Flash to active – Right Click on Project -> Set as Active – Double Click app.c to open the main user file
    • 83. main () in app.c Disable all interrupts to the CPU Initialize the µC/OS-III operating system Create the AppTaskStart task Start multitasking (i.e. – give control to µC/OS-III
    • 84. Startup Task *Note – You MUST start multitasking before initializing the ticker These lines of code are used to set up the SysTick timer built into the Cortex-M3 core Initialize the µC/CPU services Initialize CPU peripherals and signals used with the LM3S9B92 Enable & reset the Ethernet controller Power down PHY Determine nbr SysTick increments Determine SysTick reference frequency Initialize µC/OS periodic time source
    • 85. Startup Task Cont’d Initializes a periodic timer that updates display Wait until playback is initiated by SWITCH2 Resume LED blink task to flash while running Wait for playback to end before suspending LEDs Suspend LED blink task
    • 86. Audio Playback Task Gathers file information and checks for valid file format Plays the WAV file & allocates bandwidth Pend playback until SWITCH 2 is pressed Set pointer to the first WAV file in the list Name the WAV files Get pointers to WAV files from IAR
    • 87. Robot Input Monitor Task Initialize the variables that require initialization
    • 88. Robot Input Monitor Task Cont’d Read and store physical state of the switches Determine the debounced switch state If(top button was pressed) Then stop the audio track If(the right bumper was pressed) Then post a flag, stop audio and go to next track If(the left bumper was pressed) Then post a flag, stop audio and go to previous track If(bottom button was pressed) then post a flag which will start track
    • 89. Display Task Displays TI screen at startup Clears screen Determines file name length Displays file name on the screen Displays Zero play time when nothing is playing Updates track info when play button or bump sensor is hit
    • 90. Playback LED Task Initially suspends this task Initializes LEDs Delays 200 ms in between LED toggles Toggle LEDs at 5 Hz, and update µC/Probe variables
    • 91. Start Audio Breakpoint • Set a breakpoint in the Audio Playback Task. • @ BSP_WaveOpen
    • 92. Flag Post Breakpoint •Set a breakpoint in the input monitor task •Inside the if statement which monitors for the start button
    • 93. Download and Debug Example 2 • You must connect EVALBOT and be sure the EVALBOT Power is ‘ON’ • IAR will download the image and run to main() • When IAR finishs press RUN from the toolbar Click the download and debug button. IAR will build as needed then start debug
    • 94. Begin Debugging Audio •Press ‘GO’ to start code execution •Code will run without hitting breakpoints •Press the bottom user button on EVALBOT (switch 2)
    • 95. Post Audio Start Playback Flag •Pressing the button is detected by the Input Monitor Task •Input Monitor Task POSTS a flag via the Kernel call.
    • 96. Release from Pend on Audio Start Flag •Only after the flag was posted by the Input task do we release from the pend and start the process of playing the wave file.
    • 97. EVALBOT Audio Next Steps •To Learn more about I2S and how to use audio on this system… – Examine bsp_wav.c and bsp_sound.c: bsp_wav.c reads chunks of the wav file from memory and puts into a sound buffer; bsp_sound.c transfers the sound buffer over I2S to the CODEC for output. – Stay tuned: later in this training we will examine how the wave files were inserted into the flash image. •EVALBOT Audio I2S system also shows use of interrupts within the RTOS and uDMA.
    • 98. Autonomous Control of the EvalBot
    • 99. Agenda (Overview) • Demonstrates the use of µC/OS-III with EVALBOT for Autonomous Control • Implemented using motors, bump sensors, and timers – Sensors detect when robot hits something • Once triggered, robot will turn and continue moving – Timer also causes the robot to turn • Important Tasks – AppTaskRobotControl – AppTaskRobotMotorPID – AppTaskRobotMotorDrive – AppTaskRobotInputMonitor
    • 100. AppRobotTaskCreate () • Creates all of the tasks that make up the application • AppTaskRobotInputMonitor – the task to monitor button and bump sensor events. • AppTaskRobotControl - the main control task • AppTaskRobotLeft(Right)MotorDrive – the left (right) motor control task • AppTaskRobotLeft(Right)MotorPID – the left (right) motor PID controller task.
    • 101. Control Task queues commands to motor tasks Motor Tasks receives command, interprets and posts to PID Task PID Task closes motor control loop based on feedback from speed sensor interrupt handlers Speed sensor interrupts relay data back to PID Task If Timer expires a random turn is initiated Input Monitor Task posts flags to Control Task buttons and Bump Sensor trigger Input monitor task
    • 102. AppTaskRobotInputMonitor • Reads and stores state of pushbuttons and bump sensors – Debounces pushbuttons and bump sensors • Posts flag to Robot control Task if pushbutton or bump sensor is triggered • Lets main task loop execute every 5 ms.
    • 103. AppTaskRobotInputMonitor Sets the infinite loop Seeds the random number generator Delays task by 5 ms to let main task execute every 5 ms Reads and stores current state of pushbuttons and bump sensors Debounces pushbuttons and Bump Sensors Adds current time to random number generator’s entropy pool Checks if pushbuttons or bump sensors are hit
    • 104. AppTaskRobotInputMonitor Posts the pushbutton flag to the Robot Control Task Flag Group if a pushbutton is pressed Posts the right bump sensor flag to the Robot Control Task Flag Group if it is pressed Posts the left bump sensor flag to the Robot Control Task Flag Group if its pressed
    • 105. AppTaskRobotControl • The main control task • Sets the Driving forward state – Drives until pushbutton, bumper, or timer hit • When triggered, robot turns • Defines Turning States – Turns until pushbutton, bumper, or timer
    • 106. AppTaskRobotControl Sets the initial value of the drive time window that will cause the robot to make a random turn Sets the Robot Control Task state to idle Sets an infinite loop Switches EvalBot’s state based on the current state. Defines the idle state
    • 107. AppTaskRobotControl Defines the drive forward state Defines the driving forward state
    • 108. AppTaskRobotControl Defines the turning state Defines the turn left state Defines the turn right state
    • 109. AppTaskRobotMotorDrive • Waits to receive a message from Drive Task Queue – Drives accordingly after the message – Drive Task Queue gets message from Motor Control Task, or PID • Motor Drive sets a flag to move or stop – Flag is relayed to PID task • Allows motor to change speeds – Clears actual speed value, and sets desired value
    • 110. AppTaskRobotMotorDrive Pends until a message is received Initializes which motor this task is intended for (left or right) Sets an infinite loop for this task Switches based on message type (defined by first byte) Sets the motor drive start message from the Robot Control Task
    • 111. AppTaskRobotMotorDrive Sets the motor drive message from PID task Sets the motor drive stop message from Robot Control Task
    • 112. AppTaskRobotMotorPID • The motor PID controller task – Controls the speed of each motor – Corrects if one goes too fast/slow – Keeps robot moving straight • If actual speed ≠ target speed – Motor slows down or speeds • Equality is checked every 10 ms • Task created for each motor
    • 113. AppTaskRobotMotorPID Sets the state of the Motor PID task to idle. Initializes which motor this task is intended for (left or right) Creates the flag group for this task Sets an infinite loop Defines the idle state Switches EvalBot’s state based on current state
    • 114. AppTaskRobotMotorPID Defines the running state Defines the start state
    • 115. AppTaskRobotMotorPID Defines the payload of the Queue message to be fed back to the Motor Drive Task Post the message to either the left or right side Motor Drive task
    • 116. Set Breakpoint •Just after the OSFlagPend call in the RobotControl Task – Place the breakpoint as shown
    • 117. Download and Debug Example 4 • You must connect EVALBOT and be sure the EVALBOT Power is ‘ON’ • Make sure the uCOS-III-Ex4 is the “active” project Click the download and debug button. IAR will build as needed then start debug
    • 118. Run Autonomous Control Example •Press the ‘Go’ button on the debug toolbar •Press the top user switch to drive forward (Switch 1) •May want to pick the EVALBOT up to prevent it from running away
    • 119. Trigger breakpoint • While the robot is driving forward… • Press the right (or left) bumper • Breakpoint is triggered
    • 120. Single Step through Control Task logic • Use the Step Over command to step through the EVALBOT control logic • Notice how the application gets the flag values from the RTOS – Logic will progress out of the DRIVING_FORWARD state to the TURN_RIGHT state, then to the CONTROL_TURNING state • Follow the logic through to next OSFlagPend, Step again. RTOS controls motors via other tasks while this task pends.
    • 121. EVALBOT Autonomous Control Next Steps •Radio Control – TI RF Evaluation modules are available for the EM socket on EVALBOT – www.ti.com/stellariswireless has examples and kits •Connectivity – USB, Ethernet, SD Card •Noisy Robot Fun – Why not make crashing noises when the bumpers are contacted? – Final hands on example will do just this…follow along.
    • 122. Hands On Project Adding Audio to EVALBOT Autonomous Control Example
    • 123. EVALBOT Hands On Objectives • Add audio sound effects from Example 2 into the Autonomous Control Example 4 – Demonstrates adding wave files to the flash image – Demonstrates adding a new task to a project • Setup of the Task Control Block • Setup of the Task function • Setup of the Task Stack • Task creation and running • Modify the new task and existing code to perform added features.
    • 124. Step 0: Open Example Workspace • File->Open->Workspace… • MicriumSoftwareEvalBoardsTILM3S9B92- EVALBOTIAR
    • 125. Step 0: Open Example Workspace • Set Ex4 as the active project
    • 126. Step 0: Open Example Workspace •Open Files app.c and app_cfg.h from both example 2 and example 4 Tip: Hover over file tab to determine which copy of the file you are viewing
    • 127. Step 1: Adding wave files •Add the wave files to the linker config – Right Click on the Project -> Select Options – Go to Category: Linker -> Extra Options tab
    • 128. Step 1: Adding Wave Files --image_input --keep • Add these two command line options for each wave file • See “IAR Linker Settings.txt” file distributed with this presentation
    • 129. Step 1: Adding Wave Files • Now we need to access the wave files from C code Paste to Example 4 app.c Copy From Example 2 App.c
    • 130. Step 2: Setup a New Task A new task needs… A Task Control Block A Stack A Task function A priority (can be shared in uC/OS-III)
    • 131. Step 2: Setup New Task •Open app.c in Ex4 •Every Task needs a Task Control Block •On or about line 101 add a new TCB – static OS_TCB AppTaskRobotAudioPlaybackTCB – Can be copy/pasted from app.c of example 2
    • 132. Step 2: Setup New Task • Open app.c in Ex4 • Every Task needs its own stack • On or about line 112 add a new stack – static CPU_STK AppTaskRobotAudioPlaybackStk[] – Use APP_TASK_ROBOT_AUDIO_PLAYBACK_STK_SIZE Which we will define later as the size of this array. – Can Be Copied/Pasted from app.c example 2 line 63
    • 133. •Copy the AppRobotAudioPlaybackTask •From: Lines 217 through 256 from example 2 app.c •To: About line 812 of app.c in example 4 (between existing functions) Step 2: Setup New Task
    • 134. Step 2: Setup New Task •Create an instance of the new task by calling OSTaskCreate •Copy the OSTaskCreate call from app.c in Example 2 Lines 475 through 487 •Paste into app.c in Example 4 at line 1535
    • 135. Step 2: Setup New Task •Our new task stills needs an assigned priority level and a defined stack size – Recall we declared a stack with a size but did not define the size – Recall our OSTaskCreate call assumes a priority we have not yet defined. •Open app_cfg.h in example 4 •Copy from line 47 and 61 from app_cfg.h in example2 •Paste to lines 52 and 67 of app_cfg.h in example 4
    • 136. •The two lines to be copied from example 2 and pasted into example 4 •Priority should be changed to a lower priority in our new task – Priority 6 (same as ex 4 display) makes sense, uC/OS- III will round-robin Step 2: Setup New Task
    • 137. Step 3: Modify the Application •We want different sounds for each of the two user buttons on the board – Currently the code only posts a flag that one of the two user buttons is pushed – We will create, post and pend on new flags. •We want a different sound for each of the two bump sensors – We will modify the new Audio Playback task to implement this functionality •We want to maintain all of the robotic functionality
    • 138. Step 3: Modify the Application •Define two new flags as a part of the AppRobotControlFlagGroup – #define FLAG_USER_BUTTON_1 (OS_FLAGS)0x0010u – #define FLAG_USER_BUTTON_2 (OS_FLAGS)0x0020u •Note that flags are typically passed as bits that are set or cleared
    • 139. Step 3: Modify the Application In the AppTaskRobotInputMonitor … Revised Current
    • 140. Step 3: Modify the Application •In AppTaskRobotAudioPlayback •Add a new OS_FLAGS Variable declaration – This is to capture which flags caused the task to wake/resume •Delete strcpy function call – Was used to display current wave title on display – Not used in our new merged application
    • 141. Step 3: Modify the Application Add Pends for each of the four flags we want to play audio for. Delete the Pend on FLAG_PUSH_BUTTON
    • 142. Step 3: Modify the Application •Add a call to get the Flags that were posted • Add if statements to catch each flag
    • 143. Step 3: Modify the Application •CUT The BSP_WaveOpen and BSP_WavePlay calls from just below these lines of code. Paste them into each of the new if statements About lines 873 and 875 – Modify the array index as shown
    • 144. Step 4: Miscellaneous 1. Open “includes.h” via IAR – Add #include <string.h>
    • 145. Step 5: Compile, Download and Debug
    • 146. TI EvalBot and Micrium µC/OS-III Conclusion & Overview
    • 147. StellarisWare Reference Software •StellarisWare = Royalty-free source code for use on TI MCU’s – Peripheral Driver Library – Graphics Library – USB Library – IQ Math Library – Wireles – In System Programming – 3rd Party Extensions – Examples
    • 148. µC/OS-III Overview •Real-Time, Deterministic – Reduced interrupt and task latency •Built-in Performance Measurement – Measures interrupt disable time on a per-task basis – Measures stack usage for each task – Keeps track of the number of context switches for each task – Measures the ISR-to-Task and Task-to-Task response time – And more •Cleanest source code in the industry •Consistent API •Run-Time argument checking
    • 149. Texas Instruments EvalBot Overview “Bump” Sensors (2) User Switches (2) I²S Audio Codec w/ Speaker Stellaris LM3S9B92-IQC80 USB-Device Connector USB-Host Connector MicroSD Socket 96x16 Blue OLED Display ON/OFF Switch DC gear-motors (2) EM2 Expansion Header (compatible w/ TI Wireless Evaluation Modules) In-Circuit Debug Interface (ICDI) Battery Power (3 AA) or USB
    • 150. Simple Display Example • Display Task – Rotates through 3 messages Displays strings on the OLED display using two tasks Start Task Display Task Pushbuttons and Bump Sensors Displays Speakers LEDs EVALBOT Board • Start Task – initializes the timer and LED status – LED toggles once per second
    • 151. Using Audio •Audio Control application with EVALBOT and µC/OS-III: •Audio tracks loaded into onboard Flash – Most WAV file formats are supported – Combined file size must not exceed 200kB •Bump sensors select audio track: – Left bump sensor – previous track – Right bump sensor – next track •Pushbuttons control audio playback – “SWITCH 1” begins audio playback – “SWITCH 2” stops audio playback •On-board LEDs flash at 5Hz when audio is playing
    • 152. Autonomous Control • Demonstrates the use of µC/OS-III with EVALBOT for Autonomous Control • Implemented using motors, bump sensors, and timers – Sensors detect when robot hits something • Once triggered, robot will turn and continue moving – Timer also causes the robot to turn • Multitasking approach 1. Input Monitor task monitors inputs from pushbuttons and sensors 2. Relays info to the robot control task using flags 3. Relays to motor drive tasks 4. Talks with PID tasks to adjust speed • Task List – AppTaskRobotControl – AppTaskRobotMotorPID – AppTaskRobotMotorDrive – AppTaskRobotInputMonitor
    • 153. Hands On Project •Merged Audio and Autonomous Control Examples •Added Audio files to the flash image through IAR •Added a new task without disturbing existing functionality – RTOS allows code to be compartmented – Demonstrates adding a new task to a project • Setup of the Task Control Block • Setup of the Task function • Setup of the Task Stack • Task creation and running • Modify the new task and existing code to perform added features
    • 154. For More Information Thank You • http://www.ti.com/evalbot • http://www.ti.com/stellaris • http://www.ti.com/lm3s9b92 • http://www.micrium.com • http://www.iar.com • Your Local AVNET or Texas Instruments representative
    • 155. EVALBOT Assembly
    • 156. EVALBOT Assembly • Full instructions available in printed form in EVALBOT Kit
    • 157. Cut out the board components
    • 158. Assemble motor sub-assembly •Required for proper operation of wheel encoders 1/30/2015 “TI Proprietary Information - Strictly Private” or similar placed here if applicable 159
    • 159. Wheel Assembly
    • 160. Attach Wheel/Motor Assembly to EVALBOT
    • 161. Attach EVALBOT Bumpers •Bumper should be snug but move freely
    • 162. Attach Motor Wires – Assembly Complete