Requirements and Specification

​

We begin the embedded system design process by understanding the customer requirements and establishing a clear system specification. This includes understanding what the system needs to do, the required performance (speed, real-time deadlines, memory footprint), cost considerations, size/weight, power consumption, etc. This is an important step since it establishes the scope of the product and the kind of technology needed to design the product.

 

Brainstorming and Design

 

Next, we explore innovative ideas to determine the hardware and software solutions best suited to meet the product requirements and write an architecture/design specification for the system. Different types of microcontrollers, peripherals, and the software tool-chains and RTOSs (if needed) that go along with the hardware are considered. A hardware and software partitioning scheme that provides the best performance is determined. Rapid prototyping is often adopted in order to make and validate design decisions. At this point, a detailed architecture document describing the overall structure of the system, the individual hardware and software components to be used, and how they interact with each other to implement the system functionality is made available.

 

Development and Implementation

​

The third step is the development and implementation of the system by the hardware and software engineering teams. On the hardware side, this includes building debug and form-factor versions of the hardware. On the software side, selecting the right embedded development tools is a critical first step towards making the development and debugging process as efficient as possible; a few minutes inspecting the call stack with the right emulator pod can save weeks of “burn and crash” style debugging. We often use open source tools such as the GNU Embedded Tool-chain, though proprietary or commercially available tool-chains may also be used depending on the requirements of the customer or the availability of open source tool support for the target processor and operating system.

 

Whenever we start developing firmware for a new board, our aim is to have a basic version of the firmware up-and-running before the PCB arrives. That way, we can help the hardware engineers bring up the board.  We typically run our code for the first time on evaluation kits from the chip manufacturer, then transition to the actual hardware once it is ready. The development phase generally involves several cycles of coding, testing, and debugging.

 

Hardware and Software Debugging

 

We have an on-site electronics technician, an in-house hardware engineering team, a large inventory of electronic test equipment, and even an X-ray machine to check for broken connections, which allows us to quickly and efficiently debug problems related to the interaction of hardware and software. We also have a large inventory of debuggers, emulators, and IDE software, and we buy what is needed when doing a project with a new chip. Examples of some debugging tools that we employ are JTAG and SWD emulators, oscilloscopes, logic analyzers (for SPI, I2C, etc.), protocol analyzers, GDB, Eclipse, and good old printfs over USB/serial.

 

Integration and Testing

 

The last step involves integrating and testing the entire system. Individual parts of the system developed by the hardware and software engineering teams are integrated, and the system is put through rigorous testing to ensure that it functions as expected. A test plan is developed, and whenever possible, shell scripts are written to automate builds and system testing. We also deploy continuous build and test servers that automatically compile/generate and test the latest version of the firmware binaries every night. This helps detect any software changes that result in broken builds or functionality, and makes available the latest version of functioning firmware to the hardware engineers and QA group.

 

Bug-Tracking and Version Control

 

We typically use JIRA for bug-tracking and GIT for version control, although we can work with any customer preferred system.

 

Design-for-Test

 

Our software development process highlights the importance of testability of our software by incorporating relevant elements of Test-Driven Development. This can include unit testing, component testing, integration testing and system testing, most of which can be automated using our Continuous Integration tools.

 

We have worked with the following microcontroller families:

 

Atmel AVR, STM32, NXP, TI MSP430, Freescale I.MX6, PIC, PIC32, Nordic nRF, Cavium, Ambiq Apollo, Silicon Labs, 8051, TI OMAP, Marvell SOCs, Qualcomm SOCs,  Movidius Myriad, Intel Atom, Analog Devices SHARC DSP, Analog Devices ADSP2100, Motorola 6800, Motorola 68000, Xilinx Zynq, Altera FPGA SOC, x86, 6502, Z-80

 

Protocols and interfaces we are familiar with:

 

I2C, SPI, SDIO, USB, UART, I2S, PCIe, PCI, ISA, MIPI CSI, MIPI DSI, MIPI Unipro, Wi-Fi, Bluetooth and BLE, Ethernet, TCP/IP

​

Additional Information

 

NK Labs offers electrical, mechanical, and software engineering services and can serve as a one-stop shop for any technical project.