Arm Education: Internet of Things Course - Review

Table of contents

RoadTest: Arm Education: Internet of Things Course

Author: ytan

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: n/a

What were the biggest problems encountered?: Majority of the time spent of troubleshooting issues related to the tools (undocumented gotchas and license issues), which would have been better invested in learning the content.

Detailed Review:

I am a software/electronics freelancer, working with small/medium sized businesses to develop prototypes and end products. Most of my projects rely on off-the-shelf boards (Arduino Uno, Mega, Due, ESP32, etc.) and I leverage heavily on the Arduino platform/libraries. Arm Education: Internet of Things Course appealed to me, because I was hoping to expand my knowledge in the growing IoT industry. I have completed ARM Accredited Engineer (AAE) program some years back, which i enjoyed immensely. Naturally, I was stoked to find myself chosen to be a Road Test participant, and couldn't wait to get started with another Arm course.

Image: I am disappointed to say that the robot on the front page is not related to the course at all.

 

Boards I have received

The course materials were far from ready when I received my package from e14, but I can't wait to unbox and inspect them. From left to right, they are as follows:

  • Nucleo F401RE (STM32 Nucleo-64 dev board 84 MHz STM32F401RE MCU, 512 KB flash, 96 KB SRAM with Arduino pin compatibility)
  • X-NUCLEO-IKS01A2 (Motion MEMS and environmental sensor expansion board for STM32 Nucleo)
  • X-NUCLEO-IDB05A1 (Bluetooth Low Energy expansion board based on SPBTLE-RF module for STM32 Nucleo)

Image: Nucleo and the two expansion boards

 

Nucleo F401RE - Dev board

For a slightly aged board, Nucleo F401RE still packs quite a bit of grunt. Packing a Cortex-M4F (STM32F401RE MCU), the Nucleo F401RE is comparable to the Arduino Due, sharing the same amount of flash and SRAM - each packed full of MCU peripheral goodies. Nucleo F401RE takes the upper hand when it comes to geometric or signal filtering applications, as the Cortex-M4F comes with a separate floating point unit (FPU).

 

X-NUCLEO-IKS01A2 - Sensor expansion

The X-NUCLEO-IKS01A2 carries on board a combination of sensors:

  • LSM6DSL MEMS 3D accelerometer (±2/±4/±8/±16 g) and 3D gyroscope (±125/±245/±500/±1000/±2000 dps)
  • LSM303AGR MEMS 3D accelerometer (±2/±4/±8/±16 g) and MEMS3D magnetometer (±50 gauss)
  • LPS22HB MEMS pressure sensor, 260-1260 hPa absolute digital output barometer
  • HTS221: capacitive digital relative humidity and temperature

 

X-NUCLEO-IDB05A1 - Bluetooth expansion

The X-NUCLEO-IDB05A1 has a BLE4.2 compliant BlueNRG-MS RF module which supports connectivity through Bluetooth Low Energy.

 

Course Materials

The course is divided into twelve modules. Each of the modules consists of lecture video, trivia quiz and/or lab exercise.

 

  • Module 1: Introduction to IoT
  • Module 2: Embedded System
  • Module 3: The Arm Cortex-M4 Processor Architecture: Part 1
  • Module 4: The Arm Cortex-M4 Processor Architecture: Part 2
  • Module 5: Interrupts and Low Power Features
  • Module 6: CMSIS and mbed
  • Module 7: Arm7A
  • Module 8: Arm Cortex-A9 Processor
  • Module 9: Introduction to Bluetooth Low Energy
  • Module 10: Bluetooth Smart Heart Rate Sensor App
  • Module 11: Networks and Connecting Things to the Cloud
  • Module 12: Weather Station

 

Most of these modules contain a lecture video, slides with the video transcript, a quiz and a lab exercise. On average, I take up about 3-4 hours per module. However, there were some gotchas along the way that ended up with me spending hours trying to troubleshoot; some successful, others I deem not worthy of my time. In the rest of this section, I will highlight some of my thoughts and reflections as I plough through the course materials.

 

Without further ado, let's begin!

 

Module 1-2

First two modules are mostly introductory information to the general audience, filling me in on the big picture of the IoT industry, and the recent advancements in technology (radio communication, embedded systems and big data) which have enabled its growth into ubiquity. Needless to say, emphasis was placed on the role of MCUs in enabling IoT development. Maybe it's just me getting accustomed to the hyper-engaging lectures from Youtube(EEVblog, Andreas Spiess, etc.) and Coursera (NAND2Tetris, anyone?), the materials presented here seemed dry and uninspiring. I suppose this is not uncommon for a professional course, but come on - are we really talking about the rise of a new class of smart internet-devices here? Okay, that's probably just me nitpicking.

 

At the end of each module, a quiz is given to test if you have been paying rapt attention. Not a simple task, mind you. Luckily, the questions seem general enough for entry-level IoT developers. Also, getting the answer wrong seem to bear no significant consequence on subsequent modules.

Image: The answer should have been Skynet...

 

 

Image: So many Arm processors inside one device!

 

Module 3-5: Now we're really getting into the real stuff

Here the Cortex-M processor is introduced, and we learn how chip vendors work with Arm to integrate Cortex-M processors into MCUs. Some of the lower level architecture is explained here. I got to learn about processor registers (R0-12, SP, LR, xPSR) and how they are used. We also looked at memory map and bit-band operation which allows SRAM memory manipulation in an atomic operation instead of the regular read-modify-write operation. Module 5 goes over interrupt concepts in a Cortex-M. Topics on entering and exiting exceptions are highlighted. Other topics such as stack restoration, timing analysis, data sharing are also covered here.

 

The contents delivered here seem to be a highly abridged version of the ARMv7-M Architecture Reference Manual. Some of the lecture topics were hard to grasp, and I wasn't able to do as well in the quiz. I think it wold be very helpful if the quiz provides some explanation, or a reference to a lecture slide when I answer incorrectly.

Image: When I am wrong, all I know is that I'm wrong.

 

 

Lab modules: The more practical stuff

 

Finding the lab resources can be a daunting challenge if you are new to VitalSource's user interface. However, this is a necessary trial that every course participant will have to undertake. Failing of which, one cannot proceed with the lab modules any further.

 

Once found, it should be relatively simple. The downloaded lab modules were neatly organised according their respective modules. Follow the instructions on the "Getting Started" document to install Keil uVision, and you're good to go... well sort of. Some of the information and links in the document are outdated, so you'll need to make adjustments as you go. The lab projects are as follows:

Lab 3: Square Root Approximation (Using Bisection method)

Lab 4: Digital Input/Output and GPIO (Press a button and see an LED light up)

Lab 5: Interrupt and Low Power Features (Same as 4, but now the MCU waits for pin interrupt in a low power mode)

 

 

Not much to say about the labs, as they are incredibly simple. All the boiler plate codes are written, so it's only a matter of filling up the missing codes. I can appreciate that, as it means more time devoted to the exercise problem itself. I find these lab modules useful for getting me up to speed with the debugging tool of the IDE (Integrated Development Interface) and also the CMSIS library that can be leveraged in application development. I enjoyed working with the assembly code implementation in Lab 3, as seeing it work helped validate my understanding of the Cortex-M registers.

 

 

Image: I'm sure the link to the "Getting Started" document is nearby... but where?

Image: Lab 3: Insert missing code

Image: Lab 3: I wrote assembly!

 

 

Death by PowerPoint: Let's have a moment of silence for those of us who have fallen due to poor presentation.

After going through the slides and listening to the instructor religiously reading every word from the script, I realised that my enthusiasm for the lecture videos have all but receded. If the instructor was in any way interested in what he was talking about, he did a great job of not showing it. The presentation slides didn't help either, as most of the contents seem to be directly pasted from the documentation. This can be useful if course participants could raise questions to the instructor, but we can't.

 

Look, I get it. The Cortex-M4 architecture is an extensive topic, so it's hard to do justice by putting them into slides. Also, this course is probably meant for hardcore seasoned embedded engineers who already know half the things that are covered in this course. Said professional engineers probably have enough passion on their own to compensate for the course's lack of passion.

 

But that shouldn't excuse the poor design of the slides. Slides are useful for visualisation of ideas, not data dumps. If there's too much information to be conveyed, I personally prefer to be given a reading lists than to be subjected to a monotonous lecture video. Or at least, give us a button to control the speed of the video.

 

As per the title: I would like to take a moment here to reflect on the high "attention death toll" caused by poor PowerPoint presentations.

Image: Presentation of information-dense slide

 

Image: One way of a making a more engaging presentation is to break information into multiple slides, and colours. Use colours!

 

Module 6: CMSIS and mbed (actually more on mbed)

We look into CMSIS (Cortex Microcontroller Software Interface Standard) and mbed. CMSIS provided a standardised hardware abstraction layer to the Cortex-M processors and debugging interfaces. The benefit of relying on CMSIS, is that it is vendor-independent (portable) and optimised (small code and memory footprint). mbed is a platformful of goodies which includes:

  • open software libraries
  • open hardware design
  • open online tools

Image: Fixed that for you. You're welcome.

 

mbed seems to be a whole beast of its own, but the course mainly looks at mbed SDK library and the online IDE. mbed SDK library is built on top of CMSIS, and provided a lot of code examples to help a developer get started. The code is licensed under Apache 2.0, and supports a wide range of dev boards out there. It implements C++ object oriented API, so Arduino users will feel right at home with it.

 

For comparison, here is code using mbed. The GPIO is used for LED output and interrupt trigger, while the Timer is used to trigger an event (toggle LED) at .5 sec intervals (wrapped by the class Ticker):

 

#include "mbed.h"
// Create a DigitalOut objects for the LED
DigitalOut LED(LED1);
// Create an InterruptIn object for the button. 
InterruptIn  BUTTON (USER_BUTTON);
// Create a Ticker object for a recurring interruption.
Ticker blinky;
bool active = false;
//Button handler
void BUTTON_ISR(){
  active = !active;
}

//Recurrent handler
void BLINKY_ISR(){
  if (active) LED =!LED;
  else LED = 0;
}

int main() {
  // Set up
  BUTTON.mode(PullUp);
  BUTTON.fall(&BUTTON_ISR);
  blinky.attach(&BLINKY_ISR, 0.5);
  while(1){
    __wfi(); //Wait for interruptions
  }
}

 

and here is just the code needed just for LED manipulation using port registers. (I'm not even going to show the full code, because it's much longer):

 

#include "leds.h"
#include "stm32f4xx.h"

void init_led(void){
//Enable IO port A 
//Set the pin to output mode, push-pull output state, pull-up mode and fast speed.
RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN;
// 01: output general purpose
GPIOA->MODER |= GPIO_MODER_MODER5_0;
GPIOA->MODER &= ~GPIO_MODER_MODER5_1;
// 0: output push-pull
GPIOA->OTYPER &= ~GPIO_OTYPER_OT_5;
// 01: pullup
GPIOA->PUPDR |= GPIO_PUPDR_PUPDR5_0;
GPIOA->PUPDR &= ~GPIO_PUPDR_PUPDR5_1;
// 10: fast speed
GPIOA->OSPEEDR &= ~GPIO_OSPEEDER_OSPEEDR5_0;
GPIOA->OSPEEDR |= GPIO_OSPEEDER_OSPEEDR5_1;
}

// Set output pin PA_5 to high
void led_on(void) {
  GPIOA->BSRRL |= GPIO_BSRR_BR_5;
}

// Set output pin PA_5 to low
void led_off(void) {
  GPIOA->BSRRH |= GPIO_BSRR_BR_5;
}

//Toggle the LED state
void toggle(void){
  GPIOA->ODR ^= GPIO_ODR_ODR_5;
}

 

The online IDE allows sharing of code with the community. Also, there are many getting started examples ready to compiled and downloaded to our dev board. All I need to do is to load an example project into my workspace, build and download the binary (*.bin) file. This file can then be dragged and dropped into the flash storage of the board. The other benefit of the IDE is that you can export the projects into other IDEs: Keil uVision, IAR, EmBitz, Sw4STM32 and other project formats. This is exactly what I did in Lab 6: Programming Using mbed API.

 

This means that I can load an example project that is already working, and then import that to my IDE and develop from there. Although I must add that the projects may require some further settings before they can work in the IDE of my choosing. In any case, it's fair to say that mbed SDK and online IDE speeds up to prototyping development significantly.

 

 

Module 7-8: ArmV7-A/R and Cortex-A9

Here is where we look deeper into assembly programming, specifically with respect to ArmV7-A. ArmV7 is the current ISA (Instruction Set Architecture) used in ARM processors, divided into three profiles:

  • ArmV7-A (application / performance) - Supports ARM and Thumb instruction sets, requiring virtual address support
  • ArmV7-R (real time / safety-critical) - Supports ARM and Thumb instruction sets, and requiring physical address support
  • ArmV7-M (microcontroller / low cost) - Supports Thumb instruction set

 

ARM instruction set (for ArmV7-A/R) is almost identical to Thumb instruction set in terms of functionality. While ARM instruction set designed for 32bit architecture, Thumb has its roots in 16-bit architectures. However, the current version (Thumb-2) supports both 16-bit and 32-bit instructions, which can sometimes be more efficient than ARM. Both instruction sets have their own quirks, and it is possible to switch from one set of instructions to another efficiently.

 

Although Module 7 was talking about assembly instructions, the quiz threw very specific questions on the Cortex-A processor architecture. I would have expected some questions related to assembly instructions, but none at all. Are the quiz questions prepared by a different person? In any case, I'm ashamed to say that I didn't do very well at the quiz.

 

Image: Devil is in the details.

 

Module 8 covers the Cortex-A9 Processor architecture: Pipeline, multi-core processing, virtual registers, memory system, etc. Throughout the video, I kept wondering if these information is related to the lab exercises at all. I must say that after Module 8, I feel better equipped to answer the quiz back in the previous module. Maybe there was a mix-up some where. Below are some slides to give you an idea of what I was staring at.

Image: Module 8 Slide 4

Image: Module 8 Slide 7

Image: Module 8 Slide 13

 

Lab 8: Migrating DS-5 projects to Arm Development Studio

We return to assembly programming in Lab 8, this time debugging an emulated Cortex-A9 processor using Arm Development Studio. No coding exercise here, just importing an existing project so that I can step through the disassembly. I hit an obstacle here as I wasn't unable to connect to the emulated processor. I did not foresee this gotcha, having followed every step along the way. I thought this might have been caused by a missing emulator on my system, as mentioned on Stackoverflow. I promptly went to sign up for an evaluation on Arm Fixed Virtual Platforms, which did me no good at all.

 

After raising this with other fellow road testers, I am told to switch to a different core, and it somehow worked, albeit with the warning: ARM Core Model: WARNING - Simulation code-translation cache failed to gain DMI for PC=0x00000004. Simulation performance will be reduced. It seemed to stopped working again at the time of writing this article - presumably because my evaluation period is over? I don't know. For all intents of the lab exercise, I was able to step through the instructions and see what happens to the registers during a function call (register use during argument passing, stack pointer, link register, etc.) So I'm more than happy to move to the next module.

 

In retrospect, I can see the value in this lab exercise, but unfortunately the time I have wasted troubleshooting has left me with an unsavory impression.

 

Image: Failed to run

Image: Successfully running. But I don't know why.

 

 

Module 9: Introducing Android!

From the low level assembly programming of Module 9, I am launched into the embrace of high level app programming. Here I am introduced to smartphones and Android OS. Some of the concepts are mentioned:

  • Concepts of App components (Activities, services, Broadcast Receivers and Content Providers)
  • App Lifecycle (Created, Started, Resume, Paused, Stopped and Destroyed)
  • Intent (Filters, Implicit and Explicit intents)
  • Manifest File

 

Am I the only one thinking a 10-slide introduction to Android app development is inadequate?

Image: Component cost breakdown of a smartphone

 

 

Lab 9: Designing a Basic Mobile Appcessory “Hello World!”

This exercise demonstrates how to create a basic app. Can't say much here, except that the demo was build on Android Studio 1.1.0. I have Android Studio 3.4.2 on my machine, and I wasn't able to run it. Basically the problem comes down to this message: "Gradle sync failed: Could not find com.android.tools.build:gradle:1.3.0." Changing it to '3.4.2' gave me this: "Gradle sync failed: Could not find com.android.tools.build:gradle:3.4.2." I have experience with Android app development, so I chalked it up to dodgy project files and moved on. I guess I won't be doing "Hello World" after all.

 

Image: Gradle sync failed: Could not find com.android.tools.build:gradle:1.3.0.

Image: Gradle sync failed: Could not find com.android.tools.build:gradle:3.4.2.

 

Module 10-11: BLE and IoT

It wasn't easy, but I managed to soldier on. Module 10 gave me some reprieve, as it diverts attention away from my failed Lab 9 exercise. Here I learn about Bluetooth in general, then the BLE (Bluetooth Low Energy) stack - in particular the two modes:

GAP (Generic Access Profile) - for broadcasting and connecting

GATT (Generic Attribute Profile) - specification of read/write attribute values within a characteristic, which is grouped under services

 

The hierarchy of a GATT for a BLE device looks something like this:

Device (Server)
|- Service1
| |- Characteristic1a
| | |- Descriptor
| | |- Value
| |- Characteristic2b
| |- Descriptor
| |- Value
|
|- Service2
| |- Characteristic2a
| | |- Descriptor
| | |- Value

 

Image: The first thing to know about BLE is the Cortex-M4 memory map

Image: GATT Profile

 

Module 11 was a big picture view of Networking and IoT infrastructure. It covers general concepts of IPv4/6, network topology and protocols, cloud computing and service models (SaaS, PaaS, IaaS).

 

Lab 10: Bluetooth Smart Heart Rate Sensor App

This exercise builds an Android app which connects to a BLE Heart Rate Sensor. Remember the dodgy outdated project files I've encountered in Lab 9? Turns out I wasn't able to import this project either. I'll spare you to hours of frustrations that i have to go through, installing and uninstalling tools, modifying gradle project files settings, and lots of superstitious exiting and re-starting Android Studio. Moving on.

 

Image: No luck here.

 

Lab 11 Part1: Sensor shield

Finally! Back to the comfort of Keil uVision. Remember the expansion boards that I have mentioned at the beginning of this article? We finally get to use them.

 

The first part of the lab involves writing code to read sensor values from the sensor shield via I2C bus, and sending the data through the serial port. The board used in this course is X-NUCLEO-IKS01A1, but I was supplied with the X-NUCLEO-IKS01A2 board. The sensors are slightly different on this board, but we only needed readings from HTS221 which is available on both boards, and the LPS25H which is replaced with LPS22HB. Based on their datasheets, the read command should be similar, so it shouldn't be a problem.

Image: This is not the board that I am provided with.

 

The drivers to communicate with both sensors are already provided, so this is a pretty easy exercise. As luck would have it - I was able to build and flash the the dev board without any hiccups. However, when I turn on my Serial Terminal I noticed that the pressure reading was 0.00Pa. My dev board wasn't reading from LPS22HB.

 

Image: No pressure at all.

 

I checked the jumpers on the expansion board, and later tried an example project from mbed, and it worked without a problem.

Image: mbed project for X-NUCLEO-IKS01A2 works fine.

 

So clearly the culprit lies in the driver source code. Despite being initialised properly, the program deemed the sensor unavailable due to a device ID check.

    // code snippet from void LPS25H::Init()
    if (ret == 0)
    {
      if(ReadID() == I_AM_LPS25H)
      {
          Lps25hInitialized = 1;
          //ret = HUM_TEMP_OK;
      }
    }

 

In the datasheet, the device ID values are as follows:

Image: ID for LPS22HB

Image: ID for LPS25H

 

Changing the ID define solved the problem.

/**
 * @brief Device Identifier. Default value of the WHO_AM_I register.
 */
#define I_AM_LPS25H                 ((uint8_t)0xB1) // this is a quick hack for LPS22HB
//#define I_AM_LPS25H                 ((uint8_t)0xBD)

 

Image: A simple hack, but it works.

 

Lab 11 Part2: BLE program

In this exercise I get to create a fake BLE Heart Rate sensor that can be read by an Android app. Except that I didn't. The compiled program exceeded the code size for my evaluation IDE: "Nucleo_BLE_HeartRate.axf: error: L6050U: The code size of this image (47980 bytes) exceeds the maximum allowed for this version of the linker." I tried other IDEs like Sw4STM32, Attolic Trustudio, and STM32CubeIDE - none of them could import the project successfully. I also raised this issue with other participants - some suggested I request for a temporary license from Keil, by then I have decided that too much time has been spent trying to make this work.

 

I gave up.

Image: This here, is where my heart sank.

 

 

Module 12: Weather Station

This module consists of a lab exercise to build a mock-weather station and an Android BLE app. I don't have much to say here, except that I couldn't get it to work.

 

 

Thoughts on this course

This is my first time doing a road test review, and I really wanted to say good things about this course, but I can't. As I progress from Module 1 to 12, I find myself becoming increasingly frustrated. Instead of learning new things, I find myself spending more time troubleshooting and wrestling with software licensing. I am sure that this course could have been better executed. In this section, I'd like to point out the difficulties that I have when undertaking this course.

 

Delivery Platform

I tried to adapt to the VitalSource user interface, but it is just poorly suited as the delivery platform for this course. Here is my observation:

1) Layout:

When going through the lecture, I find myself choosing between watching the video or reading the transcript of each slides. If I want to see the video in full screen, I'll have to forgo the transcript. If I want the transcript, I'll have to minimise the video. This is the weirdest layout I have ever seen in an e-learning platform.

Image: This is what a regular lecture looks like.

 

2) Video playback:

There seems to be a caching issue with the video playback, as it reloads when I navigate to a different part of the video. Sometimes I need to go back a few minutes earlier in the video, or move the video ahead. Other times, I might pause and resume later. In any case, I would find my pace disrupted waiting for the reloads. Also, there is no playback speed setting, so I can't change the pace of the video lecture.

 

3) User interface:

To drive home the fact that this is the weirdest e-learning platform:

  • The only way to move to the next slide is to first minimise the current slide. Go figure.
  • The arrow keys left/right sends the browser off to load the previous/next module. When I return to my original page, I have to wait and reload the video again. Here's an idea: why not bind the arrow keys for navigating the slides, or the video. Or both.

 

4) Slow website:

The website is just sluggish overall. To give you some metrics, here is a comparison of VitalSource and Udemy (another education platform):

Image: This is the front page on VitalSource.

Image: This is Udemy.

 

Image: This is what Google PageSpeed Insights has to say about VitalSource.

Image: This is what Google PageSpeed Insights has to say about Udemy.

 

Maybe it's just my experience with other course platforms like Udemy and Coursera - but the interface here is really lacking, and reminiscent of web interfaces from ten years ago. The interface seems to obstruct and hinder my learning experience at every step of the way. I can't help but feel that the course materials were developed with another delivery platform in mind - it just happened to be retrofitted to VitalSource Bookshelf, and it wasn't executed properly.

 

 

Course Design

As for the course design, here's what I have observed:

1) Uninspired presentation:

PowerPoint presentation used as a means to dump text-heavy information on students. Frankly speaking, much of the material felt to me as if I were a sales stuff learning cheat sheets of Arm products. I am of the opinion that some information should be left for the students to read on their own. Going through information-packed slides for hours and hours inevitable overwhelms students and leads to the death of attention. Also, the slide designs are reminiscent of 90s PowerPoint slides (sans awkward animation/transitions).

 

2) Overambitious Scope:

It is not easy to design a course which covers a broad topic such as IoT. Although providing students with a holistic view of technology is desirable, cramming every bit of detail into the lectures will only overwhelm the students. I am not new to working with Android app development and also with BLE (ESP32), and even then I can't relate to much of the lecture materials. Sure, SIMD can do arithmetic with multiple data in a single clock cycle... but what am I going to do with this information? It's not like I am taking this course so that I can write white papers on Cortex-A9. Therefore I recommend that the course focus on enabling skill sets so that its students can work with IoT technology. The rest of the information can be left in a readings list for further self-study.

 

3) Underwhelming lab exercises:

The lab exercises demonstrate too little of what was presented in the lectures, and I believe so much more can be done here. Instead of having one single lab at the end of the lecture (by then most of the lecture material is forgotten), how about embedding demos throughout the lecture? This way students can learn something from the lecture and also see it applied in practice.

 

4) Lab software license:

Lab exercises that cannot be completed because its code has exceeded the size limit has no educational merit. How about including trial licenses for the course participants? Alternatively, how about a free IDE? STM32 Cube IDE seems like a good candidate.

 

5) Gotchas and outdated project files:

The gotchas that I have faced in this course really rained spanners in my learning process. Too much of my time was wasted second-guessing if I have missed an instruction earlier or if it's just an error in the instructions. Then send me off on a wild goose chase, trying to fix the problems on my own. To be fair, some gotchas are bound to be discovered in a "new" course, but I do hope they get resolved for the future students. As for outdated project files, they should be checked to be working well with the latest software, or at least provide the software version, so that the students can better troubleshoot any problems that arise. No sense in providing outdated projects which are no longer supported by current versions.

 

6) Support:

Students should not be left on their own to troubleshoot the exercises. That's a responsibility of the course provider. It's a shame that we aren't able to interact with the Instructor and/or other course participants. This is very useful as it provides feedback on how effective a course is, and highlights parts of the course that the instructor may have overlooked. An FAQ or a discussion forum can be implemented so that challenges/solutions of earlier students can be known.

 

Verdict: Broken hopes and promises

Arm Education: Internet of Things Course is an ambitious endeavour to introduce the world of IoT from the lowest levels to the highest level, covering on ARM processors for MCUs and for smartphone processors, Android programming, Bluetooth Low Energy and a sprinkling of networking fundamentals. ARM attempts to synthesise the core knowledge and present everything within a coherent framework.To that end, I like to think that they have succeeded to a certain extent.

 

However, it is difficult to overlook the obstacles and hoops that I have to jump through. I can imagine less painful (or dare I say fun?) ways of gaining the same knowledge and skill set. The course materials seem like an amalgamation of existing course materials, haphazardly put together (like a Frankenstein's monster.) The "Internet" part of the "Internet of things" seem to take up only 1 out of the 12 modules, seemingly an obligatory set of slides added as an afterthought. For an "Internet-of-Things" course, Internet wasn't even used in the lab exercises.

 

I know I'm writing what amounts to a scathing review - but I do strongly feel that this course has the potential to be so much more. I won't even pretend that I'm not upset. Over the course of my career I have given and designed professional training courses to commercial and academic audiences, so I like to think that I know what I am talking about here. There are many ways to improve this course, and I would like to see it improved over time. The aspirations of this course is commendable, but somewhere in the planning it seemed like the designers lost their bearings - ended up cramming information in favour of education.

 

For now, whether professional course or not, I find myself leaning towards Coursera/Udemy or even Google.

 

Image: A slight overreach...

 

 

Credits

Credits to where they are due:

 

Thanks to the course designers at ARM for creating this course. There's no question that countless hours of work and planning (and dare I say, passion?) have been put into this course. (Although not immediately applicable, I do find myself more knowledgeable with regards to Arm products.) And it is my sincere hope that our reviews can help inform the design of future courses.

Thanks to for organising and sticking with us in this dragged-out road test. I'm sure you didn't expect this simple road test to drag out this long. You have been a champ in liaising between us and ARM. Kudos!

Thanks to my friend weiwei2, who has invited me to participate in the road test. You always know where to find the good stuff.

Thanks to you, my readers who persevered to the end of this article. (If you think reading this article is painful, wait till you enrol in the course itself.)

Anonymous