Bitove polia v C

Petr Labaj labaj na volny.cz
Středa Duben 4 17:25:16 CEST 2012


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

*************************************

From: "Jan Waclawek" <konfera na efton.sk>
To: "HW-news" <hw-list na list.hw.cz>
Sent: Wednesday, April 04, 2012 5:18 PM
Subject: Re: Bitove polia v C


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.

wek



Další informace o konferenci Hw-list