ARM- interrupt/event

[Jan Waclawek]

>problem je v
>tom, ze raz ten bit set trva 10 cyklov a raz 15... A snazenie nasho experta
>je zistit, kedy je to 10 a kedy 15.

To nie je celkom presne - idealne je samozrejme vediet to presne, ale v
mnohych pripadoch staci mat istotu, ze je to 10 a viac, ak sa dodrzi toto
a toto.

>To som fakt netusil, zeby na 160MHz
>toto mohlo niekoho zaujimat. 

A preco nie? Tych 160MHz, to je nejaka samospasitelny svaty gral? V com sa
presne lisi 160MHz od trebars 16MHz, co sa tyka potreby mat kontrolu nad
tym, co sa mi v obvode a na jeho vyvodoch deje? Predsa tak, ako su
dostupne rychlejsie mcu, su dostupne aj rychlejsie k nemu pripojitelne IO,
naucili sme sa zvladat rychle signaly na DPS, atd. A ak potrebujem pre
nejaku periferiu generovat min. 15ns pulz, tak je dost rozdiel, ci ten
pulz bude vacsinou 18ns ale obcas 12ns, alebo som si isty ze tych min.
18ns (co su tri hodinove cykly pri 160MHz) bude stale; a naopak, dost by
mi vadilo, kebyze kvoli tomu zabijem viac nez absolutne nevyhnutnych
nejakych 5-10 cyklov procesoroveho vykonu (toto som si zhodou okolnosti
nevymyslel, ale je to podobne jednej z poziadaviek, s ktorymi som sa pri
praci stretol).

>A uplne absurdne je to v pripade
>bit-bandingovej I2C na pinoch portu, ktora bezi na 100kHz resp. 400kHz...

No a toto nie je absurdne preto, lebo nikde nie je napisane, ze ten 168MHz
procesor musi stale chodit na 168MHz; naopak, praveze sa velky doraz
kladie na to, ako dobre dokaze chodit na menej (kvoli setreniu elektrinou
- tomu skutocnemu, nie ziarovkovemu :-) ). A ak sa ukaze, ze je
energeticky vyhodnejsie ist s jadrom povedzme prave na 100kHz a robit I2C
bit-bangom (pozor na to pismeno) nez rozbiehat ten hardwarovy I2C modul
(ktory je mimochodom zlozity ako prasa), ale nemozem to robit, lebo nemam
zaruky co sa tyka casovania IO operacii, no tak to su zase minusove body
pre pripadne rozhodovanie o tom, co pouzijem... 

A takychto prikladov sa da samozrejme vytriast z rukava kolkokolvek.


wek