New Motor Controller

This is a Dev kit from ST that is a complete Motor Controller in ESC format with 3 current sensors, 3 BEMF, 3 discrete Gate Drivers, Hall sensors, temperature sensors and 28V@120A Solution. The MOSFETS are rated at 120A with 480A pulse, but heat dissipation causes them to be limited to max 40A with hard fan cooling. The kit cost around 20.- USD so I bought 2 of them for testing.

Using ST’s Motor Profiler I got motor data that I imported into their motor workbench, generated a project for STM32CubeIDE, Compiled it and was running the large drone motor in an evening. The generated code include a serial protocol that match their Motor Pilot application and voila – the motor span up.

The Motor Pilot application is shown above running. In this case I have only connected the USB that act as a serial port and I have not switched on the driver power, so the motor driver report and undervoltage alarm as it should.

You receive 90% of the source code. The remaining 10% is in a library that ST preffer to avoid sending out since it contains patented algorithmes, but questioning ST I got an answer that they could send me the code if I signed a NDA with them – so all code is available free of charge.

What impressed me was that I had the large 1,2KW drone motor spinning and controlled without writing a single line of code and still had all required code I needed to work on it myself. I have friends that have tried and not been successfuly in using this kit, and I had problems myself as well. As mentioned before – you need to be willing to try & fail a bit with source code from ST as they have an improving, but far from perfect SW quality. ST is however improving a lot. I have had far less issues with STM32CubeIDE and drivers lately than earlier.

The autogenerated settings worked, but I did not like the ramp-up logic. I managed to tune it so the motor started ok, but I suspect they use a Trapzoidal algorithm to spin the motor up in speed and then take over with FOC as current readings are safe. As they switch the motor over compensated and span forth and back before speed regulation was correct. I managed to fix that without any coding by changing their PID regulator.

The MCU on the kit is STM32G431CB that runs at 170Mhz, 128Kb Flash and 32Kb SRAM. I only use ca 40Kb Flash in the code, so plenty left to play with. G431 have analogue components on-board that makes current sensing easy and fast. Programmable Op Amps allow you to adapt analogue signals to the motor you use etc.

I mentioned this was an ESC, but it also comes with 5Mbps CAN-FD Tranceiver and the total size of the kit is 17 x 41mm – half a finger in size. It has a ST-Link 2.1 attached that you can break off. ST-Link 2.1 have also comes with an UART crossed into the driver and connected to the USB, so by default ST-Link enable a UART as a Virtual Com port that is great for debugging. Another great feature is that I can connect and work on SW without powering the MOSFET drivers – using USB only.

And best of all – I have all schematics, so it is easy to adapt this kit to a more sensible form factor. The dev kit is to small for my usage – I want to change DC/DC to 60V so I can run with 48V + I also want to attach more heatsinks to get more currents out. The small PCB I got have 8 layers and is very dence. Small is not always good in this case.

The picture above show the Wotkbench that basically is a diagram over the SW logic. You click on different parts to get a screen allowing you to edit parameters and then press a button to generate a Cobe project with code.

All in all – if you wanna work on motor controllers this kit is a must in my opinion – it will get you started with full schematics and all source code in a matter of hours. Well done ST!


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.