St have a good series of MCU’s and I have stuck with F405 for a while. But, I just discovered G474RE, G484RE, G484CEm G491CE etc. This series is very similar to F405, but contains a lot of extras for a lower price. Also some of the MCU’s are LQFP48, but it is still a M4 ticking at 170Mhz.

Using G474RE as an example:

  • M4 w/512KbFlasg, 128Kb SRAM, 170Mhz
  • Math accelerators (Geometri and Filters)
  • 16 ch DMA
  • 5 x 12 bit ADC w/16bit oversampling.
  • 7 x 12 bit DAC
  • 7 x Analog comparators
  • 6 x Op amps
  • Loads of PWM signals.
  • 17 timers
  • 3 x FDCan
  • 4 x 1Mbit I2C
  • 6 x UART
  • 4 x SPI
  • USB
  • and much more…

G484RE holds crypto in addition, both G474 and G484 also have 48 pin versions. ST is also very good in backward compability so these MCU’s are a drop-in replacement on my F405 designs I assume. The addition of math accelerators and analogue components makes this a very good candidate for motor controllers – but, that said – these MCU’s are very fast as is without the accelerators.

FD CAN in special interest me as IPC backbone on a stack. It is fast and with higher payload than it’s HS version. FD CAN seems very similar to ordinary CAN with the exception of up to 64 byte payloads. I fail to read if max speed is increased, but I assume so. What these lacks is a bit less Flash and no Ethernet compared to F407 etc. But, I can live with that.

Ethernet on one of these MCU’s can easily be added through a Wiznet chip for normal usage. Usage of Ethernet often also requires web pages and I preffer to offload that to another MCU anyway. A fronend Linux like Raspberry PI is excellent as Web Server and gateway to real-time systems. The same goes for user interface – GUI/HMI, but that’s my preferences.

I have ordered kit’s to play with many of the new ST MCU’s. Ordering MCU’s at this time is almost impossible as it is very long manufacturing delays all-over due to the aftermath of the pandemic. I order ST kits from digikey and just add sufficient kits so I get free P&P – so far this has worked great with packages arriving after 2-3 days. Attempting to order anything from China these ways are also difficult due to prices. Hopefully the world will normalize the next 12 months – fingers crossed.

BSA – Drawing Flowcharts

BSA is moving on and is getting more advanced on the diagramming side than I actually planned for in this first version, so one option I am considering is to create a free flowcharting tool. I basically only need to wrap up some of the interfaces and add a print/preview option in addition to custom libraries and it’s done.

This screen shows the polygon tool. You click with left mouse button to add edges and with right mouse button to the remove last corner. I am very happy with how that worked out. Drawing polygons with shart or rounded edges is a must for creating custom components for HMI or diagrams. I need to add text fields connected to a property etc, but I am thinking that this is becoming a very nice semi-automated drawing/flow-charting tool on it’s own. I have often tried to find free ones and end up with some tools that are not well suited for diagrams. BSA on the other hand is designed with semi-automatic diagrams in mind.

The diagram above took me around 30 seconds to draw as is. I obviously need to adjust default property content, and yes this is SDL, but if I start creating custom symbols I can draw any diagram very fast with proper automated content.  Adding PScript I can also let users automate content. The usage would be as a free flow charting tool and BSA viewer to assist in discussions. It is worth considering at least. I need to think a bit on the total work-load, but adding customs control- and symbol- libraries add a lot of value and with PolyGon in place it is becoming an easy thing to do.

Process diagrams are also important as it would be easy to let a process engineer draw hes/her own user interface and send it to a SW engineer that links it up in the HMI with little or no extra work. This can be done with other diagrams as well. Using high level diagrams as specifications tend to increase quality, but you need specialized drawing tools or you end up spending too much time on the drawing part.


BSA – User Control and User Diagrams

This actual screen dump from BSA illustrate both User Control and User Diagrams. The diagram to left is a process diagram very common to a lot of industrial control systems. This diagram is the actual, main  user interface in this case. The User Gauge to right is just an illustration made by 3 polygons and a circle on how to create a 3-Way Valve symbol. I need to work on the User gauge function, but this will privide one way to create very powerfully user gauges/interfaces.

The “Function Name” will be replaced by a unique gauge name that is listed in the left toolbar together with build-in tools. As mentioned before – BSA will contain two different tool libraries – one is build into BSA and cannot be changed, the second is user libraries. The build-in tools must be static to ensure that BSA alsways remain functional.

Since we now allow user libraries I have a second issue – what if I save a project and import it to a different computer? The obvious answer is that the saved file must be stand-alone and include either a reference or a copy of the user library. A reference should cause BSA to prompt for installing the required user library and maybe replace missing library components with a “TODO” something. BSA will compile the output checking integrity, so non-functional content should result in an error.

Keep in mind that this will give one way – not the only way – to create user symbols. The usage above have it’s limitations + you can use older user symbols to create new ones etc, but you can also create user content in old, fasion code. One obvious part here is that a user symbol also need an associated property list/tree that the user must edit.

Another challenge is mixture of automated and manually located lines – with diagrams being user interface themselves I need to care about manual control (positioning) of lines.

Also notice the small dot (above). This is a link connector and is a normal symbol that allows me to connect link lines to show what lines are connected and not. It also gives me manual control of the connect location. I can create 2-Way that rotate, 3-Way that rotate and a 4-Way version of this and I have full manual control of diagrams. I can later add auto-inserion of these to make diagrams a little easier to control – if needed. This can be used on all diagrams. As with all these ideas – I have to draft them and test them in actual usage and it is not always an idea proove to be a good one, but that is engineering for you.

BSA – User Control

One of the big things with any GUI/HMI is the capability to quickly create new user controls. The method I want to use is to let the user create this using a state-matrix. Layers in rows with layer 0=preview and columns as states. The control is illustrated above.

In this example I plan to rotate the needle on layer 2 to create a simple clock gauge. To do this I set in config that input value goes to layer 2 and on each state I connect that with rotation of the line. The final result will be a gauge that change background and needle color based on state.

I have some experience creating gauges in code and think  this will be a big time-saver + I can link cells to code if I need to and do other tricks. I am coding this as we speak so give me a few days and you will see it in action as we start adding user HMI libraries to BSA.

BSA – WPF Dark Theme

And there we area – still a bit work in progress with styling details, but I have passed the point of no return.

Back in the days then I coded MFC for User Interface I often upgraded my apps almost for free by just sticking to classic development. This was what I did here as well – I ignored dark theme assuming I would find a solution that could provide that for free. The solution is the 2nd on Nuget list – import a single style sheet, write a few lines of code and style up the places that needed manual styling – and voila.

I am ok working with light style, but dark theme is so much cooler and most important of all – I use colors and styles that get me into better moods. And yes – I need to change some of the above as this still is work in progress, but I am actually impressed over how fast and easy this actually was.

What I have done technically speaking is to avoid caring about colors and used a style sheet that override colcors and style for standard Windows components. I don’t fully understand all the XAML code yet, but I like the results and way of doing this as it means I can have different style sheets and completely change the look of BSA – but, that’s for later.

BSA – WPF Dark Blend Theme

Work in progress. I found an example of how to change the style of Windows controls and voila – all the controls I have not styled myself changed. Notice the scroll bars etc. This is what I liked with Visual Studio back in the old days – you just stayed loyal to their scheme and suddenly get a lot of work for free. I need to update the rest of the color codes, but I can now go dark theme with close to no extra work. This is exactly what I hoped for as I decided not to dig into dark theme yet.

Also I discovered that the property folders I want actually exist – called “Expander” so I need to do less work than expected to build a property editor the excact way I want it. The Blend Style example that convinced me is seen below. This is basically a single xaml style file and a few lines of code added to you project. I was surpriced about how little extra code it was. For those interested you can find the original github code here under MIT license. Next time you see BSA will be in it’s final dark style. The all gray style used below is a bit booring in my eyes – I need a little bit more colours to light up the moods.

I don’t fully understand the styles.xaml yet and it is still a bit work in progress, but this was a very convinsing demo about how powerfully WPF/XAML actually is. I don’t pretend I like everything in it, but what I like is the sum speed of productivity you get – hours needed to make an advanced GUI solution. WPF is suprisingly fast to work. It’s been a few tweaks on the 2D engine, but I am very happy with the results and hours I needed to get there.

In comparison – I can (and am) doing the same in QML. I get the job done in Qt/QML as well, but working with QML is a steady stream of technical problems and an IDE that don’t do it’s job. The sum is that to do the same I use close to 5 x as much time. In WPF you write C# and XAML, but in QML you write C++, convert to Qt++, do QML bindings, write QML and JavaScript. It simply is a larger job to start with and add a poorly working IDE on top of that. That said – QML compares well to technologies we used 25 years ago like C++/MFC. And more important – QML and WPF is the only technologies I have seen that make using GPU’s decently easy. I have yet not tested the new MAUI, but I will.

The main reason I still work on QML is because I have auto-generated most of the difference and need a SDK that I can use to generate code for. While my primary target will be C# itself I also intend to pick up targets like QML. The result will be a huge difference in number of hours needed to code up systems – just stay tuned a few more months and BSA will be airborne.

Cost wise QML is a nightmare – Qt/QML with their designer cost ca 50,000.- NOK, while Visual Studio cost ca 5000.- NOK. And add to that the well of libraries like this one you find in Visual Studio. Just one advice – be very sceptical and think through what you import as you pick up nuget packages. Myself I only use MIT or similar licenses and source code unless I buy a commercial package. Make sure the library you pick up fits the bill.

Happy coding!

BSA – Starting HMI Components

This list will increase, but I need to start with some basic components. The first version I need is HMI only together with a few other components:


Generic definition of a source that can be connected to a HMI component to read/write data. This will be a named component that is implemented manually allowing us to generate code.


Window/Form used to hold everything else. Only components displayed over a Form is visible thought BSA allow invisible components outside the form. Form has options for Caption, System, minimalize, normal, maximize etc. Form is just the main container. Typical Form is a desktop window, but Form can also be a report or Web page.

Panel A square container that holds other components.
Label Text label.
String Edit Single line text edit.
Number Edit Specialized Number Edit.
Button Button with style options.
Checkbox Boolean checkbox.
ComboBox Edit box with selectable list.

Multiline text edit field with optional mini-editor controls.

Group A frame container with title in the border.
HScrollBar Horizontal scroll bar.
VScrollBar Vertcal scroll bar.
Image Picture/Image.
Menu Main Menu
MenuItem Menu Item.
StatusBar Status Bar
ToolBar Tool Bar
TabBar Bar with tabs allowing you to select one of many pages.

Container allowing one of many pages to be selected. The container outline the page area and link to an index component like TabBar. It can also visualize selected pages, but the pages are defined on separate Panel containers.

ListBox Standard List Box.
TreeGrid Grid/Tree hybrid allowing first column to be a Tree.
Layout Grid

Invisible grid allowing other components/containers to be positioned and scaled.

Circular Gauge Standard circular gauge.
Bar Gauge Standard Bar Gauge.
RT Line Plot

Specialized Real-Time Line Plot designed for high speed data visualization.

Led Colored status indicator.
User Components

All components are a visual representation with a property list used to generate code. So I want a list of “build-in” components that the user cannot change to get started, but I also want to give the user a capability to add their own content. I have to return to how to do this.

Gauge Designer

A specialized gauge consisting of multiple layers put on top of each other. Should give the user an easy path to design theire own animated gauges.


A mini state diagram allowing the user to specify a timer and what happens on that event.

This list will change and grow. The main challenge here is to limit the scope of this first release so I actually can release a first version. Also keep in mind that we are not just designing the screens here, we are actually coding the content as well. I have fetched HMI content from standard GUI designers, but it is important to remember that this is a design specification used to generate code. That gives us far more automation options. Using Modbus as an example – I want to grab a Modbus map as data source and be able to create a fancy desktop application in minutes and literally have the same on desktop and web without thinking about it – it needs to be that easy.

BSA – HMI Form Properties

The easiest way to discuss properties is by discussing actual components, so I start with HMI Form. The terminology “Form” is well known for C# developers. I could have used dialog, window or whatever, but decided that “Form” is a good word. What you see below is the current HMI Form draft used in BSA. I will make this a bit more WYSIWYG later, but this is NOT the actual Form – this is the design of a Form. The actual Form will be generated from BSA. In this case I illustrate a Form that is a Display dialog containing a property list that design look and behavior. The result will be a long list of properties, but my experience with this from C# and other tools is that I 99% of the time only use a few selected properties – so lets start with those:

Colors and Style is something I set and later reuse. So the best idea is I think to remember what was last use and use that as a starting template. Simply said this is something I change once and seldom use so it can go into background on a separate page.

  • Description is very nice to always have in front.
  • Name of component
  • Caption Enable and Title
  • System Box enable
  • Minimize, Normal and Maximize box.
  • Starting Window state
  • Window Size and Scale limitations.
  • Window style – modal etc

The idea is to put the properties you actually use a lot and will change on a default front-page, while all the colors and nitty gritty details can go on specialized pages. The rationale for this is that I often spend time looking for things, so I want to see if I can make this a bit easier. The components will need a lot of properties so it makes sence focusing like this.

To do this one I will need the following completed:

  • My mini dopcument editor.
  • Standard single line text editor for name, title.
  • Boolean to enable caption, boxes and features.
  • Number editor
  • Combo box.
  • Color editor.

Form is a container for other components so it has no direct data-links.

BSA – Property Editor

The next task on BSA is to get my Property Editor functional. What you see above is an early demo draft to test a concept. I just wanted to get a feeling with how this could be done and test out the “Text Edit” part. The concept with a Property Editor is that you click on a component in a diagram and get properties for this displayed. Some of these properties are documents, source code and tables making them a bit complex to integrate without to many trade offs.

I considered using an existing Property Editor, but (1) WPF does not contain one, (2) this is a very important component for BSA and (3) it is actually straight forward to implement if your not afraid of huge work loads. It is a large job and you will get tired of me blogging about various editor details as this evolves, I will need a specialized editor for each datatype I use. Some are very straight forward, while others will need a good design and some fresh ideas.

It is three editors that are of special concern – Tables, Text documents and Source Code. These can all be implemented as a property line. Text document is illustrated above. This was far more capable than I first expected as I can widen the Property editor and get a larger doc. But, having all tables, docs an source code like this have it’s usage and limitations. I will need something more.

Having source code as part of the property editor is usefully as you want a quick look by selecting a block on a diagram that contain source code. You can see and even edit in the mini editor, but I thing we all agree that we can’t do more serious work here – we will need a proper source code editor. So the idea is to do both allowing Tables, text doc and Source code to expand into being a full View in BSA itself. This might also work for sub-diagrams. I obviously need to experiment a little around this and see how this works out. But, this is a functional area that will decide the success of BSA – it is that important. If I don’t get this to become something that is very convenient to use the entire tool will become a big, clumbsy failure. The reason is obvious – time usage.

This is the one thing you need to have in mind all time – time. BSA is  a productivity tool that should enable you to do more faster. But, I have used so many tools in my carrier that ended up as a failure that I am well aware of the danger of repeating that failure if you make the wrong choises or compromizes.

BSA – Integrating PScript

I will need an editor for PScript and the most obvious path is to integrate this into BSA as a building block. PScript evolved from an experiment into being a Plain Interpreter and this makes it easier because I can actually generate source code for other languages from PScript. Meaning you can write PScript and either use Plain, C++ or C# as your target platform – which can be done by either integrating PScript or generating target code.

Plain will change based on the experience with PScript. The VM I drafted for Plain is complicated and I realized that I probably can simplify things a lot by building a Compiler based on the Interpreter. I need to test this new idea a bit later, but the only difference between an Interpreter and Compiler is that an Interpreter execute source code, while a Compiler generate executable code – in Plain’s case I can actually generate C++ or C# etc.

Obviously I can also use PScript as is. This was intended as an Interpreter running embedded and I can easily create a C# or QML PScript component adding HMI libs. For C# I need to create a component that convert between natice C++ code and C#. With Qt I basically need to do the same. While Qt is C++ it has so many tweaks and separate datatype definitions that you end up converting C++ to Qt++. QML/JavaScript Integration comes on top of that.

As for PScript Editor we also need an integrated debugger, but lets take one step at the time. My first PScript editor will not impress anyone, but it comes a day tomorrow 🙂