| - unit test framework developed by the company
- a simulator developed by the company
- debugging with an emulator if necessary
|
system contains THREE processors. (1) the main ARM processor (2) nRF BLE processor. (3) i don't use. |
- VS code: Source code editor
- IAR: build and link the code
- GIT: source code control
|
We use GitHub and live mobbing for code reviews. |
5-30 minutes |
50% |
25% |
25% |
Show
|
| Create tests that drive code paths of what I am adding/changing |
z/OS |
. |
Provide team with background of code change, then go line by line and review, rework offline |
1-5 minutes |
20 |
50 |
30 |
Show
|
| Build Gtest suite w/ unit tests for new code coverage, then run existing unit tests and integration tests, team Jenkins pipeline tests on PR submission (end to end, smoke tests, integration) |
Software stack for Z AI Enablement |
Bob, VSCode, git, github project board, jenkins |
submit pr w/ template, include any necessary comments and output, Leads/Stake holders leave comments |
31-60 seconds |
30 |
30 |
40 |
Show
|
| In real environment |
Embedded System |
C++ Development Kit |
We do peer reviewing of the GitHub PR |
31-60 seconds |
50 |
30 |
20 |
Show
|
| I haven't really done much development work at my new company yet, so I'm not sure... |
Software running on a laptop, sometimes in areas where internet is spotty or non existent |
CLion |
At least two people must review the code. The reviewer should test the code to ensure it works. |
11-30 seconds |
40 |
40 |
20 |
Show
|
| Just run the unit tests generated by Catch. And hope Jenkins stays green |
A Linux installation |
CLion, Emacs (Magit), Git, CMake |
Pair program everything, no formal review |
Under 10 seconds |
1 |
8 |
2 |
Show
|
| Running it on the target machine and exercising it manually or hard coding stuff to test corner cases.
I've written some developer tests using CppUTest and Ceedling on different projects, but they are very immature and there are too few of them. |
Main project is 32-bit arm embedded linux device and there is a side project based on a dsPIC device |
CMake, GCC, XC-DSC, VSCode |
Just quick looks at PRs. |
1-5 minutes |
30 |
35 |
35 |
Show
|
| Unity test on target.
We are slowly shifting to the Ceedling framework to run unit tests on PC. |
RISC microcontroller. ARC EM7D CPU. |
CMake, Synopsys ARC toolchain, VS code. |
Pull request reviews within Azure Dev Ops.
At least 2 approvals, resolve comments, test passing. |
5-30 minutes |
45 |
10 |
45 |
Show
|
| Bluetooth Protocol-level test suites |
System-On-Chip with Bluetooth stack |
CMake, cross-compilers, debugger, protocol analyzers, conformance testers |
Reviews performed thru Azure DevOps with two reviewers required to push a PR. |
11-30 seconds |
20 |
50 |
30 |
Show
|
| Manually... I wish we had a pipeline |
X86 laptop, or x86 NUC on a UxV |
Clion, VSCode |
1 in process review at 50% completion, 1 at pull request with run testing |
1-5 minutes |
50 |
30 |
20 |
Show
|
| Static analysis, system test, integration test |
Low power MCU, modem, RF chip |
Cmake, gcc compiler, vs code, st-link, cubemx programmer |
It is mostly to check if changes are made in line with acceptance criteria |
1-5 minutes |
30 |
20 |
50 |
Show
|
| combination of static analysis, unit tests and functional testing. |
Embedded medical devices |
Common embedded C IDEs |
Code always reviewed by multiple members of the team before merging. |
31-60 seconds |
30 |
30 |
40 |
Show
|
| Python |
z/OS, Linux |
Eclipse, IDZ |
For small code changes - GitHub reviews.
For complex code changes - live code reviews. |
5-30 minutes |
0 |
90 |
10 |
Show
|
| Unittests when practical. Manual testing for things that involve hardware in specific states. |
Embedded QNX or Linux systems running on NXP IMX or STM ARM SoCs. |
GCC, CMake, Yocto |
All commits must pass two peer reviews before merging into main |
1-5 minutes |
25 |
25 |
50 |
Show
|
| unit tests, integration tests, e2e tests, performance tests |
N/A |
Git, Jenkins, just, GitHub Actions |
We do not often have code reviews, we use pair programming |
Under 10 seconds |
20 |
60 |
20 |
Show
|
| Pytest scripts and a regression suite |
Our systems are used for Qubit control |
GitHub |
We add who we think knows the code as a reviewer and need just one approval. |
5-30 minutes |
30 |
30 |
40 |
Show
|
| Mostly manual testing. |
Printers and sometimes a Windows computer. |
I mostly use VS Code or QNX Momentics IDE. |
Almost never do any code reviews as we optimize for fast customer solutions. |
5-30 minutes |
40 |
30 |
30 |
Show
|
| I run automated unit tests using CxxTest and stubs. |
We develop the ERTMS on-board system for railway applications. |
I use Visual Studio Code and Visual Studio 2022. |
We make peer reviews for every change |
1-5 minutes |
50 |
30 |
20 |
Show
|
| unit tests after development |
embedded systems (insulin pumps) |
IAR
PC Lint
internal unit test framework |
Take too long to get done! A lot of design controls which are needed in the regulated space. |
11-30 seconds |
40 |
20 |
40 |
Show
|
| We unit test our embedded C code on the host using a custom harness with type-specific assertions. Tests run via CMake/CTest with gcov coverage tracking. CI runs everything automatically on every change.
|
We have ARM and NRF processors. |
IAR Embedded Workbench, CMake, GCC, Git, Python scripts, gcov/lcov, Bamboo CI, JTAG debuggers. |
If a code change is large, we have PR review to go over ti changes. |
1-5 minutes |
10 |
5 |
20 |
Show
|
| Run PC-Lint static analysis. Home grown unit tests that call into each function in a file and test inputs, branches and lines of code. |
Poor use of semaphores, delays, timers all over the place. |
IAR Workbench, STM32Cube, GCC, Saleae logic analyzer, PC-Lint |
Performed in GitHub. |
11-30 seconds |
50 |
25 |
25 |
Show
|
| Unit tests |
Complex med device multi chip system |
IAR, VS Code |
Decently well structured usually containing changes to software and unittests |
1-5 minutes |
20 |
40 |
40 |
Show
|
| General, non-standard methods. |
STM32 |
IAR, gcc toolchains. |
Done on Bitbucket, has CI/CD. |
Under 10 seconds |
50 |
20 |
30 |
Show
|
| Static test regressions |
Code is built for simulation with HDL RTL models to stimulate, inspect, check RTL model against code |
IBM Bob (VSCode-based)
CMake |
GitHub-based PR reviews for involved team. |
1-5 minutes |
20 |
20 |
60 |
Show
|
| Off-target unit-testing, on-target HIL tests. |
Distributed system with internal interfaces (UART), external Debug CLI. hard realtime. |
IDE
Code coverage
Lint
|
Ad-hoc and retrospective. |
30-60 minutes |
40 |
10 |
50 |
Show
|
| - Primarily unit tests (in gtest)
- Secondary: system tests using a python based framework (built on top of pytest).
- Manual tests on running system |
Distributed embedded system (but no real limitations to memory allocation or exceptions). |
IDE (Clion+IDE), sourcetrail, main project toolchain (debian12 gcc).
Codescene, Coverity, copilot |
Our agile team is heavily invested in code reviews. |
1-5 minutes |
60% |
30% |
10% |
Show
|
| Unit-test, static analysis, Custom automated tests of various kinds. |
Arm V7 with Linux and OpenRtos. |
IDE (code completion, debugger), automated CI/ Build-Systems, AI assistants, |
Git/PRs, used to be SVN/Code-collab |
31-60 seconds |
60 |
5 |
35 |
Show
|
| build then test on target *_*, if it fails debug then repeat |
MCU based target |
IDE provided by MCU manufacturer |
there are almost no peer review, if I found something that may cause a problem I will fix it. |
5-30 minutes |
30% |
10% |
60% |
Show
|
| Manual |
Platform? Windows/GNU+Linux |
IDE, clang-tidy |
Good. Learning a lot from them. |
Under 10 seconds |
5 |
2 |
3 |
Show
|
| n/a |
PC |
Jetbrains
Visual Studio |
All check ins require a code review |
1-5 minutes |
6 |
1 |
3 |
Show
|
| function and some gtest |
Embedded STM32's, esp's and nordic series of ICs. Bare metal, idf or Zephyr RTOS |
Jlink ultra, salea, scope, multimeter, SCA tools, lizard cognitive load |
Mob review, AI supported and PR with context |
11-30 seconds |
50 |
40 |
10 |
Show
|
| I usually check my outputs match my expected outputs given the inputs (I am a researcher). |
Don't have one |
Jupyter Notebooks, Python |
I am the only person writing code and reviewing my own code |
Under 10 seconds |
60 |
10 |
30 |
Show
|
| I currently test code manually on the vehicle or Testsetup and verify module behavior and outputs. |
The target system is a vehicle embedded controller interacting with sensors and actuators. |
MATCH tool chain |
I follow Google's code review guidelines to review code quality, readability, and correctness. |
5-30 minutes |
60 |
20 |
20 |
Show
|
| directly on the machine |
machine |
MATCH toolchain
VS Code
Github Copilot
Github
Jira
Confluence |
only starting
in github in pull request
two AI agents (still not configured right)
manually |
1-5 minutes |
40 |
30 |
30 |
Show
|
| Typically, it is best to test on the actual hardware if available. If the actual hardware is not available, we have evaluation boards that have the same controller and we are able to scope pins. |
Our fw runs on a Renesas 'S5' microcontroller w/ a 32-bit Arm proc. Target is ZSeries Power supplies |
MS Visual Studio, Renesas e2 Studio |
We have periodic code review with our small team, especially at the start of new programs. |
1-5 minutes |
30 |
50 |
20 |
Show
|
| Unit Test (unity), integration tests (Python), code coverage currently performed on FPGA with LDRA, moving to GCOV and CMock. |
Embedded system based on ARC CPU for Bluetooth LE SoC. |
Metaware C Compiler/Debugger.
Python |
Done via Azure DevOps during Pull Request integration. |
31-60 seconds |
30 |
40 |
30 |
Show
|
| We can execute unit tests on the target or without the target.
|
Bluetooth SOC using ARC CPU and our custom IPs.
We write all the drivers and integrate a BLE stack. |
Metaware compiler/debuguer with Visual Studio Code |
Using Azure Devops pull request to make the code review |
30-60 minutes |
40 |
40 |
20 |
Show
|
| Unit Tests, we are able to run them on the target or without the target.
Regression (Integration) tests.
We write python tests which send HCI commands over SPI to the target. |
Bluetooth SOC using ARC CPU and our custom IPs.
We write all the drivers and integrate a BLE stack. |
Metaware compiler/debuguer with Visual Studio Code. |
We use Azure DevOps and git for pull requests. |
31-60 seconds |
30 |
50 |
20 |
Show
|
| Using test suites with CxxTest |
I don't understand the question |
Microsoft Visual Studio Code
Microsoft Visual Studio |
Tools: QAC++ static analysis, CxxTest framework, Make build system, integrated regression testing |
1-2 hours |
60 |
10 |
30 |
Show
|
| Almost all of my code runs through functional/blackbox tests with minimal unit testing. |
My target system is an IBM Z Mainframe |
Mostly Bob/vscode and its extensions, not much else. |
We need at least our feature leads and integration managers to review code to merge in. |
1-5 minutes |
70 |
10 |
20 |
Show
|
| I run it on the hardware and test for functionality |
Mostly STM32 |
Mostly STM32 |
Done more senior coders |
Under 10 seconds |
30% |
20% |
50% |
Show
|
| Unit test, automated test, |
printers |
NA |
NA |
31-60 seconds |
3 |
5 |
2 |
Show
|
| Using unit test and developer tests. |
|
Programming using Visual studio code and compiling debug code with MSVC/MSVC++ |
|
31-60 seconds |
5 |
2 |
3 |
Show
|
| Mostly through firmware level verifications with hardware to sus out edge cases. Core functions are identified and individual development tests laid out. This often happens after much of the code is written though. |
Low level firmware in microcontrollers (AVR,ARM, PIC), but also GUI dev, webservers, embedded |
STM32 IDE, Microchip Studio, Visual Studio, Espressif IDE, Arduino IDE, MPLabs |
Code reviews are organic and change from project to project based on available senior developers |
5-30 minutes |
50 |
10 |
40 |
Show
|
| Writing system Tests based on customers use cases. |
Telecoms multiplexer equipment. Embedded Linux. |
SVN, IAR Studio, VsCode, QtCreator |
Use the Atlassian Crucible tool which allow comments to be added to individual lines of code |
1-5 minutes |
60 |
20 |
20 |
Show
|
| Printf statement to follow-up code execution, toggling GPIOs when performances are requested.
Used VectorCast for unit and integration testing (long time ago). |
ARC CPU with few KBytes of memory. |
Synopsys ARC toolchain and debugger.
Git for source code management.
Digilent Digital Discovery |
Pull requests done when a branch has to be merged within the develop main branch. |
11-30 seconds |
30 |
30 |
40 |
Show
|
| On Device Black box testing |
Multiple ARM 32-bit systems. One multi core WiFi/BLE, one BLE, one low level hardware driver. |
VS Code
GDB
Various hardware debug tools
|
One Person Firmware team. Self Review and sometimes AI tools |
31-60 seconds |
75 |
10 |
15 |
Show
|
| Blackbox System Level Test |
Multiple Cortex-MX devices |
VS Code + extensions
Salea |
I am the only Embedded Developer on my team currently. I need better tools for test/etc |
31-60 seconds |
50 |
10 |
40 |
Show
|
| Ideally, unit-testing off target HW, if "required", on HW. Integration testing using our QA team's harness, then any BLE SIG tests. I also will do some basic personal smoke testing of my features iteratively. |
ARCv2 ASIC running BLE stack. |
VS Code, GDB, gcc toolchain when building on Linux, Docker, Metaware toolchain when built on target. |
First, I review over the intent of the change, then I go over other things like readability, tests. |
5-30 minutes |
40% |
30% |
30% |
Show
|
| Pytest |
Currently cross-platform Python. In the past, PIC or PSoC. |
VS Code, Git. For embedded: MPLAB X IDE, PICkit, PSoC Creator, oscilloscope/logic analyzer, etc. |
~weekly meetings to go over updates and discuss changes |
11-30 seconds |
30 |
45 |
25 |
Show
|
| Unit testing, integration testing, qualification tests, and with an internally development test system. |
Embedded ARC |
VS Code, Metaware development environment, python |
Code reviews are preformed on an informal basis, but are required. |
31-60 seconds |
25 |
40 |
35 |
Show
|
| Test cases |
EM made SoC |
VS Code, WSL2, Confluence |
n/a |
1-5 minutes |
8 |
8 |
10 |
Show
|
| Unit tests and manual testing. |
A55 and Nordic processors running Zephyr. |
VS Code, gcc, git. |
All pull requests are reviewed by another person to check basic functionality and completion of DoD. |
11-30 seconds |
60% |
20% |
20% |
Show
|
| Unit test and integration test |
s390 |
VS code, IBM bob |
2 round of manual code review by sme |
1-5 minutes |
30 |
30 |
40 |
Show
|
| Unit test and integration test |
s390 |
VS code, IBM bob |
2 round of manual code review by sme |
1-5 minutes |
30 |
30 |
40 |
Show
|
| Write UT code along with the Feature. Make use Unit Test passes. Then test using breakpoints
Perform Software Validation tests as well as Software Verification Test |
Multi-processor platform using BLE to communicate with other system components. |
VS, IAR, custom Automation tool |
Code reviews are done via PRs. Also use Mobbing style for code walkthroughs |
1-5 minutes |
60 |
20 |
20 |
Show
|
| Mostly manual with occasional integration/unit testing |
Internal Engine Tooling |
VS, VSCode, Intellij |
Custom tool for code reviewws |
Under 10 seconds |
2 |
3 |
5 |
Show
|
| Not sure I just started |
Python wrapper around a C++ api |
VSCode |
not sure I just started here |
31-60 seconds |
3 |
3 |
4 |
Show
|
| Manual, SITL, HITL |
Embedded linux or embedded |
VSCode |
We have peer reviews by a senior person |
5-30 minutes |
40 |
40 |
20 |
Show
|
| Writing unit tests, integration tests and end-to-end tests |
N/A |
VSCode |
Talking through with another developer |
11-30 seconds |
7 |
1 |
2 |
Show
|
| TDD |
Battery-powered, embedded ARM A-core device |
VSCode and open-source compilers |
Quick checks of functionality and making sure the objectives of the task/story were accomplished. |
Under 10 seconds |
40 |
40 |
20 |
Show
|
| We currently use pytest in our test framework |
Embedded software for control systems |
VSCode, Claude Code |
We have code reviews on Github from other members of our team |
5-30 minutes |
20 |
20 |
60 |
Show
|
| Occasional unit tests. By running the code. |
Mostly STM32 based boards. PX4 Autopilot. |
VSCode, Emacs occasionally. GDB, some of the simple SWD probes, STLink. |
A team member or lead reviews a pull request. Not done as a group. |
11-30 seconds |
80% |
5% |
15% |
Show
|
| Unit tests, automated tests, manual tests, static code analysis |
Embedded device with three independent processors |
VSCode, GCC, IAR |
Github PR reviews, invite team of 6 devs and 5 testers |
5-30 minutes |
40 |
50 |
10 |
Show
|
| using shell on zephyr |
imx93 platform running Zephyr RTOS |
VSCode, GIT and bitbucket |
Average 50 hours we spend for every sprint of 2 weeks length. |
11-30 seconds |
10 |
5 |
5 |
Show
|
| Unit tests, on target tests, automated tests (via a simulator) |
It's an embedded system that primarily uses two processors. |
VSCode, IAR, Git, GitHub |
They can take awhile since that's the first time some people see the code |
31-60 seconds |
40 |
30 |
30 |
Show
|
| Unit testing, functional testing, manual testing, regression testing |
wireless embedded systems |
VSCode, Linux, IDEs |
peer reviews and SME approval |
11-30 seconds |
5 |
6 |
8 |
Show
|
| A mix of unit tests and manual testing |
- |
VSCode, Visual Studio |
- |
11-30 seconds |
4 |
2 |
4 |
Show
|
| manually |
ARM Cortex-A55 running Zephyr RTOS, and an ARM Cortex-M device (BLE radio) also running Zephyr. |
VSCode, gcc, git/bitbucket |
Code reviews are done manually for every pull request. |
11-30 seconds |
25 |
50 |
25 |
Show
|
| Management Framework Integration Tests (MFIT), python scripting end2end tests.
Unit Tests (Gtest) |
Debian OS for Telecommunications |
VSCode, with some extensions |
At least one reviewers must approve before delivery, and none can disapprove. |
1-5 minutes |
20 |
60 |
20 |
Show
|
| unit tests, pyttests |
I've worked a lot with backend data systems. I want to learn testing for live, real-time systems. |
VScode |
not frequent enough |
11-30 seconds |
50 |
10 |
40 |
Show
|
| Using prints and testing behavior |
Embedded system running Zephyr |
VScode
JLink
StateSmith |
All code is reviewed before merging to master. Code is reviewed and tested |
Under 10 seconds |
50% |
25% |
25% |
Show
|
| Unit, integration & end-to-end tests, CI & manual |
Various embedded systems |
Various: VSCode, functional safety compilers, CI |
Scrum |
11-30 seconds |
25 |
10 |
25 |
Show
|
| Write unit/component tests after coding completed (in current role, previously used TDD in another job) |
C++ firmware |
Visual Code |
GitHub reviews |
1-5 minutes |
20 |
30 |
50 |
Show
|
| Iam not doing currently heavy programming. But I did test using automated unit tests with JUnit |
TDD as mindset to develop embedded app. |
Visual Code,
Unity... |
using primarily Pull request. |
1-5 minutes |
XX |
XX |
XX |
Show
|
| First unit testing, then integration tests (automatic when possible), and finally manual system level partial testing (full system level verification and validation is done by other departments). |
Usually embedded systems (RTOS or linux), but sometimes PC |
Visual Code, makefile, cmake, propietary compilers, git, QAC static analyser |
Our processes include peer reviews before the feature branch is merged. |
1-5 minutes |
30 |
30 |
40 |
Show
|
| Mix of manual and unit tests |
PC |
Visual Studio |
Mostly used to spot architectural inconsistencies and standards deviations. |
11-30 seconds |
60 |
10 |
30 |
Show
|
| Primarily manually with some unit tests |
Cross-platform for Windows and macOS |
Visual Studio |
Often asynchronous, sometimes used for spotting bugs as opposed to purely for alignment/sharing |
11-30 seconds |
5 |
2 |
3 |
Show
|
| gtest |
windows/linux/osx/ios/android |
Visual Studio |
Every change is reviewed, but not blocking. |
11-30 seconds |
7 |
1 |
2 |
Show
|
| Initially, personally against requirements. Then some basic CID tests, then via games played on internal regions, then more extensively via Public Beta games. |
All flavours of PC/Mac and mobile. |
Visual Studio |
1 - 4 reviewers required per change. Reviews via Swarm |
31-60 seconds |
50 |
10 |
40 |
Show
|
| Scenario testing with scripted events, verfying certain outcomes.
Automated testing with mouse / keyboard interactions. |
We test video game functionality and windows programs. |
Visual Studio |
We have SMEs look at code as well as TLs. We have a system for people to become reviewers. |
5-30 minutes |
60 |
15 |
25 |
Show
|
| Unit tests, functional tests, manual QA |
Desktop and mobile devices |
Visual Studio
Qt Creator
Emacs
Renderdoc |
Perforce Swarm |
Under 10 seconds |
5 |
1 |
4 |
Show
|
| Combination of unit and functional tests |
Game Engine |
Visual Studio
VS Code
Visual Assist
Perforce
Proprietary |
We have them for every checking from a selection of SME's team members |
11-30 seconds |
60 |
30 |
10 |
Show
|
| Run through a series of test in editor and game to confirm expected behavior, and identify any edge cases |
We develop for PC, Mac, Android, and IOS, but primarily target PCs. The codebase is > 18 years old |
Visual Studio, RenderDoc, Sublime Text, |
We use Swarm, and Peer review our code, requiring at least one SME sign off |
1-5 minutes |
3 |
1 |
6 |
Show
|
| C: flash it onto an MCU , step thru with debugger until something goes wrong. In RTOS, hopefully with logging messages |
CC2340, MSP430, python is for automating my lab |
Visual studio + copilot
CCstudio |
None, solo |
11-30 seconds |
40 |
10 |
50 |
Show
|
| Usually running in a debugger. |
Windows and Mac PCs |
Visual studio, neovim, vscode, xcode. |
When reviewing I focus on potential issues/bugs and maintainability. |
1-5 minutes |
20 |
30 |
50 |
Show
|
| Ah-hoc playthroughs. |
PC games, typically low-end machines e.g. older laptops. |
VisualStudio + in-house tools. |
2-4 people review with discussions. |
11-30 seconds |
30 |
30 |
40 |
Show
|
| Unit tests only |
NA |
WSL, VS code, git, docker, jenkins, jira |
Pair programming or AI review my code |
Under 10 seconds |
20 |
20 |
60 |
Show
|
| unit test, integration tests, system tests |
Card Application SW running on zync ultrascale arm cortex core processor |
bitbucket, eclipse, ms code, various plugins |
in bitbucket. Required review and approval for all PRs |
1-5 minutes |
30 |
40 |
30 |
Show
|
| depends on the project.
- on target with unity
- off target with ceedling
- system level integration tests |
it varies
- arc core (ASICS and general SoC)
- risc V core (ASICS)
- some assembly (custom ISA) |
ci/cd pipelines
clang format/tidy
code coverage tools
MISRA etc...
requirement management |
lacking. It seems we never have enough time for good reviews. |
31-60 seconds |
5 |
3 |
2 |
Show
|
| unit tests
integration tests
end to end tests
all run every build |
embedded linux device with supporting PC work. |
clion |
Pair programming only. |
31-60 seconds |
30 |
40 |
30 |
Show
|
| As ASPICE mandates (3 layers) |
It's a Bluetooth SOC. |
cmake, clang goodies, CPU supplier toolchain, IBM DOORS, Azure devops, etc. |
Formally, there is a checklist. Practically, we use our engineering judgement. |
Under 10 seconds |
2 |
7 |
1 |
Show
|
| Unit tests, manual tests, automated tests |
ble, arm |
gcc, nvim/vscode, jtag debuggers, simulators |
mostly performed per pull request. We have been mobbing pull requests |
5-30 minutes |
10 |
60 |
30 |
Show
|
| unit tests |
ai system |
git, jenkins, vs code |
I check for clarity and readability |
5-30 minutes |
50 |
25 |
25 |
Show
|
| n/a |
n/a |
n/a |
n/a |
11-30 seconds |
n/a |
n/a |
n/a |
Show
|
| mainly ml code, so includes validating data pipelines, model performance, and reproducibility using the unit tests, integration tests, and metric based evaluations |
microcontrollers, embedded devices, edge ai accelerators and npus |
pytorch / tensorflow, huggingface, scikit, xgboost, mlflow, onnx, nvidia |
focus on code clarity, reproducibility, data handling, evaluation logic. mix of software and ml |
1-5 minutes |
50 |
30 |
20 |
Show
|
| using the bluetooth qualification tests and verifying manually in specific instances |
an embedded firmware system written in C running on target |
visual studio code as an IDE, cmake to build the firmware, ninja as a compiler |
code reviews happen in PRs by the people reviewing the change, rather informally done asynchronously |
Under 10 seconds |
50 |
20 |
30 |
Show
|
| Build it and run it. |
nRF54 and nRF52 devices and iMX93 devices. |
vsCode
Zephyr
West
|
We have a pull-request system and reviews must be done. |
11-30 seconds |
3 |
2 |
5 |
Show
|
| module trace |
z/os |
vscode |
required |
5-30 minutes |
3 |
3 |
3 |
Show
|
| Manually
Unity |
ARC MCU |
vscode
clang-format
|
PRs must have 2 approvals |
Under 10 seconds |
20 |
40 |
40 |
Show
|