Peripheral Link Driver for ADSP In Embedded Control Application

Transcription

1 Peripheral Link Driver for ADSP In Embedded Control Application Hany Ferdinando Jurusan Teknik Elektro Universitas Kristen Petra Siwalankerto Surabaya Phone: , fax: Abstract Link driver concept proposed by Hilderink is very useful for embedded control application. The reason lies on the fact that one can use the same program in different platform by changing hardware dependent part only. This feature is in the Communicating Threads (CT) Library developed by Control Engineering group, University of Twente, the Netherlands. Therefore, it is necessary to write link drivers for all peripheral in a microcontroller. This paper discusses the implementation of peripheral link drivers for ADSP-21992, 16-bit fixed point DSP from Analog Devices, Inc. The chosen perihperals are Analog to Digital Converter (ADC), Auxiliary Pulse Width Modulation (AuxPWM) and Encoder Interfaace Unit (EIU). For the experiments, these link drivers are applied in controlling the speed of a DC motor with PID controller. The experiments show that using link driver concept, one can build embedded control application easily. Introduction Hilderink proposed separation of hardware dependent and hardware independent in the Communicating Threads (CT) Library [1]. This library is developed by Control Engineering group, University of Twente, the Netherlands. Hardware dependent part consists of two parts, i.e. context switch and link driver. Context switch relates to processor s architecture while the link driver relates to processor s peripherals. This idea is very useful for embedded application, when one wants to use the same program in different platform. One does not need to write the program from the beginning. He only writes the context switch and link driver for the new processors. Therefore, it is necessary for designer to have such a library of all link drivers for microcontroller. This library will help him to develop an embedded application fast. This paper only discusses the implementation of link driver for peripherals in the ADSP The context switch is not discussed here since it is different from the link driver. The ADSP is 16-bit fixed point DSP from Analog Devices, Inc. The link drivers are built for Analog to Digital Converter (ADC), Auxiliary Pulse Width Modulation (AuxPWM) and Encoder Interface Unit (EIU). The implementation uses C language in the VisualDSP environment with object-oriented approach. The CT Library is explained first as the main idea of this implementation. The implementation of object-oriented approach in C language is also discussed briefly. The ADSP as the microcontroller is explained to give a general overview for new user. Three peripherals and their link driver implementation are written separately in order to give detailed explanation how to build them. To try these link drivers for real

2 application, a DC motor is used with PID controller algorithm. This paper is ended with conclusion and recommendation from the implementation and experiments. The CT Library Communicating Sequential Process (CSP) as a formal algebra is very useful to analyze deadlock, livelock and starvation in the program. This concept is proposed by Hoare in 1980s [2]. The CSP programming concept is implemented in the occam programming. The target device is microprocessor, called transputer. When the transputer disappeared from the market. Several occam-like libraries are developed [3,4]. These new libraries are made in the popular programming language such as Java, C and C++. Inside the CT Library, Hilderink proposed separation between hardware dependent and hardware independent part of the program. Hardware independent part is program which does not have relation with hardware at all, e.g. mathematics calculation, bit manipulation, etc. The hardware dependent part consists of context switch and link driver. The context switch relates to processor s architecture, while the link driver relates to processor s peripherals. Therefore, a processor has one context switch and several link drivers, it depends on the number of peripheral on that processor. To move one program from one processor to another, one only changes the hardware dependent part. This is interesting since in the embedded application one can use different processor in one system. Object-oriented in C Language The C language does not support the object-oriented programming. Therefore, Hilderink mimics the behavior of this programming in C [5]. The main idea is to allocate space in memory for an object and clear that memory space when the object is not used anymore. The constructor and destructor must be called manually by the programmer. The object orientation in C only allows single inheritance. The ADSP The ADSP is 16-bit fixed point DSP from Analog Devices, Inc [6]. This chip can be driven with clock up to 160 Mhz, with single cycle per instruction. Several useful peripherals are on chip, i.e. Analog to Digital Converter (ADC), Digital to Analog Converter (DAC), Timer, Encoder Interface Unit (EIU), Auxiliary Pulse Width Modulation (AuxPWM), Digital I/O flag, Serial PORT (SPORT), Control Area Network (CAN) Controller, Serial Port Interface (SPI). Therefore, this processor is powerful not only for Digital Signal Processor (DSP) application but also for general-purpose application. The ADSP comes with an evaluation board called ADSP EZ- KIT LITE. This evaluation board is equipped with VisualDSP++ environment to write, to download and to debug the program. There is USB cable to connect the EZ-KIT LITE with PC. This experiments is carried out with the VisualDSP The EZ-KIT LITE is driver with 16 MHz clock. To use clock higher than 16 MHz, one must use software frequency multiplier. Link Driver To write a link driver for specific peripheral, one must follow the rule as written in the comment part of the link driver class (abstract) in the CT library. The main rule is derived user s link driver from that abstract class. One has to call his user s link driver from link driver class.

3 There are two main method in the link driver class, i.e. read and write. Those methods relates to input and output operation. The directions refer to system s point of view. On the implementation section, this will be explained. The programmer must analyze the peripheral from this I/O point of view. Other methods are isinputready, isoutputready and isexternal. These last three methods only return TRUE. The next step is to study the registers involved in the peripheral s operation. Usually, each peripheral has specific register for the operation. Special location for memory sometimes is also needed. Therefore one should understand the operation inside the processor clearly. The last step is to determine whether there is synchronization or not. The synchronization can use semaphore concept, proposed by Dijkstra [7]. ADCLinkDriver Implementation The output of ADC acts as input for a system. System reads something from ADC. On the other hand, system never gives output for ADC except start conversion command. This is not a value; therefore, ADC has one method only, i.e. read. The ADC in the ADSP is 14-bit ADC and has eight channels. For simplicity, only the simultaneous sampling mode is implemented. The first version of ADCLinkDriver only uses one channel. Before using the ADC, one has to initialize it. This process takes place only once. There are two parameters for setting up the ADC, i.e. clock divider and mode of operation. Last but not least, one has to initialize the interrupt of ADC. Without this interrupt, there is no signal from the ADSP that the conversion is finished. Here is the idea for read method: first, user must give command to ADC to convert its input, then this process is blocked until the ADC interrupt release it. After being released, the process continues by reading the conversion result. Listing 1 shows the complete method for read method. AuxPWMLinkDriver Implementation From the system s point of view, Auxiliary PWM (AuxPWM) receives a value from the system. It means system writes a value to this peripheral. There is no value written by AuxPWM for the system. Therefore, this link driver has only write method. The main idea of Pulse Width Modulation (PWM) is to produce DC voltage by varying the duty cycle of a signal, usually a square wave signal. System only writes a value from 0 to 100. This value indicates the duty cycle of the PWM. The initialization involved in PWM operation is only the frequency of the square wave signal. There is no interrupt in this operation since the AuxPWM unit acts as passive peripheral. AuxPWM uses no synchronization. The implementation is very simple, because system only writes duty cycle value to this peripheral. Listing 2 shows the complete write method in AuxPWMLinkDriver. EIULinkDriver Implementation The Encoder Interface Unit (EIU) receive pulse from encoder. These pulses can be used to estimate the speed of some rotary shaft, to determine the position of some pointer, to estimate the distance between two points, etc. System only reads the result from this peripheral; therefore, from the system s point of view the EIULinkDrive class only has one method, i.e. read. In this experiment, the encoder is used to estimate the speed of a rotary shaft (DC motor). Therefore, the initialization process is

4 to prepare the EIU to estimate the speed of the motor. To estimate the speed of rotary shaft, the EIU loop timer is used. This loop timer gives interrupt pulse every 1ms (user can determine this duration by himself). If there is interrupt from EIU loop timer, the interrupt service routine reads value in the EIU counter and stores it in a buffer. Listing 3 shows the complete program for read method. Implementation and Experiments To test whether those link drivers work well or not, some simple set up should be prepared. The simple plant is the DC motor with PID controller. The main idea is to control the speed of the motor. The block diagram of the system is shown in figure 1. That figure also shows how the link drivers are connected to the plant. The PIDController process reads reference signal or setting point (SP) from channel with ADCLinkDriver and actual speed of the motor or present value (PV) from channel with EIULinkDriver. The result of PID calculation is sent to channel with AuxPWMLinkDriver. Listing 4 shows part of the run method for PIDController process. The goal of the experiments carried out in this paper is to show how simple to use the user s link driver when the system moves from one platform to another one. Therefore the discussion will not go beyond this constraint since the response of the motor depends on the PID controller constants. Figure 2 shows the result of PID controller action to control the speed of the motor to certain setting point. When the PID controller constants are changed the response also changes. DC Motor Response ADCLinkDriver ADSP EIULinkDriver AuxPWMLinkDriver speed (x500 RPM) Ref H-bridge time (ms) Figure 1. Block diagram of the system This project uses CSP programming concept. There are processes, which communicate to each other via channels. There is only one process called PIDController that connects to outside world via three channels. These three channels are for ADC, encoder and PWM. The link drivers used in those channels are ADCLinkDriver, EIULinkDriver and AuxPWMLinkDriver respectively. Discussion Figure 2. Response of the DC motor In listing 4, there is no program relates to the ADSP It is only reading and writing from channels and those channels use link drivers. PIDController process does not care the link driver inside the channel. It only uses the channels directly. When the link driver is changed, the PIDController process only see

5 the channel not the detailed operation inside the channel. This feature is the advantage of using separation between hardware independent and hardware dependent part as proposed by Hilderink. This system can be used in another processor with little modification. The PIDController process remains the same but the link drivers use the link driver for the new processor. The disadvantage of this feature is that the programmer should change the framework of programming style from the old style into CSP style. Conclusions and Recommendations From this experiment, several conclusions can be drawn, i.e.: Separation between hardware independent and hardware dependent part of the program is useful when one wants to move a system from one platform to another. From embedded application point of view, the link driver concept frees user to choose the processor then to write the link driver for its peripherals. This experiment also gives recommendation as follows: It is useful to collect peripheral link drivers for one type of processor as a library. Therefore, for application with that processor, one can use the existing link drivers. The link drivers in this experiment can be developed more complex by adding some feature, e.g. to add selection of operation mode for ADC. Time Distributed Computing ISORC 2000, Newport Beach, CA, USA, [2] Hoare, C. A. R., Communicating Sequential Process, [downloaded from [3] Welch, P. H., Java Threads in the Light of occam/csp, presented at Architecture, Language and Patterns for Parallel and Distributed Applications, WoTUG-21, Amsterdam, 1998 [4] Hilderink, G. H., J. F. Broenink and A. W. P. Bakers, Communicating Threads for Java, presented at Proc 22 nd World Occam and Transputer User Group Technical Meeting, Keele, UK, 1999 [5] Hilderink, G.H. Communicating Thread for C - A White Paper [6] Analog Device Inc., ADSP EZ-KIT LITE Evaluation System Manual, Analog Device, Inc. Digital Signal Processing Division, Noordwood, MA, 2002 [7] Dijkstra E. W., Cooperating Sequential Processes. Programming Languages (F. Genuys, ed.), Academic Press, New York, 1968 Reference: [1] Hilderink, G. H., A. W. P. Bakers and J. F. Broenink, A Distributed Real-time Java System Based on CSP, Proc 3 rd IEEE Int Symp. on Object Oriented Real-

6 Listing 1. ADCLinkDriver::read and its Interrupt Service Routine void ADCLinkDriver read(adclinkdriver me, Object obj,unsigned size){ sysreg_write(sysreg_iopg,adc_page); // set to ADC page io_space_write(adc_softconvst, 1); // start conversion // wait for end of conversion interrupt Processor enteratomic(); Semaphore p(me->sem); Processor exitatomic(); // enter atomic section // wait here // exit atomic section sysreg_write(sysreg_iopg,adc_page); // set to ADC page *(me->buffer) = io_space_read(adc_data1); // read data from ADC register buff. *(int*)obj = *(me->buffer); // put data to the output void ADC0_IRQ(){ unsigned temp; sysreg_write(sysreg_iopg, ADC_Page); io_space_write(adc_stat,0x0100); Semaphore v(semadc); // set to ADC page // clear the interrupt // release the reader Listing 2. AuxPWMLinkDriver::write void AuxPWMLinkDriver write(auxpwmlinkdriver me, Object obj, unsigned size){ unsigned temp; // declare temp variable // only to change duty cycle, no lock and unlock mechanism needed me->buffer = obj; // get the value temp = (unsigned)(*(me->buffer)); // write the value to temp sysreg_write(sysreg_iopg,aux_pwm_page); // set to AuxPWM page io_space_write(aux_cha0,temp); // write the value to register Processor enteratomic(); Processor exitatomic(); // enter atomic section // exit atomic section, will allow // context switch to happen here Listing 3. EIULinkDriver::write and the Interrupt Service Routine for EIU loop timer void EIULinkDriver read(eiulinkdriver me, Object obj,unsigned size){ *(me->buffer) = encoder; // read from buffer *(int*)obj = *(me->buffer); // put the value to the output Processor enteratomic(); // enter atomic section Processor exitatomic(); // exit atomic section void EIU0_Timer(){ sysreg_write(sysreg_iopg, EIU0_Page); // set to EIU page encoder = (unsigned)io_space_read(eiu0_cnt_lo); // store value to buffer io_space_write(eiu0_stat,0x0021); io_space_write(eiu0_cnt_hi,0x0000); io_space_write(eiu0_cnt_lo,0x0000); // clear the interrupt // reset the EIU counter high // reset the EIU counter low

7 Listing 4. Part of run method in the PIDController process me->channel->read(me->channel,sp) me->channel->read(me->channel,pv) me->channel->write(me->channel,action) // PID controller calculation starts // PID controller calculation ends // read from ADC // read from encoder // write to PWM