Informationen zu Atmel AVR Controller ( nur Info )

[Mathias]

Ich habe gerade eine coole Seite von Atmel entdeckt
Da findet man viele Infos und Datenblätter zu den Atmel's.

Auch gibt es zu jedem Atmel eine XML-Datei, die hat wohl die Endung *.atdf, ist aber ein normaler XML-Code.
Auch kommt man direkt an die Datenblätter.

http://packs.download.atmel.com/

So nebenbei habe ich festgestellt, das alle *.pp für die AVR's, Ähnlichkeiten mit den adtf-Dateien haben, inklusive die Kommentare.
Daher vermute ich, das die Entwickler der AVR FPC Bibliotheken eine Konverter geschrieben habe um die die *.pp automatisch zu generieren. Bitte mich korrigieren, wen es anders ist.

Wen ich die Lizenz richtig verstanden habe, darf man diese Dateien für eigene Zwecke verwenden, solange man auch den Lizenztext mitkopiert ?

[PascalDragon]

So nebenbei habe ich festgestellt, das alle *.pp für die AVR's, Ähnlichkeiten mit den adtf-Dateien haben, inklusive die Kommentare.
Daher vermute ich, das die Entwickler der AVR FPC Bibliotheken eine Konverter geschrieben habe um die die *.pp automatisch zu generieren. Bitte mich korrigieren, wen es anders ist.

Das Tool stammt von ccrause.

[Mathias]

Das Tool stammt von ccrause.

Tolle Tool. Von ccrauss habe ich schon viele gute Sachen gesehen.

Nun bin ich neugierig geworden und habe das Tool ausprobiert. Auf den ersten Blick sieht das Ergebniss gleich aus, wie die Dateien von FPC-Sourcen.
Aber es hat doch einige Abweichungen. ZB. bei den Pins.
Tool von ccrause, mit den neusten atdf-Datein, sowie von 2019:

Code: Alles auswählen

unit ATmega328P;

{$goto on}
interface

var
  PINB: byte absolute $23;  // Port B Input Pins
  DDRB: byte absolute $24;  // Port B Data Direction Register
  PORTB: byte absolute $25;  // Port B Data Register
  PINC: byte absolute $26;  // Port C Input Pins
  DDRC: byte absolute $27;  // Port C Data Direction Register
  PORTC: byte absolute $28;  // Port C Data Register
  PIND: byte absolute $29;  // Port D Input Pins
  DDRD: byte absolute $2A;  // Port D Data Direction Register
  PORTD: byte absolute $2B;  // Port D Data Register
  ...

FPC-Sourcen vom 11. April:

Code: Alles auswählen

unit ATmega328P;

{$goto on}

interface

var
  // USART0
  UDR0 : byte absolute $00+$C6; // USART I/O Data Register
  UCSR0A : byte absolute $00+$C0; // USART Control and Status Register A
  UCSR0B : byte absolute $00+$C1; // USART Control and Status Register B
  ...
  // PORTB
  PORTB : byte absolute $00+$25; // Port B Data Register
  DDRB : byte absolute $00+$24; // Port B Data Direction Register
  PINB : byte absolute $00+$23; // Port B Input Pins
  // PORTC
  PORTC : byte absolute $00+$28; // Port C Data Register
  DDRC : byte absolute $00+$27; // Port C Data Direction Register
  PINC : byte absolute $00+$26; // Port C Input Pins
  // PORTD
  PORTD : byte absolute $00+$2B; // Port D Data Register
  DDRD : byte absolute $00+$2A; // Port D Data Direction Register
  PIND : byte absolute $00+$29; // Port D Input Pins

Die grösste Abweichung ist, das bei den FPC-Sourcen immer "$00+$xx" steht. bei dem Tool fehlt überall das "$00+".
Auch die Reihenfolge der Konstanten ist anders, was an anderen oder sehr alten Versionen von den atdf-Dateien liegen kann.

Auch gab es mit dem Tool noch folgende Port-Konstanten.

Code: Alles auswählen

const
  // Port B Data Register
  PB0 = $00;  
  PB1 = $01;  
  PB2 = $02;  
  PB3 = $03;  
  ...

Andere Sachen, wie Interrupt-Tabelle sehen gleich aus.

Weiss einer der Grund dieser Abweichung ?

[PascalDragon]

Weiss einer der Grund dieser Abweichung ?

Schau dir doch mal bitte die Zeitstempel an. Die atmega328p Unit ist 6 Jahre alt. Das Tool von ccrause ist 3 Jahre alt. Also, logische Antwort: entweder wurde damals von Jeppe ein anderes Tool genutzt oder er hat die Konvertierung von Hand gemacht.

[Mathias]

Das ist jetzt aber recht interessant, das die Dateien 6 Jahre alt sind. So wie ich mich erinnern mag, kam der AVR Run in Lazarus erst etwa 2017/2018, dies wären erst etwa 5 Jahre. Das da in dieser Zwischenzeit nichts mehr geändert wurde erstaunt mich echt.
Nach meiner Meinung schade, das die nicht die neusten atdf-Dateien mit ccrause Tools bearbeitet wurden. Es hat doch einige Neuerungen in den adtf-Dateien geben, vor allem einige Konstanten.

Was mit noch in den adtf-Dateien der ATtiny und ATmega-Familie aufgefallen ist, dort steht überall bei achitecture "AVR8". Ist das etwa nicht das gleiche, wie die SubArch, welche man bei den FPC Crosscompilern einstellen muss ?

[PascalDragon]

Das ist jetzt aber recht interessant, das die Dateien 6 Jahre alt sind. So wie ich mich erinnern mag, kam der AVR Run in Lazarus erst etwa 2017/2018, dies wären erst etwa 5 Jahre.

Und? Der Port ist eben schon älter. Es musste ja erstmal gut genug funktionieren, bevor es sinnvoll war es auch aktiv zu nutzen.

Das da in dieser Zwischenzeit nichts mehr geändert wurde erstaunt mich echt.

Es gab keine Beschwerden, also warum was ändern?

Nach meiner Meinung schade, das die nicht die neusten atdf-Dateien mit ccrause Tools bearbeitet wurden. Es hat doch einige Neuerungen in den adtf-Dateien geben, vor allem einige Konstanten.

Dann reiche doch einen Merge Request mit aktualisierten Dateien ein.

Was mit noch in den adtf-Dateien der ATtiny und ATmega-Familie aufgefallen ist, dort steht überall bei achitecture "AVR8". Ist das etwa nicht das gleiche, wie die SubArch, welche man bei den FPC Crosscompilern einstellen muss ?

Nachdem FPC keinen AVR8 kennt, vermute ich mal, dass dies nicht das gleiche ist.

[Mathias]

Nachdem FPC keinen AVR8 kennt, vermute ich mal, dass dies nicht das gleiche ist.

Ich habe unterdessen die Herkunft herausgefunden, die 8 ist für 8Bit.

[ccrause]

Jeppe generierte eine Reihe von Einheiten mit seinem eigenen Skript. Er folgte einer etwas anderen Namenskonvention als die atdf/datasheets. Ich habe einen Fehlerbericht erstellt, um einige der Konstantennamen zu aktualisieren, aber Jeppe war nicht begeistert. Ich habe das atdf-Tool verwendet, um die Einheiten für Controller zu generieren, die in Jeppes Arbeit fehlten, die dann offensichtlich der atdf-Konvention folgte.

(Google Übersetzung)

[PascalDragon]

(Google Übersetzung)

Best also include the English text so that one can see where the translator might have done something wrong (e.g. it translated “units” with “Einheiten” which by itself isn't wrong, but is wrong in this context).

And thanks for the explanation!

[ccrause]

(Google Übersetzung)

Best also include the English text so that one can see where the translator might have done something wrong (e.g. it translated “units” with “Einheiten” which by itself isn't wrong, but is wrong in this context).

And thanks for the explanation!

Bleibt es im Deutschen "unit", weil es im Pascal-Kontext verwendet wird?
(Does it stay "unit" in German, because it is used in a Pascal context?)

[PascalDragon]

Bleibt es im Deutschen "unit", weil es im Pascal-Kontext verwendet wird?
(Does it stay "unit" in German, because it is used in a Pascal context?)

Correct, yes. Also the word “Fehlerbericht” for “bugreport” while fully correct is rather unusual in the computer science context, thus “Bugreport” (or something similar) is usually used in German as well.

[theo]

Bleibt es im Deutschen "unit", weil es im Pascal-Kontext verwendet wird?

Mainly because it's a reserved word in (Turbo-, Object-) Pascal.
Translating these is not necessary and can be confusing.