Taking a C++ class, looking for a C++14 compatible microcontroller to play with.

[nbritton]

Hi,

I'm taking a C++ programming course at my local college and I'm wondering which microcontrollers I can program with C++14 or C++11 for practice and experimentation. Support for the Standard Library, STL, and/or Boost would be nice. Would prefer a development or prototyping board that has I/O headers.

The size of the programs I've created so far average 450KB compiled on my mac. So I'm guessing I would need 1MB+ of flash?

[Franc]

Atmel SAM D in AS7 ..

[nbritton]

Atmel SAM D in AS7 ..

The Arduino Zero has a SAM D21, would you recommend this board?

https://www.arduino.cc/en/Main/ArduinoBoardZero

[ataradov]

It doe not matter at all. Any MCU with GCC support will work.

But if you are just taking the class, do you want to pile up figuring embedded programming at the same time? Programming for embedded device is quite a bit different from programming desktop applications.

And with STL and Boost you won't get far in the embedded world.

[rstofer]

^^^ What he said!

I would want to program the C++ stuff for the PC.  I don't care whether it is a command line program for Windows or whether it targets Linux but I sure wouldn't want to try to get up to speed on embedded programming with an application that is that large.  You could target the Raspberry PI, I suppose.  That's a full blown Linux system on a board and, while you can do some 'sort of' embedded programming, you don't have to.  There are Python examples of embedded stuff included in the distribution (IIRC).

[nbritton]

But if you are just taking the class, do you want to pile up figuring embedded programming at the same time?

And with STL and Boost you won't get far in the embedded world.

I thought I did, I was thinking I could knock out two birds with one stone. I work as a Linux systems engineer so I'm thinking I can translate that skillset to figuring out embedded programming. Also, the C++ course I'm taking is all console based programming.

In fact, maybe a little embedded ARM prototyping board running Linux would be what I'm looking for? Can I install gcc on the Raspberry Pie?

[ataradov]

Also, the C++ course I'm taking is all console based programming.

Well, in embedded world there is not even a console

In fact, maybe a little embedded ARM prototyping board running Linux would be what I'm looking for?

Depends on what you want to do. Programming for Linux on RPi is not all that different from programming for desktop Linux. And If you don't have a project that actually warrants the use of RPi, then it is a waste of time, just program for desktop. And programming for RPi is very-very different from programming MCUs with no OS or with RTOS.

Can I install gcc on the Raspberry Pie?

Yes, you can. It runs full Debian, you can install anything you like.

[ez24]

Can I install gcc on the Raspberry Pie?

Sounds good, but I never had one.  Has anyone ever eaten a raspberry pie?

[nbritton]

There are Python examples of embedded stuff included in the distribution (IIRC).

Yeah, that reminds me! I'm taking a Python class too, so I would want to be able to program using that too. Perhaps what I actually need is a Linux prototyping board that has some GPIO, SPI, and I2C headers? I still would like to get into microcontroller programming though.

[ataradov]

Perhaps what I actually need is a Linux prototyping board that has some GPIO, SPI, and I2C headers?

That's a RPi.

I still would like to get into microcontroller programming though.

That's something entirely different and you better get used to programing in plain C. Majority of advanced C++ features are way too expensive on MCUs.

[nbritton]

Perhaps what I actually need is a Linux prototyping board that has some GPIO, SPI, and I2C headers?

That's a RPi.

I still would like to get into microcontroller programming though.

That's something entirely different and you better get used to programing in plain C. Majority of advanced C++ features are way too expensive on MCUs.

What about something like the Intel Edison or Galileo? Would that teach me more about what's going on under the hood? One of my goals is learning more about everything that is going on between the bare hardware and the operating system, so the thing that appeals to me about the Intel boards is that they're based on the x86 based ISA.

Mastering C is on my bucket list, but for the next few months I'm focused exclusively on C++11 and Python.

[ataradov]

What about something like the Intel Edison? Would that teach me more about what's going on under the hood? One of my goals is learning more about everything that is going on between the bare hardware and the operating system, so the thing that appeals to me about the Intel Edison is it's based on the x86 based ISA.

You are programming in high level language, what do you care what ISA your MCU has?

Intel Edison is a pretty pointless thing. It is very restrictive on available memories and has no features that would make it attractive for any practical use.

Industry standard for embedded things right now is ARM, and if you want to get some useful practical skill, then learn ARM.

Mastering C is on my bucket list, but for the next few months I'm focused exclusively on C++11 and Python.

Then do desktop stuff first. C is basically the same as C++ if you don't use classes.

[nbritton]

Industry standard for embedded things right now is ARM, and if you want to get some useful practical skill, then learn ARM.

Agreed. However, I work with commodity Linux servers and x86 is the only player in this market. In fact, the company I work for has a strategic partnership with Intel.

[ataradov]

Agreed. However, I work with commodity Linux servers and x86 is the only player in this market. In fact, the company I work for has a strategic partnership with Intel.

That's fine, but what MCUs have to do with that?

You can program regular computers on a low level - just look at the code of any Linux loader (LiLo, GRUB). Then take QEmu or VirtualBox and do x86 programming on a low level all you want.

Edison is an x86 core slapped on top of mediocre MCU peripherals, it is nothing like programming actual real x86 hardware.

[kc8apf]

What you use for desktop or server isn't relevant for embedded work. There's basically no overlap in ISA between the two worlds.

Sent from my Nexus 5X using Tapatalk

[nbritton]

Edison is an x86 core slapped on top of mediocre MCU peripherals, it is nothing like programming actual real x86 hardware.

What do you think of the MinnowBoard Max? It sounds like what I need then is real x86 hardware, but with the addition of GPIO and SPI headers that I can program with C++ or Python. At home I'm all Apple and Mac OS X on my desktops, so I can't (read don't want to) play with them. I think maybe what I really want is just a little low wattage box that I can SSH into wirelessly that has some GPIO headers and SPI and I2C buses I can play with.

[ataradov]

What do you think of the MinnowBoard Max?

Never heard of it, but looks like a decent board.

But if you are going this route, then why not RPi? At no point you will actually see that it is an ARM processor. Same as you will never know that it is an x86 with MinnowBoard.

Using those interfaces from Python sounds more likely on RPi than on MinnowBoard.

[Ian.M]

Yes, there's a *LOT* to be said for sticking with mainstream hardware, and the Pi is about as mainstream as it gets for consumer SBCs.  Get a PI 3 to develop on then if you want to integrate it into anything consider a Pi Zero to deploy with.

Also why not try an Arduino?  The Uno is the most popular entry level one and you'll soon get a feel for how much of C++ is practical on a small MCU with only 2K RAM.  Its very easy to ditch the Arduino setup()/loop() stuff^* and code in raw GCC C++, either with the simplified Arduino HAL, or digging deeper and using the raw AVR registers and libraries.  Once you've mastered that, porting to any ATmega MCU is fairly simple.

Both platforms have plenty of good breadboardable tutorials to cover the interfacing side of things.

* see http://www.gammon.com.au/forum/?id=12625

[nbritton]

Hardware wise, what would it take to run the code below?... it uses the new c++11 <random> library.

#include <iostream>
#include <random>
#include <type_traits>
#include <thread>

using namespace std;

template < typename T > inline T get_random_number( T min, T max ) {
   
    static_assert( std::is_arithmetic<T>::value, "expected integral or floating point type" ) ;
   
    static std::mt19937_64 generator ( std::chrono::steady_clock::now().time_since_epoch().count() );
   
    using uniform_distribution = typename std::conditional< std::is_integral<T>::value,
                                                            std::uniform_int_distribution<T>,
                                                            std::uniform_real_distribution<T> >::type ;
   
    std::this_thread::sleep_for( std::chrono::nanoseconds(1) );
   
    return uniform_distribution(min, max) (generator);
}

int main(int argc, const char * argv[]) {
   
    while (true) {
        cout << get_random_number<int>(0, 1);
    }
    return 0;
}

[ataradov]

This is very hardware-independent, so any platform with reasonably recent GCC will run this without any problems.

This will definitely work on RPi.

[asgard20032]

Does some general purpose mcu (not talking about high end blackfin), like avr, pic, mps430, arm cortex... has some random number generator?

[ataradov]

Correction. It will compile on RPi, whether it will work is not guaranteed, apparently.

I don't have a free RPi at the moment, but I do have Atmel SAMA5D3 Xplained board (still runs Linux).

This program compiles but hangs when you run it.

I'll try to debug a bit. It may lack a source of entropy.

[ataradov]

Does some general purpose mcu (not talking about high end blackfin), like avr, pic, mps430, arm cortex... has some random number generator?

Some do, but most don't.  At the same time they all have lots of peripheral that can be used for random number generation (ADC noise, random content of the RAM on power up, variable time it takes to write a EEPROM value, etc).

[ataradov]

Yes, so the program above works. It was console buffering that held the output.

With modification like this:

Code: [Select]

    while (true) {
        cout << get_random_number<int>(0, 1) << "\n";
    }
it prints random numbers right away.

[pardon for "\n", I'm not into screwed up C++ standard output stuff]

[nbritton]

Yes, so the program above works.

Cool. How much space did it take up? I'm still trying to get a feel for how big the binaries are that the compiler makes. Could this fit and run on an Ardunio Micro, Pro Mini, Uni, or Mega? I have all of those boards.