GPIORn

Odpovědět
butan
Příspěvky: 61
Registrován: 02 dub 2019, 07:06

GPIORn

Příspěvek od butan » 18 pro 2019, 12:20

Použil jste někdy někdo na atmelech GPIORn registry?
Lubor
PS po chvilkách si listuji návodem od CPU arduína uno, a často narazím na něco neobvyklého.

DavidO
Příspěvky: 959
Registrován: 01 kvě 2013, 21:27

Re: GPIORn

Příspěvek od DavidO » 18 pro 2019, 13:23

To jsou prostě 3 bajty v I/O prostoru navíc. Žádná periferie je nepoužívá, programátor si s nima může dělat, co chce, třeba si tam něco uložit. Podobně jako bit T ve stavovém registru.

butan
Příspěvky: 61
Registrován: 02 dub 2019, 07:06

Re: GPIORn

Příspěvek od butan » 18 pro 2019, 20:24

A po resetu se ta ramka nuluje.
pokud to neudělá bootloader, ale když už jsem si udělal debugger, tak to můžu snadno zkontrolovat.
Lubor

DavidO
Příspěvky: 959
Registrován: 01 kvě 2013, 21:27

Re: GPIORn

Příspěvek od DavidO » 18 pro 2019, 21:57

V datasheetu píšou, že po resetu tam je 0, takže leda obráceně, že by ti tam bootloader něco strčil (ale proč, když se obvykle používá generický, který nemá důvod)

HonzaD
Příspěvky: 9
Registrován: 17 bře 2020, 12:39

Re: GPIORn

Příspěvek od HonzaD » 17 bře 2020, 15:40

GPIOR0 a 1 jsou MNOHEM lepší než RAMKA - jsou v I/O prostoru dosažitelném instrukcemi cbi/sbi a lze testovat jednotlivé bity. Obecně přístup k nim je rychlejší než k obyčejné RAM a navíc je možné nastavovat/nulovat jednotlivé bity bez účasti registrů CPU. To je výhodné například (zejména) v obsluze přerušení které může vypadat např.

Kód: Vybrat vše

ISR(xxx_vect, ISR_NAKED) {
  GPIOR0|=MyFlag;
  reti();
}
Někde v programu si pak zkontroluji hodnotu MyFlag a vím, jestli se stala ta věc, které se dané přerušení týká. Obsluha přerušení je ale velmi rychlá, protože se nemusely ukládat žádné CPU registry.
Na první pohled to může vypadat jako samoúčelná blbost - mohl bych rovnou kontrolovat "flag" (jak se to řekne česky? vlajka?) příslušného přerušení. Pokud ale např. je procesor uspaný a je víc možných příčin, proč se probudí, tak se to musí udělat např. takhle. Druhá věc je, že do ISR mohu přidat např. "PORTB|=1", což také nejde přes CPU registry a zareaguje "ihned" a složitější rekce přijde "až bude mít procesor čas".

Jestli si dobře vzpomínám u ATMega328 je GPIOR2 mimo "privilegovanou" I/O oblast a oproti RAM paměti žádné výhody nemá.

DavidO
Příspěvky: 959
Registrován: 01 kvě 2013, 21:27

Re: GPIORn

Příspěvek od DavidO » 19 bře 2020, 12:16

Dík za připomenutí! :idea:
Na 128 nejsou (tam jsem používal v přerušení právě ten T) a s 328 jsem ještě takovýhle kejkle nedělal, tak mi to nedocvaklo...

Na 328 (+ těch stejných menších 48/88/168) a i na 16/32U4 je takhle použitelný jen GPIOR0, protože ty 4 instrukce co s tím pracujou přímo (nastavení SBI a CBI a podmíněné skoky SBIC a SBIS) dosáhnou jen na IO registry 0-31, ale GPIOR1 a 2 mají adresy nad 32. Takže z nějakého vyššího jazyka by se to muselo asi opsat a už to bysme si nepomohli.

DavidO
Příspěvky: 959
Registrován: 01 kvě 2013, 21:27

Re: GPIORn

Příspěvek od DavidO » 19 bře 2020, 14:48

Hm, tak teď jsem si to zkusil, ale avr-g++ (z instalace Arduina) mi to udělalo klasickou read-modify-write trojičkou in-ori-out pro libovolný dolní IO registr (a stejně tak mi to vygeneruje i avr-gcc od WinAVR). To je ňáký divný. Že bych měl nějak blbě nastavený optimalizace?

HonzaD
Příspěvky: 9
Registrován: 17 bře 2020, 12:39

Re: GPIORn

Příspěvek od HonzaD » 01 dub 2020, 17:13

Myslím, že to bude vypnutou optimalizací. Mě každopádně Atmel Studio 7.0 generuje sbi/cbi, když to jde (i pro PINB|=1, což se dá považovat za bug).

Ještě jsem na to koukal - GPIOR1 a 2 skutečně nejsou dosažitelné pomocí instrukcí sbi, cbi, ale jsou v dosahu instrukcí in a out (ty dosáhnou až k registru 0x3F, což je snad vždy SREG). Takže je přeci jen o kousek efektivnější použít jeden z těchto dvou než SRAM.

Odpovědět

Kdo je online

Uživatelé prohlížející si toto fórum: Žádní registrovaní uživatelé a 3 hosti