Stránka 2 z 3

Napsal: 16 čer 2019, 23:17
od masar
A jak si pak mám vysvětlit:
"The I-bit is cleared by hardware after an interrupt has occurred, and is set by the RETI instruction to enable subsequent interrupts. The I-bit can also be set and cleared by the application with the SEI and CLI instructions, as described in the instruction set reference."
? :wink:

Napsal: 17 čer 2019, 09:14
od fero_b
AVR seria nema viacej urovni preruseni, pokial si spravne pametam, a obsluha prerusenia, nemoze byt prerusena dalsim prerusenim

Napsal: 17 čer 2019, 09:17
od masar
Děkuji za potvrzení. :wink:

Napsal: 17 čer 2019, 09:47
od Crifodo
U "nových" AVR pod Microchipem to je už jinak.
tazatel asi potřebuje řešit nejen zásobník a ukazatele, ale i hodnotu proměnných, aby mu program pak nepočítal nesmysly. Takže bude muset proběhnout nějakou inicializační částí, kde se vynulujou nebo definujou počáteční hodnoty, pokud není žádoucí pokračovat. To ví jen autor.

Napsal: 17 čer 2019, 10:14
od masar
Tady ale řešíme problém tazatele:
epes píše:AT Tiny 2313, program v Céčku...
:wink:

Napsal: 17 čer 2019, 11:58
od ZdenekHQ
Ať máte nastavený priority jak chcete, tím RET(I) z přerušení vyskočíte a než se dostanete na reset nastavení, může to klidně zavolat dalších 20 přerušení.

Bohužel to používám taky a vím, jaký to umí vylomeniny.

Mimochodem, teď se objevily "embedded" klony 8051, kde RETI nechodí zrovna korektně a je lepší ty příznaky přerušení preventivně mazat.

Napsal: 17 čer 2019, 17:04
od termit256
U ceho jsi mel konktetne problem? Ja jsem ted objednal nejake jednocyklove 8051 z Ciny, tak at vim na co se mam tesit.

Napsal: 17 čer 2019, 17:37
od ZdenekHQ
Já bych to napsal spíš obecně, protože něco mám z druhé ruky a nedokážu posoudit, jestli to není chyba jinde. Ale pořád poslouchám nějaký pohromy. Je potřeba si hlídat vektory přerušení, co jsou přidaný navíc, u NRF9E5 třeba přijatý paket z rádia apod.

A samozřejmě mazat příznaky UART, ty se samy nesmažou i přes RETI. To pak poslouchám, jak 16 znaků vyvolalo 22 přerušení apod.

U AT89LP51 i AT89C51RD2 jsem zaznamenal nepříjemný jev, když hardwarově generuju tón pomocí timeru T2 rovnou na výstupní pin, tak občas a náhodně jedna část periody trvá dvojnásobek délky. Nedokážu v SW najít příčinu, vlastně ten SW na to ani nemá vliv. Je tam jen ON/OFF. Působí to dost rušivě.

Napsal: 17 čer 2019, 18:25
od termit256
Tu LP radu taky obcas pouzivam. Tam se musi softwarove mazat ty priznaky preruseni kde je jeden vektor sdilen nekolika ruznymi vecmi, jako napr UART prijem/vysilani, preruseni od citace2/externi preruseni2 apod. Ma to vcelku logiku, po vymazani priznaku preruseni ktere se deje pri vstupu do obsluhy preruseni by neslo zjistit od ceho je vlastne vyvolane. Ale jestli je to pravidlem uplne u vsech si nejsem jist, radeji vzdycky mrknu do DS.

S tim hledanim obsasne se vyskytujicich anomalii to je kolikrat fakt peklo. Asi bych to zkusil napsat v asm a nechat delat MCU jen ten ton a nic jineho. To by snad melo fachcit. A pak pridavat ostatni akce co se maji delat a zjistovat tak co to vlastne zpusobuje. To externi preruseni 2 pouzivas? Ma stejny vektor jako ten citac.

Napsal: 17 čer 2019, 18:32
od ZdenekHQ
Však já to na test upravil tak, aby to nic nemohlo ovlivnit. Nakonec obecně je povolenej snad jen T0, co se týká přerušení. A vzal jsem digitální osciloskop a zjistil, že ono to při přetečení sice správně načte do registrů nastavenou hodnotu (jinak by se rozhodil kmitočet), ale neudělá to CPL výstupu. Občas a náhodně.

T2 by měl běžet čistě hardwarově. A zlobí. Pravda, jsem na dorazu, takže 30MHZ krystal u 89C51RD2 a 5V.

Napsal: 17 čer 2019, 18:43
od termit256
No, to je divne. Ja mam ted na stole AT89LP51RD2 napichly na logicky analyzator, tak sem pripadne hod ten asm s tonem a muzu zkusit jestli mi to bude delat taky. Obvod je koupeny u mouseru, tak by to nemela byt cinska kopie. I kdyz i v Cine jsem je kupoval a chodily normalne.

Napsal: 17 čer 2019, 18:45
od ZdenekHQ
To nejde. Jednak je to chráněný HW klíčem, jednak potřebuješ externí EEPROM, a navíc ten tón jen tak nespustíš. :D

Napsal: 17 čer 2019, 18:58
od termit256
Ja myslel jen tu cast kodu co dela ten ton :-)
Delal jsem ted s citacem2 nejake casovani komunikace a zadne anomalie jsem nepozoroval. Slo o cyklicke vysilani neceho pres uart a pokud je mezera ve vysilani delsi jak 1ms, prejde slave do jineho rezimu takze bych poznal kdyby to blblo. Ale pouzivam AT89LP51RD2 coz je uplne jiny MCU.

Napsal: 17 čer 2019, 19:57
od ZdenekHQ
Tam bude skutečně HW problém, protože mám pocit, že pár minut po zapnutí ten efekt mizí. Dělám s tím víc jak 20 let, takže takový drobnosti bych měl umět. Ovšem HW je proti.

Dokonce jsem zkusil ten tón spustit a hodit SW do smyčky. Je to tam pořád. Jak může něco ovlivnit čistě HW proces?

Ale tu část klidně pošlu, nic tam ale neuvidíš, je to jen vložení konstanty do registrů a spuštění/zastavení T2.

Napsal: 17 čer 2019, 20:39
od termit256
Mozna by stalo za zkousku poslat to do microchipu, jak se na to budou tvarit. Pry jsou celkem komunikativni.

Neni mozne ze chvilkove vypadava oscilator? (dela to s externima hodinama taky?)