In an earlier tutorial I introduced using I2C with the NXP LPC55S69 on OKdo E1 board to read a Bosch BME280 environmental sensor on a Mikroe Weather Click board. The MCUXpresso Clocks, Pins and Peripheral Config tools were used to get it running. It’s all for my Weather Station project that I’ve been working on during these months of lockdown. It is starting to take shape – as you can see from the photograph:
Now I really need to start reading and writing to the BME280 sensor, and that means using the I2C driver in the lpcxpresso55s69 SDK. And so this week I’ll provide a forensic examination of the most commonly-used I2C function call.
I selected the Bosch BME280 environmental sensor as the heart of my OKdo E1-based weather station. It is convenient to use, and I can prototype with the Mikroe Weather Click board MIKROE-1978. But the sensor is accessed over I2C, and that is my least favourite of the communication interfaces. In this short tutorial, I show you how the MCUXpresso Config tools (Pins, Clocks, Peripherals) are used to set up the I2C driver from the MCUXpresso lpcxpresso55S69 SDK. And very quickly, I am able to communicate with the BME280 sensor.
I’m using the VL6180X ToF (Time-of-Flight) sensors successfully in different projects. The VL6180X is great, but only can measure distances up to 20 cm and in ‘extended mode’ up to 60 cm. For a project I need to go beyond that, so the logical choice is the VL53L0X which measures between 30 cm and 100 cm or up to 200 cm. For this project I’m using the VL53L0X breakout board from Adafruit, but similar products are available e.g. from Pololu.
I’m pleased to announce a new release of the McuOnEclipse components, available on SourceForge. This release includes several bug fixes, extra support for the NXP S32 Design Studio and SDK and includes FreeRTOS V10.1.1.
I’m pleased to announce that a new release of the McuOnEclipse components is available on SourceForge. This release includes several smaller bug fixes and initial component support for the NXP S32 Design Studio and SDK.
It’s April Fool’s Day, but be assured this is not a joke ;-): I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge. This release includes several smaller bug fixes and components have been upgraded for FreeRTOS V10.0.1.
University research projects can be a lot fun, and are very challenging the same time. The good thing is that there is always someting new to learn :-).
This week-end I was working on my Internet of Things (IoT) project, based on a Freescale KL15Z and a nRF24L01+ transceiver. In essence it is a wireless data logger. For this, I only can afford a few micro amps consumed by the whole board over an extended period of time. I mean 21 micro amps for running a whole board with sensor, EEPROM, wireless transceiver, operating system and an ARM Cortex-M0+ ready to crunch numbers at 20 MHz 🙂
21 micro amps for wireless sensor node (when not sending)
I probably would have missed the fact that Freescale has released a new Freedom board, if I would not have visited my local distributor site to order a replacement for one of my first FRDM-KL25Z boards. So surprise, surprise: there is a new Freedom board: the FRDM-KL26Z!
So instead ordering again a FRDM-KL25Z, I decided to order that new FRDM-KL26Z instead. And it arrived right before Christmas, and now I had time to check it out. Nope, I did *not* use it as a blinking gadget on a Christmas tree, even if that would have been a nice idea ;-).
The good thing with the internet is: it allows engineers to collaborate. And here is an example: Marc is a reader of this blog had a problem with the I2C hardware of a Freescale Kinetis ARM microcontroller. In his case, the I2C bus could be stuck, and there seems no way to reset it with the I2C hardware on the microcontroller. So a solution would be to reset it with software instead.
For many projects I need to store configuration or sensor data. For this I’m using either an SD card or program the internal flash memory of the microcontroller. Using the internal flash is a good thing as it does not need an external component. However, the typical number of programming cycles is limited to 10k-50k which is a limiting factor if data has to be recorded over a long time or very often. That’s why I’m using the very popular external 24xx external EEPROM devices from Microchip.
Not everyone is familiar with Git, and not everyone wants to use it. Although I think using Git or SVN is something every software engineer today needs to master 😉 To make it easier for the ‘non-Gitter’ to use the Processor Expert components, they are available now as *.PEupd files as described here. However, the *.PEupd files are just a snapshot, and not the latest and greatest. So how to use the latest component sources and example projects without Git?
If you are a frequent reader of this blog, then you know: I’m a big fan of Processor Expert components. While there are many Processor Expert components delivered with CodeWarrior, it lacks many components and device drivers beside of the normal on-chip peripherals. But value gets added to an embedded project with all the external devices, sensors and actuators. That’s why I have created many more components which are available on my GitHub site. Readers of this blog have asked several times to create a tutorial on how to create a Processor Expert component. So why not working on that on a long Easter weekend full of cold rain and snow?
So here we go: a tutorial how to create a Processor Expert component for the MMA8451Q accelerometer found on the FRDM-KL25Z board: