Da in der aktuellen Debian (bullseye) avr-gcc die neueren AVRs nicht unterstützt werden, habe ich mir das mal hier: https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers heruntergeladen. Nun wundert mich aber, daß selbst Mikrochip hier offensichtlich keine Unterstützung anbietet. Angeblich soll das ja die gleiche Toolchain wie beim Studio 7 sein. avr-gcc --target-help liefert mir (u.a.): avr1 avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega1 avrxmega2 avrxmega3 avrxmega4 avrxmega5 avrxmega6 avrxmega7 avrtiny at90s1200 attiny11 attiny12 attiny15 attiny28 at90s2313 at90s2323 at90s2333 at90s2343 attiny22 attiny26 at90s4414 at90s4433 at90s4434 at90s8515 at90c8534 at90s8535 ata5272 attiny13 attiny13a attiny2313 attiny2313a attiny24 attiny24a attiny4313 attiny44 attiny44a attiny84 attiny84a attiny25 attiny45 attiny85 attiny261 attiny261a attiny461 attiny461a attiny861 attiny861a attiny87 attiny43u attiny48 attiny88 attiny828 at86rf401 at43usb355 at76c711 atmega103 at43usb320 attiny167 at90usb82 at90usb162 ata5505 atmega8u2 atmega16u2 atmega32u2 attiny1634 atmega8 atmega8a ata6285 ata6286 ata6289 atmega48 atmega48a atmega48pa atmega48p atmega88 atmega88a atmega88p atmega88pa atmega8515 atmega8535 atmega8hva at90pwm1 at90pwm2 at90pwm2b at90pwm3 at90pwm3b at90pwm81 at90pwm161 ata5790 ata5795 atmega16 atmega16a atmega161 atmega162 atmega163 atmega164a atmega164p atmega164pa atmega165 atmega165a atmega165p atmega165pa atmega168 atmega168a atmega168p atmega168pa atmega169 atmega169a atmega169p atmega169pa atmega32 atmega32a atmega323 atmega324a atmega324p atmega324pa atmega325 atmega325a atmega325p atmega325pa atmega3250 atmega3250a atmega3250p atmega3250pa atmega328 atmega328p atmega329 atmega329a atmega329p atmega329pa atmega3290 atmega3290a atmega3290p atmega3290pa atmega406 atmega64rfr2 atmega644rfr2 atmega64 atmega64a atmega640 atmega644 atmega644a atmega644p atmega644pa atmega645 atmega645a atmega645p atmega649 atmega649a atmega649p atmega6450 atmega6450a atmega6450p atmega6490 atmega6490a atmega6490p atmega64rfr2 atmega644rfr2 atmega16hva atmega16hva2 atmega16hvb atmega16hvbrevb atmega32hvb atmega32hvbrevb atmega64hve at90can32 at90can64 at90pwm161 at90pwm216 at90pwm316 atmega32c1 atmega64c1 atmega16m1 atmega32m1 atmega64m1 atmega16u4 atmega32u4 atmega32u6 at90usb646 at90usb647 at90scr100 at94k m3000 atmega128 atmega128a atmega1280 atmega1281 atmega1284 atmega1284p atmega128rfa1 atmega128rfr2 atmega1284rfr2 at90can128 at90usb1286 at90usb1287 atmega2560 atmega2561 atmega256rfr2 atmega2564rfr2 atxmega16a4 atxmega16a4u atxmega16c4 atxmega16d4 atxmega32a4 atxmega32a4u atxmega32c4 atxmega32d4 atxmega32e5 atxmega16e5 atxmega8e5 atxmega32x1 attiny416 attiny417 attiny816 attiny817 atxmega64a3 atxmega64a3u atxmega64a4u atxmega64b1 atxmega64b3 atxmega64c3 atxmega64d3 atxmega64d4 atxmega64a1 atxmega64a1u atxmega128a3 atxmega128a3u atxmega128b1 atxmega128b3 atxmega128c3 atxmega128d3 atxmega128d4 atxmega192a3 atxmega192a3u atxmega192c3 atxmega192d3 atxmega256a3 atxmega256a3u atxmega256a3b atxmega256a3bu atxmega256c3 atxmega256d3 atxmega384c3 atxmega384d3 atxmega128a1 atxmega128a1u atxmega128a4u attiny4 attiny5 attiny9 attiny10 attiny20 attiny40 von den neuen Tinys keine Spur. Was läuft hier falsch? >> avr-gcc --version avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.2_1759) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
pegel schrieb: > Die anderen sind zu finden unter: > > http://packs.download.atmel.com/ Das sind alles html files (.atdf). Muß ich die jetzt wirklich alle auf die normalen includes umfrickeln?
Eigentlich sind es .atpack Dateien. Ist eine zip. Versuch mal zu entpacken.
Andreas B. schrieb: > Muß ich die jetzt wirklich alle auf > die normalen includes umfrickeln? Ja. Oder du machst dir ein kleines Umfrickekl-Programm …
Habe ich ja. Da sind lauter htmls drin. Damit kann AVRstudio wohl was mit anfangen, aber es sind keinn includes. :-(
Thomas W. schrieb: > Ja. > > Oder du machst dir ein kleines Umfrickekl-Programm … Gehört Microchip jetzt zu Microsoft oder wie kann man das verstehen?
Ja, Danke! Das habe ich auch gerade entdeckt. Ich habe es in das aktuelle Download Verzeichnis einfach entpackt und zu spät gesehen, daß er da mehrere Directories angelegt hatte.
:
Bearbeitet durch User
Ah gut. Jetzt musst Du nachsehen, wo für die verschiedenen Typen die inc, libs und Sonstiges hinterlegt sind. Dann sollten die Neuen sich wie alle anderen behandeln lassen.
Die können also nicht nur nicht mehr mit Upstream zusammenarbeiten sondern schaffen es nicht mal mehr ihren eigenen Fork selber weiterzupflegen? Ich würde mir in dem Falle ernsthaft überlegen ob ich nicht allmählich Abstand von so einer unterbesetzten Bude und ihren Produkten nehmen sollte!
pegel schrieb: > Ah gut. > Jetzt musst Du nachsehen, wo für die verschiedenen Typen die inc, libs > und Sonstiges hinterlegt sind. > Dann sollten die Neuen sich wie alle anderen behandeln lassen. Jain, in die io.h sind aber nicht alle drin. Ziemlich schlampig gemacht. Bernd K. schrieb: > Die können also nicht nur nicht mehr mit Upstream zusammenarbeiten > sondern schaffen es nicht mal mehr ihren eigenen Fork selber > weiterzupflegen? Ich würde mir in dem Falle ernsthaft überlegen ob ich > nicht allmählich Abstand von so einer unterbesetzten Bude und ihren > Produkten nehmen sollte! Da kommt man wirklich ins grübeln. Schade, die neuen Tinys sind wirklich gut.
Hallo, das hat nichts mit einer Toolchain und auch nichts mit irgendwelchen Forks zu tun. Das ist alles modular aufgebaut. Von was hier die Rede ist sind die Devicepacks. Wenn neue µC dazukommen aktualisiert man das Devicepack und gut ist. Geht in Atmel Studio ganz simpel. Wenn du Linux nutzt und keine IDE die das automatisch aktuell halten kann, dann musst du das selbst einsortieren. Das ist nicht schwer. Die Ordnerstruktur sollte für jeden erkennbar sein. Also bitte nicht aufregen wenn Microchip ihre Devicepacks für jeden zum Download anbietet und nicht nur für ihre Software abkanzelt. Und ja es fehlen in io.h paar Einträge, warum immer, auch das kann man nachtragen. Das Namensschema ist immer gleich.
ZAK hat sein Windows Paket inzwischen um ein Linux Paket ergänzt: https://blog.zakkemble.net/avr-gcc-builds/ Version 9.2.0 sollte reichen, oder?
Veit D. schrieb: > Das ist alles modular aufgebaut. Warum ist dann die Hälfte schon drin und die andere Hälfte muss man manuell nachfrickeln? Das ist nicht konsequent! Und warum muss das überhaupt modular sein, es gibt außer Microchip keinen der solche Prozessoren baut und Module anbieten müsste, das könnte alles in einem Rutsch fertig eingebaut sein, genauso wie es die alten Prozessoren schon sind.
:
Bearbeitet durch User
Veit D. schrieb: > Also bitte nicht aufregen wenn Microchip ihre Devicepacks für jeden zum > Download anbietet und nicht nur für ihre Software abkanzelt. Und ja es > fehlen in io.h paar Einträge, warum immer, auch das kann man nachtragen. > Das Namensschema ist immer gleich. Das mag ja sein, ist aber trotzdem Schlamperei. Es ist ja schließlich der Hersteller und nicht irgendeine Hinterhof SW Klitsche. Faktisch sieht es also jetzt so aus: - Toolschain zusammenfrickeln - Komplett neue Registerbezeichnungen - Andere Programmierschnittstelle (nur noch UPDI) Ich muß sagen, die geben sich alle Mühe die Kunden zu ARM zu treiben.
Andreas B. schrieb: > avr-gcc --target-help liefert mir (u.a.): > avr1 avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega1 [...] Das sieht stark nach Assembler-Optionen aus, die beim genannten Kommando mit aufgelistet werden – so wie Linker-Optionen auch.
Beitrag #6150055 wurde von einem Moderator gelöscht.
Bernd: Weil du vielleicht einen alten Stand hast? Deswegen fehlen dir die aktuellen Devices in deinem Devicepack. Modular ist es weil die Toolchain nicht nur aus dem Devicepack besteht. Der Compiler zum Bsp. ist nicht von Microchip. Andreas: Wie schon gesagt, du musst gar nichts an der Toolchain zusammenfrickeln. Registernamen, UPDI. Was regst du dich auf. Die haben endlich einmal im Inneren aufgeräumt. UPDI ist ein Fortschritt und kein Rückschritt.
Veit D. schrieb: > Registernamen, UPDI. Was regst du dich auf. Die haben endlich einmal im > Inneren aufgeräumt. UPDI ist ein Fortschritt und kein Rückschritt. Wenn ich mich jetzt komplett umstellen muß, dann nenne mir einen Grund warum ich dann nicht gleich auf ARM umstelle? Ich hatte eigentlich vor, SW für verschiedene Tinys zu schreiben (gleicher Quellcode). Das gibt auch so schon genug #if define's im Quellcode. Wenn dann jetzt aber noch Registernamensänderungen dazu kommen (für die es wirklich keinen Grund gibt) dann rege ich mich auf. Johann L. schrieb: > Das sieht stark nach Assembler-Optionen aus, die beim genannten Kommando > mit aufgelistet werden – so wie Linker-Optionen auch. Na ja, die Option heißt "target-help". Aber es steht unter den Assembler Optionen. Da hast Du Recht. Da bleibst einem wohl wirklich nichts anderes als in io.h und den includes nachzuschauen.
Hallo, es gibt aktuell eine Übergangsphase von alten zu neuen. Wenn man zukünftig für verschiedene Controller programmiert wird es einfacher, auf Grund der Änderungen. Das muss man einfach verstehen. Das wird ersichtlich beim Manual lesen. Ansonsten werde ich dich nicht daran hindern AVR zu verlassen.
Veit D. schrieb: > Ansonsten werde ich dich nicht daran hindern AVR zu verlassen. Das wird Microchip vermutlich auch nicht kratzen. ;-) Ich werde wohl bei den alten Tinys bleiben und mich mal langsam in die ARMs einfinden.
:
Bearbeitet durch User
Andreas B. schrieb: > Ich hatte eigentlich vor, SW für verschiedene Tinys zu schreiben > (gleicher Quellcode). Das gibt auch so schon genug #if define's im > Quellcode. So macht man das halt auch nicht. Überall im Quellcode auf irgendwelche HW Spezifika mit #ifdef eingehen. Man schreibt so viel wie möglich komplett generisch und mit sauberen, HW-unabhängigen Schnittstellen. Alle HW-spezifischen Unterscheidungen werden so lokal wie möglich (also möglichst an einer Stelle) abgehandelt. Aber ja, wenn ich mir das Toolchain Geraffel bei AVR inzwischen anschaue, ist STM32 da weit vorne. Installiert man sich den STM32Workspace, kann man wirklich Out of the box loslegen. Auch debuggen mit ST-Link geht auf Anhieb.
Cyblord -. schrieb: > Man schreibt so viel wie möglich komplett generisch und mit sauberen, > HW-unabhängigen Schnittstellen. Bei den ganz kleinen Tinies fehlt dazu oft schlicht der nötige Speicherplatz. Dennoch würde ich auch zu dieser Vorgehensweise raten, soweit es geht.
Stefan ⛄ F. schrieb: > Cyblord -. schrieb: >> Man schreibt so viel wie möglich komplett generisch und mit sauberen, >> HW-unabhängigen Schnittstellen. > > Bei den ganz kleinen Tinies fehlt dazu oft schlicht der nötige > Speicherplatz. Dafür braucht man keinen Speicherplatz.
Cyblord -. schrieb: > So macht man das halt auch nicht. Überall im Quellcode auf irgendwelche > HW Spezifika mit #ifdef eingehen. Bei den alten Generationen war das eben nicht so viel. Alles halb so wild. > Aber ja, wenn ich mir das Toolchain Geraffel bei AVR inzwischen > anschaue, ist STM32 da weit vorne. Ja, das ist bei Microchip mittlerweile ziemlich katastrophal.
:
Bearbeitet durch User
Andreas B. schrieb: > Ja, das ist bei Microchip mittlerweile ziemlich katastophal. Kannst du es etwas konkreter gestalten? Meine Programme schreibe ich mit dem Atmel Studio 7 ohne Probleme oder gar Katastrophen.
Killian schrieb: > Andreas B. schrieb: > >> Ja, das ist bei Microchip mittlerweile ziemlich katastophal. > > Kannst du es etwas konkreter gestalten? Meine Programme schreibe ich mit > dem Atmel Studio 7 ohne Probleme oder gar Katastrophen. Thread hier gelesen? Versuche doch mal eine neueren AVR mti deinem Studio 7 zu programmieren. Ohne gefrickel wirds nicht gehen. Wer natürlich seit 20 in ASM Jahren auf mega535 entwickelt, ja klar der hat keine Probleme. > Bei den alten Generationen war das eben nicht so viel. Alles halb so > wild. Du verstehst nicht. Die herangehensweise ist schon falsch. Portablen Code schreibt man nicht, in dem man darauf vertraut dass möglichst viele Register gleich sind, sondern in dem 90% des Codes gar nicht erst direkt auf diese Register zugreift.
:
Bearbeitet durch User
Killian schrieb: > Meine Programme schreibe ich mit > dem Atmel Studio 7 ohne Probleme oder gar Katastrophen. a) habe ich keine Lust mir eine solche lahme Monster SW zu installieren. Ich arbeite lieber mit make und Editor. b) arbeite ich mit Linux. Ich habe mir mal ein Studio 6 auf eine VM (Win7)installiert, aber selbst das war schon elendig langsam. Dann müßte ich mir extra dafür eine Win10 Lizenz kaufen. Nö. Früher (TM) war das einfach: apt-get install avrdude avr-gcc avr-libc binutils-avr 1min warten und gut. Cyblord -. schrieb: > Die herangehensweise ist schon falsch. Portablen > Code schreibt man nicht, in dem man darauf vertraut dass möglichst viele > Register gleich sind, sondern in dem 90% des Codes gar nicht erst direkt > auf diese Register zugreift. Die meisten Register für irgendwelche Initialisierungen sind nun mal bei den verschiedenen uCs auch unterschiedlich. Ich rede auch von C, da programmiert man (normalerweise) nicht auf Registerebene (außer für die Initialisierungen eben)
:
Bearbeitet durch User
Hallo alle, ich suche gerade verzweifelt die Toolchain fürs AVRStudio 4 auf Windows 10pro. Rausbekommen habe ich, dass die wohl "avr-toolchain-installer-3.3.0.710-win32.win32.x86.exe" heißt. Bei Microchip kann man die downloaden - aber wenn ich dort auf Download klicke kommt nur ein neues Fenster mit gleichem Inhalt (bitte lacht mich nicht aus). Muss man sich dafür registrieren? Oder kann man die nicht "einfach so downloaden"? Wenn ja, wo? Halt so einfach, wie ich früher meine AVRtools - auch Studio7 - downloaden konnte. Danke für die Hilfe (und nix für ungut wenn ich mir grad etwas ?gaga? vorkomme nach der unergiebigen Sucherei).
Walter J. schrieb: > ich suche gerade verzweifelt die Toolchain fürs AVRStudio 4 auf Windows > 10pro. Die habe ich auch nicht ans Laufen bekommen. Aber diese drei gehen: http://stefanfrings.de/avr_tools/index.html
Andreas B. schrieb: > Die meisten Register für irgendwelche Initialisierungen sind nun mal bei > den verschiedenen uCs auch unterschiedlich. > Ich rede auch von C, da programmiert man (normalerweise) nicht auf > Registerebene (außer für die Initialisierungen eben) Ja ganz genau. Darum soll das ganze HW-Spezifische Register Zeug aber so lokal wie möglich sein. Alles darüber sollte eben davon unabhängig sein und gerade nicht von #ifdef durchsetzt.
Cyblord -. schrieb: > Ja ganz genau. Darum soll das ganze HW-Spezifische Register Zeug aber so > lokal wie möglich sein. Alles darüber sollte eben davon unabhängig sein > und gerade nicht von #ifdef durchsetzt. Schon klar. Trotzdem wird es mit den neuen Registerbezeichnungen nicht einfacher. Im Prinzip habe ich mich schon entschieden: Wenn die alten AVRs reichen, dann nehme ich die, ansonsten STM (oder LPC, die scheinen übersichtlicher zu sein).
Andreas B. schrieb: > Schon klar. Trotzdem wird es mit den neuen Registerbezeichnungen nicht > einfacher. > Im Prinzip habe ich mich schon entschieden: Wenn die alten AVRs reichen, > dann nehme ich die, ansonsten STM (oder LPC, die scheinen > übersichtlicher zu sein). Aber Achtung, bin letztens etwas reingefallen. Habe auf einem Tiny841 einen HW UART am laufen mit 9O2 (9 Bit, Odd Parity, 2 Stop Bits). Das ist leider durch die vorhandene Komponenten mit denen ich reden will vorgegeben. Die beiden HW Uarts des Tiny841 machen das ohne Probleme. Nun bin ich ganz großkotzig auf STM32F05 umgestiegen. Und merke dann recht spät, die UARTs dort können das nicht. Entweder 9 Bit ohne Parity, oder 8 Bit mit Parity. Auch die entsprechende STM32G0 Klasse mit mit immerhin 4 UARTs kann es nicht. Da scheinen die Tinys doch mal recht gut ausgerüstet zu sein und bei ST hat man das ein wenig schleifen lassen. Hätte ich so nicht vermutet.
:
Bearbeitet durch User
Andreas B. schrieb: > Danke für den Tip. Obwohl 9O2 schon sehr exotisch ist. ;-) Richtig. Aber es gibt nicht viele Features die ein Tiny hat und ein STM nicht. Vor allem nicht wenn sie im Preis vergleichbar sind.
Cyblord -. schrieb: > Aber es gibt nicht viele Features Gibt es denn noch andere Features die du kennst?
Ingo Less schrieb: > Cyblord -. schrieb: >> Aber es gibt nicht viele Features > Gibt es denn noch andere Features die du kennst? Ja
Cyblord -. schrieb: > Andreas B. schrieb: >> Danke für den Tip. Obwohl 9O2 schon sehr exotisch ist. ;-) > > Richtig. Aber es gibt nicht viele Features die ein Tiny hat und ein STM > nicht. Vor allem nicht wenn sie im Preis vergleichbar sind. Der Punkt ist: ein STM sollte überhaupt kein Feature eines ATtiny vermissen lassen. Ganz sicher jedenfalls nicht bei solchen anspruchslosen Trivialitäten wie der UART. Die hat einfach alle denkbaren Wort-Formate zu unterstützen und fertig isses. Alles andere ist Kernschrott.
Andreas B. schrieb: > a) habe ich keine Lust mir eine solche lahme Monster SW zu installieren. > Ich arbeite lieber mit make und Editor. Willkommen in der Zukunft!
Josef schrieb: > Andreas B. schrieb: >> a) habe ich keine Lust mir eine solche lahme Monster SW zu installieren. >> Ich arbeite lieber mit make und Editor. > > Willkommen in der Zukunft! Tja, dafür bin ich halt schneller fertig.
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.