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.

Thursday, March 23, 2017

Standard is better...

Code size wise, using only the Standard Libraries, you get an advantage of around 3Kb in size, compared with the HAL Libraries. Disadvantages? You lose the fast prototyping features (and the sense of security) offered by the STM32CubeMX.

Well, that is not a problem for the advanced programmer, but I, as a beginner, I will work with HAL Libraries a little longer - the microcontroller I work with, has a lot of unknowns to me. I rewrote the Blink application using Standard Libraries and compared the code after the compilation. The sources are in the github repository.

Made with Standard Libraries:

Made with HAL Libraries:

The application is simple, it blinks a LED at three different speeds, which can be changed pressing the user button, where an interrupt is generated. Anyone knows the Arduino sketch, "BlinkWithoutDelay", an even simpler application. I compiled that in Mapple IDE for Cortex-M3 microcontroller, and is good to know that it is even bigger :P (almost double than with HAL Libraries)

Tuesday, January 3, 2017

Staring at the display

After adding a conversion library and porting the LCD library from c18lib project, and adjusting the microseconds delay, I have a functional example. When you set the pins as outputs on the STM32CubeMX graphic configurator, you must rename them as follows: LCD_D7, LCD_D6, LCD_D5, LCD_D4, LCD_E, LCD_RS. Otherwise, the library will set her own default configuration.

Yep, I used this board for her peripherals. On board, the peripherals are connected only to power lines. with available connectors for arbitrary connections - be it on board, or external. The board was powered at 5Vcc from the Nucleo board. The default configuration and connection to the Arduino socket is as follows:

LCD_D7 to Arduino D7
LCD_D6 to Arduino D6
LCD_D5 to Arduino D5
LCD_D4 to Arduino D4
LCD_E to Arduino D3
LCD_RS to Arduino D2

Note: all the pins from the default configuration are 5V tolerant (not that it really matter as are set as outputs). The LCD was powered at 5Vcc.

Sunday, January 1, 2017

One char after another...

I started the work to onewire library, to test the DS18B20 temperature sensor but realized that I don't know yet how to work with the serial transmission :(. So, I opened the STM32CubeMX for the configuration of a new project that will use the main serial port of the Arduino socket (on my Nucleo board, of course). And, after generating the configuration, you have to look for the HAL API documentation to realize which transmit function you can use.

Of course it didn't worked for the first try, because instead of UART function, I used USART function. It didn't worked until I changed to:

HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData,
                        uint16_t Size, uint32_t Timeout)

But now is ok. See the code in repository. In future, I will try the interrupt based functions as I need them for a more advanced program.