News for hackers. Stuff that matters.
Re:The amazing $1 microcontroller (2017) by SV_BubbleTime on Thursday September 10, 2020 @03:47AM (#24429900)
Interesting take because I see the Nordic HAL (nrfx) as a little heavy. Just tracing out toggling a GPIO it’s at least 6 function calls, the register is abstracted to some unknown pointer called reg or cb (control block, not callback), they don’t ever seem to intend anyone to trace through their driver.

I like the Nordic chips, the event system and DMA is very good. But even their events are abstracted out where you aren’t allow access to the ACTUAL interrupt, you get to send a callback that on ISR they promise to call for you with a context pointer when they allow it (SPI) and when they don’t you are in your own (GPIO event callbacks).

Yes, Nordic does take it “seriously”, but also heavy and complicated. I’d love to see a light implementation of their drivers instead of a HAL that is supposed to cover all models all time. No one actually switches chips like that.

Re:The amazing $1 microcontroller (2017) by jwr on Thursday September 10, 2020 @05:24AM (#24430438)
I'm also worried about nrfx. But I think it is the price you pay if you want to have a BLE/Mesh stack running. You can't really go all bare metal anymore.

The way I see it is a spectrum: on one end, you go bare metal and write your own startup code, TPM0_IRQHandlers and implement core stuff in assembly (been there, done that). On the other end, you run Linux and who knows what's happening on your extremely complex system and whether it will run at all the next day. I think Nordic is trying to find a balance inbetween.

Re:The amazing $1 microcontroller (2017) by SV_BubbleTime on Thursday September 10, 2020 @02:54PM (#24435384)
All true.

Nrfx has some stupid decisions made in it. Like #if #define where if you don’t “enable” something the variables aren’t ever defined. Which means for me I have some SPI code that throws errors when SPI INST 2 isn’t enabled. My code is still valid, it’s just that variables that used to exist no longer do. Annoying. It doesn’t cost anything to “enable” the peripherals in preprocessor.

It’s ~47 instructions in the example I just checked to get a return from nrf_gpio_pin_read(some_pin) that’s not good. It also reminds me that nrfx and nrf aren’t the same and when you need to use one vs the other is anyone’s guess.

I do like their ASSERT() and use it for my own things. It’s report function is weak so i can overload it with one that reports to my other FreeRTOS threads.

Nordic isn’t bad, but they went a little overboard with the HAL. I don’t want “one code” that runs on all chips poorly. I want chip specific code that runs great and yes I’ll have changes to make if I switch chips, but that’s life!

Not only can’t you go bare metal with BLE and real complexity, but with a modern RTOS and knowledge of when you need a thread there is no reason to on chips with 48Mhz and 512kB Ram.

FWIW, I do recommend Amazon FreeRTOS but investigate their LTS version they are moving to if you look into it.