Silicon for industrial communication
This namespace covers the silicon we build industrial communication on: one page per vendor family, describing what the parts actually do in an automation design, which protocols they carry, and what we have built on them. It is written from the integrator's side: what bring-up involves, where the part's real constraints are, and which evaluation kits are worth the bench time. AEI Corporation does BSP, driver, firmware and protocol-stack work on these platforms.
How is this namespace organised?
One page per vendor family, each following the same shape: what the family is and which automation slot it fills · where it fits in a system · what we have built on it · a dev-board and evaluation-kit table with an honest “none yet” where there is nothing to show · training on that hardware · how to engage.
That last column is deliberate. A vendor page that lists only successes tells you nothing about whether the part has been touched; the table says plainly which kits are in the lab and which are not.
What is here now?
- Analog Devices — ADIN6310 TSN switch, ADIN1100/2111 10BASE-T1L single-pair Ethernet, fido5000/RapID multiprotocol platform
- Texas Instruments Sitara — PRU-ICSS/ICSSG industrial Ethernet firmware, AM64x/AM243x, C2000 motor control
- Silicon obsolescence and end-of-life migration — what happens when a communication controller is discontinued
Pages in preparation, in wave order: NXP (LS1028A, i.MX RT/8M Plus), Moxa, Intel (i210/i225 ETF/TAPRIO), AMD/Xilinx (Zynq, Kria), STMicro (STM32MP2, STM32H7) and Renesas (RZ/N2L, RZ/T2M). They are listed here rather than linked because the pages do not exist yet. Links appear as pages land.
How does silicon choice interact with the platform choice?
They constrain each other, and getting the order wrong is expensive. An MMU-less core rules out Linux; a hard microsecond deadline points at a programmable real-time unit or dedicated hardware rather than a general core; a 20-year service obligation rules out any part without a published longevity commitment. Decide the timing and lifecycle requirements first, then the part, then the operating system. See embedded platforms for the OS side of that decision.
Protocol-specific quick-start guides stay in the protocol tree under industrial Ethernet; the vendor pages here link to them rather than duplicating them.
Where does AEI's work sit?
Board bring-up and BSP development on custom hardware, industrial-Ethernet firmware on the vendor's real-time cores, protocol stack integration, and the lifecycle work that follows when a part goes end-of-life. We hold evaluation kits for the platforms we work on, which is why the dev-board tables on these pages are specific rather than generic.