`std::format` and by extension `std::print`/`std::println` are actually extensible just as well as iostreams (take a look at `std::formatter`), even allowing for custom format options which was not possible with iostreams.
The custom shift operator overloads shown at 39:13 can actually also be done for std::iostream. These are normal operator overloads and thus are discovered by the overload resolution if they are declared in the same namespace as the (second) argument or as the caller.
I think that the overload/redefinition of std::chrono::highresolution_clock::now() presented at 52:40 is not allowed by the standard and maybe not even possible.
I think it is not optimal to configure pins one by one in a loop, it is basically writes few bits (via read, bitwise-OR, write) into the same MMIO register again and again. What I do is I calculate a bunch of registers values (during compilation) and write those constants into MMIO registers. If it takes 10 registers to configure GPIO, it takes 10 writes then. No loops, no bitwise-OR.
But do you need this to be optimal? Correct me if I'm wrong, but you configure IO pins is once in a lifetime of a program, so i doesn't matter if you save couple of writes.
@@wojtekburzynski654 it might be important to put the IO pins into a safe and known state as fast as possible, depending on your application and/or hardware.
The code presented at about 28:30 centainly does not work at all. There are useless lines like "index == 1;" and a wrong mix up of 'index' and 'count' for 'result.mData' and 'text'. Finally, to parse a hex string to bytes, two characters need to be combined to a single byte. Can not see this happinging anywhere in the code.
@@destiny_02believenes has nothing to do with reality. (have a look at c++ standard section 28.7.1 Header synopsis). on g++ compiler it's accepted because the internal implementation of std::pow is based on internal __builtin_pow functions. Just take a simple code: constexpr auto i = std::pow(2.0, 3.5); on g++ is going to compile, on clang++ and msvc compilers, the compilation fails. The approach presented in the talk is not supported by the c++ standard.
@@nextlifeonearth It is not really an oversight. Overall, it is just not as easy as it seems. The math functions can have side effects, like setting the errno variable for certain input values. A constexpr function can not set errno.
True, but there are hundreds of companies that still use the most basic approaches from the 90'. The presenter shows here a much modern way - that's why it is important to have those sessions.
@@peterfistin8584 habitual reminder that this wasn’t because of backwardness, but because up until ARM became the de facto standard, most C++ compilers had no guarantees about supporting features past C89.
Many embedded engineers write C++ code as C with a C++ compiler. Introducing neat modern C++ practices for embedded programming bring net benefits to every one.
@@mapron1 True, I’m one of them 🤣 Been involved in a dozen of companies, in safety critical applications…the core functionally was always C, and only some fancy libraries were C++, but as you’ve said, we’ve been using the C++ in a very simple way. It makes sense, if you think about it. I think that C allows us to understand easily the propagation of a signal from hardware to the topmost application layer.
5:28 Declarative GPIO
16:15 Compiler-driven lookup table generation
23:21 Address-like structures
31:00 Lean stream-based I/O
40:55 Using heap in embedded applications (arena allocators)
50:23 Unlock std::chrono
54:56 Unlock std::random
`std::format` and by extension `std::print`/`std::println` are actually extensible just as well as iostreams (take a look at `std::formatter`), even allowing for custom format options which was not possible with iostreams.
Really liked the readable numeric structures.
Thank you for your time.
Nice talk and great tips, thanks!
The custom shift operator overloads shown at 39:13 can actually also be done for std::iostream. These are normal operator overloads and thus are discovered by the overload resolution if they are declared in the same namespace as the (second) argument or as the caller.
That is clear, but he got rid of std::iostreams because they are too expensive (talking about binary size) for an embedded device.
why have not used enum class? why not put & in to const std::array coeff?
thank you for such great hints
How does the LUT table work when the coefficients are pulled from the factory calibration data stored in micro?
I think that the overload/redefinition of std::chrono::highresolution_clock::now() presented at 52:40 is not allowed by the standard and maybe not even possible.
So title changed. And I thought I missed talk "Modern C++ to Impress Your Embedded Dev Friends" :-)
I think it is not optimal to configure pins one by one in a loop, it is basically writes few bits (via read, bitwise-OR, write) into the same MMIO register again and again. What I do is I calculate a bunch of registers values (during compilation) and write those constants into MMIO registers. If it takes 10 registers to configure GPIO, it takes 10 writes then. No loops, no bitwise-OR.
I'm curious how you did that. Can you share some code ?
But do you need this to be optimal? Correct me if I'm wrong, but you configure IO pins is once in a lifetime of a program, so i doesn't matter if you save couple of writes.
@@wojtekburzynski654 it might be important to put the IO pins into a safe and known state as fast as possible, depending on your application and/or hardware.
@@HelderParracho so as always... use proper tool for a job
19:53 are these actually are going to be evaluated at compile time? since std::pow is not constexpr?
It will be constexpr in C++26, it's not hard to write your own
Very useful talk, especially for those with a C background, but yes we know what Proctor & Gamble do....... skip the first 4 minutes
Great talk!
The code presented at about 28:30 centainly does not work at all. There are useless lines like "index == 1;" and a wrong mix up of 'index' and 'count' for 'result.mData' and 'text'. Finally, to parse a hex string to bytes, two characters need to be combined to a single byte. Can not see this happinging anywhere in the code.
Thank you!
19:30 std::pow is _not_ `constexpr`...
I believe it is in C++23
@@destiny_02believenes has nothing to do with reality. (have a look at c++ standard section 28.7.1 Header synopsis). on g++ compiler it's accepted because the internal implementation of std::pow is based on internal __builtin_pow functions. Just take a simple code: constexpr auto i = std::pow(2.0, 3.5); on g++ is going to compile, on clang++ and msvc compilers, the compilation fails. The approach presented in the talk is not supported by the c++ standard.
@@peterlauro9222 IMO pretty much all functions in cmath should be constexpr and if they aren't, it's an oversight.
@@nextlifeonearth It is not really an oversight. Overall, it is just not as easy as it seems. The math functions can have side effects, like setting the errno variable for certain input values. A constexpr function can not set errno.
First time I heard for resistor divider.
This talk is more like "c++ basics that might impress a first year CS student"
True, but there are hundreds of companies that still use the most basic approaches from the 90'. The presenter shows here a much modern way - that's why it is important to have those sessions.
Embedded programmers (at least all I knew) usually use C++ as C with classes/destructors. So anything beyond that will be an impression for them.
@@peterfistin8584 habitual reminder that this wasn’t because of backwardness, but because up until ARM became the de facto standard, most C++ compilers had no guarantees about supporting features past C89.
Many embedded engineers write C++ code as C with a C++ compiler. Introducing neat modern C++ practices for embedded programming bring net benefits to every one.
@@mapron1 True, I’m one of them 🤣
Been involved in a dozen of companies, in safety critical applications…the core functionally was always C, and only some fancy libraries were C++, but as you’ve said, we’ve been using the C++ in a very simple way. It makes sense, if you think about it. I think that C allows us to understand easily the propagation of a signal from hardware to the topmost application layer.