Saturday, November 25, 2017

What kind of I2C device is TSL2591?

The TSL2591 lux sensor is described as an I2C device in it's datasheet where you won't see detailed the communication protocol so there are some problems:

- it does not work with the hardware implementation of the master I2C library;
- it does not work with the software implementation of the master I2C library;
- but it does work with the software implementation of Arduino's Wire library.

It is also reported that it works with the Linux SMBus implementation. Right now, I will put this sensor aside, and continue with the SPI library, but I will return at it. I still think that the MAX44009 is a better replacement as it has a larger lux range to the top end of the scale, auto calibration and it is truly an I2C device.

Friday, November 3, 2017

How to activate floating point for sprintf in your Low Layer based project

By defaut, a project created for Low Layer driver with STM32CubeMX use the newlib-nano C library and as direct effect, the floating point processing is removed from printf formatting function. You won't see your floating point numbers printed.

Here I wrote a little tutorial about how you activate the floating point for the printf function, which will also affect the sprintf function

Wednesday, October 18, 2017

A short report on my progress with LL driver

After the success with the DS18B20 temperature sensor, I started working with I2C peripheral, trying to read and set a PCF8583 real time clock but there is a catch.

The only thing I used from LL driver is the initialization function generated by the CubeMX software. The other (4) functions (I2C in master mode) I got them from Tilen Majerle because it was no way to make the LL functions work and the examples from ST didn't helped at all this time. I will return later and adapt what I got for LL driver but not too soon. Anyway, there are no extra requirements and the library can be used as it was from LL (you'll see when I'll upload the code).

There are three examples that work with the PCF8583 RTC and I will upload everything soon but I would have liked to have also the SD library ready and that means learning to work with the SPI peripheral in master mode. Not decided yet...

You may wonder why all this... I need LCD, I2C for a LUX sensor, RTC and SD to record the LUX values, aperture, shutter speed, the number of film frame from a DIY SLR film camera that can work with a Canon EOS EF lens.

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)