Categories

[Little Brosers] Narrowing the components list and pushing my first commit !

SoC final choice

After more digging into SDK features, we finally chose the NRF52832 from Nordic as our SoC thanks to Nordic’s great SDK.

Why this choice ? I’m glad you asked!

Comparing NXP, Cypress and Nordic SDKs, I came to the conclusion that our development process would be simplified the most using Nordic’s SDK. Not only the C libraries from Nordic such as the nRF5 SDK v14.1.0 are impressively well documented but we will also be helped by the Nordic Android BLE SDK and user guide for the mobile app we plan to develop.

Other tools may be considered. For example, Nordic provide the Power Profiler Kit allowing developers to estimate the current consumption of the SoC during our code execution from 1µA to 70mA with a resolution of 0.2µA.

Also, Nordic’s SoC come with OTA firmware update feature. Allowing us to easily setup the firmware update process though BLE.

Choosing the Flash memory

We had less specific needs for the flash memory.

To estimate the needed size, I used the following values:

  • A message with payload +  Little Brosers’s overhead should take less than 400 bytes
  • A drop should be able to store around 9000 messages
  • A worst case scenario 4-ary Merkle tree with this configuration should have a size of 300kB with 128 bits long hashs
  • The total of those estimation gave us a size of around 4MB

Of course those estimations are not precise but 9000 messages is quite a big number and we’ll allow us to store less messages on a drop if needed.

I also knew that a easy to solder package like SOIC-8 would be way more convenient during the soldering process of our PCBs.

In the end I had 5 flash models packaged in a SOIC-8 with similar features and I selected one of average price, well balanced set of feature and allowing several power modes to adapt its consumption. This is the AT45DB321E from Adesto Technologies.

Pushing my first commit

Indeed, for the drops firmware we plan to separate the C source code supposed to be used in the drops and the C++ source code only executed one our PCs to perform quick simulations. This structure should allow us to develop the hardware independent C code for the drops and test it using C++ ease of use. Those simulations will allow us to perform Merkle tree merges without the whole BLE communication process. We will emulate it with C++ objects.

So, i spoke about my first commit… and what a commit !

Indeed, we decided to start from a Nordic’s SDK’s example four our Makefile structure. Thus, I had to put the whole Nordic SDK in the repository (~120MB).

In the following weeks, I’ll work on editing the Nordic’s Makefile to include our C++ simulation environnement.

Eventually, we would like to have a Makefile from which we could run the following kind of targets:

  • make sim : build a x86 binary including hardware independent C code and the C++ simulation code
  • make devkit : build an ARM binary for the NRF52 DevKit including hardware independent C code, SDK and DevKit specific code
  • make firmware : build an ARM binary for the drops including hardware independent C code, BLE code, SDK and Drops specific code
  • make clean : well… clean the project
  • make flashdv : flash the DevKit with its dedicated binary
  • make flashd : flash a Drop with its dedicated binary

See you next week !!

Antony Lopez

Antony Lopez

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>