Have the Embedded world gone ape? 10 years time? - Page 1
Forum section: electronics / general

author: MT
author_rank: Super Contributor
timestamp: October 15, 2015, 12:23:41 am
content: I was reading some of gnassleshttp://www.ganssle.com/rants/timetomoveonfromc.htmso we all know the situation around ST for example but aparently they are not alone and that the whole HAL and Cube faff is more orless the result of truck loads of peripherals. When we look at a MCU silicon today we find far out in the corner a little dot, that's theCPU everything else is memory and peripherals, we all know this.So in 5-10 years from now how will embedded world look like? Will there for example be 2 dollar MCU's containing10 very fast CPU's and only rudimentary interface logic and SW based peripherals? Wouldn't that be nice?All the HAL/CMSIS crap is gone and you can decide your self what kind of peripherals you need and how many.Will this MCU be running ADA since the downsides of C is becoming more and more evident?Your take on this?

author: miguelvp
author_rank: Super Contributor
timestamp: October 15, 2015, 01:18:07 am
content: That article is from 2010, C++ has evolved since then, would we see C++11 on MCUs? probably, ADA not so much but maybe Erlang, Haskell, F#, Scala, or a ton of other functional languages that are coming out of the woods.But C++ is a concurrent and functional language (impure) since C++11.C++14 supersedes C++11 and C++17 is in the works.Of course a lot of programmers are stuck on C and the original C++, but C++11 and even C++14 should be on your list of things to learn soon if you are looking for a job

author: richardman
author_rank: Frequent Contributor
timestamp: October 15, 2015, 01:47:51 am
content: C++ supposed to have taken over C by 2010. It didn't happen.Depending on what you mean by "take over", per my definition (50%+ of market) it will not happen for another 10 years at least.Why? Lots of small devices will be made with Cortex-M0, under $1 today, with 64K flash. Great with C.C++ excels over C with "programming of the large", but while more and more embedded projects will be larger and larger, each piece will be small. Distributed computing, Internet of Thing model.

author: ralphd
author_rank: Frequent Contributor
timestamp: October 15, 2015, 02:00:15 am
content: Ada!? My wife asked why I burst out laughing. Unfortunately she doesn't get humor.

author: richardman
author_rank: Frequent Contributor
timestamp: October 15, 2015, 02:04:25 am
content: Quote from: ralphd on October 15, 2015, 02:00:15 amIt was good for its day :-)I worked for Intermetrics for a couple years after they bought Whitesmiths, and it's amazing: the "old guards" were mostly gone by then, but this was the company that wrote the Space Shuttle software. They built their own optimizing compilers. Talk about quality software - failure isnotan option. Somany stories.

author: Marco
author_rank: Super Contributor
timestamp: October 15, 2015, 02:38:27 am
content: Quote from: miguelvp on October 15, 2015, 01:18:07 amJust what embedded programming needs. GC, asynchronous message passing and lazy evaluation. An unholy trinity of unpredictable memory use and program flow, just need to add some lock free programming to really pile on those impossible to pinpoint bugs.

author: briselec
author_rank: Regular Contributor
timestamp: October 15, 2015, 03:14:27 am
content: going by the 2014 embedded market study, C is still sitting at 60%, C++ has dropped to 19%, and good old assembly language is still ahead of everything else.

author: miguelvp
author_rank: Super Contributor
timestamp: October 15, 2015, 03:20:21 am
content: The OP is talking on the hypothetical future of multicore MCUs, which happens to be the direction hardware is currently going since we are hitting the limit on how long it takes the information to travel the silicon, so the solution is either going 3d, but that just helps only a little, or adding more cores.Quote from: MT on October 15, 2015, 12:23:41 amCurrent mobile chips already feature 8 cores or more. Will embedded MCUs follow that trend? that's the question at hand.Myself I don't think that is going to happen in the next decade since 5-10 years is really not that big of a span of time to affect the MCU industry, but we are already seeing the migration to lower voltage cores and once they hit 200mV the only way to make more efficient and low power processors would be to add more cores.Not sure what the physical limits are but 5GHz at 200mV core voltage rings a bell, so it's going to take more than 10 years in my opinion for this paradigm shift to affect MCUs.The problem then will be that the hardware would surpass what the programmers can make use of the device using C or similar sequential oriented programming languages, maybe you can use 10 cores and keep them busy doing 10 separate tasks but what happens with 20, 50, 100, 1000 cores all with shared memory and resources? That's when functional and concurrent languages will come to play.Again, I don't know if that will happen at the embedded level in the next 10 years, that sounds too aggressive of a timeline, but it will happen at the desktop and mobile level and it's going to be hard to make use of all that computer power with legacy sequential oriented languages.Sooner or later, however, it will be the same paradigm shift for MCUs.Fortunately a lot of people are dealing with HDL and are no strangers to concurrency versus sequential thinking. After all we are born as concurrent beings and we have to unlearn our instincts in order to learn sequential languages.But whatever the future brings we will adapt.

author: MT
author_rank: Super Contributor
timestamp: October 15, 2015, 03:39:57 am
content: QuoteIt would be strange if it did not.QuoteWell diamond and graphene substrate is not to far away, progress have been made.QuoteTiny local memories and one large main memory, i mentioned ADA now i'm going to mention FORTH, yes you can laugh now!http://www.greenarraychips.com/144 CPU's is a interesting case.Also is Samsung Exynos5422 Cortex™-A15 2Ghz and Cortex™-A7 Octa core CPUs

author: westfw
author_rank: Super Contributor
timestamp: October 15, 2015, 05:25:25 am
content: QuoteIt's been tried, mostly not very successfully. Bitslice microcoded machines, Scenix/Ubicom chips, XMOS, Parallax Propeller, Atmel FPSLIC, Cypress PSoC, and probably others. And no, it wouldn't be particularly nice; the hardware to implement a UART or Ethernet controller is far simpler (and less power hungry) than the processor that can implement it in SW. And for every programmer or business that cries over the inefficiency of a vendor library, there are probably 10 that are happy enough to throw more clocks and memory at their product (because THEY scale easily enough (so far), while peripheral complexity keeps going up. And that's for the simple peripherals; by the time you get to gigabit ethernet, wifi, USB, Bluetooth, or TCP/IP, there are VERY FEW companies or people who are prepared to implement things from scratch (compared to a known-quantity library that everybody uses.)

author: Mechatrommer
author_rank: Super Contributor
timestamp: October 15, 2015, 06:40:59 am
content: Quote from: miguelvp on October 15, 2015, 03:20:21 amwhy the "Current mobile chips already feature 8 cores or more" is not called embedded MCU? i will be surprised if its not.Quote from: MT on October 15, 2015, 12:23:41 amwhy you want parallel computing with minimal IOs? the IOs need to be scheduled anyway and parallel computing will reveal its superiority in time consuming and complex algorithms. how many applications that call for this? cant the existing FPGA or the bigger multicored mcu deal with it? probably imho only in very specific, serious and expensive application, the margin thats not worth trying? the only advantage i can see is miniaturization but... in a very specific task miniaturization is not a critical motive, most of them are big big machines with abundant of IOs...Quote from: miguelvp on October 15, 2015, 03:20:21 amwe are both concurrent and sequential beings.. the task of cognition is concurrent, the task of intelligence or decision making is sequential...ps: i should get a life again...

author: ale500
author_rank: Frequent Contributor
timestamp: October 15, 2015, 06:41:51 am
content: Software peripherals ?... You have the Parallax Propeller with 8 processors and you have XMOS chips with 1 or 2 cores and up to 8 threads per core... both with software peripherals, today. The cheapest XMOS chip costs like 2 $, one core and 4 threads. There is also GreenHills massive 144-core forth uC, also with software periphs.

author: miguelvp
author_rank: Super Contributor
timestamp: October 15, 2015, 06:55:58 am
content: Quote from: Mechatrommer on October 15, 2015, 06:40:59 amCortex profile abbreviations:Cortex-M is for microcontrolers.Cortex-R is for real timeCortex-A is for application (mobile chips are on this category)I'm not the one deciding to not call them MCUs, ARM made that decisionBut I digress, mobile chips are more of a systems on chip and they come with integrated GPUs, USB, HDMI, PCIe, etc, etc, etc. So it's not just the ARM processor and it's not an MCU.Edit: plus mobile chips do run an OS.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: October 15, 2015, 07:08:24 am
content: Predict the future? We cannot even predict the weather for tomorrow!I would like to see more versatile MCU with programmable (FPGA style) port logic - hybrids. This would allow designs to become even smaller and allow us to put IoT stuff in every nook and cranny. But I'm sure it has other uses as well.And if you go there - do you also need some integrated language to describe it? At first probably not.The other thing is parallelism. I don't see 1000 core MCUs being manufactured any day soon, but multi cores are already available. I do think a level of abstraction over that would be very beneficial. That way those cores can be utilized effectively and easily without chances of too much thread-safety issues.IDEs can use some love too. I still cannot use unit tests or have source control in Atmel Studio for instance. These people are from the Dark Ages. I think the more software is running on MCUs the more the EEs have to become Software developers. Embedded has its own share of specific requirements for sure, but good software development practices (test and release process) is mandatory. So with the next generation of MCUs should also come the next generation of IDEs. Perhaps they should stop each trying to develop their own and combine the efforts in a plug-in based model like eclipse for instance? Then all the effort can go into building the actual tool and not the shell and the printing and the etc.

author: miguelvp
author_rank: Super Contributor
timestamp: October 15, 2015, 07:32:12 am
content: Hard core FPGAs are already around.For example this one:http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=205&No=941which I did buy but didn't have a chance to play with it yet other than running some demo software. It has a 925MHz Dual-core ARM Cortex-A9 hard core processor on it.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: October 15, 2015, 08:52:00 am
content: Using that for most IoT-ish projects is like buying a super computer to run a word processor program...

author: Kalvin
author_rank: Super Contributor
timestamp: October 15, 2015, 10:32:58 am
content: C and C++ are the cancer of the (embedded) computing. If the C / C++ would adopt Ada's strong type checking and runtime range checking, C/C++ would be quite usable languages for production work. And the macros with side-effects create quite often bugs that are hard to spot.Although Linux is an example of a large-scale C project, even Linux would benefit for improved type checking, range checking etc.Ada-like strict type checking won't cost a thing as it will performed at compilation time. The runtine-checks can be enabled or disabled as needes per module so the impact of the runtime-checks are well controlled. Runtime exception handling is not necessary to keep things simple and avoid code-bloat and it can be handeled by a general trap-function which will be invoked when something nasty happens, print the error location and restart the device.Yes, I have been using C and C++ for the past 20+ years and will use it for the another 20 years for fun and profit. The more I use C/C++ more I see their weaknesses. I have seen too much of badly written C/C++ code and seen too many bugs resulting from the poorly designed languages that I cannot appreciate those languages very much. Unfortunately the reality is that decent C compilers are available for the most microcontrollers on the market for free, so the C/C++ nighmare will not go away anytime soon.

author: tszaboo
author_rank: Super Contributor
timestamp: October 15, 2015, 11:41:51 am
content: Quote from: miguelvp on October 15, 2015, 03:20:21 amI dont think so. In fact, the market is going the opposite direction. Since it is cheaper and cheaper to put a core into your asic, we are basically outsourcing the MCU intensive tasks to the peripherals. The radio chip has an on-chip MCU. The USB controller has an on-chip MCU. The I2C extender is an MCU. The LCD controller has a built in controller, and it connects to the MCU with SPI instead of a parallel interface. They already make digital power management chips, with onboard logic.The way I see it, it will be small microcontrollers distributing the tasks into smaller chunks which are easy to write, easy to handle. Why would you need a big FPGA to do all these stuff? Interfaces are standard, and MCUs come with dozen SPI, I2C, USART.

author: tggzzz
author_rank: Super Contributor
timestamp: October 15, 2015, 12:47:04 pm
content: Quote from: NANDBlog on October 15, 2015, 11:41:51 amYes. As I'm sure you are aware, the main reasons for using an FPGA are tight latency/time constraints or in-chip throughput and/or tight coupling with processors, e.g. Zynq.Message-passing (in all its myriad incarnations) will become the dominant communications paradigm because it is robust and scalable from high-performance computing, through cloud computing, through multi-core programming, to the kind of heterogeneous embedded systems you outline.C is sufficient for such message passing. C++ is evolving to look like a badly specified and poorly implemented C# wannabe.How long was it before acompleteC++98 compiler emerged? ISTR an email trumpeting it in about 2005, but maybe it was for acompleteC99 compiler. seehttp://yosefk.com/c++fqa/

author: Mechatrommer
author_rank: Super Contributor
timestamp: October 15, 2015, 02:19:33 pm
content: Quote from: Kalvin on October 15, 2015, 10:32:58 amyoung kids always think they have more than enough... i mean cpu resources.. btw, there are few modern languages that fit your criteria, go get it. hint basic, java, python? etc... i'm tired of C/C++ vs another languages fight BSdont get me wrong i dont treat C/C++ as holy but there are lot more important things than that really...

author: MT
author_rank: Super Contributor
timestamp: October 15, 2015, 03:17:16 pm
content: Quote from: Kalvin on October 15, 2015, 10:32:58 amOh! i need that one, right now!

author: ale500
author_rank: Frequent Contributor
timestamp: October 15, 2015, 05:00:23 pm
content: QuoteDid you hear about MIRSA ?, that seems to be the answer of the "(automotive) industry" to your exact requirement... instead of building a MISRA-C compiler, they go for a check after you write.... sorry but that is an abomination

author: obiwanjacobi
author_rank: Super Contributor
timestamp: October 15, 2015, 05:01:47 pm
content: Are you talking about static code analysis?

author: Lukas
author_rank: Frequent Contributor
timestamp: October 15, 2015, 06:58:40 pm
content: I'm wondering why no one mentioned Rust. I haven't played with rust yet, but it looks really promising in terms of features. (Automatic memory management, no GC, type safety, strong type system, etc)

author: westfw
author_rank: Super Contributor
timestamp: October 16, 2015, 03:22:34 am
content: I see that TI has a chip (AM437x) with a single GHx ARM A9 core and four "PRU-ICSS" Progrogrammable Real-time Unit and Industiral Communications Subsystem" and NXP has asymetric multicore chips (CM4+CM0); so we'll have to keep an eye on how those do vs more conventional multi-core chips. My experience suggests that SW engineering teams are lazy and would rather not keep track of two different kinds of code.

author: ale500
author_rank: Frequent Contributor
timestamp: October 16, 2015, 05:52:56 am
content: They are a bit more than static code analysis, or they pretend to be...

author: andersm
author_rank: Super Contributor
timestamp: October 16, 2015, 06:36:12 am
content: Quote from: Lukas on October 15, 2015, 06:58:40 pmIt's too new, and not there yet. Last time I looked at it, it seemed like one person had managed to build a "Hello world"-style app for a microcontroller. Maybe the situation has improved since then, but C++14 combined with theCore GuidelinesandGuidelines Support Librarywill provide most, if not all, of the features of Rust. Some of the guideline checkers will be implemented in the next update of VS2015, I don't know if GCC has started implementing them yet.For an introduction to the core guidelines, watch Bjarne Stroustrup's CppCon talk "" and Herb Sutter's talk "."

author: Marco
author_rank: Super Contributor
timestamp: October 16, 2015, 06:48:36 am
content: Does it have runtime bounds checking by default?

author: bson
author_rank: Unknown
timestamp: October 16, 2015, 08:32:01 am
content: I do tend to agree it's a little out of hand...The technical reference manual for the new TI Sitara AM572x is about 7000 pages. That's just insane!Seven. Thousand.http://www.ti.com/lit/ug/spruhz6d/spruhz6d.pdfThe AM5728 is powering the new BeagleBoard X15 -http://www.elinux.org/Beagleboard:BeagleBoard-X15This looks like a nice evaluation kit without the need to try to cobble together an initial boot image from a BSP that barely even cross compiles. (Xilinx, looking at you.)I like how TI is embracing gcc and open source. They even added mainline gcc support for the C66x DSP (which the AM5728 has two of in addition to the two Cortex-A15 andfourCortex-M4 cores, and the two oddball real-time PRU cores).

author: Kalvin
author_rank: Super Contributor
timestamp: October 16, 2015, 01:33:15 pm
content: Quote from: Mechatrommer on October 15, 2015, 02:19:33 pmStrong type checking is a compile-time feature which doesn't consume any extra cycles on the target processor. The runtime checking will add extra cycles and increase the code size, but the runtime checking can be enabled and disabled as needed, so the impact can be controlled.Quote from: MT on October 15, 2015, 03:17:16 pmWell, if you do not need that or understand what the feature implies, it doesn't mean that the feautre is useless. Do you think that it is better that the software continues its execution as if nothing has happened even if something nasty happens - like an array index overflows, variable value overflows etc - or should the system or an application print an error message to the debug interface, reset and try to recover?Quote from: obiwanjacobi on October 15, 2015, 05:01:47 pmStatic code analysis is almost useless in C/C++ due to the fact that the language itself has very weak type system. Static analysis is more useful in the languages in which the type checking and type declarations are more specific about the numeric range etc. For example, SPARK is a subset of Ada language and it can perform extensive static analysis of the program code. SPARK's ultimate aim is to be able to prove the software mathematically correct. I do not know SPARK enough so that I could go into details.Quote from: ale500 on October 15, 2015, 05:00:23 pmMISRA contains good set of rules for avoiding the bad features of C/C++. MISRA is an attempt to fix broken language by limiting the allowed constructs and giving rules, guidelines and recommendations on how to write better and safer programs in C/C++ language. Like you said, there are compilers available that will validate whether the source code adheres MISRA's rules and recommendations. Even the GCC will check the source code for possible problems by enabling all warnings.

author: lod
author_rank: Contributor
timestamp: October 16, 2015, 01:36:23 pm
content: Quote from: MT on October 15, 2015, 12:23:41 amI suspect that the market will continue much as it is, you can roughly divide this into three groups.1. Very cheap 8bit micros, like the Atmel AVR. ARM will probably remain at the upper end of this space.2. Decent sized ARM chips running a full OS like Linux. These will have a range but I expect in ten years even the bottom end will be multiple cores with a solid amount of RAM thrown in.3. Flexible programmable hardware with cores, such as FPGAs and Cypress PSOC chips.You can roughly break the current market up like this at the moment. I think over the next ten years there will be movement between the categories, Intel is playing with introducing programmable logic into CPUs and I expect to see specialised elements like GPU cores in FPGAs for floating point or massively parallel tasks. You can also expect to see continuing advances in power usage, probably the hardware and OS working together to do things like shut down chunks of ram or peripherals when idle.The programming language question is I feel a bit misguided because it depends on the micro. The cheap micros will continue to be ASM/C/C++ as there are substantial advantages to being very close to the hardware, probably shifting towards C over time. The big core systems run a full OS, once you take that step the system will probably involve multiple programs written in whatever language best suits the task.

author: MT
author_rank: Super Contributor
timestamp: October 16, 2015, 01:39:48 pm
content: Quote from: bson on October 16, 2015, 08:32:01 amSay it with emphasis, like this!SEVENTHOUSANDPAGES........That's just INSANE!With more cores and less pheripherials the manuals will indeed shrink! The focus as of today... why-dont-my-pheripherial-work will'then shift to why-dont-my-function-work.....and endless debates about how a particular function is correctly implemented...with references to incomplete language standards....I wonder what Agatha Christie would have tought about todays product manuals?!

author: VEGETA
author_rank: Super Contributor
timestamp: October 17, 2015, 10:04:10 am
content: QuoteIf it is not over 9000, then it is normal. However, if it is over 9000, then:_______moving to:QuoteHe mentioned this without saying what does he hate about C. He himself said over 90% of developers use C... That can not be purposeless I guess.

author: Marco
author_rank: Super Contributor
timestamp: October 17, 2015, 05:37:09 pm
content: Quote from: VEGETA on October 17, 2015, 10:04:10 amWe're lazy and the market isn't very good at punishing long tail failures.

author: miguelvp
author_rank: Super Contributor
timestamp: October 17, 2015, 05:52:58 pm
content: Quote from: Marco on October 17, 2015, 05:37:09 pmNot only that but he is probably salty because C++ programmers are the top paid ones.

author: VEGETA
author_rank: Super Contributor
timestamp: October 17, 2015, 09:43:11 pm
content: Quote from: miguelvp on October 17, 2015, 05:52:58 pmCan you explain why is that?I mean, someone who program MCUs like PIC or ARM ones using C, he does the job right. What is the difference between programming it in C and C++?

author: CosPhi
author_rank: Regular Contributor
timestamp: October 17, 2015, 10:41:44 pm
content: Quote from: obiwanjacobi on October 15, 2015, 08:52:00 amBelkin uses Linux for a light switch.http://www.belkin.com/us/p/P-F7C030/Sadly they forgot there private PGP for code signing key on it and the passphrase toohttp://arstechnica.com/security/2014/02/password-leak-in-wemo-devices-makes-home-appliances-susceptible-to-hijacks/Please guys don't develop such things ...Recently I got a air conditioner for a machine cabinet ... how to set the temperature? No, not with buttons ... first load software on the Notebook and connect over USB... at the same time I deleted "Pfannenberg" from my vendor list, there are others too.

author: miguelvp
author_rank: Super Contributor
timestamp: October 18, 2015, 05:57:02 am
content: Quote from: VEGETA on October 17, 2015, 09:43:11 pmI wouldn't use C++ for an MCU like PIC or and ARM Cortex-M. I was just stating that in general programming C++ is the highest paid one.Why? it seems C++ has the best ratio of productivity, performance, resource overhead, re-usability and large team friendly.Just the performance of task per watt makes it most cost effective. Memory is a one time cost so it doesn't matter much

author: andersm
author_rank: Super Contributor
timestamp: October 18, 2015, 11:09:53 am
content: Quote from: miguelvp on October 18, 2015, 05:57:02 amThere's (AFAIK) no C++ compilers for the 8- and 16-bit PICs, but there's nothing preventing its use on either PIC32s or Cortex-Ms.

author: janoc
author_rank: Super Contributor
timestamp: October 18, 2015, 11:37:58 am
content: Quote from: andersm on October 18, 2015, 11:09:53 amThere are also some other reasons why you may not want to use C++ for MCU development. Unless you really need the OOP machinery with classes, inheritance, templates and what not you are only imposing a significant compilation time and code size overhead (the C++ runtime) on yourself with few to none benefits over straight C. You don't need things like operator overloading or classes for twiddling bits on a port or to drive an SPI peripheral.

author: c4757p
author_rank: Super Contributor
timestamp: October 18, 2015, 12:05:00 pm
content: Do us a favor and compile a bit of test code for your favorite platform in both C and C++ modes, optimization at least -O1 and -flto if available, and see if there is any overhead for the "runtime". A great many useful C++ features addnoneon any I have used, or no more than you would use to implement the feature yourself.This is an old myth on all but the shittiest compilers.

author: c4757p
author_rank: Super Contributor
timestamp: October 18, 2015, 12:55:40 pm
content: Here, I'll compile some things for AVR, using various C++ features, and show you what the overhead is.First, a quick test to make sure there isn't any overhead in just switching to C++. Here's a test, toggling PA0:Code:#include <avr/io.h>int main(void){VPORT0.DIR = 0x01;for (;;) {VPORT0.OUT |= 0x01;VPORT0.OUT &= ~0x01;}}Same file saved as both test.c and test.cpp.Code:% avr-gcc -mmcu=atxmega32e5 -g -O1 test.c -o test.o% avr-size -C --mcu=atxmega32e5 test.oAVR Memory Usage----------------Device: atxmega32e5Program: 210 bytes (0.6% Full)(.text + .data + .bootloader)Data: 0 bytes (0.0% Full)(.data + .bss + .noinit)% avr-gcc -mmcu=atxmega32e5 -g -O1 test.cpp -o test.o% avr-size -C --mcu=atxmega32e5 test.oAVR Memory Usage----------------Device: atxmega32e5Program: 210 bytes (0.6% Full)(.text + .data + .bootloader)Data: 0 bytes (0.0% Full)(.data + .bss + .noinit)So no increase there.Let's try some C++ features, shall we? Using a templated class to wrap a pin:Code:#include <avr/io.h>#include <stdint.h>#define VPORT(addr) ((VPORT_t*)(addr))template<intptr_t vport, uint8_t npin>class VPortPin{public:void init(void) {VPORT(vport)->DIR |= (1 << npin);}bool operator=(bool rhs) {if (rhs) {VPORT(vport)->OUT |= (1 << npin);} else {VPORT(vport)->OUT &= ~(1 << npin);}return rhs;}};int main(void){// Unfortunately gcc or C++ isn't smart enough to handle &(*(a))// in a constant expression. 0x0010 is the address to VPORT0.VPortPin<0x0010, 0> PA0;PA0.init();for (;;) {PA0 = true;PA0 = false;}}Code:% avr-gcc -mmcu=atxmega32e5 -g -O1 test.cpp -o test.o% avr-size -C --mcu=atxmega32e5 test.oAVR Memory Usage----------------Device: atxmega32e5Program: 208 bytes (0.6% Full)(.text + .data + .bootloader)Data: 0 bytes (0.0% Full)(.data + .bss + .noinit)What? It's smaller?? But I thought C++ made everything larger! Let's take a look at the assembly:Code:% avr-objdump -S test.otest.o: file format elf32-avrDisassembly of section .text:**SNIP VECTOR TABLE**SNIP CONSTRUCTORS000000c4 <main>:template<intptr_t vport, uint8_t npin>class VPortPin{public:void init(void) {VPORT(vport)->DIR |= (1 << npin);c4: 80 9a sbi 0x10, 0 ; 16}bool operator=(bool rhs) {if (rhs) {VPORT(vport)->OUT |= (1 << npin);c6: 88 9a sbi 0x11, 0 ; 17} else {VPORT(vport)->OUT &= ~(1 << npin);c8: 88 98 cbi 0x11, 0 ; 17ca: fd cf rjmp .-6 ; 0xc6 <main+0x2>Yup. It was smart enough to boil down the templated class complete with method call and operator overload tosingle instructions,sbi(set bit in I/O) to set the pin,cbi(clear bit in I/O) to clear the pin, andrjmp(relative jump) to loop. The class instance takes no SRAM because it has no variables, and the conditional and return statement and functions calls themselves are removed because everything is known at compile time.Anything else we could test? Ah - how about polymorphism? Let's make a couple subclasses of a virtual parent, and see how it deals with that.Code:#include <avr/io.h>#include <stdint.h>class A{public:virtual void do_thing() = 0;};class B: public A{virtual void do_thing() {PORTA.OUTTGL = 0x01;}};class C: public A{virtual void do_thing() {PORTA.OUTTGL = 0x80;}};int main(void){B b;C c;A *pa_b = &b;A *pa_c = &c;PORTA.DIR = 0x81;for (;;) {pa_b->do_thing();pa_c->do_thing();}}Code:% avr-gcc -mmcu=atxmega32e5 -g -O1 test.cpp -o test.o% avr-size -C --mmcu=atxmega32e5 test.oAVR Memory Usage----------------Device: atxmega32e5Program: 322 bytes (0.9% Full)(.text + .data + .bootloader)Data: 12 bytes (0.3% Full)(.data + .bss + .noinit)% avr-objdump -S test.otest.o: file format elf32-avrDisassembly of section .text:**SNIP VECTOR TABLE**SNIP CONSTRUCTORS000000da <main>:PORTA.OUTTGL = 0x80;}};int main(void){da: cf 93 push r28dc: df 93 push r29de: 00 d0 rcall .+0 ; 0xe0 <main+0x6>e0: 00 d0 rcall .+0 ; 0xe2 <main+0x8>e2: cd b7 in r28, 0x3d ; 61e4: de b7 in r29, 0x3e ; 62{public:virtual void do_thing() = 0;};class B: public Ae6: 84 e0 ldi r24, 0x04 ; 4e8: 90 e2 ldi r25, 0x20 ; 32ea: 8b 83 std Y+3, r24 ; 0x03ec: 9c 83 std Y+4, r25 ; 0x04virtual void do_thing() {PORTA.OUTTGL = 0x01;}};class C: public Aee: 8a e0 ldi r24, 0x0A ; 10f0: 90 e2 ldi r25, 0x20 ; 32f2: 89 83 std Y+1, r24 ; 0x01f4: 9a 83 std Y+2, r25 ; 0x02B b;C c;A * const pa_b = &b;A * const pa_c = &c;PORTA.DIR = 0x81;f6: 81 e8 ldi r24, 0x81 ; 129f8: 80 93 00 06 sts 0x0600, r24for (;;) {pa_b->do_thing();fc: eb 81 ldd r30, Y+3 ; 0x03fe: fc 81 ldd r31, Y+4 ; 0x04100: 01 90 ld r0, Z+102: f0 81 ld r31, Z104: e0 2d mov r30, r0106: ce 01 movw r24, r28108: 03 96 adiw r24, 0x03 ; 310a: 09 95 icallpa_c->do_thing();10c: e9 81 ldd r30, Y+1 ; 0x0110e: fa 81 ldd r31, Y+2 ; 0x02110: 01 90 ld r0, Z+112: f0 81 ld r31, Z114: e0 2d mov r30, r0116: ce 01 movw r24, r28118: 01 96 adiw r24, 0x01 ; 111a: 09 95 icall11c: ef cf rjmp .-34 ; 0xfc <main+0x22>Two or three instructions' worth of initialization that I think I could probably avoid. Two or three instructions isn't much. As for the indirect, polymorphic method calls, eight instructions: two to load the pointer, two to presumably get the method pointer from the vtable, three to prepare registers for the call (I used PORT_t.OUTTGL rather than VPORT_t.OUT here, that requires multiple instructions and spoils registers to access, being in the high section of memory), and the call itself. I'm unconvinced I could have done better.

author: c4757p
author_rank: Super Contributor
timestamp: October 18, 2015, 01:02:42 pm
content: Followup: the C++ pin-toggle is one instruction shorter because I used|=to initialize VPORT0.DIR in C++, which compiles to a singlesbi, but I used=in C, which compiles toldifollowed byout. Had I been consistent, they would have beeninstruction-for-instruction identical.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: October 18, 2015, 01:07:18 pm
content: FRIEND!O0

author: Kalvin
author_rank: Super Contributor
timestamp: October 18, 2015, 02:13:19 pm
content: When using C++ for the embedded programming, it is always a good thing (TM) to take a look at the assembly listing the compiler produces, just like c4757p did in his postings, so that you will not do goofy things.Edit: It won't hurt even if you are using plain C.

author: c4757p
author_rank: Super Contributor
timestamp: October 18, 2015, 02:41:39 pm
content: Quote from: Kalvin on October 18, 2015, 02:13:19 pmIndeed not. I've been working on a lightweight AVR HAL in C recently. I'm writing a lot of functions that are specifically designed to compile down to single instructions or close to it, many of which have significant branching structures in them. One learns a lot about the way compiler optimizations work, that way. Highly recommended for anyone. You'll be pleasantly surprised - it's better than it gets credit for, or at least avr-gcc is. It knows almost as much at compile time as I do and makes significant use of that information.

author: miguelvp
author_rank: Super Contributor
timestamp: October 18, 2015, 05:42:00 pm
content: RE C++ on 32 bit MCUs (Cortex-M)PSoC Creator even if it's not designed to compile C++ can be coerced to use the C++ compiler:http://www.mbedded.ninja/programming/microcontrollers/psoc/using-cplusplus-with-psoc-creatorOf course, it's not a supported feature, so you can't go around asking for Cypress customer support.Also, it's not like you could use the latest Clang (as far as I'm aware) so you don't get the nice C++11 features unless they use GCC 4.8 which I doubt but have not really look into in.@c4757p:Thank you for doing that. I'm a C++ developer but when I tinker with MCUs I fall back to C, maybe I should revisit this since I'm mostly using ARM processors (Cortex-M0 and M3), so maybe I will enable C++ on Creator and dig more into what version of GCC they are using and If it would be possible to use Clang as the toolchain.Followup: according to the following document, PSoC Creator 3.0 uses gcc 4.7, so it does come with some of the C++11 featuresCypress PSoC Creator Release Notes:http://www.cypress.com/file/124626/downloadGCC 4.7 C++11 features:https://gcc.gnu.org/gcc-4.7/cxx0x_status.htmlLooking at the latest version of Creator (3.3) I found the release notes (log-in required so I'm not linking it) and it states they are using GCC 4.9-2015-q1So it has support for C++11 and experimental C++14, C++17(or 201z), I should play with it to see if that's the case:https://gcc.gnu.org/gcc-4.9/changes.html

author: janoc
author_rank: Super Contributor
timestamp: October 18, 2015, 06:57:45 pm
content: Quote from: c4757p on October 18, 2015, 12:05:00 pmI guess you are not using new/delete operators to allocate memory. Or exceptions. Or RTTI. Or std::string ...Your template code is very rudimentary, essentially "macros" which get converted into generated code at compile time and don't touch the standard library. So no surprise it is the same code, it would be disappointing if gcc was that poor at optimization to screw this up.Since you have mentioned gcc options, do yourself a favour and look in the libstdc++ library (use: nm -D -C libstdc++.so ) You will see what code gets actually linked in such cases. And gcc is hardly a "shitty compiler". Clang will be similar.Even if you don't use any of the above in your code explicitly, a lot of "boilerplate" will be linked to your code to support its possible use, unless you disable all those things using compiler options (but then why are you using C++ in the first place?).

author: Kalvin
author_rank: Super Contributor
timestamp: October 18, 2015, 07:33:34 pm
content: Quote from: janoc on October 18, 2015, 06:57:45 pmC++ provides all kinds of features that are useless in small embedded systems. Typically, you do not use new/delete. Instead you use resource pools and possibly malloc to allocate them only once the system boot up. Using resource pools the system is deterministic and it will not suffer from heap fragmentation or heap exhaustion. Exceptions are not needed either. Nor RTTI. Nor std::string.You can take a subset of the C++ and use it for your advantage in the embedded software development. You do not have to use every bells and whistle of the language just because it is there and you can use it. You just use the subset that is needed to get the job done and which doesn't cause you trouble.You can take advantage of the classes and simple inheritance with little or no penalty. You can use virtual methods with little overhead. Encapsulation, data hiding and generalization can be used without too much of code bloat in favor of creating reusable software components.The templates provides a way to create parametrized classes with type checking far better than preprocessor macros. Templates can be used for generalization and object instantiation. When used properly, they will create code bloat very little if any.

author: c4757p
author_rank: Super Contributor
timestamp: October 18, 2015, 07:39:37 pm
content: Quote from: janoc on October 18, 2015, 06:57:45 pmWhat the hell kind of argument is that? I don't use malloc and free on a microcontroller either, typically don't use floating-point, etc... We're talking about a language, not a shovelful of every excessively complicated thing in its standard library just thrown in because we like them. One always has to tread carefully when doing embedded development, that says nothing about the language.Quote...and then stripped right back out at the end. Or did you not see where Idid not use any of the above in my code explicitlyand the generated codedid not contain any "boilerplate" to support its possible use?

author: MT
author_rank: Super Contributor
timestamp: October 18, 2015, 07:44:53 pm
content: The basic idea is that people overwhelmingly prefer taking on risk in situations where they know specific odds rather than an alternative risk scenario in which the odds are completely ambiguous—they will always choose a known probability of winning over an unknown probability of winning even if the known probability is low and the unknown probability could be a guarantee of winning. That is, given a choice of risks to take (such as bets), people "prefer the devil they know" rather than assuming a risk where odds are difficult or impossible to calculate as in C v.s C++.

author: c4757p
author_rank: Super Contributor
timestamp: October 18, 2015, 07:49:52 pm
content: It's not a "risk" though. Don't be afraid of the assembly.Look at itand see how much of your resources something used. If too much, use something else. If you're afraid of assembly dumps you'renotan embedded developer.

author: MT
author_rank: Super Contributor
timestamp: October 19, 2015, 12:41:42 am
content: C v.s C++!.... I fondly recall my Z80 assembler years in spring 1824 just prior the French revolution!People are afraid of C++1314!

author: legacy
author_rank: Super Contributor
timestamp: October 19, 2015, 06:45:02 am
content: I wish I had the time and the resources (and the skills) to develop a "safeC" C compiler, based on C99, but MISRA by design.but, more afraid about C++, which is more complex to be designed (and to understand, when you have to use)p.s.why C++ ? I needed to work with fixed point, C has no support, but C++ can overload, so I designed a custom library to have a native support for fixed point.(fpga softcore, programmed with C++)

author: legacy
author_rank: Super Contributor
timestamp: October 19, 2015, 06:46:49 am
content: herewe discussed about concurrency, I think it will be THE trouble with the C language as soon as we will have a lot of cores in our MPU devices

author: richardman
author_rank: Frequent Contributor
timestamp: October 19, 2015, 07:32:38 am
content: re: fixed pointEmbedded C, which is not a Standard, but an ... "advisory"? Anyway, it adds fixed point data point, so no need to roll your own.We will be adding that in Q1 2016.

author: janoc
author_rank: Super Contributor
timestamp: October 19, 2015, 12:28:52 pm
content: Quote from: c4757p on October 18, 2015, 07:39:37 pmAs far as I know things like exceptions, new/delete, RTTI are parts of the language standard, not some optional extra or ("a shovelful of every excessively complicated thing" as you call them). So you are basically using only a tiny subset of the language (nothing wrong with that, btw) but making generalized statements about it.

author: c4757p
author_rank: Super Contributor
timestamp: October 19, 2015, 12:57:41 pm
content: My "generalized statements" arecorrect. You are trying to claim that even if you don't use the heavier features of C++, they will pull in code to support them 'just in case'. I demonstrated that to be false. If you want to claim that C++ is poorly suited for embedded development because some of its optional features are, fine, that's an opinion and I'm not the least bit interested in discussing people's programming opinions. But saying that features you don't use increase code size is an attempt at stating fact, and statements of fact can betested.

author: tggzzz
author_rank: Super Contributor
timestamp: October 19, 2015, 02:23:09 pm
content: Quote from: c4757p on October 19, 2015, 12:57:41 pmTo be a little more precise, you demonstrated that inoneexample foronearchitecture usingoneversion ofonecompiler andoneset of compiler flags where the compiler complies (to some extent) withoneversion of a language standard.C/C++ is notorious for having too many variations for all of the above.

author: c4757p
author_rank: Super Contributor
timestamp: October 19, 2015, 03:10:16 pm
content: Well, let's get some more tests in here, shall we? I did AVR because I'm familiar enough with it to dig into the assembly dumps. Anyone here for ARM?Obviously - as I said - there are crap compilers. I wouldn't expect Microchip's excuses for compilers to perform particularly well here, for instance, if they even support C++If you're stuck with a poor compiler, obviously you're going to be limited.

author: tggzzz
author_rank: Super Contributor
timestamp: October 19, 2015, 05:07:22 pm
content: Quote from: c4757p on October 19, 2015, 03:10:16 pmChanging the statement to "To be a little more precise, you demonstrated that in one example fortwoarchitectures using one version of one compiler and one set of compiler flags where the compiler complies (to some extent) with one version of a language standard" is not much better. Especially when there are so many varieties of ARM.QuoteAll C/C++ compilers are crap in some respects. For example, even in 2015 gcc doesn't support C++11 (it supports bits of it). Are there anyfullC++11 compilers yet?

author: c4757p
author_rank: Super Contributor
timestamp: October 19, 2015, 05:30:46 pm
content: Quote from: tggzzz on October 19, 2015, 05:07:22 pmIt's infinitely better when it's a statement about the architecture and compiler you want to use. Or do you seriously refuse to use anything because some obscure platform somewhere in the world doesn't support it?QuoteFine, "crap" was an opinionated statement. I figured a tautological "obviously, compilers that don't support feature X don't support feature X" would be too patronizing - but it's the truth. Generic claims that a language is poor for embedded because not every single platform implements it properly aren't useful.janoc said:Quote from: janoc on October 18, 2015, 11:37:58 amI never attempted to claim every feature of the latest version of C++ was suitable for use on every platform with every compiler. I merely claimed, and showed for one example, that the runtime overhead doesn't exist. Perhaps you can find a platform for which itdoes, in which case you probably shouldn't use it there. But on many, it doesn't. As a general statement that it is a necessary consequence of using C++, it's utterly false. No good as general advice. Where it's true, it's a flaw of your specific chosen platform and toolchain.You'll find development a lot more enjoyable if you stop avoiding things because something somewhere doesn't support them. C++ has rather a lot of nice stuff you could use. Come to the dark side, we have cookies. O0

author: miguelvp
author_rank: Super Contributor
timestamp: October 19, 2015, 05:39:31 pm
content: GCC 5.0 and Clang 3.4 have full C++11 and C++14 supportIntel's and Microsoft's compilers fully support C++11 as well.Source:http://en.cppreference.com/w/cpp/compiler_support

author: andersm
author_rank: Super Contributor
timestamp: October 19, 2015, 05:46:56 pm
content: Quote from: tggzzz on October 19, 2015, 05:07:22 pmIf you keep moving the goalposts, I'm sure you'll eventually find something that backs your points, but at some point it'll just start looking contrived.There must be something very special about embedded systems, because no matter how fast they get or how much memory they have, they're still somehow always too small and too slow for C++. At some point it was inconceivable to program embedded systems in something as wasteful as C, but somehow we as a species survived that ordeal as well.QuoteGCC supportseverything except garbage collection, libstdc++ has a few items that are missing or only partially implemented. Clang has couple of unimplemented features (GC, C99 extended integral types), but libc++ claims complete support for both C++11 and C++14.

author: c4757p
author_rank: Super Contributor
timestamp: October 19, 2015, 09:57:02 pm
content: Quote from: andersm on October 19, 2015, 05:46:56 pmEmbedded garbage collection, I believe, is where you set a bin out for everybody to throw away their microcontrollers that don't support C++. This should be easily supported by GCC.

author: richardman
author_rank: Frequent Contributor
timestamp: October 19, 2015, 10:26:23 pm
content: Quote from: andersm on October 19, 2015, 05:46:56 pmDo you work in the industry? If you do, you would know why.As I said a few times already: embedded system programmers generally are not software engineers. This is the reality. It does not matter how many better Go/Swift/C++/MicroPython etc. are. They will not get traction until that fact changes.

author: c4757p
author_rank: Super Contributor
timestamp: October 19, 2015, 10:45:09 pm
content: Quote from: richardman on October 19, 2015, 10:26:23 pmHow sad, that they're writing software for a living and won't deign to learn software engineering. It feels like the embedded world just wants to live a perpetual amateur hour. Reminds me of the old electrical engineers who won't admit that it's 2015 and they should probably learn to code.

author: Marco
author_rank: Super Contributor
timestamp: October 19, 2015, 10:58:29 pm
content: Ehh, once you start using C++ as C with slightly more syntactic sugar around struct based classes and with easier to use comments I doubt it speeds up development much.PS. the entire IT industry is amateur hour, can I have some more buffer overflows?

author: c4757p
author_rank: Super Contributor
timestamp: October 19, 2015, 11:10:14 pm
content: Well, it's fine if you don't like it or don't think it's very useful for you - as long as you don't start giving bullshit reasons why it's broken. You can say you don't think you need its features without saying they'll magically bloat your code by just being there.Quote from: Marco on October 19, 2015, 10:58:29 pmYeah, gimme a minute, I'm sure I can find one for you...

author: westfw
author_rank: Super Contributor
timestamp: October 20, 2015, 05:32:01 am
content: I found this interesting discussion pursuing another forum's comments:http://programmers.stackexchange.com/questions/48401/learning-c-properly-not-c-with-classesWhich I basically interpret as "if you're not using the bloated parts of C++, you're not doing it right." :-(Their "good example" is about 60% bigger than their "bad example" (compiled for x86 MacOS.)And yet people wonder why embedded engineers are scared away...

author: Kalvin
author_rank: Super Contributor
timestamp: October 20, 2015, 11:22:44 am
content: Complex numbers are part of the C++ (std::complex). Those who have been awake on the math classes know that the real numbers are the subset of the complex numbers.So, does that imply that if I am using just the double or float numbers (subset of the complex numbers) and not using std::complex, that I am not really programming in C++?More precisely, if I use only the specific subset of the C++ and not using the std::-libraries, multiple inheritance, RTTI, exceptions or any place-your-favourite-C++-feature-here because of the code bloat, or the specific feature is considered unusable for the small embedded MCUs, does it imply that I am not really programming in C++?It seems that some of the arguments suggest that one should always use the full language features in order to justify its usage. Here is then a hint for those so called "programmers": Next time you use doule or float, please use std::complex instead, and perform your computations using only the complex numbers, because you do not want to use only the subset of the numeric space the C++ is providing.

author: nctnico
author_rank: Super Contributor
timestamp: October 20, 2015, 12:14:28 pm
content: Quote from: c4757p on October 19, 2015, 11:10:14 pmI agree. C++ offers many features to make programming quicker and with some care you can avoid using pointers because you can pass variables by reference. I often see obfustigated constructs where people use function pointers in C to make objects. It works but at that point it is time to switch to C++ and use classes.

author: Marco
author_rank: Super Contributor
timestamp: October 20, 2015, 03:30:17 pm
content: Quote from: nctnico on October 20, 2015, 12:14:28 pmI don't think that makes a whole lot of sense. If I'm passing a pointer to code which might change the data I'd really prefer being able to see it in the code on my screen, rather than having to mouse over or rely on my god awful memory (Googleseems to agree with me, that whole style guide is basically anti-C++ though).

author: c4757p
author_rank: Super Contributor
timestamp: October 20, 2015, 03:32:48 pm
content: Quote from: Marco on October 20, 2015, 03:30:17 pmProbably utterly offtopic:yes. Non-const referencessuck, don't use them please. C's pure pass-by-value-at-all-times is very clean and makes it very easy to know when something will be able to make modifications.Pointersaren't evil.

author: tggzzz
author_rank: Super Contributor
timestamp: October 20, 2015, 04:18:26 pm
content: Quote from: c4757p on October 20, 2015, 03:32:48 pmAs someone that remembers theendless"casting away constness" discussions in the early-mid 90s, I findhttp://yosefk.com/c++fqa/const.htmlwryly amusing.

author: legacy
author_rank: Super Contributor
timestamp: October 20, 2015, 05:06:52 pm
content: Quote from: westfw on October 20, 2015, 05:32:01 amwhat do you mean with "bloated parts of C++"? which parts do you mean?

author: nctnico
author_rank: Super Contributor
timestamp: October 20, 2015, 07:07:06 pm
content: Quote from: c4757p on October 20, 2015, 03:32:48 pmPointers are prone to errors. Probably because they are appearantly difficult to grasp by many. Why do you think many higher level languages don't have pointers?

author: c4757p
author_rank: Super Contributor
timestamp: October 20, 2015, 07:12:45 pm
content: Because higher-level languages are more abstract and pointers are a low-level construct.

author: Dielectric
author_rank: Regular Contributor
timestamp: October 20, 2015, 08:32:58 pm
content: Quote from: c4757p on October 20, 2015, 03:32:48 pmIndeed, I posit that pointers are the shiz-nit for MCUs. Note the qualification. You can utterly hose yourself, or just trip the MPU, on a regular processor and I can see where they get a bad rap. Of course, you can still hose yourself with a badly handled pointer on an MCU, but the good part is being able to pass-by-reference and stuff like that.I just did a project where most of the stuff was done by structure passing. Keeps scope and concurrency nice and contained because it was a multi-channel thingy. I could make any number of channels this way, just allocate a few more structs.Function pointers? Yes please! I converted a project from a big tree of if/elses (maybe it was a case structure, can't remember) into a function pointer exercise, and it did exactly the same function in less code space. Cortex M0 with GCC, for the record.

author: janoc
author_rank: Super Contributor
timestamp: October 20, 2015, 08:46:47 pm
content: Quote from: c4757p on October 19, 2015, 05:30:46 pmI am actually doing C++ development for living for the last 15 years or so, on multiple platforms, including some embedded ones, my friend. So I dare to say that I know what I can and cannot expect from this language.

author: c4757p
author_rank: Super Contributor
timestamp: October 20, 2015, 09:37:36 pm
content: Excellent! Well, you should be able to tell us which platforms incur runtime overhead for unused features, then.

author: miguelvp
author_rank: Super Contributor
timestamp: October 20, 2015, 09:46:34 pm
content: C++ or C++11?After all, they are in different ball parks.

author: tggzzz
author_rank: Super Contributor
timestamp: October 20, 2015, 10:12:53 pm
content: Quote from: Dielectric on October 20, 2015, 08:32:58 pmFunction pointers are indeed averygood implementation technique for FSMs. I first used that technique in 1982 on a Z80.

author: Howardlong
author_rank: Super Contributor
timestamp: October 20, 2015, 10:20:46 pm
content: Quote from: tggzzz on October 20, 2015, 10:12:53 pmReal men used E9h. I just stunned myself that I could even remember the opcode.

author: Marco
author_rank: Super Contributor
timestamp: October 21, 2015, 02:24:08 am
content: Quote from: nctnico on October 20, 2015, 07:07:06 pmMaking it harder to reason about small parts of code makes programs prone to other kinds of errors, in this case programmers can assume it was passed by value for instance. Higher level languages have distinct types of errors related to this kind of obfuscation. Last year both a Python and a PHP library meant to sanitize SQL input were exploited for instance for much the same reasons in my opinion. Dynamic typing makes it very difficult to completely think through how code might execute.This is why I think Rust is almost right in it's design intention (implementation remains to be seen). Except for "asynchronous" message passing as the default, they got that one all wrong. Almost all the reasons to avoid GC apply to "asynchronous" message passing. "Asynchronous" message passing will eventually turn into synchronous message passing in production and then it will start exposing bugs which you might have found if only you had developed it as synchronous in the first place.

author: legacy
author_rank: Super Contributor
timestamp: October 21, 2015, 05:15:34 am
content: Quote from: tggzzz on October 20, 2015, 10:12:53 pmcan I see an example, please ?

author: Howardlong
author_rank: Super Contributor
timestamp: October 21, 2015, 07:56:47 am
content: Quote from: legacy on October 21, 2015, 05:15:34 amFWIW, even if you use a case statement in an FSM, it's pretty common for compilers to turn them into computed jumps, especially if the states tend to be incremental. A computed jump is barely a step away from using a function pointer. Whether it's more understandable to look at a case statement compared to explicitly using a function pointer I'll leave for another day...

author: tggzzz
author_rank: Super Contributor
timestamp: October 21, 2015, 08:11:08 am
content: Quote from: legacy on October 21, 2015, 05:15:34 amI'm sure you can find one on the net; my example is lost in time.Basic principle is:you have events and states, and it is necessary to specify what happens when each event occurs in each stateit is also necessary for someone else to unambiguously read, determine and change what happens with each state/event combinationit is also necessary that someone have made exactly the right change andonly the right change- and that is very error-prone with if-the-else statementsthere is a 2D array, one dimension for each state, the other dimension for each eventeach element in the 2D array contains a function pointer to the action which occurs when one of the events occurs in one of the stateswhere appropriate the action can be "do nothing"where appropriate the action can be "should not happen, log message and shutdown"you can also have a parallel 2D array specifying the next state, or it can be encoded in the action, whichever is easier to read and correctly modifydebugging with breakpoints is easy, obviouslydebugging via printf is easy, just consisting of the state-event indexes"how did we get to an error" audit trail is easy if the x-y indices are stored in a buffer, being dumped in the "should not happen" action

author: tggzzz
author_rank: Super Contributor
timestamp: October 21, 2015, 08:16:09 am
content: Quote from: Howardlong on October 21, 2015, 07:56:47 amI have seen a commercial product where an if-the-else state machine was the central control-flow mechanism. Over the years it gradually mutated due to customer requests until it was hundreds of lines long and statements were nested 10 deep! Nobody dared refactor it. (I imagine each mutation was individually commercially justifiable.)Inept? Sure. That's the way of the world, andengineers(cf hackers) develop techniques to deal with real-world "sub-optimalities".

author: nctnico
author_rank: Super Contributor
timestamp: October 21, 2015, 12:17:58 pm
content: Now you are opening an old wound in my memory! One of my first projects involved making changes to such a program. It was written by someone who was a wood worker. I decided to print the program (still using a matrix printer!) and draw lines in the margin where each if-then-else block started and ended with numbers to keep track. I think some IF statements spanned several pages (printed 100 lines per page). I recall combining several half-page long spaghettis into just a few lines doing exactly the same. The customer wasn't happy with the amount of hours I had to put in...I agree with Howardlong though on statemachines and function pointers. It is hard to follow a statemachine based on function pointers because the cause is detached from the resulting action. I have implemented an ISDN protocol stack that way but my co-workers didn't really want to dive into it because they found the concept hard to grasp. It worked blazingly fast though!

author: Kalvin
author_rank: Super Contributor
timestamp: October 21, 2015, 12:33:30 pm
content: My preferred way of implementing state machines is to use a function pointer "current_state" pointing to the function of the current state handler. Thus, there is one function for each state. Inside the state handler function there is a simple switch-case-structure which will catch & handle each event. There is also a default handler which will do either nothing or it can propagate the event to some where else if needed. The state handler function will also return the the next state if a state change is required because of an event. My state machine implementations typically have also predefined events like, STATE_INIT, STATE_ENTER, STATE_EXIT and STATE_TIMEOUT which are invoked automagically by the state machine during the state transitions or timeouts. To me this is mentally most easiest way to keep the things in order.

author: legacy
author_rank: Super Contributor
timestamp: October 21, 2015, 02:53:26 pm
content: @tggzzzdo you mean something likethis?

author: Dielectric
author_rank: Regular Contributor
timestamp: October 21, 2015, 03:16:47 pm
content: Quote from: legacy on October 21, 2015, 02:53:26 pmFrom that page, this is a great example:Code:typedef void transition_func_t( instance_data_t *data );void do_initial_to_foo( instance_data_t *data );void do_foo_to_bar( instance_data_t *data );void do_bar_to_initial( instance_data_t *data );void do_bar_to_foo( instance_data_t *data );void do_bar_to_bar( instance_data_t *data );transition_func_t * const transition_table[ NUM_STATES ][ NUM_STATES ] = {{ NULL, do_initial_to_foo, NULL },{ NULL, NULL, do_foo_to_bar },{ do_bar_to_initial, do_bar_to_foo, do_bar_to_bar }};state_t run_state( state_t cur_state, instance_data_t *data ) {state_t new_state = state_table[ cur_state ]( data );transition_func_t *transition =transition_table[ cur_state ][ new_state ];if ( transition ) {transition( data );}return new_state;};

author: tggzzz
author_rank: Super Contributor
timestamp: October 22, 2015, 12:30:15 am
content: Quote from: nctnico on October 21, 2015, 12:17:58 pmI have no idea what you mean by that.

author: Howardlong
author_rank: Super Contributor
timestamp: October 22, 2015, 07:08:30 am
content: I use both methods for FSMs, but when reading someone else's code almost always I find it easier to follow if it's a case statement rather than a function pointer, it's right there in your face. I use "clever" things like function pointers less and less as I get older, not because I'm going senile particularly (!) but because I know when I go back to look at even my own code several months down the line stuff like this sometimes unnecessarily gets in the way of comprehending quickly what is happening.My concern is usually around whether some piece of language functionality is used to show off one's chops because at the time you might think it's more elegant rather than whether it's easily maintainable. If you have to spend time reverse engineering your own or someone else's algorithms and data structures, rather than following simple program flow, then for me at any rate the simple in your face version wins. That is not to say there's a time and a place though!I remember when I was younger re-coding a whole bunch of Windows code from an enormous number of event driven case elements and putting it into an array of function pointers back in the 80s (when Windows was still 16 bit and MFC didn't exist my friends) because I thought it was more "elegant". The problem was that nobody else understood the code as that wasn't the way Charles Petzold did it.Having said all that, the concept of function pointers is inherently locked up inside polymorphism in OO languages like C++, it's just that as humans we choose not to see them as function pointers.

author: tggzzz
author_rank: Super Contributor
timestamp: October 22, 2015, 08:40:55 am
content: Quote from: Howardlong on October 22, 2015, 07:08:30 amAs I said, I've seen undisciplined use of if-the-else statements in complex FSMs "blossom" into unmaintainable cancersAnd no, those statements weren't autogenerated from a higher level description.As for re-comprehending, if the design pattern is remembered and suitable names are given, then I've found it easy to pick up. Of course if those aren't followed, all bets are off!QuoteCompletely agree, but I'll add some constraints for what consititues "maintainable"for FSMs. When an event occurs in a state, I want to be able todetermine which piece of code gets executedchange what happens, in the knowledge that I haven't affected any other state/event's actionlog the state/event for debugging and for live-system audit trailsThe latter isinvaluablewhen a problem occurs and you need to demonstrate the problem is with other manufacturer's equipment.QuoteThe standard OO FSM design pattern is extremely useful since, with some boilerplate it enables all the valuable attributes I've previously mentioned.

author: nctnico
author_rank: Super Contributor
timestamp: October 22, 2015, 09:51:13 am
content: If all code should follow a design pattern then programming becomes like being a monkey coloring within the lines.

author: Kalvin
author_rank: Super Contributor
timestamp: October 22, 2015, 10:34:37 am
content: Quote from: nctnico on October 22, 2015, 09:51:13 amProgramming is all about communication. Otherwise you could scrap the source code, ignore the language to be used (you could always use assembly, Forth, Brainfuck, Whitespace etc. instead of C/C++), ignore the comments, ignore the source code formatting, ignore using meaningful names, ignore asserts and test cases, ignore documentation and instead deliver your work to your collegues in the form of the hex or binary code.Design patterns improve communication as they provide common language inside the team/organization, improves productivity as one doesn't have to invent the wheel for each project requiring specific "pattern" but the designer can instead concentrate on solving the actual problem at hand instead composing the solution with a help of the known patterns, reduces bugs by using proven patterns and avoiding antipatterns, improve software architecture design as the software structure can be expressed in known patterns, and make the software maintenance easier due to the sum all of the previous arguments. Of course, one could also argue that the canvas and the colors available will make an artist a monkey coloring white canvas between the frames.

author: tggzzz
author_rank: Super Contributor
timestamp: October 22, 2015, 10:38:22 am
content: Quote from: nctnico on October 22, 2015, 09:51:13 amHow do you suggest we distinguish the current state of programming from "monkey coloring within the lines"?I suggest you study where design patterns originated and why they are regarded as standard operating procedures in engineering disciplines. Programming != engineering, unfortunately. Cue standard jokes about "if buildings were designed by programmers"...

author: c4757p
author_rank: Super Contributor
timestamp: October 22, 2015, 10:40:14 am
content: Put simply: design patterns keep you safe from being murdered by other developers

author: Howardlong
author_rank: Super Contributor
timestamp: October 22, 2015, 07:41:56 pm
content: One of the reasons I enjoy embedded programming is that I feel at one with the machine. After decades of working the system professionally mostly with enterprise software, I find it a breath of fresh air to be able to work with deterministic systems that I can understand an entore system all the way from the electrons in the LAN wire to the pixel on the TFT.Some time around the mid 90s after the introduction of multi-tiered distributed systems and the siloing of jobs (segregation of responsibility they call it) it became impossible for an individual to be able to reasonably understand an entire stack in intricate detail from the UI through the token ring, network infrastructure and into the assorted servers. My job became as much about ego massaging the right "it ain't my problem" techies into the right room to talk to each other as it was a technical role.Luckily the entire real time embedded world below Linux is still accessible to single individuals without needing multiple experts, but I am not sure how long that will last. The recent introduction of some platform specific frameworks makes the bar higher for entry for example, and people will inevitably specialise more, despite still being based on C.More concerning is the fragmentation of the software industry in terms of the number of languages and frameworks, and the average lifetime of them. Perl for example was the king of backend scripting and then suddenly over the period of only three or four years has been left in the dust. This flavour of the month attitude is expensive. When I see things like Node.js, Lua and Python being bandied around as embedded languages it makes me shudder, not just because they are necessarily inherently wrong on low to mid end low power real time embedded systems, but because they will probably be on their way out in a few short years for Next Big Thing.The biggest thing that's changed in embedded programming in the past fifteen years is that even on the very lowest end MCUs, complete assembly solutions have almost completely disappeared, with most of it being done in C. Now whether that morphs into C++ lite over the next decade remains to be seen, but I could accept that as a likely event particularly as embedded project code becomes larger. What I don't see happening is any fly by night language coming along and taking over the crown of C or C++ in the real time area. If you want real time, none of these Lua, Python or Node.js languages will help you, and your coin cell battery will probably be flat before your system boots anyway.Just my current thoughts, I'm willing to be encouraged to think otherwise.

author: MT
author_rank: Super Contributor
timestamp: October 22, 2015, 08:55:38 pm
content: case 1:if (monkey==engineer)stage = color between lines;else{stage = look for human spices origin;}break;This thread went "ape" but in evolutionary interessting way, i'd like to thank you all monkeys for yourinsights and sharing of experience. I will try to incorporate the wisdom into my monkey brain whilesitting here trying to comprehend my own C code!It's said by quantum physicists that if 1 million monkeys was to type letters at random thatat one fraction of a second the entire The Hitchhiker's Guide to the Galaxy would emerge.

author: MT
author_rank: Super Contributor
timestamp: October 22, 2015, 09:23:55 pm
content: Quote from: Howardlong on October 22, 2015, 07:41:56 pmWhich frameworks?

author: miguelvp
author_rank: Super Contributor
timestamp: October 22, 2015, 09:27:16 pm
content: Not sure about the Hitchhiker's Guide to the Galaxy but without an improbability drive the library of babel online claims that it has all the words ever devised or that will be devised ever (I guess they mean in English). But maybe you can find full books readable books.https://libraryofbabel.info/Alas, no monkeys. But if you do search "the hitchhikers guide to the galaxy" it doesn't allow apostrophes, it would find at least the title in the book that is in Volume 21 on Shelf 3 of Wall 4 of Hexagon, page 196 of 410 around the middle.

author: miguelvp
author_rank: Super Contributor
timestamp: October 22, 2015, 09:41:38 pm
content: Actually i'm impressed, did a random search for a short story:https://americanliterature.com/author/kate-chopin/short-story/the-story-of-an-hourBut the search is limited to just 3200 charactersAnd it found those on page 171 in Volume 10 on Shelf 1 of Wall 2 of Hexagon: (too long to paste, it's 3256 characters for the hexagon name).I guess they use some kind of algorithm that produces a hash that reversed contains the book? not sure since I didn't research it much.

author: eas
author_rank: Frequent Contributor
timestamp: October 22, 2015, 10:04:21 pm
content: In skimming this thread, it strikes me that the real language problem here isn't with C, or C++, or which variant thereof, or Python, or ..., it is with human communication.As is often the case, everyone has differing understandings of the terminology being used, starting with "programming," "software development," "embedded development," and what people mean when they talk about C, C++ and variants thereof in that context. People are more likely to have a high-degree of overlap in their understanding of well established terminology.As has been noted, a decade or two ago, the idea of relying on C for embedded development was relatively new and not well accepted, now, it is. Why was there so much skepticism? Why have things changed? In part, the early skepticism was due to some real shortcomings in libraries, and compilers, and linkers, and in time, those problems were ironed out. I think though, that even if everything worked perfectly skepticism would still have prevailed, in part because it was new an unfamiliar. People were justifiably skeptical that it might be a flash in the pan. Also ,being new and unfamiliar, people heard about or had direct experience with C projects going badly, and it was inevitable that they would, because C gives one plenty of rope with which to hang oneself.Overtime though, the craft of embedded programming in C became well understood enough that people could start to take for granted that they were talking about substantially the same thing. Which isn't to say that there isn't considerable room for misinterpretation. For some, the assumption is making use of a particular vendors ecosystem of libraries and compilers. For others, its writing or adapting ones own libraries. But even these differences have become better and more widely understood, and people are better at clarifying.In time, I would expect greater shared understanding about the use of C++ in embedded development.I think though, that there is going to be increased confusion about what constitutes embedded development. For this, we can thank/blame the semiconductor process engineers and chip designers. Their steady progress over the past half-century have enabled plenty of confusion, chaos, and dysfunction at every level of software development. Embedded development is no different.The way I see it, the envelope of fixed costs, unit costs, and power consumption have shifted. Some situations that previously required embedded development specialists who fretted about every cent of unit cost, every coulomb, every byte of code, every clock cycle, every I/Opin and every bug, are now open to a wider range of practitioners. People who, ~15 years ago, might have been Visual Basic 6 developers, integrating various Microsoft and third party components to make in-house apps, might now be buying a few modules and using the vendor provided dev environment to make an embedded device for in-house use. When bugs are discovered, they'll use a vendor provided solution to push updated software to the field.I'm sure this sounds like a perfect nightmare to most anyone who considers themselves embedded engineers, but for someone who can't quite find anything that is quite right for their need, and who can't afford to do "proper" embedded development its going to be a godsend. It remains to be seen what this does to traditional embedded development. Will opportunities for such work shrink? Hold steady? Expand? It's hard for me to guess. I think there will always be a need for the skills and mindset. But how many will they be employed developing for deployed products, vs tools used by higher-level developers?In this new world, I think small low powered devices programmed using Lua, Python, Javascript, and similar are going to become more numerous. As for fear of them being flashes in the pan, I don't know if it will reassure Howardlong to hear that his perspective may be a little skewed. Perl's time in the sun as king of the backend languages was quite short. Coldfusion and ASP were strong challengers by 1998, and by the dotcom crash, PHP had a strong and rapidly expanding foothold on the UNIX servers Perl CGI apps called home. It wasn't too much longer before Ruby + Rails was stealing a lot of PHPs thunder. Python was slower catching on on Web servers than Ruby + Rails, but before Ruby found a niche in web development, Python was already being used as an integration language in a variety of areas (google used it a lot internally, YouTube was built with it, and it has a strong foothold in bioinformatics). Lua, its had a great foothold in computer game scripting for over a decade. Javascript has been the lingua franca of client-side web development since before anyone even really developed client-side web apps. Its presence as a serverside language is just about as old, though it didn't get any traction on the server until someone took Chrome's fast javascript engine and made Node.js.To wrap all of this up:Computer languages are really human languages. Even with the economic and cultural force of the combined British and American empires over multiple centuries, there are plenty of people who rarely use English, and plenty more who never use English. Even among english speakers, there are significant differences in accent, pronunciation, spelling, dialect, vocabulary and idiom. Even among english speakers talking about the same technical subject, there is ample room for misunderstanding.Therefore, there are apt to be a variety of computer languages, and variants of individual computer languages and their applications to given problem domains. Moreover, now that computing is almost ubiquitous, the forces of proliferation and variation are likely to grow.There may be large areas of common adoption and practice, but there will always be fractal edges. Todays tiny fractal edge of computing/programming could conceivably include more practitioners and users than all of computing did in the days that some of you started your careers. Or looking at it another way, there have been ~10x as many Rasberry Pi's sold as there were DEC PDP-11s.

author: MT
author_rank: Super Contributor
timestamp: October 22, 2015, 11:03:31 pm
content: Quote from: miguelvp on October 22, 2015, 09:27:16 pmYes english only..

author: Howardlong
author_rank: Super Contributor
timestamp: October 22, 2015, 11:07:49 pm
content: Quote from: MT on October 22, 2015, 09:23:55 pmMicrochip Harmony in my own experience, and I believe STMCube is of a similarly derided genre.

author: Marco
author_rank: Super Contributor
timestamp: October 23, 2015, 07:00:20 am
content: Quote from: c4757p on October 22, 2015, 10:40:14 amUnfortunately only low hanging fruit relevant to large GUI/web applications are really tackled. Domain specific books of patterns and infinitely more important anti-patterns are lacking, but the people with the ability to write them unfortunately have better things to do. So all we get is anecdotes and lots of reinventions of wheels and failure modes.

author: westfw
author_rank: Super Contributor
timestamp: October 23, 2015, 07:26:09 am
content: QuoteThe New TI MSP432 Launchpad (http://www.ti.com/tool/msp-exp432p401r) supports multitasking in Energia. Only. Using TI-RTOS. (ie, no MSP432 support in Energia without using TI-RTOS.) I find myself relatively unwilling to invest much time in learning about TI-RTOS. Because: TI-only... Sigh.

author: diyaudio
author_rank: Frequent Contributor
timestamp: October 23, 2015, 08:59:19 am
content: Quote from: c4757p on October 22, 2015, 10:40:14 amAnd design patterns done wrong just adds more twisted metal to the problem, layers of shit, to perform simple things with gross levels of over engineering overhead...

author: tggzzz
author_rank: Super Contributor
timestamp: October 23, 2015, 09:53:07 am
content: Quote from: diyaudio on October 23, 2015, 08:59:19 amEverything can be misapplied, and will be. Your argument is equivalent to saying for loops add more layers of shit, with the implication that goto is all that is necessary and is all that should be used.It is notable that the GoF book correctly followed best practice by clearly indicating examples where each pattern should not be used.Design patterns represent a higher level of abstraction than individual statements/functions/modules, and succinctly communicate aspects of an architecture or design. For example, if I am working with distributed messaging systems, it is very useful to know that a component implements the "half-sync half-async" design pattern rather than "sync RPC", because then I have a good idea of its behaviour.

author: diyaudio
author_rank: Frequent Contributor
timestamp: October 23, 2015, 09:58:14 am
content: Quote from: tggzzz on October 23, 2015, 09:53:07 amRubbish. that's what you are assuming. please don't lecture me about design patterns, I am old enough to understand what their benefits are (when applied correctly) you really NOT teaching me or anyone here anything that we already don't know.

author: tggzzz
author_rank: Super Contributor
timestamp: October 23, 2015, 11:18:14 am
content: Quote from: diyaudio on October 23, 2015, 09:58:14 amI responded to what you wrote; not being a mind-reader I couldn't divine your other thoughts. No could anybody else reading your comment.If you had mentioned that vital caveat, then there would have been no need to ensure thatinexperiencedreaders weren't mislead by your partial statement of your position.

author: Howardlong
author_rank: Super Contributor
timestamp: October 23, 2015, 12:36:32 pm
content: Quote from: eas on October 22, 2015, 10:04:21 pmSome very good points.While I can certainly see the likes of garage door openers easily being targets for higher level script languages where the overhead of abstraction is of no practical consequence and devices supporting them become commodity parts, my original comments were to do with the low to middle end real time embedded area which is where I specialise. When you need deterministic responses measured in microseconds, for example for signal processing, these high level scripting languages just aren't the right solution. While you can do a bit of orchestration with them, typically embedding a scripting language interpreter is often going to be an additional unnecessary overhead and complication. The Lua implementation on a PIC32 that I'm aware of, for example, needs at least 128KB of RAM to run something reasonable on a PIC32, an enormous amount in low to middle end microcontroller terms.For a system which is capable and for which you've already accepted that you're going to implement a high level OS like Linux, of course these scripting languages makes an awful lot of sense, but there is inevitably a cost in this in terms of memory, processing power and energy. It's still a long way off before we'll see a CR2032 powered Linux device available that has a practical use.I should have been clearer in defining terms I guess, "embedded" covers a multitude of sins. If I were a betting man, I'd still be betting C and C++ as the language of choice in 10 years in the real time low to middle end market (eg, PICs and Cortex-M).

author: legacy
author_rank: Super Contributor
timestamp: October 23, 2015, 01:00:23 pm
content: why don't we focus on fixing troubles with C99 instead?why don't we write tools like "inter modules dependencies"?why don't we improve the C language to support try exception?and something more comfortable, thing we can do to stop the (ab)use of "goto" ?

author: c4757p
author_rank: Super Contributor
timestamp: October 23, 2015, 01:03:02 pm
content: Which problems with C99? I've not found any.

author: legacy
author_rank: Super Contributor
timestamp: October 23, 2015, 01:19:48 pm
content: C99 comes from the legacy of C89, so it is not exactly compatible with C89, while it is keeping old troubles, withbreak,continue,goto, (plus goto *xxxx introduced by gcc) { all of these are banned by MISRA },complex typemight fail (and there is a specific #pragma for that), it still missesfixed point type, still inadequate opaque type, still missing try-exception (which forces people to use goto), and problems in defining abstract interfaces (and how to define if a parameter is IN/OUT/INOUT ?), etc etc and let me say new features like the "restrict" which was introduced with the motivation of protecting pointers is an useless bullshit, and more and more problems with concurrency, in where every C revision is still a pain in the headso the point is:too many bullshit around,no real progresswith the C language, while C++ is simply too bloated

author: legacy
author_rank: Super Contributor
timestamp: October 23, 2015, 01:24:55 pm
content: Interestinglythisrecent study found that "developers limit themselves to using goto appropriately in most cases, and not in an unrestricted manner like Dijkstra feared", thus suggesting that goto does not appear to be harmful in practiceInterestingdevelopers use goto in C files for error handling and cleaning up resources at the end of a procedurea proposition that follows from (and is often appended to) one already proved.: the C language is inadequate for that

author: c4757p
author_rank: Super Contributor
timestamp: October 23, 2015, 01:37:04 pm
content: There's absolutely nothing wrong withbreakandcontinue, that's just silly. Whoever came up with that MISRA rule is full of shit. I likewise don't think anything is wrong withgotowhen used properly - never jumpintoa block, and absolutely, positively never jumpbackwards. It'sfinefor simple error handling.I wasn't aware of the problems with the complex type, though I've yet to see anybody use it. Exceptions are just not something that is done in C. If you want exceptions, use C++. Same with abstract interfaces - C isn't meant for OOP. As for defining whether a parameter is in or out - well, if it's a pointer and it isn'tconst, it's probably either an outparam or the programmer doesn't understand const (in which case he needs a good thwack with the cluestick).C is weakly typed by nature, defining in- and out-params is not something I'd expect from it. If you don't like that, don't use a weakly typed language. Ada supports those...

author: legacy
author_rank: Super Contributor
timestamp: October 23, 2015, 01:50:01 pm
content: Quote from: c4757p on October 23, 2015, 01:37:04 pmyeah, absolutely nothing wrong with them, and people always uses goto in the properly way, while MISRA always tells you bullshitsQuote from: c4757p on October 23, 2015, 01:37:04 pmoh, really?Quote from: c4757p on October 23, 2015, 01:37:04 pmoh, really?Quote from: c4757p on October 23, 2015, 01:37:04 pmoh, really? And can I feed the monkey? with nuts or with bananas ?good motivations, man(to stay in the cave-office)

author: legacy
author_rank: Super Contributor
timestamp: October 23, 2015, 01:53:22 pm
content: and can your monkey port ADA to MPU/8bit?and can your monkey execute ADA on DSP?

author: legacy
author_rank: Super Contributor
timestamp: October 23, 2015, 02:01:01 pm
content: Code Complete: A Practical Handbook of Software ConstructionSecond Edition 2nd Edition, Microsoft PressI guess that book is a good point, it contains a lot of "horror-code", including examples of bad (ab)use of the C languageI had a read when I was a student, since then in my job experience I have realized that book has never told lies

author: c4757p
author_rank: Super Contributor
timestamp: October 23, 2015, 02:01:34 pm
content: Quote from: legacy on October 23, 2015, 01:50:01 pmya rlyQuoteThe monkey prefers nuts.

author: autobot
author_rank: Regular Contributor
timestamp: October 23, 2015, 02:32:33 pm
content: I actually believe that c++ will be the language of the future, and as the arduino have shown us, with a limited enough subset of the language , even less experienced people can contribute.That, the safety/simplicity improvements offered by C++14 and the fact we're starting ot see a lot of c++ mcu libraries(for example the new mbedOS), and the fact that it's close to impossible to create good interoperability tools for c++ from other languages, means c++ will rule.As for the future in general - think it will be much more abstracted(and that's where most of the simplification will come from, not the language. BTW this is also true for python, i believe) .We're already seen a lot of work done on abstracting the hardware , and we'll see more, ARM, in the mbedOS is doing good work in abstracting mcu power management behind nice interfaces, and nobody in his right mind could write a secure connected device without really abstracting it (and most devices would be connected, if just for updates when bugs appear, or a nice phone UI).And from the hardware standpoint, we'll see more cost reduction(unless too many mergers kill it) ,more lower power ,so it'll be easy to abstract in many cases.

author: tggzzz
author_rank: Super Contributor
timestamp: October 23, 2015, 02:44:20 pm
content: Quote from: c4757p on October 23, 2015, 01:03:02 pmIn that case either you haven't looked very hard, or you aren't perceptive, or you are very tolerant. There is at least one other possibility, which I won't mention.I would be surprised if you still can't see any problems after readinghttp://yosefk.com/c++fqa/

author: c4757p
author_rank: Super Contributor
timestamp: October 23, 2015, 02:46:32 pm
content: Am I missing the part of that about C? All of what's on there seems to be C++-specific, and I agree with most of it.Quote from: tggzzz on October 23, 2015, 02:44:20 pmStupid? Definitely a possibility. Though out of the choices I'd pick tolerant, I don't really mind a language with a few quirks. Seems every useful language is fairly quirky, anyway. *shrug*

author: tggzzz
author_rank: Super Contributor
timestamp: October 23, 2015, 03:03:26 pm
content: Quote from: c4757p on October 23, 2015, 02:46:32 pmClearly either you haven't read the FQA or you aren't aware of the significant overlap between C and C++.I class "stupid" in the "not very perceptive" category.

author: c4757p
author_rank: Super Contributor
timestamp: October 23, 2015, 03:06:49 pm
content: Clearly.

author: legacy
author_rank: Super Contributor
timestamp: October 23, 2015, 03:24:51 pm
content: Quote from: c4757p on October 23, 2015, 02:46:32 pmyes, I do not hate the C++, I simply do not like that it adds to much complexity to the language, too many features, too bloatedwhileC++14is the best trade off I can think and useI am watching theGo language(never tried in real context) simply because I am impressed, especially by the desire to return to purportedly simpler days of programming. "A common sentiment among Go supporters is that modern languages are too complicated and 'academic', whereas they see Go as a 'working man's' language.

author: legacy
author_rank: Super Contributor
timestamp: October 23, 2015, 03:30:24 pm
content: From C-Chimpanzees to Go-Gopher, Google hopes to remake programming with GoThere is a ne iconic mascot over there, born out of habit of enraged apes of flinging their own feces at their object of anger when they fail to catch nuts because their C language sucks (if you haven't experienced this phenomenon first hand consider yourself blessed). A new specie has come, it's a Go- Gopher, smart enough to be able to grow their acorns.(my humor)Go-pher, iconic mascot, referred togolang, a programming language developed atGooglein 2007"TheGoProgramming Language",Specification,FAQBorn out of frustration with existing languagesand environments for systems (also embedded?) programming when programming had become too difficult, no doubt Google's Go language is off to a great start, but still has work ahead: Go offers speed, concurrence, and portability, but it's still young and might be too simple, it's currently fully supported onLinuxandDarwin/MacOSXand fully integrated in Gcc >=gcc-v4.9(1) as "frontend" connected to the GCC backend. This means that, in the Theory(2), anyGoprogram that you can compile forx86/x86_64should work on Arm, and besidesLinuxandDarwin/MacOSX,Gois also "experimentally supported" onFreeBSDandNetBSD, Go is a new language. Although it borrows ideas from existing languages, it has unusual properties that make effective Go programs different in character from programs written in its relatives. A straightforward translation of a C++ or Java program into Go is unlikely to produce a satisfactory result—Java programs are written in Java, not Go. On the other hand, thinking about the problem from a Go perspective could produce a successful but quite different program. In other words, to write Go well, it's important to understand its properties and idioms.I put emphasis in the above presentation to catch your attention, I'd like to hear some unbiased opinions about(1) you can try to compile gcc withCode:./configure --languages=C,Go(2) It seems that the Go team has written two different compilers that implement that spec:gc, the first one, is the original compiler, and the go tool uses it by default, I guess that having two different implementations helps ensure that the spec is complete and correct: when the compilers disagree, they fix the spec, and change one or both compilers accordingly, It supports only the most popular processors: x86 (32-bit and 64-bit) and ARMgccgo, slower than gc but it supports all the processors that GCC supports. Not all those processors have been thoroughly tested for gccgo, but many have, including { x86/32bit, x86/64bit, SPARC, MIPS, PowerPC }. Gccgo has also been tested on operating systems that the gc compiler does not support, notably Solaris (what about Irix? Aix? who knows?)

author: c4757p
author_rank: Super Contributor
timestamp: October 23, 2015, 03:51:04 pm
content: I'm with you on the golang love. I don't think it's suitable for embedded dev right now - it has things like garbage collection pretty strongly built in - but an embedded variant of it, that's something to consider.Probably not going to happen, and the world probably doesn't needmorerandom variants of languages. But still - it's kinda neat.

author: westfw
author_rank: Super Contributor
timestamp: October 24, 2015, 12:44:38 am
content: QuoteHas there EVER been a successful "embedded variant" of a "modern" programming language? It's not clear that language-designer types UNDERSTAND embedded (or that any two embedded designers can agree on "requirements" in the first place.How about just a well-loved embedded string library? Maybe I'll start a campaign to invent "C with Strings: C||"; hypothesizing that 99% of the horrible C errors "caused by pointers" are actually caused by people having to use pointers to manipulate strings (because there is no good alternative.)

author: c4757p
author_rank: Super Contributor
timestamp: October 24, 2015, 01:05:42 am
content: Quote from: westfw on October 24, 2015, 12:44:38 amI doubt it. Just a brief pipe dreamQuoteYes! C's built-in string processing functions suck.

author: nctnico
author_rank: Super Contributor
timestamp: October 24, 2015, 01:18:56 am
content: Quote from: tggzzz on October 22, 2015, 10:38:22 amIf there is already a solution for the problem you are about to solve then there is no need to re-implement that solution word for word. In other words: design patterns should be something you get from a library or a language construct.

author: krish2487
author_rank: Frequent Contributor
timestamp: October 24, 2015, 07:59:07 am
content: No it isn't and should not be either.I apologise for the deviation.You can have access to all the bricks, mortars, lumber and similar construction equipment and material you want.They will not give you a building plan (design pattern) which you have to follow. The building design decides the equipment and material and the other details.Having design patterns built into the libraries, HALs, glue logic or what other name you want to call it, restricts the applications and/or usage of the language itself. It is a recipe for sureshot disaster. Design patterns are language agnostic and languages are design-pattern agnostic.It is purely dependant on the guy who is writing the code.There is no one solution fits all in our work. The different solutions stem from different requirements. Hence, the need to have different design patterns applied to every problem set.Quote from: nctnico onTodayat 12:18:56 PM>If there is already a solution for the problem you are about to solve then there is no need to re-implement that solution word for word. In other words: design patterns should be something you get from a library or a language construct.

author: tggzzz
author_rank: Super Contributor
timestamp: October 24, 2015, 08:16:49 am
content: Quote from: nctnico on October 24, 2015, 01:18:56 amYou don't understand design patterns, in particular their level of abstraction.I suggest you read the original GoF book, where "Chapter 1 Introduction, page 1" indicates clearly why your statement is not only infeasible but undesirable.(You don't even have to buy the book, you can see it athttp://www.amazon.co.uk/Design-patterns-elements-reusable-object-oriented/dp/0201633612then click on "look inside" and first pages).

author: legacy
author_rank: Super Contributor
timestamp: October 24, 2015, 01:32:01 pm
content: Quote from: westfw on October 24, 2015, 12:44:38 amI have written a pretty safe-library, calledlib_safe_string_v2, you can't be "off by one"(char_t string …. string='@')Code:/idp.do/src/lib_safe_string_v2# cat lib_safe_string_v2.interfaceboolean_t safestring_extract(p_safestring_t p, uint32_t from);boolean_t safestring_append_ch(p_safestring_t p, char_t ch);boolean_t safestring_append(p_safestring_t p, char_t msg[]);boolean_t safestring_let(p_safestring_t p, char_t msg[]);boolean_t safestring_reverse(p_safestring_t p);boolean_t safestring_done(p_safestring_t p);boolean_t safestring_touch(p_safestring_t p);uint32_t safestring_get_len(p_safestring_t p);uint32_t safestring_get_i(p_safestring_t p);boolean_t safestring_new(p_safestring_t p, char_t msg[], uint32_t size);boolean_t safestring_clean(p_safestring_t p);uint32_t undefined_string_get_size(char_t msg[]);boolean_t safestring_show(p_safestring_t p);boolean_t safestring_register_show_method(p_safestring_t p, p_this_t p_show_method);

author: legacy
author_rank: Super Contributor
timestamp: October 24, 2015, 01:33:56 pm
content: a "safe_string" is a struct_typeCode:typedef struct{p_char_t p_data;uint32_t i;uint32_t len;uint32_t size;} safestring_t;C|| should handle strings this way

author: tggzzz
author_rank: Super Contributor
timestamp: October 24, 2015, 01:36:51 pm
content: Quote from: krish2487 on October 24, 2015, 07:59:07 amPrecisely.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: October 27, 2015, 01:55:13 pm
content: Quote from: legacy on October 24, 2015, 01:33:56 pmlooks very similar to the old bstring library by Paul Hsieh.http://bstring.sourceforge.net/

author: legacy
author_rank: Super Contributor
timestamp: October 27, 2015, 03:16:43 pm
content: I started from scratch, I wrote safe_string because I had to support a tokenizer and a parser, and they both had silly bugs, e.g. string was defined char_t string, and the user tried to access the 11th position string='\0'; because he started to count from 1 instead of from 0it also happened string[-2] because the user forgot to check the error code that was used as string indexversion 3, revision 2, adds new interesting functions, e.g.safestring_winlookaheadis very useful for my lib_tokenizer, whilesafestring_get_Cstringis a toy, used to collect everything is between " and "Code:boolean_t safestring_is_ahead_left_anything_to_eat(p_safestring_t p, uint32_t ahead);boolean_t safestring_winlookahead(p_safestring_t p, char_t target[], uint32_t from, char_t win_len);safestring_ans_t safestring_winlookahead2(p_safestring_t p, char_t target[], uint32_t from, char_t win_len);boolean_t safestring__register_show_method(p_safestring_t p, p_this_t p_show_method);boolean_t safestring_extract(p_safestring_t p, uint32_t from);p_char_t safestring_get_data(p_safestring_t p);safestring_ans_t safestring_get_ch(p_safestring_t p);safestring_ans_t safestring_geth_ch(p_safestring_t p, uint32_t i);void safestring_touch_and_rewind(p_safestring_t p);void safestring_rewind(p_safestring_t p);void safestring_reinit(p_safestring_t p);boolean_t safestring_append_ch(p_safestring_t p, char_t ch);boolean_t safestring_append(p_safestring_t p, char_t msg[]);boolean_t safestring_let(p_safestring_t p, char_t msg[]);boolean_t safestring_reverse(p_safestring_t p);boolean_t safestring_done(p_safestring_t p);void safestring_touch(p_safestring_t p);uint32_t safestring_get_len(p_safestring_t p);boolean_t safestring_set_i(p_safestring_t p, uint32_t i);boolean_t safestring_set_i_ahead(p_safestring_t p, uint32_t ahead);boolean_t safestring_set_i_back(p_safestring_t p, uint32_t back);uint32_t safestring_get_i(p_safestring_t p);boolean_t safestring_set_i_next(p_safestring_t p);boolean_t safestring_new(p_safestring_t p, char_t msg[], uint32_t size);void safestring_copy_to_array(p_safestring_t p, char_t array[]);boolean_t safestring_clean(p_safestring_t p);uint32_t undefined_string_get_size(char_t msg[]);boolean_t safestring_show(p_safestring_t p);boolean_t safestring_draft(void);boolean_t safestring_test(void);safestring_ans_t safestring_get_Cstring(p_safestring_t p, p_safestring_t b);safestring_ans_t safestring_get_CIstring(p_safestring_t p, p_safestring_t b, char_t string_markA, char_t string_markB);boolean_t safestring_remove_sub_quote(p_safestring_t p);

author: tggzzz
author_rank: Super Contributor
timestamp: October 27, 2015, 03:56:03 pm
content: Quote from: legacy on October 27, 2015, 03:16:43 pmWithout making any comment on the qualities and merits of your code, I'll note that the C++ world isexcessivelyprone to re-invention of pre-existing wheels. Which IMNSHO is a waste of talent.Another way of observing something similar is to note that papers describing C++ applications and features tend to refer to other C++ papers. In contrast papers describing language X applications and features tend to refer to papers about many other languages. The conclusion is that the C++ world is relatively inbred/parochicial and doesn't understand the broader scope of what has been achieved and can be achieved relatively easily.

author: legacy
author_rank: Super Contributor
timestamp: October 27, 2015, 05:52:19 pm
content: Quote from: tggzzz on October 27, 2015, 03:56:03 pmrelated to strings, the point was- no license for C++ (we were not allowed to use GNU)- too many bugs in the C application I was assigned withI was involved into that fun when I had to support an interpreter included in a product(1) like "ethernet debugger with a built-in C-interpreter (features reduced) that helps you to test your software" (WinRiver sells a similar product, ofcourse more expensive)the tokenizer had too many bugs, 60% located at a very bad porting from the PC's world to the embedded's world (when the previous developer believe that being minded with host=target=PC is fine to develop embedded things). The remaining bugs, the 40%, were related to other wicked things (including a very crap tcp/ip stack)(1) here on forum I have released my personal sources, e.g. my (toy)filesystem, my little interpreter (university homework), my C++ fixed point overload (my first job task), my MIPS R3K monitor (assembler, hobby), etc, Unfortunately my current job has the Copyright about all the code I write for them =(

author: legacy
author_rank: Super Contributor
timestamp: October 27, 2015, 05:55:37 pm
content: corollary: the C language, as-is, has no support for strings, and having directly to deal with array of chars causes too bugs, so we'd better use the divide and impera paradigm, and relegate strings into a library which can be hardly tested and then usedwhat do you think about that? is it correct? It was my solution-line.

author: tggzzz
author_rank: Super Contributor
timestamp: October 27, 2015, 06:40:47 pm
content: Quote from: legacy on October 27, 2015, 05:55:37 pmI have no comment about whether it was the best solution for you. My comments are limited to my previous post.

author: legacy
author_rank: Super Contributor
timestamp: October 28, 2015, 12:40:33 pm
content: Quote from: westfw on October 23, 2015, 07:26:09 amI have read the above sentence and I wonder about thebloated partsofC++in detailsis C++ bloated about the memory allocation? Does a C++ program eat more memory than a C program ? In my experience, it's Falseis C++ bloated about the CPU use? std::sort vs qsort says "False", is there a better example?is C++ bloated because it's "too verbose"? Does it make you to write more and more lines of code to achive the same purpose ?is C++ bloated because it offers too many features?etc ...I am not a fan of C++, I wonder the practical meaning behind the above sentence

author: westfw
author_rank: Super Contributor
timestamp: October 28, 2015, 05:04:10 pm
content: QuoteMostly, it's the "Use the STL features", most of which include dynamic allocation, and very "generalized" code.Did you look at the example I had included with the original message?http://programmers.stackexchange.com/questions/48401/learning-c-properly-not-c-with-classesTheir "good example" is about 60% bigger than their "bad example" (compiled for x86 MacOS.) (for significantly shorter source code size.)In another example, I was helping someone figure out whether their code using Complex numbers would run on an Arduino. The complex class they are using is 24 bytes, and I can't figure out where the third "double" is... (but changing all "double" to "float" does reduce the size to 12.)

author: legacy
author_rank: Super Contributor
timestamp: October 28, 2015, 05:45:13 pm
content: OK, understood, thank you