BSA – Styling Native Controls

It is two controls with an identical border on the picture above. The button display the border correctly, while the ComboBox do not display the border at all. It does have a BorderBrush that I set, but it has no effect. This is quite common with build in native controls – it might be a trick to this – I don’t know. This is sadly a repeatetive challenge for styling Windows GUI, so what I will do is to create my own ComboBox that I can control 100% – I simply need controls I can trust because I will re-use them in the SDK. So, it is often less effort to simply create a new one than fighting Windows GUI limitations.

In this case I want to control colors for Normal, Hover and Selected on Background, Foreground, Border as well as all details on the drop down part as well. I need full control and so do you. In old Windows you could use the control and take over painting – I am a bit on thin ice on that on WPF, so lets see. If I can control the ComboBox I will use it as is, but it is more than just controlling as we would like to add images and details on the selection list etc.

Or a workaround can be to just overlay a transparent rectangle with rounded corners like above to get around this specific issue. What you see is the Hovering effect of my ButtonStyle=Border Button. I code that into all controls so you can visualize selection or hovering with a thick border – a “Standard” control will change background. These effects are handy in creating a modern, custom styled HMI.

BSA – Code Generator Results

And this is the result of the code generator. In C++ and C# you can use inheritance – simply use a base class for symbols, autogenerate a HMIButton_base and then create the final HMIButton manually – this is a nice way to allow autogenerated code while you still have the full manual control. C# have an even nicer technique that I used – partial class. I autogenerate a class with all property setting based on a Excel spreadsheet and manually write the part creating the symbols.

Obviously I still have a few bugs:( – … but my code generator works just fine. This will make a significant impact since we talk about hundreds of components with 10 to 30ich properties each and each property account for ca 10 lines of code 🙂

BSA – Assisting Code Generator in place

This example is the property list for Button. This is just an early draft, but as I added more properties to Button yesteday I realized that this would take some time with the number of components involved as every property require a bi of coding. So using a CSV file allow me to use Excel as editor and then just run a simple script in C# to generate repetive code that I can use to cut and paste from. It actually worked out well, it took me yesterday to moch up the code generator and today I can start speeding up adding properties – or more correctly modving my focus away from declaring properties to implementing their usage.

This is not rocket sciense as I believe every single developer have done something similar at one point using CSV, XML or JSON.

BSA – Generating Code

I am sitting setting up all the properties for the components and it is a bit of work for each component, so what I want to do is one of my usual tricks to code using Excel. Simply by creating a CSV list, read it into a C# app and generate all the property settings and code because it’s a lot of repetition and there will be changes. To do so I will need to create a tree structure in Excel – it is many ways of doing this, but I want a table that is simple to edit and a small app that convert that into C# code so I have an easy way of editing properties – and can save some hours.

While this is used to set up the list for BSA it will also become part of BSA as we allow users to create their own components.

  • 001, Component Name
  • 002, Property Name,…..
  • 003, Value,…..

I think a simple tree where 001 is top, 002 subtree to last 001 aso will do the job – comma separated text fiels so they are easy to edit in Excel or similar.

This is a task you need to consider, but the general idea is that if you need to set up loads of repetive lines like I do now it might be worth consider spending the time on the code generatir instead. Many of my friends use Python for this, bur for me it is faster to do this in C++ or C#.

BSA – Property Editor Compromise

Now as I know why I have a performance issue and know the solution it is also possible to make a compromize. I need to address performance, but I can live with what I have for a while. The issue is that it is easier to experiment with functionality using XAML, so I can make it functional before optimizing performance – you need around 50+ properties before you notice the performance issue anyway.

The reason I can make this compromize is because the real property list is an internal list that do not care about the property editor, so all I need to do is to make the new, optimized with an identical interface later and voila… lets move on…

BSA – New Property Editor

This picture is the old one that had performance problems. The new one is not so impressive yet, but it’s performance is far better. I ended up doing the exact same from code as I did from XAML finding out that it was far faster and allowed me to do some smarter code. At the end of the day WPF (or should I say GPU) are capable of handling large tables, but you need to be aware that IO between CPU and GPU can be a bottleneck. So at 1000 entries it still started to get unacceptable slow. The solution is obvious – since I now coded the grid I could also focus on the visual parts only and update the grid as I scroll – basically creating a virtual grid to be able to handle large amounts of data.

The problem started as I added several properties to the grid and noticed that it became slow, so I added 1000 and was shocked about XAML performance. I am not confident that coding it in C# will be better then all details are added, but I can add smarter code. I only update those that are visual and text strings (as an example) I only display and create the editor as I need them – I also only create a single editor because I can only edit one field at the time anyway – the later is important for solving the huge memory leakage I detected.

The drawback is all the extra work I am forced to do, but this is engineering for you – sometimes you need to redo things because of unexpected challenges.


Looking at the examples above I also need to consider the end result – the embedded mini word processor is great, but it makes the property list long. The same with the attribute table expanded – and as each attribute have it’s own description with mini editor this really takes over the property list. The result all in all is very functional, but this is a very important part of the tool so we need to be critical and look for improvement options. One details is how I collapse a description – another is to avoid expanding multiple attributes unless I want to – I could also move tables and descriptions to separate pages – this is the upside og not using XAML as I can easier do more smart systems.

Home Autiomation – LoRa based Bootloader

One of the things I am looking into is to have a bootloader through LoRa. Making one is straight forward, but I actually think I can use the silicon bootloader as is…

You probably know that all STM32 MCU’s comes with a build-in bootloader in ROM located at a special address. You invoke this by using boot pin, but less known is that you actually can call this manually from firmware. in my case I have LoRa connected to USART, and accessing this from a PC I should be able to use the build-in bootloader over LoRa and use ST’s own utilities.

The trick here is that neither the serial line on MCU or PC actually see the LoRa in the middle. The LoRa unit I use can be configured once and will afterwards just work using that setting. I obviously need to create an adapter for my PC as well (or buy one), but that should be doable.

USB – Serial Debugger

This shows the moisture sensor from my previous entry with one exception – I added the USB Serial port. I have used various serial ports for debugging in the past, but never the USB despite I have always had it on my boards (almost always) – I simply never took the time to figure out how it worked before. And once I did I was puzzled about how easy it was.

Yes we have JTAG/SWD with single step debugger etc, but you do need a serial line to print info on during a real-time loop – not a lot of info, but triggered info about what is happening. You need this to verify that your system is working and to debug problems. Or to put it in a different way – you CAN manage without as I just had to in a project, but that will cost you a lot of extra hours.

USB is perfect for maintenance and debugging – it only takes two pins and all software topside and embedded is free – only a few lines of code and you have a debug serial running.

In this case I will also use LoRa and I will even look into having a LoRa based Bootloader. A bootloader is a small program that download and start the real program. To do so you need to do a few tricks that I will get back to, but it is not difficult.


Something else that is handy is a proper serial debugger/logger application. This is something I want to create and it is very straight forward. You make a debugger that send info in a selected format and then you add logic to the top-side utility to filter and process that. I tend to do this as per need, so I will look into creating a proper one that I can re-use more because it is an important part of your development time/productivity.

Home Automation – Moisture Sensor

It’s spring and summer comping up, and I am spending a bit of money on flowers every year so I would like to know more accurately their condition. Weather can change from very hot to very wet and not all plants get what they need from rain – some plants also get to much water etc. The solution to this is a moisture sensor that report soil moisture once an hour as illustrated below:

Using my classic block diagrams I use a Blackpill – cheap STM32F401CC breakout in dip40 format – as base and create the circuit abobe. I add a battery and remove things like leds and add a single sensor – a low cost moisture sensor consisting of two pins I stick into the soil. This gives resistance that decreases with moisture, so a very wet soil (water) will give value 0 (Zero). I removed the circuit that came with the sensor and powered it from a GPIO pin + connected a 10K resistor in serie – that gives a nice ADC reading after a few ms allowing me to switch the sensor on/off.

Temperature of electronics are not that accurate, but it is sufficient in this case and vref are internal. I also have VBAT (not shown) – I need to experiment a bit with VBAT and VREF, but I expect they will show me the condition of my battery – if not I will need to add another sensor measuring battery so I can predict battery condition/life.

The more complex circuit is the LoRa transmitter. I decided on a 5.- USD E220-900T22 D or S for the moment. These operate through UART and is very easy to use. I will need to put this in deep sleep and wake it up every time I want to send data. I also put a 32KB FRAM chip that uses the same footprint as SPI Flash on the back of the BlackPill – 32Kb is a lot of storage and FRAM is very low power and fast and can be written to almost forever. It is a good solution if you want to sample more often than you want to activate the transmitter. I am just experimenting with solutions here.

The illustration above is the actual finish sensor. I will use an old plastic pill-container, put the sensor through the lid and tighten it up consealing the electronics and transmitter inside – painten in black or dark green it will be “invinsible” in my garden between my flowes. I obviously need a matching adapter as gateway, so I decided on a Raspberry PI connected to mainst that will act as a gateway between LoRa and Wifi. I can connect UART + 3 GPIO pins from Raspberry PI directly to the LoRa unit.

It will be no PCB on first prototype, but I will order a PCB later – this is the first time I do a low power LoRa project so it is an experiment. STM32F401CC is not optional, but I still believe I should manage to get ca 1 year’s operation out of a 1Ah/3.7V battery – lets see.

The way this shold work is that the sensor sleep most of the time and measure moisture every 5th or 10th minute – reporting results every hour or so. Sending uses 110mA so I have to be carefully with not doing that to often or to long. One option to LoRa is ESP32 & Wifi, but I decided against that because of distances in my garden and the 3-4 seconds needed to connect Wifi + nice to actually do something withy LoRa as well.

Home Automation – Moisture ratnest

This picture shows my current development ratnest of a moisture sensor connected to a LoRa unit. It’s a few extra components that have nothing to do with this project, but it’s a good reminder why I seldom do breadboard ratnests anymore. The wiring failure trate is very high, but in this case it worked out well as I needed to test the moisture sensor and the LoRa unit (bottom left). I will put out a PCB for this soon. I decided to use a Blackpill that is a dip 40 breakout with a STM32F401CC on it. It has space for a SPI FLASH/FRAM on the back and have RTC oscillator etc. For it’s low price it is good value and an easy way around the current component shortage.

STM32F401CC is not low power, but my main concern here is the other components.