Big configuration problems for small devices

Part 1. Lyric

The modern world is inconceivable without a huge number of electronic and electrical assistants. Starting from computers and smartphones, ending with a simple light switch in the kitchen and input protection circuit breaker. One way or another, you have to interact with all devices. With some more often, for example a smartphone, which some people don’t get out of hand at all, with some less often, the same automatic entry protection device for an apartment, the existence of which some are not even aware of.







As for devices from the first category, everything is simple there. The interface, in fact, is graphical and is determined by designers and programmers. And with the devices of the second, in terms of interaction, not of importance, the plan is much more complicated. We take them for granted, the same light switch, or to the materials, when they do their job, like an input automaton that worked for overload.



For very simple devices, the interface is primitive. Button or toggle switch, several buttons for the thermostat, for example. Characteristics are set by the manufacturer and do not change by the consumer. Tripping current 10A, 16A, 25A ... Switching to 6A 230V ... But when the device is a little more complicated, everything becomes very bad.



A little distracted, I will talk about my failure just because of the hardware interface. There was a task of load balancing for a private house. In fact - a multi-channel programmable time relay. I made a prototype literally in the evening, delivered it to the customer, the customer, a housemate, was satisfied, I decided to try to establish small-scale production, organize a small electronic startup on a village scale, since the problem of lack of input capacity is relevant for the private sector. One design problem remained - the configuration of the device. In the prototype, the intervals were simply packed into the Firmware, if 200 assembler commands could be called that. A couple of times I had to adjust the settings, this was done simply by assembling a new firmware and updating by means of the programmer. It is clear that for a serial, even small-scale device, this method is not suitable.



Then I came across all the "charms" of developing a hardware user interface ... Simple methods, such as writing down 16 options for settings and setting the slide switch did not give the required flexibility, making any serious interface for communicating with a PC or smartphone is an unjustified complication, a rise in price. In addition, there immediately arises the need to develop a simple, but cross-platform application (Win / Linux / Android / iOs). But this is not the main thing. In fact, the user will configure the device once during installation and, ideally, no longer recalls it.



In contrast to the prototype, a 4-bit LED indicator, buttons, and LEDs appeared on the front panel of the device. Functionality was also added, features of delays in turning on the load after a power outage, additional modes for power supply from a power transmission line or a backup generator, maintaining the freezing temperature ...

And here is the mass-dimensional layout of this Frankenstein monster

(Controls contactors, inside low-current coils switching circuits)



While the functionality of only a programmable relay was present, it was not difficult with the settings, the created hardware interface paid off. But at some point, the configuration instruction began to exceed the size of the firmware code. Initial idea: the user scans the QR code on the instrument panel, goes to the page with the instruction - failed. It remains either to make a very simple device, or to look for another method of communicating with the device. Potential buyers (courageous testers) for a very long time understood the configuration according to the instructions.



The saddest thing is, I have prototypes of several devices that are once configured and live their lives in an electric panel. Configuration - a dozen other bytes. It remains to find a suitable interface.



What do we have today? Comparison of the “classic” configuration methods:

• The choice of ready-made configurations. PROS: Easily implemented both software and hardware. Additional hardware improvements are minimal. The user does not need to have special equipment, enough instructions. CONS: There is no flexibility, not intuitively, instructions are required.
  
  
• A sequence of clicks with feedback through a simple display (similar to setting a regular electronic clock). PROS: It is easily implemented programmatically, the user does not need to have special equipment, enough instructions. CONS: Not intuitively, it is difficult to configure a large number of parameters, the inability to clone settings, which is critical for installer companies.
  
  
• Configuration using a standard wired interface. PROS: Intuitively, if the application is well written, easy cloning of settings, relatively simple implementation, perhaps not very expensive hardware improvements, the ability to update firmware. CONS: The user should have equipment, at least a computer or laptop with a USB port, an interface converter, if your device provides something other than USB or Ethernet. The need to develop an application.
  
  
• WiFi + WEB - shooting from a cannon at sparrows and terry ardurinshchina. But the idea is not bad. PROS: similar to a wired connection, there is no need to develop a cross-platform application by providing the built-in WEB interface of the configurator, it is enough for the user to have any device with WiFi support and a browser. Access to the global network is not even required. Perhaps this design will be cheaper than hardware buttons / indicators, the case is also simplified. CONS: Technically, an extremely ugly solution that transfers the product to a completely different class of devices. Reliability is reduced, both due to the complexity of the firmware, and increased sensitivity to EMF.
  
  

I summarize that one of the most beautiful solutions from the point of view of the user is the latter. But it is also one of the most terrible from the point of view of an engineer. I almost stopped on it, but ...

Technical curvature haunted. In order to write a few bytes in the EEPROM, fencing a garden with such an extensive protocol stack is irrational. But it looks like I found a solution to my problem, here are the characteristics of this method:



Pros:

• The increase in the cost of the hardware component is comparable to the “choice from ready-made configurations” solution, 10–15 rubles. And the ability to refuse unnecessary buttons, indicators, etc. gives, rather, a cheaper price.
  
  
• Software implementation is not a problem.
  
  
• It does not require the development of a special application. If desired, the application can be provided.
  
  
• Intuitiveness depends on the quality of the development of the WEB configurator or application.
  
  
• Galvanic isolation with the device.
  
  

Minuses:

• Low data transfer rate compared to a wired or radio interface.
  
  
• Physical contact with the device is required.
  
  
• You need at least one access to the Network.
  
  

In addition, this method of transmitting information is very common in nature. This is a sound wave.







Now, perhaps everyone has smartphones. There is no smartphone - any device for playing sound, even a cassette player, is suitable. As I see this interface in action:

1. The user installs the device according to the instructions.
   
   
2. The required configuration of the device is created, the necessary modes and settings are registered.
   
   
3. The user puts the device into configuration mode, for example, by a special sequence of pressing a key, the device displays a ready state, for example, by blinking an LED with a frequency of 5 Hz.
   
   
4. The “transfer parameters” icon is clicked in the configurator, after which the encoded sound sequence begins to play (and who loaded them from the tapes in the 90s?).
   
   
5. The user waits for the data to be loaded into the device to finish (for example, the LED has become constantly on) and clicks the “stop transmission” icon.
   
   

Everything, new parameters are transferred to the device. Do you think this configuration method will be convenient enough?



Instead of an afterword



I specifically did not touch on the technical part of the implementation. Each case can be individual, the approach is a general idea. If the article arouses interest, I will publish the second part. Practical. While the spoiler: the idea was successful, the model on the 8-bit PIC16 + “student” version of the C compiler without optimization, including manual, the firmware quietly fit both in memory (about 1KB) and in performance. The most difficult mathematical operation is the addition of sint8_t and sint16_t. According to preliminary calculations, the core of the sound configurator, rewritten in Assembler, will fit in less than 512 kiloslov and PIC16F819 should have 2MIPS performance.



All the best,

Konstantin.