I’ve wanted to restructure the code that produces a list of vPorts and associated parameters for some time now. On the first board designs it was all hand crafted (did I hear beautifully?) and specific to each boards requirements.
This worked well and made frequent use of the copy and paste features on our development environment (code reuse at its best?), however it does slow down development of new products, particularly with some products requiring a lot of data cells to be displayed (think of routes and the 32 port input and output devices, due this summer).
The goal has been to programmatically generate these two dimensional tables from a few parameters and this has now been achieved.
If you look at the software stack for any System2 product you’ll have:
- Application code running on the microcontroller written in C.
- Presentation code on the web browser running a mixture of HTML and JavaScript.
So these two sides of the stack (say, the left and right hand) need to be in sync with each other so that:
- The web page only displays inputs or outputs that match the hardware it is running on.
- The server on the back end has suitable memory structures to manipulate and store the web data for the hardware it is running on.
- The communications channels are established between browser and server (the System2 product).
All the time we also need to take care that we don’t break anything or allow out of range data into the system spoiling anyone’s fun.
With the new generated code driven from the same data source the system configures the front end and back end consistently and efficiently. Changing a single number can be the difference between controlling 8 or 100 outputs on a single System2 board including all the back end housekeeping required to make it work.
No, were not producing 100 port devices, we just tested the large numbers to evaluate memory usage and see how it behaves under stress.
This was not without its challenges as serving 800+ data elements to the browser can swamp the back end processors (they are dual core). To solve this we’ve implemented queueing and throttling of bulk data transmission so your device still remains responsive to operational network commands while all this is going on.
I think the big data requirements will be for the planned System2 Route Engine where you can have a lot of routes with a lot of components within a route. We don’t know limits yet, but suspect you’ll only ever need one for any size layout.
One of the best things we did with System2 was to implement easy software updates that are both customer driven (optional) and free.
Exciting times ahead.
The screenshots below show an example of the Stall/Kato board programmatically configured for 8 and 20 devices.
