[HN Gopher] SDK update for Raspberry Pi Pico W unlocks Bluetooth...
       ___________________________________________________________________
        
       SDK update for Raspberry Pi Pico W unlocks Bluetooth support
        
       Author : _Microft
       Score  : 148 points
       Date   : 2023-02-11 10:07 UTC (12 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | dgacmu wrote:
       | For those looking to find this specifically, it's about 79% of
       | the way to the bottom with sub-heading:
       | 
       | > Bluetooth Support for Pico W (BETA) The support is currently
       | available as a beta. More details will be forthcoming with the
       | actual release. In the meantime, there are examples in pico-
       | examples.
        
         | rogerbinns wrote:
         | > The Bluetooth API is provided by BTstack
         | 
         | From https://github.com/bluekitchen/btstack
         | 
         | | BTstack is free for non-commercial use. However, for
         | commercial use, tell us a bit about your project to get a
         | quote.
        
           | efitz wrote:
           | I was so excited until I read that. I'm working on an IoT
           | device that I hope to sell and was going to build it around
           | an RPi; I would love to switch from nano to pico but need
           | better Bluetooth.
        
             | gswdh wrote:
             | [dead]
        
             | tagyro wrote:
             | The motto of Bluetooth is "It's going to work great ...next
             | year!". I've had so many challenges working with it in my
             | past projects (even writing my own firmware) that I now try
             | to avoid it and go directly to wifi.
        
             | philsnow wrote:
             | Will you be able to source enough rpi modules? I guess your
             | plan isn't just "buy them off the (online) shelves" because
             | it's nigh-impossible to get more than a couple that way
             | these days.
        
             | Gabriel24 wrote:
             | So go ahead and use Bluetooth on the Pico? Selling your IoT
             | device is explicitly supported, you just have to get a
             | license.
        
               | efitz wrote:
               | Yes, but at what cost per unit?
        
             | ta988 wrote:
             | See my other comment above, this will be allowed on RP2040.
        
           | ta988 wrote:
           | (edited, did a bit of research after complaining)
           | 
           | "It will be licensed by us for more permissive use on RP2040
           | (like cyw43-driver)"
           | 
           | Seen on https://github.com/raspberrypi/pico-sdk/issues/1164
        
             | yencabulator wrote:
             | What does that mean, though? Wouldn't they need an open
             | source license for everything in BTStack except non-RP2040
             | drivers? There's a daemon, there's a "libusb", etc. This
             | sounds like it'd require open sourcing practically all of
             | BTStack, not just one driver?
        
               | nulld3v wrote:
               | There's really not that much. "libusb" is just the port
               | of BTStack to the libusb API.
        
               | yencabulator wrote:
               | I'm just curious about the backstory; did the RPi
               | foundation pay BTStack to be ok with this sudden open
               | sourcing?
        
       | nirav72 wrote:
       | The pico is an amazing little board. Im using it with micro-
       | python and HID library to simulate subtle mouse movements every
       | 120 seconds to prevent RDP session to remote server from closing
       | due to lack of activity. Now with bluetooth support, I can just
       | hopefully toggle it on or off or disable. Instead of removing the
       | usb cable from the notebook.
        
         | mouse_ wrote:
         | bluetooth mouse jiggler sounds like a potentially revolutionary
         | concept
        
           | [deleted]
        
         | winter_blue wrote:
         | I'm not impressed by it. It's got 264 _kilobytes_ of RAM. That
         | 's so low, that you can't run Linux or BSD on it. I guess you'd
         | need some DOS-like OS for it.
         | 
         | This chip sells for $8.45 which is ridiculously high for what
         | it offers[1].
         | 
         | The price of $0.80 per chip non-W is impressively low however,
         | I'll admit. [2] But once you throw shipping and other costs in,
         | how much will it actually cost?
         | 
         | The Pi Zero 2 W at $15 is far far better than this chip. [3]
         | 
         | [1] https://www.pishop.ca/product/raspberry-pi-pico-w/
         | 
         | [2] https://www.raspberrypi.com/news/raspberry-pi-direct-buy-
         | rp2...
         | 
         | [3] https://www.microcenter.com/product/486575/raspberry-pi-
         | zero...
        
           | sosborn wrote:
           | This is apples and oranges. Microcontrollers aren't meant to
           | be SBCs.
        
           | gambiting wrote:
           | >>That's so low, that you can't run Linux or BSD on it. I
           | guess you'd need some DOS-like OS for it.
           | 
           | Absolutely no offence, but I think you are absolutely, 100%
           | missing the point of microcontrollers, like by a nautical
           | mile. It's the kind of chip that you'd have inside a
           | humidifier and it controls the fan turning on or off
           | depending on the read from the humidity sensor. It absolutely
           | doesn't need to run a full OS, and in fact it would be a
           | detriment to it and its abilities.
           | 
           | I have several Pico Ws around the house acting as sensor
           | boards and I wouldn't replace them with Zero Ws even if they
           | were free - it's just a worse board for that kind of job.
        
             | winter_blue wrote:
             | Did you pay circa $8.45 for each of your Pico Ws?
             | 
             | My problem is the price point. At that price point, you can
             | get a full power chip. The Pico W should be selling for
             | $0.90 so, if it were to be good value.
        
               | gambiting wrote:
               | I paid PS5.90 each.
               | 
               | >>At that price point, you can get a full power chip.
               | 
               | You see, this is the problem right here - you got it in
               | your head that this isn't a "full power chip", whatever
               | that even means. It's as "full power" as any
               | microcontroller that has ever existed.
               | 
               | Once again ,it isn't meant to run an OS. The price is
               | more than justified by the rich development environment
               | with plenty of support(both official and community
               | driven) as well as good connectivity options implemented
               | directly on the board. The closest thing I can think of
               | is a cheap ESP8266 board like a D6 Mini, but cheap
               | chinese clones of that sell for PS4 on ebay, barely any
               | cheaper than the Pico W - an official D6 board is about
               | PS12, so not only it costs more - it actually offers less
               | functionality and power.
               | 
               | If you know what this chip is for and what it's competing
               | against, you'd see that in fact the value here is
               | outstanding.
        
           | avmich wrote:
           | While we don't yet have a Unix for Pico - correct me if I'm
           | wrong - we have this -
           | https://news.ycombinator.com/item?id=34446251 - a small
           | RetroBSD clone for an ARM, a Cortex-M0 one.
           | 
           | DOS-like OS is also possible... RetroBSD creator is
           | apparently looking into it:
           | https://vak.dreamwidth.org/982612.html
        
         | bratao wrote:
         | You can't use autohotkey?
        
           | bornfreddy wrote:
           | Thanks, TIL: https://en.m.wikipedia.org/wiki/AutoHotkey
        
         | VLM wrote:
         | > I can just hopefully toggle it on or off or disable
         | 
         | I used an accelerometer. Just a funny UI idea, flip it upright
         | to jiggle the mouse.
         | 
         | I used a different board of course, although you could add an
         | generic accelerometer to a Pico W pretty easily.
        
         | Eduard wrote:
         | Here is the Bluetooth Mouse HID sample demo from the Bluetooth
         | stack which the Pico W is using, Bluekitchen:
         | 
         | https://github.com/bluekitchen/btstack/tree/master/example/h...
        
           | nirav72 wrote:
           | Perfect. This might be what I'm looking for to get started.
           | thank you!
        
       | incanus77 wrote:
       | I'm happy to see a built-in I2C responder library, even if it is
       | an incorporation of the most popular community one. I'm working
       | on a board with a bare RP2040 as a responder and currently my
       | firmware is in MicroPython, which at best has a polling, third-
       | party responder library. I've already decided to now move the
       | firmware to the C SDK and this seems like good timing.
        
       | benj111 wrote:
       | I don't understand why they didn't use something like an esp for
       | the wireless. That seems to be more open. Is it a cost thing. Or
       | is the esp equally closed but has a front end that isn't?
        
         | mmoskal wrote:
         | If you have ESP (most of them anyways) you don't really need
         | the RP2040 anymore - you can run all your code on the ESP. Also
         | there are all that geopolitical concerns about Chinese
         | networking gear coming with more than you asked for.
        
         | ajb wrote:
         | The wireless chip they used is a cypress chip but the design
         | was by Broadcom, who sold it to Cypress (now owned by
         | Infinion). A lot of the Pi team are ex-Broadcom and probably
         | have a good working relationship with the team that make that
         | chip. That will give them good confidence that any issues can
         | be sorted out because they can get the attention of the right
         | people. It's related to the chips which they use on the
         | original Pi line
         | 
         | RF in general is pretty closed. Last I heard the ESP low level
         | drivers for wifi and BT were closed source (but that was a few
         | years back). There is a lot of resistance to opening RF, partly
         | to please incumbents but partly because of concerns that
         | completely open RF would cause a radio spectrum "tragedy of the
         | commons" - BT and wifi protocols need each tranceiver to behave
         | in order to share the spectrum, if people could easily tweak
         | it, people could easily take the spectrum at the expense of
         | their neighbours. (for example, see https://fsfe.org/activities
         | /radiodirective/radiodirective.en...)
        
           | benj111 wrote:
           | Surely the pi foundation is big enough now to be able to get
           | through the front door of any chip maker.
           | 
           | I'd like to see them using that clout to get (more) open
           | hardware.
           | 
           | Protecting against tragedy of the commons through obscurity?
           | Seems misguided. You could make the same claims about
           | software, or SDR. And it isn't As if the Pico is high
           | powered...
        
           | robert_foss wrote:
           | Having worked with creating drivers for Qualcomm (but not
           | worked at Qcom) I can't stress enough how important is to
           | have connections with people who are familiar with the
           | hardware or have access to documentation.
        
           | mytailorisrich wrote:
           | Yes, between Broadcom and Arm, Raspberry Pi is very much a
           | product of the Cambridge (UK) microcosm.
        
           | RF_Savage wrote:
           | That tragedy of commons thing is why any consumer product
           | where you could modify the radio transmitter firmware would
           | loose its FCC certification, making it illegal to sell in the
           | US.
           | 
           | That almost ended the sale of openwrt (or other open
           | firmware) compatible wifi routers in the US. The compromise
           | that was reached was that radio firmware would be signed
           | blobs that would not be user modifiable, but that everything
           | else could be modifiable while retaining the FCC
           | certification.
           | 
           | I sure wish we could teach no tricks to the very capable RF
           | hardware in many things. But things like the FCC and NDA's
           | from IP vendors make that hard.
        
             | ac29 wrote:
             | > That tragedy of commons thing is why any consumer product
             | where you could modify the radio transmitter firmware would
             | loose its FCC certification, making it illegal to sell in
             | the US.
             | 
             | This is not true. FCC equipment approvals have both a
             | frequency range and power level. What the FCC tried to
             | clarify is that devices should not be able to be "easily
             | modified" to operate outside of these approved parameters,
             | which has always been true since way before radios had
             | anything that could be considered software or firmware. For
             | example, it would be against the rules to sell a radio
             | certified for 1W power output that had a 5W power amplifier
             | inside that could be enabled by removing a screw or
             | something.
             | 
             | Firmware modification, in general, is not against FCC
             | rules. For example, new firmware that lowered maximum power
             | would be permissible (or firmware changes that did not
             | affect the emissions of the device at all).
             | 
             | Here is the specific document from the FCC:
             | https://s3.documentcloud.org/documents/2339685/fcc-
             | software-...
        
       | codetrotter wrote:
       | That's a big W for the Pico W. If you know what I mean. :smirk:
        
       | jenadine wrote:
       | And I am still waiting for the WiFi support in the Rust rp-rs
       | crates
        
         | mvniekerk wrote:
         | For Embassy-Rs there is this: https://github.com/embassy-
         | rs/cyw43
         | 
         | I've tested it myself and it works great. Plus async Rust on
         | embedded is nice.
        
           | grawp wrote:
           | I'm still waiting for the AP mode :(
        
       | levpopov wrote:
       | I love RP2040 (especially how circuit designer and firmware dev
       | friendly it is) and even tried building my own MCU with it[1]
       | 
       | However I don't _quite_ see the Bluetooth use case - RP2040 is
       | not really a low power chip, making it pretty hard to use for a
       | battery-powered IoT application. You 'd need a pretty giant
       | battery pack to make it last a long time.
       | 
       | Nordic's nrf52 is an order of magnitude better for a typical
       | "sleep-burst transmit-sleep" cycle, and can be suspended to <5uA
       | current. Pico W is $6, Seeed has a $10 nrf52 MCU, or you could
       | get a "just hook up USB and power" bare module for $5-6.
       | 
       | [1] https://twitter.com/levpopov/status/1623376630378008576
        
         | TaylorAlexander wrote:
         | One use case would be a little desktop robot for an educational
         | setting. The motors of a robot use orders of magnitude more
         | power than the CPU so it needs big batteries anyway.
         | 
         | I can also imagine applications where the device has wall power
         | but you want to connect to it with a phone. Like a piece of
         | wall art you want to be able to turn on and off remotely.
        
         | packetlost wrote:
         | There are a _lot_ of IOT applications that do rely on battery
         | power. Regardless, this is nice for people whose MCU /embedded
         | experience is limited to pre-existing firmwares and the Arduino
         | ecosystem.
        
         | regularfry wrote:
         | I've got a bunch of ESP32's piggy-backing on USB chargers
         | around the house doing BLE and wifi stuff. The things they're
         | talking to are battery powered, but I want them plugged in to
         | the mains. I could easily see myself using the Pico W in that
         | job.
        
         | mmoskal wrote:
         | nit: MCU is Micro Controller Unit, so for example rp2040
         | itself. What you mean is "board".
         | 
         | Completely right on the power consumption though. The NRF52 is
         | also quite good at limiting power consumption while it's
         | running and automatically disabling peripherals while not used
         | (you typically do that with disabling clocks on other chips).
         | It also has the sanest hardware registers I've seen (looks like
         | they were actually designed with software in mind).
        
           | levpopov wrote:
           | Yes, thanks for the correction! In DIY keyboard community a
           | microcontroller breakout board is often referred to as MCU
           | which makes things confusing.
        
         | makomk wrote:
         | There's also a fully open source Bluetooth stack for the Nordic
         | chips (Apache nimBLE) compared to the non-commercial use only
         | but with some vague and possibly not yet available exception
         | for the RP2040 license of the BTstack used here. (This seems to
         | have been enabled by the radio hardware being fully documented,
         | which is very unusual for Bluetooth chips.)
        
       ___________________________________________________________________
       (page generated 2023-02-11 23:01 UTC)