Mit Assembler kommt man bei Robotern schon sehr weit. Es wird zwar nicht unbedingt für Kamera-Auswertung und Map-Making reichen, aber die Grundfunktionen kann man damit sehr gut abdecken. Gerade wenn es um die Hardwaresteuerung geht ist Assembler unschlagbar.
Also nur Mut und drauf los, ich meine, dass man den Asuro auch in Assembler programmieren kann.
http://www.avr-asm-tutorial.net/avr_de/index.html
hatte mich an die Herstellerfirma NICAI SYSTEMS gewendet und bekam Antwort!
Sehr geehrter Herr Hegewald,
selbstverständlich ist der NIBObee Roboter in Assembler programmierbar. Das heißt nicht, dass wir für den AVR-Assembler
Tutorials etc. bereitstellen. Das ist für Assembler auch nur schwer möglich...
Assembler 'lebt' davon, dass man alles auf die gründliche Tour macht, deshalb wird die Sprache in der Regel nur für
Teile einer komplexen Software eingesetzt.
Wie man das machen kann können Sie in meinem Beispiel für einen Multitasking-Scheduler für den NIBObee sehen, dort ist
der Code zum switchen des Kontextes in Assembler geschrieben:
http://www.roboter.cc/index.php?opti...2668&Itemid=41
Als Einsteiger würde ich Ihnen empfehlen, zunächst in C-Programmen einfache Routinen durch reinen Assembler-Code zu ersetzen.
Prinzipiell brauchen Sie für den Einsatz von Assembler, den Schaltplan des Roboters, die Dokumentation von Atmel zum ATmega16A
und die AVR Instruction Set Reference von Atmel:
* http://download.nicai-systems.com/ni...matic_1_14.pdf
* http://www.atmel.com/Images/Atmel-81..._Datasheet.pdf
* http://www.atmel.com/Images/Atmel-08...Set-Manual.pdf
Gute Informationen und eine Tutorial zum Thema AVR Assembler finden Sie auf den mikrocontroller.net Webseiten:
http://www.mikrocontroller.net/articles/AVR-Tutorial
Mit freundlichen Grüßen,
Nils Springob
Am 03.02.2015 um 19:00 schrieb Rolf Hegewald:
> Hallo,
> hätte Interesse am Kauf eines Bausatzes wie o.g.
> Über Reichelt-Elektronik hatte ich die Möglichkeit, eine PDF-Datei bezüglich zur Programmierung zu öffnen.
> Die detaillierten Hilfeprogramme zur ersten Inbetriebnahme, sowie alle anderen Programme sind alle in C bzw.
> C++ aufgeführt. Also hätte ich mit meinen Assembler-Kenntnissen kaum eine Chance!
> Obwohl von Reichelt in der Allgemeinbeschreibung auf Assembler hingewiesen wird.
> Ich wüßte nicht, wie eine Kombilierung von C auf Assembler stattfinden könnte.
> Giebt es von Ihrer Seite hierin eine Alternativ-Lösung??
>
> Mit freundlichem Gruß
Ich programmiere seit Jahren ASM auf dem PC. C/C++ natürlich auch. Ich kann sagen dass ASM (wenn man mit allen Wassern gewaschen ist) C/C++ deutlich überlegen ist. Und ich finde den Programmieraufwand kaum höher.
Bei extrem anspruchsvollen Applikationen ist ASM die erste Wahl.
Und die, die sagen dass es nicht so ist, können selten ASM.
Hallo,
So als Faustformel gilt, dass 1 Zeile in einer Hochsprache etwa 10 Zeilen Assembler entspricht.Zitat von Karl1000
Ich programmiere seit Jahren ASM auf dem PC. C/C++ natürlich auch. Ich kann sagen dass ASM (wenn man mit allen Wassern gewaschen ist) C/C++ deutlich überlegen ist. Und ich finde den Programmieraufwand kaum höher.
Bei extrem anspruchsvollen Applikationen ist ASM die erste Wahl.
Und die, die sagen dass es nicht so ist, können selten ASM.
Die Leistung eines Programmierers in Zeilen Code/Tag ist in etwa konstant, beim Assembler braucht man etwas mehr Zeit fürs Debuggen.
Mit einer Hochsprache ist man also in etwa 10x schneller mit einem Projekt fertig.
Was die Effizienz von C anbelangt ist der Unterschied bei heutigen Compilern mit Optimierung nicht mehr sehr gross.
Assembler ist im Durchschnitt nur 10-20% schneller/kompakter.
Für einzelne zeitkritische Funktionen macht Assembler einen Sinn. Auch für den Taskwechsel in einem Multitask-System (Alle Register retten und alle wieder restoren) kommt man um Assembler nicht herum.
Ausser für die genannten Ausnahmen, habe ich in den letzten 20 Jahren nichts mehr in Assembler geschrieben, sondern alles in C!
Allerdings sind Assembler-Kenntnisse sehr von Vorteil, wenn man den Linker verstehen und ausnutzen will. Dann bekommt man es auch hin, dass Konfigurations-Einstellungen auch nach einem Firmware-Update erhalten bleiben.
MfG Peter(TOO)
P.S. Angefangen mit Assembler habe ich 1976 mit einem KIM-1 (6502 CPU). im Laufe der Zeit sind noch jede Menge CPUs dazugekommen.
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Also bei Microcontrollern ist ASM wirklich Schwachsinn. Wenn da die Performance nicht reicht nimmt man halt einfach was schnelleres. Wenn man aber hardwaremäßig am Anschlag ist und mit wassergekühlten 5GHz CPUs am Wergeln ist, kann nur durch ASM noch einiges gerissen werden. Aber wo man mitspielen will muss am Ende jeder selber entscheiden. Und eins ist ja uns allen klar, am Ende entscheidet immer der Coder wie schnell etwas laufen wird...
finde ich vollkommen richtig.
C (nicht unbedingt C++) ist grundsätzlich genau so schnell wie ASM (habe früher mit Turbo C und Turbo asm auf x386 "gearbeitet", um beide immerhin vergleichen zu können), aber C ist 1000x mächtiger und vielseitiger. Kein Wunder, dass man es bekanntlich "erfinden musste", um UNIX überhaupt programmieren zu können (wie man auch hier lesen konnte).
Und wer wirklich Multitasking braucht, sollte ARMs verwenden, die von vornherein MT unterstützen (Arduino Due mit Due Scheduler, NXT mit nxtOSEK, EV3 mit POSIX pthread, oder RasPi, BBB...), warum sich hier die Arbeit machen, selber Speicher und Register zu sichern und wieder zurückzuschreiben? Hinzu kommt die extreme Speicher-Einschränkung, die AVRs haben - völlig ungeeignet für anspruchsvolle Robotik-Anwendungen (ich spreche allerdings nicht von Linienfolgern). Daher: mindestens ein Due für Robotik, zusätzliche ARMs für IO-Multiplexing. Alleine 6 Encoder-Motore mit pwm brauchen schließlich bereits 30 Dpins.
Natürlich kann man auch gleich mit der erneuten Erfindung des Rades anfangen...
Hallo,
Irgendeiner muss das MT mal schreiben, sonst kannst DU es dir nicht fertig besorgen.
Zudem benötigt man ASM nur für die Funktion welche die Register bei einem Taskwechsel manipuliert.
Das heisst alle Register auf den aktuellen Stack retten, den Stackpointer sichern, Stackpointer des neuen Tasks laden und gerettete Register vom neuen Stack laden.
Passt alles auf eine A4-Seite.
Zudem sprach ich nicht von einer bestimmten CPU, sondern nur über Umstände welche zwingend zu ASM-Routinen führen.
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Berechtigungen
Zitieren
Lesezeichen