|
Anzeige
|
Device Packs Unterschiede?Hallo, kann mir jemand sagen worin die Unterschiede zwischen Atmel Devicepacks und den Microchip Devicepacks liegen? Beide werden Seiten von Microchip betreut. http://packs.download.atmel.com/ https://packs.download.microchip.com/ Vermeintlich gleiche Versionsstände sind im Detail nicht gleich. Zumindestens laut Änderungsbeschreibungen. Beide Seiten werden jedoch zeitgleich aktuell gehalten. Was ist hier los?
Gast
#7999469
Die Übernahme ist doch noch keine 10 Jahre her.
Die übernommenen Leute von Atmel bekommen nicht genug Kaffee in der Früh. Nimm einfach das her, was in MPLAB-X angeboten/gefordert wird und gut iss. Nur geraten: vielleicht sind sie für unterschiedliche IDE gedacht. "Note: DFPs from the Microchip DFP repository cannot be used with Microchip Studio (formerly Atmel Studio)." "Note: DFPs from the Atmel DFP repository cannot be used with MPLAB X IDE."
Hallo Georg und Nemopuk, das ist der Grund, aha, vielen Dank. Hatte mich schon etwas über die vermeintliche Doppelpflege gewundert. :
Bearbeitet durch User
Ich dachte du verwendest aktuelle Tools, da sind Devicepacks doch überflüssig. Ansonsten ist darauf zu achten, dass die Packs zum Compiler passen. Weil die Packs nämlich nicht 100% unabhängig von den Tool-Versionen sind.
??? Mir scheint, dass die aktuellen Tools gerade erst durch die DevicePacks auf dem aktuellen Stand gehalten werden.
Vor allem auch darauf dass sie zum gewünschten Target passen (Bugfixes) bzw. dieses überhaupt erst mal enthalten.
Vor allem sind sie nicht unabhängig von den target devices, weswegen man sie klugerweise auch "DevicePacks" genannt hat. Klar, sie enthalten u.U. auch Anpassungen oder Erweiterungen für die Tools, der Kernpunkt sind aber doch wohl sicher die Targets. Ja, den reinen Compiler-Frickler stört natürlich die bloße Existenz verschiedener Targets bei der Verfolgung der reinen Lehre erheblich, das tut der Tatsache aber keinen Abbruch, dass sie nunmal existieren.
Wenn die Tools aktuell sind dann braucht's kein Device Packs Gefrickel, denn die Tools untestützen die Devices auch ohne Device Packs. Zumindest ist das für die GNU Tools für AVR der Fall. :
Bearbeitet durch User
Das ist interessant. Die MPLAB X IDE z.B. braucht die DFPs.
Angehängte Dateien:
Soweit ich sehe werden all diese Devices von der aktuellen AVR-LibC unterstützt. Siehe Abschnitt "Supported Devices": https://avrdudes.github.io/avr-libc/avr-libc-user-manual/index.html :
Bearbeitet durch User
Ist auch einleuchtend. Wer DFPs verwendet, muss auch die MCHP-Tools verwenden. Wer sie nicht verwenden will (warum auch immer), hat keinen Grund danach zu fragen. Oder welches Tool unterstützt sonst noch die DFPs?
Device-Packs kann man mit avr-gcc ab v5 verwenden. Davor musste der Compiler erweitert werden. Ab v5 kann man sich den Support für ein Device selber zusammenbasteln, vorausgesetzt der entsprechende Core wird unterstützt. Die Device-Packs von Atmel / Mirochip dienen vor allem dem Komfort, so dass man nicht selbst Specs-Files etc. schreiben muss falls ein Device noch nicht unterstützt wird; technisch ist es aber nix Neues.
Die in den DFPs enthaltenen Dateien sind für die Programmierung konkreter Mikrocontroller unerlässlich. Diese Dateien sind zusätzlich auf GitHub untergebracht (falls das jemanden interessiert).
Angehängte Dateien:
Hallo Johann, natürlich verwende ich aktuelle Toolchains. :-) Ich schaue dennoch immer einmal auf den Devicepacks Seiten nach. Ist a) Gewohnheit und b) Firmware Updates Neugierigkeit. Ich hätte noch eine Frage. Verwendet die avrLibc immer Headerfiles aus den aktuellen DevicePack Versionen? Oder wird das bei "alten" µC eingefroren? Ich frage, weil Microchip ja gerne an paar Namen von Bit Definitionen rumfummelt bzw. in der Vergangenheit rumgefummelt hat. Vermutlich haben sie ein einheitliches Namensschema gefunden. Denn mir fiel auf das eine TCA Lib von mir, für einen AVRxDB, nur mit geringen Änderungen für einen ATtiny414 sofort funktionierte. Keine Compilerfehler bezüglich das irgendwelche Bitnamen für den TCA unbekannt wären. Das wäre zwischen einem ATmega328P vs. ATtiny841 unmöglich in ähnlicher Form. Also meine Frage lautet ist es Zufall das die Bitnamen der Headerfiles passen oder kann es zukünftig passieren das in neueren Version nicht mehr übereinstimmt?
Ich verwende abseits der Arduino IDE wenn dann das Atmel/Microchip Studio 7. Meine Frage drehte sich nicht um die IDE. Da kann ich sowieso nur das installieren/updaten was sie mir anbietet. Dazu fällt mir noch eine Frage ein. Das Atmel/Microchip Studio verwendet doch seine eigenen Headerfiles? Die die man mittels Device Pack Manager installiert hat. Ich hatte nämlich einmal einen Fall wo ich in früheren eigenen Toolchains, wo aktuelle µC noch nicht in der avrLibC aktuell gehalten wurden, die Headerfile Version gleichziehen musste, damit ich, egal womit ich die Toolchains nutze, nichts an den Bitnamen in meinem Programm ändern musste. Das Problem trat jedoch schon länger nicht mehr auf. Vermutlich fummelt Microchip nicht mehr an den Bit Definitionen o.ä. rum. Was ich sagen wollte. Wenn man ohne IDE programmiert, gilt das Headerfile der Toolchain. Wenn man mit Arduino IDE programmiert, gilt das Headerfile vom Core Package, im Falle bei Verwendung eigener Toolchain, dann von dieser. Wenn man Microchip Studio programmiert, gilt das Headerfile der IDE, im Falle bei Verwendung eigener Toolchain, dann von dieser. Kleine feine Unterschiede. Ich hoffe ich habe nichts durcheinander gebracht. ;-) :
Bearbeitet durch User
Allerdings nicht als Device-Packs, sondern als Device-Support wie er bei der AVR-LibC üblich ist (Der Link war zur AVR-LibC).
Nein und Ja. Für "neue" Devices, also AVRrc, x-Series und AVR-xx werden die neuesten Header verwendet. Für "alte" Devices werden die Header nicht mehr angefasst, es sei denn es gibt Bugreports. War zum Beispiel bei ATxmega64A1U and ATxmega128A1U der Fall. Siehe https://github.com/avrdudes/avr-libc/blob/main/NEWS.md#changes-in-avr-libc-v230
Danke. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
