Patent Description:
The disclosure reveals a controller and techniques for expanding its feature capabilities. Techniques may incorporate using an external memory to store feature sets that can be downloaded to an internal memory for intimate incorporation and usage by the controller. The external memory may be large in comparison to the internal memory. External storage of additional feature sets allows for use of a small and simple controller with access to numerous feature sets that otherwise could not be incorporated by the small controller.

The present system and approach may incorporate one or more processors, computers, controllers, user interfaces, wireless and/or wire connections, and/or the like, in an implementation described and/or shown herein.

This description may provide one or more illustrative and specific examples or ways of implementing the present system and approach. There may be numerous other examples or ways of implementing the system and approach.

With a growing need for "connectivity" of each product, devices are becoming more expensive and more complex to fulfill customers' requirements. Typically, when a new product vision is developed, features, communication interfaces and protocols may be selected to provide as best as possible usability of the product in an end application. But one size does not necessarily fit all. Taking a burner controller with an Ethernet interface as a model example, this device may communicate via following protocols such as Ethernet/internet protocol (IP), Profinet, EtherCat, and so forth.

The burner controller may typically be a high-volume, low-cost device, so it does not necessarily use a high power central processing unit (CPU), and its low cost microcontroller unit (MCU) may usually have a constrained internal memory and processing speed.

State of the art may be noted. Now when it comes to a particular trade or skill, typically, the user may need a limited set of features. But to get as big market share as possible, the manufacturer should provide a device with all of the needed features. This may result into two solutions. A larger and more expensive MCU may implement all of the features, but need to develop more complicated firmware, and be tested while distributing devices with only a limited feature set, and the like, may bring in an issue with more device models to maintain, release process, manufacture, and so on. Again, speaking in a language of examples, one may have a device with a capability of all possible communication protocols. For example, the MCU of such a device may need to be big in an amount of FLASH, RAM, and processing power. Or for another example, one may sell two types of the same device, one running with, e.g., Profinet, and another one, EtherCat.

In a first situation, a device may be completely flexible but require more internal resources in an MCU to keep the device functionality available and running. Firmware inside the MCU may be more complex and have obviously a higher risk profile and since when there are more communication stacks, that may increase the risk of issues.

In a second situation, a device may be relatively simple, and its MCU may be cheaper, smaller and less versatile. But when a customer decides to switch to a different functionality, the customer may need to buy new hardware.

An alternative may be noted. At the present time, newly developed devices may be equipped with boot loaders. A boot loader may be a very simple piece of software that loads firmware from external media (e.g., a cheap external flash) to an MCU internal memory (i.e., a firmware upgrade) and verifies the signature upon a boot (i.e., a secure boot). But there may be another use case that is not necessarily utilized; however, it can bring interesting opportunities. If a device was equipped with an on-board flash memory (which it usually already is), this flash memory may be partitioned to contain various types of firmware such as firmware with a feature set A (e.g., Profinet firmware), firmware with a feature set B (EtherCat), and so on. In this way, a single piece of hardware may be used to switch between completely different functionalities. A boot loader may select which firmware (i.e., feature set) customer wants, load it and boot it. The device may be sold to customers for a price of all features together, but utilize a smaller MCU and make resulting hardware and all features possible, plus have a cheaper design.

Technical benefits of the present approach may include lower prices of hardware and software, and an MCU with less computational power and storage resources that can be used; features that are often used in mutually exclusive ways that do not have to directly coexist, which makes development easier. Expanding this approach further, boot loader intelligence may be expanded so it can get an ability to enable a feature set (i.e., certain firmware) only when activated explicitly by remote command. It is expected that to fulfill customer requirements, there may be a large set of communication protocols required to be supported.

Newly developed devices that expect to be supporting wide range of features (e.g., communication protocols) may have several compiled firmware files stored in an external non-volatile memory (flash) which is generally more inexpensive than related art approaches. During an MCU selection process, it is possible to target lower-specification devices with a lower amount of internal flash and ram. The final products may be considered to be providing a superset of all features across all firmware files carried in an external memory.

<FIG> is a diagram of a layout of the present system <NUM>. A user or users' interface <NUM> may have a connection with a processor <NUM> of a device MCU <NUM>. Application <NUM> uses a configuration storage <NUM>, an internal flash memory <NUM> and coexists with boot loader <NUM>. Boot loader <NUM> may be connected to an external flash unit <NUM> via communication ports <NUM> and <NUM>. A selection is made from images with feature sets <NUM>-<NUM>. There is a total of N feature sets from which to choose. N shall be greater than <NUM>. External flash memory <NUM> may have a greater storage or memory capacity (i.e., hold more feature sets) than internal flash memory <NUM>.

<FIG> is a diagram of a power-up procedure <NUM>. After power up <NUM> boot loader <NUM> is initialized. Configuration storage <NUM> is accessed by boot loader <NUM>. At symbol <NUM>, a decision is made whether a loaded image corresponds to a configuration. If an answer is yes, then the image may be validated at symbol <NUM>. After validation of the image, a question of whether the firmware is valid is noted at symbol <NUM>. If the firmware is valid, then the application is booted as per step <NUM>. If the firmware is not valid at symbol or step <NUM>, then a question may be asked whether the failure is repeated at symbol <NUM>. If the failure is repeated, then the error may be handled at step or symbol <NUM>. If an answer is no, then an image may be loaded from an external storage at symbol or step <NUM>. The image may be re-validated at step <NUM>. Then symbols or steps <NUM> and <NUM> or <NUM> may be repeated.

The procedure of the question asked at symbol <NUM> may instead be no rather than yes as indicated above. Then at symbol or step <NUM>, an image may be loaded from the external storage and be validated at step or symbol <NUM>. Then steps or symbols <NUM> and <NUM> or <NUM> may be repeated as indicated above.

<FIG> is a diagram of a configuration change <NUM> within system <NUM>. An application may be running at symbol <NUM>. A user may want to use a different feature set according to symbol <NUM>. An external memory may be scanned at step <NUM> for feature sets which may be presented to the user at step <NUM>. The user may select a feature set at step <NUM>. Then, the device power may be cycled at step <NUM>.

<FIG> is a diagram of a feature set change <NUM>. An application may be running at symbol or step <NUM>. A user may want to install a new feature set at step or symbol <NUM>. At symbol <NUM>, a question may be asked whether space is available in an external memory. If the answer is yes, then the desired feature set image may be downloaded to the external memory at symbol or step <NUM>. At symbol or step <NUM>, a question of whether the feature set image is valid and genuine may be asked. If an answer is yes, then success may be reported at symbol <NUM>. If the answer is no, then an error is reported at step or symbol <NUM>. Similarly, if the answer to the question whether there is no space available at the external memory at symbol <NUM>, is no, then an error is reported at step or symbol <NUM>.

To recap, a burner controller unit system may incorporate a user interface, a microcontroller connected to the user interface, and an external memory connectable to the microcontroller. The microcontroller may incorporate an application handling the user interface, a configuration storage handled by the application and a boot loader, and an internal memory accessible by the application and the boot loader. The boot loader may be accessible by the application. The external memory incorporates more storage capacity than a storage capacity of the internal memory.

The internal memory can hold at least one feature set. The external memory can hold more feature sets than the internal memory.

The external memory incorporates a plurality of feature sets. Each feature set may be stored in a form of an image in the external memory.

The internal memory is partitioned to contain various types of firmware. The various types of firmware incorporating a feature set A and a feature set B.

The feature set A may incorporate a functionality that may or may not be incorporated to the feature set B.

The boot loader is initialized. The configuration storage is accessed. The boot loader loads an image from the external memory to the internal memory. A question is whether a loaded image may correspond to a configuration in the configuration storage. If an answer to the question is yes, then the image may be validated. A second question is whether firmware of the image may be valid. If the firmware is valid, then a boot is applied. If the firmware is invalid, then an error is reported.

The boot loade is initialized. The configuration storage may be accessed. The boot loader may load an image from the external memory to the internal memory. A question may be asked whether a loaded image corresponds to a configuration in the configuration storage. If an answer to the question is no, then another image is loaded from the external storage. The other image may be validated. A question may be asked whether the firmware of the other image is valid. If the firmware is valid, then a boot may be applied. If the firmware is invalid, then an error may be is reported.

A configuration change may be implemented. The external memory may be scanned. Feature sets may be presented for selection. A feature set may be selected. The device may be reinitialized.

A new feature set may be installed. An inquiry may be made of whether space is available in the external memory. If space is unavailable in the external memory, then an error may be reported.

A new feature set may be installed. An inquiry may be made of whether space is available in the external memory. If space is available, then a feature set may be downloaded to the external memory. An inquiry may be made to determine whether the feature set is valid and genuine. If an answer is yes, then a success may be reported. If the answer is no, then an error may be reported.

An approach for enabling a small microcontroller unit to operate with a large number of feature sets, may incorporate obtaining a microcontroller having an application with access to an internal memory and a boot loader with the same access, and finding an external memory connectable to the processor. The external memory may incorporate more storage capacity than a storage capacity of the internal memory.

The storage capacity of the internal memory and the external memory may be proportional to a number of feature sets stored in the internal memory and the external memory.

The approach may further incorporate doing a feature set addition or change for the microcontroller, incorporating determining which new feature set is to be selected for a microcontroller, checking for space available in the external memory for a new feature set, downloading a new feature set image to the external memory if storage capacity is available in the external memory, and determining whether the feature set image is valid and genuine.

A feature set may represent a functionality that is distinct from a functionality of another feature set.

The microcontroller may contain and use just one feature set. The microcontroller may have an internal memory that needs only to hold one feature set to be loaded and booted.

If the microcontroller needs a different functionality than that of the feature set presently set in it, then the microcontroller may replace the present feature set with another feature set having the different functionality, loaded from the external memory.

A controller unit may incorporate a microcontroller, and an external memory connectable to the microcontroller. The microcontroller may incorporate an application, a boot loader, a configuration storage accessible by the application and the boot loader, and an internal memory accessible by the application and the boot loader. The external memory may have more storage capacity than a storage capacity of the internal memory.

The internal memory may hold at least one feature set, and the external memory may hold more feature sets than the internal memory.

Changing a feature set in the internal memory for a different feature set, may incorporate scanning an external memory for available feature sets, presenting the available feature sets for selection to a user, and checking a user selected feature set for validity and genuineness.

Claim 1:
A burner controller unit system (<NUM>), the system comprising:
a user interface (<NUM>);
a microcontroller (<NUM>) connected to the user interface; and
an external memory (<NUM>) connectable to the microcontroller,
wherein the microcontroller comprises:
an application handling the user interface;
a configuration storage handled by the application and a boot loader; and
an internal memory (<NUM>) accessible by the application and the boot loader,
wherein:
the boot loader (<NUM>) is accessible by the application; and
the external memory comprises a storage capacity greater than a storage capacity of the internal memory, wherein the internal memory is configured to store only one firmware corresponding to one feature set (<NUM>, <NUM>, <NUM>), and
wherein:
the boot loader is initialized;
the microcontroller is configured to access the configuration storage to retrieve a configuration;
the microcontroller is configured to load a first image of the feature set stored in the internal memory;
the microcontroller is configured to determine whether the first image corresponding to the feature set stored in the internal memory corresponds to the configuration in the configuration storage;
in response to determining that the first image corresponds to the configuration in the configuration storage, determine whether a firmware of the first image is valid, if the firmware of the first image is valid, the firmware of the first image is booted;
the microcontroller is configured to load a second image from the external memory to the internal memory in response to determining that the first image corresponding to the feature set loaded from the internal memory does not correspond to the configuration in the configuration storage;
the microcontroller is configured to validate the second image in response to determining that the second image corresponds to the configuration;
determine whether a firmware of the second image is valid;
if the firmware of the second image is valid, the firmware of the second image is booted; and
if the firmware of the second is invalid, an error is reported on the user interface.