Sample Code For Device Under Test- and BlinkUp Fixture-specific Firmware
impCentral™ supports the creation of separate code structures for the factory firmware that runs on your BlinkUp™ fixtures and on your Devices Under Test (DUTs). Previously, these two device types ran the same factory firmware, which therefore needed to be able to detect the type of device on which it was running and to perform appropriate actions accordingly. Now each of these device types can have their own, type-specific firmware to run.
This improvement allows factory firmware developers to code with confidence, knowing that a given flow will always run on the correct device type, virtually eliminating the production hold-ups that an incorrect code flow can cause, such as executing DUT-oriented testing and blessing code on a BlinkUp fixture.
This document describes the changes made to impCentral in detail and introduces a new version of our standard factory firmware that has been adapted to take advantage of the new methodology.
Previously, factory firmware was developed in a Test Factory Device Group and deployed in production to a Factory Device Group. Instead, impCentral now has extra device group types which target DUTs and fixtures in test and production environments:
| Previous Methodology | New Methodology | |||
| Environment | Development and Testing | Production | Development and Testing | Production |
| Device Group(s) | Test Factory | Factory | Test Fixture, Test DUT |
Fixture, DUT |
Application firmware development and deployment to production are not affected by this change.
For any Product, each of its Test Factory Device Groups will be be renamed a Test Fixture Device Group and be paired with a new Test DUT Device Group. Both groups will contain identical copies of the code from the source Test Factory Device Group so that your factory firmware, and Connected Factory Process development and testing, can continue unchanged. BlinkUp fixture assignments will not change.
Similarly, each of the Product’s Factory Device Groups will be renamed a Fixture Device Group and be paired with a new DUT Device Group. Again, both groups will be provided with identical copies of the code from the source Factory Device Group so that your Connected Factory production flow can continue exactly as it did before. BlinkUp fixture assignments will not change.
In short, you need make no changes to your code or factory flow until you are ready to do so.
The process of assigning devices to any of the existing and new device groups discussed above remains exactly as before. For example, consider the testing environment (impCentral’s Test Zone). You assign a BlinkUp fixture to a Test Fixture Device Group — this will receive and run the fixture firmware that you develop in the Test Fixture Device Group’s code editor.
The fixture firmware’s task is to use BlinkUp to prepare DUTs for impCloud access. Upon BlinkUp, a DUT is automatically added to the Test DUT Device Group that has been specified as one of the Test Fixture Device Group’s targets. The DUT then receives the DUT firmware that that you develop in the Test DUT Device Group’s code editor. The DUT firmware’s task is to test the DUT and then test-bless it. Upon test-blessing, the DUT is automatically assigned to a Test Production Device Group (also specified as one of the Test Fixture Device Group’s targets, as before).
When you are ready to move to production (impCentral’s Production Zone), you create Production, DUT and Fixture Device Groups, and deploy promoted application, DUT and Fixture firmware, respectively, to those groups.
This process is straightforward and simply involves removing the code which determines the device type — DUT or BlinkUp fixture — on which the firmware is running. You can also remove the code for the unwanted device type: for example, in your DUT firmware, you can remove all fixture-specific code. From your fixture firmware, you may remove all code solely relevant to DUTs.
This is demonstrated in the sample code, below.
As before, your two types of factory firmware may also comprise agent code. This continues to run as before, but with the proviso that it needs only provide support to the type of device that it is paired with. For example, if your existing factory firmware contains responses to messages sent from DUTs and from fixtures, you can remove from, say, the DUT agent code all callbacks that are triggered by messages from fixtures because these will never be called.
Removing the unused code will make your firmware source easier to read and maintain, but because the unneeded code will never be called, you may safely choose to leave your agent code unchanged if you wish.
The new methodology, as it applies to factory firmware, is best demonstrated with an example.
This code contains just a single callback registration call which deals with "testresult" messages from the DUT: device-specific information is sent to your data logging server (its address is placed in the constant RESULTS_URL) and to the BlinkUp fixture’s agent (see below).
This code immediately runs the test and Bless process.
The new code contains a single callback registration call which deals with "blinkup.sent" messages from the fixture itself. It also uses Electric Imp’s Rocky library to establish an Internet API through which it can receive data from DUT agents.
This code configures the fixture (for this example we are using an impFactory™ appliance) and then to perform a factory BlinkUp operation when triggered by as assembly line operator or some automated mechanism. This also causes the "blinkup.sent" message to be transmitted to the fixture’s agent (see above).