Device communication and controls
Developed web controls for rectifier DC output voltage, current limits and read requests. The interface supports a shared CAN target, broadcast selection and direct targeting when a rectifier is selected.
Embedded Linux.
Real-world power control.
Connecting Linux services, CAN communication and practical device controls on an AM62x platform.
01 / OVERVIEW
A controller is more than a board running Linux. It needs to communicate with equipment, expose useful controls and make its own behaviour observable.
01Operator controls02Linux services03CAN communication04Power equipment
Simplified conceptual overview of the work, not an implementation schematic.
02 / THE CHALLENGE
Where the engineering
gets interesting.
Power-system development crosses several boundaries: the CAN bus, application services, an operator interface and the Linux image deployed to the target. A change only becomes useful when those parts work together on the device.
03 / MY CONTRIBUTION
The work I brought
to the system.
Feedback from the actual device
Added visibility of the rectifier-reported current limit, bringing device feedback into the same workflow as command entry.
Embedded Linux development
Work with the PHYTEC phyCORE-AM62x / phyBOARD-Lyra platform, Yocto images, CAN services and Redis-backed application state. Development includes target bring-up, deployment checks and hardware/software debugging.
Hardware integration
Investigated peripheral integration on the AM62 platform, including I²C device discovery, addressing and voltage-domain compatibility with an external ADC.
Configuration and lifecycle design
The ongoing engineering scope includes battery capacity and state-of-charge settings, current and power limits, Ethernet configuration, firmware-update recovery and audit records. These topics form part of continuing controller development.
04 / VALIDATION
Check the behaviour.
Development uses on-target checks alongside source and image verification. My Yocto workflow distinguishes rapid devtool deployments from changes integrated into an image, helping identify when the software running on a board does not match the intended source revision.
- Targeted and broadcast CAN commands
- Device-reported control feedback
- Repeatable build and target verification
05 / OUTCOME & REFLECTION
What the work adds up to.
The work includes implemented rectifier controls and device feedback, alongside continuing controller development. Firmware-update recovery, configuration persistence and audit logging remain part of the continuing lifecycle design work.
The most useful diagnostic is often the connection between layers: what the interface requested, what the communication service sent and what the hardware reported back.
LET’S CONNECT
Good ideas deserve
good engineering.
↗Have a product, an integration challenge or an engineering role in mind?
I’d be happy to hear about it.