My recently-bought Behringer UMC204HD audio interface, that is advertised as 2 inputs, 4 outputs, presents itself to Linux as one stereo input channel and one 4.0 output channel:

 1pacmd list-sinks |grep -P 'name: \<|channel map' -C 1
 2...
 3    index: 2
 4	name: <alsa_output.pci-0000_00_1b.0.iec958-stereo>
 5	driver: <module-alsa-card.c>
 6--
 7	sample spec: s16le 2ch 44100Hz
 8	channel map: front-left,front-right
 9	             Stereo
10...
11pacmd list-sources |grep -P 'name: \<|channel map' -C 1
12...
13    index: 2
14	name: <alsa_input.usb-BEHRINGER_UMC204HD_192k-00.analog-stereo>
15	driver: <module-alsa-card.c>
16--
17	sample spec: s32le 2ch 44100Hz
18	channel map: front-left,front-right
19	             Stereo
20
21...

I'm guessing the reason is plain "we just use some generic USB ADC/DAC chip and reference implementation comes in that config".

That poses a problem for most voice communication software, usually putting stereo input into it means it will sum both channels up, and summing a channel with signal to channel with zero signal results in volume drop (-6db usually).

Some software is competent enough to auto-gain out of that problem, but most don't even have VU meter, let alone any indication of sound level you're sending to other participants of the conversation so it's easy to be too quiet in out of the box config.

So we need to split one device into two. We might still occasionally want the stereo input so I won't try to replace it with two mono ones.

Why change clock speed

So why you would want to change speed of your I2C interface?

You might just need to probe your sensors more often.

You might also want to get around long standing I2C stretching bug, which caused that by default I2C stretching on rPi I2C controller is disabled.

in this post we will look at how systemd handles dependencies and how they can be used to increase the robustness of the system, and also discuss potential pitfalls.

For the existing services all of the examples should be put in /etc/systemd/system/<service you change>.d/<override>.conf, as this way you will only override the things you change in unit, instead of editing whole unit file in /lib (and having your changes overridden on package upgrade).

Unless mentioned otherwise the dependencies are specified in [Unit] section

Setting up our editor (CLion, VS Code) to debug the STM32 ARM chips.

See Part 1 on how to connect to board and Part 2 on how to setup project and OpenOCD for compile and debug

Setting up project and programming our first piece of Rust code onto microcontroller (Part1)

Preparing build environment

After we finished the hardware setup in Part 1 we should have working openocd connection.

Rest of this series of posts will assume stlink or jlink debugger + Blue Pill board. There is variety of clones like these:

but legality of the software on the clones is at very best dubious. You can also just get a Nucleo board which contains debugger and small eval board all in one

We will also be using template graciously provided by Rust Cortex-M team. Make sure to use at least Rust 1.53 (tutorial is built on that version) and install cross-compile dependencies of rust and binutils-arm-none-eabi:

Setting up tooling and development hardware for Rust on the ARM (STM32 CPUs)

What hardware do we need?

• Dev board. Just about any will do, Blue Pill is pretty popular, other option is one of the STM32 Discovery boards that come with the programmer.
• Programmer/debugger - any of the ST-Link (or clones) will do, here we will be using ST-Link V2 clone. Really, anything supported by openocd is fine, altho some need some tweaking
• Power supply for a dev board - a lot of them just accept micro-USB connector

Most dev boards come with some example code, the barebones often just have LED blinking, but I've seen some that even output on USB.

The more sophisticated ones that have extra peripherals usually come with demo of them so you might want to plug them before doing anything else to have a look.

Git has very convenient feature called filters. What it basically allows to do is to pipe the content of a given file (decided by entry in .gitattributes thru external filter command.

The different hook points are on file checkout (so called "smudge"), check-in, and on diff.

Here are two useful cases for using it:

Formatting files on checkin

If your language have a formatter that just accepts stdin and outputs formatted file on stdout, like Go, it is very straightforward to add it:

1git config --global filter.gofmt.clean "gofmt"
2git config --global filter.gofmt.smudge "gofmt" # or "cat" if you don't want to filter incoming commit

then in either ~/.config/git/attributes or in repository itself under .gitattributes

1*.go filter=gofmt

Do remember that if used on repo where others don't use formatter regularly you might get a bunch of spurious formatting modifications during daily work.Especially with filter on checkout.