Attiny417/814/816/817 und avr-gcc, avr-libc

[AVR-Bastler (Gast)]

Hallo,

inzwischen gibt's die Attiny417/814/816/817 ja auch zu kaufen, und da 
ich ein neugieriger Mensch bin, könnte ich mir vorstellen, die neue 
Peripherie einfach mal auszuprobieren. Warum soll ich einen Attiny84A 
kaufen, wenn ich für's gleiche Geld einen einen 814 oder 816 bekomme.

Nun unterscheiden sich die "Neuen" ja nicht nur in der Peripherie von 
den "Alten". Wenn ich das richtig sehe, ist der Befehlssatz ja nicht 
mehr "Attiny". Ich komme auf 130 instructions, mit FMUL usw.
So viel hat auch ein ATmega.

Und dann die neue Speicherstruktur...

Was mache ich also, wenn ich nicht einfach Atmels Studio herunterlade, 
sondern mit avr-gcc und avr-libc (und einem Editor/einer IDE meiner 
Wahl) arbeite?

1. Macros schreiben für die Namen/Adressen aller Register und deren 
Bits. Die gibt's ja in der libc noch nicht. OK, das ist eine 
Fleißaufgabe...
Reicht das - kann man den Rest der "alten" Funktionen in der libc 
benutzen?

2. Kompilieren mit.. ja, mit was? Mit -mmcu=avr4, weil 8kB Flash? Oder 
mit -mmcu=avr5, weil der Addressbereich ja bis 0x9FFF geht?
Welche Version von avr-gcc braucht man mindestens?

3. Linker Script schreiben, damit der Linker die Bereiche an die 
richtigen Adressen packt? Wie macht man das? Wohin? Wie sieht das dann 
aus?

4. Habe ich etwas vergessen?


Oder lieber 5.: Warten bis jemand das alles gemacht hat?

[Johann L. (gjlayde)]

AVR-Bastler schrieb im Beitrag #4914467:
> Wenn ich das richtig sehe, ist der Befehlssatz ja nicht
> mehr "Attiny". Ich komme auf 130 instructions, mit FMUL usw.

Laut Atmel sind die eher als Xmega einzuordnen.

> Und dann die neue Speicherstruktur...
>
> Was mache ich also, wenn ich nicht einfach Atmels Studio herunterlade,
> sondern mit avr-gcc und avr-libc (und einem Editor/einer IDE meiner
> Wahl) arbeite?
>
> 1. Macros schreiben für die Namen/Adressen aller Register und deren
> Bits. Die gibt's ja in der libc noch nicht. OK, das ist eine
> Fleißaufgabe...
> Reicht das - kann man den Rest der "alten" Funktionen in der libc
> benutzen?

Ja, vorausgesetzt es wird eine passende Multilib-Variante ausgewählt, 
welche das ist ist mir aber nicht klar, siehe unten.

> 2. Kompilieren mit.. ja, mit was? Mit -mmcu=avr4, weil 8kB Flash? Oder
> mit -mmcu=avr5, weil der Addressbereich ja bis 0x9FFF geht?
> Welche Version von avr-gcc braucht man mindestens?

Die Devices werden allerdings von avr-gcc noch nicht unterstützt, und 
anhand der Eigenschaften passt wohl auch keiner der vorhandenen Cores.

Laut Datenblatt unterstützen auch die Kleinen CALL und JMP, was schonmal 
etwas verwirrend ist, aber auch bei anderen Herstellern nicht unbedingt 
unüblich (aus großen Cores werden Kompnenten raus-gexxxt, um die 
Derivatvielfalt zu erhöhen).

Die Frage Xmega oder nicht-Xmega entscheidet sich vor allem an der 
Frage, welcher Code für SP-Änderungen erzeugt werden soll, z.B.

void bar (void*);
void foo (void)
{
    int a[10];
    bar (a);
}

> 3. Linker Script schreiben, damit der Linker die Bereiche an die
> richtigen Adressen packt? Wie macht man das? Wohin? Wie sieht das dann
> aus?

Die Adressen geben sich einerseits durch die Emulation und daher durch 
das Linker-Description-File für diese, und andererseits durch Optionen, 
die avr-gcc an den Linker gibt, welche wiederum im specs-File (ab 
avr-gcc v5) beschrieben sind.  Ein specs-File pro Device wäre also 
ausreichend.

Was Mapping von Flash in den Adressraum von LD* betrifft, so kann man 
die gleiche Lösung wählen wie für reduced Tiny, dh man braucht weder 
__flash noch PROGMEM, siehe auch das Beispiel für ATtiny40 in

https://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html

Wobei der Offset nicht 0x4000 ist sondern 0x8000 WIMRE.

> 4. Habe ich etwas vergessen?

- specs-File für's Device

- Startup-Code.  Kann erhalten werden aus der avr-libc Quelle, was
  aber auch einen Device-Header voraussetzt, zumindest teilweise um
  z.B. Größe der vectab zu erhalten.

- avr-gcc wird versuchen gegen die Devicelib zu linken, die es aber
  nicht gibt, d.h. selber generieren oder -nodevicelib verwenden.

> Oder lieber 5.: Warten bis jemand das alles gemacht hat?

[AVR-Bastler (Gast)]

Johann L. schrieb:
> Laut Atmel sind die eher als Xmega einzuordnen.
Ja, auf avrfreaks.net wird der name ATxtiny vorgeschlagen.

Johann L. schrieb:
> https://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html
>
> Wobei der Offset nicht 0x4000 ist sondern 0x8000 WIMRE.

Oh, fein - da ist ja mal so ein Ding. Dann wäre Punkt 3 damit ja 
erledigt.

Johann L. schrieb:
> Die Devices werden allerdings von avr-gcc noch nicht unterstützt, und
> anhand der Eigenschaften passt wohl auch keiner der vorhandenen Cores.

Bist Du sicher?
Atmel empfiehlt Studio 7 für die neuen ATtiny - das benutzt ja auch gcc.
Allerdings weiß ich nicht, welche Version. 6.1? 6.3?

Johann L. schrieb:
> specs-File für's Device
Das hört sich nach Arbeit an...

Johann L. schrieb:
> - Startup-Code.
Also ausgehend von  gcrt1.S in der libc-Source?

[Johann L. (gjlayde)]

AVR-Bastler schrieb im Beitrag #4914658:
> Johann L. schrieb:
>> Die Devices werden allerdings von avr-gcc noch nicht unterstützt, und
>> anhand der Eigenschaften passt wohl auch keiner der vorhandenen Cores.
>
> Bist Du sicher?

Nein. Verwechsel ich möglicherweise auch mit ATtiny102.  Um Datenflash 
nett zu unterstützen wäre eine eigene Emulation allerdings 
wünschenswert, aber ein eigened ld-Sktipt geht für den Hausgebrauch ja 
auch..

> Atmel empfiehlt Studio 7 für die neuen ATtiny - das benutzt ja auch gcc.
> Allerdings weiß ich nicht, welche Version. 6.1? 6.3?

Interessanter wäre, was wie gepatched wurde.

> Johann L. schrieb:
>> specs-File für's Device
> Das hört sich nach Arbeit an...

Ähnliches Device suches, dessen specs-File lesen und den Kommentaren 
folgen.

> Johann L. schrieb:
>> - Startup-Code.
> Also ausgehend von  gcrt1.S in der libc-Source?

Ja, zumindest für die Teile, die nicht in der libgcc sind.

[AVR-Bastler (Gast)]

Johann L. schrieb:
> Interessanter wäre, was wie gepatched wurde.

Hmmm...
Atmel hat im September 2016 die Toolchain aktualisiert auf Version 
3.5.4.
Darin enthalten sind laut Release Notes
http://www.atmel.com/Images/avr8-gnu-toolchain-3.5.4.1709-readme.pdf:

GCC: 4.9.2
binutils: 2.26.20160125
avr-libc: "2.0.0"
gdb: 7.8

In den Release-Notes sind ATtiny817 & Co. nicht gelistet.
Auf der Website der Toolchain aber schon:
http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx?tab=devices
In der Online-Doku von Atmels avr-libc fehlen ATtiny817 & Co. wieder.

Verflixt - muss ich da jetzt 2 x 100MB Quellen herunterladen und 
"diff"en?
Nervig.
Ich geh' erst mal ins Bett...

[doppelschwarz (Gast)]

AVR-Bastler schrieb im Beitrag #4914467:
> Was mache ich also, wenn ich nicht einfach Atmels Studio herunterlade,
> sondern mit avr-gcc und avr-libc (und einem Editor/einer IDE meiner
> Wahl) arbeite?

Vielleicht hilfts: http://start.atmel.com/
Projekt starten, alles einstellen und exportieren. Keine Ahnung, wie 
schön der Code wird, aber vielleicht kann man damit dann sein Projekt 
starten.

[guest (Gast)]

Johann L. schrieb:
>> Johann L. schrieb:
>>> specs-File für's Device
>> Das hört sich nach Arbeit an...
>
> Ähnliches Device suches, dessen specs-File lesen und den Kommentaren
> folgen.
>
>> Johann L. schrieb:
>>> - Startup-Code.
>> Also ausgehend von  gcrt1.S in der libc-Source?
>
> Ja, zumindest für die Teile, die nicht in der libgcc sind.

AVR-Bastler schrieb im Beitrag #4914919:
> Verflixt - muss ich da jetzt 2 x 100MB Quellen herunterladen und
> "diff"en?
> Nervig.
> Ich geh' erst mal ins Bett...

Specs-File, Startup-Code und Device-Lib für die Teile findet man im 
"Atmel ATtiny Series Device Support (1.2.112)" Pack:
http://packs.download.atmel.com/
http://packs.download.atmel.com/Atmel.ATtiny_DFP.1.2.112.atpack
(zum Reinschauen einfach als .zip umbenennen)
Core nennt sich wohl "AVR8X" bzw. "avrxmega2", letzteres sollte der gcc 
kennen.

[AVR-Bastler (Gast)]

guest schrieb:
> Specs-File, Startup-Code und Device-Lib für die Teile findet man im
> "Atmel ATtiny Series Device Support (1.2.112)" Pack:

Danke!

Da scheint tatsächlich alles drin zu sein, was man braucht. Header, 
vor-kompilierter Start-up Code, asm inc-files...
Alles in 20MB.

Und so werden sie also eingeordnet:
avrxmega2 - XMEGA, > 8K, < 64K FLASH, < 64K RAM

Interessant.
Dann kann ich ja bestellen. ;-)

[Niklas B. (niklas90)]

Also, angenommen, meine avr-gcc toolchain wäre in 
/usr/local/CrossPack-AVR-20131216/, müsste ich die dann wie folgt 
ändern?

Atmel.ATtiny_DFP.1.3.132/gcc/dev/attiny814/avrxmega2/crtattiny814.o nach 
/usr/local/CrossPack-AVR-20131216/avr/lib/avrxmega2/ kopieren
Atmel.ATtiny_DFP.1.3.132/gcc/dev/attiny814/device-specs/specs-attiny814 
in Projektordner kopieren (wo das Makefile ist)
Atmel.ATtiny_DFP.1.3.132/include/avr/iotn814.h nach 
/usr/local/CrossPack-AVR-20131216/avr/include/avr kopieren

In /usr/local/CrossPack-AVR-20131216/avr/include/avr/io.h

#elif defined (__AVR_ATtiny814__)
#  include <avr/iotn814.h>

einfügen

Im Makefile
--specs specs-attiny814
zu den avr-gcc einfügen und -mmcu weglassen

Also er zumindest kompilieren tut er was, aber keine Ahnung ob das 
sinnvoll ist, was da rauskommt bei dieser main.c

#include <avr/io.h>
#include <util/delay.h>

int main() {
  PORTB.DIR = 1 << PIN0_bm;
  while(1) {
    _delay_ms(500);
    PORTB.OUT ^= 1 << PIN0_bm;
  }
  return 0;
}

Die io header file ist ganz anders als bei den "klassischen" AVRs. Dort 
sind jetzt überall structs. Zusätzlich sind auch Konstanten als 
Alternative drin, aber die sehen auch anders aus. Z.b. wird aus

DDRB

 jetzt

PORTB_DIR

Was aber der wirkliche Knackpunkt ist: Wie programmiere ich das Teil? Im 
Datenblatt ist beschrieben wie der UPDI pin funktioniert, aber avrdude 
kennt den 814 nicht, was kommt in so eine part description in der 
/usr/local/CrossPack-AVR-20131216/etc/avrdude.conf rein? Kann man sich 
da an den ATxmegas orientieren und die Werte aus der 
Atmel.ATtiny_DFP.1.3.132/atdf/ATtiny814.atdf oder dem Datenblatt holen?

Oder müsste man sich eher an den Attinys orientieren? Was die ganzen 
Werte bei den Attinys sind, verstehe ich nicht, gibt es dazu Docu?

Als Programmer hätte ich ein Attiny817 XPlained, da kann man ja den UPDI 
pin rausführen. Für avdude ist das Board doch ein JTAG, oder?

[Johann L. (gjlayde)]

Niklas B. schrieb:
> Also, angenommen, meine avr-gcc toolchain wäre in
> /usr/local/CrossPack-AVR-20131216/, müsste ich die dann wie folgt
> ändern?

Kommt drauf an, welche Toolchain du verwendest.  Atmel sortiert diese 
Devices unter avrxmega2 ein, während der offizielle FSF avr-gcc 
avrxmega3 verwendet.

> Im Makefile
> --specs specs-attiny814
> zu den avr-gcc einfügen und -mmcu weglassen

-mmcu=attiny1617 muss reichen, der Treiber soll das specs-File wählen, 
nicht der Anwender.  Außerdem ist es ein Unterschied, ob das Device 
unterstützt wird oder nicht; ich weiß jetzt nicht, wie sich der Compiler 
verhält, wenn man ein bereits unterstütztes Device so behandelt als sei 
es nicht unterstützt.

> In $INSTALL/avr/include/avr/io.h
> #elif defined (_AVR_ATtiny814_)
> #  include <avr/iotn814.h>
>
> einfügen

avr/io.h braucht man nicht zu hacken, siehe Kommentare im specs-File.

[Niklas B. (niklas90)]

Also alle fertigen Builds, die ich bisher kenne (WinAVR für Windows von 
2010, Crosspack von 2013 für Mac und die GNU toolchain von Atmel 
http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.5.4/) 
kennen den ATtiny814 noch nicht.

Deshalb geht auch -mmcu=attiny814 nicht (kennt mein avr-gcc nicht), 
weshalb ich dem compiler das spec file als parameter übergebe. Dort wird 
(vermute ich jedenfalls), die Zeile unter *cpp:

-D__AVR_ATtiny814__ -D__AVR_DEVICE_NAME__=attiny814 -D__AVR_DEV_LIB_NAME__=tn814

 an den compiler übergeben. Damit wird in der io.h

#elif defined (__AVR_ATtiny814__)
#  include <avr/iotn814.h>

getriggert, da io.h in der main.c included ist.

Ich vermute man kann sich eine neue Version der toolchain selbst 
kompilieren, wie z.B. hier beschrieben 
https://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain#LinuxundMacOSX, 
habe ich aber noch nicht ausprobiert.

Falls jemand eine aktuelle Version hat, würde mich mal interessieren, 
was als .hex File bei ihm rauskommt, wenn der Code oben kompiliert wird. 
Mit meinen Patches sieht die aus wie angefügt.

Hier noch ein minimal working Makefile:

TARGET    = project
CLOCK    = 20000000
SOURCE    = main

COMPILE = avr-gcc -Wall -Os -DF_CPU=$(CLOCK) --specs specs-attiny814

all:
  $(COMPILE) -c $(SOURCE).c -o $(SOURCE).o # compile
  $(COMPILE) $(SOURCE).o -o $(TARGET).elf # link
  avr-objcopy -O ihex -j .data -j .text $(TARGET).elf $(TARGET).hex

[Niklas B. (niklas90)]

Um den Thread zu vervollständigen: Die Programmierung geht mit dem 
Python Projekt pyupdi 
(https://github.com/mraardvark/pyupdi/blob/master/pyupdi.py).

Beispiel Ausführung:

python3 pyupdi.py -d tiny814 -c /dev/tty.usbserial-A50285BI -f ../ATtiny814_Blink/project.hex

Bei mir hat es allerdings erst mit einem FTDI basiertem USB-UART Adapter 
geklappt.

Kompiliert wie gesagt mit main.c, Makefile und specs-attiny814 in einem 
Projektordner, sowie
mit <toolchain-pfad>/avr/include/avr/iotn814.h
und <toolchain-pfad>/avr/lib/avrxmega2/crtattiny814.o