stm32xx-i2c-server: record error code in ringbuf.

[cbiffle]

No description provided.

[bcantrill]

Looks good -- if you'll excuse me thinking aloud here, one of the annoyances about this particular ringbuf is that it is historically small because the memory usage is very close to power-of-two boundary and we haven't wanted to double its RAM consumption due to ringbufs. But this change doesn't increase the size, and seems unlikely to newly drown the ring buffer (with, say, alternating errors). And certainly, it gives us more understanding of what happened!

[cbiffle]

Looks good -- if you'll excuse me thinking aloud here, one of the annoyances about this particular ringbuf is that it is historically small because the memory usage is very close to power-of-two boundary and we haven't wanted to double its RAM consumption due to ringbufs. But this change doesn't increase the size, and seems unlikely to newly drown the ring buffer (with, say, alternating errors). And certainly, it gives us more understanding of what happened!

So my sense from looking at ringbuf memory consumption across tasks recently is that we could probably save a bunch of memory by enabling more per-task I2C logging, and removing some of the central driver logging. The central driver logging is difficult to correlate with individual tasks, and gets rewritten quickly -- which is why we couldn't just look at it here!

I think that'd let us get away with less net RAM. But I'd want to play with it before committing.

[bcantrill]

FWIW, this has been addressed by #1413 -- and the ring buffer both expanded and made more space efficient in addition to recording the error code.