Hacker News Reader

Comment by teruakohatu | Hacker News Reader

If I understand it correctly, it uses the closed-source library libcyw43 from MicroPyton to communicate with the hardware chip.

The library is closed source, I think, because it uses propriety Cypress code.

Cypress apparently since released source code and the author had considered releasing an open source version of the library but it never eventuated. See this discussion from 2019:

https://github.com/micropython/micropython/pull/4669#discuss...

Seems bizarre to me that rpi didn't just create a non-proprietary library.

View on HN

The Raspberry Pi Foundation's ultimate goal is to get access to computing, computer science, robotics and experimentation into the hands of children, especially those that can't afford a conventional PC. Their goal is not to advance free software or open source or any of that stuff. The GPU on Raspberry Pis (which is basically the master controller of the entire system) is a repurposed chip that was meant for cable TV set-top boxes and is very proprietary.

From the launch blog post, "The network stack is built around lwIP, and uses libcyw43 from Damien George (of MicroPython fame) to communicate with the wireless chip. By default, libcyw43 is licensed for non-commercial use, but Pico W users, and anyone else who builds their product around RP2040 and CYW43439, benefit from a free commercial-use license."

point of GP being availability of source, not freedom as in beer.

It's not remotely bizarre. Distros take on so much god damn work because of the quality of firmware, etc releases. It's a real nightmare. Go check the firmware commit log. Or try to figure out what version of the kernel, firmware, dtbs, eeprom, and more, are actually tested by the Foundation.

Doing some work for (distro), I've spent an enormous amount of time building automated, hdmi-captured, media-less-netboot testing platform and you wouldn't believe the number of bugs I hit or slight behavior changes I saw as various firmware updates landed. Usbboot (nee rpiboot) is not really great or well written. Oh I forgot by/wifi firmware is in two more repos, with no instructions on usage, and they keep renaming files breaking my work.

So, yeah, I'm not remotely even 1% surprised by this.

Man, thanks for doing all that work.

> Seems bizarre to me that rpi didn't just create a non-proprietary library.

There is a chip shortage on, so having a volume supply wifi chips is a miracle.

Not having to pay a licensing cost is also rather a good deal.

As with all things here, perfect is the enemy of good.

The point is they could be using these very same chips, but with an open source driver.

Another point is that chip suppliers can pick their customers until supply issues resolve, which there's no sign of.

Should chip suppliers view open-source drivers as undermining their competitive advantage? I don't think so, but they tend to, and this isn't a great time for RasPi to get on their bad side.

It's also not their mission, although that's been pointed out enough. Call it a battle for another day.

> they could be using these very same chips, but with an open source driver.

You are not understanding the issues. If it was an option, the Rpi foundation would have taken it. Shipping closed drivers, to an opensource project is a ball ache, and leads to lovely people claiming that the foundation is there to stifle this and under mine that.

Its far more dull than that.

Its either a compliance thing (opensource drivers might need re-certifying the wifi) Contractual: its a seller's market and in order to get the best value, the foundation had to use the drivers provided.

Raspberry Pi never put openness first.

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.

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.

rpi has never been about open source.

  >...but it never eventuated

Has anyone seen my Babel Fish? I think it just fell out

I think you're a couple of decades too early for the Babel Fish.

https://www.merriam-webster.com/dictionary/eventuate

  >Other British grammarians, and even some Americans, agreed that it was horrible. Eventuate is less controversial these days, though its use is still regarded by the occasional critic as pompous, ponderous, and unnecessary...

Glad I'm not the only one.

Reply on news.ycombinator.com