Originally I had an idea to develop an Arduino-compatible project using an ATmega328P, some sensors and the nRF51822 as the BLE radio. As I progressed, I realized that if I relaxed the Arduino-compatible requirement, I could actually do away with the ATmega328P and write the application directly on the nRF51822 as it is a more capable MCU (32-bit, more memory, faster, has SPI, I2C and TTL serial, etc.) I'm not familiar with writing native applications for the nRF51822 but it seems much more complicated.

For someone that has experience in both platforms, can you please list some of the tradeoffs of developing using an ATmega328P for application + nRF51822 for radio and using the nRF51822 for both application and radio?

  • This sometimes even bothers me. That moment you realize that the "slave ethernet module" is running Linux on an 88Mhz x86 CPU with 256kb sram. And that you realize that your tiny MCU is the master (and 10x cheaper). – Paul Mar 15 '16 at 17:28

First, there are various ports of the Arduino environment to the NRF51822, but I'll leave that aside for the moment and address using Nordic's codebase or the mbed one.

Generally speaking, one of these paths will put you more in the current "real world" of professional level embedded development, in which the ARM cortex parts play a leading role. You will have conventional multiple source file projects tied together by more ordinary means such as a Makefile or explicit IDE configuration, rather than the rather oddball way the Arduino IDE has evolved to do things. The basic lower level APIs you will be writing against will be much more conventional - ie, your code will start in main() rather than setup() and loop(), you will generate debug messages with printf() or similarly styled member function on mbed, rather than Arduino type print()/println() (though of course you can use printf() on an Arduino with some setup). This tends to make it a lot easier to port or share code between this and other embedded systems, or even between an embedded system and a phone or desktop communicating with or simulating it. Of course you can treat an Arduino as a plain ATmega and do this with that as well, up to the limits of the CPU and its memories.

People tend to think of the mbed option as being an online "toy" for certain boards, but you can generally use others just by setting it for a board using the same MCU in a similar way. And in most cases you can download a zipfile of a project with a Makefile in it that will drive arm-gcc or a few other compiler choices. The NRF51822 does come in varieties with different onboard storage sizes, and this can sometimes require care and attention to the linker script - in a few cases a project that fits in the online build (apparently with the Keil compilation engine as its backed) will not build in the downloaded GCC configuration unless you adjust the linker script to reduce the stack size, or perhaps change compiler optimization levels.

Countering reasons you might end up keeping the ATmega would be if you need some of its I/O peripherals or its 5v I/O capability. For example, the NRF51822 has limited hardware PWM capability compared to an ATmega so that must generally be done in software.

If you are really at home with "The Arduino Way" switching to anything more traditional may take some adjustment of thinking and habits. On the other had, if you look at the benefits of Arduino being the variety of works-out-of-the-box, easily modified examples you can use to explore the possibility of a project, but often find yourself annoyed by the legacy of its countless quirks and atypical approaches in the longer run, then you'll probably find the adaptation to using the NRF51822 directly to have been worthwhile.

  • Thank you. In my application I'd like to attach at least a GPS, an IMU, a microSD adapter and perhaps temperature/barometric sensors. These take up all the UART, I2C and SPI interfaces. No need for PWM. Would this be a reasonable way to go to remove the need for an extra IC at the cost of more complicated development? – Ana Mar 15 '16 at 16:15
  • That seems like it should work, yes. Much of your challenge will be in figuring out organized code to service the peripherals, and in how this integrates with the BLE or whatever other use you are making of the radio. – Chris Stratton Mar 15 '16 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.