Author Topic: Looking at BLE SOCs, nRF52  (Read 8029 times)

0 Members and 1 Guest are viewing this topic.

Offline JPorticiTopic starter

  • Super Contributor
  • ***
  • Posts: 3461
  • Country: it
Looking at BLE SOCs, nRF52
« on: November 08, 2023, 09:31:17 am »
I'm asking here because i know there are some nordic afficionados, we are considering transitioning one product from MCU + BLE Module to an integrated solution, and before diving in i wanted to ask some questions.
To throw a partnumber: nRF52810

First, it seems that the nordic parts are not plagued by dealbraker erratas such as in the ESP32, and that is good. By looking at the errata it seems that the NRF52 ADC is actually usable, good. And the PWM module while being fairly simple seems to be Good Enough™ for analog signal generation. So far so good.

However, i don't understand if there are input capture and output compare modules. That is a hard requirement because we need to acquire and generate some bitbanged signals with microsecond resolution (which is not a problem for a lowly PIC24 at 16MIPS, but with ARM cores, i honestly don't know)
It seems the timer module implements input capture and output compare but i don't know the limitations if i want to do both, and the total amount of channels (2in + 2out should be enough)

Another question: these devices are single core, which means that the CPU is bound to be spending some time managing the BLE stack. Can i assume that it is going to be a hell of a problem for the bitbanged signal generation/acquisition, which has the top priority? (Provided that DMA can't help me)
How much CPU time should the BLE stack take? because if it's frequent but really short i can work around it, if it's going to take a whole 1-10ms continously, that is going to be a major problem.
Ideally i should look for a dual core device - and there are new STM parts i'm also looking at as well

Final question: is there is a preferred IDE/Toolchain? i'm a fan of prepackaged things that "just work", i see that many sources seem to favor VSCode, which i'm not really a fan of

Bonus: How much of a pain would it be to certify the thing?
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26906
  • Country: nl
    • NCT Developments
Re: Looking at BLE SOCs, nRF52
« Reply #1 on: November 08, 2023, 03:22:15 pm »
Which ESP32 are you referring to? For the ESP32-S3 is errata is pretty short and the software ecosystem is pretty good in my book. I'm currently working on an ESP32-S3 project using BLE and I must say I'm quite happy with the software ecosystem Espressif is providing.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline JPorticiTopic starter

  • Super Contributor
  • ***
  • Posts: 3461
  • Country: it
Re: Looking at BLE SOCs, nRF52
« Reply #2 on: November 08, 2023, 03:58:40 pm »
I remember reading, just a couple of months ago, much longer errata documents for ESP32 modules of the ones i can find now, with many features i was interested in (mainly CAN and ADC) being effectively useless. (NB: this particular application does NOT require CAN, i was just mentioning the fact)
I believe it was the S3
« Last Edit: November 08, 2023, 04:02:06 pm by JPortici »
 

Offline mayor

  • Regular Contributor
  • *
  • Posts: 234
  • Country: ca
Re: Looking at BLE SOCs, nRF52
« Reply #3 on: November 08, 2023, 05:33:20 pm »
Have you checked TI's CC2652? I think it has what you need, having a Cortex M4F, dedicated Cortex M0 core for radio operations, as well as another core for different types of sensor processing (including comparators, for example).
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14470
  • Country: fr
Re: Looking at BLE SOCs, nRF52
« Reply #4 on: November 08, 2023, 07:26:59 pm »
Have you checked TI's CC2652? I think it has what you need, having a Cortex M4F, dedicated Cortex M0 core for radio operations, as well as another core for different types of sensor processing (including comparators, for example).

In terms of power consumption, these TI chips are very good.
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7377
  • Country: nl
  • Current job: ATEX product design
Re: Looking at BLE SOCs, nRF52
« Reply #5 on: November 08, 2023, 08:01:43 pm »
Another question: these devices are single core, which means that the CPU is bound to be spending some time managing the BLE stack. Can i assume that it is going to be a hell of a problem for the bitbanged signal generation/acquisition, which has the top priority? (Provided that DMA can't help me)
How much CPU time should the BLE stack take? because if it's frequent but really short i can work around it, if it's going to take a whole 1-10ms continously, that is going to be a major problem.
Ideally i should look for a dual core device - and there are new STM parts i'm also looking at as well
I'm fairly sure this one also has a coprocessor with some sort of ROM memory handling all the radio things. Most of these 2.4GHz radio chips will, unless it's a dedicated transceiver.
Bonus: How much of a pain would it be to certify the thing?
What certification we are talking about. RED? BT? Honesty, I would just forget about the BT certification, it's a subscription for your company, for every year you could get an 1 GHz oscilloscope or other new toys, or this logo.

Have you checked TI's CC2652? I think it has what you need, having a Cortex M4F, dedicated Cortex M0 core for radio operations, as well as another core for different types of sensor processing (including comparators, for example).

In terms of power consumption, these TI chips are very good.

It's OK, but it's a 5 year old chip and it shows. I've seen chips that have -3dB better receive sensitivity, and use 30-50% less power when transmitting with the same power on this band. That sleep current looks good, but that only matters if your average current consumption is less than 5-10uA, or it's a "smart button" type of thing.
 

Offline bookaboo

  • Frequent Contributor
  • **
  • Posts: 728
  • Country: ie
Re: Looking at BLE SOCs, nRF52
« Reply #6 on: November 08, 2023, 09:07:00 pm »
I’ve used the ESP32-S3 for BLE with very few problems. Pretty happy with ESP-IDF on VS-Code.

My colleague also uses nRF52x because of the lower sleep current available. Occasionally I have to check the code or make a small mod on SES which I don’t find particularly intuitive and as far as I know has no intellisense.

I’d rate Espressif support better too.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14470
  • Country: fr
Re: Looking at BLE SOCs, nRF52
« Reply #7 on: November 08, 2023, 10:40:29 pm »
It's OK, but it's a 5 year old chip and it shows. I've seen chips that have -3dB better receive sensitivity, and use 30-50% less power when transmitting with the same power on this band.

We would be humbly obliged if you cared to share a reference.
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7377
  • Country: nl
  • Current job: ATEX product design
Re: Looking at BLE SOCs, nRF52
« Reply #8 on: November 08, 2023, 10:50:46 pm »
It's OK, but it's a 5 year old chip and it shows. I've seen chips that have -3dB better receive sensitivity, and use 30-50% less power when transmitting with the same power on this band.

We would be humbly obliged if you cared to share a reference.
Most of the Series 2 Silicon Labs Blue Geckos.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14470
  • Country: fr
Re: Looking at BLE SOCs, nRF52
« Reply #9 on: November 09, 2023, 12:26:25 am »
It's OK, but it's a 5 year old chip and it shows. I've seen chips that have -3dB better receive sensitivity, and use 30-50% less power when transmitting with the same power on this band.

We would be humbly obliged if you cared to share a reference.
Most of the Series 2 Silicon Labs Blue Geckos.

OK thanks, I was not really impressed by previous generations of Silicon Labs MCUs, but this Series 2 looks pretty nice.
Looking at the specs of the EFR32BG24, it's clearly superior to the CC2652 even just on paper.
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 826
Re: Looking at BLE SOCs, nRF52
« Reply #10 on: November 09, 2023, 04:16:16 am »
I only do simple ble broadcasting data such as temperature, or device 'odometers' (keep track of run times of devices), but have used nRF52 and EFRBG22.

For the nRF52 (52810 raw device via Laird board, and 52840 usb dongle, later bought an nRF dev board), I was using the command line only (they have a bunch of examples with makefiles), using the led on the 52840 dongle for error codes (many at first, since frequently using sdk wrong), and could get a basic app running without a lot of problems. It is a process at first to figure out the software stack that needs to be loaded, and how to deal with programming via the nRF desktop app (electron app). They also have a big config file with tons of defines/options to sort out or find, which is not pleasant to deal with. The actual hardware is pretty nice, as its generally quite simple work with and things work as expected. (The Segger ide can be used, is free for nRF, but I did not use it).

Not long ago, I started to use an EFRBG22 via a ~$10 board they sell, doing the same projects as the nRF52. Although I'm not a big fan of ide's, their Eclipse implementation is polished and probably took 10 minutes to get a basic example working, and very little time to do the same projects as I was doing on the nRF52. I don't really need to deal with buying the raw mcu as I simply use their cheap dev board or can find cheap boards using the BG22 (Laird, etc.), but looking at mouser, they have lots of stock and quite inexpensive compared to the others. The hardware is also quite simple to deal with, and their sdk is also pretty good.

The bottom line for my simple needs is that the EFR is quite a bit easier to use, has low power consumption similar to the nRF (either which I can get years out of a small 3v battery). Silabs also has plenty of good documentation.

Get some dev boards and simply try them out. It does require some effort to get to a point where a good decision can be made. I had tried Silabs a few years ago, but was lost and gave up too soon. The BG22 for some reason seemed relatively easy- I think they have improved their ide/sdk/documentation quite a bit, so maybe that contributed to success this time. (I don't know what Nordic has done in the last year or so, maybe they have improved also).
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7377
  • Country: nl
  • Current job: ATEX product design
Re: Looking at BLE SOCs, nRF52
« Reply #11 on: November 09, 2023, 01:13:39 pm »
It's OK, but it's a 5 year old chip and it shows. I've seen chips that have -3dB better receive sensitivity, and use 30-50% less power when transmitting with the same power on this band.

We would be humbly obliged if you cared to share a reference.
Most of the Series 2 Silicon Labs Blue Geckos.

OK thanks, I was not really impressed by previous generations of Silicon Labs MCUs, but this Series 2 looks pretty nice.
Looking at the specs of the EFR32BG24, it's clearly superior to the CC2652 even just on paper.
I've been regularly using the geckos in the past 5 years, and I've been very happy with it. The software guys complain about the default IDE, but they always complain about every IDE, so no difference there. What is really nice is that you can re-map all the GPIOs practically everywhere, has a built in very low power DC-DC, loading caps for crystals, and the RF has impressive specs. I regularly get 500m+ range with 10dBm output with inverted F PCB antennas, but they also measure good at EMC/RED.
 
The following users thanked this post: SiliconWizard

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8172
  • Country: fi
Re: Looking at BLE SOCs, nRF52
« Reply #12 on: November 09, 2023, 07:45:09 pm »
I've been using nRF52 extensively lately, and the chip peripheral design is quite fresh which shows in both good and bad sense, mostly good, with great ideas that ease the use and increase flexibility - like routability of any peripheral into any pin, TASK/EVENT system with totally generic interconnect so that any peripheral can work together with any other peripheral, DMA which is so trivially easy to use that they don't offer non-DMA modes on some peripherals at all; etc. That said, you will see strange limitations like a timer incapable of zero-latency resetting at a certain count (obvious with most other microcontrollers; in nRF, you do it using the event system shortcut which still adds some clock cycles of delay), or impossibility of instantly disabling UART because someone thought that it might have to "flush" 4 bytes or some bullcrap like this.

That being said, PWM peripheral is capable of doing quite some advanced stuff from DMA alone - sequences with repeat counts, looping or double buffering, even loading different counter top values from memory for each cycle. They also have good number of peripheral instances, e.g. nRF52833 has five TIMERs, 4 PWM generators, three realtime counters (really useful for low-power stuff). Could be much fewer, actually if you compare to ST for example you see similar number of instances only on the flagship cortex-M7 models.

Lack of generic DMA peripheral which could be triggered to do a transfer from any EVENT (given their excellent EVENT system) is nearly unbelievable, since it would be trivial for them to implement. But it seems you could use TIMER(s) to do input capture and PWM(s) to do output generation, but realistically you would have to prototype it quickly because as with any microcontroller, some weird limitations are not easy to see until you actually start writing code and testing it!

I just did an IR remote signal generation with the PWM peripheral with very little CPU intervention and it was an interesting project; they show you a fully-DMA example idea on web but that is unsuitable for real-world IR remote standards as it would require kilobytes of RAM buffers, but instead I made heavy use of the repeat counts and double buffering of the PWM unit so that the interrupt handler always updates one symbol in advance which makes it forgiving against interrupt jitter, and then the peripheral just repeats configured number of 38kHz cycles and gives an interrupt when the generation of next symbol has started, so that the repeat count for the next after that can be written.

Their SDK, their examples and their softdevices are a complete and utter mess, totally unusable. You have to write code from scratch and use third-party code for BLE if you need that, I'm pretty confident about this now. The difference to their HW design is massive. These MCUs are very nice to program register-level, much easier than STM32 for example, but on the other hand completely impossible to program using any SDK stuff. I spent a full week not getting even a simple LED blinker working with their SDK, and then spent another week writing a completely functional radio stack from scratch using their easy-to-understand radio peripheral on register level!

And the softdevices cannot be used because they are so bloated they don't actually fit to the device with any customer firmware! I don't know what they have been smoking. If you have a 512KB flash device, that will be 256KB after partitioning in two separately upgradeable sections which is mandatory if you want to update the networking stack and not brick devices, and then the BLE stack is over 200KB IIRC so you have some tens of KB for your whole application! Probably they thought you would factory program in their "perfect" softdevice and not allow it to be updated.
« Last Edit: November 09, 2023, 07:57:12 pm by Siwastaja »
 
The following users thanked this post: tellurium

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8172
  • Country: fi
Re: Looking at BLE SOCs, nRF52
« Reply #13 on: November 09, 2023, 07:59:33 pm »
What is really nice is that you can re-map all the GPIOs practically everywhere, has a built in very low power DC-DC, loading caps for crystals, and the RF has impressive specs. I regularly get 500m+ range with 10dBm output with inverted F PCB antennas, but they also measure good at EMC/RED.

How does this differ from nRF52 which you implied performing significantly worse? I'm seeing well over 500m range with 8dBm output with PCB antenna and good margins in EMC/RED, using Fanstell modules. No problems whatsoever.
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 7377
  • Country: nl
  • Current job: ATEX product design
Re: Looking at BLE SOCs, nRF52
« Reply #14 on: November 09, 2023, 08:56:44 pm »
What is really nice is that you can re-map all the GPIOs practically everywhere, has a built in very low power DC-DC, loading caps for crystals, and the RF has impressive specs. I regularly get 500m+ range with 10dBm output with inverted F PCB antennas, but they also measure good at EMC/RED.

How does this differ from nRF52 which you implied performing significantly worse? I'm seeing well over 500m range with 8dBm output with PCB antenna and good margins in EMC/RED, using Fanstell modules. No problems whatsoever.
Well, I was comparing it to the TI CC chip. But if you want  to compare it to the nRF, the max power is 11dB more for some gecko part numbers, which might be over the limit some cases, the receiver sensitivity is 1-2dB better for the BG27 series it's -99dBm for BT. Better sleep modes, and ~50% better RX currents. You have to be careful with the RX currents when comparing, some MCUs define it with DC-DC on, and the radio running on 1.8V though. Also for those nRFs, the ones with a lot of Flash and RAM get a worse radio for some reason.
The Nordic chips are very good compared to other solutions to be frank. If you need USB its a clear winner. I cannot comment on the modules, I have to use my own design.
 

Offline JPorticiTopic starter

  • Super Contributor
  • ***
  • Posts: 3461
  • Country: it
Re: Looking at BLE SOCs, nRF52
« Reply #15 on: November 10, 2023, 12:41:30 pm »
It's OK, but it's a 5 year old chip and it shows. I've seen chips that have -3dB better receive sensitivity, and use 30-50% less power when transmitting with the same power on this band.

We would be humbly obliged if you cared to share a reference.
Most of the Series 2 Silicon Labs Blue Geckos.

OK thanks, I was not really impressed by previous generations of Silicon Labs MCUs, but this Series 2 looks pretty nice.
Looking at the specs of the EFR32BG24, it's clearly superior to the CC2652 even just on paper.

as superior as it might be, it won't make me design in anything radio from sillab. I am still haunted by EzRadios and the geckos from that period

Their SDK, their examples and their softdevices are a complete and utter mess, totally unusable. You have to write code from scratch and use third-party code for BLE if you need that, I'm pretty confident about this now. The difference to their HW design is massive. These MCUs are very nice to program register-level, much easier than STM32 for example, but on the other hand completely impossible to program using any SDK stuff. I spent a full week not getting even a simple LED blinker working with their SDK, and then spent another week writing a completely functional radio stack from scratch using their easy-to-understand radio peripheral on register level!

Though this does not inspire confidence, at all. Being a BLE MCU targeted at BLE communication i expect the BLE peripheral stack to be a black box that just works that exposes a function to register a GATT profile, one to read and one to write a characteristic and a series of interrupts/callbacks for when it is connected/disconnected to a central, characteristic notifications and such things
« Last Edit: November 10, 2023, 12:48:19 pm by JPortici »
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 826
Re: Looking at BLE SOCs, nRF52
« Reply #16 on: November 10, 2023, 06:52:21 pm »
Quote
but on the other hand completely impossible to program using any SDK stuff. I spent a full week not getting even a simple LED blinker working with their SDK

Quote
Though this does not inspire confidence, at all.

I'm not great at mcu, but was able to get their nRF52840 usb dongle to do some examples without a lot of problems. Command line only, except for programming the usb dongle which required their desktop app. There are some things to figure out, like which soft device to use etc. Initially I used an existing example (makefiles), created my own gpio class just from the datasheet, used an led to blink out error codes from the sdk for error return values. Eventually bought one of their dev boards, but used it only for programming a Laird module that had a 52810 on it (and could then use segger rtt to printf debug info via swd, instead of simple led error code blinking). Not saying it was all a walk in the park, but I wouldn't say you have to throw out the sdk and start from scratch. I think one of the reasons I initially chose nRF was because they did not require any registration to download any of their stuff (sdk, apps, etc., could even get the segger ide from segger if wanted without any hassle).

I wouldn't dismiss Silabs based on past experience. I have no previous experience other than I couldn't figure anything out several years ago, using one of their 'thunderboards'. Not that long ago, I bought their ~$10 (more now I think) eval board for a BG22 (BG22-EK4108A) and using their ide was able to easily do examples and create my own projects. Their cheap board has a segger debugger on board, and the ide has everything you need to program/debug, including a network viewer where you can monitor ble. It takes a little to figure out their 'code generator', but once you get a handle on that it is relatively easy (the harder part is simply dealing with ble, which is the same for any mcu). The advantage of this over nRF is everything is under 'one roof' (ide), although nRF users have free access to the Segger ide I think you will still end up dealing with separate parts (ide, nRF desktop app, download sdk and maybe toolchain on your own, etc.), but have not touched nRF for a couple years so may be different now.

Get some inexpensive eval/dev boards for various mcu's that look interesting. Give them a test drive, and get first hand experience. Like all recommendation threads, there can be no substitute for first hand experience even if not extensive. About the only useful info these type of threads can produce is if most agree that something is either horrible or great. There is no one yet commenting on certification (or dealing with the bluetooth cartel), so maybe that info would be useful if someone had first hand experience.

It looks like the advantage you have now is you already have something that works, so can make good comparisons with a real app (not example apps). plus maybe not under pressure to get something else working quickly so can evaluate at a slower pace. It may turn out that your current mcu+ble module is a better solution, although I would suspect cost is the driving factor here.
 

Offline artag

  • Super Contributor
  • ***
  • Posts: 1070
  • Country: gb
Re: Looking at BLE SOCs, nRF52
« Reply #17 on: November 10, 2023, 09:33:19 pm »
With regards to the Nordic SDK, is that the old one (which I found fairly easy to use, though I didn't like having my code buried 15 levels deep in the directory tree) or the new one, which is platformio and VS Code, and therefore a horror ?
 

Offline JPorticiTopic starter

  • Super Contributor
  • ***
  • Posts: 3461
  • Country: it
Re: Looking at BLE SOCs, nRF52
« Reply #18 on: November 11, 2023, 06:35:32 am »
It's not really cost but the desire to move from the current, very limited solution to a more flexible one, and of course to drive costs down why not look at an integrated solution? Full disclosure: we recently found a supplier for cheap ble remotes, which expose the programming port. We were looking for something like this for a while (for another project) and as luck would have it these remotes use the older nRF521, so i started looking at nordic more closely because i will have to get comfortable with them anyway.

In any case, i program bare metal so i want an ide with an header file that has the register definitions, no platformio bullshit, and the BLE stack.
 

Offline eleguy

  • Regular Contributor
  • *
  • Posts: 55
  • Country: fi
Re: Looking at BLE SOCs, nRF52
« Reply #19 on: November 11, 2023, 07:10:12 am »
We have used different models of ESP32s and nRF52s. I think in our case the answer is pretty simple. If one has to do somewhat light battery product then nRF52 is the answer. We have not used their own development environment but instead done things more hard way and used Zephyr as RTOS.  With the zephyr one can manage low one digit uA levels some what "out of the box". WARNING... learning curve can be visualized as a right angle and  |O .

In general ESP32 beats nRF52 in the most of the "common" specs like mem and speed. However, our favorite nRF52833 has up to 48 GPIOs depending on the package you select. Ok, I need to admit their aQFN73 chip is not the first chip you pick into your practice project. I would recommend starting with the QFN40 model instead and try if a nRF52 fits into your mindset or not.

My first nRF52833 based sensor project did look something like this at the time. Done with kicad and freecad.
« Last Edit: November 11, 2023, 07:11:56 am by eleguy »
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8172
  • Country: fi
Re: Looking at BLE SOCs, nRF52
« Reply #20 on: November 11, 2023, 07:11:12 am »
With regards to the Nordic SDK, is that the old one (which I found fairly easy to use, though I didn't like having my code buried 15 levels deep in the directory tree) or the new one, which is platformio and VS Code, and therefore a horror ?

I guess the "old one"; last time I discussed this the story was that the old one was bad and the new one is great, but you are saying the opposite? (This also demonstrates the problem of committing one's time in manufacturer's software solutions: they abandon this stuff faster than they change underwear, so that the support goes down the drain every few years.)

Could be any stupid mistake of mine why none of the examples worked out of box (including just working with wrong examples), but I don't know, with "hello world" example being a True Software Project consisting of 200 .c files with well over 100kLoC total and consuming the whole flash of the device, what are you expected to do when the logger library, which comes with 10000 lines of configuration of message colors, fails to log? Is one realistically supposed to try to start debugging this stuff? Examples should be "minimum working code", not some architectural masterpieces, but maybe I'm just old-fashioned.

I have written millions of lines of code, most of which is crap, in my life, and I have had zero problems whatsoever integrating stuff like mbedtls in my own codebase, but probably I'm not just competent enough to use Nordic Semi's SDK, you would need a True Software Engineer and not some self-proclaimed embedded greybeard. The point is: if I can't do it, I'm 100% confident many others, especially beginners, cannot either, regardless of fact that some people say they have succeeded.

But I still recommend their products because the hardware is easy to use. I have so far managed doing without BLE stack but I have this good feeling about it that I will find a working non-bloated BLE stack using Google which runs on nRF52 with no or minimum modifications, if and when that need arises. So far I have been working with own custom radio stack which, in some ways, is way superior to BLE LR simply because being custom, it is tailored for the use case without decades of compatibility requirements driving the design.

Seeing that nRF52 implements many of BLE stuff in hardware (well designed, with easy register interfaces!), I'm 99% positive fully working BLE stack should be < 10 .c files, < 2000 LoC, < 10KB of flash. I'm sure someone has done it, and if not, it is actually something I could consider doing if that's the only way.
« Last Edit: November 11, 2023, 07:19:24 am by Siwastaja »
 

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 826
Re: Looking at BLE SOCs, nRF52
« Reply #21 on: November 11, 2023, 09:01:17 pm »
Quote
With regards to the Nordic SDK, is that the old one
In my case, nRF5 SDK, which is the 'old' one. I'm quite sure if I tried nRF Connect, I would be lost and would then echo Siwastaja's comments. Anything with Zephr and I'm going to be lost, and if nRF Connect was the only option I'm quite sure I would have given up.

Quote
I have so far managed doing without BLE stack
So you are using the radio but not doing ble? The nRF SDK has various examples of non-ble radio usage, and is 10x easier than dealing with ble. That would be nice, but in many/most cases the cellphone is the the 'other end', so have to deal with ble however unpleasant. In my case, I just wanted an easy way to view data remotely and the cellphone is probably the simplest way to do this even though it means dealing with ble.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8172
  • Country: fi
Re: Looking at BLE SOCs, nRF52
« Reply #22 on: November 12, 2023, 08:16:33 am »
Quote
I have so far managed doing without BLE stack
So you are using the radio but not doing ble? The nRF SDK has various examples of non-ble radio usage, and is 10x easier than dealing with ble. That would be nice, but in many/most cases the cellphone is the the 'other end', so have to deal with ble however unpleasant. In my case, I just wanted an easy way to view data remotely and the cellphone is probably the simplest way to do this even though it means dealing with ble.

The RADIO peripheral gives you all the low-level BLE long range greatness, offers CRC, address matching etc. in a very simple to use register access package, so all you need to do if you write your own protocol is some sort of interrupt-driven logic which tracks message timing so that it starts RX at correct time (just before expected TX), sets pointers to a packet, enables TX at correct time, maybe tags messages with sequence numbers and request for resends - much of this preferably using the RealTimeCounter peripheral independent of the CPU so that core can sleep. Preferably hop frequencies given some predetermined table. None of this is rocket science but of course it takes time to get right; I found it super helpful to use the GPIOTE to route RADIO EVENTS directly to GPIO transitions (independent of CPU), so that one can see on oscillosscope/logic analyzer when the participants start or stop listening, start transmitting, receive address or packet ends.

As a plus side, you can get better protocol than BLE which is a compromise defined by being somewhat suitable for all workloads. My current implementation is 1200 LoC for master, 800 LoC for slave and includes low-power sleep modes, wakeup-by-radio stuff, running mode, frequency hopping, multi-slave time slicing, timing correction packets, resends, run-time adjustable timing parameters, message FIFOs. Of course, there is not going to be any interoperability with anything else than your own code, which is, depending on case, either a plus or a total showstopper. If you have to interface with Zigbee products, then you can't avoid Zigbee, and if you want to interface with mobile phones, you can't avoid BLE. And using nRF's softdevices, you can't have them both since they are so bloated they won't fit. And actually you can't have BLE either because it's still so bloated you are left with some tens of KB for your whole app, which is just ridiculous. Don't know about the new Zephyr route but probably it's as bloated.
« Last Edit: November 12, 2023, 08:19:22 am by Siwastaja »
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3785
  • Country: de
Re: Looking at BLE SOCs, nRF52
« Reply #23 on: November 12, 2023, 08:42:50 am »
With regards to the Nordic SDK, is that the old one (which I found fairly easy to use, though I didn't like having my code buried 15 levels deep in the directory tree) or the new one, which is platformio and VS Code, and therefore a horror ?

Don't use either, just use Zephyr (which Nordic has replaced their old SDK with, AFAIK) and be done with it. Zephyr has great support for Nordic parts and as long as you don't need some proprietary protocols like ANT or Zigbee (which the Nordic chips also support) you will be fine.

Platformio/VS Code you don't have to use. They only make getting started and debugging easier because setting up something like Zephyr from scratch is both a significant learning curve and takes some time - it is a complex system!

The old SDK was "easy to use" - but also an enormous PITA if anything went wrong and the softdevice (basically a proprietary RTOS blob encapsulating their RF black magic) started to throw errors (and crashes!) at you. Debugging that is "fun". With Zephyr/new SDK based on it you get all the source so if the BLE stack is e.g. refusing authentication for some reason you can figure out why. Also using something like BLE Mesh (not regular BLE!) with the old softdevice based SDK and Zephyr - give me Zephyr any day, despite the extra complexity with having to manage device trees and what not. The API is much saner - which matters when it comes to implementing complex protocols like this.
« Last Edit: November 12, 2023, 08:46:10 am by janoc »
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8172
  • Country: fi
Re: Looking at BLE SOCs, nRF52
« Reply #24 on: November 12, 2023, 08:52:53 am »
the softdevice (basically a proprietary RTOS blob encapsulating their RF black magic)

I did hear these magic words a lot and I simply hate it; there is absolutely nothing RF nor nothing magic in softdevices. All the "RF black magic" is implemented on-chip, as hardware, and nRF guys have clearly done great job at it. All the software has to do is basic MCU firmware stuff like write "send packet" commands on bog standard interrupt handlers, manage device addresses, keys, states. Just like a networking library would manage TCP/IP headers, or a USB implementation would look at interrupt flags and manage data flow between the peripheral and application.

And I'm pretty sure softdevices do not use any kind of RTOS, just normal interrupt driven code, they even list the timers and other peripherals they use so that you can avoid using them in your own code. But of course I could be wrong. In any case, to me these softdevices look like much larger than I would expect them to be, and total lack of simple examples of how to use them is devastating.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf