ABOUT

This is a collaborative effort between the customer and the Re:Build AppliedLogix team. The more team members and respective disciplines represented for this activity, the more comprehensive the requirements list is.

After the requirements have been defined, a system block diagram is created for the hardware needed to meet them. Communication between subsystems is defined, and a detailed definition of all internal and external interfaces is created for each subsystem or board.

System components’ power consumption is defined by analysis or measurement. The product’s operational modes (off, standby, running, and so on) are described, and its power consumption is documented based on the components used in each mode. Once power usage is fully understood, a power supply and distribution plan is defined.

External connections to the product are fully defined. In many cases, industry standards apply. All the physical interconnects are specified, and any unique environmental requirements, such as surge protection, are defined. If abnormal use cases (e.g., reverse battery connection) are anticipated, they are defined, and mitigation is identified.

Circuit designs are created and captured electronically. Components used in the design are made in a library that includes the schematic symbol, layout footprint, and approved manufacturer part number(s) information. Simulation is performed on individual circuits, as appropriate. When the schematic is complete, the design moves to the layout phase. 

The mechanical team provides details on the required board outline, mounting features, connector locations, and any component height restrictions. The schematic provides connectivity between components and the layout engineer creates the physical copper interconnect between them. The output of the layout phase is a complete build package for a printed circuit board assembly (PCBA) that a contract manufacturer can build.

Selecting the correct microcontroller family and device within the family based on the technologies needed is essential based.. For example, you would not want to pick a microcontroller without SPI if the peripherals in the system speak SPI. This is often a collaborative selection process involving both hardware and software engineers.

Knowing which algorithms will run within a device’s microcontrollers will help with selecting the class of microcontrollers and their processing speed. Evaluating the algorithms used in higher-level simulation languages, such as Python or Matlab, can help ensure the successful selection of hardware.

Knowing the software architecture upfront allows for software reuse and library creation. It also ensures consistency across the code base in different microcontrollers and code sections. Selecting the architecture at the outset will significantly reduce the likelihood of defects owing to inconsistencies in implementation later on.

Modern-day best practices in software encourage the deployment of software layers that are not dependent on or interwoven into each other. This allows for ease of swapping out libraries, tools, or even microcontrollers later on. This approach of layering software is called abstraction because the physical hardware is abstracted away from the high levels of code.

When the architecture and hardware abstraction layers are in place, the application code (which likely includes algorithms of some kind) is authored.

Although experience, templates, models, and best practices often produce high-quality code, writing tests for each portion of the design is always wise. This ensures that corner cases that are difficult to comprehend or foresee can be covered programmatically.

When the first boards come back from the contract manufacturer, they must be tested by the hardware engineer who designed them to ensure minimal manufacturing defects. This is often called the “smoke test” whereby if the boards are assembled or manufactured incorrectly, the ICs may let out their smoke. This step generally does not include software or firmware in the board; it is done to ensure that voltages and sequencing are correct.

When the hardware appears to be assembled correctly, a simple application is loaded into the microcontroller (or microcontrollers, depending on the complexity of the board). This step is typically referred to as “Hello World,” which is a standard message printed out of the serial console to ensure the microcontroller boots successfully. If there is no serial console, a blinking LED is standard.

When the microcontroller(s) have been validated to be working, the peripherals are brought up one by one to ensure that they can talk correctly.  With the validation completed, the algorithms can be turned on and tested in actual hardware. This almost always results in coefficient (or the like) adjustments based on the “real world” feedback.

Finally, once the software engineer is satisfied the system is functioning correctly, test stands will be used to ensure the systems work -across process and temperature. This will allow for further adjustments to the application code and algorithms based on test results.