Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nordic is getting involved in RISC-V

blog.nordicsemi.com

Post reply on HN
Print view View original

91–100 of 122 posts

Re: Nordic is getting involved in RISC-V

#91

Post by lionpixel »

fullstop wrote: post #63
lionpixel wrote: post #58

Earlier quoted context omitted.

For $9.90 you get a Seeed Xiao NRF52840[1] board with Arduino support. In sleep mode it consumes just 1µA. In my spare time I'm building smart locks with these that last for up to 2 years with a CR123 battery. Recently I switched from Arduino to the nrf Connect SDK and a tiny nrf52832 board that cost just 4$ on AliExpress. Works like a charm. [1] https://www.seeedstudio.com/Seeed-XIAO-BLE-nRF52840-p-5201.h...

Yeah, Nordic crushes it right now with their sleep mode. Espressif is making progress in that area, though, but they have a lot of ground to make up. Out of curiosity, how do you flash the nrf52832 board?

With SWD and a Tag-Connect connector[1]. I watched someone on youtube recommend it due to the small space and low profile. You can use the VSCode NRF Connect SDK plugin (coupled with Jlink or NRF52 dev kit) to flash the device. But of course you can just use USB und copy a generated .hex file directly on the device. I use SWD because its faster to flash many boards by just pressing the pogo pins on the connector pad. Boom done. :)

[1] https://www.tag-connect.com/product/tc2030-ctx-nl-6-pin-no-l...

Re: Nordic is getting involved in RISC-V

#92

Post by StillBored »

freeopinion wrote: post #29
fullstop wrote: post #13

Earlier quoted context omitted.

Unless things have changed recently, Nordic is still king of low power applications. With that being said, I've worked with both the Nordic NRF SDK and the Espressif SDK and greatly preferred Espressif. For doo-dads that I make for my home, esp32 and esp8266 are fantastic. The modules are inexpensive and the community is huge. I would not want to be in Nordic's shoes right now.

It's easy for us hobbiests to forget that all the spare do-dads we have floating around our workbench aren't even a drop in the bucket compared to the number of chips bought by a single manufacturer for a single model of a kitchen blender. We matter a little and can be somewhat of an indicator sometimes. Right up until we don't. A lot of times what matters to us just doesn't apply at scale.

But these kinds of things also seem to follow a tech playbook, cheap parts show up, lots of hobbyist, small companies, etc start using them in low volume applications. They work out the bugs, and the newer competitors parts keep getting better. The existing big company doesn't care because, as someone else pointed out they are maintaining a stable volume/revenue.

Only, in the tech industry that's almost always a bad sign, the competitors are winning new designs that haven't yet really started to ramp, while the existing vendor is coasting on the current device using their parts. Then what happens is they get stuck in a declining revenue/volume situation while the newer cheaper better competitor slowly eats the market, and at that point investing in a "dying" product just about never happens.

Re: Nordic is getting involved in RISC-V

#93

Post by AussieWog93 »

paulgerhardt wrote: post #47
audunw wrote: post #19

Earlier quoted context omitted.

> "getting crushed by a wave of very low cost Chinese competitors" That's an odd way of spelling "maintaining a stable market share in the face of Chinese competition". Going forward, IoT security is going to be an increasingly important factor for new designs. The EU is quite serious about combating security problems with IoT devices. And security is something that the new products coming out of Nordic is very serio…

Having bought a few hundred thousand Nordic chips I can assure you they don’t care about security in a meaningful sense. All Nordic chips are susceptible to bootloader attacks which make them a poor choice for storing key material. This can be mitigated in the design phase by adding an external security chip like a ATECC608B but if you were to tear down a device and see a board present without this module it certainl…

>Having worked extensively with both Nordic and Chinese chips, what makes Nordic win is the ease of development

This seems to be the norm for Chinese chips in general.

Poor documentation, even in the native Chinese, no official dev boards, sometimes no JTAG debuggers, random bugs, just a whole lot of bullshit to deal with as a foreign developer.

I suspect it might be a cultural thing; developers are less prone to pouring over data sheets and more prone to asking their friends/colleagues to introduce them to someone who works at one of the microcontroller companies. (This is just a hunch, and I could be completely wrong.)

Re: Nordic is getting involved in RISC-V

#94

Post by lgg »

wallaBBB wrote: post #42
fullstop wrote: post #35

Earlier quoted context omitted.

I've only used the nRF5 SDK. It worked, and it worked well, but it was cumbersome to work with if you didn't want to keep your code in the same tree as the the SDK itself. This was probably an organizational issue on my part, honestly. The other thing which really bit me was someone here used a symbol name which collided with one used in the SDK, but the build system allowed this to link without error.

nRF5 is indeed inferior SDK of the 2 (thus abandoned). Also I dislike that a big chunk of the stack there is a binary blob. Regarding the code organization, not sure what toolchain you used, but the latest recommendation for nRF5 (Segger studio) could make it fairly easy to do this, but manually opening the project config files and changing them, not through the GUI. nRF Connect is a different world, comes with a lot…

I have been out of this area for almost a decade now, but I have very fond memories of the nRF5 SDK. When I was evaluating the (then new) Nordic BLE SoC's for future products it was so much nicer than the TI CC2540 we had used in our first BLE device.

Re: Nordic is getting involved in RISC-V

#95

Post by AussieWog93 »

IshKebab wrote: post #85
sitkack wrote: post #82

Earlier quoted context omitted.

The chips themselves are $1 qty 1. Remove the old chip, put your unlocked chip in its place.

It's beyond most people's ability, equipment and effort threshold to order 1 chip from digikey (how much is delivery on that $1?) and replace a QFN package.

>how much is delivery on that $1?

From AliExpress, it'd probably be $2-$3 including shipping.

They don't ask questions when ordering large volumes of microcontrollers either.

Re: Nordic is getting involved in RISC-V

#96

Post by josephcsible »

msgilligan wrote: post #89
josephcsible wrote: post #74

Earlier quoted context omitted.

The problem with TrustZone is that control of it always resides with a megacorp and never with the owner of the device. It's not that it isn't security at all, but rather that it's security against the owner.

The owner can control Trustzone if the device is shipped with unfused OTP registers. On Raspberry Pi for example, you can write the hash of your own public key to locations 47-54 of the OTP memory block: https://www.raspberrypi.com/documentation/computers/raspberr... Here's the QuickStart for the entire process: https://github.com/raspberrypi/usbboot/blob/master/secure-bo... Note that the Raspberry Pi does not have a…

OTP and e-fuses are also evil. Devices should never be forced to become e-waste over them being set "wrong". There should always be a factory reset option that clears everything.

Re: Nordic is getting involved in RISC-V

#97

Post by bfrog »

IshKebab wrote: post #84
bfrog wrote: post #61

Espressif always seems to be ahead of the game. The premade compliant modules, shifting to riscv, providing a rust sdk, and so on. I like Nordic products in some ways but they are becoming very complex and not necessarily in all the right ways. Esp32 having ble and Wi-Fi in a single part is especially appealing, add in I can now program in rust and avoid all the cruft of C and it’s becoming an ever harder sell.

In fairness they were previously using Xtensa which is a far worse option than Arm so they had a much bigger incentive to switch to something that people actually wanted.

for sure, but yeah an fcc licensed ble/wifi/riscv module for $2.50 on digikey? yeah that's a win

Re: Nordic is getting involved in RISC-V

#98

Post by zh3 »

paulgerhardt wrote: post #47
audunw wrote: post #19

Earlier quoted context omitted.

> "getting crushed by a wave of very low cost Chinese competitors" That's an odd way of spelling "maintaining a stable market share in the face of Chinese competition". Going forward, IoT security is going to be an increasingly important factor for new designs. The EU is quite serious about combating security problems with IoT devices. And security is something that the new products coming out of Nordic is very serio…

Having bought a few hundred thousand Nordic chips I can assure you they don’t care about security in a meaningful sense. All Nordic chips are susceptible to bootloader attacks which make them a poor choice for storing key material. This can be mitigated in the design phase by adding an external security chip like a ATECC608B but if you were to tear down a device and see a board present without this module it certainl…

The security issues also cause inconvenience, e.g. the later revisions of the nrf52 needing either a recover operation or updated firmware (the hack of flashing a default bootloader in recovery mode that disables security is...interesting).

That aside, Nordic still seems the best choice out there though quite a lot of features are leveraging the ARM ecosystem. RISC-V involvement is possibly toe in the water stuff/de-risking from ARM ("who owns them today?"). The recent big switch in SDK's (nrfSDK to Zephyr) wasn't teribly welcome, so the possiblility of another one is not welcome (if there was an approximately equal competitor with more stability we'd jump ship).

Re: Nordic is getting involved in RISC-V

#99

Post by zh3 »

fullstop wrote: post #35
wallaBBB wrote: post #32

Earlier quoted context omitted.

There are actually 2 Nordic SDKs, nRF5 (now in maintenance, but still in many supported products in the field) and nRF Connect (bundled with Zephyr). Later gives a lot of access to both Host and Controller part of the stack and for commercial products that are not simply flipping a lightbulb it is still a standard. ESPs are good for quick hacks and more competitive with Nordic if low power is not an imperative.

I've only used the nRF5 SDK. It worked, and it worked well, but it was cumbersome to work with if you didn't want to keep your code in the same tree as the the SDK itself. This was probably an organizational issue on my part, honestly. The other thing which really bit me was someone here used a symbol name which collided with one used in the SDK, but the build system allowed this to link without error.

The simple hack is a softlink to the actual SDK.

On the other hand, checking in the whole SDK as part of a project gives an impressive LoC tally ;)

Link issue was possibly macro craziness? The scars of sdk_config.h etc.

Re: Nordic is getting involved in RISC-V

#100

Post by fullstop »

zh3 wrote: post #99
fullstop wrote: post #35

Earlier quoted context omitted.

I've only used the nRF5 SDK. It worked, and it worked well, but it was cumbersome to work with if you didn't want to keep your code in the same tree as the the SDK itself. This was probably an organizational issue on my part, honestly. The other thing which really bit me was someone here used a symbol name which collided with one used in the SDK, but the build system allowed this to link without error.

The simple hack is a softlink to the actual SDK. On the other hand, checking in the whole SDK as part of a project gives an impressive LoC tally ;) Link issue was possibly macro craziness? The scars of sdk_config.h etc.

If you base your project off of one of the examples, the project file has relative paths back to the SDK. For example:
No amount of symlinking can fix this, and there's a lot of these files. Maybe copying an example project is not the right way to do things.

The link issue was, I think, the result of what Nordic does with weak symbols. I don't recall the symbol name, but it was something which caused very unusual results.

Regarding LoC tallies, I often try to minimize mine. :-)

Post reply on HN