Bitove polia v C

[Jan Waclawek]

Asi nie - u LPC17xx su GPIO zapojene priamo na AHB, ktora ma hodiny rovnake ako CPU.

Ono ta moja analyza moze byt v detailoch nespravna, zaver je vsak z toho aj tak ten isty: toto NIE su mikrokontrolery s definovanym casovanim (okrem ineho periferii voci jadru).

wek



>A nebylo to zapricineno jen prilis velkym pomerem rychlosti CPU/sbernice,
>kdy se ty instrukce pro modifikaci IO stacily udelat behem jedineho taktu sbernice ?
>
>PL
>
>*************************************
>
>
>Upozornujem vsak na jeden zaujimavy gotcha - aj ked je ta operacia neprerusitelna, nie je zarucene, ze sa z hladiska casovania vykona uplne presne tak, ako by si clovek predstavoval. Je to nasledok toho, ze tie ARMy nie su mikrokontrolery ale SoC, t.j. procesor zlepeny s periferiami roznymi medzikusmi na jednom cipe, pricom tie medzikusy su zlozite a ich presne casovanie nie je zverejnene a nemusi byt uplne priamociare. Pri hratkach s LPC17xx som napriklad zistil, ze ked som cez bit-banding robil bit-banged (naschval som pouzil tento davno zauzivany a podobne znejuci vyraz, aby bolo jasne co si myslim o idiocii ARMovskeho nazvu pre to bitove premapovanie) SPI, tak sa mi pri urcitom poradi instrukcii menili dva piny (dva bity z jedneho wordu prisluchajuceho danemu vystupnemu portu) naraz, aj ked som ich menil dvomi roznymi instrukciami ktore dokonca ani nenasledovali tesne za sebou. Ten bit-bandovaci medzikus zrejme pri prvej instrukcii urobil to "read" z "read-modify-write",
  
> ale skor nez stihol nastat "write" prisla poziadavka na "read-modify-write" pre ten isty word (pricom tie medzilahle instrukcie fungovali len na registroch procesora, cize sa tym z pohladu periferii nic nepokazilo), a tak medzikus uz nerobil dalsi "read" ale len dalsie "modify" a potom to finalne "write" zahrnujuce obe zmeny.
>