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?
Veit D. schrieb: > Beide Seiten werden jedoch zeitgleich aktuell gehalten. > Was ist hier los? Die Übernahme ist doch noch keine 10 Jahre her.
Veit D. schrieb: > Was ist hier los? 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.
"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." https://developerhelp.microchip.com/xwiki/bin/view/software-tools/ides/x/projects/packs/dfp-distribution/
Georg M. schrieb: > "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." > > https://developerhelp.microchip.com/xwiki/bin/view/software-tools/ides/x/projects/packs/dfp-distribution/ 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.
Johann L. schrieb: > Ich dachte du verwendest aktuelle Tools, da sind Devicepacks doch > überflüssig. ??? Mir scheint, dass die aktuellen Tools gerade erst durch die DevicePacks auf dem aktuellen Stand gehalten werden. > Ansonsten ist darauf zu achten, dass die Packs zum Compiler passen. Vor allem auch darauf dass sie zum gewünschten Target passen (Bugfixes) bzw. dieses überhaupt erst mal enthalten. > Weil die Packs nämlich nicht 100% unabhängig von den Tool-Versionen > sind. 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.
Ob S. schrieb: > Mir scheint, dass die aktuellen Tools gerade erst durch die DevicePacks > auf dem aktuellen Stand gehalten werden. 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
Angehängte Dateien:
-
MPLAB_X_IDE__DFPs.png
62 KB
Johann L. schrieb: > 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. Das ist interessant. Die MPLAB X IDE z.B. braucht die DFPs.
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
Georg M. schrieb: > Die MPLAB X IDE z.B. braucht die DFPs. 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?
Nick schrieb: > 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.
Angehängte Dateien:
-
github_include_avr.png
120 KB
Nick schrieb: > Wer DFPs verwendet, muss auch die MCHP-Tools verwenden. 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).
Johann L. schrieb: > 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. 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?
Nick schrieb: > Veit D. schrieb: >> Was ist hier los? > > 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. 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
Georg M. schrieb: > Diese Dateien sind zusätzlich auf GitHub untergebracht Allerdings nicht als Device-Packs, sondern als Device-Support wie er bei der AVR-LibC üblich ist (Der Link war zur AVR-LibC). Veit D. schrieb: > Verwendet die avrLibc immer Headerfiles aus den aktuellen DevicePack > Versionen? Oder wird das bei "alten" µC eingefroren? 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
1 | Due to several problem reports concerning the I/O headers for |
2 | ATxmega64A1U and ATxmega128A1U (#391, #635, #643, #663, #875, #959, |
3 | #960, #961), these headers have been updated to a more recent revision. |
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.