This shows a simplified BSA Workflow. So far I have mostly blogged about the BSA Designer that will read and write a project repository – or more exact an xml file. The content of this file is used by BSA Compiler to generate Errors or Target Source Code. Source Code is generated towards a target SDK that is a pre-made library for the selected target. These can be used by 3rd party compilers to generate executable images.
Errors are feeded back to BSA Designer so that the user can correct them. BSA Compiler will allow you to design and make errors, but it will not create source code unless errors are fixed and the repository support executable accuracy. The rationale behind this is that larger systems needs to be drafted before it is worth adding all details, so the designer will never stop you, but the compiler will. I am considering a JIT style compiler so that errors can be listed as you design, but I will look into that.
BSA Debugger connect directly to the executable using easyIPC and receive feedback as the application executes. This will allow us to monitor or run single step execution on multiple modules simultaneously. Keep in mind that a BSA System might be multiple executables running on Windows, Linux, embedded platforms etc.
I have plenty of loose ends in the Designer (Work todo), but Compiler and SDK are on the table next. I need to get started on these because the design/implementation will drive the last part of the designer – speciall properties.
Some time ago I planned to focus on HMI as first out. That has not changed, but HMI dragged a lot of other stuff with it. My first target is Windows C#/WPF for natural reasons since that is what I use for BSA itself. My 2nd and 3rd target will be STM32 and Qt/QML. I already have half-made SDK in QML. Part of the SDK’s are the gauges I curently work on.
BSA is generic in nature allowing you to make whatever system you like, but I will focus a lot on real-time, distributed systems and advanced HMI.