Saturday, May 27, 2017

Your map may be old and you'll get lost

The actual version of the HAL drivers in OpenSTM32 IDE for my board is 1.6.0 and the last official ST version is 1.7.0. So, I thought I may update it myself, how hard may be that (I had to do it anyway, as I did the upgrade also for STM32CubeMX)? And I did it, replacing the HAL drivers as there are no files extra or less - direct replacement for every header and source file. Easy.

But I got errors at compilation so I went to the ST community to ask questions. The suggestion was to include a specific device file. A device file that was already included. The error showed that there a definition was missing... So I compared the device files between the versions to find out that there some definitions were changed in name.

Then the conclusion was obvious: is not enough to replace the HAL drivers by hand, you have to do it also for the CMSIS drivers (where the device files are stored). It seems that ST suffers from the same symptoms as Microchip...

See the discussion here.

Wednesday, May 10, 2017

Preparing the trap for time...

Update May 12, 2017: The HAL libraries regarding I2C peripheral are just stupid! Their unneeded "simplification" gives me headaches. I'm not a newbie, you know? Well, more likely I'll use the HAL Low Layer drivers for this one...It seems that the mixed use is allowed (Chapter 4 of "Description of STM32L1 HAL and Low-layer drivers")

Original article: Just a quick note. I'm preparing for the PCF8583 RTC library which use the I2C peripheral (is the only device I have that use the I2C). This library is well tested with PIC microcontrollers and is configurable so it can use I2C1 or I2C2 peripheral, at users choice. Now, on Nucleo board, because of the way I connected the LCD (and it will remain that way for all my examples), there is a single I2C peripheral available so, it will be much easier to simplify the things and eliminate this feature. But STM32 has a single header file for all I2C peripherals, and the use is a little different - will see, I only had a glimpse into the header file.

P.S.: Luckily, the I2C1 pins are 5V tolerant - thanks ST, your microcontrollers are great.

Tuesday, May 9, 2017

The wire has fever!

Yep! The onewire and DS18B20 libraries are ready. Built on top of the HAL layer, I was afraid that the timing won't be right... my tiredness added to that and I didn't observed that the bus is connected to a wrong wire on Nucleo board, making me to do some major changes in the source.

So, once I solved the issues, I added two projects as examples:

1. OW03_DS18B20_temp

This works with a single temperature sensor on bus, showing the temperature and the ID number on a 16x2 LCD. Is a good way to label your sensors, as I don't provide a search function and you need the IDs for the second example.

The LCD mockup looks like this:
It shows the temperature on the first row, and on the second, the unique serial number of the sensor in hexadecimals - you need to know the ID of your sensors for the following example. The second row is also used to display the error messages.