|
Anzeige
|
minGW und AVR
Gast
#5076732
Ich programmiere meine avrs mit winAVR und nuerer toolchain. Studio ist mir zu langsam und zu nervig. Zwecks debugging habe ich jetzt mal MinGW ausprobiert: schnell und macht im Prinzip alles, was ich erwarte. Wäre jetz natürlich schön, wenn man mit MinGW hexfiles generieren und mittels avrdude in die mcus bekommen könnte. Gibts dafür eine einfache Anleitung? Habe dies gefunden: Beitrag "AVR Tool Chain mit MinGW". Ist aber schon etwas älter. Und was genau ist das Problem? Was wäre denn deiner Meinung nach der Vorteil von MinGW gegenüber deiner "neueren" Windows-toolchain? Oliver
Gast
#5076759
Oliver S. schrieb: > der Vorteil Man kann Debuggen, d.h. Teile des Programms ohne mcu ablaufen lassen und schauen wie sich z.B. Variablen verändern. grundschüler schrieb: > Wäre jetz natürlich schön, wenn man > mit MinGW hexfiles generieren und mittels avrdude in die mcus bekommen > könnte. MinGW ist GCC & Co auf Windows für Windows. Damit kannst du keinen AVR-Code generieren. Dafür gibt es ja den AVR-GCC. Du kannst MinGW verwenden, um Programmteile auf dem PC vorzutesten. Ist der Test erfolgreich, übersetzt du das Programm mit dem AVR-GCC und lädst es auf den AVR. Es gibt m.W. keine GCC-Variante, die beides kann. So ist es. Echten AVR-Code debuggem geht halt (fast) nur mit dem Studio, das du aber nicht nutzen willst. Oliver Algorithmen kann man durchaus auch auf sehr gut auf einem PC testen.
Gast
#5077009
GCC kann zwar Code für sehr viele verschiedene Architekturen erzeugen - allerdings muß man GCC konfigurieren, wenn man ihn compiliert. Man kann also nicht zur GCC-Laufzeit auswählen, für was er Code erzeugen soll. MingW ist so gebaut, daß es x86-Code rauswirft. Clang hingegen kann das, mit einem Clang-Binary per Kommandoswitch für verschiedene Architekturen Code erzeugen. Neu übersetzen muss man aber immer noch.
Gast
#5077230
Johann L. schrieb: > Algorithmen kann man durchaus auch auf sehr gut auf einem PC testen. Das setzt voraus, dass sich der Entwickler gedanken ueber die Datentypen und die vielleicht vorhandene diskrepantz der Wertebereiche auf den unterschiedlichen Platformen gemacht hat... Ich schreibe meine Programmteile auch separat und baue/teste diese vorher auf dem PC mit dem "normalen" gcc. Dafür benötigst du ja aber eh eine "Testumgebung", welche dir die Schnittstellen zur MCU s(t)imuliert. Wenn es also schon zwei unterschiedliche Programme werden, warum dann nicht zwei unterschiedliche Makefiles verwenden??? Eines für die MinGW Toolchain und ein zweites für die AVR-GCC Toolchain. Das macht die ganze Sache doch auch gleich viel übersichtlicher... Kaj schrieb: > Johann L. schrieb: >> Algorithmen kann man durchaus auch auf sehr gut auf einem PC testen. > Das setzt voraus, dass sich der Entwickler gedanken ueber die Datentypen > und die vielleicht vorhandene diskrepantz der Wertebereiche auf den > unterschiedlichen Platformen gemacht hat... Wenn ein Entwickler sich keine Gedanken um Datentypen gemacht hat, dann ist das schon mal schlecht. Diskrepanz der Datentypen lässt sich gut mit [u]int*_t Typen begegnen. Allerdings hat man immer noch unterschiedliche Größe für int, und dies wird für Typ-Promotion verwendet. Während es also auf einem AVR möglich ist, 16-Bit Integer zu vergleichen, ist dies auf einem PC nicht möglich, den jeglicher Vergleich wird vorher mindestens zu (unsigned) int promoten.
Gast
#5077281
grundschüler schrieb: > Studio ist mir zu langsam und zu nervig. Da musst du dich schon deutlicher ausdrücken. Meinst du Atmel Studio, AVR Studio oder welches sonst?
Gast
#5077399
Johann L. schrieb: > Kaj schrieb: >> Johann L. schrieb: >>> Algorithmen kann man durchaus auch auf sehr gut auf einem PC testen. >> Das setzt voraus, dass sich der Entwickler gedanken ueber die Datentypen >> und die vielleicht vorhandene diskrepantz der Wertebereiche auf den >> unterschiedlichen Platformen gemacht hat... > > Wenn ein Entwickler sich keine Gedanken um Datentypen gemacht hat, > dann ist das schon mal schlecht. Ja, das ist richtig, ist aber (m.M.n.) eins der groessten Probleme die wir haben, siehe nur mal die Referenzimplementierung von MD5, um nur ein Beispiel zu nennen. https://de.wikipedia.org/wiki/Message-Digest_Algorithm_5#Referenzimplementation
Gast
#5077732
danke für die Beiträge. Beitrag "AVR Tool Chain mit MinGW" habe ich dann wohl falsch verstanden. probiert hatte ich atmel studio 6. Damit habe ich mir meine XP-Installation versaut. Es kamen dann ständig vb-Fehlermeldungen. Alternative zu PC-debugging mit studio wäre dann noch codeblocks? grundschüler schrieb: > Beitrag "AVR Tool Chain mit MinGW" habe ich > dann wohl falsch verstanden. Dort ging es darum, sich eine AVR-Toolchain zu generieren, die unter WIndows läuft. Also z.B. --host=i386-mingw32 und nicht --host=x86-pc-linux-gnu. Prinzipiell hat man dazu 2 Möglichkeiten: Die Tools nativ unter Windows generieren mit entsprechender Umgebung wie cygwin nd --build = --host. Oder einen Canadie Cross Build wie z.B. --build=x86_64-linux-gnu -- host=i386-mingw32 --target=avr von einer Linux-Maschine aus. > Alternative zu PC-debugging mit studio wäre dann noch codeblocks? Code::Blocks for Windos bringt i.d.R. einen mingw Compiler mit, der auch separat, also ohne C::B genutzt werden kann. Wie ich sehe, liegt der Comiler da in ./MinGW/bin/gcc und dito für andere Tools wie g++ und objcopy etc. Da gäbe es ja auch noch Eclipse CDT mit Debugging über GDB. Das sollte ja auch keine große Sache sein, die Toolchain da zum Laufen zu bekommen. Antwort schreiben |
Anzeige
|
