Názor k článku Přístupy k programování STM32 od gripennn - Takže jádro sporu je v tom jak by...

  • Článek je starý, nové názory již nelze přidávat.
  • 5. 10. 2017 21:38

    gripennn (neregistrovaný)

    Takže jádro sporu je v tom jak by ta fce "receive()" měla vypadat. Vy navrhujete aby fce "receive()" sypala 0 nebo jedničky aniž by nad tím měl programátor kontrolu. Já říkám, že je to v podstatě stejné jako když sype náhodná data. Když má něco sypat, nechť o tom rozhoduje programátor a předá tu "dummy" hodnotu funkci jako argument.

    Ten datasheet měl poukázat právě na to, že dummy byte složený z log.1 by dělal problémy. Explicitně se tam totiž píše o první trojici bitů, že "Valid settings for these three bits are 000, 100, and 101. Other combinations should be avoided." Jinak řečeno 111 = problém.

    Když tedy bude existovat fce "receive()" bez vstupního argumentu a bude sama sypat někým zvolenou hodnotu (samé jedničky nebo samé nuly) vznikne stejný problém, jaký byl na začátku. Programátor čeká, že receive bude "pouze" číst a ona něco vysype (programátor neví co, protože si stejně jako váš kamarád neprohlídl vnitřnosti funkce). Shodou okolností si zrovna vybere slave který jedničky nebo nuly "nesnáší"(viz výše zmíněné ADC) a požár je na střeše.

    Když bude mít fce "receive()" vstupní argument jaká dummy data má sypat, nastane zase jiný problém. Programátor který má SPI nastavené v režimu "receive only" (tedy simplex) bude hledat fci "receive()" bez argumentu (on přece nic posílat nemůže ani nechce). Protože takovou fci nenajde, bude nadávat na autory HALu, že tam není.

    O tom jestli stávající "receive()" funkce je nebo není pro simplexní použití se můžeme jen přít. V dokumentaci k HALu o tom není zmínka. Já vycházím z předpokladu, že k ničemu jinému rozumně sloužit nemůže (v duplexu sype "náhodná" data), takže proč by tam jinak byla ?