Messaging Strategies for a Remote Temperature and Pressure Monitor

Transcription

1 Messaging Strategies for a Remote Temperature and Pressure Monitor BY Donnie Garcia - Applications Engineer Semiconductor 6501 William Cannon Austin, TX United States Donnie.Garcia@.com Web Site:

2 Page 2 Abstract In consumer applications a multitude of drivers, sensors and other peripheral ICs must be used to accomplish the end purpose of the system. Data and commands must be transferred to and from these devices and handled by the microcontrollers (MCUs) involved. This document provides a good example of how a system of drivers, sensors, and other peripherals are linked together to accomplish a remote temperature and pressure monitoring device. SPI, SCI and radio frequency interfaces and data management using both assembly and C code are explored. The temperature and pressure monitoring device provides an excellent venue to address this subject. The device consist of 2 MCUs, a UHF transmitter, a UHF receiver, a temperature and pressure sensor, a SPI controlled octal switch, and the device is controlled by a GUI run on a PC through SCI communication. A systematic approach to interfacing these devices is critical to having a short development time and the various methods outlined in this document should be helpful to a developer of consumer applications. Background Present day consumer applications are complex devices accomplishing a wide variety of tasks. This is clearly seen for the case of creating a remote Temperature and Pressure Monitor System (TPMS), a device that consist of 2 MCUs, a UHF transmitter, a UHF receiver, a temperature and pressure sensor, a SPI controlled Octal switch, and is controlled by a GUI run on a PC through SCI communication. The interconnectivity of these devices is critical to this application. An important component of every system design is handling the communications between the multiple peripherals that are used to accomplish the goals of the end application. Complex goals of an end application lead to more peripherals that must be connected together through communications. In the TPMS sensor data must be relayed to an MCU that then must format the data for UHF transmits. Then a UHF receiver receives the data and sends it to another MCU that will parse this data and present it to a GUI on a PC. Different communications protocols, methods and data rates must be implemented in this system. Communications is critical for this application because if data can not be shared between the sensors and drivers in the system the required tasks could get done. The TPMS project was created to showcase a new UHF transmitter and MCU multi-chip module. This device contains a UHF transmitter and an HC08 MCU in the same package. During the course of this project it was found that the methods and processes that were implemented would be useful information to any designer. If the proper steps are taken design time can be reduced. When addressing a complex system as the TPMS using tools such as C code and taking the steps such as documenting the messaging requirements is critical. In this project, as is common in many projects, different people were charged with creating code for the different parts of the system. This 2

3 Page 3 led to different programming languages and different development environments being used. Careful planning can make the execution phase of the project easier and reducing design time allows faster time to market and will affect the bottom line. The information provided in this paper will offer tips and direction that can be used when creating a complex system like the remote temperature and pressure monitor. Novel ways to utilize C code and other methods to ease the interconnectivity of the project are addressed. Before we go into the details about the way communications was designed for the TPMS we must review some background material to have an understanding of the system. The purpose of the Remote Temperature and Pressure Monitor is to provide temperature and pressure data to a central receiver module that can display this data to a Graphical User Interface on a PC. This system is specifically tailored to monitor the tires of an automobile. This system consists of three main hardware blocks: Sensor module with UHF transmitter, Receiver module that receives UHF data and can interface to a PC graphical user interface and low frequency (LF) initiator modules. A representation of this hardware can be seen in the block diagram shown in figure 1. This project was an upgrade of an existing design. Some of the important system requirements include: FSK UHF transmission, SCI communications at a 9600 baud rate and existing code reuse. In the definition phase of the project system requirements were made that affect how the development of this project was done. For example, to meet the code re-use requirement, software development had to be done in both assembly and C code. Remote Temperature and Pressure Monitor Description Figure 1: TPMS Hardware Representation At the core of the complex transmitter and receiver modules is a microcontroller that will be used to process and relay the data. The receiver module contains a MC68HC908GZ16, a microcontroller with a large peripheral set that includes SCI, SPI and CAN modules. The transmitter contains the MC68HC908QF4 is a multi-chip module that contains a much smaller less feature rich microcontroller that does not contain peripherals like SCI and SPI. For this reason the handling of communications for these two different parts varied as will be explained in this document. Typical TPMS Operation In order to grasp all the communications that must be handled in this system we should review a step by 3

4 Page 4 step flow of how typical operation of the TPMS is defined to operate. 1. The user initiates the process by selecting a location to be polled in the GUI. 2. The GUI sends an SCI command to the central receiver module through the serial port of the computer. 3. The Central Receiver module MCU initiates an LF transmit by communicating to a Driver IC through SPI 4. The Transmitter module receives an LF transmission and this is relayed to the Transmitter modules MCU through simple I/O 5. The Transmitter module MCU communicates through software SPI to the temperature and pressure sensor to collect the temperature and pressure data 6. Temperature and pressure data is relayed to the UHF transmitter through software bit banging and transmitted 7. The transmitted data is received by The UHF receiver IC and the data is relayed to the MCU through software SPI. 8. The receiver module analyzes and processes the data and communicates the results to a PC through a Graphical User Interface In every one of the steps above it is clearly shown how important communication is for the processes of this application to occur. Each of these steps will be examined to show the methods used to accomplish the communications. Defining the Messaging Requirements Defining the messages that will be sent between all of the peripherals was an important step of this project. A messaging requirements document was done to show how and what type of messages will be sent. This document became a way for the members of the team to work together to meet the system requirements. Every possible message between the devices in this system was defined in this document so that as the software was being developed it could be referenced as a guide to the software implementation. The time spent creating this document was well spent because when questions arose bout the form or function of bytes in a message they were often answered in this document. This document defined LF transmissions, SCI transmissions, SPI transmissions and UHF transmissions between all of the modules involved. In a complex system such as the TPMS it is critical that a document such as this exist so that development can be eased. Central RX Module To GUI Definition Defining the data that can be relayed from the central receiver module to the GUI was done with the information below. 4

5 Page 5 Sig # Signal Name Signal Description Signal Length (bits) Signal Start Bit Signal Initial Value Raw Value Range Normalized Value Range - <signal_name> - <signal_size> <signal_of fset> <init_value > ID [0:3] 4 Byte Tire Module ID $ Right Front Tire $C1C2C3C4 -Right Rear Tire $ Left Front Tire $ Left Rear Tire $ RKE Data - 4 Pressure Daytona Pressure Data $00 - $FF 0-640Kpa 5 Temperature Daytona Temperature Data 6 Status QF4 Status Data 8 64? 7 Threshold Current Pressure threshold 8 56? $00 - $FF minus C $01-$05 - LED 1-5 on $50 - Status OK $80 - Alarm Mode $40 - LVI Alarm 8 72? $00-$FF - - Sample Frame ID Pressure Temperature Status Threshold Byte Figure 2: Central Rx Module to GUI documentation The table defines not only the length and form of the data but also provides the range of acceptable values for this data and translates the data into the commands that it will represent. When creating the software that handles the communication between the central receiver module and the GUI this information can be referenced and sums up all the cases that must be handled by this software. Defining the data in this way greatly eases the software implementation. In this project communication between the hardware modules (LF, Central RX and Tire module) was defined in this way but communication between on board peripherals was not. This made the implementation of on board communication more difficult. This was recognized because in order to implement on board communications much more time was spent in creating the messages. In order to analyze how communication was implemented for this project we will take each of the above 8 steps that outline typical system operation and explain the implementation for each of these steps. In this explanation we will cover what software implementation was used, assembly or C code. And examine the data handling methods. SCI communication-central Receiver and GUI The first step in typical operation of the TPMS is Central RX Module to GUI communication. Using the messaging scheme defined for this communication the development was done using C code. This simplified the software 5

6 Page 6 implementation because transmit and receive data can be collected using arrays. Arrays offer an easy way to build a data frame and then transmit or receive using this data frame. Implementing arrays in C is quite easy. Defining an array is accomplished with the code shown below. char Receive_Data_array [2]; This defines an array that is 3 bytes in size. The Receive_Data_array is used by the SCI receive interrupt service routine to store the incoming bytes from the GUI. The below routine shows the usefulness of arrays when receiving strings of data. interrupt void SCIR_ISR(void) while(scs1_scrf ==0); Receive_Data = SCDR; if(count > 0) Receive_Data_array[count++] = Receive_Data; if (count == 0) if (Receive_Data == (0xAA 0x55)) Receive_Data_array[count++] = Receive_Data; if(count > 3) count = 0; The routine is called each time a receive interrupt occurs. The count variable is used to count the bytes as they are received and to index the array so that the incoming data is stored in the proper locations. As shown in the ISR the data is parsed by looking at the first byte that is received to see if it matches the defined command structure. If it does not match, the incoming data is not stored in the receive data array. This code snippet is a good example of a typical SCI interrupt service routine. The receive data array is then used by the main program to direct the operation of the central receiver. This is shown below, a simple conditional is used to look at the second byte received in the Receive_Data_array and the transmit variables are set accordingly. if(receive_data_array[1]==0x01) Transmits are accomplished using the variable data_array[7]. This creates a structure in memory that consist of 8 bytes: data_array[0] through data_array[7] that can be accessed using the data_array pointer. This is shown in the below routine that creates the data_array message frame with the message in preparation for a SCI transmit. void CreateFrame(void) //Create Frame data_array[0] = ID0; data_array[1] = ID1; data_array[2] = ID2; data_array[3] = ID3; data_array[4] = Pressure; data_array[5] = Temperature; data_array[6] = Status; data_array[7] = Threshold; 6

7 Page 7 This routine takes the defined variables for ID, Pressure Temperature, etc and places them into their proper locations in the data array. Doing this prepares the data_array so that a simple transmit routine using the indexing of the array will transmit SCI data. The below transmit routine shows how the proper message frame is sent out using the data_array variable. void Transmit(void) char Tx_count = 0x0; while(tx_count!= 0x08) /* Is the transmitter empty? */ while(scs1_tc == 0); /* If no then error */ SCDR = data_array[tx_count++]; /* OK */ The temp variable Tx_count is used to index the array and ensures that all 8 bytes of the message are sent out the MCUs SCI. Arrays allow an easy way to mange and create data. Transmits are accomplished through simple routines as shown above. SPI communication MCU to Octal Serial Switch The next step in the process of this system is initiating an LF (Low Freq) transmit using a serial switch. This implementation of SPI is done using the GZ60 s SPI peripheral and is done in C code. The octal switch implements a very simple data scheme where a single byte of SPI data chooses which switch to enable. To sum it up, a single byte of SPI data is sent out by the MCU to the switch so that the proper output is set. Again using C code makes this an easy implementation. The Update_Switch routine below takes a byte of data, and outputs this data through the SPI. In the code below, a check is done to see if the switch should be toggled, if the switch data is the same as before the switch is turned off by sending a $00 to the high side driver. So to turn on and then turn off switch 1, the Update_Switch routine should be called with $01 in the Switch_Data variable. This makes the MCU send out a $01 then a $00 through the SPI. In the below snippet PTD0 is used as the Slave select signal to the octal switch. The SPI module s registers are written as shown below to accomplish the SPI transmit. //Send SPI Data to High side Switch void Update_Switch(unsigned char Switch_Data) char temp; temp = Switch_Data; PTD_PTD0 = 0; if (SPI_DATA == temp) temp =0; SPI_DATA = temp; SPDR = SPI_DATA; while(spscr_spte == 0); Long_Delay(15); PTD_PTD0 = 1; In order to facilitate the selection of switches, macros are made for each of the five switches as shown below. //High side switch macros 7

8 Page 8 #define Switch1 Update_Switch(0x01); #define Switch2 Update_Switch(0x02); #define Switch3 Update_Switch(0x04); #define Switch4 Update_Switch(0x08); #define Switch5 Update_Switch(0x10); With these macros an update of a switch is done witch a simple function call, Switch1; As shown above the SPI implementation is quite easy when using C code. SPI communication Temperature and Pressure Sensor and the Tire module s MCU The LF signal initiated by the central receiver module wakes the Tire module through a simple KBI interrupt. The LF circuit is a simple RF switch and does not follow any set protocol. The radio frequency signal triggers a circuit that drives a low signal to the tire module MCUs KBI pin. This in turn initiates a state in the tire module that leads to a temperature and pressure reading. To accomplish this reading software SPI communication between the sensor and the MCU is used. In this instance software SPI is done using GPIO, not a SPI peripheral. The MCU on the tire module does not have an on chip SPI. Also this code was done in assembly rather than C code, this leads to differences in this software implementation. The code below is the assembly code routine that generates a SPI message to the sensor. In software SPI routines GPIO are used to represent the clock and the data lines. For each bit of data that is output the GPIO that controls the clock and the data line must be set. As shown below this routine is CPU time intensive. When the MCU is outputting a byte to the SPI bus, it can not complete any other operations. SEND_BYTE: pshx bclr DCLK,PORTB ; Clock is initially low. mov #$08,BITCOUNT ; Initialize number of bits to be sent (1 byte). ldx DATABUFF ; DATABUFF contains the byte to be sent serially SEND_nextbit: ; to Daytona. sec ; Set the carry bit rolx ; Rotate x left and watch the Carry bit toggle. bcs ONE ; Send a '1' if Carry set else bcc ZERO ; send '0' just to be symetric. ONE: bset SDATA,PORTB ; SDATA = '1' bra TOGGLE_CLOCK ZERO: bclr SDATA,PORTB ; SDATA = '0' bra TOGGLE_CLOCK ; again to be symetric TOGGLE_CLOCK: bset DCLK,PORTB ; Shift SDATA state into DAR by toggling clock 8

9 Page 9 bclr DCLK,PORTB dec BITCOUNT ; Determine if there are more bits to be sent. bne SEND_nextbit ; Shift out next bit if we have more bits to send. pulx ; If all bits are sent, restore XR rts ; and return. of the UHF transmitter. This ensures that data is transmitted at the desired data rate. The data being transmitted follows the below frame definition that was created for this application. The byte to be transmitted is examined bit by bit, if it is a one the GPIO pin is set, if it is a zero, the GPIO pin is cleared. The software loops so that all bits are examined and the GPIO pin used as the clock is toggled at the correct time to clock the data out. The example above uses the rolx and the carry bit in the condition code register to make the decision on if the bit is a one or a zero. This routine is very straightforward but as stated above the drawback to a software SPI routine is that it is CPU time intensive. Again in this example the data that has to be sent to the sensor is not very complex, so there is no real messaging scheme where multiple bytes must be defined. It is a good example of implementing software SPI. SPI communication MCU to UHF transmitter Another implementation of SPI that is a bit more complex is the communication between the Tire modules MCU and the UHF transmitter. This interface is also a kind of software SPI, the data is sent serially through a GPIO pin to the UHF transmitter. The UHF transmitter provides a time base that is input to the MCU s timer module. This time base is provided by a clock pin 9

10 Page 10 Signal Name Signal Description Signal Length (bits) Signal Start Bit Signal Initial Value Raw Value Range Normalized Value Range Resolution (units/bit) <signal_name> - <signal_size> <signal_of <init_value fset> > Preamble0 Preamble Constant 8 0 $FB $FB - - Preamble1 Preamble Constant 8 8 $86 $ ID [0:3] 4 Byte Tire Module ID $ Right Front Tire $C1C2C3C4 -Right Rear Tire $ Left Front Tire $ Left Rear Tire $ Spare Tire - - Pressure Daytona Pressure Data $00 - $FF 0-640Kpa 2.5Kpa Temperature Daytona Temperature Data 8 56? $00 - $FF minus C 0.77*C Status QF4 Status Data 8 64? $50 - Status OK $80 - Alarm Mode - - $40 - LVI Alarm CRC Calculated CRC Code 8 72? $00-$FF - - Trash Trash Repeat of CRC 8 80? $00-$FF - - Sample Frame Preamble ID Pressure Temperature Status CRC Trash Byte Figure 3: Transmitter Data Definition Implementing a large message frame in assembly code is not as straight forward as using C code. In the assembly code example below indexed addressing is used to create the message frame. Make_preamble: ldhx #Preamble ; Constant sthx Tx_byte rts Make_device_ID: lda Device_ID sta Tx_byte+2 lda Device_ID+1 sta Tx_byte+3 lda Device_ID+2 sta Tx_byte+4 lda Device_ID+3 sta Tx_byte+5 rts As the example shows Tx_byte is indexed to get all of the critical information into the consecutive RAM locations. The above code snippets show how this is done for the preamble and the device ID. This is similar to the C code snippet that is shown in the above explanation of SCI communications (see Create_Frame routine). These two methods are accomplishing the same task of creating a message in a desired format. Transmitting the UHF message frame is done in much the same way as the Software SPI example above. The difference is that timing is tracked using the MCU s timer and the clock from the UHF transmitter. Each byte is examined bit by bit and a GPIO set accordingly. The change in data is controlled by a timer interrupt; this keeps track of timing 10

11 Page 11 and allows the 9600 baud data rate to be achieved. SPI Communication between the UHF Receiver and the Central Receiver Module MCU The next step in the process of this application is Receiving UHF Data and relaying it to the receiver module MCU. This is accomplished through software SPI. Though the Central Rx MCU contains a SPI peripheral this example is software instead of a hardware implementation. The communications between the UHF receiver and the MCU include MCU to receiver initialization and data transfer once a UHF reception occurs from the receiver to the MCU. In the init Routine the data transfer is accomplished with the code shown below. //Begin Software SPI Routine while( k!= 0x18) k++; //Sending 24 bits k is the bit counter if ((Send & 0x ) == 0x ) PTA_PTA2 = 1; else if ((Send & 0x ) == 0) PTA_PTA2 = 0; //Toggle Clock PTA_PTA3 = 1; //Use this time to shift the data Send = Send<<1; PTA_PTA3 = 0; Send is a predetermined value defined as all the init information that the UHF receiver needs. The value for this application is shown below. Send = 0x77B8C8; In this software SPI routine, Each bit is examined with a conditional then Send variable is shifted so the next bit can be checked. Using this method the number of iterations must be counted to make sure the entire message is transmitted. In this method the number of bytes is not tracked as in the assembly implementation. Receiving of SPI data is done by waiting for the receiver IC to toggle the Clock line. Once this is done the Input GPIO is checked and for every received bit a bit is set in a receive data array and then shifted. //Begin Software SPI Routine while (k!= 0x20) k++; while( PTA_PTA3!= 1); //Wait for rising edge of CLK while( PTA_PTA3!= 0); //wait for falling edge of CLK if (PTA_PTA2 ==1) //Shift in a 1 to recieve data array Recieve = Recieve<<1; Recieve = Recieve 0x ; else if (PTA_PTA2 ==0) //Shift in a 0 to the recieve data array Recieve = Recieve<<1; 11

12 Page 12 Implementing software SPI in this way takes CPU time but has the advantage of using C code to parse the data. Conclusions Complex applications require complex messaging strategies. A systematic approach to interfacing the devices in a system is critical to having a short development time and the various methods outlined in this document should be helpful to a developer of consumer applications. 12