ARM- interrupt/event

[Andrej Jancura]

Ahoj,

Dňa 12. apríl 2013 13:09, Jan Waclawek <konfera na efton.sk> napísal(-a):

> >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.
>

No ale to ti tuna Tomas uz napisal, ze to jadro ma latenciu 1-4 cykly a
keby mali popisovat vsetky tie stavy, tak sa upisu k smrti... Myslim si, ze
tento cip je urceny na iny typ aplikacii, je to ina generacia ako 8-bitove
architektury, kde to bolo vsetko dane designom  a jasne z navrhu.

>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 precital si si, co som napisal v svojej reakcii vcera vecer...? Na tych
160MHz musi byt ina technologia navrhu ako na 16MHz... Proste ine triky. A
to ta nepusti. Ked chces bezat na 16MHz, tak tam prilep nejaky jednocip na
SPI za dolar a aj tak ti ten ARM nepojde rychlejsie. Akurat sa s tym series
a nevies co s tym. Druha vec je, ako som tiez uz naznacil, ze mas 160MHz,
ale nevies za to, co sa tam deje. Je to proste lepsia hracka urcena na typ
aplikacii, kde tych 10ns nehra ziadnu ulohu a ty chces z toho ... upliest
high-tech. Myslim si, ze na presne casovanie IO operacii tato architektura
nie je moc stavana, co tu ktosi tiez postol z uvodu nejakeho datasheetu.
Ale to ti tiez ideologicka marketingova masineria nepovie. No a potom pridu
zakaznici, ktori tiez nevedia co chcu a to je lepsie cuknut, ako investovat
kopec prachov do niecoho co je nerealne. Koniec koncov, aj do teba a
tvojich pokusov ktosi mesacne natlaci 3000e a tiez sa nepytas odkial su, a
ci vobec su. Ale kto uz len povie zakaznikovi, ze nejde spravit to, co si
vymyslel?! Toz tak to vidim ja.


>
> >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.
>

Ako som ti napisal vyssie, daj tam nejaky klasicky jednocipak nalepeny na
SPI, ktory ti tu I2C obsluzi, alebo pouzi inu architekturu. Pokial sa aj
tak budes silou mocou domahat bitbangovej I2C na 160MHz Cortexovom jadre,
tak skus napisat na support. Neviem sice co ti profesionalne odpisu, ale
urcite sa stanes kultovou postavickou supportoveho oddelenia. :)))

A.


>
> wek
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20130412/cd193478/attachment.htm>