Hire by skill · Firmware and embedded software
Hire a CAN Bus Developer
A CAN bus developer designs and implements how a device talks on a CAN or CAN FD network: identifiers and priorities, bit timing, acceptance filters, error handling and the DBC file that documents every message. Talent Badger's bench includes firmware specialists with CAN and FDCAN skills, available fractionally or per project to build, debug or review a CAN interface.
What CAN bus firmware work covers
- Message design: identifiers assigned so time-critical messages win arbitration (the lowest ID wins), with periods, payload layouts, scaling and units defined in a DBC file that serves as the interface contract.
- Bit timing: prescaler and time segments calculated from the peripheral clock, with one sample point agreed across every node, and for CAN FD a separate data-phase bit rate with transceivers rated for it.
- Peripheral setup and filtering: on STM32 FDCAN, the message RAM and acceptance filters are configured before the peripheral is enabled, so the CPU only sees the IDs it needs.
- Interrupt-driven receive: an RX callback that copies the frame and hands it to a dispatch table keyed by ID, instead of polling, with no blocking or slow work inside the callback.
- Errors and diagnostics: error-passive and bus-off detection with a defined recovery policy, timestamped TX and RX logging while debugging, and traffic checked with a CAN analyzer against the DBC.
Signs you need a CAN specialist
- Frames go missing or arrive late under bus load, and nobody has checked the ID priorities or the receive path.
- A node goes bus-off in the field and stays silent until someone power-cycles it.
- You're moving from classic CAN to CAN FD and need bit timing, transceivers and filters redone.
- Message definitions live in a spreadsheet or in one person's head, and the firmware, test tools and other teams disagree about them.
How to vet a CAN bus developer
- How do you assign CAN identifiers? A strong answer ties priority to deadlines, since the lowest ID wins arbitration, and checks worst-case bus load and latency before the IDs are frozen.
- How do you choose bit timing and the sample point? Expect a calculation from the peripheral clock through prescaler and time segments, one sample point across all nodes, and for CAN FD, transmitter delay compensation at higher data rates.
- What happens when a node goes bus-off? Look for the error counters (error-passive above 127, bus-off when the transmit counter exceeds 255), the 128 × 11 recessive-bit recovery rule, and a deliberate choice between automatic and application-controlled recovery.
- Walk me through your receive path. Strong answers use an interrupt, copy the frame out quickly, dispatch by ID through a table and push slow work to a task or the main loop; blocking in the callback is a red flag.
- What tools do you use on a misbehaving bus? Listen for a USB-CAN interface or analyzer with DBC decoding, timestamped logs from the firmware itself, and a scope on CAN_H and CAN_L when the problem is physical.
Cost and engagement shape
- On Talent Badger each profile shows a rate band set by assessed level, from $95/hr at engineer level up to $245/hr at the top of the most senior band.
- Typical shapes: a CAN or CAN FD driver for one controller, a message set and DBC across nodes, a bus-off or lost-frame investigation, or a review before system integration.
- Planning range, not a quote: developing and integrating one defined block, such as an FDCAN driver with filters, dispatch and error handling, is commonly budgeted around 40 hours. Load that by about 1.3–1.5× for reviews, meetings and contingency.
- Analyzer hardware or test benches are quoted as line items. Billing is milestone-gated, and IP assignment is signed before work begins.
Common questions
They define and implement how each node uses the bus: the message set and its priorities, bit timing, filters, error handling and the DBC file every team works from. Much of the work is diagnosis: lost frames, nodes going bus-off, or timing that breaks as bus load grows.