Friday, October 6, 2017

Even the Low Layer Driver can get a ... cold

I finished testing both applications with DS18B20 temperature sensor so both libraries, onewire and ds18b20 are working well with Low Layer API. And the compiled code is almost four times smaller. The applications are identical with the ones written for HAL API.

I prepared the library for the PCF8583 real clock timer that uses the I2C bus - the reason I moved to LL API - so I should be able to test it soon...

Not yet an update from STM for their CubeMX application (4.22.1 version) - functionality for generating LL code for a Makefile based application is still broken...

Sunday, September 24, 2017

Alea iacta est

I've decided, Low Layer Driver it is. So, I am in the middle of porting my libraries to LL. Just finished checking the LCD4 library, and decided to make a code size comparison between the APIs (HAL and LL).

Saturday, September 16, 2017

TIM6 set for 1ms timer using ST Low Layer API

This is true for the STM32CubeMX 4.22.1 and STM32CubeL1 driver 1.8.0. Actually, CubeMX does not generate the complete functional code and the snippet included will serve for me as a future reference.

TIM6 general timer is used as an alternative to the Systick until the Low Layer API will have the same features for the 1ms system tick as HAL API does.

Tuesday, September 12, 2017

First success with the libopencm3 library

Obvious, the first thing to try using both a new board and a new library is to blink a LED. But there were a couple of issues.

1. The first thing I had to solve, was properly setting the clock of my board in order to have a functional microseconds delay function. The libopencm3_examples project does not come with examples for Nucleo L152RE board and the examples for the STM32L1 Discovery board weren't too helpful but looking inside the library, I found a set of clock settings for few cases involving STM boards.

Saturday, September 9, 2017

Nucleo headers

As this will become my online reference regarding this board, lets store some more technical details regarding the header connectors.

Arduino style connectors

Well, because of the Arduino standard connector, the microcontroller pinout wirings are a mess but I'm not the one to complain, as I did the same to a couple of microcontrollers for the sake of this standard.

One Wiring language to rule them all

Finally, my Nucleo board is supported by the Arduino project (see here the core). The first effect is that the board enters in the RAD (Rapid Application Development) category of the selected Arduino compatible boards. It means also that I can test directly the TSL2591 Lux sensor (my DIY SLR film camera needs it) using the Adafruit library. We will see how this goes in the near future.

I'm definitely not a fan of the wiring language but I can't ignore the deep pool of resources (a large variety of libraries and projects) accumulated over the years within the Arduino ecosystem. This being said, I will continue my adventure in learning the much more efficient Low Level libraries of STM32 microcontrollers, combining the two worlds as much as possible.

Wednesday, August 30, 2017

Crossroads without signs...

Usually. I chose the complete solution, the one that helps me get the most of it. As is the case with STM32CubeMX + OpenSTM32 IDE + HAL drivers. But HAL does not give me the level of control I was used to, so Low Layer drivers are a very good addition. Unfortunately, OpenSTM32 does not offer support for it and that breaks the solution.

Well. one solution is to generate the code for Makefile (a STM32CubeMX option) and that would make it "IDE immune", but for now, there are linking problems in the I2C library of the STM32L1xx Low Layer drivers and it seems no one got that yet (I opened a discussion thread on the ST community)...

I will try to see if I can get the libopencm3 library configured for my Nucleo board. If it works, I won't mind to translate my libraries again for the new system.

Tuesday, August 1, 2017

A new morning shines at the horizon

Finally, the STM32CubeMX can generate Low Layer code for all STM32 microcontrollers! Thank you ST Microelectronics!

I have taken an active pause, continuing with PIC18F microcontrollers, SDCC and XC8 compilers. Translating the library and examples for the DS18B20 temperature sensor, but these are yet to be committed in their repositories. I also tried to make an I2C library for the TSL2591 LUX sensor (now this is the second I2C device in my possession), still working on that...

So, not a wasted waiting... but not an activity for this blog.

I had a topic here on ST Community regarding this feature for STM32CubeMX.

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. Now, 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.

Wednesday, December 28, 2016

Without microseconds, you're just an outsider

As it is, the HAL library comes with a tick at every 1 millisecond, like a "millis" in an Arduino library. It is your application's timer, allowing you to plan timed, non-blocking tasks, like in a real-time operating system. But no microsecond delay function provided :( . And you know, many initialization procedures or protocols of different external peripherals require microsecond delays in data flux.

Of course I started to search for already written code and I came across Domen Jurkovic code on github, but his assembler code didn't compiled on my toolchain (sure it worked on his toolchain). I continued the search and found on the Mapple library an assembler code that compiled ok on my toolchain and resulted in a function that actually works. I tuned the code to work correctly on my 32MHz clock (look in my repository - link on the right panel).

    asm volatile("   mov r0, %[us]          \n\t"
                 "1: subs r0, #5            \n\t"
                 "   bhi 1b                 \n\t"
                 : [us] "r" (us)
                 : "r0");