5 ms·

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

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#discussion_r307131392 https://github.com/micropython/micropython/pull/4669#discuss... Seems bizarre to me that rpi didn't just create a non-proprietary library.

Zenst 4y ago
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.
- unwind 4y ago
  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-connectivity/airoc-wi-fi-plus-bluetooth-combos/cyw43439/ https://www.infineon.com/cms/en/product/wireless-connectivit...
  - Zenst 4y ago
    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.
    - unwind 4y ago
      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-IEEE-802.11-b-g-n-MAC-PHY-Radio-with-Integrated-Bluetooth-5.0-Compliance-AdditionalTechnicalInformation-v03_00-EN.pdf?fileId=8ac78c8c7ddc01d7017ddd033d78594d https://www.infineon.com/dgdl/Infineon-CYW43439-Single-Chip-...
      - Zenst 4y ago
        I found under the block diagram of https://www.infineon.com/cms/en/product/wireless-connectivity/airoc-wi-fi-plus-bluetooth-combos/cyw43439/ 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.
    - anotherhue 4y ago
      Likely, the computation needed for n almost certainly exceeds that needed for basic IoT logic.
    - baybal2 4y ago
      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.
  - targafarian 4y ago
    > 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 https://yo3iiu.ro/blog/?p=1301
    - zozbot234 4y ago
      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.
    - varispeed 4y ago
      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.
Normille 4y ago
>...but it never eventuated Has anyone seen my Babel Fish? I think it just fell out
- vertis 4y ago
  I think you're a couple of decades too early for the Babel Fish. https://www.merriam-webster.com/dictionary/eventuate https://www.merriam-webster.com/dictionary/eventuate
  - Normille 4y ago
    >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.
goodpoint 4y ago
Raspberry Pi never put openness first.
aallan 4y ago
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."
- black_puppydog 4y ago
  point of GP being availability of source, not freedom as in beer.
KaiserPro 4y ago
> 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.
- tinus_hn 4y ago
  The point is they could be using these very same chips, but with an open source driver.
  - KaiserPro 4y ago
    > 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.
  - samatman 4y ago
    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.
stoplying1 4y ago
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.
- tomcam 4y ago
  Man, thanks for doing all that work.
Siecje 4y ago
rpi has never been about open source.
yc20220630102 4y ago
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.

Zenst 4y ago

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.

unwind 4y ago
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-connectivity/airoc-wi-fi-plus-bluetooth-combos/cyw43439/ https://www.infineon.com/cms/en/product/wireless-connectivit...
- Zenst 4y ago
  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.
  - unwind 4y ago
    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-IEEE-802.11-b-g-n-MAC-PHY-Radio-with-Integrated-Bluetooth-5.0-Compliance-AdditionalTechnicalInformation-v03_00-EN.pdf?fileId=8ac78c8c7ddc01d7017ddd033d78594d https://www.infineon.com/dgdl/Infineon-CYW43439-Single-Chip-...
    - Zenst 4y ago
      I found under the block diagram of https://www.infineon.com/cms/en/product/wireless-connectivity/airoc-wi-fi-plus-bluetooth-combos/cyw43439/ 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.
  - anotherhue 4y ago
    Likely, the computation needed for n almost certainly exceeds that needed for basic IoT logic.
  - baybal2 4y ago
    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.
- targafarian 4y ago
  > 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 https://yo3iiu.ro/blog/?p=1301
  - zozbot234 4y ago
    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.
  - varispeed 4y ago
    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.

Normille 4y ago

>...but it never eventuated Has anyone seen my Babel Fish? I think it just fell out

vertis 4y ago
I think you're a couple of decades too early for the Babel Fish. https://www.merriam-webster.com/dictionary/eventuate https://www.merriam-webster.com/dictionary/eventuate
- Normille 4y ago
  >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.

goodpoint 4y ago

Raspberry Pi never put openness first.

aallan 4y ago

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

black_puppydog 4y ago
point of GP being availability of source, not freedom as in beer.

KaiserPro 4y ago

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

tinus_hn 4y ago
The point is they could be using these very same chips, but with an open source driver.
- KaiserPro 4y ago
  > 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.
- samatman 4y ago
  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.

stoplying1 4y ago

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.

tomcam 4y ago
Man, thanks for doing all that work.

Siecje 4y ago

rpi has never been about open source.

yc20220630102 4y ago

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.