Wie berichtet, kam heute das bestellte AVR Evaluationboard von Pollin an. Ich habe mir aus Faulheit und mangels Lötausrüstung die fertig montierte Version bestellt, aber jeder halbwegs versierte Löter sollte mit dem Zusammenbau von Hand kein Problem haben.
Pollin Evalboard AVR
Also ATmega16 eingesteckt, Netzteil angeschlossen, etwas mit den avrdude Einstellungen rumgefummelt – und siehe da, ich hatte mein erstes Testprogramm laufen, welches zumindest beide Test-LEDs anknipst. Zu mehr hatte ich erstmal keine Zeit, aber mir war es wichtig, daß das Board inklusive ISP via RS232 überhaupt erstmal funktioniert.
Aus Eclipse heraus habe ich avrdude konfiguriert. Da ich bei mir irgendwie Ponyprog mit RS232 nicht einstellen konnte, habe ich etwas rumprobiert und schließlich ging der “Lancos SI-Prog” sehr gut. Ich musste nur die Schnittstelle auf die RS232 konfigurieren (Bei mir /dev/ttyS0 unter Linux)
avrdude Einstellungen für das Pollin Evalboard
Danach hatte ich plötzlich einen funktionierenden avrdude Aufruf im Outputfenster und die LEDs gingen an
Erster Test bestanden! Auf geht es in die neue Welt der AVRs! Und viel gekostet hat mich der Spaß auch nicht
Ich habe mir bei Pollin ein relativ günstiges Evaluation Board bestellt und gleich ein paar ATmega16 Chips dazu.
Angeblich ist das Board mit Ponyprog kompatibel und daher müsste ich es über avrdude ansprechen können. Ich werde es erfahren, wenn das Paket da ist.
Etwas konkrete Fortbildung und was zum Basteln und Entdecken ist immer gut – und im Gegensatz zu meinem 2003 gekauften 8051 Board von Phytec, hält sich der finanzielle Aufwand in Grenzen. Board und Zubehör für die AVRs kosten mich im Moment ca 30€, während ich damals 160€ bezahlt habe. Dafür ist das Phytecboard vermutlich stabiler und besser dokumentiert, aber man kann nicht alles haben.
Ich warte dann mal auf die Lieferung warten und werde dann berichten.
Im Laufe der Woche habe ich lange nachgedacht und beschlossen, mich prinzipiell mit weiteren Mikrocontrollern zu Fortbildungszwecken zu beschäftigen. Bislang habe ich praktisch einiges mit 8051er gemacht, aber modernere Architekturen sind doch sehr einladend. Vorallem möchte ich mal Erfahrung mit echten RISC-Architekturen sammeln.
Längere Zeit habe ich damit geliebäugelt, ein Board mit ARM zu kaufen. Leider sind ARM Prozessoren nicht so 100% hobbytauglich, da sie in aller Regel nur 3Volt Ein- und Ausgänge haben. Ferner kommen sie nur in SMD-Technik daher, was das Löten für Grobmotoriker wie mich extrem verkompliziert, wenn nicht sogar unmöglich macht. Ferner ist mein Interesse sehr Lowlevel, was I/O an geht. Ethernet und CAN-Anwendungen reizen mich im Moment auch nicht. Da das Lernziel sowieso Praxis mit Assemblercodierung für RISC-Architekturen ist, ist ein Controller, auf dem ein Linux läuft, nicht so 100% das was ich suche.
Schließlich habe ich mich dann doch für beliebte Bastleralternative entschieden und werde mich in Zukunft ein wenig mit AVRs von Atmel beschäftigen. AVRs passen zur Not ins Steckbrett, sind extrem tolerant, was die äußere Beschaltung angeht, haben einen schönen RISC-Kern und sind untereinander durchaus kompatibel.
Außerdem gibt es Support, eine gute Community und last but not least erschwingliche Starterkits. Ich plane mir demnächst ein STK500 zuzulegen. Das wird supported, kann auch mit freien Tools unter Linux angesteuert werden (Die Programmiersoftware avrdude behauptet das jedenfalls von sich) und es ist gleichzeitig ein erstes Evalboard, mit dem man die ersten Schritte ohne Bau von Hardware machen kann.
Letzteres ist für mich recht wichtig, da ich zur Zeit keinerlei Löt- und Bastelausrüstung hier habe.
Für den Anfang habe ich mir erstmal unter Linux die nötigen Tools installiert, darunter Assembler, Linker, C Compiler und die spezielle C Library für AVRs. Ich habe mich an diese Anleitung hier zur Installation der avr-libc gehalten. Es hat soweit geklappt. Mangels echtem AVR konnte ich aber bislang noch kein Programm flashen oder testen. Aber übersetzen und HEX-File erzeugen funktioniert soweit ganz gut.
Nebenbei habe ich einiges über die GNU Toolchain gelernt, unteranderem daß der GNU Assembler architekturunabhängig relokatiblen Objektcode erzeugt und erst der Linker legt die genaue Position im Speicher fest. Fernen spuckt er grundsätzlich erstmal Binärdateien im ELF Format aus. Aber mit dem objcopy Programm kann man dann Intel HEX erzeugen. Wenn man andere Toolchains gewöhnt ist, ist das natürlich etwas umständlich. Andererseits ist es aber auch recht flexibel, und wenn es automatisch gemanaged wird (s.u.), will man ja nicht viel mehr.
Hinweis: Zum Selberkompilieren der Toolchain sind temporär ca 3GB freier Plattenplatz erforderlich. Die GCC Sourcen sind ein ziemlicher Moloch während der Übersetzung.
Da ich in letzter Zeit sowieso viel mit Eclipse und CDT gearbeitet habe, habe ich auch gleich das AVR Plugin dazu installiert. Damit kann man gleich ein Codeprojekt für die AVR Toolchain aufsetzen und alles wird halbwegs sinnvoll konfiguriert. Das gefällt mir sehr gut. Man muss seine Makefiles nicht selber schreiben und man kann direkt aus Eclipse heraus avrdude konfigurieren und aufrufen. Im Prinzip stellt man nur den gewünschten Prozessor und die Taktrate ein und kann dann fröhlich loscoden.
