Werner Almesberger
2016-01-23 03:24:30 UTC
A while ago I discussed the Anelok design with Bluetooth hacker Mike
Ryan, and he strongly recommended using the Nordic nRF51822 instead
of the the TI CC2543.
The idea for the TI CC2543 is to write the lower layers of an open
BTLE stack from scratch, and at some point mix this with the upper
layers from BlueZ.
The main benefit of this approach is that it's 100% open. The main
drawback is that it's a lot of work, especially given that the
hardware doesn't quite support the BTLE frame format, and thus would
require some creative software tweaks.
After looking (again [1]) at the nRF51822 documentation, I'm now
reasonably confident that one could write an all-Free stack also for
this chip. But it has the added benefit that Nordic provide a
(closed) stack as well, which should help to keep the development
time for a first working prototype down.
Another feature that may become important given recent regulatory
trends is that the nRF51822 (like the Kinetis MCUs) can be protected
against unauthorized Flash modification. I.e., one could write a
boot loader that only accepts signed binaries. The CC2543, on the
other hand, can always be fully erased and then accepts any new
firmware.
Further advantages of the nRF51822 include that it's a Cortex M0
(so we don't need SDCC for the ancient 8051 core of the CC2543) and
that it has enough Flash and RAM for the entire BTLE stack. That may
end up weakening the role of the cMCU, but I think any possible
optimizations there can wait until later.
I haven't put too much work into the CC2543 so far, so the time lost
by switching RF chips again wouldn't be excessive. Of course, such a
change will still obsolete all the RF sections of the 2014/Mk2/CR2032
boards made so far.
[1] http://lists.en.qi-hardware.com/pipermail/discussion/2014-April/010574.html
Opinions ?
- Werner
Ryan, and he strongly recommended using the Nordic nRF51822 instead
of the the TI CC2543.
The idea for the TI CC2543 is to write the lower layers of an open
BTLE stack from scratch, and at some point mix this with the upper
layers from BlueZ.
The main benefit of this approach is that it's 100% open. The main
drawback is that it's a lot of work, especially given that the
hardware doesn't quite support the BTLE frame format, and thus would
require some creative software tweaks.
After looking (again [1]) at the nRF51822 documentation, I'm now
reasonably confident that one could write an all-Free stack also for
this chip. But it has the added benefit that Nordic provide a
(closed) stack as well, which should help to keep the development
time for a first working prototype down.
Another feature that may become important given recent regulatory
trends is that the nRF51822 (like the Kinetis MCUs) can be protected
against unauthorized Flash modification. I.e., one could write a
boot loader that only accepts signed binaries. The CC2543, on the
other hand, can always be fully erased and then accepts any new
firmware.
Further advantages of the nRF51822 include that it's a Cortex M0
(so we don't need SDCC for the ancient 8051 core of the CC2543) and
that it has enough Flash and RAM for the entire BTLE stack. That may
end up weakening the role of the cMCU, but I think any possible
optimizations there can wait until later.
I haven't put too much work into the CC2543 so far, so the time lost
by switching RF chips again wouldn't be excessive. Of course, such a
change will still obsolete all the RF sections of the 2014/Mk2/CR2032
boards made so far.
[1] http://lists.en.qi-hardware.com/pipermail/discussion/2014-April/010574.html
Opinions ?
- Werner