Nordic

Perspectives from a backend engineer learning how to write embedded software specifically on Nordic’s nRF52832.

These are some general things I wish somebody would have told/reminded me …

General:

  • everything is single-threaded
    • the program will be basically:

setup_everything(); while(true) { do_work_if_needed(); sleep(); }

  • everything is interruptable
  • memory!!
    • super constrained environment (16 kb of RAM to work with)
    • buffer overruns are very hard to debug!
      • do not confuse number of bytes with number of elements in a buffer!
  • pay attention to signed vs unsigned types

There are four layers to the stack:

  • ARM Cortex M4
    • this is the embedded processor
    • code at this layer is invoking specific ARM instructions to e.g. configure interrupts
  • nRF52832
    • this is the microcontroller
    • code at this layer is manipulating registers and specific memory addresses defined by Nordic
  • nRF SDK
    • this is a C library written by Nordic to handle writing to registers for you
    • code at this layer is calling library functions which hide some of the complexity of the Nordic stack
  • SoftDevice
    • this is a C library written by Nordic which handles Bluetooth communication
    • code at this layer is also calling library functions but in a way that is “safe” in the Bluetooth-enabled stack

Some meta-tricks to make this more effective:

  • download all of the manuals so you have access offline
    • The Nordic website goes down for maintenance suprisingly often which can be really inconvenient
  • similarly, download all the datasheets for hardware that you’ll attach to the board

Ok, first some basics:

  • In the SDK, each functionality is offered by a specific “peripheral”

SPI vs TWI PPI

power measurement

debugging reset NRF_LOG_INFO float issues

Name:

Comment: