Topics

Let's Minimize the Library problems.

Jack, W8TEE
 

This is a common problem for many homebrew projects. Frankly, I don't know which library to use either, so let's agree to try and make things simpler: I always use this format for any non-standard library, where non-standard means the library is not distributed as part of the Arduino IDE:

    #include <XPT2046_Touchscreen.h>        // https://github.com/PaulStoffregen/XPT2046_Touchscreen


The comment on the line gives the URL where the reader can go and download the library. This simple change would help people find the correct library to use. (I don't know which one is correct, I'm just using Paul's as an example of how to document it in the code.)

Jack, W8TEE

On Saturday, December 14, 2019, 1:03:47 PM EST, GM4CID <gm4cid@...> wrote:


Hi, there seem to be several XPT2046_Touchscreen libraries on Github, wondering which one is correct to use ?

73, Bob GM4CID

--
Jack, W8TEE

Cory King
 

In my personal projects that use Arduino stuff (or in my case ESP32/8266) I have been using platform.io.  In addition to really good IDE integration, it has a way to express library dependencies.  


Its way isn’t as fancy as something you’d see with a “real” package manager like NPM but it is good enough that anybody pulling down your source code will know what libraries to install—in fact platform.io will do it for them.

If it was me, I’d switch all the code to use platform.io.  It could also help with porting to ESP and teensy as the system helps manage any compiler flags you’d need in order to add platform-specific code.

Cory King
 

And sorry to double reply, “good ide support” I mean something other than Arduino IDE.  VSCode or JetBrains CLion.  Both have much better syntax highlighting, auto-completion, git integration and oh so much more.

Ashhar Farhan
 

Cory, jack,
Great ideas. I am travelling and I will try implementing these.
One of my key constraints is to keep things working with what others find easy to use. I would switch from Arduino to the Blue pill in a second except that programming it from Arduino or Platform I/O isn't so simple. You have burn in the boot loader that needs you to hook it up with a serail to usb cable, then switch over to usb programming.
I just give this as an example. Platform io isn't as familiar to many as the horribly kuldgy Arduino IDE. I aleast wish they had implemented a goto line feature!

73, f


On Sun 15 Dec, 2019, 2:16 AM Cory King, <cory@...> wrote:
And sorry to double reply, “good ide support” I mean something other than Arduino IDE.  VSCode or JetBrains CLion.  Both have much better syntax highlighting, auto-completion, git integration and oh so much more.

Tom, wb6b
 

Perhaps the biggest problem with STM32F103 Blue Pill development on the Arduino platform is there are two competing tool chains, the original "Paul Stoffregen" toolchain and the "official" STM32 tool chain endorsed by STM. I would prefer the official STM32 toolchain, but most Arduino Blue Pill projects seem to have been developed with the Paul Stoffregen version, so I use it. 

Another big issue I've found, for example with the graphics/touchscreen libraries, is several libraries such as the Adafruit graphic libraries need to work together with the lower level display module drivers for the TFT and touchscreen hardware. 

Library writers upgrade and enhance their libraries and no regression tests are (or can be) done on other libraries compatibilities, especially the non-mainstream libraries like those for the Blue Pill. And writers of the STM32 libraries may not be maintaining their libraries anymore, so they don't get updated. 

For what ever reason, the ESP32 toolchain developers have been doing a much better job in keeping their libraries updated to reflect changes in other libraries they are dependent on.

In an example of trying to get a touchscreen display working on a Blue Pill, AdaFruit updated one of the screen attributes from one parameters to two. (I've forgotten which one, but they changed the X and Y parameters [possibility a dot size value] to be separately specified, rather than the X and Y values being equal.) There was no backwards compatibility so the STM32 touchscreen libraries no longer worked. The change was done in a way that adding simple wrappers, still required culling through the AdaFruit code to correct numerous instances in the code. (There were still other issues with the hardware assumptions around interrupts and SPI ports, that clashed in the latest libraries, but may not have in older libraries when the STM32 toolchains were first introduced, years earlier)

Unlike the ESP32 toolchain, the STM32 toolchain(s) seemed to get off to a bad start, along with libraries breaking over time as other libraries are updated, generating confusion and trouble it so far has not recovered from. Then adding two toolchains to top the confusion off. 

For many simpler projects, these issues are less troublesome and the Arduino platform is still simple fun to use.

Finally, I don't bother with putting boot loaders on the Blue Pills. I either flash the program with the serial boot loader built into the chip, with a USB to serial adaptor, or use one of the inexpensive ST-Link adaptor clones from eBay. Although I might try the various boot loaders out at some future point. I can see for something like the uBitx installing a USB boot loader would be the best way to go for usability. 

Whichever toolchain you use, as Jack pointed out, let people know where the actual source location of library you used can be found.  As, many libraries have more than one version and authors.

Tom, wb6b

Ashhar Farhan
 

Tom,
I have moved on to using nothing except the standard arduino libraries. The current build is dependent only in the i2c and spi libraries. I am going bare metal on the touch library as well. I will oush the touch and display code into one file that you can rewrite for every display.
- f

On Sun 15 Dec, 2019, 10:14 AM Tom, wb6b, <wb6b@...> wrote:
Perhaps the biggest problem with STM32F103 Blue Pill development on the Arduino platform is there are two competing tool chains, the original "Paul Stoffregen" toolchain and the "official" STM32 tool chain endorsed by STM. I would prefer the official STM32 toolchain, but most Arduino Blue Pill projects seem to have been developed with the Paul Stoffregen version, so I use it. 

Another big issue I've found, for example with the graphics/touchscreen libraries, is several libraries such as the Adafruit graphic libraries need to work together with the lower level display module drivers for the TFT and touchscreen hardware. 

Library writers upgrade and enhance their libraries and no regression tests are (or can be) done on other libraries compatibilities, especially the non-mainstream libraries like those for the Blue Pill. And writers of the STM32 libraries may not be maintaining their libraries anymore, so they don't get updated. 

For what ever reason, the ESP32 toolchain developers have been doing a much better job in keeping their libraries updated to reflect changes in other libraries they are dependent on.

In an example of trying to get a touchscreen display working on a Blue Pill, AdaFruit updated one of the screen attributes from one parameters to two. (I've forgotten which one, but they changed the X and Y parameters [possibility a dot size value] to be separately specified, rather than the X and Y values being equal.) There was no backwards compatibility so the STM32 touchscreen libraries no longer worked. The change was done in a way that adding simple wrappers, still required culling through the AdaFruit code to correct numerous instances in the code. (There were still other issues with the hardware assumptions around interrupts and SPI ports, that clashed in the latest libraries, but may not have in older libraries when the STM32 toolchains were first introduced, years earlier)

Unlike the ESP32 toolchain, the STM32 toolchain(s) seemed to get off to a bad start, along with libraries breaking over time as other libraries are updated, generating confusion and trouble it so far has not recovered from. Then adding two toolchains to top the confusion off. 

For many simpler projects, these issues are less troublesome and the Arduino platform is still simple fun to use.

Finally, I don't bother with putting boot loaders on the Blue Pills. I either flash the program with the serial boot loader built into the chip, with a USB to serial adaptor, or use one of the inexpensive ST-Link adaptor clones from eBay. Although I might try the various boot loaders out at some future point. I can see for something like the uBitx installing a USB boot loader would be the best way to go for usability. 

Whichever toolchain you use, as Jack pointed out, let people know where the actual source location of library you used can be found.  As, many libraries have more than one version and authors.

Tom, wb6b

Tom, wb6b
 

On Sat, Dec 14, 2019 at 10:09 PM, Ashhar Farhan wrote:
I have moved on to using nothing except the standard arduino libraries.
Hi Farhan,

I was just reading the post you did elsewhere and was impressed at the work you did to accomplish the user interface with such minimal resources. For the uBitx that is fantastic as it allows the folks that are building it to learn, to also delve into the software world without all the pain of using less stable toolchains and libraries. Cost is also important for your uBitx to have the reach of users around the world it is enjoying. So the path you went down is great. I'm definitely interested in looking at the code you wrote for creating the minimal resources needed user interface. 

Tom, wb6b

Jack, W8TEE
 

Tom:

I think you mean the tool chain developed by Roger Clark for the STM32. Most of Paul's work is dedicated to the Teensy family, which his company developed. Paul's Teensy 4.0 (aka T4) is a real game-changer.  Our book's DSP project does a real time FFT plot of the audio signal so you can see the impact of your DSP changes in real time. You can't do that without having a fast processor (e.g., the 600MHz clock of the T4).

The key to working with any graphics library is to make sure your display has the right video driver chip to match the library. If more people understood that, or if us programmers were more careful to use download URL's for the correct library in the code, there would be a lot less bandwidth used here. This is taken from the JackAl header file:

#include <Arduino.h>          // Standard with IDE
#include <EEPROM.h>           // EEPROM distributed with Teensy libraries
#include <math.h>             // Standard with IDE
#include <Wire.h>             // Standard with IDE
#include <SPI.h>              // Standard with IDE
#include <stdio.h>            // Standard with IDE

#include <OpenAudio_ArduinoLibrary.h> // http://hamradiodesigns.com/index.php/content/
#include <Adafruit_GFX.h>     // Now supplied with Teensy Library install
#include <Audio.h>            // Now supplied with Teensy Library install
#include <RA8875.h>           // http://hamradiodesigns.com/index.php/content/
#include <Rotary.h>           // https://github.com/brianlow/Rotary
#include <SerialFlash.h>      // Now supplied with Teensy Library install
#include <Time.h>             // Now supplied with Teensy Library install
#include <TimeLib.h>          // Now supplied with Teensy Library install
#include <TimerOne.h>         // Now supplied with Teensy Library install
#include <UTFT.h>             // Now supplied with Teensy Library install
#include <URTouch.h>          // http://www.rinkydinkelectronics.com/library.php?id=92
#include <UTFT_Buttons.h>     // http://www.rinkydinkelectronics.com/library.php?id=61

As you can see, it is not hard to do and it makes it unequivocal which library to use.

Jack, W8TEE

P.S. Now that the book's done, Al and I are going to resurrect our hamradiodesigns web site. It's been hacked, so don't go there now. For the moment, most of the files have been moved to my softwarecontrolledhamradio web site.

On Saturday, December 14, 2019, 11:44:11 PM EST, Tom, wb6b <wb6b@...> wrote:


Perhaps the biggest problem with STM32F103 Blue Pill development on the Arduino platform is there are two competing tool chains, the original "Paul Stoffregen" toolchain and the "official" STM32 tool chain endorsed by STM. I would prefer the official STM32 toolchain, but most Arduino Blue Pill projects seem to have been developed with the Paul Stoffregen version, so I use it. 

Another big issue I've found, for example with the graphics/touchscreen libraries, is several libraries such as the Adafruit graphic libraries need to work together with the lower level display module drivers for the TFT and touchscreen hardware. 

Library writers upgrade and enhance their libraries and no regression tests are (or can be) done on other libraries compatibilities, especially the non-mainstream libraries like those for the Blue Pill. And writers of the STM32 libraries may not be maintaining their libraries anymore, so they don't get updated. 

For what ever reason, the ESP32 toolchain developers have been doing a much better job in keeping their libraries updated to reflect changes in other libraries they are dependent on.

In an example of trying to get a touchscreen display working on a Blue Pill, AdaFruit updated one of the screen attributes from one parameters to two. (I've forgotten which one, but they changed the X and Y parameters [possibility a dot size value] to be separately specified, rather than the X and Y values being equal.) There was no backwards compatibility so the STM32 touchscreen libraries no longer worked. The change was done in a way that adding simple wrappers, still required culling through the AdaFruit code to correct numerous instances in the code. (There were still other issues with the hardware assumptions around interrupts and SPI ports, that clashed in the latest libraries, but may not have in older libraries when the STM32 toolchains were first introduced, years earlier)

Unlike the ESP32 toolchain, the STM32 toolchain(s) seemed to get off to a bad start, along with libraries breaking over time as other libraries are updated, generating confusion and trouble it so far has not recovered from. Then adding two toolchains to top the confusion off. 

For many simpler projects, these issues are less troublesome and the Arduino platform is still simple fun to use.

Finally, I don't bother with putting boot loaders on the Blue Pills. I either flash the program with the serial boot loader built into the chip, with a USB to serial adaptor, or use one of the inexpensive ST-Link adaptor clones from eBay. Although I might try the various boot loaders out at some future point. I can see for something like the uBitx installing a USB boot loader would be the best way to go for usability. 

Whichever toolchain you use, as Jack pointed out, let people know where the actual source location of library you used can be found.  As, many libraries have more than one version and authors.

Tom, wb6b

--
Jack, W8TEE

Tom, wb6b
 

On Sun, Dec 15, 2019 at 06:38 AM, Jack, W8TEE wrote:
I think you mean the tool chain developed by Roger Clark for the STM32.
Jack, you are correct.  Thanks for the correction. Roger Clark is the developer of the "original" STM32 toolchain ported to the Arduino platform. The platform most Arduino Blue Pill projects are still done with.

Maybe the work the people have done with the Teensy make it one of the best places to start, if you want to use STM32 and other more powerful boards with Arduino. As they are smart to focus on a set of boards that they build and have control over, and therefore can support with stable working toolchains and libraries.

Looks like the way they have kept their boards form being crushed by cheap clones, and afford to stay in business, is they have a special bootloader chip they keep proprietary.

I may buy some Teensy boards, do development on them, then when I want a new hair raising adventure I can try porting to a Blue Pill if cost is an issue.

Mostly I do my STM32 development with the STM32Cube tools from STM now. Great for the consulting I do, but still want to do some projects on the Arduino platform so they can be shared in the Maker/hobbyist, open source community. Mbed is another interesting developer platform that is meant for both professional and Maker/hobbyist projects.

Tom, wb6b

Jerry Gaffke
 

They are both ARM processors.
But the Blue Pill processor is made by ST,  the Teensy by NXP.
Slightly different worlds.


On Sun, Dec 15, 2019 at 02:13 PM, Tom, wb6b wrote:
Maybe the work the people have done with the Teensy make it one of the best places to start, if you want to use STM32 and other more powerful boards with Arduino.

Tom, wb6b
 

On Sun, Dec 15, 2019 at 04:45 PM, Jerry Gaffke wrote:
They are both ARM processors.
Yes they are both ARM processors, but each manufacture has a lot of latitude in how the peripherals and I/O are designed. So, that would make porting from Teensy to Blue Pill much easier, especially with the Wire abstraction Arduino uses for I/O. 

However, I looked at some of the libraries the Teensy had in their toolchain and they were maintained with the Teensy version of things. So using the Teensy toolchain with Teencys looks like you will get libraries that have been curated and up to date. But they did not necessarily try to include code in compile options for other ARM processors. So I guess you can take the Teensy libraries and add the changes needed for the Blue Pill, or fix the current STM32 libraries and bring them up to date, or write a bunch of wrappers. 

I did see in the headers Jack posted, yet another graphics library. I may try that on the Blue Pill. 

#include <UTFT.h>             // Now supplied with Teensy Library install
#include <URTouch.h>          // http://www.rinkydinkelectronics.com/library.php?id=92
#include <UTFT_Buttons.h>     // http://www.rinkydinkelectronics.com/library.php?id=61
 
Graphics on the STM32Cube tool chain is no walk in the park either. You have to work yourself through the learning curve, confronting a cacophony of documentation. Be led astray by out of date app notes. Follow blind alleys suggested by the easy get started videos. Try the examples, but they are for different toolchains and have to be converted from the gitgo to STM32Cube (unless you have the expensive toolchains the examples were written in) and fix the bugs resulting from the conversion process. (and you just wanted to quickly get an example going so you could learn something from it)

The graphical user interfaces build with these tools are trying to compete with the expectations people have from using smartphones, so they are more complicated than what I'd try (actually they would not fit) on a Blue Pill.

Finally, for graphical user interface applications, you finally realize you shouldn't start from the easy everything is integrated here point in the IDE, although they keep pointing you there. It is better to just use a working example (after you fix all the incorrect relative library paths pointing to code outside the scope of the project) that already has the clocks, I/O, graphic chips, DMA and all, already working (then simply modify the I/O init code provided by the example code), rather than dealing with a clock and I/O configuration tool that has no idea how the chip (actually development boards from STM) should be configured. So none of the I/O is configured correctly, even assigns pins needed for the graphic I/O to other functions making them unavailable. This is part of the learning curve if you want to start from the chip configurator, like they try to get you to do. This is part of the learning curve of learning a new tool set. 

Many of the manufacture supplied toolchains are disorganized in similar ways. They are far from alone. But the price is right. 

So the best word of wisdom I got, regarding difficult to use tools, from a manager was. (This was at a company where our department head was out for an extended time and they hired a former employee [was currently a Oracle consultant] as an interim department head.) 

In a meeting we were dishing out our dislike for some of the tools of the time and how bad we felt they were. We were hoping for enlightenment, as he was a big time, highly experienced, certified Oracle consultant. 

The interim manager said, "I know the tools are bad and terrible to use". "But! Everyone in the valley (Silicon Valley) uses Oracle, and I make a lot of money as a consultant because of that". So case closed on bad tools. I guess I haven't figured out the lots of money part, but still pays better than working at the gas station. 

I suppose when I get more time under my belt with the development tools I'm now using and learning more complicated UI development, I'll think how obvious everything is. Then I'll make yet another YouTube video on how easy it is. 

Tom, wb6b

Tom, wb6b
 

On Sun, Dec 15, 2019 at 04:45 PM, Jerry Gaffke wrote:
Slightly different worlds.
In a second reading of your comment I realize you are making the point of the differences of the processors, not the sameness being they are both ARM processors. 

So the part where I say "but each manufacture has a lot of latitude" should have acknowledged that that was the point you were making, rather than being a counter argument.

Tom, wb6b