add default SPI word types

[burrbull]

Thought about this reading #295

cc @eldruin @Sh3Rm4n @ryankurte

Should we restrict types be some trait?
Can also split U16 to U16LE and U16BE

[rust-highfive]

r? @ryankurte

(rust-highfive has picked a reviewer for you, use r? to override)

[Rahix]

How are these zero-sized types supposed to be used? I think you'd need something more like

pub struct U9(pub u16);
pub type U16 = u16;
pub struct U18(pub u32);

[burrbull]

You are right it was stupid for me. But you suggestion will not work also.
It should be something like:

pub trait SpiWord {
   type Bytes;
}
pub struct U9;
impl SpiWord for U9 {
    type Bytes = u16;
}

[Rahix]

I see, this solution also works. However, now there isn't any implicit type annotation anymore so when calling, for example, Transfer::transfer() you'll have to be explicit about the datatype. This means you cannot call it like

spi.transfer(&buf);

but you'll have to call it as

Transfer::<U8>::transfer(&mut spi, &buf);

My suggestion was to have newtype wrappers around the odd bitwidths and then store an array of those. This would allow the compiler to infer the type automatically:

let buf: [U9; 16] = [U9(0), U9(23), ...];
spi.transfer(&buf);

[burrbull]

Wrapping each element of array is a pain

[Dirbaio]

1. u32 should be added: stm32h7xx-hal has an impl for Word=u32.
2. This is fixing the in-RAM representation of u9 etc. Perhaps a chip wants the 9 bits be msb-aligned inside the u16 instead of lsb-aligned to be able to DMA. Without the bound, a HAL can define their own WeirdU9 newtype that handles this and take &[WeirdU9] which already has the right repr to DMA straight out of it. Restricting word types makes this impossible.
3. I'm not sure if the benefit is worth the extra complexity, with new types, a new trait, and associated types.