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.
Home
Help
Search
Login
Register
