Hacker News Reader

Comment by Zenst | Hacker News Reader

Maybe a few factors at play here:

Wireless/RF drivers tend to be closed source for what I understand gets down to bad code can cause RF no noes. Hopefully somebody more knowlegable will chip in upon that though it is common (sadly) for your mobile driver to be some closed blob.

They may also be working on such a library and still need a lot of work, which could be why BT/BTE is not enabled as is though mooted at a later date.

Might also be that the community is large and momentomous enough that the hope is that they will produce the goods in open source spirit. Certainly the whole graphics driver stack upon the RPi's seems to be going down both those last two paths in it's open source flavour.

View on HN

All true, but the radio chip [1] has two on-board ARM cores (an M3 for Wi-Fi and an M4 for BT) each with separate ROMs. So I would assume the library just interfaces with the chip and tells it what to do, not implement low-level radio protocols and so on. Weird that such a library is closed source, on the other hand. Annoying. :(

Edit: forgot to include the link to the radio chip.

[1]: https://www.infineon.com/cms/en/product/wireless-connectivit...

Very useful - so does the wifi chip have faster ARM cores than the RP2040 microcontroller which has M0+ cores is what I'm wondering now.

The cores are faster/better, but the one public document I found [1] without logging in to Infineon does not specify how they are clocked. Weirdly, the document says that both Wi-Fi and Bluetooth have M3 cores, no M4 mentioned.

The chapter on Wi-Fi says this:

10.1 WLAN CPU and Memory Subsystem

The CYW43439 includes an integrated ARM Cortex-M3 processor with internal RAM and ROM. [...] On-chip memory for the CPU includes 512 KB SRAM and 640 KB ROM

And for Bluetooth it has this:

8. Microprocessor and Memory Unit for Bluetooth

The Bluetooth microprocessor core is based on the ARM Cortex-M3 32-bit RISC processor with embedded ICE-RT debug and JTAG interface units. It runs software from the link control (LC) layer up to the host controller interface (HCI). The ARM core is paired with a memory unit that contains 576 KB of ROM for program storage and boot ROM, and 160 KB of RAM for data scratch-pad and patch RAM code.

Strange and confusing.

Edit: quote markup, added mising section number for BT.

[1]: https://www.infineon.com/dgdl/Infineon-CYW43439-Single-Chip-...

I found under the block diagram of https://www.infineon.com/cms/en/product/wireless-connectivit...

Does shows it does have an M4 as you stated, that is for the BT stack.

Likely, the computation needed for n almost certainly exceeds that needed for basic IoT logic.

Yes, and that's why ESP32 can be so cheap. They just run the WiFi stack on the same core, and they got very good know-how on the side of hardware<->RTOS interaction how to make it viable (very hard.)

Imho, non-wireless-intergrated MCUs will go extinct in IoT very soon.

They also have the best mixed signal out of every other scrawny IoT startup who uses off-the-shelf IP.

> not implement low-level radio protocols

You don't have to re-implement protocols to commit FCC (or pick your local reg agency) no-no's. See e.g. discussion by this HAM radio operator on his blog (doing legal things, but you can easily do this for non-legal things):

https://yo3iiu.ro/blog/?p=1301

That blog post is describing hardware-specific configuration tweaks. It's quite possible for firmware to check that these are regulation-compliant, and good quality hardware will typically do this.

Even if you don't write custom RF code, you still need to go through certification, so it does not really matter if user can or cannot write their own custom code. It may be just a bit more expensive to get it certified if you make a mistake.

Reply on news.ycombinator.com