2017-12-31
In the last review, we have finished the LCD display, and it is time to provide some content. Considering the combination with DAVE, we gave up those sensors with single bus protocol and used BMP180 with I2C interface to complete a simple barometer design. The appearance of the module is shown in the figure below. It is very simple. Just connect the power supply, ground and standard I2C interface. This is an older module. The power supply has 5V and 3.3V to choose from. We use 3.3V directly. In fact, the data sheet says that the maximum IO of bmp180 can only withstand 4.25V. Therefore, when using the Arduino interface of xmc relax, we also use the jumper cap to adjust IOref to 3.3V. A simple test shows that the last LCD still works normally.
Figure 1 Appearance of bmp180 module Bmp180 and the microcontroller are connected by directly using the Arduino interface on the development board. The specific connections are as follows:
The project can be modified directly based on the last LCD. In eclipse, you can directly copy and paste, and then change the project name to get it done. Of course, the driver code to be ported should also be placed in the user directory. Since the display part is already there, just put the bmp180 driver in.
Figure 2 Copy Project The advantage of copying is that the LCD driver is already there, and you only need to add one more I2C_MASTER APP. As you can see in the figure below, the dependency relationship between this APP and SPI is the same, because they both belong to SCU.
Figure 3 I2C dependencies I2C has no particular settings. If you don't want it to be too fast, you can use the default 100KHz clock speed without making any changes. Just assign the pins, as shown in the figure below.
Figure 4 I2C pin configuration The work that needs some time is mainly to transplant the original 51 verified code to xmc4700 for use. I2C transplantation is simpler than SPI because it only involves two buses. However, the bus protocol is slightly more complicated than SPI because SPI uses hardware IO to select the device, while I2C selects the device by writing an address byte (which also contains the designation of read and write operations). At the same time, I2C also includes start and stop timings, which is also more than SPI. If there is no I2C peripheral under 51, all timings must be implemented through IO simulation. In the I2C APP of xmc, all the above factors have been taken into consideration, and writing and reading have been simplified to the following two functions.
- Write: I2C_MASTER_Transmit
- Read: I2C_MASTER_Receive
Of course, the actual situation is not as simple as imagined. Let's take a look at the input parameter list of each function. The first is writing, because no matter reading or writing, it starts with the write timing. Contains the following 6 input parameters:
- I2C_MASTER_t * handle: Generated I2C instance
- bool send_start: Whether to send the start timing, which is required at the beginning of I2C transmission.
- const uint32_t address: Device address, note that it must be moved to the upper 7 bits. See how the device sheet gives the address.
- uint8_t * data: Data address to be sent
- const uint32_t size : Number of bytes sent
- bool send_stop: Whether to send the stop sequence, which is required when the I2C transmission ends
Figure 5 I2C write function Look at the code replacement below. The green commented out ones are 51, and the normal color ones are transplanted. In fact, line 40 replaces the original 3 lines of code, but after the transmission, it is necessary to determine whether the transmission is completed, which is the same as SPI.
Figure 6 I2C write transplant [p=null, 2, After reading the writing function, there is no problem with the reading function. There is one more bool send_nack in the parameter list than transmit. Generally, if the reading process is over, just select true.
Figure 7 I2C read function The transplantation of the read function will be more concise than 51. The green commented out is 51's, 6 lines of code, and it can be done with line 50 in the figure. It is also necessary to judge whether the reading is completed, which is the same as writing.
Figure 8 I2C read transplantation Finally, add a small amount of code to the main function to use the sensor, which is very convenient. Here, in order to facilitate taking pictures, only one pressure acquisition is done in the code, and the code is also relatively casual. If real-time acquisition is required, just put the convert and display codes into the last while(1U).
Figure 9 Main function add code In this way, our eebarometer is completed. Of course, we can't forget to thank xmc and DAVE for their help. It is also displayed on the LCD.
Figure 10 Barometer effect display Summary: In this evaluation, a bmp180 pressure sensor was added based on the last LCD driver, and the I2C_MASTER APP was used to drive the sensor and display the results on the LCD, thus realizing a simple barometer. It can be found that the main advantage of DAVE APP is that it greatly simplifies the configuration and initialization process of the peripherals, allowing users to focus on writing user code. At the same time, DAVE also provides a basic API manual and simple sample code for users to quickly master. However, this also requires users to be familiar with the actual working process of the peripherals. For example, in the transplantation of the bmp180 driver, users still need to have a deeper understanding of the I2C communication process, otherwise the transplantation will still be difficult.
This content was originally created by EEWORLD forum user johnrey. If you want to reprint or use it for commercial purposes, you must obtain the author's consent and indicate the source