C++ Function Template Parameters

[thestumbler]

(I will probably make some mistakes with the terminology in this post, as I am new to some of these concepts and still learning by example.)

I understand on the surface how MODM specifies compile-time parameters using function template parameters. Some of the results are boggling like the UART speed calculations. Let's consider a simpler example, like the Chip Select parameter used in a few of the register access functions of the recently added SPI / DMA example for the Nucleo H723 board. I can wrap my head around this, and it makes sense.

I am porting some C++ code for the Wiznet W5100s's Arduino library into MODM. This approach is a compromise between (1) the resulting kludge if you tried to shoehorn Wiznet's C library into MODM, and (2) the daunting task of rewriting the entire large library of functions from scratch.

The Arduino C++ library is organized so that the hardware specific interactions are not too difficult to swap out (actually the Wiznet C library is a bit better in that regard). One thing they did was to generate a dozen or so pairs of functions for reading / writing each register. For example, readMR() and writeMR(), etc. Thess repetitive function definitions are done using the preprocessor. I'm not one to shy away from cryptic preprocessor incantations, but only when I can't find a "normal" way to accomplish the task. This method seems out of place in a C++ program.

I tried to replace this approach with function template parameters, like the above mentioned example. It was a steep learning curve, but I tentatively determined that my goal was impossible. When you pass something like GyroCs as a function parameter, that is a class known at compile time. In my case, I wanted to pass a certain register instead. For example, AccRegister::Status. As it took me some time to discover, you can't do that. I think.

I ended up passing the register name at runtime to a handful of functions, equivalent to the original Arduino code's preprocessor macros. And in hindsight, this is probably good enough.

Question 1: in one search result on this topic, I read that in C++23(?) you can now use certain non-class, constant parameters to a function template. I tried briefly and failed, so I ran with a different approach. Are there any such examples in MODM of passing a non-class parameter?

As everyone says, C++ compiler error messages are a pain to read. My normal flow has been to pipe them to junk.cpp and view that in my editor (being sure to delete this file before rebuilding). I discovered that VSCode has slightly easier to read error messages. But, the main focus of my edits are in MODM itself because I'm basically adding a new driver to the ETHERNET group. I'm not a daily VsCode user, and setting up a multi-project solution is non-trivial for me.

Question 2: Are there any examples of a MODM application in VsCode that deals with the separate nature of the MODM library and the LBUILD BUILD step?

[rleh]

For example, AccRegister::Status. As it took me some time to discover, you can't do that. I think.

This is possible with C++, see here in the Compiler Explorer demonstrated.

[thestumbler]

Because it is an ENUM, the complier knows that it can't change at runtime. Right?

[salkinium]

1. Not sure, I'm not up-to-date on C++, since I mostly write Python nowadays. I would stick with the normal runtime arguments. If you're willing to share code, I can have a look though.

2. You would develop your drivers in your application and only at the last step move them into modm, if at all.
   Alternatively you can use lbuild build --symlink, which will symlink the file whenever possible (ie. when not using a template). Then you can edit it in VSCode directly and it reflects back into modm. But be warned: I sometimes still edit non-symlinked templates and then that code disappears on the next lbuild build.

[thestumbler]

Yeah, I tried briefly to develop the driver outside of MODM locally in my project, and couldn't get it working after a few attempts, and decided to plow ahead developing it inside MODM. These new driver files are basically clones of the four BMI088* driver files but the details are changed for WizNet. It's made more complicated because those files use the SPI driver as well. I was (am) facing so many hurdles just grasping the "advanced" C++ that I didn't want to add one more headache.

Anyway I've 90% done with the driver file and will be focusing on the TCP/IP and application code next, which will be in the project folders.

[chris-durand]

@thestumbler Is it that library: https://github.com/arduino-libraries/Ethernet/blob/master/src/utility/w5100.h ?

There is a "utility" folder with two files "w5100.h" and "w5100.cpp". As far as I can see those are the only ones with a direct dependency on the hardware. All other source files access the device through a global variable declared as extern W5100Class W5100; in "w5100.h".
You can basically swap the files in folder utility with your own modm implementation of the driver. Replace W5100Class with anything you like, as long as it has the same interface as the original class and you create a global instance in variable W5100.

Of course all the other Arduino library dependencies have to be dealt with as well.

[thestumbler]

Yep. That's the one. Actually it's confusing because there are two different repositories, one in Arduino's GitHub and another in WizNet's. And they're different. I'm using the Arduino one -- it seems newer, although I'm not clear why/how they are different. I figure that I'll deal with that down the road as needed.

I am basically taking the approach you've outlined. The trick was separating out the Arduino interactions. It was not that difficult, but there wasn't a single module you could carve out. But those calls were limited in number and clearly documented in the Arduino API online.

I probably made more work for myself, but I really didn't like all those register-unique read/write functions that were generated by preprocessor macros. I replaced them with a bunch of explicit one-line function definitions.

For example, the W5100 utility class provides a bunch of functions like writeMR() rather than one function write(MR,...). Those unique register functions are used by all the application examples, so I wanted to preserve them. I will note that an application could / can still call them using generic calls, but I wanted to maintain compatibility with existing example code.

I also took out the parts where the code decides what kind of chip it's talking to, and hard coded it as the W5100s, realizing that it is something that may need to be added back down the road.

[chris-durand]

To question one: Here is a minimal example for non-type template parameters used with a function template. Not sure, if this will be helpful for your problem.

[thestumbler]

Well that example is what's already happening in the source code I'm using as a starting point (it uses a chip select GPIO parameter). My question was how to pass a structure member, and @rleh sent an example of that yesterday -- also on Godbolt compiler explorer!

Part of my problem is that I've been impatient and plunged ahead, assuming I can just learn these features by example. In hindsight I probably should have slowed down and studied first.