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

[ataradov]

Cool How much flash space did it take up?

20 KB. It obviously uses a lot of dynamic libraries, which are probably taking dozens of megabytes.

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.

You are confusing things. The board I was using runs Linux, it is nowhere close to Arduino stuff. It is like Raspberry Pi.

AVR compiler does not support STL, so you are out of luck there. Again, you need plain C for those boards.

Here is what happens if you try to compile that madness with AVR GCC:

alexru:/tmp/2$ avr-g++ -std=c++11 r.cpp
r.cpp:1:20: fatal error: iostream: No such file or directory

You get the idea

[nbritton]

Alright, thanks for your help, I just bought a Raspberry Pi 3 Model B.

[JPortici]

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

of course.
a lot of the newer pic offerings (i think even from pic16 up to pic32) has either a PRNG or a TRNG. if not explicitely noted look in the oscillator section, you may have a "random" register that can be used by the MCU to implement frequency hopping of the internal oscillator
cortex M4 has a TRNG, but that may be vendor-dependant

[Dubbie]

Alright, thanks for your help, I just bought a Raspberry Pi 3 Model B.

Finally!
I thought you were never going to take Ataradov's advice.


Sent from my iPhone using Tapatalk

[tggzzz]

If you want to get a leg-up on the other people on the course, read learn and inwardly digest the C++ FQA (no typo). While not updated to C++14, it is still highly relevant and highly amusing.

See http://yosefk.com/c++fqa/

[gmb42]

If you want to get a leg-up on the other people on the course, read learn and inwardly digest the C++ FQA (no typo). While not updated to C++14, it is still highly relevant and highly amusing.

See http://yosefk.com/c++fqa/

Another run of your standard trope to C++ questions.  Meanwhile, many folks are actually using C++ (along with many other languages) for millions of applications that actually do something useful.  Some even pass all their tests and run for decades (I'm not joking here, stuff I wrote in the 90's is still in use in the field) and haven't blown up yet.

Of course, sometimes I run into problems, mostly logical errors in my own code, occasionally a compiler\library bug, and once in a blue moon a language issue.  None of these problems are exclusive to C++.

[nbritton]

Alright, thanks for your help, I just bought a Raspberry Pi 3 Model B.

Finally!
I thought you were never going to take Ataradov's advice.

It was great advice. As a beginner, it's really the only choice because it has the most educational resources due to its ubiquity. I was really interested in a x86 device, but as far as I can tell only the Intel Edison has WiFi. The deciding factor for me was that it has WiFi and Bluetooth to connect my wireless keyboard, and that it was cheap.

I still would like to find an x86 ISA board that I can use as a trainer for learning more about how the platform works at the component level and how the hardware interacts with the operating system. One of my long term goals is to make my own rudimentary computer from scratch using discrete components.

[nctnico]

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

I wouldn't rule out anything right off the bat because it could be bloated or slow. At the end of the day what counts is whether it works perfectly and is finished in a reasonable timeframe. For example: In a DSP project I used soft floating point because it was fast enough to get the job done.

[nbritton]

If you want to get a leg-up on the other people on the course, read learn and inwardly digest the C++ FQA (no typo). While not updated to C++14, it is still highly relevant and highly amusing.

See http://yosefk.com/c++fqa/

Another run of your standard trope to C++ questions.  Meanwhile, many folks are actually using C++ (along with many other languages) for millions of applications that actually do something useful.  Some even pass all their tests and run for decades (I'm not joking here, stuff I wrote in the 90's is still in use in the field) and haven't blown up yet.

Of course, sometimes I run into problems, mostly logical errors in my own code, occasionally a compiler\library bug, and once in a blue moon a language issue.  None of these problems are exclusive to C++.

C is a 44 year old programming language and C++ is 33 years old. The world's first stored-program computer (Manchester) was created in 1948, which was only 68 years ago. So C was created only 24 years after that. It took us 60 years from first flight by the Wright brothers until we got into space. You have to keep that in perspective before complaining about the language, in its day it was an awesome language and it helped to build the foundation of world we know today. With the additions of C++11, C++14, and the upcoming C++17 I believe the language can stay relevant. C and C++ is about as close as most people want to get to the hardware so I don't see them going away any time soon. The modern human is about 200,000 years old, so 68 years represent a fraction of a blip on that time scale... computers are still in their infancy.

[legacy]

computers are still in their infancy.

it's also interesting that fourth-order languages
like "Prolog" (PROgrammation en LOGique)
haven't grown in their popularity and currently
almost used for AADL's purposes (e.g. "Stood")


!:: computers are still in their infancy
-> artificial intelligence is not born yet

[tggzzz]

If you want to get a leg-up on the other people on the course, read learn and inwardly digest the C++ FQA (no typo). While not updated to C++14, it is still highly relevant and highly amusing.

See http://yosefk.com/c++fqa/

Another run of your standard trope to C++ questions.  Meanwhile, many folks are actually using C++ (along with many other languages) for millions of applications that actually do something useful.  Some even pass all their tests and run for decades (I'm not joking here, stuff I wrote in the 90's is still in use in the field) and haven't blown up yet.

Of course, sometimes I run into problems, mostly logical errors in my own code, occasionally a compiler\library bug, and once in a blue moon a language issue.  None of these problems are exclusive to C++.

Unfortunately almost as many are misusing c/c++, usually through ignorance of its misfeatures.

Don't forget that the second book on C in 1981 (The C Puzzle Book) detailed it's few "idiosyncrasies", and it has got much worse since then. In the early 90s even the language designers didn't understand what they had created. (Yes, I still have both K&R and The Puzzle Book; it is worrying to realise I first used C professionally 35 years ago).

The c++ fqa is invaluable not only for beginners but those that think they know the language.

[rstofer]

C is a 44 year old programming language and C++ is 33 years old. The world's first stored-program computer (Manchester) was created in 1948, which was only 68 years ago. So C was created only 24 years after that.

C is still around because it serves its purpose better than anything that has come along.  Major projects, like the Linux kernel, are still being written in C.

Fortran is even older than C but it is still in use in the scientific community because it serves its purpose better than anything that has come along.  It's a simple language which means it is easy to learn and apply.  When you want a fast answer to an arithmetic problem, Fortran is still the way to get it.  I have been using it when providing sidebar explanations for my grandson's math courses.  I will make certain he learns how to write Fortran code over the Thanksgiving break.  It's a tool, just like a calculator.  I rather like the extensions over Fortran IV where they have cleaned up the IF and DO statements.

I have yet to try gfortran against one of the embedded (ARM) versions of gcc.  Wouldn't that be cool?  Image processing on a robot coded in Fortran.

[tggzzz]

C is a 44 year old programming language and C++ is 33 years old. The world's first stored-program computer (Manchester) was created in 1948, which was only 68 years ago. So C was created only 24 years after that.

C is still around because it serves its purpose better than anything that has come along. 

That's very debatable; never underestimate the power of inertia. Hence COBOL

Nowadays the critical factor isn't the C/C++ language(s) per se, rather it is the accumulated development environments and libraries, and upfront financial cost.

Major projects, like the Linux kernel, are still being written in C.

Well of course it is! Nobody in their right mind would rewrite it in another language.

Fortran is even older than C but it is still in use in the scientific community because it serves its purpose better than anything that has come along.  It's a simple language which means it is easy to learn and apply.  When you want a fast answer to an arithmetic problem, Fortran is still the way to get it.  I have been using it when providing sidebar explanations for my grandson's math courses.  I will make certain he learns how to write Fortran code over the Thanksgiving break.  It's a tool, just like a calculator.  I rather like the extensions over Fortran IV where they have cleaned up the IF and DO statements.

Agreed.

[lukier]

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

  Tell me why I cannot get far in the embedded world, even on an 8 bit MCU, with such "horrible" STL/Boost things: std::array, std::pair, std::tuple, std::fill, std::is_same, boost::circular_buffer, boost::crc and so on.

These are pretty much pure templates, no new/delete, no exceptions or can be disabled, the compiler optimizes out everything leaving very compact output binary (or nothing in the binary, as some things like std::is_same are only compile time). I think people don't realize how good C++ compilers became in the last 1-2 decades. And in the exceptionally very rare cases one can always study the resulting assembly and may hint the compiler to do the right thing anyway, without resorting to the inline assembly.

Also there is embedded and there is embedded, sometimes people think everything is ATtiny. I once worked in a mission critical project (core network switch, total switching 6 Tbit/s) where our system was running on 14 cards, each one with dual core 1GHz PowerPC and 2GB RAM (some of the cards were control cards, one card active, one sleeping and taking over if the primary fails - extra redundancy).

The system was complex, written in C++, but with RT-allocator and Xenomai where needed. The management decided we cannot use STL because: "STL is not for embedded". Instead they've decided to get some people to develop "in-house" STL containers alternative. After a lot of time and corporate money they've came up with C++ classes operating on void pointers and even the simple vector there was 20% slower than the STL one, not to mention the bugs there (STL is tested for decades everywhere).

C is still around because it serves its purpose better than anything that has come along.  Major projects, like the Linux kernel, are still being written in C.

Historical reasons and Linus' personal animosity towards C++, probably related to the former. When Linux was started C++ wasn't that mature, compilers buggy and the UNIX tradition has always been K&R C.

AFAIR Linus's argument against C++ was dynamic memory management (new/delete) and exceptions. For my embedded projects I disable exceptions (binary size too big for small MCUs) and either don't use heap (small stuff) or put TLSF allocator (real-time) underneath new/delete operators - problem solved.

I did some kernel development and when you start learning Linux codebase the lack of C++ syntax screams at you everywhere, for example:

• containers done with void pointers and macros (e.g. INIT_LIST_HEAD) - yay type safety,
• polymorphism, virtual functions and object hierarchies done with structs with function pointers that have to be manually set (e,g, ethtool_ops), pointer arithmethic to get private data (e.g. netdev_priv) and other horrid constructs
• instead of exceptions we get a ton of error prone gotos and return codes

Of course no one in the right mind would now start rewriting Linux to C++, it would be a tremendous effort. I think there were plans to rewrite GCC to C++, but I don't know what's the current status. Richard Stallman (original author of GCC) is another anti-C++ dinosaur. Of course it is perfectly possible to write a good compiler in C++, LLVM/Clang is the proof.

I don't get this C/C++ argument at all. C++ supports C as well and one can do stupid things in both languages. If someone is not fluent in C++ and writes embedded code with heavy use of heap (and with non-RT allocator), incorrectly uses exceptions (for program flow) or god knows why uses RTTI then it is not the language to blame. One can do stupid stuff in C, pulling in size-heavy glibc functions, dynamic memory on void pointers and ignore type safety.

I personally use C++ everywhere, from small MCU to large multithreaded image processing apps, either on the CPU or nVidia CUDA and I absolutely love strong type safety and template metaprogramming in all of these platforms. Just, as any other skilled worker, know your tools and libraries.

[ataradov]

Tell me why I cannot get far in the embedded world, even on an 8 bit MCU, with such "horrible" STL/Boost things: std::array, std::pair, std::tuple, std::fill, std::is_same, boost::circular_buffer, boost::crc and so on.

Because of this:

For my embedded projects I disable exceptions (binary size too big for small MCUs) and either don't use heap (small stuff) or put TLSF allocator (real-time) underneath new/delete operators - problem solved.
......
If someone is not fluent in C++ and writes embedded code with heavy use of heap (and with non-RT allocator), incorrectly uses exceptions (for program flow) or god knows why uses RTTI then it is not the language to blame.

You really-really need to know what you are doing. And it is very clear that OP does not at the moment.

It is like asking "can I drive safely without seat belts". You can under certain conditions, but in most cases, if you don't know exactly what you are doing, you should not.

Also, C++ projects tend to bloat if there is no control. If you are working in a team, over time, people start using more and more of nice, but expensive features of  C++. If you work alone, you can control that. If you work on a team - not necessarily.

[legacy]

instead of exceptions we get a ton of error prone gotos and return codes

this part looks interesting 

[legacy]

I mean those "exceptions features" have been a part of C++
since early 90s (correct?) and are sanctioned by the standard
to be *THE* mechanism for writing fault-tolerant code
however, many developers for various reasons choose not to use
exceptions, and voices that are skeptical of this language feature
are still numerous and loud 

[nctnico]

IMHO the problem with exceptions is that you still need to handle the error in a gracefull manner otherwise it is just a nice way to crash. When used to catch an error an exception is very similar to (for those familiar with Basic) 'on error goto...'

[legacy]

Google C++ Style Guide are some of the frequently
quoted texts that advise against the use of exceptions.

on the other way, exceptions are hard to ignore, unlike error
codes, and easily propagated from deeply nested functions

but, Exceptions break code structure by creating multiple
invisible exit points that make code hard to read and inspect

and they easily lead to resource leaks, especially in a language
that has no built-in garbage collector and finally blocks.

( should a kernel have a garbage collector ? no sense  )

also, from the implementation point of view,  Exceptions are also
expensive and break the promise to pay only for what you use.

[lukier]

You really-really need to know what you are doing. And it is very clear that OP does not at the moment.

That's maybe true, but then you think one cannot shoot themself in the foot in C? OP needs to learn, doesn't matter if C or C++. This is not a C++ problem

Also, C++ projects tend to bloat if there is no control. If you are working in a team, over time, people start using more and more of nice, but expensive features of  C++. If you work alone, you can control that. If you work on a team - not necessarily.

You have no idea how serious the development process is in mission critical projects. First of all there is way more documentation & paperwork then the code itself, then very strict coding standards (see MISRA or Joint Strike Fighter) and the available language features and libraries are set by the architects, fixed in the Board Support Package or similar construct project-wide and there is no way you'll pull your own "cool think" into the codebase.

Also, you cannot merge your branch into the mainline of the project without a dozen of signatures, from code review to approvals on unit tests and component tests from the testing/integration team, static & dynamic code analysis results, automated coding standard compliance verification to paperwork like release notes and other traceability related stuff. And then in the next project internal release cycle the performance integration testing team will come back to you if there are problems with performance.

That's why I laughed when it was in the news that the VW emissions was just a thing done by few engineers without anyone knowing. No f... way.

Also, as I mentioned before, in this case "embedded" didn't mean resource constrained and STL containers would be perfectly acceptable.

this part looks interesting 

I know exceptions are difficult. That's probably one of two C++ features (another being RTTI) where I don't object if people say to turn them off. I do that myself for MCU projects, because exception handling adds 65KB to my binary.

On less resource constrained platforms I prefer exceptions and RAII design pattern to a litany of gotos and labels like in Linux kernel and forgetting to manually release some resource in each of the 10 gotos in a function. Also, there are some myths around exceptions, for example some people think that using exceptions impacts performance. This is not true, currently exceptions are implemented with Zero-Cost model and if there is no exception there is no performance penalty.

Google C++ Style Guide are some of the frequently
quoted texts that advise against the use of exceptions.

Google C++ Style Guide is horrible and I think the intentions were as such: 1) we have 100 mln lines of current bad code, so let's keep writing more bad code, 2) we don't expect fresh undergrads to know C++ well, we cannot afford skilled people in large numbers, so let's work our way around that.

The dogmatic lack of exceptions creates another problems in this style guide (e.g. constructors are bad etc).

[legacy]

just a nice way to crash

especially if you feel there is a lack of "discipline"
in your development team 

I mean learning to write Exception safe code is hard
and, still worse, is hard to introduce to legacy code
(not mentioning that it's hard for the testing team)

[ataradov]

You have no idea how serious the development process is in mission critical projects.

I do, but most projects are not "mission critical" and you don't have a luxury of rigorous code review.

[lukier]

I do, but most projects are not "mission critical" and you don't have a luxury of rigorous code review.

Again, nothing to do with C++ as such.

I'm quite militant on this C/C++ issue because there is a ton of people in the embedded world that either don't know C++ that well or tried a bit of  C++ in the early nineties when it was buggy. It doesn't stop them from spreading the misinformation that persists after 2 decades. Myths abouts runtime performance of exceptions (by people that use exceptions for control flows or non-critical errors), that virtual functions are slow (your series of ifs or a switch statement in C is probably slower than a C++ call table), that C++ produces huge binaries (C++ compilers are extremely good nowadays and Template Metaprogramming alows code that runs in the compile time, possibly generating no assembly at all) and so on.

C++ combines nice OO and sometimes unique (template metaprogramming) features while being as close to the metal as C, this gives tremendous possibilities. I agree that exceptions are problematic and C++ has a steep learning curve, but in C++ you can always write your C code, just it's nothing to be proud about .

[legacy]

@lukier
I see the UK flag in your profile: Cheltenham?
I happen to have some collaborations there, but it's C only
things like bpum, BSP, iBSP, Automa, and some drivers
nothing as complex as the AFDX lan-switch (was it?)
on which you have probably worked

frankly, when you say C++ I have a thrill of genuine fear
if I let my mind thinking about tools like Vectorcast
applied to C++, in a mission critical environment
with exceptions enabled ( God save the Queen  )

[lukier]

@lukier
I see the UK flag in your profile: Cheltenham?
I happen to have some collaborations there, but it's C only
things like bpum, BSP, iBSP, Automa, and some driver
nothing as complex as the AFDX lan-switch (was it?)
on which you have probably worked

frankly, when you say C++ I have a thrill of genuine fear
if I let my mind thinking about tools like Vectorcast
applied to C++, in a mission critical environment
with exceptions enabled ( God save the Queen  )

Nope, London now, Kings Langley before, and Poland even before that. Telecom stuff was elsewhere. In the UK I was working on drivers and firmware for a video decoding IP core. A lot of stories from there as well, it felt like being in the 80's
Now I'm gladly not in the industry anymore, just submitted my PhD and now I'm a research engineer at a university (to transfer our research to the industrial sponsor, a lot of freedom, no corporate Dilbert-like scenarios, a lot of prototyping or making quick-and-dirty demos).

BTW on the Google Style Guide I like this review:
https://www.linkedin.com/pulse/20140503193653-3046051-why-google-style-guide-for-c-is-a-deal-breaker