Okay, so this is getting really long, I'll put the ask up front: I have a strategy, I think it is reasonable. Now is a point where I can easily change things, and it won't be so easily later. So I'm looking to see if anyone has trod this road before and can recommend any of:

1. a different build system that will be easier to manage for this use case
2. a different strategy for using cmake that will be easier to manage
3. any gotchas I should be aware of, even if you don't have better solutions.

Background

I have a project I'm working on where the ultimate deliverable will be a hardware device with 3-4 different microcontrollers coordinating with each other and interacting with a PC-ish platform. This is a clean rewrite of a C++ codebase. Due to the microcontroller (and some of the PC APIs) being C++, the language of choice for most of it is likely to remain C/C++.

I'm succeeded in setting up a build system for embedded code. The old code was arduino, so it relies a lot on those libraries, but I've managed to set up enough custom cmake to get off of the ardunio tools altogether, even if I am borrowing their libraries and some of the "smarts" built into the system about setting build flags, etc. So far, I have a dockerized toolchain (cmake + make + gcc-arm-none-eabi) that can successfully build ARM binaries for the target platform.

The thing that I'm up against now is that I'd like to have a robust off-target unit testing infrastructure. My ideal case is that everything in the embedded system will be broken down into libraries that have clear interfaces, then to use unit tests with mocks to get high coverage of test cases. I'll still need some HIL tests, but because those are harder to set up and run, I want to use those for integration and validation.

In terms of OSes available, we're mostly working on Windows systems using WSL for linux. I'd like things to be as linux-based as possible to support CI on github, etc.

Goals and Cmake limitations

I started out using cmake because I hate it least of the tools I've used, and I am at least pretty far up the learning curve with it. But a limitation I'm hitting is that you can't do a mixed compile with two different toolchains in one build. The reasons why cmake has this limitation seem reasonable to me, even if it is annoying. You can easily change the toolchain that your code is built with, but that seems to be largely targeted at cross-compiling the same binaries for different systems. What I want to do is:

• build my code libraries with embedded settings for linking to the embedded binaries and build those embedded binaries (the end product)
• build my code libraries with linux-ish tools and link them against unit tests to have a nice CI test process
• (eventually) also be able to build windows binaries for the PC components -- when I get to that point, I'd like to get away from the MSVC compilers, but will use them if I have to

Current strategy

My current plan is to configure a library build like this (pseudocode):

add_library(mylib sources)
if (BUILD_TYPE STREQUAL BUILD_TYPE_EMBEDDED)
<embedded config>
elseif (BUILD_TYPE STREQUAL BUILD_TYPE_LINUX)
<linux config, if any>
endif()

#unit tests are built for each library
if (BUILD_TYPE STREQUAL BUILD_TYPE_LINUX)
add_executable(mylib_test sources test_sources)
target_link_libraries(mylib gtest etc.)
endif()

For the rollup binaries, I make the whole target conditional

if (BUILD_TYPE STREQUAL BUILD_TYPE_EMBEDDED)
add_executable(myembedap sources)
target_link_libraries(mylib)
endif()

Then the build script (outside cmake) is something like

cd build/embedded
cmake <path to src> <set embedded toolchain> -DBUILD_TYPE=embedded
make
cd ../../build/linux
cmake <path to src> -DBUILD_TYPE=linux
make

Things I like about this strategy:

• It's relatively simple to do all the builds or just one of the builds (that control would go in the shell script)
• I have one source tree for the whole build
• It lets configuration be near code
• It lets tests be near code.
• I think it's extensible to cover the PC component builds in the future

Things that worry me:

• It feels like a hack
• Support for off-target tests feels like it should be solved problem and I'm worried I'm missing something

Thanks for reading. If you made it this far, you have my gratitude. Here's a video with funny out of office messages that I enjoyed.

Intro

Hello everyone,

@wanda-seldon has been giving us an introduction to quantum physics. For now, she will be given a short break to prepare new stuff. In the meantime I will be covering some classical mechanics, more specifically thermodynamics. In part 1, we need to work our way through some of the more dry concepts, so we can understand and appreciate the horrifying implications of the fun parts. So I promise, this will be the most verbose one.

Some of you may have briefly seen a version of this posted, that was due to me misunderstanding the schedule with @wanda-seldon. If you saw that one, I will mention I rewrote nearly all of it to be more readable.

Now, on today's agenda: The basics of heat, work and energy and how it's all related.

Previous posts can be found here: https://tildes.net/~science/8al/meta_post_for_a_laypersons_introduction_to_series

Important note

If @wanda-seldon in her posts mention "energy", it's most likely in the context of energy operators, which is a concept in quantum physics. I'm not going to pretend I understand them, so I will not be explaining the difference. We will cover what energy is in classical mechanics. So keep that in mind if you read something from either of us.

Subject

Summarized

What is heat? Using a lot of fancy words we can describe it as follows. Heat is an energy that is transferred between systems by thermal interaction. And what is work? Work is an energy that is applied in a way that performs... work. The combined energy in a system is called internal energy. This type of energy can be transformed or applied to other systems.

These are a lot of new words, so lets break that down a bit.

Systems

A system is just a catch-all term for something that can be defined with a boundary of sorts. Be it mass, volume, shape, container, position, etc. A canister, your tea mug, the steam inside a boiler, your body, a cloud, a room, earth, etc. They are all systems because you can in some way define what is within the boundary, and what is beyond the boundary.

In theory, you could define every single nucleid in the universe as an unique system. But that would be counter-intuitive. In thermodynamics we tend to lump things into a system, and treat it as one thing. As opposed to Quantum stuff that looks at the smallest quantity. Calculating every single water molecule in my coffee would be pure insanity. So we just treat my mug as the boundary, and the tea inside the mug as the system. And just so it's mentioned, systems can contain systems, for instance a tea mug inside a room.

Energy

Energy is some quantifiable property that comes in either the form of heat, work. It can be transferred to other systems, or change between the different energy types. An example of transfer is my coffee cooling down because it's in a cold room. That means heat has been transferred from one system (my mug) to another system (the room). Alternatively you could say my hot coffee mug is warming up the room, or that the room is cooling down my coffee. Thermodynamics is a LOT about perspective. An example of transforming energy types is when we rub our hands together. That way we convert work (rubbing) into heat. It's really not more complicated than that. An interaction in this case is just a system having an effect on a different system. So a thermal interaction means it's an interaction due to heat (like in the mug example).

This brings us to an extremely important point. So important, it's considered "law". The first law of thermodynamics even. Energy cannot be destroyed, it can only change forms.

Your battery charge is never really lost. Neither is the heat of your mug of coffee. It just changed form or went somewhere else. The combined energy of all types that is residing inside a system is called internal energy.

Heat and work

Let's say we have a system, like a room. And all windows and doors are closed, so no energy can leave. In this system, you have a running table fan connected to a power line, getting energy from outside the system. The table fan is making you feel cool. Is the fan cooling down the room, heating up the room, or doing nothing? Think about it for a moment.

http://imgbox.com/CKtQLLOQ

The first thought of many would be to think that this fan would cool the room down, it sure makes you feel cooler! But it's actually heating up the room. As we remember, internal energy is the energy inside a system (room, in this case). The fan is getting energy from outside, and uses this energy to perform work. The fan accelerates the air inside the room, and this accelerated air will evaporate some of your sweat, so you feel cool. But as we remember, energy cannot be destroyed. So we are importing energy into the system, increasing the internal energy. Some of the work from the fan is also directly converted to heat, since the motor of the fan will get hot.

So if we are not getting rid of any of this excess energy, we are increasing the internal energy. And therefore actively increasing the temperature of the room.

http://imgbox.com/SAtqk7YG

To use a more tangible example: Simplified, this phenomena is why green house gases are bad. Lets define earth as a system. Earth gets a lot of energy from the sun. And a lot of this energy will be reflected and sent back to space. Green house gases will reflect back some of this energy trying to leave earth. So instead of having a roughly equal amount of energy enter the system (from the sun, from us doing stuff, etc) that leaves out in space, we have an increasing amount of energy on earth. This, as a consequence, increases temperature.

Implications

Now, what are the maybe not so obvious implications of this?

Waste heat, from supplied energy or inefficient work is a constant headache in engineering. If we cannot remove enough heat, we will actively heat up objects until they are destroyed. Thats why good cooling systems are important in cars, computers, etc.

Whats next?

Now this was not so bad. In the future we will cover phase changes, equilibriums, entropy, the heat death of the universe and briefly touch upon engines. So thats most likely two more parts after this. After that @wanda-seldon will take over again.

I plan on doing one main part per week, but if something is asked that warrants a small topic I might do smaller ones inbetween.

Feedback

Something unclear? Got questions? Got feedback? Or requests of topics to cover? Leave a comment.