I don't see this as improvement :( Previous code looks cleaner to me: separates concerns of a) ensuring default value and b) handling frequency.

Found the separate if-statement superfluous, since we already have a flow control on the frequency.

can you two@ysoldak,@b0ch3nski agree on that?

I find switch statements much easier to read but I think it's just a matter of personal preference. Nevertheless, we already have a switch here and that lonely if statement looks like it has rejoined it's people 😃

I find switch statements much easier to read but I think it's just a matter of personal preference. Nevertheless, we already have a switch here and that lonely if statement looks like it has rejoined it's people 😃

Yes, felt the same to me.

Regarding switch, I must confess, I was struggling to understand what's going on at first.
I was expecting every 'case' to produce a unique value (number of unique values = number of cases in switch).
I would propose merge two cases, but then case condition becomes long and look ugly.

So I still prefer deal with default value first, then handle the value, regardless default it is or not.
It may look nice/smart to have only one switch without an extra "if" before it, because we can, but I'd say readability suffers, at least in my case.

Read and Write are not part of the SPI interface. It is easy enough to implement an abstraction if needed that works for all SPI hardwares of all MCUs

funcwriteSPI(w []byte,spiinterface {Tx(w,r []byte)error}) (int,error) {returnlen(w),spi.Tx(w,nil)}

Yeah, lets do it! Actually I was surprised that SPI is not supplying it, since it would have seemed the more natural way to interface with SPI than the current one. Can you point me to the relevant file/code section?