libkakapo recent changes

Hi all, a quick post about some recent changes in libkakapo.

Firstly, on the major API changes, there is a different SPI API than existed previously. It now accepts arbitrary length buffers for bytes to TX and fill with RX. As TX always happens before RX, you can supply the same pointer if you wish.

The API also allows either of these buffers to be provided as NULL, which means it will either generate 0’s on TX (which is how a read-only SPI transaction works), or discard RX bytes.

In the old API, you would do this to write a 128 byte stream:

uint8_t buf[128], n;

ASSERT_CS;
for (n = 0; n < 128; n++) {
    spi_txrx(spi_d,buf[n]);
}
DEASSERT_CS;

On the surface, this doesn't seem like it's that bad, but this involves making 128 function calls to transmit each byte!

Instead, in the new API, you can do this:

uint8_t buf[128];

ASSERT_CS;
spi_txrx(spi_d,buf,NULL,128);
DEASSERT_CS;

Since we're just writing, we can just toss the RX, and throw the SPI driver the whole buffer to churn through. This eventually will allow us to decide if we want to set up DMA for the transaction, which would speed up transfers a little more.

The other changes are more minor:

  • The ringbuffer utility code now uses lengths for buffers, instead of masks. Internally, we still use masks and enforce power-of-two lengths for the ringbuffer, but the API feels more natural.
  • Added a watchdog driver, since the avr-libc one is a little inconsistent with XMEGA hardware. This has not been completely tested (I still need to write a test case for it).
  • GCC was generating warnings for the hook functions in timer.c, these have been silenced properly. (H/T: hads)
  • timer.c also was not returning the same error codes consistent with other drivers, so these have been fixed up.
  • clock.c (the system/peripheral clock configuration API) now returns a unique error code for an oscillator not being ready.

So there we are, that's the last couple of weeks on the libkakapo front!

Leave a Reply