Add flow-control type to radio FW name

[hlyi]

@jnilo1

This is a nice-to-have feature. please feel free to do it after v4.0.0 release. I just want to document it before I forget.

Currently, the name convention for Radio FW is <fw_type>, it would be great to have flow control type in the name. Especially, it is useful when we are developing a new board, and we want to try different configuration. Maybe something likes this will be helpful: <fw_type><flow_control_type><uart_driver_type>.

Thanks for considering this.

[jnilo1]

Implemented for v4.0.0 (this also closes the -hw-/-sw- naming nit from #130)

Done the way you outlined, with one change: the flow-control type goes on every baud-bearing firmware, but the UART-driver type only on OT-RCP. The driver is only a real choice there — NCP and the Z3 router are always the iostream-usart backend, RCP is always CPC, and the bootloader has no baud or flow — so a driver field on those would be a constant that carries no information (and could read as if it were selectable). On OT-RCP it varies (uartdrv vs iostream), so that's where it belongs.

<flow> is the as-built value, so it matches what flash_efr32.sh records as FIRMWARE_FLOW_CTRL. One consequence: RCP has no software flow control (CPC is RTS/CTS-or-none), so a sw board's RCP is built — and named — none.

Scheme (the bootloader is unchanged — no baud/flow in its name):

Firmware	lidl	sengled-e39-g8c
NCP	ncp-uart-hw-7.5.1-115200-hw.gbl	ncp-uart-hw-7.5.1-115200-sw-sengled-e39-g8c.gbl
RCP	rcp-uart-802154-460800-hw.gbl	rcp-uart-802154-460800-none-sengled-e39-g8c.gbl
OT-RCP	ot-rcp-460800-hw-uartdrv.gbl	ot-rcp-460800-sw-iostream-sengled-e39-g8c.gbl
Router	z3-router-7.5.1-115200-hw.gbl	z3-router-7.5.1-115200-sw-sengled-e39-g8c.gbl

Notes:

• flash_efr32.sh resolves the new names by anchoring <flow>/<driver> exactly from the board's BOARD_UART_FLOW, so it stays a single deterministic match and a forced-driver build (UART_DRIVER=iostream ./build_ot_rcp.sh → ot-rcp-460800-hw-iostream.gbl) never shadows the default ot-rcp-460800-hw-uartdrv.gbl.
• The old bare -iostream marker is gone: the driver is always spelled out now, so a forced build differs by its driver field rather than by an add-on suffix.
• Committed prebuilts were renamed (contents unchanged); the legacy no-baud artefacts (ot-rcp.gbl, etc.) are left as-is.

Queued for v4.0.0, along with the rest of the batch waiting on the issue #99 soak.

[hlyi]

@jnilo1 Thanks for implementing the consistency enhancement! That's great.

I have a few questions:

1. what's drawback using iostream driver instead of DMA driver ( for RCP firmware on Lidl)?
2. I am not familiar with CPC, is it independent of flow control being used? If I want to try out CPC, will be safer to enable SW flow control?

Thanks

[jnilo1]

1 — the driver choice does not exist for RCP; for OT-RCP the cost of iostream is CPU per byte

Worth separating first, because it is the reason the driver field is only on OT-RCP: RCP has no such choice. The CPC secondary stack owns the UART itself, so there is no uartdrv-vs-iostream decision to make there (and none to encode in the filename). NCP and the Z3 router are always the iostream USART backend. OT-RCP is the one firmware where the backend is genuinely selectable: the OpenThread platform abstraction compiles iostream_uart.c or uartdrv_uart.c purely from which USART instance the project declares — a project-level swap, zero firmware code.

So, for OT-RCP on the Lidl, what do you give up by taking iostream instead of uartdrv? uartdrv is DMA-first — the LDMA moves the bytes, the CPU sees a completion per buffer, so the per-byte cost is near zero. iostream takes an interrupt per byte. At 460800 that is on the order of 46 000 RX interrupts per second at full line rate, on a Cortex-M4 that is also running RAIL's timing-critical 802.15.4 work. That is the drawback on paper, and it is why uartdrv stays the default on a board that wires RTS/CTS: hardware flow control is strictly the better protection, and DMA is the cheaper way to get it.

In practice we could not measure a penalty: an iostream OT-RCP at 460800 with hardware flow ran clean on our Lidl bench — 30 back-to-back spinel operations, network formed, state leader, no link errors, then left soaking. That is what made the backend swap trustworthy enough to ship for sw boards in the first place. The reason we still do not switch the Lidl to it is simply that there is nothing to gain: the only thing iostream buys is complete XON/XOFF, which a board with RTS/CTS does not need. (One trap if you ever build it yourself: iostream defaults to LF→CRLF conversion, which would corrupt binary spinel. Our header turns it off.)

2 — CPC is hardware-flow-or-nothing, by construction — enabling sw flow would be worse, not safer

CPC is not independent of flow control, but it has no software mode, and that is structural rather than an omission. Look at the wire format: a CPC frame is a 7-byte header (flag 0x14, endpoint, length, control, header checksum) followed by a length-prefixed payload, with no byte stuffing (server_core/core/hdlc.h in cpcd). Nothing is escaped, so a payload byte of 0x11 or 0x13 is indistinguishable from XON/XOFF. Any XON/XOFF layer under CPC would eat frame content. Contrast the OT-RCP path, where software flow control is viable precisely because OpenThread's HDLC encoder escapes 0x11/0x13.

Hence the EFR32 CPC UART driver offers RTS/CTS or nothing, and cpcd's only knob is uart_hardflow: true|false. On a board with no RTS/CTS wiring, CPC therefore runs with no flow control at all: the build clamps BOARD_UART_FLOW=sw to none for RCP, and flash_efr32.sh records FIRMWARE_FLOW_CTRL=none so the in-kernel UART bridge — which is the chip's actual flow partner, since cpcd reaches it over TCP — arms to match instead of eating in-frame 0x11/0x13 as flow characters.

So: enabling software flow control would not be safer, it is not available, and forcing the bridge into sw mode against unescaped CPC frames would be actively harmful. What protects you instead is (a) CPC's own reliability layer — sequenced I-frames, header and payload checksums, ACK with a retransmission timeout — so a frame lost to a FIFO overrun is retried rather than desynchronising the session, which is a materially better failure mode than raw spinel has, and (b) baud headroom.

Please do try it at the 460800 default first. We genuinely do not know whether CPC holds at 460800 on a board with no flow control — nobody has ever run the RCP path on a G4, and you are the only person who can find out. The reasoning above says the FIFO will overrun under burst, but reasoning is not measurement: CPC retransmits, so the honest question is whether the retry rate is negligible or crippling, and that is an empirical question about your box. Either answer is worth having, and it goes straight into the docs.

The instrument is the same one we used for OT-RCP: cat /proc/tty/driver/serial and look for an oe: field on the ttyS1 line — it only appears once the hardware overrun counter is nonzero. Pair a few devices, push some traffic, then check. If oe: stays absent and the network is stable, 460800 works and we will say so. If it climbs, step down to 230400, then 115200, and report where it goes clean — that boundary is the useful number, and it is one we cannot produce ourselves.

Whatever you find, post it here. Right now the G4 RCP path is built but never functionally validated by anyone, so your result — good or bad — is the first real data on it. (NCP remains the validated Zigbee path on your board in the meantime.)