I am currently in the process of developing vscpworks+ a new version of the VSCP Works toolbox. This is something that has been in the pipeline for many years now as the old version is pretty old and outdated at this time.
The previous version was developed using the wxWindgets framework and I never quite liked it. It is non intuitive and hard to work with IMHO. But at the time when it was selected, QT, which was the alternative GUI framework, had strange licensing and a very unsure path ahead. Well a bad choice as it turned out.
The year before last year I removed all dependencies of wxWidgets in the core code of VSCP software. That was quite a rewrite I can assure you. Now it is dependent almost only on standard C++. Now when that has been done time has come for the rewrite of the VSCP works toolbox.
My goal is to handle all the standard pieces of the VSCP specification in VSCP Works. Many are missing just because I thought that the old project was a dead end and that there was no meaning in putting in to much development in that end.
So this is a rewrite also. A large project. (Help is welcome 😉 )
But it not about the VSCP Works rewrite this post was supposed to be about. It is about CANAL.
Many many years ago I did the CANAL specification and it’s API as an abstraction layer for CAN (CAN Abstraction Layer). The thought was to select something really low-end and build VSCP functionality on top that. Thus allowing VSCP to work on really low end devices and on high end devices. Nope there is no tcp/ip and json at that level. Sorry.
The CANAL spec has survived over time and is more or less unchanged since it was created. Companies like Rusuka and 8Devices and others use it for there devices. It’s main use here is of course as the VSCP Level I driver API. The last common denominator format for a VSCP low end device is outlined from the constraint set up by this interface.
On the client side, there is the VSCP daemon that use the API, but there is also C/C++ code available, Python code, node.js code and more. (See https:docs.vscp.org)
The CANAL specification has one method that I never used in my client implementations (because of the reasons above) but which I think is very nice and beautiful indeed. It is a method that allow a CANAL driver to tell it’s client how it should be configured. This method should be implemented for all CANAL/VSCP Level I drivers and is called canalgetdriverinfo.
Before I go in to how it works I need to explain how CANAL/VSCP Level I drivers are configured. It is simple. There are a only two items that need to be configured.
- The configuration string which is a semicolon separated string with driver specific configuration values.
- The flags which is 32-bit unsigned integer where each bit or group of bits can be used for configuration.
So for the simplest of driver both of thees could be empy and for a really complex driver there could be many many complex options.
What the canalgetdriverinfo method does is to return a XML structure. This structure explains each option both for the configuration string and for the flags integer. The thought is of course that a client software, as soon as it knows the path to the driver, call this method and parse the XML content and then can be able to support the user with the configuration of the driver. Easy and nice and beautiful.
The XML object is constructed in such a way that it can present the configuration of the driver as a step by step wizard. So by going through the steps the driver can be set up in a way an end user (yes it could be a machine to) wants.
So in vscpworks+ when a user defines a CANAL/VSCP Level I driver this option will be present. Making it very easy to configure drivers without looking for documentation topics. The code is encapsulated in a couple of C++ classes so this code can in turn be used by other projects including Python and node.js code.
Just simple and beautiful as VSCP itself.
