Názor k článku Přístupy k programování STM32 od Karel - Tady je problém v tom, že SPI neumí...

Tady je problém v tom, že SPI neumí z principu věci nic jako POUZE číst. Tam je prostě pár drátů, které mají nějakou funkci. Jedním z nich jsou hodiny - když tím zahejbám, tak tím říkám druhému zařízení, že má na drátu MISO nastavit další bit a na drátu MOSI si bit načíst. Ty hodiny jsou prostě drát, kde náběžná hrana znamená "teď". Tam není žádný způsob jak druhému zařízení říci "pošli mi další bit ale sám nic nečti". Na to je to rozhraní příliš primitivní.

Houba tvrdí, že tuhle vlastnost SPI zná. Ale tak proč se diví, že to SPI něco posílá, přestože se funkce jmenuje "Receive"? Vždyť ví, že technicky není možné na SPI jen číst nebo jen psát.

A druhá věc je, že v dokumentaci není nikde žádné POUZE. V dokumentaci je přesně popsáno, co to funkce deklaruje, že udělá: přijme data. Nedeklaruje, co pošle. Tedy bude posílat nějaký bordel. K čemu ta funkce je dobrá? Ono řada SPI zařízení (senzory apod.) nic nečte. Kolikrát nemají ten drát zapojený, nebo prostě přijatá data nezpracovávají. Proč bych pak měl tedy plácat pamětí na alokaci výstupního bufferu? A na otázku proč neposílat jen samé 0 nebo 1 je odpověď také snadná: protože nechci mít 3 funkce. Tím, že funkce Receive a Transmit jsou jen aliasy pro TransmitReceive ušetřím docela dost paměti. Daň za to je ta, že Receive posílá to, co přijímá, a Transmit přijímá to, co vysílá. Protože ty dva pointery ukazují na stejný blok paměti.

PS: HAL je zlo a sám bych ho nepoužil. Ale tady v tom konkrétním případě je problém mezi klávesnicí a židlí. Ten pán se diví, že HAL dělá to, co SPI z podstaty věci dělat musí. Buď neví co je SPI, nebo jen doufal, že HAL nějakou magií dokáže něco, co SPI ne.