BasicPI

Programming HMI with C#/NET 4.7.2

Posted on by Jan

This demo is a bit in the early stage, but I am using C# and .NET 4.7.2 for a simple test. I developed in C# a few years back and was a bit dissapointed over performance. But, I notice that this have improved dramatically with later .NET versions so I am putting it up for a test. What interest me with C# is that the combination of language, Visual Studio IDE and libraries/framework makes it very productive to work with on the HMI side. What have dissapointed me in the past was performance. I have similar demo using Qt and I have to admit that I have not been convinced about Qt performance either.

What I am experimenting with here is a graphical programming language. In this case I started on UML State diagrams. I am not sure if I want to complete this, but I was using UML State diagrams earlier and know it add some value. I simply want to see if this is a path to pursue if I start using this to generate code. The demo you see above was knocked up in ca 2 days work including scrolling/zooming and a lot of the basic graphichs work.

C# itself is much slower that C++, but C# graphics uses optimized C/C++ libraries and I must admit I like the improvements I see.  What actually convinced me is the plot below. This is done in raster graphics with 10 line plots containing thousands of points and update itself ca 27FPS. This is a stupid test to verify if raster graphics are sufficient for my graphical designers.

The difference between C# and C++ is that .NET (that is C# VM) actually have started using more kernals on HMI. So while it is slower at first it seems to get the upper hand because it can use the entire CPU while C++ libraries are stuck with one kernal. I know I can get a much higher performance using C++, but that will require that I put in a lot of work. This is also why I tend to stick to 2D raster graphics – I lack a framework that can do the same on 3D engines without a lot of work first.

One of the drawbacks with C# used to be that it was Windows only, but both Linux, Android and iOS has since then been integrated into Visual Studio. We will see where this leads.

12 x PWM Hat

Posted on by Jan

 

I have so many Hat’s by now that I try to make some systematic documentation on them. This drawing is part of what I call “Annotated Schematics” to document the design and collect notes needed for working on the Hat. This example is one of my more powerfully Hat’s as it contains 12 separate PWM ports with current sensors. PWM ports are actually separate Half H-Bridge ports with a GND connector each for maximum flexibility.

  1. Standard CAN port.
  2. 6 x PWM and 6 x GND connectors. Can use different terminals, but is designed for a right angle terminal to allow the Hat to be stacked.
  3. Current sensors. Separate current sensor on each PWM High Side, meaning we measure current out.
  4. Power connector for PWM supporting 60V.
  5. Capacitor Bank.
  6. Leds. One power led and one status led.
  7. USB port.
  8. 5V Power.
  9. Current Sensors.
  10. 6 x PWM and 6 x GND connectors.
  11. PWM Drivers. In this case I use DRV8301 that contains 3 x separate Half H-Bridge drivers. This can be combined to drive 12xindividual PWM signals of 60V/2A, 6xDC Motors, 4×3-Phase Motors, 3xStepper motors or any combination you like. Each of the DRV8301 have power pads connected to back of the PCB and I can actually mount a heatsink on this one if needed.
  12. Standard SWD connector.
  13.  na
  14. STM32F405RG
  15. Raspberry PI Connector with SPI Backbone and 5V. Enables the Hat to be used with Raspberry PI in a stack, stand-alone or together with other Hat’s.

This Hat is so powerfully that it replaced a lot of other Hat’s I planned. I was considering a separate Stepper Motor Hat or DC Motor Hat etc, but I don’t see the point. This is one of the most flexible motor drivers I have made. If you go back on this blog you will also see my notes on how many attempts I made on routing this before I succeeded. So far it is only minor comments on what needs to change.

This show another part of my “standard” documentation, the functional block diagram. This is basically just a visual content list.

I have done PWM signals before, but I am looking forward to experiment with the current sensors. If I use current sensors on a Stepper I should be able to sense torque and automatically detect edges etc.

The reason I started assembling this now (it has been around for a while) is however x-mas coming up – powering multi-colored led string.

 

 

PWM12 – Current Sensor

Posted on by Jan

I have started assembling the first PWM12 board and this is the current sensor I use. It will probably work ok, but the circuit lack two important components. One a small capacitor between CSense and ground and secondly a TVS between the same. The reason is I could have needed those to protect the MCU against pulses, but I had no space for them. Hopefully INA193 will absorb the pulses if we have any.

Buck Converter working

Posted on by Jan

Soldered up a new board just to realize that DRV8301 was bust as well, so replaced DRV8301 and Buck converter is actually working. I am getting 3.4V just enouth for SPX3819 to give 3.2 out and the MCU ticks at 168Mhz. Looking at datasheet I also see that I have done correctlt – EN_BUCK should be floating.

I suspect that I busted the MCU partly by giving it 15V on the ADC by mistake – who knows – I still have components to solder on, but it’s a good start on my 2nd board.

Had to scrap yet another MCU as well. I soldered a new MCU, but it did not tivk properly. This one is from a different batch, so I hope to be out of the bad batch scheme – I am buying these MCU’s from proper distributors next. Talking about MCU’s checking pricing through Arrow I realize that STM32H753Vx is not much more expensive that STM32F405RG – I think the V version with it’s 100 pins is a bit large for most of my projects thought. I am also a bit dissapointed over IDE support on H743 yet, but I get it working.

Expression Parser

Posted on by Jan

One key component of any Parser is the Expression Parser. This one is used to parse mathematical or logical expressions into a list of micro-statements. Plain have a separate instruction to execute math, but the parser need to build the list correct.

Example : 4 + 5 * 3

If we add 4+5 we get 9 and if we multiply that with 3 we get 27 which is wrong because * (multiplication) have higher priority than +. So the correct processing is:

5*3 gives us 15 and adding 4 gives us 19.

I have a preference for using tables to compute expressions. I need one temp table, a operator priority table and an output table for micro-instructions. The algorithm is quite simple as we parse a value and a operator before we evaluate the tree.

First is 4 +. As this is the first we can’t do any temp calculations.

Second is 5 *. Since * have higher priority than + we just add it to out temp table and parse 3 =. Our table will now look like this:

  1. 4 +
  2. 5 *
  3. 3 =

=is the highest priority so we now output a micro statement:

  1. t1 = 5 * 3

And we modify our table to the following:

  1. 4 +
  2. t1 =

Next we output t1 = 4+t1. t1 is our result leading to a small math script as follows:

  1. t1= 5 * 3
  2. t1 = t1 + 4

What we now lack is parenthesis, variables and function calls and we have an algebraic expression parser. Many language parsers will build the language on this, but my preference have always been to handle the language and expressions separately.

Dealing with this in plain was a challenge because a normal language would implement assembly instructions like Add, Sub, Mul, Div etc. At this point I decided to implement a math instruction that take the parsed tree as input to enable math to be done as close to C as possible. This keeps the instruction set small + it preserves execution speed.

Plain Syntax Alternatives

Posted on by Jan

One of the challenges I have with Worldpress is to be able to show source code in here, so I apologize for the bad quality on the examples above.

The examples show one of my Plain test examples in 2 different syntax styles. the one to left is the currently chosen one and the one to right is the more C++ alike version and decided to leave for now.  My rationale is that some of the syntax is more difficult to express using CPP style and since Plain and C++ will co-exist it would create too much confusion.

Plain Assembler

Posted on by Jan

The Assembler itself will read Plain source code and generate a RTL file that is downloaded to the device. RTL (Real Time Linker) is located on the target device and will convert RTL format to executable Plain VM instructions.

Most modern Assemblers are very similar to Compilers. The main difference is that the Assembler have a syntax that is close to the native assembly or in this case VM instructions. That said Plain is actually a high level language, so the technique used is a classic Descent Recursive Parser assisted by tables.

Any Assembler (or Compiler) will consist of 3 components; a Parser, a Repository and a Code Generator. The Parser read Plain code and convert it to a repository (database) over the code. Once done it call the code generator that in this case generate RTL Code. One of the differences with Plain is that the Repository is exposed and can be imported and exported as well as accessed through other applications.

The Repository need a XML repository file that define the target platform and available libraries/modules on that platform. This together with the Plain source code form the final applications.

While the assembler “PASM” is one application we will also have several other command line utilities and file formats. One is the output reports from the repository that can be used for IDE integration or libraries. Another is the download utility, but I will return to those in due time.

Plain has been a long coming system since I needed to create HW supporting Plain, FW supporting Plain, VM Engine, RTL as well as the assembler itself. It will still be on-going for a while, but I am not that far off demonstrating the first Plain applications.

 

Train Control System Rev 1.2

Posted on by Jan

I started this blog with a Train Control System that basically failed big time on the positioning system. The solution I attempted was possible, but to large and expensive for small model trains. I later upgraded the control system to ESP32 which definitely is the path forward, but it is time to make another attempt on positioning as well. I will nor reveal the technique I will use yet, but this is low cost, small and have a very good chance of working as required.

The core functionality of the controller is a PSU consisting of a rectifier and a regulator giving 3.3V and 12V out.

ESP32 provide CPU power, Wifi and Bluetooth capabilities.

A standard H-Bridge allow us to control motors up to ca 0.5A

An external USB programmer is needed since we do not have space for the programmer logic on the controller.

The main challenge I have is size – even ESP32 is a bit big, but it is new , smaller modules around. The one I will use this time have an IPEX antenna enabling us to use a smaller board and hide the antenna a convenient place. It even exist a module smaller than this, but I have not had my hands on this yet. One option here is to replace ESP32 with a smaller ESP8266 module, but I preffer to stay with ESP32.

Another option is to separate the H-Bridge and PSU away from the main controller and position them closer to the motor. The advantage with this is the obvious separation of the noisy PWM components as well as space. It would also open for different, more powerfully motors or even multiple motors. The drawback is that we end up with 2 PCB’s as a minimum.

The position sender is a bit special and the receiver will be part of my Hat based control system. I will return to this in a later article.

The magic poof of smoke

Posted on by Jan

I have done a mistake by leaving EN_BUCK floating. The doc is a little vage around this area and I have copied that from other references that probably was not using the Buck Converter. The buck converter works, but it seems to give very little out. 168Mhz uses more than 84Mhz and power starts misbehaving. I tried to solder EN_BUCK to 3.3V, but a short-cut gave the magic poof of smoke on the MCU + DRV8301 looks weird afterwards – next board I assume – blah – I will make another attempt on the Buck Converter tomorrow, but if not I will just move on. This change is however the only one that might force a new PCB so far because it is very tight and hard to fix on the current PCB.

Looking at schematics I see I shorted 3.3V to PVDD and basically feeded 20V straight into 3.3V circuits – blah – it means DRV8301 probably is OK, so I could rip the board to test the buck converter alone – can’t do more damage anyway :). Looking at TI’s reference schematics I am convinced my mistake here is EN_BUCK. Using 3.3V is however not optional here since 3.3V depends on the Buck Converter. I need to make a voltage split from 8-60V that drag EN_BUCK above 1.25V. Voltage is clamped to 5V internally anyway I notice. That is sadly 2-3 more passive components.

This design have some complexity so I would like to see PWM, Temperatures and Current Sensor logic before I order new PCB’s – I can do that by simply feeding the MCU from a 2nd PSU and avoid using the build in Buck converter. It is not ideal, but it allows me to test a bit more before I move on.