12:53 <re_irc> <Jan Bronicki> I have a question about CI jobs

12:53 <re_irc> <Jan Bronicki> any tips for setting up CI pipelines for embedded projects?

12:53 <re_irc> <Jan Bronicki> like what should i include

12:55 <re_irc> <James Munns> Often embedded CI is limited to building your projects, and running any checkers (like formatting, clippy)

12:55 <re_irc> <James Munns> in most cases, you'll just need to do a build like: "cargo build --target thumbv7em-none-eabihf"

12:56 <re_irc> <James Munns> There are some ways to either use an emulator, like QEMU, or physical hardware, but those end up being quite a bit more involved.

12:56 <Lumpio-> Also if your project has parts (maths, logic, whatever) that are reasonably refactored out of hardware-related stuff, you can always run unit tests

12:57 <re_irc> <James Munns> If you are building a library, instead of a binary, you can often do your unit testing in CI as well, as long as you don't need to interface with physical hardware.

12:57 <re_irc> it's common to mark no-std libraries with:

12:57 <re_irc> "#![cfg_attr(not(test), no_std)]"

12:57 <Lumpio-> Depending on the build.rs trickery and whatnot in your dependencies, you might need to jump through some hoops through to get them to build for something that's not a microcontroller

12:57 <re_irc> <James Munns> that way you still have the standard library when running unit tests, like Lumpio- said.

12:57 <Lumpio-> like e.g. separate them into a different crate

12:57 <re_irc> <James Munns> There's also https://github.com/dbrgn/embedded-hal-mock, for mocking HW interfaces, if your library is using embedded-hal.

12:58 <re_irc> <Jan Bronicki> unfortunately the start of the project will be in C++ altho i plan on introducing more Rust later

12:58 <re_irc> <James Munns> Are you making the rust part a static library?

12:59 <re_irc> <Jan Bronicki> its more like the device we are building has many mcontrolelrs

12:59 <re_irc> <Jan Bronicki> and some of them I plan to program using rust

12:59 <re_irc> <Jan Bronicki> its a university science club project

12:59 <re_irc> <James Munns> Gotcha!

13:00 <re_irc> <James Munns> As for CI, just building, and running "cargo +nightly clippy" or checking that "cargo fmt" is clean, is a good first step!

13:00 <re_irc> <James Munns> Then if you have any specific questions on how to test certain things, feel free to ask for more help then!

13:01 <re_irc> <James Munns> https://github.com/actions-rs should work with no-std just as well, if you are using GH actions for CI

13:02 <re_irc> <Jan Bronicki> I had some experience in embedded but that was some time ago and right now as one of the senior students im mainly responsible for project management side of things given that i have profesional experience. But because its been so long and I havent been learning embedded for quite some time Im trying to basically gather the tools I would normally use aka testing, mocking, some simulation. For example I once used a...

13:02 <re_irc> ... project called Renode https://renode.readthedocs.io/en/latest/

13:02 <re_irc> Its made to emulate boards etc so you can debug them and whatnot but I dont know if better projects than this one exist. So im really looking for guidance here ☺️

13:03 <re_irc> <James Munns> I think renode should work with Rust if it supports your hardware!

13:03 <re_irc> <James Munns> This is similar to what I said w/ QEMU

13:03 <re_irc> <James Munns> I haven't used Renode, but I've heard good things!

13:03 <re_irc> <James Munns> But honestly, if you can test WITHOUT simulating/emulating, you'll have a better time!

13:03 <re_irc> <Jan Bronicki> James Munns: For normal Rust projects i do rustfmt, clippy, builds for all toolchains i need and stable, nightly and beta, crate creation check, tests, crate publishing dry run, doc creation (i use some packages that for example add latex so in my case docs can actually fail) etc

13:03 <re_irc> <James Munns> e.g. isolating logic into crates, and unit testing them independently, rather than on hardware or in a simulator.

13:04 <re_irc> <Jan Bronicki> Hm yeah thats the catch I dont have exp in this stuff so I cant tell

13:04 <re_irc> <Jan Bronicki> also im looking for tools that will also play with C++

13:04 <re_irc> <Jan Bronicki> as for now this is the focus

13:04 <re_irc> <Jan Bronicki> also do you know forums like this one or discord servers where i could ask the same question about C++?

13:05 <re_irc> <James Munns> This is the typical split between "unit", "integration", and "system" tests

13:05 <re_irc> <James Munns> unit tests are easier, because you don't need to pull in the whole world

13:05 <re_irc> <Jan Bronicki> sure but i have no idea about any of it for C++

13:06 <re_irc> <Jan Bronicki> i worked as a QA intern so i dont have a problem in general with testing, got some good exp there

13:06 <re_irc> <Jan Bronicki> but in C++? damn

13:06 <re_irc> <Jan Bronicki> i dont know the actual production ecosystem

13:07 <re_irc> <James Munns> Also can't help with C++

13:07 <re_irc> <James Munns> The memfault slack is actually really good and helpful

13:07 <re_irc> <James Munns> and has more non-rust folks there

13:07 <re_irc> <James Munns> https://interrupt-slack.herokuapp.com/

13:08 <re_irc> <Jan Bronicki> gotcha

13:08 <re_irc> <Jan Bronicki> thanks!

13:35 <Lumpio-> I was recently asked about unit testing embedded C... I couldn't even name a unit testing library for C

13:38 <re_irc> <James Munns> I tend to use CMocka

13:38 <re_irc> <James Munns> Have also used whatever the throwtheswitch tooling is

13:38 <re_irc> <James Munns> ceedling?

13:39 <re_irc> <James Munns> CMocka is a fork of the old, C version of googletest, before it went all C++

13:40 <re_irc> <James Munns> That being said, today, I'd probably just use rust + cargo

13:40 <re_irc> <James Munns> it'd honestly be easier to instrument everything in Rust, mocks and all.

13:40 <re_irc> <James Munns> but that might be a "if your only tool is a hammer, every problem looks like a nail" answer

13:41 <re_irc> <James Munns> But honestly, a build-rs+cc-rs for compilation (instead of a make file), and std::collections for writing mocks is going to be 100x easier than doing it all in C.

13:42 <re_irc> <James Munns> If Uber can use zig just for cross compilation, I don't see why it wouldn't be legit to use Rust just for unit testing :D

13:43 <Lumpio-> "but nobody knows rust at the company"

13:43 <re_irc> <James Munns> Yeah, then it's a bad choice

13:43 <Lumpio-> I guess I'll find out what their tool of choice is soon

13:43 <Lumpio-> Well, hopefully anyways.

13:44 <re_irc> <James Munns> CMocka is good (pretty opinion-less, it's just asserts and some basic test organization stuff), Ceedling is much more involved (it has a ruby/rake based build system), which is more complicated, but does some nice stuff like auto-generating dependency mocks

13:45 <re_irc> <James Munns> ceedling also has a ton more docs/resources available, Grenning's Embedded TDD book uses it IIRC

16:10 <cr1901> I use minunit.h