How to manage a microcontroller, without attracting the attention of orderlies
Microcontrollers are everywhere, in transport, at work, in medicine, in everyday life. Thanks to them, the ability to “solder a lot” was replaced by the ability to program. The fact that yesterday it was necessary to re-solder is reprogrammed today. The elementary multivibrator, for the project of the next tweeter, performed on the microcontroller, will be more reliable and cheaper, the analogue on separate components. And such a trend, in my opinion, will only increase.
A part of not complex projects on microcontrollers, such as light switches or level sensors, once debugged, no longer require any additional settings. However, most projects still involve interaction with the outside world. For example, a thermostat or a timer needs the ability to adjust and control given values. Most often, this function is implemented by adding user interaction mechanisms to the project. And the simplest project begins to acquire screens, buttons, encoders ...
Part of the already limited resources of the microcontroller goes to the maintenance of the entire infrastructure of user interaction. As a result, the core carrying all useful functionality, the microcontroller and power switches, occupy 5-10% of the physical volume. Everything else is auxiliary, screens and buttons.
This state of affairs is almost universally. Significant efforts are spent on the creation of all these control panels for TVs, air conditioners, refrigerators, machine tools ... Crazy multi-level menus-quests are composing ... In addition, all these built-in mechanical buttons and encoders, screens often break. In some cases, resulting in the uselessness of a fully functional otherwise.
')
At the same time, all these buttons and screens have limited potential for use, compared to any mobile gadget in the pocket of each of us ... With a convenient, large, contrast, touch screen and a fairly productive “iron”. In addition, many on the shelf gathering dust no less powerful, completely serviceable, outdated, device, sometimes not one. Which to throw out ... until the hand rises.
In this regard, it would not be bad, in projects on microcontrollers, to completely abandon screens and buttons and transfer all the functionality of monitoring, control and control to mobile devices. Well, or on computers. As a result, in my opinion, it will be more user-friendly and more effective solution.
Work in this direction is already underway. For example, there are models of floor scales , which through Bluetooth allow not only to see the weight on the mobile phone, but also to track the history of its change. However, so far, the built-in weight indicator is still not discarded .... until.
I think, soon enough, everything will come to the fact that having bought a household appliance, the user, in order to use its functionality, will need to download from the manufacturer’s website, and install the application on his phone.
So why now, since the advantages are so obvious, don’t start transferring from the microcontroller a part of the user interaction functionality to the side of mobile devices.
The answer is simple.
It's complicated.
Distributed systems are always much more complicated.
And the complexity is not in the very principle of communication / transport, which has already been managed to be formalized as UART, I2C, CAN ..., but in the complexity of writing the protocol itself over transport. Some of the problems: tracking the failure of the channel, requesting a retransmission, scheduling packets ... for machines with sufficient resources, could be implemented as TCP / IP. But the rest, the writing of the actual communication protocol itself is specific for each project and requires considerable expenses. One of the ways to simplify the problem can be automation of the programming process.
For this, as a rule, they create a language (DSL) with which they formally describe a protocol, and then create a program that, based on this description, generates source code for various target platforms in the required programming languages. There are a lot of examples of ready-made solutions in this style.
Protocol buffers
Cap'n proto
Flatbuffers
ZCM
MAVLink
Thrift
The complexity of the exchange protocol can be estimated by one of the descriptors of the exchange protocol with the quadcopter. In this example, XML is selected as the protocol description language.
For microcontrollers, many solutions from the world of large machines, such as TCP / IP, are not applicable due to limited resources. We have to remember and use CRC , Bit / Byte stuffing , Endianness , and also take into account many other, sometimes completely unobvious subtleties like this or that . Attempting to solve a problem by manually writing code can turn a programmer’s creative life into hell. Similar to the one that was with java script support on different browsers. Only here are different languages on completely different platforms. Even small changes to a debugged protocol can lead to a very long debugging process.
Not many of the above tools, in their kodogeneratsii fall to the level of microcontrollers. Attempting to use the mentioned code generation tools hardly managed to pull on the older 32 bit series microcontrollers. The most popular, cheap and widespread 8-bit microcontrollers were left out. I very often come across projects in which the most correct would be the removal of controls on a mobile device. Sometimes it was possible to do this, but further maintenance and expansion of the functional became very difficult.
Having gained considerable experience in using existing code generation tools, understanding their advantages and disadvantages ... after a while I created my amusement park ... BlackBox .
The code generator itself was decided to write on SCALA , the well-known language JAVA was taken as the basis for the protocol description language.
Why is that? The language is simple, for JAVA the largest number of really convenient development environments has been created. It turned out to have enough language constructs in order to describe not only the types of data transmitted in the packet, but also many additional characteristics and, very importantly, the network topology.
BlackBox generates source code in the following programming languages JAVA, C #, C. Support for SWIFT is planned .
At the moment, the BlackBox code generator is built as SaaS . To obtain the generated and tested code, you must:
Here you can find an example of the generated generated code, and here the use of this code in the above-mentioned, demonstration project of control with android flashes of the LED on the demo board collected on STM8 .
Using BlackBox you can easily establish communication not only between microcontrollers, mobile devices, but also ordinary computers. And what is important, with minimal time and effort. In fact, the code generated by the BlackBox can be the skeleton of your distributed application. The programmer will just have to add handlers to the packet receiving events, as well as the logic for creating the packet, filling it with data and sending it to the recipient.
Take a look around how many projects can win by following this paradigm. Here are the guys from Guangzhou made oscilloscope DS212 . If you move the screen and controls to the side of a mobile phone or tablet, you can:
In addition, in the process of creating code generation for JAVA, I thought about the problems and shortcomings of the enum construction built into JAVA . As a solution, Android programmers suggest using IntDef annotation.
Creatively rethinking, I created my solution SlimEnum . It is actively used in BlackBox during code generation on JAVA. For ease of programming using SlimEnum, a plugin for IDEA / Android studio was created, which can be installed from the Intellij plugin repository. SlimEnum itself , its advantages and features will be described in a separate article.
A part of not complex projects on microcontrollers, such as light switches or level sensors, once debugged, no longer require any additional settings. However, most projects still involve interaction with the outside world. For example, a thermostat or a timer needs the ability to adjust and control given values. Most often, this function is implemented by adding user interaction mechanisms to the project. And the simplest project begins to acquire screens, buttons, encoders ...
Part of the already limited resources of the microcontroller goes to the maintenance of the entire infrastructure of user interaction. As a result, the core carrying all useful functionality, the microcontroller and power switches, occupy 5-10% of the physical volume. Everything else is auxiliary, screens and buttons.
This state of affairs is almost universally. Significant efforts are spent on the creation of all these control panels for TVs, air conditioners, refrigerators, machine tools ... Crazy multi-level menus-quests are composing ... In addition, all these built-in mechanical buttons and encoders, screens often break. In some cases, resulting in the uselessness of a fully functional otherwise.
')
At the same time, all these buttons and screens have limited potential for use, compared to any mobile gadget in the pocket of each of us ... With a convenient, large, contrast, touch screen and a fairly productive “iron”. In addition, many on the shelf gathering dust no less powerful, completely serviceable, outdated, device, sometimes not one. Which to throw out ... until the hand rises.
In this regard, it would not be bad, in projects on microcontrollers, to completely abandon screens and buttons and transfer all the functionality of monitoring, control and control to mobile devices. Well, or on computers. As a result, in my opinion, it will be more user-friendly and more effective solution.
Work in this direction is already underway. For example, there are models of floor scales , which through Bluetooth allow not only to see the weight on the mobile phone, but also to track the history of its change. However, so far, the built-in weight indicator is still not discarded .... until.
I think, soon enough, everything will come to the fact that having bought a household appliance, the user, in order to use its functionality, will need to download from the manufacturer’s website, and install the application on his phone.
So why now, since the advantages are so obvious, don’t start transferring from the microcontroller a part of the user interaction functionality to the side of mobile devices.
The answer is simple.
It's complicated.
Distributed systems are always much more complicated.
And the complexity is not in the very principle of communication / transport, which has already been managed to be formalized as UART, I2C, CAN ..., but in the complexity of writing the protocol itself over transport. Some of the problems: tracking the failure of the channel, requesting a retransmission, scheduling packets ... for machines with sufficient resources, could be implemented as TCP / IP. But the rest, the writing of the actual communication protocol itself is specific for each project and requires considerable expenses. One of the ways to simplify the problem can be automation of the programming process.
For this, as a rule, they create a language (DSL) with which they formally describe a protocol, and then create a program that, based on this description, generates source code for various target platforms in the required programming languages. There are a lot of examples of ready-made solutions in this style.
Protocol buffers
Cap'n proto
Flatbuffers
ZCM
MAVLink
Thrift
The complexity of the exchange protocol can be estimated by one of the descriptors of the exchange protocol with the quadcopter. In this example, XML is selected as the protocol description language.
For microcontrollers, many solutions from the world of large machines, such as TCP / IP, are not applicable due to limited resources. We have to remember and use CRC , Bit / Byte stuffing , Endianness , and also take into account many other, sometimes completely unobvious subtleties like this or that . Attempting to solve a problem by manually writing code can turn a programmer’s creative life into hell. Similar to the one that was with java script support on different browsers. Only here are different languages on completely different platforms. Even small changes to a debugged protocol can lead to a very long debugging process.
Not many of the above tools, in their kodogeneratsii fall to the level of microcontrollers. Attempting to use the mentioned code generation tools hardly managed to pull on the older 32 bit series microcontrollers. The most popular, cheap and widespread 8-bit microcontrollers were left out. I very often come across projects in which the most correct would be the removal of controls on a mobile device. Sometimes it was possible to do this, but further maintenance and expansion of the functional became very difficult.
Having gained considerable experience in using existing code generation tools, understanding their advantages and disadvantages ... after a while I created my amusement park ... BlackBox .
The code generator itself was decided to write on SCALA , the well-known language JAVA was taken as the basis for the protocol description language.
Why is that? The language is simple, for JAVA the largest number of really convenient development environments has been created. It turned out to have enough language constructs in order to describe not only the types of data transmitted in the packet, but also many additional characteristics and, very importantly, the network topology.
BlackBox generates source code in the following programming languages JAVA, C #, C. Support for SWIFT is planned .
At the moment, the BlackBox code generator is built as SaaS . To obtain the generated and tested code, you must:
- Create a protocol specification. In fact, this is the usual source for java. Here's an example of how it looks for a control project demo with Android by flashing the LED on the board under STM8S103F3P6 via Bluetooth UART on HC 08. When writing a specification, you need to connect a set of annotations describing the characteristics of the data to the java project, and also, following a small set of rules, describe the packets, channels, hosts, communication interfaces, network topology
- Check that the specification is successfully compiled, and send its source, in the form of attachment of a letter to the postal address of OneBlackBoxPlease@outlook.com . The server periodically takes the sent specifications from this mailbox, checks their correctness. Generates the ordered source code in the required programming languages. After this, several tests are created and the sources are run through them. If all the tests were successful, the generated code, the last test passed, as well as an example of using the ordered API is packed into the archive and sent to the addressee. If an error is detected, the sender is notified of a possible delay and the BlackBox support service understands the difficulty encountered.
Here you can find an example of the generated generated code, and here the use of this code in the above-mentioned, demonstration project of control with android flashes of the LED on the demo board collected on STM8 .
Using BlackBox you can easily establish communication not only between microcontrollers, mobile devices, but also ordinary computers. And what is important, with minimal time and effort. In fact, the code generated by the BlackBox can be the skeleton of your distributed application. The programmer will just have to add handlers to the packet receiving events, as well as the logic for creating the packet, filling it with data and sending it to the recipient.
Take a look around how many projects can win by following this paradigm. Here are the guys from Guangzhou made oscilloscope DS212 . If you move the screen and controls to the side of a mobile phone or tablet, you can:
- significantly reduce the cost of the product
- Significantly improve ergonomics with all touchscreen features.
- the oscilloscope itself, becoming even more compact, will be located where the measurement directly takes place, and the result will be displayed where it is convenient for the user, within 10 meters, if it is Bluetooth.
- receiving the measured data through the bes wire and powering the oscilloscope from the battery, which it will now consume much more modestly, we get a reliable galvanic isolation.
In addition, in the process of creating code generation for JAVA, I thought about the problems and shortcomings of the enum construction built into JAVA . As a solution, Android programmers suggest using IntDef annotation.
Creatively rethinking, I created my solution SlimEnum . It is actively used in BlackBox during code generation on JAVA. For ease of programming using SlimEnum, a plugin for IDEA / Android studio was created, which can be installed from the Intellij plugin repository. SlimEnum itself , its advantages and features will be described in a separate article.
Source: https://habr.com/ru/post/374149/
All Articles