Getting started with Cortex-M and nRF9160

[ohj]

Hello.

I've been asked to help develop an IoT device where GPS positioning and transmitting status via LTE-M/NB-IoT is central.  So I've landed on the nRF9160 device, which seem to have what I need.  I have some years of experience with Atmel's AVR MCU's, but have no experience with Cortex-M.

I'm considering buying either the Thingy:91 or the Icarus IoT Board to get my feet wet and develop a prototype.  But how is the nRF9160 compared to other Cortex-M MCU's, from e.g. Microchip or NXP?  I see that Nordic Semiconductor have their own SDK.  Will working with nRF9160 then differ from working with e.g. "generic" Cortex-M0 MCU's (if such a term exists), so that I would basically need a devboard from Microchip or NXP to learn Cortex-M MCU's?

I think a bit of my confusion is that my embedded experience is with either Atmel AVR MCU's or Microchip PIC MCU's, which both have their own SDK's and IDE's.  But now with the wondeful invention of ARM Cortex MCU's/CPU's, which is a core that can be embedded into a plethora of different MCU/CPU types from different companies, things seem a bit more unclear. 

I also apologize if this question has been asked before.  I see that there are other "getting started" threads, but they are either quite old (i.e. the advice might be outdated) or doesn't seem to answer what I'm asking (or trying to ask).

[Øyvind]

Hello Øystein, 

It's great to hear that you want to start with our nRF9160 device! 

I have some years of experience with Atmel's AVR MCU's, but have no experience with Cortex-M.

I assume the biggest jump will be moving from a "simple" 8-bit device (assuming you have used AVR 8-bit only) to the Cortex M33, which is Arm architecture used in the nRF9160. 

But how is the nRF9160 compared to other Cortex-M MCU's, from e.g. Microchip or NXP?

 I assume much of Arm Cortex M instructions set will be similar, depending on what Microchip or NXP are using. The big difference will be peripherals.

Will working with nRF9160 then differ from working with e.g. "generic" Cortex-M0 MCU's (if such a term exists), so that I would basically need a devboard from Microchip or NXP to learn Cortex-M MCU's?

 You can't use a devboard from Microchip or NXP to work with nRF9160.

I see that Nordic Semiconductor have their own SDK.

 Yes, Nordic Semiconductor has at the moment two SDK, the nRF5 SDK targeting nRF51 and nRF52, and older devices. While the new nRF Connect SDK (NCS) targets nRF9160, nRF5340 and more advanced features on the nRF52. NCS is needed to work with the nRF9160. I recommend going through our NCS Getting Started Guide and the NCS Tutorial Series. The latter gives you a simple, but good, introduction on how to start with nRF9160.

 

I'm considering buying either the Thingy:91 or the Icarus IoT Board to get my feet wet and develop a prototype.

 The Thingy:91 is a prototyping platform which includes sensors that gather data about its own movements and the surrounding environment. Temperature, humidity, air quality, air pressure, color, and light data can easily be extracted for local or remote analysis. For input, the Nordic Thingy:91 offers a user-programmable button. Visual output is achieved with RGB indicator LEDs, while a buzzer can provide audible output. The standard application firmware on Nordic Thingy:91 extracts the data from the different sensors and relays it securely to the nRF Connect for Cloud, where it is displayed in a user-friendly interface.

But we also have the nRF9160 Development Kit which features all necessary external circuitry like a SIM card holder and an antenna and it provides developers access to all I/O pins and relevant module interfaces. It has more GPIO pins available compared to the Thingy:91, but on the other hand does not have sensors like the Thingy:91. 

Kind regards,
Øyvind

[ohj]

Thank you very much for your reply!

Øyvind said:

But we also have the nRF9160 Development Kit which features all necessary external circuitry like a SIM card holder and an antenna and it provides developers access to all I/O pins and relevant module interfaces. It has more GPIO pins available compared to the Thingy:91, but on the other hand does not have sensors like the Thingy:91. 

Can the nRF9160 DK be battery powered in the same manner as the Thingy:91?  As for the missing sensors on the DK, it would be possible to prototype a solution with sensors using exposed I/O pins, correct?

[Øyvind]

You're welcome. This is what we're here for :)

ohj said:

Can the nRF9160 DK be battery powered in the same manner as the Thingy:91?

 The nRF9160 DK has external power supply pins and the ability to do performance measurement. This way you can power the device using an external battery source.

ohj said:

As for the missing sensors on the DK, it would be possible to prototype a solution with sensors using exposed I/O pins, correct?

 Yes, that is correct. GPIO interfaces are shown here, but be aware that he DK includes a board controller that controls some GPIOs. 

Kind regards,
Øyvind

[ohj]

Thank you.

In the project I'm considering using the nRF9160 for, I'm planning to have master and slave devices.  The master devices will have the LTE-M/NB-IoT modem, while the slave devices will not.  And I want to have local RF communication between the master and slave devices.  The distance between slave and master devices shouldn't be more than perhaps 100 meters or so.  The purpose is to save cost on LTE-M/NB-IoT subscriptions, so that the slave devices can transmit their data through the master devices.

As far as I can tell, the nRF9160 doesn't have an RF interface other than LTE-M/NB-IoT.  Can you suggest an external RF chip that I can connect to the nRF9160, and a second MCU with matching RF interface that I can use on slave devices?  Compatibility-wise it would be good if the second MCU had a Cortex-M core as well, so I can reuse both experience and source code.

[Øyvind]

Hello, 

For questions regarding sales, please contact you local RSM. If you do not know who your local RSM, please send me a PM and I will provide you the contact details. 

Kind regards,
Øyvind