Bei den AVR-Controllern z.B. läuft eine PWM ja einmal angestoßen hardwaremäßig im Hintergrund, ohne das Hauptprogramm zu belasten. Neue PWM-Registerwerte brauche ich eigentlich nur bei Drehzahländerung.Zitat von Holomino
Bei den AVR-Controllern z.B. läuft eine PWM ja einmal angestoßen hardwaremäßig im Hintergrund, ohne das Hauptprogramm zu belasten. Neue PWM-Registerwerte brauche ich eigentlich nur bei Drehzahländerung.
Ja, also laufend, weil die Drehzahlregelung ist ja eine Regelung. Sie regelt den Ist- zum Sollwert aus.
Stimmt natürlich. Eventuell wäre eine Auslagerung dieser Regelung in einen separaten "Antriebscontroller" sinnvoll. Der kümmert sich dann nur um die Belange des Fahrwerks.
Die Interruptgeschichte, was Holomino meint, spielt sich bei mir, wenn, dann (für das Fahrwerk) auf unterster Ebene ab. Ich habe drei Ebenen. Die AVRs für die Echtzeitsteuerung der Räder (Encoder auslesen, Motor steuern, auf Ereignisse mit Stillstand reagieren). Die zweite Ebende ist auch ein AVR, der soll Berechnungen anstellen, wie die einzelnen Räder zu steuern sind (also welche Daten die untergeordnete Ebene bekommt) und kann auch auf Ereignisse von außen reagieren; aber vor allem auf Ereignisse der Ebene drunter (also direkt von den Antriebseinheiten). Es gibt auf Ebene 2 noch einen AVR, der eigentlich nur dem Schnittstellenhandling dient. Der stellt vor allem Digital- und Analog-Pins zur Verfügung. Irgendwie muss ich ja noch was messen können. Da kommt es dann drauf an, was angeschlossen wird, danach richten sich dann die Funktionen in der Firmware und da kann ich z.B. auch noch Interrupts einbauen. Die oberste Ebene ist ein ESP-12E, als schnellste Recheneinheit. Der verteilt vor allem Programmcode an die darunter liegende Ebene und ist sonst noch nicht ausgelastet. Ich fürchte, dass ich vermutlich Funktionen der zweiten Ebene aus dem AVR am besten raus nehme und die auf den ESP-12E verlagere (zum Beispiel langwierigere Berechnungen); das muss ich dann mal sehen, wie das mit den Zeitfenstern überall so passt. Eigentlich soll die mittlere Ebene die Oberste entlasten. Der ESP muss vor allem Daten zusammensuchen, vielleicht Wege berechnen usw. Also so weit habe ich das durchdacht. Zurzeit übe ich noch mit der Fortbewegung, ich probiere noch aus, was auf Ebene 2 wie schnell geht und wie dort die Vorgänge optimal gestalten kann (also den Programmablauf zur Fortbewegung). Deshalb dieses Thema hier "Fortbewegungsstrategie gesucht".
MfG
Drei "Ebenen" AVRs. Versteh ich.
Der AVR für Schnittstellenhandling stellt Digital- und Analog-Pins zur Verfügung? Wieso dann Schnittstellen? Das verstehe ich nicht, kann mir nicht vorstellen. wie gehts?
Und ESP verteilt Programmcode? An die AVRs? Wie geht das? Programmiert der at runtime die Controller neu?
Hallo muell-er!
Ja, wieso Schnittstellen?
Schnittstellen gibt es überall, in Software, Hardware und auch in Hardware selbst.
Bei mir gibt es nur einen AVR, wo man praktisch noch was anschließen kann. Alles andere ist intern auf der Platine verdrahtet und (fast) nichts mehr nach außen geführt. Da sind theoretisch noch eine USART, serielle Schnittstelle und I2C, die I2C-Schnittstelle nutzt er selbst. Aber auch durch Software auf einem AVR lassen sich zusätzlich Schnittstellen installieren, die man so gängig als das sehen würde, wie SoftwareSerial (wo die ganz normalen I/O-Ports genutzt werden). Oder man nutzt die Pins anderweitig, direkt selbst als Schnittstelle und zusammen mit anderen Pins, womöglich einen ganzen Port, als weitere Schnittstelle. Da aber noch nichts festgelegt ist: Schnittstellenhandling, als allgemeinen Begriff, für Schnittstellen zu externen Geräten.
Der Programmcode ist festgelegt und gespeichert auf SD-Karte. Aber es ist durchaus denkbar, dass die Software auf dem ESP in der Lage ist, diesen Programmcode auch zu ändern. Die AVRs haben ihre Firmware drauf, die die Funktionen beinhaltet, die ein AVR ausführen soll. Also Funktionsumfang ist damit festgelegt. Damit tut der AVR aber jetzt nichts. Einzige Ausnahme hier vielleicht die IR-Diode, die ich fest in der Firmware drin habe, die aber auch nicht ausgewertet wird, solange dieses Feature nicht aktiviert ist. Damit die AVRs was tun, brauchen die Code für den Programmablauf. Den fordern sie beim ESP an. Der ESP ist auch in der Lage, selbst mitzuteilen, wer was tun soll. Er kann direkt dem AVR mitteilen, dass dieser jetzt als nächstes Programmcode Nr. 14365 ausführen soll. Darauf hin wird der AVR schauen, ob er den schon gespeichert hat, wenn nicht, muss er ihn anfordern und der ESP schickt ihm den (per I2C oder USART). Zu diesem Zweck habe ich einen Bytecode-Interpreter eingebaut. Und um der nächsten Frage zuvor zu kommen: auf dem ESP ist ein Webserver installiert, worüber man diese Codeblöcke erstellen und verwalten kann.Programmiert der at runtime die Controller neu?
MfG
Ich bin etwas weiter. Nachdem ich ein paar Korrekturen im Code vorgenommen habe, fährt das Chassis nun endlich zufriedenstellend per IR-Fernsteuerung. So konnte ich das jetzt mal ausprobieren, was ich benötigen würde, um in der Wohnung zumindest herum zu fahren und Hindernisse zu umfahren. Zurzeit habe ich 45°-Abschnitte zum Drehen. Das ist etwas zu wenig. Praktisch ist die Hälfte davon besser. Also 22.5°. Zum Fahren sind 30cm am Stück schon ganz gut. Aber auch hier manchmal etwas viel. Deswegen denke ich, 10cm-Abschnitte wären gut, vielleicht auch 15cm. Feinsteuerung ergäbe sich später per Abstandsmessung, auch genaueres Fahren, um z.B. eine Ladestation anzufahren.
MfG
Berechtigungen
Zitieren
Lesezeichen