Hacker News Reader

Comment by atVelocet | Hacker News Reader

For SiLabs Si4xxx (e.g., Si4463) chips there is also this wonderful repo:

https://github.com/astuder/Inside-EZRadioPRO

There are basically four main OEMs for SubGHz radios (hobby projects): - Analog Devices (ADF7xxx) - SiLabs (Si4xxxx) - Semtech (SX1xxx) - Texas Instruments (CCxxxx)

If i remember correctly the Analog Devices and the Semtech radios share the same internal core (blackfin?). Please correct me if i am wrong. For the Semtech and ADF702x there are firmware patches and/or ROMs available. The most interesting part would be to unlock the internal test mode which some of those chips have…

View on HN

Which open source stacks work with Infineon CYW43439 (used on Pico w and Pico 2W)? I know about BTstack, but apparently NimBLE is not ported to this chip.

I'm also curious, of all the available BLE chips, which one has the "most sane" development environment? I had the misfortune of using the SiLabs BLE chips, and it seems like the Dev Environment was meant for Web dudes or something -- it seemed very foreign to me, an embedded guy. It was like 5 layers to go from their SDK down to the machine instruction that would set the value of a GPIO pin hi or lo. Confused documentation, spread out over dozens of not-related sections, weird configuration wizards, etc. Now, the Hardware seemed just fine, but gosh, the Dev Environment?

I've heard good things about Nordic's environment, but haven't used it. I also know nothing about TI's or AD's.

Opinions appreciated!

The older Nordic SDK wasn't too bad (once you get over the learning curve). Trying to start a project from scratch is challenging though, so much easier to pick the closest example, get that going and modify from there.

However, they've deprecated the old SDK [0] in favour of Zephyr [1] and quite a number of people struggle with it (check the forums and general internet). I have less experience with Zephyr, but both of them use a lot of python support tools which seem to suffer from versioning amd compatibility problems (even trying to keep a stable platform has been difficult here, what works one time doesn't work a few months later). YMMV.

[0] https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/ind...

[1] https://www.zephyrproject.org/

There are good reasons for depreciating the nrf5 sdk. However, I’m not sure how long the Nordic Semi lead is going to last.

Previously if there was a project that came up that didn’t strictly need BLE, I’d recommend the nrf5 sdk because it was reliable and stable. Now with the new sdk they are encouraging people to write firmware that’s much easier to port to other mcus (with zephyr) and the development experience has much higher cognitive load.

Thats been my experience also. The tooling for Zephyr is pretty lousy, especially configuration. Kconfig hell.

Reply on news.ycombinator.com