direkt in ein Register des Tiny5 schreiben

[Svensson (svensson)]

Hallo liebe Gemeinde,

ich möchte auf einem AT Tiny5 direkt mit dem Register PCMSK (0x10) 
arbeiten. Also ungefähr so:

PCMSK |= (1<<PCINT0);    //enable pin change interrupt on PB3

Wie macht man so etwas in einem C-Script für avr-gcc?

PCMSK ist doch auch nur eine Definition für irgendetwas, um sich das 
Leben einfacher zu gestalten.

Vielen Dank im voraus

Svensson

[Nemopuk (nemopuk)]

In jeder halbwegs ordentlichen IDE kannst mit gedrückt gehaltener Strg 
Taste auf PCMSK klicken, dann siehst du, wie es definiert ist. Es ist 
ein Zeiger mit der Adresse des Registers.

Und PCINT0 ist schlicht eine Zahl und zwar die Nummer dieses Bits.

Direkter als
> PCMSK |= (1<<PCINT0);
sowie
> PCMSK &= ~(1<<PCINT0);
geht es in C nicht, weil die Programmiersprache keine gesonderte Syntax 
für Register hat und auch nicht für dem Zugriff auf einzelne Bits. Aber 
keine Sorge, der Compiler ist so schlau, diese Zeile in einen einzigen 
CPU Befehl umzusetzen, auch wenn sie eher nach einer Kombo aus 
read+modify+write back aussieht.

[Svensson (svensson)]

Okay wenn es in C nicht geht, wie schreibe ich das dann in 
Inline-Assembler um?

asm {
      "ldi r16,0x4\n"
      "mov r10,r16\n"
}

[Oliver S. (oliverso)]

Svensson schrieb:
> Okay wenn es in C nicht geht, wie schreibe ich das dann in

Dann nochmal etwas deutlicher:

Was funktioniert denn an „PCMSK |= (1<<PCINT0);“ nicht?

Oliver

[Svensson (svensson)]

Ich habe in meiner IDE keine vorgegebene io.h für den Tiny5. In der Doku 
habe ich gelesen, daß PCMSK das Register 0x10 ist.

Ich brauche auch nur diesen einen direkten Befehl, um das eine Bit im 
PCMSK zu setzen. Der Rest ist dann Standard C.

[Oliver S. (oliverso)]

https://www.avrfreaks.net/s/topic/a5C3l000000UCFbEAO/t060889

Oliver

[Ob S. (Firma: 1984now) (observer)]

Svensson schrieb:

> Ich habe in meiner IDE keine vorgegebene io.h für den Tiny5.

Dann sorg' dafür, dass du eine hast. Der Tiny5 ist dermaßen 
übersichtlich, das man die zur Not sogar von Hand verfassen könnte. Aber 
warum sollte man? Gibt's ja schließlich fix und fertig von MC.

Musst du halt die IDE wechseln. Welche ist es den derzeit?

[Nemopuk (nemopuk)]

Svensson schrieb:
> Ich habe in meiner IDE keine vorgegebene io.h für den Tiny5.

Aber die avr-libc bringt die Header mit.

#define __SFR_OFFSET 0x00
#define _SFR_IO8(io_addr) ((io_addr) + __SFR_OFFSET)

#define PCMSK _SFR_IO8(0x10)
#define PCINT0 0
#define PCINT1 1
#define PCINT2 2
#define PCINT3 3

[Falk B. (falk)]

Svensson schrieb:
> Okay wenn es in C nicht geht, wie schreibe ich das dann in

Das hat KEINER geschrieben! Versuchs mal mit sinnerfassendem Lesen!

[Ob S. (Firma: 1984now) (observer)]

Nemopuk schrieb:

> Aber die avr-libc bringt die Header mit.

Ja klar. Deswegen führt nur die Beantwortung meiner Frage, welche IDE 
dee TO eigentlich verwendet (und damit der Frage, welche Toolchain und 
damit wiederum welche Header).

Genau diese eine zentrale Frage wurde vom TO allerdings negativ 
bewertet.

Sprich: Das ist ganz offensichtlich ein Troll, der sich darum sorgt, 
dass sein Troll-Thread zu kurz wird.

[Nemopuk (nemopuk)]

Nemopuk schrieb:

#define __SFR_OFFSET 0x00
#define _SFR_IO8(io_addr) ((io_addr) + __SFR_OFFSET)
#define PCMSK _SFR_IO8(0x10)

Mir fehlt da der Pointer. Aber ich bin ganz sicher, die Zeilen korrekt 
aus den Headern heraus kopiert zu haben. Und war da nicht auch was mit 
volatile?

Vielleicht kann das jemand erklären.

[Nemopuk (nemopuk)]

Nemopuk schrieb:
> Vielleicht kann das jemand erklären.

Ich hab's selbst gefunden. Ich habe wohl doch die falschen Zeilen 
kopiert.

So sieht es besser aus:

#define __SFR_OFFSET 0x00
#define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))
#define _SFR_IO8(io_addr) _MMIO_BYTE((io_addr) + __SFR_OFFSET)
#define PCMSK _SFR_IO8(0x10)

Man kann die Definition von PCMSK so zusammen fassen:

#define PCMSK (*(volatile uint8_t *)(0x10))

Also ein Zeiger auf ein volatiles 8 Bit Register an Adresse 0x10. So 
hatte ich das auch in Erinnerung.

[Svensson (svensson)]

Nemopuk schrieb:
> Man kann die Definition von PCMSK so zusammen fassen:
> #define PCMSK (*(volatile uint8_t *)(0x10))
>
> Also ein Zeiger auf ein volatiles 8 Bit Register an Adresse 0x10. So
> hatte ich das auch in Erinnerung.

Danke! Das ist genau das, was ich gesucht hatte. Und schon ist der 
Fehler weg...

Ob S. schrieb:
> Der Tiny5 ist dermaßen
> übersichtlich, das man die zur Not sogar von Hand verfassen könnte.

Das kann man wohl sagen. Das "Programm" ist so ungefähr 20 Zeilen lang. 
Im Grunde ist es ein Luxus-Timer; ist auch nicht mein Ding - ich soll es 
nur kompilieren. Kompliliert sind es 470 Byte, also eher übersichtlich.

Ob S. schrieb:
> Genau diese eine zentrale Frage wurde vom TO allerdings negativ
> bewertet.

Ich habe gar nichts bewertet.

Hintergrund: Ich habe schon den ganzen Tag verplempert, um das 
Miniprogramm zu übersetzen. War schon kurz davor, das gleich in 
Assembler neu zu schreiben. :-(
Beim Atmel Studio 4.19 habe ich wohl vergessen wie es geht, außerdem ist 
der Tiny5 grau in der Liste. Bei avr-gcc (avr8-gnu-toolchain 3.7.x) 
erhalte ich die Meldung, daß beim Tiny5 nur Assembler unterstützt wird. 
Ebenso beim WinAVR. Dann habe ich mir den GCC 10.3 heruntergeladen, aber 
in der 1000+x-seitigen Doku habe ich nur -mmcu=avrtiny gefunden, der 
aber nicht laufen will.
VS mit PlatformIO habe ich mir auch heruntergeladen, aber das ist auch 
nichts für mal eben schnell.

[Johann L. (gjlayde)]

Du hast einfach nur eine hornalte Toolchain. Besorg dir was aktuelles, 
und fertig ist der Lack.

[Svensson (svensson)]

Nun, die avr8-gnu-toolchain habe ich von Microchip heruntergeladen. Das 
war schon die neueste Version (von 2022).

Den gcc habe ich direkt von der Projektwebsite. Da habe ich extra den 
älteren 10.3 gewählt, weil es doch angeblich mit den neueren irgenwelche 
Probleme gab.

[A. B. (Firma: ab) (bus_eng)]

aktuell ist gcc-15.2.0 von 2025-08-08

https://github.com/ZakKemble/avr-gcc-build/releases/tag/v15.2.0-1

[Norbert (der_norbert)]

Svensson schrieb:
> Den gcc habe ich direkt von der Projektwebsite. Da habe ich extra den
> älteren 10.3 gewählt, weil es doch angeblich mit den neueren irgenwelche
> Probleme gab.


A. B. schrieb:
> aktuell ist gcc-15.2.0 von 2025-08-08

~$ find /usr/lib/gcc/avr/ /usr/lib/avr -iname "iotn5*.h" -exec grep -E "tiny|PCMSK" {} \;
/* avr/iotn5.h - definitions for ATtiny5 */
#ifndef _AVR_ATtiny5_H_
#define _AVR_ATtiny5_H_ 1
#define PCMSK _SFR_IO8(0x10)
#endif /* _AVR_ATtiny5_H_ */

~$ avr-gcc -v
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/5.4.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/5.4.0/lto-wrapper
Target: avr
Configured with: ../gcc/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr CFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-Q3AFj7/gcc-avr-5.4.0+Atmel3.6.2=. -fstack-protector-strong -Wformat ' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' CXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-Q3AFj7/gcc-avr-5.4.0+Atmel3.6.2=. -fstack-protector-strong -Wformat ' FCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-Q3AFj7/gcc-avr-5.4.0+Atmel3.6.2=. -fstack-protector-strong' FFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-Q3AFj7/gcc-avr-5.4.0+Atmel3.6.2=. -fstack-protector-strong' GCJFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-Q3AFj7/gcc-avr-5.4.0+Atmel3.6.2=. -fstack-protector-strong' LDFLAGS=-Wl,-z,relro OBJCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-Q3AFj7/gcc-avr-5.4.0+Atmel3.6.2=. -fstack-protector-strong -Wformat ' OBJCXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-avr-Q3AFj7/gcc-avr-5.4.0+Atmel3.6.2=. -fstack-protector-strong -Wformat '
Thread model: single
gcc version 5.4.0 (GCC)

[Peter D. (peda)]

Svensson schrieb:
> ich möchte auf einem AT Tiny5 direkt mit dem Register PCMSK (0x10)
> arbeiten. Also ungefähr so:

PCMSK |= (1<<PCINT0);    //enable pin change interrupt on PB3

> Wie macht man so etwas in einem C-Script für avr-gcc?

Nicht nur ungefähr, sondern genau so.
Falls eine Fehlermeldung kommt, hast Du noch diese Zeile vergessen:

#include <avr/io.h>

Oder das falsche Target ausgewählt.

[Johann L. (gjlayde)]

Svensson schrieb:
> Also ungefähr so:
>
> PCMSK |= (1<<PCINT0);    //enable pin change interrupt on PB3
>
> Wie macht man so etwas in einem C-Script für avr-gcc?

Das geht so nicht. In C müssen Anweisungen in einer Funktion stehen.

[Svensson (svensson)]

Norbert schrieb:
>

> Reading specs from /usr/lib/gcc/avr/5.4.0/device-specs/specs-avr2
> ...
> gcc version 5.4.0 (GCC)
>

Sagt mir das, es wird der gcc in Version 5.4.0 benutzt? Dann wäre das 
auch nicht "modern".

A. B. schrieb:
> aktuell ist gcc-15.2.0 von 2025-08-08
>
> https://github.com/ZakKemble/avr-gcc-build/releases/tag/v15.2.0-1

Tausend Dank! Das ist offensichtlich genau das, was ich gleich hätte 
verwenden sollen.

Johann L. schrieb:
> Das geht so nicht. In C müssen Anweisungen in einer Funktion stehen.

Erbsenzähler. :-) Im Zweifel steht es dann in setup{} oder main{}

[Norbert (der_norbert)]

Svensson schrieb:
> Sagt mir das, es wird der gcc in Version 5.4.0 benutzt? Dann wäre das
> auch nicht "modern".

Das sagt dir, dass das Headerfile für den ATtiny5 bereits dort vorhanden 
ist und nur auf die passende Einbindung wartet.
Bevorzugt per ›io.h‹ und passendem Target.

[Harald K. (kirnbichler)]

Svensson schrieb:
> Im Zweifel steht es dann in setup{}

Das riecht nach Arduino, und das ist dann kein C, sondern C++.

[Norbert (der_norbert)]

Harald K. schrieb:
> Svensson schrieb:
>> Im Zweifel steht es dann in setup{}
>
> Das riecht nach Arduino, und das ist dann kein C, sondern C++.

Wobei das hier: ›setup{}‹
nach einem völlig neuen language feature aussieht. ;-)

[Johann L. (gjlayde)]

Svensson schrieb:
> Sagt mir das, es wird der gcc in Version 5.4.0 benutzt?

Das sagt dir

$ avr-gcc --version

Und selbst wenn es eine v5.4 ist, bereits damals vor fast 10 Jahren 
wurde AVRrc (Reduced Core) schon unterstützt:

https://gcc.gnu.org/gcc-5/changes.html#avr

[Svensson (svensson)]

Johann L. schrieb:
> Das sagt dir$ avr-gcc --version
>
> Und selbst wenn es eine v5.4 ist, bereits damals vor fast 10 Jahren
> wurde AVRrc (Reduced Core) schon unterstützt:

Ich erhalte als Antwort:
avr-gcc (AVR_8_bit_GNU_Zoolchain_3.7.0.1796> 7.3.0

Also müßte der funktionieren, aber das tut er nicht. Es kommt die 
Meldung, daß nur Assembler unterstützt wird für -mmcu=attiny5.

> das ist dann kein C, sondern C++

Der gcc ist doch ein C-Compiler, der gpp ist doch der Compiler für C++, 
oder?

Außerdem müßte das doch egal sein, denn ein C++-Compiler müßte doch auch 
Standard-C übersetzen können?

[Peter D. (peda)]

Habs eben probiert mit 5.4.0 (= AS7) und 7.3.0, geht beides:

int main(void)
{
  PCMSK |= (1<<PCINT0);
  28:  80 9a         sbi  0x10, 0  ; 16

[Norbert (der_norbert)]

Peter D. schrieb:
> Habs eben probiert mit 5.4.0 (= AS7) und 7.3.0, geht beides:
> int main(void)
> {
>   PCMSK |= (1<<PCINT0);
>   28:  80 9a         sbi  0x10, 0  ; 16

Das ist aber vermutlich 7.3.0 output, oder?
Der alte 5.4.0 erzeugt zumindest bei mir hier nämlich noch einen ganzen 
Sack mehr. Egal in welcher Optimierungsstufe (O0|O1|O2|Os).

#include <avr/io.h>
// avr-gcc -Wall -Wextra -pedantic -mmcu=attiny5 -os -o x x.c && avr-objdump -d x > xs.lst

int main(void) {
    PCMSK |= (1<<PCINT0);
    return 0;
}

00000000 <main>:
   0:  cf 93         push  r28
   2:  df 93         push  r29
   4:  cd b7         in  r28, 0x3d  ; 61
   6:  de b7         in  r29, 0x3e  ; 62
   8:  40 e1         ldi  r20, 0x10  ; 16
   a:  50 e0         ldi  r21, 0x00  ; 0
   c:  60 e1         ldi  r22, 0x10  ; 16
   e:  70 e0         ldi  r23, 0x00  ; 0
  10:  e6 2f         mov  r30, r22
  12:  f7 2f         mov  r31, r23
  14:  60 81         ld  r22, Z
  16:  61 60         ori  r22, 0x01  ; 1
  18:  e4 2f         mov  r30, r20
  1a:  f5 2f         mov  r31, r21
  1c:  60 83         st  Z, r22
  1e:  40 e0         ldi  r20, 0x00  ; 0
  20:  50 e0         ldi  r21, 0x00  ; 0
  22:  84 2f         mov  r24, r20
  24:  95 2f         mov  r25, r21
  26:  df 91         pop  r29
  28:  cf 91         pop  r28
  2a:  08 95         ret

Edit: Comment korrigiert

[Nemopuk (nemopuk)]

Norbert schrieb:
> Der alte 5.4.0 erzeugt zumindest bei mir hier nämlich noch einen ganzen
> Sack mehr.

Krass! Das sieht aus, als ob du eine negative Optimierungsstufe 
eingeschaltet hättest.

[Norbert (der_norbert)]

Man kann's noch ein wenig quetschen… ;-)

#include <avr/io.h>
// avr-gcc -Wall -Wextra -pedantic -mmcu=attiny5  -o x x.c && avr-objdump -d x 
__attribute__ ((OS_main))
int main(void) {
    PCMSK |= (1<<PCINT0);
    __builtin_unreachable();
}

00000028 <main>:
  28:  cd b7         in  r28, 0x3d  ; 61
  2a:  de b7         in  r29, 0x3e  ; 62
  2c:  40 e1         ldi  r20, 0x10  ; 16
  2e:  50 e0         ldi  r21, 0x00  ; 0
  30:  60 e1         ldi  r22, 0x10  ; 16
  32:  70 e0         ldi  r23, 0x00  ; 0
  34:  e6 2f         mov  r30, r22
  36:  f7 2f         mov  r31, r23
  38:  60 81         ld  r22, Z
  3a:  61 60         ori  r22, 0x01  ; 1
  3c:  e4 2f         mov  r30, r20
  3e:  f5 2f         mov  r31, r21
  40:  60 83         st  Z, r22

[Peter D. (peda)]

Anbei das Lst und Hex bei -Os des 5.4.0

#include <avr/io.h>

int main(void)
{
  PCMSK |= (1<<PCINT0);
  while(1) {
  }
}

[Norbert (der_norbert)]

Interessant.
Da musst du tatsächlich einen anderen 5.4.0 als ich haben.

/tmp/norbert$ avr-gcc --version
avr-gcc (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Klaus H. (klummel69)]

Norbert schrieb:
> Das ist aber vermutlich 7.3.0 output, oder?
> Der alte 5.4.0 erzeugt zumindest bei mir hier nämlich noch einen ganzen
> Sack mehr.

Probiers mal Compiler Explorer, bei mir kommt auch mit AVR 5.4.0 die 
schlanke Version raus.

https://godbolt.org/z/9fceGxbMc

Stimmt bei die Compileroption?
Statt "-os" müsste es "-Os" lauten.

[Norbert (der_norbert)]

Klaus H. schrieb:
> Stimmt bei die Compileroption?
> Statt "-os" müsste es "-Os" lauten.

Verdammt! Genau das war's.
Und das anschließende -o <outfile> hat's dann ohne irgend eine Warnung 
überschrieben. (Auch kein ›s‹ angelegt)

Einmal ohne makefile, schon ist's passiert.

Gutes Auge!

[Johann L. (gjlayde)]

Svensson schrieb:
> avr-gcc (AVR_8_bit_GNU_Zoolchain_3.7.0.1796> 7.3.0

Also eine von Atmel gepimpte Version.

> Also müßte der funktionieren, aber das tut er nicht. Es kommt die
> Meldung, daß nur Assembler unterstützt wird für -mmcu=attiny5.

Sehr seltsam.  Diese Meldung sollte nur kommen für -mmcu= at90s1200, 
attiny11, attiny12, attiny15 oder attiny28.  Alle anderen Devices 
sollten entweder funktionieren oder komplett abgelehnt werden (specs 
File nicht gefunden etc.)

Und wo man auf jeden Fall drauf achten sollte, ist dass LDS und STS eine 
16-Bit Codierung haben.  Ansonsten: Binutils Bug.

Builds for Windows findet man bei Microchip, Zak Kemble oder

https://sourceforge.net/projects/winavr/files/avr-gcc/

[Klaus H. (klummel69)]

Norbert schrieb:
> Gutes Auge!

Adler Augen....

Schön wär`s. Der Compiler Explorer hat gemeckert....
Hab deine Option per Copy&Paste eingefügt.

Das ist der Grund, weshalb ich bei lokalen
Compiler-Problemen gerne darauf zurück greife.

[Norbert (der_norbert)]

Klaus H. schrieb:
> Schön wär`s. Der Compiler Explorer hat gemeckert....
> Hab deine Option per Copy&Paste eingefügt.

Hätte ich mir von avr-gcc auch gewünscht.

Das Verrückte ist, hab gerade in die bash history geschaut. Weiter oben 
hatte ich es erst einmal richtig und im weiteren Verlauf mit 
verschiedenen Optimierungen dann zielsicher durch editieren versaut. ;-)