Neue MCU und Pin Mapping

International Deutsch
1

Hallo Leute,

ich würde gerne einen Atmel nutzen, der in der IDE noch nicht integriert ist.
Ich weiß, dass man in der boards.txt das board mit seiner MCU ablegen muss, allerdings ist es damit ja noch lange nicht getan. So weiß die IDE nur, das es ein Board mit einem bestimmen namen gibt, kennt dessen Pins und Interrupts aber noch nicht oder?

Wobei ich Probleme habe:

  1. Muss das "upload.protocol" irgendwo hinterlegt werden oder ist es nur ein frei wählbarer Name?
  2. Woher bekomme ich das "bootloader.file" oder kann ich einfach eine "bootloader.hex" aus der gleichen Familie nehmen (Bsp.: Atmega328 für Atmega 328p).
  3. Was steht in dem build.core (also im core-Ordner), woher bekommt man es oder was muss man anpassen, damit es passt?
  4. Wie funktioniert das pin mapping?
    Ich weiß, dass ich im Odner "variants" eine pins_arduino.h anlegen kann (wobei ich auch in core diese Datei gefunden habe), aber wie genau ist die aufgebaut?
    Ich habe mir schon verschiedene pins_arduino.h angeschaut, komme aber nicht dahinter, nach welcher Reihenfolge die Pins durchnummeriert sind etc.

Ich hoffe ihr wisst mehr...

Lieben Dank!

2

Konkret: welchen µController willst Du verwenden?
Grüße Uwe

3

Schon mal bei AVR/Atmel Studio nachgeschaut, ob das Deinen Controller überhaupt schon kennt?

4

@DrDiettrich:
Nein das hatte ich noch nicht. Damit habe ich noch nie gearbeitet und wollte eigntlich mit der Arduino IDE arbeiten.
Bin aber gerade mal, aufgrund deiner Nachfrage, das AVR-Studio 7.0 am runtergeladen (schlappe 735MB ... das dauert noch n Weilchen).

@Uwe: Es geht konkret um den ATmega169PA.
Es hat sich schonmal jemand die Arbeit gemacht und für das Butterfly Board auf dem ein Atmega169 (ohne PA) sitzt alle Dateien für die Arduino IDE angepasst/erstellt.

Davon ausgehend würde ich dann gerne die Dateien entsprechend anpassen, bloß weiß noch nicht wie.
Generell wäre das sicherlich aber dennoch interessant zu wissen, wie man das von Grund aus selbst macht.

Die unterschiede die ich durch die Datenblätter finden konnte beziehen sich hauptsächlich auf ein paar Bits bei:
EIMSK, EIFR, MCUCR, LCDCRA, LCDCCR.

5

@DrDiettrich: Ja der Atmega169PA ist im Atmel Studio (7.0) bekannt. Bringt dich das bei der Hilfe weiter?

6

Leon333:
@DrDiettrich: Ja der Atmega169PA ist im Atmel Studio (7.0) bekannt. Bringt dich das bei der Hilfe weiter?

Höchstens so weit, daß man vielleicht von dort was abkupfern kann.

7

Ich wüsste leider nur nicht was und wo.
Ist es nicht einfacher, vom Atmega169 ausgehend, der ja bereits in die Arduino IDE eingefügt wurde, den Atmega169PA anzupassen?
Da sind ja eigentlich nur ein paar Bits (und Interrupts?) verschieden.

8

Solange sich die Prozessoren 169/PA nur noch in ein paar internen Registern bzw. Bits unterscheiden, dann die entsprechenden Symbole einfügen (Adresse und Bitmaske) bzw. löschen. Die Spezialbits werden ja vermutlich im Code direkt angesprochen, ohne Hilfsfunktionen (wie digitalWrite) zu benutzen. Ansonsten wären solche Funktionen in einer zusätzlichen Bibliothek gut aufgehoben (LCD169, LCD169PA). Da drin könnte dann getestet werden, ob die Bibliothek zum aktuellen Controller paßt, bzw. was eine gemeinsame Bibliothek je nach Controller unterschiedlich machen muß. Oder diese Bibliotheken werden einfach in den Controller-spezifischen Verzeichnissen abgelegt (...avr\variants...)?

Falls es Lock-Bits sind, damit kenne ich mich nicht aus, wie die vom Compiler etc. benutzt werden.

9

Ich verstehe leider von der Materie zu wenig um das einfach so anpassen zu können.
Schon allein beim festlegen (Nummerierung) des pinouts in der pins_arduino.h blicke ich nicht durch.

Dennoch scheinen mir die Unterschiede nicht sehr groß zu sein.
Ich habe mal ein Bild (siehe Anhang) zusammengeschnitten und alle Unterschiede im ATmega169PA rot markiert.

Die Informationen habe ich vom Datenblatt, allerdings gibt es zwischen der "DATASHEET SUMMARY" und der "Preliminary" zum Teil deutliche Unterschiede. Daher sind alle Informationen aus dem "echten" Datenblatt und am Ende habe ich einen Unterschied zwischen dem echten Datenblatt und der Preliminary Version mit rein gemacht.

Quellen:
Datenblatt ATmega169
Datenblatt ATmega169PA
Preliminary Datenblatt ATmega169PA

Vielleicht hilft es ja jemanden dabei mir zu helfen...

Liebe Grüße!

Unterschiede_final.png
Unterschiede_final.png1358×1453 133 KB

10

Bei den Unterschieden zwischen Preliminary und Final kann Dir niemand helfen, der den Chip nicht selbst hat, da mußt Du ggf. selbst rumprobieren. Ich würde aber der Final vertrauen.

Für die zusätzlichen Ports (J, H) und Segemente reicht IMO die Angabe der Adressen, da ja keine bitweisen Zugriffe (digitalWrite) implementiert werden sollen.

Vereinfacht: was glaubst Du von den Änderungen in Deinen Programmen verwenden zu wollen, und wie? Was Du nicht brauchst, mußt Du nicht hinzufügen.

11

DrDiettrich:
Für die zusätzlichen Ports (J, H) und Segemente reicht IMO die Angabe der Adressen, da ja keine bitweisen Zugriffe (digitalWrite) implementiert werden sollen.

Das verstehe ich nicht so ganz.
Heißt das, dass wenn ich digitalWrite nicht an entsprechenden Pins benutze, dass ich dann nichts weiter zu definieren brauche?

Bisher habe ich noch gar nichts gemacht (also auch nicht den Bootloader vom ATmega169 geflasht oder irgendetwas versucht), weil ich Angst habe, dass wenn es nicht komplett angepasst ist, dass ich mir dann den Controller zerschieße.

Ich verstehe den Zusammenhang des Registers (Adresse und Bit) zwischen den Pinouts bzw. den Funktionen nicht.
Ich weiß also nicht mal zu welchen Pins der Port J und H gehört oder was mir die Registertabelle wirklich sagen soll.

Kurzfristig würde es mir schon sehr helfen, wenn folgendes funktionieren würde:
Analoge Werte einlesen von PF0(ADC0), PF1(ADC1), PF2(ADC2) und PF3(ADC3).
Digital schreiben auf PE2(XCK0/AIN0/PCINT2), PE6(DO/PCINT6) und PE7(CLKO/PCINT7).
Digital lesen auf PE3(AIN1/PCINT3).
Flashen über PB1(SCK/PCINT9) PB2(MOSI/PCINT10) und PB2(MISO/PCINT11).
Eventuell auch ansprechen von PE0(RXD/PCINT0) und PE1(TXD/PCINT1) um darüber Serielle ausgaben zu machen zum debuggen.

Langfristig wäre es natürlich gut, wenn PA0-7, PB0-7, PC0-7, PD0-7, PE0-7, PF0-7 und PG0-4 komplett funktionieren würden, aber das ist momentan noch nicht soo wichtig.

12

Also wenn man sich mal das Mega Pin Mapping ansieht wird klar dass die Reihenfolge einfach die Pin-Nummerierung auf dem Arduino Board ist

Fängt mit 0 an und geht bis 53. Dann kommen die Analog-Pins dahinter

const uint8_t PROGMEM digital_pin_to_port_PGM[] = {
 // PORTLIST 
 // ------------------------------------------- 
 PE , // PE 0 ** 0 ** USART0_RX 
 PE , // PE 1 ** 1 ** USART0_TX 
 PE , // PE 4 ** 2 ** PWM2 
 PE , // PE 5 ** 3 ** PWM3 
 PG , // PG 5 ** 4 ** PWM4 
 PE , // PE 3 ** 5 ** PWM5 
 PH , // PH 3 ** 6 ** PWM6 
 PH , // PH 4 ** 7 ** PWM7 
 PH , // PH 5 ** 8 ** PWM8 
 PH , // PH 6 ** 9 ** PWM9 
 PB , // PB 4 ** 10 ** PWM10 
 PB , // PB 5 ** 11 ** PWM11 
 PB , // PB 6 ** 12 ** PWM12 
 PB , // PB 7 ** 13 ** PWM13 
 PJ , // PJ 1 ** 14 ** USART3_TX 
 PJ , // PJ 0 ** 15 ** USART3_RX 
 PH , // PH 1 ** 16 ** USART2_TX 
 PH , // PH 0 ** 17 ** USART2_RX 
 PD , // PD 3 ** 18 ** USART1_TX 
 PD , // PD 2 ** 19 ** USART1_RX 
 PD , // PD 1 ** 20 ** I2C_SDA 
 PD , // PD 0 ** 21 ** I2C_SCL 
 PA , // PA 0 ** 22 ** D22 
 PA , // PA 1 ** 23 ** D23 
 PA , // PA 2 ** 24 ** D24 
 PA , // PA 3 ** 25 ** D25 
 PA , // PA 4 ** 26 ** D26 
 PA , // PA 5 ** 27 ** D27 
 PA , // PA 6 ** 28 ** D28 
 PA , // PA 7 ** 29 ** D29 
 PC , // PC 7 ** 30 ** D30 
 PC , // PC 6 ** 31 ** D31 
 PC , // PC 5 ** 32 ** D32 
 PC , // PC 4 ** 33 ** D33 
 PC , // PC 3 ** 34 ** D34 
 PC , // PC 2 ** 35 ** D35 
 PC , // PC 1 ** 36 ** D36 
 PC , // PC 0 ** 37 ** D37 
 PD , // PD 7 ** 38 ** D38 
 PG , // PG 2 ** 39 ** D39 
 PG , // PG 1 ** 40 ** D40 
 PG , // PG 0 ** 41 ** D41 
 PL , // PL 7 ** 42 ** D42 
 PL , // PL 6 ** 43 ** D43 
 PL , // PL 5 ** 44 ** D44 
 PL , // PL 4 ** 45 ** D45 
 PL , // PL 3 ** 46 ** D46 
 PL , // PL 2 ** 47 ** D47 
 PL , // PL 1 ** 48 ** D48 
 PL , // PL 0 ** 49 ** D49 
 PB , // PB 3 ** 50 ** SPI_MISO 
 PB , // PB 2 ** 51 ** SPI_MOSI 
 PB , // PB 1 ** 52 ** SPI_SCK 
 PB , // PB 0 ** 53 ** SPI_SS 
 PF , // PF 0 ** 54 ** A0 
 PF , // PF 1 ** 55 ** A1 
 PF , // PF 2 ** 56 ** A2 
 PF , // PF 3 ** 57 ** A3 
 PF , // PF 4 ** 58 ** A4 
 PF , // PF 5 ** 59 ** A5 
 PF , // PF 6 ** 60 ** A6 
 PF , // PF 7 ** 61 ** A7 
 PK , // PK 0 ** 62 ** A8 
 PK , // PK 1 ** 63 ** A9 
 PK , // PK 2 ** 64 ** A10 
 PK , // PK 3 ** 65 ** A11 
 PK , // PK 4 ** 66 ** A12 
 PK , // PK 5 ** 67 ** A13 
 PK , // PK 6 ** 68 ** A14 
 PK , // PK 7 ** 69 ** A15 
};

Bei digital_pin_to_bit_mask_PGM[] ist es genauso, nur werden hier die Bit-Nummern eingetragen

PROGMEM digital_pin_to_timer_PGM[] hat die gleiche Reihenfolge, aber gibt es ob ein Pin einem Timer zugeordnet ist

13

Also beim Butterfly gibt es z.B. gar keinen "variants" Ordner und es wird nur auf "cores" und "bootloaders" verwiesen.
Dort in der pins_arduino.h steht nur das hier:

#ifndef Pins_Arduino_h
#define Pins_Arduino_h

#include <avr/pgmspace.h>

#define NOT_A_PIN 0
#define NOT_A_PORT 0

#define NOT_ON_TIMER 0
#define TIMER0A 1
#define TIMER0B 2
#define TIMER1A 3
#define TIMER1B 4
#define TIMER2  5
#define TIMER2A 6
#define TIMER2B 7

extern const uint8_t PROGMEM port_to_mode_PGM[];
extern const uint8_t PROGMEM port_to_input_PGM[];
extern const uint8_t PROGMEM port_to_output_PGM[];

extern const uint8_t PROGMEM digital_pin_to_port_PGM[];
extern const uint8_t PROGMEM digital_pin_to_bit_PGM[];
extern const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[];

extern const uint8_t PROGMEM digital_pin_to_timer_PGM[];

// Get the bit location within the hardware port of the given virtual pin.
// This comes from the pins_*.c file for the active board configuration.
// 
// These perform slightly better as macros compared to inline functions
//
#define digitalPinToPort(P) ( pgm_read_byte( digital_pin_to_port_PGM + (P) ) )
#define digitalPinToBitMask(P) ( pgm_read_byte( digital_pin_to_bit_mask_PGM + (P) ) )
#define digitalPinToTimer(P) ( pgm_read_byte( digital_pin_to_timer_PGM + (P) ) )
#define analogInPinToBit(P) (P)
#define portOutputRegister(P) ( (volatile uint8_t *)( pgm_read_byte( port_to_output_PGM + (P))) )
#define portInputRegister(P) ( (volatile uint8_t *)( pgm_read_byte( port_to_input_PGM + (P))) )
#define portModeRegister(P) ( (volatile uint8_t *)( pgm_read_byte( port_to_mode_PGM + (P))) )

#endif

Es werden also nicht wie bei dir gezeigt die pins ähnlich zum 2560 definiert...

Allerdings ist in der boards.txt auch noch auf die bf_boot.hex (im Ordner bootloaders) verwiesen und was da drinne steht (und wo die her kommt) weiß ich nicht.

Die Implementation des Butterfly-Boards (ATmega169) kommt von Nick Lott und kann hier runtergeladen werden.
Das ist aber komplett anders als z.B. beim Mega aufgebaut.

Ich hab das eben noch nie gemacht und verstehe noch nicht, was man alles tun muss, damit es funktioniert (ne .hex erstellen kann ich nicht).
Wenn es "nur" das anpassen der "boards.txt" und das erstellen der "pins_arduino.h" ist, dann mach ich mich mal dran und hoffe ich verstehe einigermaßen was ich da tue...

14

extern bedeutet dass die Variable bekannt gemacht werden soll, aber wo anders definiert wird. Diese Arrays sind die eigentlichen Pin Definitionen. Eine davon habe ich oben kopiert. Das muss also noch irgendwo anders was stehen.

Ich war von den Standard Arduino Boards der IDE ausgingen. Da steht das direkt drin,

15

Ok dann werde ich nochmal suchen müssen...

Zur Pinbelegung des Megas - da steht z.B. das hier:

const uint8_t PROGMEM digital_pin_to_port_PGM[] = {
	// PORTLIST		
	// -------------------------------------------		
	PE	, // PE 0 ** 0 ** USART0_RX	
	PE	, // PE 1 ** 1 ** USART0_TX	
	PE	, // PE 4 ** 2 ** PWM2	
	PE	, // PE 5 ** 3 ** PWM3	
	PG	, // PG 5 ** 4 ** PWM4	
	PE	, // PE 3 ** 5 ** PWM5	
	PH	, // PH 3 ** 6 ** PWM6	
	PH	, // PH 4 ** 7 ** PWM7

Warum wird hier PE0, PE1, PE4 und dann PE5 zugewiesen?
Woher weiß man das?
Ich hätte nämlich jetzt gedacht, dass man hier PE0, PE1, PE2 und dann PE3 zuweist.
Woher man sehen kann, welcher Port PWM-fähig ist und welche Nummer der dann auch noch hat weiß ich auch nicht.
Das Datenblatt sagt zwar "Six/Twelve PWM Channels with Programmable Resolution from 2 to 16 Bits" aber ich sehe nicht wie ich da dann darauf komme wo diese liegen.

16

Schau dir an was hintendran steht. Das wurde so gemacht damit Serial auf 0 und 1 liegt und danach alle PWM Pins (d.h. Pins die einem Timer zugeordnet sind). Dann die anderen seriellen Schnittstellen. Dann I2C. Dann die restlichen Digital Pins.

Das kannst du auch anders machen wenn du ein anderes System bevorzugst.

Timer-Pins erkennt man ganz einfach an Zusatzfunktionen wie OC0A oder OC2B. Steht für "Output Compare, Timer 0, Kanal A" bzw. "Output Compare, Timer 2, Kanal B"

PCINTx sind Pinchange Interrupt Pins

INTx sind externe Interrupts

17

Warum sind beim mega in digital_pin_to_port_PGM[] die analogen Pins mit angegeben und warum fehlen dort z.B. PD4-6 und PE7?

Soll ich #define LED_BUILTIN 13 komplett raus hauen/auskommentieren?

Warum beginnt "PROGMEM port_to_mode_PGM[]", "port_to_output_PGM[]" und "PROGMEM port_to_input_PGM[]" mit "NOT_A_PORT" ?
Kommt da üblicherweise etwas vor dem Port A ?

In das #define digitalPinToInterrupt(p) sollen warscheinlich alle Pins mit "INTx" rein (ich hab da nur einen), aber warum fehlt beim Mega dann der PE7 (INT7)?
Außerdem weiß ich nicht nach welchem Schema da die Zahl vergeben wird, denn

(p) == 2 ? 0

Bedeutet, dass PE4 (OC3B/INT4) die Null zugewiesen wird...?
Kann man die INTx frei irgendwelchen Interrupt-Zahlen von 0 beginnend zuweisen?

Außerdem verstehe ich nicht, warum man hier:

#define digitalPinToPCICRbit(p) ( (((p) >= 10) && ((p) <= 13)) || (((p) >= 50) && ((p) <= 53)) ? 0 : \
                                ( (((p) >= 62) && ((p) <= 69)) ? 2 : \
                                0 ) )

extra die pins 10<= p <=13 und 50 <= p <= 53 (das ist PB0-7) für "0" zuweist um dann am Ende ALLE auch "0" zuzuweisen.
Entweder ist die erste Bedingung unnötig (weil am Ende eh "0" zugewiesen wird) oder am Ende ist fälschlicherweise auf "0" zugewiesen und es hätte dann "-1" oder "NULL" sein müssen...

Ansonsten ( :smiley: ) hab ich soweit alles in der pins_arduino.h angepasst...

18

Leon333:
Warum sind beim mega in digital_pin_to_port_PGM[] die analogen Pins mit angegeben und warum fehlen dort z.B. PD4-6 und PE7?

Die gelisteten analogen Eingänge können auch als digitale Pins verwendet werden.

Soll ich #define LED_BUILTIN 13 komplett raus hauen/auskommentieren?

Im Prinzip ja, wenn auf dem Board keine LED drauf ist. Dann könnte aber der Bootloader oder sonstiger Code durcheinanderkommen, wenn das #define LED_BUILTIN ganz fehlt. Deshalb besser die 13 durch 0 (oder garnichts) ersetzen um anzuzeigen, daß das Board keine LED eingebaut hat. Sonst eben den Pin, an den diese eingebaute LED angeschlossen ist.

Warum beginnt "PROGMEM port_to_mode_PGM[]", "port_to_output_PGM[]" und "PROGMEM port_to_input_PGM[]" mit "NOT_A_PORT" ?
Kommt da üblicherweise etwas vor dem Port A ?

Möglicherweise dient der erste Eintrag zum Ausblenden ungültiger Parameter (index 0), wenn in den anderen Tabellen Nullen drinstehen.

In das #define digitalPinToInterrupt(p) sollen warscheinlich alle Pins mit "INTx" rein (ich hab da nur einen), aber warum fehlt beim Mega dann der PE7 (INT7)?

Der Pin PE7 wird höchstwahrscheinlich als CLKO konfiguriert, da soll der Benutzer nicht daran rumspielen können.

Außerdem weiß ich nicht nach welchem Schema da die Zahl vergeben wird, denn

(p) == 2 ? 0

Bedeutet, dass PE4 (OC3B/INT4) die Null zugewiesen wird...?

Wie kommst Du auf PE4? PB2/PCINT2 wird für MOSI benutzt, darf keinen Inerrupt auslösen.

Außerdem verstehe ich nicht, warum man hier:

#define digitalPinToPCICRbit(p) ( (((p) >= 10) && ((p) <= 13)) || (((p) >= 50) && ((p) <= 53)) ? 0 : \

( (((p) >= 62) && ((p) <= 69)) ? 2 :
                               0 ) )



extra die pins 10<= p <=13 und 50 <= p <= 53 (das ist PB0-7) für "0" zuweist um dann am Ende ALLE auch "0" zuzuweisen.
Entweder ist die erste Bedingung unnötig (weil am Ende eh "0" zugewiesen wird) oder am Ende ist fälschlicherweise auf "0" zugewiesen und es hätte dann "-1" oder "NULL" sein müssen...

Das hast Du richtig erkannt. Anscheinend wurde die Bedingung vom nachfolgenden digitalPinToPCMSK kopiert und angepaßt, da stehen nämlich andere Werte statt den beiden Nullen drin. Entweder wurde dabei übersehen, daß der erste Teil weggelassen werden könnte, oder die Bedingungen wurden absichtlich nicht geändert, um die Wartung des Codes zu vereinfachen. Die Zusammenhänge wären allerdings klarer, wenn man die Zeilen wie bei digitalPinToPCICR formatiert hätte.
Du kannst das ändern, dann laufen ein paar Funktionen ein paar Ticks schneller.

Glückwunsch, jetzt bist Du ja schon ein Experte für die Arduino Konfigurationsdateien geworden :slight_smile:

19

Danke für die netten Worte, aber eigentlich bin ich gar nichts geworden :smiley:

Ich bekomme hier dank euch einfach nur großartige Hilfe und geb mein bestes, meinen Teil dazu beizutragen...

Ein vorläufiges Pinout-Bild habe ich im Anhang, genauso wie meine momentante pins_arduino.h (vielleicht hilft es ja mal jemanden hier).

Ich habe noch 11 Fragen und werde wenn die geklärt sind mit eurem "OK" mal das Flashen über SS,SCK, MISO und MOSI wagen.

Ich weiß nicht ob die analogen Eingänge vom ATmega169PA ebenfalls als digitale Pins verwendet werden können und habe mich an den atmega2560 gehalten und meine ebenfalls als digitale Pins angegeben.
1. Kann ich die analogen Pins bei den ditigalen stehen lassen?

Die LED_BUILTIN habe ich jetzt auf 13 gelassen. 0 ist ja RX und da will ich nicht, dass es da irgendwelche Probleme gibt.

Bei mir habe ich jetzt den PE7 (CLKO) als D7 definiert und der wird auch in der Schaltung benutzt um einen MOSFET zu schalten.
2. Soll ich jetzt alles ändern, damit PE7 nicht angesprochen werden kann?

Wie ich auf PE4 komme?
Die Abfrage war ja

(p) == 2 ? 0

und weiter unten steht

const uint8_t PROGMEM digital_pin_to_port_PGM[] = {
 // PORTLIST 
 // ------------------------------------------- 
 PE , // PE 0 ** 0 ** USART0_RX 
 PE , // PE 1 ** 1 ** USART0_TX 
 PE , // PE 4 ** 2 ** PWM2

Da ist p=2 dem PE4 zugeordnet.

Also meiner Meinung nach sollte es PE4 und nicht PB2 sein.

3. was ist XTAL1 (TOSC1) und XTAL2 (TOSC2)?
4. Ist es sinnvoll GP5 als DigitalPin zu definieren, da er ja auch gleichzeitig Reset Pin ist?

Die boards.txt von Nick Lott sieht so aus:

bfly.name=Butterfly

bfly.upload.protocol=butterfly
bfly.upload.maximum_size=14336
bfly.upload.speed=19200

bfly.bootloader.low_fuses=0xE2
bfly.bootloader.high_fuses=0x98
bfly.bootloader.extended_fuses=0xFF
bfly.bootloader.path=butterfly
bfly.bootloader.file=bf_boot.hex
bfly.bootloader.unlock_bits=0x3F
bfly.bootloader.lock_bits=0x0F

bfly.build.mcu=atmega169
bfly.build.f_cpu=8000000L
bfly.build.core=butterfly

ich habe die jetzt einfach so umgeändert:

ATmega169PA.name=ATmega169PA // einfach nur umbenannt, keine sonstigen veränderungen an Dateien

ATmega169PA.upload.protocol=ATmega169PA // einfach nur umbenannt, keine sonstigen veränderungen an Dateien
ATmega169PA.upload.maximum_size=14336 //woher stammt die upload.maximum_size=14336? (Der ATmega169PA hat 16Kbyte 512Bytes 1Kbyte)
ATmega169PA.upload.speed=19200

ATmega169PA.bootloader.low_fuses=0xE2
ATmega169PA.bootloader.high_fuses=0x98
ATmega169PA.bootloader.extended_fuses=0xFF
ATmega169PA.bootloader.path=ATmega169PA // umbenannt und Dateipfad erstellt)
ATmega169PA.bootloader.file=ATmega169PA_boot.hex // bf_boot.hex in ATmega169PA_boot.hex umbenannt und in den Ordner "ATmega169PA" verschoben
ATmega169PA.bootloader.unlock_bits=0x3F
ATmega169PA.bootloader.lock_bits=0x0F

ATmega169PA.build.mcu=ATmega169PA // von atmega169 in ATmega169PA umbenannt , keine sonstigen veränderungen an Dateien
ATmega169PA.build.f_cpu=16000000 // von 8000000L auf 16000000
ATmega169PA.build.variant=ATmega169PA // "build.core=butterfly" komplett gegen "build.variant=ATmega169PA" ersetzt, da ich das "core" zeug nicht verstehe und die pins_arduino.h erstellt habe

===========================

5. Darf und kann ich es so machen oder wird es so Probleme geben?

Besonders die Punkte:
6. Ist "core" durch "variants" ersetzen erlaubt und brache ich den core Ordner überhaupt? (oder wie soll ich es machen?)
7. Sind die Fuse-Werte weiterhin korrekt durch das Ändern der Werte wie z.B. CPU-Takt? (Falls nein, wie müssen die aussehen?
8. Bezeichnung des "mcu" frei wählbar?
9. "protocol"-Name frei wählbar?

In der programmers.txt hab ich folgenden Eintrag ergänztz:

Atmega169PA.name=Atmega169PA
Atmega169PA.communication=serial
Atmega169PA.protocol=Atmega169PA

Auf Arduino Playground - CustomizeArduinoIDE steht "build.f_cpu - the CPU frequency (in HZ)".
10. Warum ist dann dennoch häufig ein "L" hinter der Zahl angegeben?

Irgendwie wäre ein Tutorial hierfür nicht schlecht :smiley:
Ich habe ganz offenslichtlich einige Fragen und weiß einfach nicht wie das alles zusammenhängt und ob das was ich gemacht habe ausreicht oder z.T. unnötig war, damit die Arduino IDE seinen bootloader und Co. auf den µC packen kann.

11. Wenn ich alles angepasst habe (und es auch stimmt), kann ich dann denn "bootloader" drauf brennen und ab dann zukünftig ganz "normal" über meinen USB<=>Serial Adaper andere Sketches über SS, SCK, MISO und MOSI drauf laden ohne den bootloader flashen/brennen zu müssen?

Ich danke euch, Serenyfly und DrDiettrich, wirklich tausendfach!

pins_arduino.h (8.94 KB)

ATmega169PA_Pinout.jpg
ATmega169PA_Pinout.jpg1059×1036 169 KB

20

Leon333:
und warum fehlen dort z.B. PD4-6 und PE7?

Nicht alle Pins sind herausgeführt. Auf dem Mega fällt da besonders auf dass der zweite Komparator-Eingang fehlt, oder fast alle der externen Timer Takt-Pins:

http://www.pighixxx.com/test/wp-content/uploads/2014/11/atmega2560.png

Der Prozessor halt einfach mehr Pins als das Arduino Board und man hat Dinge weggelassen die man nicht für nötig gehalten hat.