Taking a C++ class, looking for a C++14 compatible microcontroller to play with. - Page 1
Forum section: electronics / general

author: nbritton
author_rank: Frequent Contributor
timestamp: October 15, 2016, 12:30:47 am
content: 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?

author: Franc
author_rank: Regular Contributor
timestamp: October 15, 2016, 12:35:16 am
content: Atmel SAM D in AS7 ..

author: nbritton
author_rank: Frequent Contributor
timestamp: October 15, 2016, 12:53:39 am
content: Quote from: Franc on October 15, 2016, 12:35:16 amThe Arduino Zero has a SAM D21, would you recommend this board?https://www.arduino.cc/en/Main/ArduinoBoardZero

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 01:02:07 am
content: 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.

author: rstofer
author_rank: Super Contributor
timestamp: October 15, 2016, 01:09:34 am
content: ^^^ 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).

author: nbritton
author_rank: Frequent Contributor
timestamp: October 15, 2016, 01:13:30 am
content: Quote from: ataradov on October 15, 2016, 01:02:07 amI 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?

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 01:17:44 am
content: Quote from: nbritton on October 15, 2016, 01:13:30 amWell, in embedded world there is not even a consoleQuote from: nbritton on October 15, 2016, 01:13:30 amDepends 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.Quote from: nbritton on October 15, 2016, 01:13:30 amYes, you can. It runs full Debian, you can install anything you like.

author: ez24
author_rank: Super Contributor
timestamp: October 15, 2016, 01:19:17 am
content: Quote from: nbritton on October 15, 2016, 01:13:30 amSounds good, but I never had one. Has anyone ever eaten a raspberry pie?

author: nbritton
author_rank: Frequent Contributor
timestamp: October 15, 2016, 01:21:02 am
content: Quote from: rstofer on October 15, 2016, 01:09:34 amYeah, 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 01:23:11 am
content: Quote from: nbritton on October 15, 2016, 01:21:02 amThat's a RPi.Quote from: nbritton on October 15, 2016, 01:21:02 amThat'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.

author: nbritton
author_rank: Frequent Contributor
timestamp: October 15, 2016, 01:41:16 am
content: Quote from: ataradov on October 15, 2016, 01:23:11 amWhat 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 01:46:20 am
content: Quote from: nbritton on October 15, 2016, 01:41:16 amYou 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.Quote from: nbritton on October 15, 2016, 01:41:16 amThen do desktop stuff first. C is basically the same as C++ if you don't use classes.

author: nbritton
author_rank: Frequent Contributor
timestamp: October 15, 2016, 02:03:56 am
content: Quote from: ataradov on October 15, 2016, 01:46:20 amAgreed. 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 02:07:51 am
content: Quote from: nbritton on October 15, 2016, 02:03:56 amThat'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.

author: kc8apf
author_rank: Regular Contributor
timestamp: October 15, 2016, 02:09:23 am
content: 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

author: nbritton
author_rank: Frequent Contributor
timestamp: October 15, 2016, 02:33:27 am
content: Quote from: ataradov on October 15, 2016, 02:07:51 amWhat 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 02:37:38 am
content: Quote from: nbritton on October 15, 2016, 02:33:27 amNever 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.

author: Ian.M
author_rank: Super Contributor
timestamp: October 15, 2016, 03:44:56 am
content: 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.* seehttp://www.gammon.com.au/forum/?id=12625

author: nbritton
author_rank: Frequent Contributor
timestamp: October 15, 2016, 04:47:53 am
content: Hardware wise, what would it take to run the code below?... it uses the new c++11 <random> library.Quote

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 04:55:30 am
content: This is very hardware-independent, so any platform with reasonably recent GCC will run this without any problems.This will definitely work on RPi.

author: asgard20032
author_rank: Regular Contributor
timestamp: October 15, 2016, 05:05:36 am
content: Does some general purpose mcu (not talking about high end blackfin), like avr, pic, mps430, arm cortex... has some random number generator?

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 05:07:19 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 05:09:54 am
content: Quote from: asgard20032 on October 15, 2016, 05:05:36 amSome 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).

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 05:14:13 am
content: Yes, so the program above works. It was console buffering that held the output.With modification like this:Code: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]

author: nbritton
author_rank: Frequent Contributor
timestamp: October 15, 2016, 05:40:14 am
content: Quote from: ataradov on October 15, 2016, 05:14:13 amCool. 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 05:43:13 am
content: Quote from: nbritton on October 15, 2016, 05:40:14 am20 KB. It obviously uses a lot of dynamic libraries, which are probably taking dozens of megabytes.Quote from: nbritton on October 15, 2016, 05:40:14 amYou 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:QuoteYou get the idea

author: nbritton
author_rank: Frequent Contributor
timestamp: October 15, 2016, 06:50:00 am
content: Alright, thanks for your help, I just bought a Raspberry Pi 3 Model B.

author: JPortici
author_rank: Super Contributor
timestamp: October 15, 2016, 06:56:50 am
content: Quote from: asgard20032 on October 15, 2016, 05:05:36 amof 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 oscillatorcortex M4 has a TRNG, but that may be vendor-dependant

author: Dubbie
author_rank: Unknown
timestamp: October 15, 2016, 07:12:18 am
content: Quote from: nbritton on October 15, 2016, 06:50:00 amFinally!I thought you were never going to take Ataradov's advice.Sent from my iPhone using Tapatalk

author: tggzzz
author_rank: Super Contributor
timestamp: October 15, 2016, 08:35:56 am
content: 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.Seehttp://yosefk.com/c++fqa/

author: gmb42
author_rank: Frequent Contributor
timestamp: October 15, 2016, 08:45:18 am
content: Quote from: tggzzz on October 15, 2016, 08:35:56 amAnother 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++.

author: nbritton
author_rank: Frequent Contributor
timestamp: October 15, 2016, 02:35:11 pm
content: Quote from: Dubbie on October 15, 2016, 07:12:18 amIt 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.

author: nctnico
author_rank: Super Contributor
timestamp: October 15, 2016, 02:54:34 pm
content: Quote from: ataradov on October 15, 2016, 01:02:07 amI 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.

author: nbritton
author_rank: Frequent Contributor
timestamp: October 15, 2016, 03:06:48 pm
content: Quote from: gmb42 on October 15, 2016, 08:45:18 amC 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.

author: legacy
author_rank: Super Contributor
timestamp: October 15, 2016, 05:43:15 pm
content: Quote from: nbritton on October 15, 2016, 03:06:48 pmit's also interesting thatfourth-order languageslike "Prolog" (PROgrammation enLOGique)haven't grown in their popularity and currentlyalmost used forAADL's purposes (e.g. "Stood")!:: computers are still in their infancy-> artificial intelligence is not born yet

author: tggzzz
author_rank: Super Contributor
timestamp: October 15, 2016, 05:55:17 pm
content: Quote from: gmb42 on October 15, 2016, 08:45:18 amUnfortunately almost as many are misusing c/c++, usually through ignorance of its misfeatures.Don't forget that thesecondbook 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 thatthinkthey know the language.

author: rstofer
author_rank: Super Contributor
timestamp: October 15, 2016, 07:00:02 pm
content: Quote from: nbritton on October 15, 2016, 03:06:48 pmC 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.

author: tggzzz
author_rank: Super Contributor
timestamp: October 15, 2016, 07:10:24 pm
content: Quote from: rstofer on October 15, 2016, 07:00:02 pmThat's very debatable; never underestimate the power of inertia. Hence COBOLNowadays the critical factor isn't the C/C++ language(s) per se, rather it is the accumulated development environments and libraries, andupfrontfinancial cost.QuoteWell of course it is! Nobody in their right mind would rewrite it in another language.QuoteAgreed.

author: lukier
author_rank: Unknown
timestamp: October 15, 2016, 08:45:14 pm
content: Quote from: ataradov on October 15, 2016, 01:02:07 amTell 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).Quote from: rstofer on October 15, 2016, 07:00:02 pmHistorical 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 constructsinstead of exceptions we get a ton of error prone gotos and return codesOf 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.

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 08:54:20 pm
content: Quote from: lukier on October 15, 2016, 08:45:14 pmBecause of this:Quote from: lukier on October 15, 2016, 08:45:14 pmYou 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.

author: legacy
author_rank: Super Contributor
timestamp: October 15, 2016, 08:54:46 pm
content: Quote from: lukier on October 15, 2016, 08:45:14 pmthis part looks interesting

author: legacy
author_rank: Super Contributor
timestamp: October 15, 2016, 09:04:45 pm
content: I mean those "exceptions features" have been a part of C++since early 90s (correct?) and are sanctioned by the standardto be *THE* mechanism for writingfault-tolerantcodehowever, many developers for various reasons choose not to useexceptions, and voices that are skeptical of this language featureare still numerous and loud

author: nctnico
author_rank: Super Contributor
timestamp: October 15, 2016, 09:10:37 pm
content: 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...'

author: legacy
author_rank: Super Contributor
timestamp: October 15, 2016, 09:11:37 pm
content: Google C++ Style Guideare some of the frequentlyquoted texts that adviseagainst the useof exceptions.on the other way, exceptions are hard to ignore, unlike errorcodes, and easily propagated from deeply nested functionsbut, Exceptionsbreakcode structure by creating multipleinvisible exit points that make code hard to read and inspectand they easily lead to resource leaks, especially in a languagethat 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 alsoexpensive andbreakthe promise to pay only for what you use.

author: lukier
author_rank: Unknown
timestamp: October 15, 2016, 09:18:15 pm
content: Quote from: ataradov on October 15, 2016, 08:54:20 pmThat'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++ problemQuote from: ataradov on October 15, 2016, 08:54:20 pmYou 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.Quote from: legacy on October 15, 2016, 08:54:46 pmI 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.Quote from: legacy on October 15, 2016, 09:11:37 pmGoogle 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).

author: legacy
author_rank: Super Contributor
timestamp: October 15, 2016, 09:20:13 pm
content: Quote from: nctnico on October 15, 2016, 09:10:37 pmespecially if you feel there is a lack of "discipline"in your development teamI mean learning to write Exception safe code is hardand, still worse, is hard to introduce to legacy code(not mentioning that it's hard for the testing team)

author: ataradov
author_rank: Super Contributor
timestamp: October 15, 2016, 09:20:56 pm
content: Quote from: lukier on October 15, 2016, 09:18:15 pmI do, but most projects are not "mission critical" and you don't have a luxury of rigorous code review.

author: lukier
author_rank: Unknown
timestamp: October 15, 2016, 09:32:08 pm
content: Quote from: ataradov on October 15, 2016, 09:20:56 pmAgain, 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.

author: legacy
author_rank: Super Contributor
timestamp: October 15, 2016, 09:41:14 pm
content: @lukierI see the UK flag in your profile:Cheltenham?I happen to have some collaborations there, but it's C onlythings likebpum, BSP, iBSP, Automa, and some driversnothing as complex as the AFDX lan-switch (was it?)on which you have probably workedfrankly, when you say C++ I have a thrill of genuine fearif I let my mind thinking about tools likeVectorcastapplied to C++, in a mission critical environmentwith exceptions enabled ( God save the Queen)

author: lukier
author_rank: Unknown
timestamp: October 15, 2016, 09:46:18 pm
content: Quote from: legacy on October 15, 2016, 09:37:55 pmNope, 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'sNow 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

author: legacy
author_rank: Super Contributor
timestamp: October 15, 2016, 09:48:29 pm
content: Quote from: lukier on October 15, 2016, 09:32:08 pmabout the capability of making a generic interfacesand let the compiler to instantiate things for youI really like the "generic" method offered by ADA:generic parameters, instances of generic packages

author: lukier
author_rank: Unknown
timestamp: October 15, 2016, 09:58:47 pm
content: Quote from: legacy on October 15, 2016, 09:48:29 pmI always wanted to do something in Ada. It has even stronger type safety than C++ (probably because there is no C backward compatibility to maintain), it has generics, exceptions etc. But I never had time to properly learn it and prepare the entire BSP or port RTEMS to my devkits, especially the bare metal MCU ones, not big-ARM devboards.Even with Ada one can go wronghttps://en.wikipedia.org/wiki/Cluster_(spacecraft)

author: IanB
author_rank: Super Contributor
timestamp: October 15, 2016, 11:10:47 pm
content: Quote from: lukier on October 15, 2016, 09:46:18 pmIs Kings Langley (interestingly, the spellchecker catches it for me). Clever spellchecker!

author: technix
author_rank: Super Contributor
timestamp: October 16, 2016, 02:03:33 pm
content: I think that anything with a recent enough version of GCC or LLVM will work. So far I know that there are up-to-date versions of GCC for ARM, AVR and x86 (yes Intel is making microcontrollers based on x86 and amd64 architecture, but so far those are all BGA chips), and LLVM can target ARM and x86.

author: andersm
author_rank: Super Contributor
timestamp: October 16, 2016, 02:15:57 pm
content: Quote from: technix on October 16, 2016, 02:03:33 pmThe Quark D2000 is (only) available in a QFN package.

author: technix
author_rank: Super Contributor
timestamp: October 16, 2016, 02:32:38 pm
content: Quote from: andersm on October 16, 2016, 02:15:57 pmI don't think that core runs AMD64 or x86 though...

author: andersm
author_rank: Super Contributor
timestamp: October 16, 2016, 04:51:29 pm
content: Quote from: technix on October 16, 2016, 02:32:38 pmThe D2000 uses the P5 ISA (sans floating-point), it's the D1000 that's not x86-compatible.

author: technix
author_rank: Super Contributor
timestamp: October 16, 2016, 04:58:00 pm
content: Quote from: andersm on October 16, 2016, 04:51:29 pmSo not exactly either x86 or amd64, but a weird cut-down version of it. I want to know if there is any open-source compiler support for those chips. Those are not cheap either by the way.If I need a 3.3V MCU at 40 pins with similar features I would prefer STM32F103CB or PIC18F46K20 anyway.

author: andersm
author_rank: Super Contributor
timestamp: October 16, 2016, 05:05:14 pm
content: Quote from: technix on October 16, 2016, 04:58:00 pmGCC should work with the D2000, but I'm not aware of any compiler other than Intel's own supporting the D1000.EDIT: I would consider those two chips as more of a technology preview/proofs of concept anyway. They're available in exactly one version each, both with pretty anemic flash and memory sizes, and some of the documentation for the D2000 is available only if you're an Intel industry partner. There's also no D1000 board for sale to the general public, even though there's mention of one in the documentation.

author: technix
author_rank: Super Contributor
timestamp: October 17, 2016, 02:15:52 am
content: Quote from: andersm on October 16, 2016, 05:05:14 pmGCC may not be aware of the instructions cut from normal i586 architecture.

author: andersm
author_rank: Super Contributor
timestamp: October 17, 2016, 04:35:35 am
content: Quote from: technix on October 17, 2016, 02:15:52 amIntel's ownSystem Studiouses GCC. The -msoft-float and -mno-fp-ret-in-387 options should be enough to suppress generation of floating-point instructions, though I assume FPU emulation is also possible.

author: legacy
author_rank: Super Contributor
timestamp: October 17, 2016, 08:56:38 am
content: and people can actually livewithout blathering -G-C-C-*in every topic*, ain't it?long life and prosper

author: technix
author_rank: Super Contributor
timestamp: October 17, 2016, 10:38:48 am
content: Quote from: legacy on October 17, 2016, 08:56:38 amSo what is your problem with GCC?GCC and clang/LLVM are probably the two best free (both as in beer and as in speech) compilers out there, and those are also the two compilers that almost always implement the latest language standards and features. There are more companies and government agencies than you can imagine out there that uses and supports those projects.

author: EBRAddict
author_rank: Contributor
timestamp: October 17, 2016, 01:34:01 pm
content: In case nobody pointed this out there are a couple issues that I've found with the Raspberry Pi 3 B GPIO: the UART/serial port doesn't function out of the box because the Bluetooth peripheral took it. To use UART you have to enable a secondary peripheral and slow down the system clock for it to work. Also, the I2C/smbus does not support clock stretching.BeagleBone Black/Wireless/Green may be a linux alternative (albeit with much smaller community support).I like the Pi and have several, but when I need GPIO I find myself reaching for an Arduino or a PSoC.

author: legacy
author_rank: Super Contributor
timestamp: October 17, 2016, 01:34:42 pm
content: Quote from: technix on October 17, 2016, 10:38:48 amit's annoying since a while, dudeit's so f*cking annoying to hearthe same record again, and againyou are making me round likea record, round round roundwhat's your problem about life?money? girls? wife? ….

author: legacy
author_rank: Super Contributor
timestamp: October 17, 2016, 01:41:04 pm
content: Quote from: EBRAddict on October 17, 2016, 01:34:01 pmyeah, for those things we'd better go for theYUNapproach

author: farsi
author_rank: Regular Contributor
timestamp: October 17, 2016, 02:55:02 pm
content: just to add that a list of getting started with embedded unix boards is here:http://embeddednodejs.com/sbc/- I can confirm that the plug and play experience of the upboard (with ubilinux) was quite goodhttp://www.up-board.org/

author: technix
author_rank: Super Contributor
timestamp: October 17, 2016, 06:20:37 pm
content: Quote from: legacy on October 17, 2016, 01:34:42 pmSo what is YOUR problem then? Way too much money or girls? I'd happy to take some if you'd like to share, then maybe I can stop being a cheapskate and start looking into those costly tools you are so fascinated about.Even for basic C support paid tools like Keil or IAR is lacking. C99 support is just added and if your code calls for C11, well dream on. By the way, even Keil have gave up on their own compiler as there is not going to be any ARMv8-M support in their own compiler, and if you target ARMv8-M in uVision 5 you ended up using clang/LLVM. A modified version, but silll based on the open source LLVM code.

author: ataradov
author_rank: Super Contributor
timestamp: October 17, 2016, 06:31:59 pm
content: Quote from: legacy on October 17, 2016, 06:30:12 pmActually no, you are getting into every thread and bash GCC.

author: legacy
author_rank: Super Contributor
timestamp: October 17, 2016, 06:43:27 pm
content: Quote from: ataradov on October 17, 2016, 06:31:59 pmoh, really? in this topic it's happening again:title "Taking a C++ class, looking for a C++14 compatible microcontroller to play with"we were talking about *the language itself* (with an interest for some features)and … oh, see, GCC once again is actually the topicso, everything, even the hardware MUST be gcc-compilantbecause blablablablablafsck off, last time I waste my time

author: technix
author_rank: Super Contributor
timestamp: October 17, 2016, 07:02:52 pm
content: Quote from: legacy on October 17, 2016, 06:43:27 pmPoint me to one of your favorite compiler on any architecture that is 1) not based on GCC or LLVM/clang, and 2) supports C++14.If the compiler does not support the language any more talk is BS. And so far the most famous compilers that advertise C++14 support are either GCC, LLVM/clang or a derivative of them. So as of October 2016 talking about C++14 is synonymous with talking about "supported by latest GCC or LLVM/clang"

author: nbritton
author_rank: Frequent Contributor
timestamp: October 18, 2016, 04:41:17 am
content: Quote from: legacy on October 17, 2016, 06:43:27 pmlol, funniest thing I read all day.

author: amyk
author_rank: Super Contributor
timestamp: October 18, 2016, 10:46:08 am
content: Quote from: andersm on October 16, 2016, 04:51:29 pmIt's a 486SX core with some P5 instructions added on. If I remember correctly, many of the diagrams and text in the datasheet were identical to those in the 486 manual, but with the name changed.

author: nbritton
author_rank: Frequent Contributor
timestamp: October 18, 2016, 07:17:46 pm
content: Quote from: andersm on October 16, 2016, 05:05:14 pmIt exists, but apparently it's not available to the general public...http://www.cnx-software.com/2015/11/10/intel-quark-d1000-customer-reference-board-and-intel-system-studio-for-microcontrollers/The D2000 development kit is available at mouser for $15...http://www.mouser.com/ProductDetail/Intel/MTFLDCRBDAL/?qs=sGAEpiMZZMvzNxwKcL67%252bpwZleYEABNkLLpgXezJXXQ%3d

author: andyturk
author_rank: Frequent Contributor
timestamp: October 19, 2016, 04:53:45 am
content: Quote from: lukier on October 15, 2016, 08:45:14 pmI've never spoken to Linus, but spent some time trying to guess at this animosity... and he may have a point. One of the problems with a large distributed project like Linux is making sure that lots of folks are able to contribute. C++ as a language could work against that because it *is* a very complicated tool and can be used so many different ways that one programmer's C++ may be almost unrecognizable to another. That's something Linus probably can't afford.OTOH, a focused team with experienced engineers and the ability to adhere to coding standards can mandate certain restrictions in the C++ they write and do good work. Again, clang and LLVM are a positive example. Google has 100 million lines of C++, so it seems they've found a way to tame the complexity beast too.Where I work, everything from the reset handler on up is written in C++ 11. All that stuff runs on a Cortex-M0, and is a pleasure to work with.

author: nbritton
author_rank: Frequent Contributor
timestamp: October 20, 2016, 06:36:23 am
content: Quote from: andyturk on October 19, 2016, 04:53:45 amI have spoken to Linus, but I can't speak towards his animosities. However, I would hazard to guess that it's 99% historical reasons. Ken Thompson, Dennis Ritchie, et. al. wrote Unix in C for the PDP. The source code to Unix was then distributed throughout academic circles and this developed into it's own variant of Unix called BSD. Many flocked to this because the source code was open and it had first mover advantage at the time prior to the AT&T lawsuit. Had there not been the lawsuit I'm not sure Linux would even be around, but that's another story. Anyways, universities would teach their CS students about Unix because the source code was accessible, if you had a license. However, Unix grew into a beast so then Minix came along out of the need to simply teaching concepts for students, but I think it cost money etc. Anyways, along comes Linus and if I recall correctly he couldn't afford or was otherwise unable to get a license for Minix, so he said screw it and started banging away on the code for Linux. This was just as the Internet was blossoming, so this good timing combined with the AT&T lawsuit made Linux take off and the rest is history. The majority of the reason it's written in C is simply due to inertia from the original implementation of Unix.https://en.wikipedia.org/wiki/History_of_Unix#/media/File:Unix_history-simple.svg

author: lukier
author_rank: Unknown
timestamp: October 20, 2016, 09:34:26 am
content: Quote from: andyturk on October 19, 2016, 04:53:45 amThere might be some truth in that, a beginner might use C++ like C, someone on the intermediate level will add classes and then on the advanced level there is template metaprogramming and each of this "styles" looks visually different.Again, as I said before, every developer should know their tools. Maybe I still have some hope when it comes to people, more than you or Linus, so I don't like the idea of resorting to C as a cure for hypothesized incompetence of the contributors.

author: legacy
author_rank: Super Contributor
timestamp: October 20, 2016, 09:59:24 am
content: Quote from: nbritton on October 20, 2016, 06:36:23 amkernels written in pascal or m2 were rejected by developersprobably because of their silly ego-burst attitudesomething that (still?) sounds like-if you are really a man, then your work is written in C,everything else (Pascal?, Modula2?) is a for bitches and kids,ADA is obviously only for those who are in the Army-I have seen this attitude in person, different times

author: legacy
author_rank: Super Contributor
timestamp: October 20, 2016, 10:35:41 am
content: Quote from: nbritton on October 20, 2016, 06:36:23 amalong the way, from the academic circlesto big irons, the arise of commercial UNIXsthings like IRIXtheDASHbackstage, both hardwareand software side, is also interesting

author: tggzzz
author_rank: Super Contributor
timestamp: October 20, 2016, 10:37:21 am
content: Quote from: lukier on October 20, 2016, 09:34:26 amYeah, that's wonderful in theory but, in this case, doesn't work in practice:even the language developers didn't understandwhat they were specifying until their noses were rubbed in it.What chance have mere application developers got?I remember watching two indicative cases happen: the discussions over severalyearsat to whether "casting away constness" should be allowed or forbidden, and theunintendedpower of templates.The latter is hilarious:QuoteThat's fromhttps://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMPwith my emphasis added. The original is athttp://www.erwin-unruh.de/primorig.htmlNote: notdesigned, butdiscovered- and that's exactly what happened.The former merely indicates that the language features are very problematic. If you allow "casting away constness", then you allow the compiler to break invariants specified by the programmer. If you forbid "casting away constness" then you prohibit a significant number of useful optimisations. The choice of safety over performance is irreconcilable in this case; hence the length of the discussions in the C++ committees.Apart from that, the information in the FQA is directly relevant and should not be ignored.http://yosefk.com/c++fqa/There are veryveryfew programmers that understand all the pitfalls therein. And that's a big problem with the tool.

author: legacy
author_rank: Super Contributor
timestamp: October 20, 2016, 11:11:59 am
content: Quote from: lukier on October 20, 2016, 09:34:26 amyes, C++ comes with the feature of being "typed" without the price to pay of being pascal-like,therefore as "step ahead" (the "++" in the name) it's cool for those who hate the other way,and you can use C++ to check if your (legacy) C code is goodthe C++ verbosity is even better than pedantic warnings in C

author: legacy
author_rank: Super Contributor
timestamp: October 20, 2016, 11:17:43 am
content: Quote from: tggzzz on October 20, 2016, 10:37:21 amagree, my reason to use just a subset

author: legacy
author_rank: Super Contributor
timestamp: October 20, 2016, 11:36:31 am
content: umm, taking a step back to exceptions,in C++11, what makes the difference isthe "nothrow" keyword

author: legacy
author_rank: Super Contributor
timestamp: October 20, 2016, 11:47:23 am
content: one of the things I don't like about C++well, exceptions in C++ are "unchecked"I mean, if you don't specify which exception can be raisedvirtually every function and method can raise an exceptionthe problem is: which one? don't you know? so, bad things might happenand if they might happen, give them a probability, and they will!exceptions are an attempt to recover the system fom a tollerable failurebut with unchecked exceptions the whole system can have a crashthey add a probability of disaster. Not Good"nothrow" says nothing can be raised. Goodand we came back into the deterministic way

author: tggzzz
author_rank: Super Contributor
timestamp: October 20, 2016, 01:50:12 pm
content: Quote from: legacy on October 20, 2016, 11:17:43 amA valid response.Next you have to determine whetherallthe libraries use a compatible subset, for whatever definition of "compatible" is relevant for your application. And that's not trivial

author: tggzzz
author_rank: Super Contributor
timestamp: October 20, 2016, 01:55:52 pm
content: Quote from: legacy on October 20, 2016, 11:11:59 amNot in anyreliableform, unfortunately.The data in memory is untyped. Sure, the variable names in the source code can be typed, but that can - and often is - defeated via casting.Plus, of course, downcasting is a killer: what's the type of "void *"? Yes Virginia, you can cast aCamel into aHorse.

author: tggzzz
author_rank: Super Contributor
timestamp: October 20, 2016, 02:01:05 pm
content: Quote from: legacy on October 20, 2016, 11:47:23 amYes.Curiously in the Java ecosystem there is a move towards unchecked exceptions. The "rationale", and I use that word loosely, is that exceptions are a pain and usually all we can do is abort, so just wrap your code in catchall.But my opinion is that checked exceptions are a good way to improve a codebase, because they force a function's client to understand the ways in which it might fail and design accordingly. Even if that design is to abort, it is clear what is happening.

author: lukier
author_rank: Unknown
timestamp: October 20, 2016, 02:25:36 pm
content: Quote from: tggzzz on October 20, 2016, 10:37:21 amI've heard that story. On one hand it might be worrying, on the other hand I find it fascinating that something in CompSci can be "discovered". And TMP is a wonderful and rather unique feature (Generics from C# or Java are no match). Of course it can be abused, for example I consider Boost Spirit purely academic exercise, as the compile times and binary sizes are not acceptable. But it doesn't prove TMP useless and someone with less academic bent can do EBNF parser in a more usable and lightweight form, e.g.http://www.gbresearch.com/axe/which I even once used on STM32F4 to parse G-code.Quote from: tggzzz on October 20, 2016, 10:37:21 amI think some gaps in type safety and casting away constness actually come from C backwards compatibility. As I said before, I would prefer a rock solid type system from Ada, but I don't use Ada because there are not so many libraries, while in C++ I have awesome C++ libraries (AXE mentioned above, Eigen algebra, Boost/STL etc) and I can use the outcomes of decades of C development (thousands of libraries) if I have to. Pros and cons always.Quote from: tggzzz on October 20, 2016, 10:37:21 amFQA has some valid points, but the author seems really bitter and writes in a manner indicating that C++ is the source of all evil. Other languages have bugs and loopholes too. In C++ I was always perplexed why std::fstream takes const char* for the filename, while STL provides std::string class. Not very consistent. In C for example, think of thousands of security bugs caused by unsafe C standard library functions (for example buffer overflows in gets, scanf, or strtok) and general C attitude encouraging void* and pointer arithmetic (in C++ I always prefer references if I can and containers checking range). I bet there are silly things hiding in C# or Java, but I don't follow these languages much.Anyway, in any language one should know the limitation, bugs, workarounds and other idiosyncrasies. That's why I don't get the argument that writing Linux in C will lead to better code. Bad C++ programmers will abuse type safety, won't catch exceptions and overdo TMP, bad C programmers will be leaking memory everywhere, creating buffer overflows, because they don't know about e.g. snprintf and invent a horrible meta-language in C preprocessor macros.

author: tggzzz
author_rank: Super Contributor
timestamp: October 20, 2016, 02:38:02 pm
content: Quote from: lukier on October 20, 2016, 02:25:36 pmAgreed, templates are not useless and are more powerful than those in Java/C#. But that wasn't the point I was making.The key issue is that the language is so baroquely complex thatnobodyunderstands it - even the designers. That is the sign of a poor tool.QuoteI was an early Java adopter 20 years (gulp) ago, and still flip between Java and C as appropriate.Back then I was pleasantly surprised at how many libraries from many different sourcesrapidlyappeared andall functioned together. That hasneverhappened with C/C++, even now.QuoteYes, but even thedesignersdon't understand all the interactions - let alone mere mortal developers. Hence your wish that programmers should know their tool willneverhappen with C/C++ can only be a wish; meanwhile back on planet Earth...The FQA isn't the only document to that effect - you can search the usenet archives for the experiences of those that took part in the standardisation committees in the 90s and later. Their experiences, and they know far more than me, made me realise that C/C++ was becoming very problematic. Subsets are less problematic, but they have their own problems.

author: legacy
author_rank: Super Contributor
timestamp: October 20, 2016, 04:09:55 pm
content: to whom is interested in some old stories:Quote from: tggzzz on October 20, 2016, 02:38:02 pm2001? do you remember the effort of thoselikeDallas Semiconductor(Maxim) had putin the direction of tini-java/390 platform?under the cost of 40 UKP, it was famousinUnited Kingdombecause used in some britishcomputer science campus whose articles wereabout weather stationshow to implement your own, able to be sendand receive remote data from the internetJava mixed with C/C++, gold ages

author: tggzzz
author_rank: Super Contributor
timestamp: October 20, 2016, 04:41:22 pm
content: Quote from: legacy on October 20, 2016, 04:09:55 pmIt rings a vague bell, but then I sort-of-vaguely remember many "small Java" platforms.

author: nbritton
author_rank: Frequent Contributor
timestamp: October 21, 2016, 05:00:46 am
content: https://www.geekbooks.me/book/view/real-time-c-plus-plus-1https://www.geekbooks.me/book/view/raspberry-pi-computer-architecture-essentialshttps://www.geekbooks.me/book/view/exploring-the-raspberry-pi-2-with-c-plus-plus

author: legacy
author_rank: Super Contributor
timestamp: October 23, 2016, 06:54:51 pm
content: CppCon 2016: Jason Turner "Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17" OMG

author: John Coloccia
author_rank: Super Contributor
timestamp: October 23, 2016, 07:28:32 pm
content: Quote from: nbritton on October 20, 2016, 06:36:23 amHe's written about it, but honestly his arguments don't really hold any water except for the one that goes, "It's too easy for bad programmers to write exceptionally bad C++ code." My words, not his, but sums it up nicely.I can personally think of a lot of things I don't like about C++. I'm not a huge fan of STL, though it's workable. Could be better. I personally think that multiple inheritance is completely unnecessary and causes way more trouble than it's worth. The interface model is better. Exception handling is cute, though it often gets used as a somewhat safe goto instead of an exception handler. Heavens, I can go on and on. It takes a bit of maturity to use C++ properly and I personally would not want to lead a project with a bunch of volunteers hacking away at C++.But as a professional tool with competent people in charge? It's really quite good and powerful, and simplifies things enormously.

author: lukier
author_rank: Unknown
timestamp: October 23, 2016, 08:29:24 pm
content: Quote from: legacy on October 23, 2016, 06:54:51 pmVery nice talk, demonstrating live how nice the output assembly can be with compile time constructs, TMP, inlining and other C++ features, all without loosing the clarity of the original source (think how readable and testable it would be if peppered with inline assembly or if done as a one huge C function with macros). And it would only get better with proper compiler backend for a particular architecture. I think this proves that C++ is perfectly fine for embedded, one cannot get more embedded nowadays than 6502

author: timb
author_rank: Super Contributor
timestamp: October 23, 2016, 08:30:06 pm
content: Quote from: legacy on October 23, 2016, 06:54:51 pmHoly shit, that was kind of amazing! Who would have thought to compile for i386 and then run the result through an x86 to 6502 reassembler... Thanks for posting that!

author: Bruce Abbott
author_rank: Frequent Contributor
timestamp: October 23, 2016, 08:57:11 pm
content: Quote from: lukier on October 23, 2016, 08:29:24 pmThe 'clarity of the original source'?Explain howCode:*reinterpret_cast<uint8_t*>(53280) = 1;is clearer thanCode:lda #1sta 53280

author: lukier
author_rank: Unknown
timestamp: October 23, 2016, 09:26:32 pm
content: Quote from: Bruce Abbott on October 23, 2016, 08:57:11 pmI'd rather watch the entire talk before posting.Quote from: Bruce Abbott on October 23, 2016, 08:57:11 pmI won't feed the troll. I'll say that for some reason we have moved from assembly to high level languages in the 1960's. Maybe not everyone got the news.

author: legacy
author_rank: Super Contributor
timestamp: October 23, 2016, 09:32:42 pm
content: Quote from: lukier on October 23, 2016, 09:26:32 pmwell, I would say 1990'sconsidering thatAmigaOS/classic and RiscOS/classicwere both written in assemblyand personally I am back to assemblyyes, right now, 2016(does it sound like "back to the future"like the movie?)

author: legacy
author_rank: Super Contributor
timestamp: October 23, 2016, 09:38:57 pm
content: Quote from: lukier on October 23, 2016, 08:29:24 pmyes, I am considering to move into C++14therefore I am open to this kind of *talk*

author: lukier
author_rank: Unknown
timestamp: October 23, 2016, 09:55:39 pm
content: I have nothing against assembly as such, sometimes some inline might be required (e.g. inline for SSE/AVX accelerations), but no one in a sane mind would write any project of sensible complexity in assembly, not in 2016. I often prefer to inspect the output assembly to see if I could hint the compiler to do better instead of writing inline snippets.Maybe the advantages of the example presented in the talk are not clear to everyone. Let me explain. His memory(...) function with this reinterpret_cast is the only contact point with the hardware. One might call it a minimalistic HAL. The rest is C++ business as usual, readable to anyone familiar with C++ and not necessarily this particular chip assembly language.Also, this is very easy to test. This memory(...) function can be mocked and unit tests can be written in C++ and run on developer's workstation (as there is no inline assembly!) and Continuous Integration systems. In the next step this function might instead interface with SystemC simulation of 6502 or a Cadence simulator - sometimes the hardware is not there yet. Only when hardware reaches FPGA and ASIC levels we can actually run the vanilla code somewhere, and this can be expensive so such testing is done in the later stages and mostly for performance profiling.Additionally, this memory(...) function can be, for some test build type, replaced with a function that does RPC over UART/Ethernet/whatever to the target system running only so called "Monitor" that only reads and writes to memory/peripherals, while the code itself runs on x86.Of course all this testing can be done with C and has been, but may require more ugly constructs (preprocessor macros etc), and with inline assembly it becomes a royal pain. The point here is that it might seem that his game is very abstracted (and this improves testability), with classes, TMP and other C++ tricks, and yet it produces very neat and compact assembly.

author: westfw
author_rank: Super Contributor
timestamp: October 24, 2016, 01:01:20 am
content: Apparently "Embedded C++" is so far from "Real C++" that C++ programmers will sneer at you...http://softwareengineering.stackexchange.com/questions/48401/learning-c-properly-not-c-with-classes(especially: "you should definitely be using all of those self-expanding containers from the STL.")(is there an "embedded STL" that omits dynamic allocation? That might be interesting...)

author: westfw
author_rank: Super Contributor
timestamp: October 24, 2016, 01:09:33 am
content: QuoteHopefully your actual program ends up containing something like:Code:TIMER1_ENA = 1;orCode:lda #1sta TIMER1_ENA

author: legacy
author_rank: Super Contributor
timestamp: October 25, 2016, 07:49:06 am
content: Code:#include <functional>#include <type_traits>template<typename BASE>constexpr bool _isOneOf_f(){return false;}template<typename BASE, typename TEST, typename... TYPES>constexpr bool _isOneOf_f(){return std::is_same<BASE, TEST>::value || _isOneOf_f<BASE, TYPES...>();}template<typename BASE, typename... TYPES>constexpr bool isOneOf = _isOneOf_f<BASE, TYPES...>();template<typename V1>constexpr auto _biggestValue_f(const V1 v1){return v1;}template<typename V1, typename... TYPES>constexpr auto _biggestValue_f(const V1 v1, const TYPES... others){return std::max(v1, _biggestValue_f(others...));}template<typename... TYPES>constexpr auto biggestTypeSize = _biggestValue_f(sizeof(TYPES)...);template<typename TOSEARCH>constexpr int _findTypeIndex_f(const int indexSoFar){return -1;}template<typename TOSEARCH, typename TEST, typename... TYPES>constexpr int _findTypeIndex_f(const int indexSoFar){if(std::is_same<TOSEARCH, TEST>::value)return indexSoFar;elsereturn _findTypeIndex_f<TOSEARCH, TYPES...>(indexSoFar + 1);}template<typename TOSEARCH, typename... TYPES>constexpr int findTypeIndex = _findTypeIndex_f<TOSEARCH, TYPES...>(0);template<typename RETTYPE, typename... ERRORTYPES>class Except{private:char values[biggestTypeSize<RETTYPE, ERRORTYPES...>];int whichIsIt = 0;public:template<typename TYPE,typename = std::enable_if_t< isOneOf<TYPE, RETTYPE, ERRORTYPES...> >>Except(TYPE value): whichIsIt{ findTypeIndex<TYPE, RETTYPE, ERRORTYPES...> }{TYPE *ptr = reinterpret_cast<TYPE*>(&this->values);*ptr = value;}template<typename ERRT,typename = std::enable_if_t< isOneOf<ERRT, ERRORTYPES...> >>Except<RETTYPE, ERRORTYPES...> & when(const std::function<void(const ERRT &)> & callback){if(findTypeIndex<ERRT, RETTYPE, ERRORTYPES...> == whichIsIt)callback(*reinterpret_cast<ERRT*>(&this->values));return *this;}void ok(const std::function<void(const RETTYPE &)> & callback){if(whichIsIt == 0)callback(*reinterpret_cast<RETTYPE*>(&this->values));}};above the attempt of handing exceptions-likewith "exceptions disabled" flag, which soundslike impossible mission, and the arrangementof words & phrases in C++11 seems designedto cause headache

author: John Coloccia
author_rank: Super Contributor
timestamp: October 25, 2016, 01:59:00 pm
content: Quote from: legacy on October 25, 2016, 07:49:06 amIt that from a new STL? Like I said before, I'm not a huge fan of the STL, though it's not particularly terrible for what it does. It's just a little bloated.Anyhow, I'm not sure I really like C++11 either. I think it's trying to do too much. I like C++ as an object oriented extension to C, along with being a more strongly typed language. I like it for embedded and system level programming. IMHO, it misses the mark as a modern language. That's not to say you need a modern language, and C++ is just fine for quite a few things, but trying to turn it into a modern language just doesn't feel like it's working. The syntax and rules just get more and more complex and obfuscated. It's not insurmountable, but I feel like it's counterproductive.

author: tggzzz
author_rank: Super Contributor
timestamp: October 25, 2016, 02:58:20 pm
content: Quote from: John Coloccia on October 25, 2016, 01:59:00 pmYes indeed.C++ tries to be both simple and close to the hardware, and also a high-level language - and fails at both. The give-away is how much youcan'tguarantee, because it is left as "implementation defined".

author: technix
author_rank: Super Contributor
timestamp: October 26, 2016, 03:56:17 am
content: Quote from: tggzzz on October 25, 2016, 02:58:20 pmThat is why there is no unified C++11, rather than separate clang++11 or gnu++11 or msvc++11 or icc++11... (clang++11 and gnu++11 are fairly similar though, as clang try to be a drop-in replacement of GCC)

author: tggzzz
author_rank: Super Contributor
timestamp: October 26, 2016, 07:54:53 am
content: Quote from: technix on October 26, 2016, 03:56:17 amPlus why the behaviour of compiled code can (and does) change when the compiler version changes, and why the concept of a portable library is problematic.

author: legacy
author_rank: Super Contributor
timestamp: October 26, 2016, 11:51:07 am
content: Code:std::mutex myMutex;…{std::lock_guard<std::mutex> guard(myMutex);//critical code...}// lock_guard automatically unlocks the mutexin my spare time I am designing my own languageactually it looks like "--C", but I am grabbing someinteresting feature from C++11, and I like "scopes"I just need to (re)invent the wheel with a bettersyntax

author: technix
author_rank: Super Contributor
timestamp: October 26, 2016, 06:49:31 pm
content: Quote from: legacy on October 26, 2016, 11:51:07 amThis is from Objective-C:Code:@synchronized (mutex_object){// ...[mutex_object canStillBeUsed:NORMALLY];// ...}Themutex_objectcan be any object, not just mutexes.