• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 5 replies
  • Subscribers 68 subscribers
  • Views 7280 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 101902
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF51822 vs nRF8001 when having an external MCU

davman

Hi,

Been using nRF51822 before but on this new design I have an external MCU running the main duties. I've been reading up a bit on both but would like to get some thoughts on pros/cons & comparisons between the two options nRF51822 vs. nRF8001.

Thoughts & Questions:

  • How does the stacks compare between the two? I'm thinking recent SoftDevice releases (6.0) vs what I assume is ROM on the nRF8001?

  • Am I right that the flexibility of doing custom things like future central-role will only be possible with the 51822.

  • To avoid having to maintain and flash two code-bases, are there ways (examples) on how to flash the SoftDevice externally? I could maybe implement SWDIO/SWDCLK via the M3, or have a basic boot-loader on the 51822 that fetches this from the main cpu upon boot.

  • Power consumption, both the nRF and my external M3 will have similar sleep current, that said, both in combo will be more than I want.

  • I assume 51822 and 8001 compares 1:1 from a RF-only perspective?
  • What would be the most efficient way to wake/sleep the nRF during BLE-radio operations only?
  • There will be many crystals, both in cost and board-size. If going for 51822, main xtal could possibly be shared.
    • Is the 32.768 needed with nRF8001 to work-around the periodic RC oscillator recalibration?

Please feel free do add tips and comments.

David

Parents
  • 0

    There is no doubt that the nRF51822 is a lot more flexible than the nRF8001. From a BLE perspective, it has primarily 3 benefits, which may or may not be applicable:

    • Higher throughput (6 packets per interval instead of 1).
    • Possibility of being a Central (by replacing a softdevice).
    • Possibility of having multiple bonds.

    However, there is no doubt that it introduces extra complexity, in that you have a second controller to program. There are a serialization example in the SDK, showing how the full softdevice API can be serialized, so this could be an option. A slightly more elegant solution may be to make a higher-level API yourself, tailored to your application, to reduce serial interface traffic and hence power consumption.

    As for flashing, there are an example bootloader in the SDK as well, but it is currently not possible to replace a softdevice with it. For full flexibility, you would therefore most likely have to include a SWD implementation on your main controller, and flash the nRF51 over it. If however you can live with not replacing the softdevice, you can get away with just the UART bootloader. The next softdevice release will also make it possible to do minor revision upgrades using the UART bootloader.

    As for crystals, the only required crystal for both the nRF8001 and the nRF51822 is the high-frequency oscillator (16 MHz for nRF8001 and 16 or 32 MHz for nRF51822). With the nRF8001, it's possible to use the DC/DC (if you don't have a 32 kHz crystal), while on the nRF51822, the DC/DC is currently unfortunately unusable.

    Software-wise, the nRF8001 is a lot simpler than the nRF51822, and can as Soren says be used over an SPI interface. We've recently released the Arduino SDK for it, which should be easy to port to other MCUs if needed.

    Bottom line, if you can live with its limitations, the nRF8001 is a much simpler way of adding BLE to an application. However, if you need the possibilities of the nRF51822, it's perfectly possible to use it in a serialization setup as well.

Reply
  • 0

    There is no doubt that the nRF51822 is a lot more flexible than the nRF8001. From a BLE perspective, it has primarily 3 benefits, which may or may not be applicable:

    • Higher throughput (6 packets per interval instead of 1).
    • Possibility of being a Central (by replacing a softdevice).
    • Possibility of having multiple bonds.

    However, there is no doubt that it introduces extra complexity, in that you have a second controller to program. There are a serialization example in the SDK, showing how the full softdevice API can be serialized, so this could be an option. A slightly more elegant solution may be to make a higher-level API yourself, tailored to your application, to reduce serial interface traffic and hence power consumption.

    As for flashing, there are an example bootloader in the SDK as well, but it is currently not possible to replace a softdevice with it. For full flexibility, you would therefore most likely have to include a SWD implementation on your main controller, and flash the nRF51 over it. If however you can live with not replacing the softdevice, you can get away with just the UART bootloader. The next softdevice release will also make it possible to do minor revision upgrades using the UART bootloader.

    As for crystals, the only required crystal for both the nRF8001 and the nRF51822 is the high-frequency oscillator (16 MHz for nRF8001 and 16 or 32 MHz for nRF51822). With the nRF8001, it's possible to use the DC/DC (if you don't have a 32 kHz crystal), while on the nRF51822, the DC/DC is currently unfortunately unusable.

    Software-wise, the nRF8001 is a lot simpler than the nRF51822, and can as Soren says be used over an SPI interface. We've recently released the Arduino SDK for it, which should be easy to port to other MCUs if needed.

    Bottom line, if you can live with its limitations, the nRF8001 is a much simpler way of adding BLE to an application. However, if you need the possibilities of the nRF51822, it's perfectly possible to use it in a serialization setup as well.

Children
Related