Use blocking spi traits

[eldruin]

• Shift to using blocking SPI traits for peripheral sharing ease
• Fix updating embedded-hal version to version 0.2.3 where the digital::v2 traits were actually added.
• Update env_logger dependency
• Add Changelog

Thanks to @Rahix and @Maldus512
Fixes #28

[Rahix]

Looks good to me at least :)

[thejpster]

I only looked at this quickly, but I had a question around the chip select. Is there a risk the card will be unselected in the middle of a transaction when using a shared bus object? And if so, does the card care?

[eldruin]

I only looked at this quickly, but I had a question around the chip select. Is there a risk the card will be unselected in the middle of a transaction when using a shared bus object? And if so, does the card care?

shared-bus allows sharing when the objects are not already borrowed so taking away the spi peripheral in the middle of a transaction is not possible.
What could happen, though, is that an interrupt arrives between the time of changing the CS pin and the use of the SPI peripheral. If in that interrupt the SPI peripheral is borrowed, a situation would come up where multiple peripherals are selected.
This is a known limitation of shared-bus and there is a proposal around a managed CS trait to solve it. See: Rahix/shared-bus#8
Other than that I believe there is no danger being added here. Even though the FullDuplex trait is being used, it is being used in a blocking way already.

[Rahix]

If in that interrupt the SPI peripheral is borrowed, a situation would come up where multiple peripherals are selected.

That is currently impossible because the bus proxy for SPI is !Send. So you'd need some unsafe code to do this.

This is a known limitation of shared-bus and there is a proposal around a managed CS trait to solve it.

Also see rust-embedded/embedded-hal#245.