Embedded Component Based Programming with DAVE? 3
9Pages

Embedded Component Based Programming By Mike Copeland, Infineon Technologies Introduction Overview of DAVE™ 3 Infineon recently introduced the XMC4000 family of Choosing a microcontroller and software development ARM® Cortex™-M4F processor-based MCUs for indus- tool chain is an important decision with lasting reper- trial real-time control and communications applica- cussions. For a software manager, when a software tions. To accompany the XMC4000 family, Infineon has engineer brings in a new tool chain it can be similarto also released a free, revolutionary software develop- having your son or daughter become engaged. If they menttool chain called DAVE™ 3. do not choose carefully, like the famous TV commer- cial says, you could end up having a "grandson with a DAVE™ 3 has all of the features you would expect from dog collar". an Integrated Development Environment (IDE), such as a code editor, compiler, debugger, etc. What is revolu- One nice feature of DAVE™ 3 is that it can be used for tionary about DAVE™ 3 is the Code Engine (CE). The the complete software development process, or you Code Engine is an automatic code can simply use it to generate drivers or generator designed to enable Compo- pieces of the application while continu- nent Based Programming (CBP)for ingto use yourfamiliar ARM® develop- embedded real-time control. menttool chain forthe rest of the design. In fact, Keil has a plug-in for DAVE™ 3 so This article provides an overview of you can convert your DAVE™ 3 project DAVE™ 3, a brief introduction to CBP into a Keil MDK-ARM™ project with the and how it differs from Object touch of a button. Still, to ease any con- Oriented Programming, and demon- cerns you might have about a new tool strates how DAVE™ 3 handles the chain, let's take a close look at DAVE™ 3 special requirements for embedded and get to knowthe family.

DAVE™ 3 comes from a long line of Inneon development tools. Figure 1 shows the DAVE™ Family Tree. In the late 1990’s, the rst version of DAVE™ was released. The rst version, along with its successor DAVE™ 2.1, was primarily a code generator targeting Inneon MCU peripherals. DAVE™ 1 and 2.1 gave the users a GUI representation of the MCU and each of its peripherals. The GUI settings were used to generate C code for initialization and drivers for use during runtime. DAVE™ 1 and 2.1 could, for example, generate functions to start an ADC or transmit a CAN message. DAVE™ DRIVE was introduced to...

To facilitate reusability, the interface and use of the Component must be well-dened. This allows you to consider the Component to be a black box and ignore how the Component is implemented. If you are like me, the black box analogy automatically raises red ags. Bad experiences when buying pre-compiled object code, or paying extra for source code and documentation, come to mind. With DAVE™ 3 you do not generally need to be concerned with how the Component is implemented (i.e., you can treat it like a black box). However, the DAVE™ team has been very careful to include all the required...

Embedded CBP The Hex2ASCII() function from college works so well as a reusable software component because its inputs and outputs are well-dened and because its operation is not xed to any specic hardware. The other Components from our example in Figure 2 are not quite so simple because they must interact with hardware. This has been an impediment to using CBP in embedded systems. A signicant portion of the software in embedded systems must make use of on-chip peripherals or other hardware resources. Any time software must interact with hardware, you can lose a certain amount of reusability....

DiVl Mug tfmlow Help Using DAVE™ 3 for eCBP Instead of devoting a lot of time and space explaining the theory behind eCBP, it is much easier to look at an example of how DAVE™ 3 handles Components that require hardware resources. In DAVE™ 3, Components are called DAVE™ Apps. Figure 4 shows a simple project that uses DAVE™ Apps to take incoming data from a UART interface and OLED display that is DAVE™ Apps appears things like generating a server. Double clicking Apps in this window in- serts them into the Apps that are being This example uses a total of seven DAVE™ Apps. Only DAVE™ Apps were...

only thought of a Compo- nent as being a piece of is more than just C code. contain a User Interface A feature of DAVE™ Apps tation provided via help files. Figure 6 shows the home help page forthe The help files include all At this point, if we were to ate code, the solver would choose which USIC mod- ules, USIC channels and I/O pins are used forthe In many cases the hard- ware designer may have already selected the pins that should be used. r DAVE CE - OUtrtVDAVEVPwre^ar^^ ■ PAVE i Filt Edit tjsvigste S*inh Prcjtn DAVE Debug Run Window Help fl'IS _|B9u tfr . H fci * ^ • ~ 9 B a fr TASKING...

Fitter SPBOl/O Figure 7: Manual Pin Assignment window for the SPI DAVE™App For example, if I want to run our UARTto Display appli- cation on a starter kit, then I must select the SPI pins that are physically connected to the display IC. DAVE™ 3 allows you to do exactly this. By right click- ing on the SPI DAVE™ App, you can select "Manual Pin Assignment" and force the Solver to only select SPI channels that meet these constraints. pins that are chosen by Mapping Information may have seen in FPGA development tools. After Appsthat your applica- The Solver then assigns play example includes...

Another option would RTOSApp(e.g., Keil/ periodic thread that checks the UART FIFO that has been received. This would probably be handle this simple ap- time a byte is received Nested Vectored Inter- rupt Controller DAVE™ ceive Buffer Interrupt" virtual signal to it. Then we would simply call show these steps. Figure 9: Connecting the UART FIFO Receive Buffer Interrupt virtual signal to the £iie £dit ^.ivigile Search (reject DAVE Debug £un y^nnow jjdp ! n * M ® t& I *T QK j& ffij L f » DAVE CE 1 □ DAVE 106 // convert frem 16>bit to char // Pwl*r.»tio« Of return variable for DAvEJ APIi...