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.
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.
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.
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.
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.