Misztikus AVR hiba

[VF]

Thus spake Fuzesi Arnold <arno at externet.hu>:

> Ez a "misztikus" hiba csak egy vacak kis pipeline uritesi szabaly. (a ket
> szabalybol az egyik amit egy AVR-en szem elott kell tartani...)
>
> Miszerint a sleep utani utasitast meg vegrehajtja a proc.

Megint nem fogod a temat, csak a szokasos szemelyeskedes es fikazas jon...
Elmagyarazom megegyszer, lassabban, hogy a nehezebb felfogasu kollegak is
ertsek.
A sleep utan 'valogat' a proci, ha call van (32bit) akkor szopas van,
ha rcall (16bit) akkor nincs. Ha nop (16bit) es utana call, akkor is minden
rendben.
Hab a tortan, hogy a call altal meghivott fuggveny jelenleg nem csinal
semmit, a hiba kommunikacio nelkul is jelentkezik. De ha lenne kommunikacio,
akkor sem lenne erdekes, hogy vegrehajtja-e az utasitast a sleep elott,
vagy csak utana, elmeletileg nem kene semmi kulonbseget okoznia.
(Ezert is nem volt benne a NOP, kulonben tettem volna, mert a jelenseg mar
evek ota ismert)
Valamint minden tokeletesen mukodik (a kommunikacio is), az egyetlen tunet,
hogy nagyobb es ingadozo az aramfelvetel.

Nemi gondolkozas utan az en tippem: nem lep be a sleepbe a proci, nem alszik
el, ha utana 32 bites (vagy 16 bites, de tobb ciklusos?) utasitas van, mert
a sleep a kovetkezo ciklus vegen lepne mukodesbe (ahogy a portok is
szinkronizalva vannak!), es utasitas kozepen nem tud elaludni.

> Minap még nagyon mentek ezek a szabály fejbentartások...

Mutasd meg leirva! Azt, hogy a sleep utan vegrehajt egy utasitast,
tudtam, nem gond, nem erdekes. Ez sincs benne az adatlapban, ahogy VFX
irta, regen bennevolt.
De az, hogy nem mindegy neki hogy milyen utasitas van a call utan,
_sehol_ nincs leirva.
Ha te ezt is fejben tudod tartani, gratulalok!
A fordito meg ugyanugy elrontja...

> Arnold

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
"Egyetlen teny romba donthet egy faradsagosan felepitett ervrendszert"