Author Topic: c vs cpp for stm32  (Read 4069 times)

0 Members and 1 Guest are viewing this topic.

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 2133
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: c vs cpp for stm32
« Reply #75 on: January 17, 2019, 01:55:11 am »
It's fun watching comparisons of programming dick lengths, but what matters, is what the safety standards tell you to use and how to write fail safe code.

One thing is to sour sketchy sketches to arduino in C++, while writing code for a product, that will actually be sold and certified is a completely another.

C++ is not the industry standard for safety concerned applications as far as my knowledge goes, as it is hard to statically analyze for errors. 

Hence why I stick with C and don't care about C++.  cv007 has also posted a nice example of unreadable code.  Who can tell what it's doing? I can't.  But I very likely would, if it would be written in anything else, but a C++.

I work now for almost 5 years in a place, where we review many and many customer application HW and application code. Very very rarely there is something written in a C++.
« Last Edit: January 17, 2019, 01:57:38 am by Yansi »
 

Offline exe

  • Supporter
  • ****
  • Posts: 902
  • Country: nl
  • self-educated hobbyist
Re: c vs cpp for stm32
« Reply #76 on: January 17, 2019, 02:49:32 am »
Hence why I stick with C and don't care about C++.  cv007 has also posted a nice example of unreadable code.  Who can tell what it's doing? I can't.  But I very likely would, if it would be written in anything else, but a C++.

If it was C, it would be pretty much the same abstraction, except the need to reinvent the wheel. Anyway, try this one: https://www.ioccc.org/2018/bellard/prog.c

I work now for almost 5 years in a place, where we review many and many customer application HW and application code. Very very rarely there is something written in a C++.

It's a pity security-critical applications are still written in languages with manual memory management. C++ at least gives some "smart" pointers to partially mitigate the issue, while I'm not aware of such methods available for C. So, I question your security standards. They may be "state approved", but doesn't mean there are no better options.
 

Online cv007

  • Frequent Contributor
  • **
  • Posts: 363
Re: c vs cpp for stm32
« Reply #77 on: January 17, 2019, 02:55:49 am »
Quote
When you look at a painting, do you really care what kind of brush the painter used to paint it? How silly would that be to tell Raphael that if he used different brushes his paintings would be better? Would his paintings be as good as they are if, instead of following his own path, he would worry about what other painters do?
The original poster (or Raphael) asked about using a different brush. Since it was asked, I'm just suggesting that brush x is nice to use, but I'm not telling anyone how to paint and ultimately I really don't care what brush anyone else uses. Just trying to point out good features of brush x.

I'm not trying to sell something, and I'm not on the 'C++ for a better world committee', just trying to suggest another tool in the toolbox may be beneficial. But probably not doing a very good job of it.

Quote
try this one
I think that is the linux serial port driver for my onion omega2 board.
 

Online IDEngineer

  • Frequent Contributor
  • **
  • Posts: 431
  • Country: us
Re: c vs cpp for stm32
« Reply #78 on: January 17, 2019, 03:00:16 am »
Beauty is in the eyes of the beholder. It's the result that matters... When you look at a painting, do you really care what kind of brush the painter used to paint it? How silly would that be to tell Raphael that if he used different brushes his paintings would be better? Would his paintings be as good as they are if, instead of following his own path, he would worry about what other painters do?

Interesting analogy. With all due respect, let's dig a bit deeper.

Art is SUBjective. Artists don't get sued if their painting "doesn't work", now or in the future. The consumer either likes it or they don't.

But Engineering, including code, is OBjective. It can be measured to "work" or "not work". People can be held liable if their code doesn't work, even if that isn't discovered at time of purchase. So unlike artists, Engineers and their employers (should) have a tremendous vested interest in making sure that their code works - and if it's found to NOT work, that it can be quickly and easily fixed by whomever is available.

Now let's consider support. A painting is a solo effort. There isn't a team coming along in a few months or years to "fix" it or add features. The consumer either likes it as-is, or they don't. Today, tomorrow, forever.

But Engineering, including (perhaps especially) code, often has people coming along later to "fix" it or add features. When there's a problem, the employer and the customer are *extremely* interested in resolving it as fast and as inexpensively as possible. That means two things: 1) There is great advantage to using tools that decrease the likelihood of bugs in the first place, and 2) there is also great advantage to using tools that make it as easy as possible for utter strangers to later pick up the code, grok it quickly, find, and fix the problem.

Do downstream "users" of art care about the brushes or the paint? No. But if art were Engineering, they'd care a lot. Example: I recently read an article about matching interior and exterior house paint colors. Paint stores have spectrometers now, so you'd expect a perfect match every time, right? What could possibly go wrong - we're using SCIENCE! And yet the consumers - DIY'ers and professional painters alike - were reporting frustration in the field. The article revealed that what happens is the paint *base* formula is sometimes changed, with the result that the optical absorption spectrum changes too. And this means that the perceived color changes depending upon the type of light source. You can match an old and new color in any single given light (say, incandescent) but when illuminated in sunlight they'll look different. Fluorescent and LED have their own emission spectrums and yield other, different results. Unless you keep an indefinite supply of the same base, and the same pigments, it's likely impossible to match existing paint... you just can't replicate the recipe.

Brushes and paint are the "language" of art, but that language can go extinct as soon as the painting is finished. An artist can literally mix his own paints and build his own brushes, and when he (unilaterally!) declares the project finished he can cavalierly destroy all of his tools without risk. Code doesn't have that freedom. To put it in art terms, your code "painting" has to be objectively without error as judged by people you may never meet personally, and then supported, understood, corrected, and extended by strangers whose background you don't know and can't predict. Those strangers have to be able to understand AND duplicate your paint bases, your pigments, your brushes, and your "style" (architecture) at some indefinite point in the future, probably under intense pressure from their employer and its customers. If art were like Engineering, a painting would have to come with a lifetime supply of base... pigments... maybe even the brushes used. But art has the luxury of being subjective. (Yes, there are art restoration projects, but I daresay those folks would side with the concept of NOT using obtuse and opaque tools! Talk about a nightmare.)

OK, I'll stop extending the analogy. In short, art doesn't have to worry about being measured or providing support. Code does. A wise software author plans for this in advance and chooses his tools and architecture to be the easiest to read, understand, debug, and extend. And as a personal request: He also includes at least one line of comment next to every line of code, dagnabit!!!  >:(  We're not time-traveling mind-readers, lend us a hand, will ya?
My political litmus test: I will vote for any candidate, regardless of party affiliation or positions on other issues, who promises to abolish the TSA.
 

Online Nerull

  • Frequent Contributor
  • **
  • Posts: 542
Re: c vs cpp for stm32
« Reply #79 on: January 17, 2019, 09:50:38 am »
It's fun watching comparisons of programming dick lengths, but what matters, is what the safety standards tell you to use and how to write fail safe code.

One thing is to sour sketchy sketches to arduino in C++, while writing code for a product, that will actually be sold and certified is a completely another.



It's funny, I've seen that exact argument used for why no one should ever program in a memory-unsafe language like C (or C++).

Embedded programming has mostly benefited from airgap isolation protecting it from exploitable flaws - you can be certain there is as much hot garbage code written in C in embedded systems as in any other language.
« Last Edit: January 17, 2019, 09:54:54 am by Nerull »
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 1858
  • Country: si
Re: c vs cpp for stm32
« Reply #80 on: January 17, 2019, 05:27:28 pm »
You can write bad code in any language: assembler, C, C++, C# etc

Its the job of the programmer to make clear and readable code, the language just provides him with the tools to do that.

Assembler is obviously horrible here since it has basically no real structure to it. Then C gives you the fundamental tools for structuring code, but then C++ and C# upgrade on that and give you a huge wide diverse set of tools to structure your code almost anyway you want.

So it must be possible to write the cleanest code in C++ or C#. The problem is that most programmers are NOT good at what they do. They learn certain features of a language like C++ and develop them in there specific coding style, sometimes it works, but other times its pushing a square peg in a round hole where language features are misused or abused to get them to do that they want. It only gets worse with teams of programmers. Put 5 of these programmers into a team project and suddenly every part of the project is written in 5 completely different styles. The code ends up separated in these 5 bubbles that each on there own seam reasonable, but then they are reaching into the other bubbles in strange tangled ways that nobody truly understands because that programmer never understood how the other guys 'bubble' really works.

With C there is so little features that the programmers tend to learn most of them and so end up using the right feature for the right job rather than forcing in a language feature that they happen to know or like.

In the hands of a good programmer C++ is definitely the better tool. It can be just as fast and efficient while structuring code much better. But when you hand C++ to a bad programmer it just makes these code even more of a horror show.

 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 1284
  • Country: 00
Re: c vs cpp for stm32
« Reply #81 on: January 17, 2019, 06:34:28 pm »
In the hands of a good programmer C++ is definitely the better tool. It can be just as fast and efficient while structuring code much better. But when you hand C++ to a bad programmer it just makes these code even more of a horror show.

But when you hand C to a good programmer it just makes these code more fast and efficient.
The difference between theory and practice is less in theory than
the difference between theory and practice in practice.
Expensive tools cannot compensate for lack of experience.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 1858
  • Country: si
Re: c vs cpp for stm32
« Reply #82 on: January 17, 2019, 06:56:40 pm »
You can compile most C code in a C++ compiler just fine and it will run at roughly the same performance.

The trick to keeping C speed is to only use features of C++ that can be statically optimized during complication. But good luck explaining that to the typical C++ programmer that has no idea of what is the difference between the stack and heap. C++ is doing all the memory management for them anyway.
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 2823
  • Country: us
Re: c vs cpp for stm32
« Reply #83 on: January 17, 2019, 10:28:22 pm »
Quote
Assembler is obviously horrible here since it has basically no real structure to it.  :
but then C++ and C# [let you] structure your code almost anyway you want.
Code structured "any way you want" is almost as bad as code with no real structure at all, what with 50% of programmers having below-median skill.
At least with assembler, the chances are pretty slim that a program will be stealthily bloated and slow.

Quote
"you may know how to use C++ wisely, but after the code is turned over to my team, they will do stupid things which they couldn't do in C, so I insist that you write the code in C."  He had a point.
Oh yes!  We used that argument against going to C++ at some point: "it's too easy to accidentally shoot yourself in the foot."
For example, this was recently posted:
Code: [Select]
std::array<uint8_t, 30> buffer;
buffer.fill(0x55);
That actually looks pretty nice.  And I read up on "array" and it doesn't seem bad at all.But if someone were to come along and not pay attention, and use instead ("because it's shorter, and a vector and an array are the same, right?"):
Code: [Select]
std::vector<uint8_t> buffer(30, 55);
It might suddenly be very painful, on an embedded system.

 

Offline exe

  • Supporter
  • ****
  • Posts: 902
  • Country: nl
  • self-educated hobbyist
Re: c vs cpp for stm32
« Reply #84 on: January 18, 2019, 12:24:29 am »
Code structured "any way you want" is almost as bad as code with no real structure at all, what with 50% of programmers having below-median skill.

I believe that meant "structured the we way the project needs".

At least with assembler, the chances are pretty slim that a program will be stealthily bloated and slow.

Good luck with supporting a big assembler project. It's fast in runtime, but very slow in development (and, I guess, expensive).

But if someone were to come along and not pay attention

Oh, c'mon, C provides plenty of ways to shoot oneself in the leg.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 3638
  • Country: 00
Re: c vs cpp for stm32
« Reply #85 on: January 18, 2019, 12:39:08 am »
I believe that meant "structured way the project needs".

we need modularity in the first place, meaning that each module needs to define its interface in term of signed/unsigned, range, max use of the stack, behavior in case of problems, e.g. does it trap on overflow?) and error propagation.

Good luck with supporting a big assembler project. It's fast in runtime, but very slow in development (and, I guess, expensive).

AmigaOS-classic and RISCOS {1,2,3} is an example of Kernel and filesystem developed in (macro)-assembly.

DrDobbs is another source of examples.

The firmware on my Z80-spectrometer was entirely developed in (macro-)assembly, and it contains a lot of complex algorithms.

My 68332 spectrometer's firmware was developed in C, and I know that Avocet was used for this.

Our AFDX switches were initially developed in C++, but avionics certifications and related stuff have recently pushed guys back to C so our new products are developed with C.

The C++ experience failed for us  :-//
the Bunker is open!
(shortcut)
 

Offline exe

  • Supporter
  • ****
  • Posts: 902
  • Country: nl
  • self-educated hobbyist
Re: c vs cpp for stm32
« Reply #86 on: January 18, 2019, 01:04:29 am »

Our AFDX switches were initially developed in C++, but avionics certifications and related stuff have recently pushed guys back to C so our new products are developed with C.

The C++ experience failed for us  :-//

It's inverse of "survival bias". There are tons of successful cpp project. Afaik space-x uses cpp.

Also, even if a program works well from user perspective, it doesn't mean it's good code. It means it's well tested. I'm pretty sure many "successful C project" are unreadable mess inside.

A special case is when it comes to special requirements. I'm fine if cpp is forbidden in military or space environment (but again look at space-x). It doesn't automatically means that it's bad. Even if it fails some requirements, most projects do not expose such requirements. So, should I drop c++ and rewrite my code just because someone works in environment where it is forbidden? Not at all!
 

Offline Otatiaro

  • Regular Contributor
  • *
  • Posts: 85
Re: c vs cpp for stm32
« Reply #87 on: January 19, 2019, 12:12:37 am »
Hello,

For example, this was recently posted:
Code: [Select]
std::array<uint8_t, 30> buffer;
buffer.fill(0x55);
That actually looks pretty nice.  And I read up on "array" and it doesn't seem bad at all.But if someone were to come along and not pay attention, and use instead ("because it's shorter, and a vector and an array are the same, right?"):
Code: [Select]
std::vector<uint8_t> buffer(30, 55);
It might suddenly be very painful, on an embedded system.

But is someone were to come along and not pay attention, and use instead ("because it's more modern, and programming languages are the same, right?") : javascript
It will suddenly be extremely painful, on an embedded system.

Programming languages are tools, and the result depend on the way you use it, that's for sure.
BUT like I said, in our framework we override the default "new" with an error basically saying "nope, you most probably are not doing it right". Then if you try to instanciate a vector at runtime with default allocator it would fail and explain you why.
Last time I tried to override malloc in C, the compiler didn't understand what I was trying to do ...

Thomas.

PS : weird for somebody who didn't know about std::array, to compare it with the more advanced std::vector ... this is basically why I prefer to train C++ to a good (open minded !) C programmer rather than a good PC C++ programmer. The C programmer will have to learn new things, the PC C++ programmer thinks he already know how to do it. Except Embedded C++ is different from PC C++.

PS 2 : I created a discord channel named EmbeddedC++ to discuss the matter (I mean benefits and how to use C++ for embedded programming, not the C vs C++ debate) : https://discord.gg/DGTr4Cg
 
The following users thanked this post: andyturk, exe, lucazader

Online westfw

  • Super Contributor
  • ***
  • Posts: 2823
  • Country: us
Re: c vs cpp for stm32
« Reply #88 on: January 19, 2019, 08:59:55 pm »
Quote
weird for somebody who didn't know about std::array, to compare it with the more advanced std::vector
yes, well...  I'm very much an ASM or C programmer trying to learn new things.  So my C++ exposure comes from Arduino, a couple of online classes (mostly of the "beginning C++" variety, but also one attempt at "C++ for C programmers", which would have been pretty good if the teacher had been better, I guess), and a book or two.Which has meant:
  • STL isn't present (ie Arduino)
  • The STL components that have simpler "pure C" equivalents (like arrays) are not stressed.
  • The "neater" STL components are mentioned.  Especially Strings, of course.
  • Whenever I look at actual STL code, I'm immediately presented with horribly unreadable levels of abstraction using language features that haven't been mentioned, and (I guess) standardized "styling" that I haven't seen before. :-(
  • My general impression of the STL is that it's full of exception processing, dynamic allocation, localization, and other stuff that ranges between "not relevant" and "a bad idea" on the class of program I use.
I was relatively impressed to find something relatively simple like "array."  Although perhaps it's a good thing I didn't look at its source code before saying good things about it :-)
Code: [Select]
       void
      fill(const value_type& __u)
      { std::fill_n(begin(), size(), __u); }


// Element access.
_GLIBCXX17_CONSTEXPR reference
operator[](size_type __n) noexcept
{ return _AT_Type::_S_ref(_M_elems, __n); }

constexpr const_reference
operator[](size_type __n) const noexcept
{ return _AT_Type::_S_ref(_M_elems, __n); }


 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 3638
  • Country: 00
Re: c vs cpp for stm32
« Reply #89 on: January 20, 2019, 12:03:11 am »
Afaik space-x uses cpp.

umm, is C++ suitable for Avionics? Maybe, in theory ...

let's check what it meant in my personal experience: we do civil and military flight boards for aircraft(1), and the being suitable for Avionics practically means to be able to satisfy DO-178B Level A-B, whose benefits is that it provides neat criteria for when it is ok to stop testing.

It's more complex than this, but basically, the criteria are mainly based on achieving certain code coverage thresholds based on the criticality of the software. The criticality is determined by assessing the worst possible consequences of software malfunction.

Guys in the quality assurance office look at the maximal stack usage, which is easy to be tested and verified in our laboratories by specific test-cases and ICEs.

This is not easy to be verified with C++ ... and requires more time and effort.

Besides, you also have to prove by specific test-cases that your compiler does not generate untraceable code in your specific context.

C++ generates a lot of untraceable code, and you have to manually prove that it's correct. "object level coverage" is required, and the traceability study requires more time and effort.

Ada is largely better than C++ in this because it provides traceability analysis packages for DO178/* && COTS traceability study for similar purposes, so we prefer Ada for the high level.

Code: [Select]
is_approved=False;
while(is_approved isNotEqualTo True)
{
    is_ok=False;
    while(is_ok isNotEqualTo True)
    {
        development(project);
        is_ok=testing(project);
    }
    is_approved=QA(project);
}
commit(project);

Anyway, combining MISRA+DO178B, C-sources become really neater and easy to be read since one of the goals of the process is involving people with different skills (system designers, developers, testing guys, quality assurance guys) at reading the source: if they don't find it comfortable and understandable the project is not approved.



(1) I am involved in the development of AFDX switches, STAP/*, ARINC 424, ARINC 664, etc ... which I autonomously develop and I cannot test by myself (you cannot test what you develop by yourself) but for weird reasons I usually end at testing things developed by my colleagues... and, worse still, I am mainly involved only in the testing team for the flight boards ...
... so, in a way, or in the other, I am the one that ends suffering at testing things (d'oh) :o
« Last Edit: January 20, 2019, 12:20:13 am by legacy »
the Bunker is open!
(shortcut)
 

Online IDEngineer

  • Frequent Contributor
  • **
  • Posts: 431
  • Country: us
Re: c vs cpp for stm32
« Reply #90 on: January 20, 2019, 01:30:37 am »
reading the source: if they don't find it comfortable and understandable the project is not approved.

That may be the smartest software evaluation criteria ever. And reinforces my points regarding things like overloading, dynamic polymorphism, etc. Sure, the guy who wrote it in real time might understand what he meant at the time, but do you really want to be the poor sucker whose job it is to figure out what that first guy meant to do, but failed to do properly? Was it his code? Or did he assume that the equal sign was overloaded to some other functionality in this context, when it wasn't? Or the equal sign really IS overloaded like he thought, but someone downstream forgot to specify that library so the development environment compiled and linked "successfully" but does something "differently correct" today?

Quote
you also have to prove by specific test-cases that your compiler does not generate untraceable code in your specific context. C++ generates a lot of untraceable code

Boy, that's got to be fun with dynamic polymorphism.
My political litmus test: I will vote for any candidate, regardless of party affiliation or positions on other issues, who promises to abolish the TSA.
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 3638
  • Country: 00
Re: c vs cpp for stm32
« Reply #91 on: January 20, 2019, 01:42:28 am »
Boy, that's got to be fun with dynamic polymorphism.

was it sarcasm, ain't it?  :D
the Bunker is open!
(shortcut)
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 889
  • Country: us
Re: c vs cpp for stm32
« Reply #92 on: January 20, 2019, 01:57:18 am »
I was relatively impressed to find something relatively simple like "array."  Although perhaps it's a good thing I didn't look at its source code before saying good things about it :-)
Yeah, no kidding! Much of the C++ standard library is terrifying to look at in source form. But in lots of cases now, the abstractions represented are quite useful for embedded code and not particularly leaky. I use std::array frequently in code for microcontrollers, but only reach for things like std::vector and std::map in unit tests, where they can be super handy.

To me, modern C++ is all about hacking the compiler from within the language itself. It gives a C++ user the ability to do things that only a compiler writer or language implementer can do in other languages. But if you're going to do that well, you need nearly a compiler writer's level of understanding of what C++ is doing. There are two execution envirionments: one on the target, and one inside the compiler itself.

For a tiny example, I've been working on a Bluetooth project recently and never liked the static arrays of byte values that people typically use to represent a UUID. I really wanted to be able to use the "human readable" string format for UUIDs in code, but have those magically translate into packed 16-byte arrays. E.g.,

Code: [Select]
const UUID my_bluetooth_service = "268cf9ec-1269-41fb-b6ca-1fd6552468d3";

instead of the more typical:

Code: [Select]
const uint8_t my_bluetooth_service[16] = {
  0xd3, 0x68, 0x24, 0x55,
  0xd6, 0x1f, 0xca, 0xb6,
  0xfb, 0x41, 0x69, 0x12,
  0xec, 0xf9, 0x8c, 0x26,
};

Turns out it's actually possible to do compile-time parsing of string literals and have a class definition convert the human readable syntax into the same 16 bytes at compile time. That's cool!
 
The following users thanked this post: hans

Offline legacy

  • Super Contributor
  • ***
  • Posts: 3638
  • Country: 00
Re: c vs cpp for stm32
« Reply #93 on: January 20, 2019, 02:11:28 am »
That's cool!

That's crap. Now, try to imagine that you have to verify this shit with a formal tool (you are not authorized to hack it, neither you have the source) that doesn't understand it. You know how it ends?

You have to move your ass to the laboratory, take a goddamn ICE, connect it to the target, load the hex, fill breakpoints here and there, and everything and logging in a file what the compiler has done.
the Bunker is open!
(shortcut)
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1018
  • Country: nl
Re: c vs cpp for stm32
« Reply #94 on: January 20, 2019, 02:19:21 am »
That's cool!
You have to move your ass to the laboratory, take a goddamn ICE, connect it to the target, load the hex, fill breakpoints here and there, and everything and logging in a file what the compiler has done.


Huh what? Don't have access to tools that can disassemble ELF files and read symbols from there?
C++ also offers static_assert, which gives a compile-time sanity checker for your code. Trivial checks such as the blow up of struct/class sizes, but also the output of these compile-time manipulations can be put in there.

Then you have unit tests for single-stepping through code, static_assert to prevent cross-compilation regressions, and inline assertions for run-time debugging (in unit-tests and potentially on the device) plus providing hints for static checkers (although most formal checking tools need loads more info to work by any stretch of the imagination - and you'd be damned if you use any kind of loop).

Programming a device really only should be necessary to check the timing of your program.
 

Online cv007

  • Frequent Contributor
  • **
  • Posts: 363
Re: c vs cpp for stm32
« Reply #95 on: January 20, 2019, 02:26:45 am »
Quote
Turns out it's actually possible to do compile-time parsing of string literals and have a class definition convert the human readable syntax into the same 16 bytes at compile time. That's cool!
or a morse code table in '.' and '-'
https://github.com/cv007/Samd10XplainedMini/blob/090811cc730fe7f14f55f9a0aee69444a7f51264/Morse.cpp#L13

not difficult to find the result, either if wanted-
Code: [Select]
arm-none-eabi-objdump -d Blink.elf | sed '/morse_table>:/,/^$/!d'
00000d0c <_ZL11morse_table>:
 d0c:   04080201 0304040a 04020100 04000306     ................
 d1c:   04070200 04040305 02020203 04060307     ................
 d2c:   0302040d 01010300 04010301 04090303     ................
 d3c:   040c040b 050f051f 05030507 05000501     ................
 d4c:   05180510 051e051c 00000000              ............


or to create a wide char for a string descriptor when wide character size needs to be 2 bytes-
https://github.com/cv007/PIC32MM_Curiosity_CPP/blob/ef60556c57d663875b1e816b69e780309345d1dd/USB/UsbCdcAcm.cpp#L12
(although needed #define macro help also, but  there may be a way without)

lots of uses, just takes a new way of thinking which can be a little difficult
 

Offline legacy

  • Super Contributor
  • ***
  • Posts: 3638
  • Country: 00
Re: c vs cpp for stm32
« Reply #96 on: January 20, 2019, 02:34:54 am »
Huh what? Don't have access to tools that can disassemble ELF files and read symbols from there?

This is not good to convince QA guys to accept your work. They do not want to disassemble anything (neither they have the skill to do it), they have to look at test-reports, so you have to go to the lab and produce documents that they are willing to consider.
the Bunker is open!
(shortcut)
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 889
  • Country: us
Re: c vs cpp for stm32
« Reply #97 on: January 20, 2019, 02:38:18 am »
That's crap. Now, try to imagine that you have to verify this shit with a formal tool (you are not authorized to hack it, neither you have the source) that doesn't understand it. You know how it ends?

You have to move your ass to the laboratory, take a goddamn ICE, connect it to the target, load the hex, fill breakpoints here and there, and everything and logging in a file what the compiler has done.
Whoa there cowboy! I'm not writing stuff where people might die. We don't need formal verification. And I'd wager that most of the STM32 projects out there (which is how this thread got started) don't need the kind of process or formal approach that your work requires.

My unit tests are much less rigorous than your formal verifications. But so what? That has little to do with the language itself and more to do with the project and its goals.
 
The following users thanked this post: hans

Offline legacy

  • Super Contributor
  • ***
  • Posts: 3638
  • Country: 00
Re: c vs cpp for stm32
« Reply #98 on: January 20, 2019, 03:49:13 am »
yup, I was simply summarizing a part of what got pubblished by CAS-T (Certification Authorities Software) Team:

Quote
C++ in DO-178B-compliant applications, see CAST paper number #8

[..]
Many C++ features, if not properly controlled and verified, can result in software code that is non-deterministic, unused, or difficult to verify, and whose configuration can change depending on the runtime state of the system
[..]

So we have collected FAA strongly recommendations {1992, 1998, 2002, 2010, 2014, 2018, ...} using RTCA/DO-178B as the vehicle to demonstrate that software is airworthy, and *if* the verification to DO-178B objectives is a labor-intensive effort since an engineering team + testing guys will spend between one and four hours verifying each line of code to demonstrate compliance to Level A, *the C++ DO-178B compliance* is more onerous because of the potentially complex nature of C++ code.

What I want to make it absolutely clear is that *hipster* features such as inheritance, overloading, and polymorphism will complicate traceability and structural coverage, and potentially lead to code that contains latent defects of unexplored behavior!


In short, due to the lack of standard guidance and tools rules leads many certification representatives to review an applicant closely who is using C++, which can result in project delays or rework.

Talking about my specific experiences with the AFDX switches and alike, I can model the process with the following piece of pseudo-C-code:

Code: [Select]
uint32_t subrelease;
uint32_t minrelease;

minrelease = 0;
subrelease = 0;
is_approved=False;
while(is_approved isNotEqualTo True)
{
    is_ok=False;
    while(is_ok isNotEqualTo True)
    {
        development(project);
        /*
         * draf version
         * tools are employed
         * to assist in satisfying
         * DO-178B objectives
         */
        is_ok=testing(project);
        subrelease++;
    }
    is_approved=QA(project);
    minrelease++;
}
commit(project);

Let's consider variables before is_approved becomes equal To True
  • with C approach, minrelease=5 subrelease=13
  • with C++ approach, minrelease=11, subrelease=43
  • with Ada approach, minrelease=3, subrelease=15

the less-interactions a project takes to pass the QA the best it is, so I can claim that in my experience a C++ project was usually approved with more internal activities on the draft version and more interactions with the QA team before a commit :palm:

Note that a premium value for this is that Ada comes with better standard guidance and tools rules so it's usually approved by QA at the third attempt. This also thanks to Stood, a tool that is used to model the Ada core, so it's more consistent with the initial design. This makes good points for preferring it, even if ... the designing, planning, development, and testing usually takes a longer time than C, but not the time required by C++.
the Bunker is open!
(shortcut)
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 889
  • Country: us
Re: c vs cpp for stm32
« Reply #99 on: January 20, 2019, 03:59:30 am »
What I want to make it absolutely clear is that *hipster* features such as inheritance, overloading, and polymorphism will complicate traceability and structural coverage, and potentially lead to code that contains latent defects of unexplored behavior!
Oh My God! That's horrible!
</sarcasm>

Quote
Note that a premium value for this is that Ada comes with better standard guidance and tools rules so it's usually approved by QA at the third attempt. This also thanks to Stood, a tool that is used to model the Ada core, so it's more consistent with the initial design. This makes good points for preferring it, even if ... the designing, planning, development, and testing usually takes a longer time than C, but not the time required by C++.
Ada sounds like an ideal tool for the kind of work you do. Maybe you should start a thread on Ada?  >:D
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf