ATMega324PB: Header?

[Randy B. (rbrecker)]

Hallo zusammen,

der Betreff sagt eigentlich schon alles: hat jemand die passende 
Header-Datei mit den Bit-/Address-Defines für den ATMega324PB bzw. eine 
Quelle?

Danke!

[Toralf W. (willi)]

Morgen,

Quelle ist Microchip (beim Studio 7 ist das anbei).

[Randy B. (rbrecker)]

Besten Dank!

[Toralf W. (willi)]

Kein Problem, hab gerade mal bei Microchip reingeschaut, die aktuelle 
Toolchain (3.5.4) kennt den tatsächlich noch nicht, da ist nur die 
48-328PB Serie drin.

[MitLeserin (Gast)]

In AtmelStudio 7 an einer für mich unüblichen Stelle:

C:\Atmel7\7.0\packs\atmel\ATmega_DFP\1.0.90\include\avr\iom324pb.h

Keine Referenz in io.h.

Wird aber in einem Projekt mit Device=ATmega324pb und Native Toolchain 
korrekt eingebunden.

[Johann L. (gjlayde)]

MitLeserin schrieb:
> Keine Referenz in io.h.

Sollte dann über's specs laufen:

# AVR-LibC's avr/io.h uses the device specifying macro to determine
# the name of the device header.  For example, -mmcu=atmega8a triggers
# the definition of __AVR_ATmega8A__ and avr/io.h includes the device
# header 'iom8a.h' by means of:
#
#     ...
#     #elif defined (__AVR_ATmega8A__)
#     #  include <avr/iom8a.h>
#     #elif ...
# 
# If no device macro is defined, AVR-LibC uses __AVR_DEV_LIB_NAME__
# as fallback to determine the name of the device header as
#
#     "avr/io" + __AVR_DEV_LIB_NAME__ + ".h"
#
# If you provide your own specs file for a device not yet known to
# AVR-LibC, you can now define the hook macro __AVR_DEV_LIB_NAME__
# as needed so that
#
#     #include <avr/io.h>
#
# will include the desired device header.  For ATmega8A the supplement
# to *cpp would read
#
#     -D__AVR_DEV_LIB_NAME__=m8a


*cpp:
  -D__AVR_AT90CAN128__ -D__AVR_DEVICE_NAME__=at90can128

# End of file

[Randy B. (rbrecker)]

Die crtatmega324*.o sind ja alle identisch. Ich nehme an, dass man die 
auch einfach für den 324pb kopieren kann bzw. im specs-file einfach auf 
die 324p verweisen kann?

[Johann L. (gjlayde)]

Randy B. schrieb:
> Die crtatmega324*.o sind ja alle identisch. Ich nehme an, dass man die
> auch einfach für den 324pb kopieren kann bzw. im specs-file einfach auf
> die 324p verweisen kann?

Ja das geht, dito für die Devicelib (libxxx.a).

Man kann aber auch einfach für einen ATmega324PA compilieren und linken 
(vorausgesetzt die Devices sind hinreichend gleich).  Wenn sie sich z.B. 
nur in Betriebsspannung, Footprint etc. unterscheiden ist das den Tools 
egal.  Unterschiedliches SFR-Layout kann über Device-Header abgebildet 
werden; die Tools verwenden keine SFRs (mit Ausnahme der Devicelib die 
EEPROM-Routinen implementiert).

Der einzige relevante Unterschied zwischen den Devices ist dann deren 
Signatur, und ob man für Device A generieren aber als Device B flashen 
kann hängt ab von der Flexibilität der Build-Umgebung.

[Horst (Gast)]

Johann L. schrieb:
> (vorausgesetzt die Devices sind hinreichend gleich)

Naja, kleine Unterschiede in der Ausstattung sind schon vorhanden:
der A hat 2 UART,3 SPI,6PWM, 2x8 und 1x16Bit Timer und 16 Touch,
der B 3 UART,2 SPI,10PWM, 2x8 und 3x16Bit Timer und 32 Touch.
Aber der Rest paßt in etwa.

[Johann L. (gjlayde)]

Horst schrieb:
> Johann L. schrieb:
>> (vorausgesetzt die Devices sind hinreichend gleich)
>
> Naja, kleine Unterschiede in der Ausstattung sind schon vorhanden:
> der A hat 2 UART,3 SPI,6PWM, 2x8 und 1x16Bit Timer und 16 Touch,
> der B 3 UART,2 SPI,10PWM, 2x8 und 3x16Bit Timer und 32 Touch.
> Aber der Rest paßt in etwa.

Das sind ja keine Unterschiede, welche die Tools interessieren.  Man 
verwendet eben andere SFRs; nämlich wie im Header festgelegt.  Code für 
A bzw. B ist zwar nicht binärkompatibel, das spielt hier aber keine 
Rolle.

Unterschiede, die für die Tools (Compiler, Assembler, Linker) ne Rolle 
spielen sind z.B. SP-Handling[*], Instruktionssatz[*], Layout der 
Vector-Tabelle, RAM-Beginn. [*] ist bereits dadurch erfüllt, dass A und 
B im gleichen Multilib-Set sind.

"Nach" den Compiler-Tools spielen dann andere Dinge eine Rolle wie 
Device-Id, Zugriff aufs Device per Progger etc.  d.h. alles, was die 
Code-Generierung betrifft ist identisch bis auf die Device-Header (von 
deren Inhalt die Tools nichts "wissen").

Am bequemsten ist natürlich, ein eigenes Device für -mmcu zu haben; 
dessen Unterstützung besteht aus:

* specs-<device> File (Text, ab v5.1)

* Device-Header

* crt<device>.o (Startup-Code der AVR-LibC, ab v5.1). Zu den anderen 
Startfiles hinzugeben, oder eigenen Code verwenden und mit -nostartfiles 
linken.

* lib<device>.a (Device-Lib der AVR-LibC mit EEPROM-Funktionen, ab 
v5.1).  Entweder selbst erstellen, von einem identischen Device 
kopieren, oder keine oder eigene EEPROM-Funktionen verwenden und mit 
-nodevicelib linken.

[Randy B. (rbrecker)]

Johann L. schrieb:

>
> Am bequemsten ist natürlich, ein eigenes Device für -mmcu zu haben;

Ja, genauso habe ich das jetzt gemacht.

[Randy B. (rbrecker)]

Ups, jetzt ist Interruptvektortabelle ist bei einem 324 nur 31 Einträge 
lang, die bei einem 324PB 51 Einträge.

Was muss man wo tun, um dies noch anzupassen?

Die C-Header passen soweit, die specs  crt  device-lib hatte ich vom 
324 kopiert. Das war dann insoweit falsch, als _VECTROS_SIZE beim 324PB 
eben größer ist. Die Frage ist also, wie kann ich crtatmega324pb.o neu 
erzeugen?

Danke!

[Randy B. (rbrecker)]

Bin jetzt den kurzen Weg gegangen, und habe mir alles einfach aus den 
Atmel-Packs geholt. Nur ist die Vektortabelle passend.