Senden und empfangen auf dem UART mit ISR kompatibel zur bisherigen RP6lib

Hallo Thorben,
Ich habe leider keine M256 und kann daher die Lib nicht 1:1 anpassen. Da nutzt auch kein Feiertag was.
Mit etwas Fingerspitzengefühl kann man sich die jedoch auch selbst anpassen, ich hab ja im Thread schon recht umfangreich erklärt wo es drauf ankommt.
Ich baue z.Z. an einer stdio-ähnlichen Lib welche jedoch ohne die stdio auskommt und mittels I2C & IR die "Gerätetreiber" über Board und Robot Grenzen hinweg erreichbar macht.
Daher verfolge ich die Konzeption der Lib wie gepostet so nicht mehr. Vielleicht werde ich mir aber mal noch ein M256 Modul zulegen wenn die neue Lib zwischen Base und M32 bzw. zwischen meinen 2 Bots zufriedenstellend läuft. Ob es dann noch Sinn macht, die alte Lib anzupassen kann ich erst sagen wenn ich weis ob und was die neue können wird. Es sieht schon gut aus aber ich will noch nichts versprechen.
Gruß

Hallo RolfD,
bevor du es geschrieben hast wusste ich garnicht, dass die Serial-Funktion (in störender Art) blockieren könnte. Das mit dem stdio war mindestens interessant. Getestet habe ich deine Lib noch nicht, das lag aber auch daran, dass eben kein zip-file wartet welches die Änderungen der UART und des LCD beinhaltet.
Leider kenne ich mich nicht so gut mit dem RP6 aus, weil mich das Studium regelmäßig zwingt, ihn verstauben zu lassen.
Aber an gebufferten Funktionen bin ich stark interessiert: Ziel ist alles per I2C steuerbar zu machen. Habe auf die Erweiterungsplatine gestern einen Header für ein Stellaris Launchpad (80 MHz ARM, bei watterott für 12 Euro) und für ein HC06 Bluetooth gelötet. Der ARM soll Busmaster werden.

Hallo,
grundsätzlich gibt es 2 Methoden um Zustände abzufragen. Polling ( CPU fragt dauernd ein Port ab und reagiert bei Ereignis) was immer blockierend wirkt .. oder Interrupt (CPU reagiert durch Interruptcontroller der das Ereignis feststellt). Man kann alle Interruptquellen auch pollen... was in der Originalfassung der RP6Lib beim serial send z.B. gemacht wird, man kann aber auch Interrupt Serviceroutinen ISR schreiben, die einfach nur den Statuswechsel erkennen .. wie z.B. die Counter-ISR für die Lichtschranken oder man kann komplexe Funktionen da rein bauen... letztlich hängt es von der verwendeten Software/Lib und der Philosophie und Knowhow des Programmieres dahinter ab, wie da mit umgegangen wird. Pollen funktioniert immer dann gut, wenn es nur eine relevante Ereignisquelle gibt - das ist beim RP6 als rollender, sich orientierende Bot aber meist nicht gegeben. Allerdings dient der RP6 oft auch nur als Experimentierplattfrom und da reicht das durchaus. Der Autor der Libs hat aber auch schon immer gesagt, das die Libs nur ein Grundgerüst darstellen, welches ausgebaut werden kann und soll.

Es gibt ja noch andere große AVR Projekte... C'T-Bot, Arduino, usw... wo man das ggf. anders regelt. Ein blick über den Tellerrand ist immer hilfreich, allerdings exist1iert im Gegensatz zu solchen Projekten für den RP6 keine wirkliche Community, welche gemeinsam die Libs weiter entwickelt. Deswegen wird es von mir dazu auch keine ZIP-Files geben. Denn ich möchte nicht, das meine Ergebnisse einfach so unreflektiert in anderen Projekten Eingang finden ohne das sich die Leute Gedanken machen oder Feedback geben.

Zu Buffer und IO noch ein Wort, gebufferte IO ist eine feine Sache aber sie birgt ein riesen Nachteil. Nutzt man mehrere Funktionen hintereinander, welche jeweils für sich buffern, frist das Speicher und ist sehr arbeitsintensiv weil ständig Bufferdaten von einem Buffer zu einem anderen umkopiert werden müssen. Die CPU hat ja keine DMA. Insbesondere dann wenn noch Daten per Value und nicht per Reference übergeben werden, kann man seine CPU massiv ausbremsen. Das allein ist schon Grund genug, die verwendeten IO Funktionen genau zu untersuchen und zu verbessern. Aber wie auch schon beim Interrupt - für ein einfaches LED aus/an oder ein paar Buchstaben auf der serial Console reicht das vorhandene und daher macht sich kaum jemand die Mühe.

Es gibt allerdings auch andere Ansätze dem System Beine zu machen z.B. in dem man sich ein RTOS Framework .. also preemtives Multitasking auf den Prozessor anpasst. Dann wartet ein Task halt bis er sein Job gemacht hat und gut is... hab ich auch mal ansatzweise hier beschrieben, es funktioniert einwandfrei. Allerdings ist der Denkaufwand auch höher weil man sich mit (für viele Leute) ganz neuen Konzepten rumschlagen muss.

Aus diesen und weiteren Überlegungen heraus schreibe ich derzeit sowas wie eine gebufferte, stringorientierte stdio, welche in der Lage ist, über eine Art Software Router ähnlich dem rpc auf Unix Befehlsketten an ein anderes Board via I2C und IRDA zu übergeben. Leider ist das langwierig und fehleranfällig da ich kein Profi progger bin.
Ich möchte aber wieder weg vom RTOS und die RP6Libs sind mir zu aufgebläht.
Ja mal sehen was bei raus kommt.
Dein Projekt klingt diesbezüglich auch interessant, ich hatte mal mit einem ARM7 Board am RP6 rumexperimentiert, ich glaube der User Radbruch hier hat auch ein ARM am RP6 laufen.
Gruß

OK, es ist zwar kein Geheimnis wie solche Buffer funktionieren (gibt ja auch bei mikrocontroller... genug Beispiele und Libs) aber ich kann trotzdem nachvollziehen wenn du keine ZIPs machen willst wenn das Geben/Nehmen-Verhältnis nicht stimmt.

Ob die Hersteller-Bibliotheken drauf bleiben oder nicht werde ich später entscheiden. Das mit dem Regler/Antrieb und diesen Tasks erscheint mir schon etwas eigenwillig (er übersteuert ja leicht beim Anfahren und man kann nicht ganz auf 100%), aber wenn man damit präzise Bewegungen ausführen kann soll es mir recht sein. Vorerst probiere ich's mit, sonst kann ich da nochmal einen Tag Arbeit reinstecken.

Habe inzwischen auf die Base und die M32-Erweiterung jeweils I2C aufgespielt. Jetzt weiß ich auch, wie man das Ganze mit Atmel Studio nutzt...
Für das Stellaris Launchpad und die Energia IDE habe ich nun entsprechende Klassen geschrieben die die Funktionen der Base und der M32 kapseln. Mit dem Bluetooth-Modul gibts noch Schwierigkeiten. Vielleicht liegts aber auch am verwendeten seriellen Ausgang des Boards. Das gilt es noch herauszufinden. Das Ding soll keine große Nummer werden, mehr so privat. Wenn aber daran Interesse besteht, kann ich (wenn's fertig is) ein neues Topic aufmachen und es vorstellen. Bis jetzt ist glaube ich nur der I2C-Code für die M32 kopiert, weils da nix offizielles gibt. Eigentlich würde ich auch gerne ein Mapping realisieren mit solchen China-Ultraschall-Modulen, habe andererseits aber auf einer Seite heute ein Diagram gesehen das nicht auf hohe Qualität von den Dingern schließen lässt. Aber wer weiß, vlt lässt sich ja über Kalman noch was machen, dann lern ich den auch mal richtig.

Naja als Sniplets stehen die zu machenden Änderungen und Beispiele von mir ja im Thread... muss man sich eben nur zusammen suchen. Hab auch schon ganze Texte/Libs als Anhang gepostet... also so schwierig ist es ja nicht. Ich hab ja nichts dagegen wenn jemand das benutzt was ich poste. Aber es gibt hier eben auch genug Flachhirne, die alles nur per copy&paste machen und sich beschweren wenn man mehr als 3 Zeilen Text dazu schreibt und die dann noch meckern wenns nicht auf Anhieb läuft.
Mit dem Atmel Studio kannst du auch ARMs proggen, da gibts eine ARM Toolchain. Ich persönlich finde es angenehmer, wenn man nicht dauernd die IDE wechseln muss.
Die Idee, dein Projekt vor zu stellen finde ich gut.
Gruß

Zitat:

---

Zitat von RolfD

... Mit dem Atmel Studio kannst du auch ARMs proggen, da gibts eine ARM Toolchain ...

---

Sorry wenn ich jetzt als Flachhirn komme: Vor Deinem Hinweis von eben auf Atmel Studio mit ARM-Funktionalität wußte ich nix davon. Nun lese ich in der RELEASE NOTES Atmel Studio 6.1 ( 42130A-MCU-06/2013 ) schon auf der ersten Seite den gleichen Hinweis. Danke, dass Du das hier erwähnt hattest (mich interessiert an diesem Thread hier die UART-Thematik, die ich als Nicht-PR6er mit PDanneggers - modifizierter - Bibliothek gelöst habe).

Studio 6 wollte ich bisher nicht nehmen, weil das m.E. viel Overhead für eine doch eher aufwändige Projektbearbeitung mitbringt, die für meine Hobbyprojekte nicht nur ~head vielleicht sogar ~kill ist. Dachte ich. Aber nun wirds doch überlegenswert. Bisher hatte ich nur Ratschläge gelesen zu einer separaten IDE für den ARM (hier und hier). Deshalb wird diese Thematik auch zumindest noch die Kollegen Gerhard/oderlachs und White_Fox interessieren.

Frage/Bitte: könntest Du mir bitte etwas mehr zu Deinen Erfahrungen mit dem Studio6, besonders im Hinblick auf ARM schreiben, vielleicht hier hin (wegen OT hier)? Danke im Voraus!

Hallo,
ja die Lib vom Dannegger als Basis tuts auch... es gibt viele Libs zur AVR Serial, welche alle nur mit Wasser kochen bzw. Grundfunktionen bieten. Ich selbst hab mir das auch angeeignet indem ich mir verschiedene Libs und die Manuals dazu angesehen habe. Ich versuche aber immer nachzuvollziehen was warum wie gecodet wurde, und dann sieht man halt irgendwann, das einer eine Fehlerprüfung drin hat.. und wie sie funktioniert.. und der andere eben nicht... so als ein Beispiel. Deswegen ist aber mein Code nicht automatisch besser als der von jemand anderem. Benutze also gern die Lib vom Dannegger weiter.
Meine Vorschläge/Änderungen betreffen aber weniger die eigentliche ISR mit dem Buffer - was technisch sogar ähnlich gelöst ist wie ich grade sehe, wobei der algo zur Berechnung der Bufferposition komplizierter ist - sondern eher so Erweiterungen wie xon/xoff in der ISR.
Zum Studio, im Prinzip ist das Atmel Studio ein modifiziertes Visualstudio von MS, eine durchaus erprobte, stabile und vielseitige IDE mit einer Toolchain alla winavr oder winarm, was beides wiederum den gcc als Crosscompiler nutzt. Da gibts kaum Unterschiede zwischen ARM und AVR. Ich denke da gibt es nicht viel zu schreiben, es funktioniert halt und wenn man dran gewöhnt ist, auch gut.
Es gibt viele weitere IDEs die so arbeiten und es gibt viele Leute die eine oder andere IDE präferieren und sicherlich ihre guten Gründe dafür haben.
Ich bin der Meinung, man sollte die Tools nutzen mit denen man am besten zurecht kommt und da ich nun mal aus der Windows und Linux Programmierung komme, sind mir große IDEs wie eclipse oder eben VS nicht fremd. Ich persönlich finde z.B. in makefiles händisch rum zu fingern viel lästiger aber letzlich arbeitet auch die gcc toolchain nur mit makefiles.
Daher will ich da keine Empfehlung zum Umstieg geben. Es kommt drauf an das ein Auto fährt, nicht wie dick die Reifen sind - und Gas geben tut eh der Fahrer.... Um das mal bildlich darzustellen.
Auf dein outing als Flachhirn weis ich nichts zu sagen... du wirst wissen warum du es schreibst.
Gruß

Zitat:

---

... Da gibts kaum Unterschiede zwischen ARM und AVR. Ich denke da gibt es nicht viel zu schreiben, es funktioniert halt ...

---

Danke für die Beschreibung. Das mit dem "Flachhirn" sollte meine völlige Unerfahrenheit mit den ARMs hervorheben. Leider lese ich nicht wirklich aus Deinem Post ob und welche ARMs Du mit dem AVRStudio schon programmierst hattest.

Eigentlich wollte ich nämlich wissen ob Du schon konkrete Erfahrungen mit dem Programmieren der ARMs (welche ?) unter AVRStudio gemacht hattest ("... Deinen Erfahrungen mit dem Studio6, besonders im Hinblick auf ARM ..."). Hast Du?

Nochmal danke für Deine Mühe.

http://www.atmel.com/products/microc...m/default.aspx
Das sind die ARMs, die soweit vorbereitet sind aber wenn man sich damit auseinander setzt, stellt man fest das auch andere Devices möglich sind. Wie gesagt.. WinARM ist eine GCC Toolchain.
Ich selbst hab LPC2138 Boards wie dieses: http://www.etteam.com/product/arm7_lpc2138.html

Gruß