Aber warum ?
(Tja, hier besser geplenkt. Seht ihr, was ich meine ?
Das Fragezeichen z.B. hat meiner Empfindung nach nix mit
dem Wort direkt davor zu tun, eher mit dem ganzen Satz.)
Ohne da jetzt was lostreten zu wollen, 'ne Alternative :
tja, hier besser nicht geplenkt. seht ihr, was ich meine ?
das fragezeichen z.b. hat meiner empfindung nach nix mit
dem wort direkt davor zu tun, eher mit dem ganzen satz.
ich sehe nicht, daß das schlechter zu lesen sei, optisch finde ich's schöner.
Du könntest dir auch das Leben leichter machen und Platinchen (Matrosen)
bauen. Ein kleiner MC und die Motortreiber darauf. Das würde dein
Softwareproblem und den Kabelverhau reduzieren und skalierbar sein.
Da hast du mit Sicherheit recht.
Wär ja auch spaßig, jede relevante Arbeit von nem kleinen Nano oder
sowas machen lassen, quasi "Hardwareobjekte", und das über ein Bussystem
zu vernetzen.
Nicht zum Selbstzweck ... sondern um deine Probleme mit den Eingängen zu lösen und für dein nächstes Projekt wiederverwendbare Module zu haben. Du solltest dich auch von dem Gedanken lösen das ein OO Objekt eine Entsprechung im realen Leben haben muss.
(Sowas hatte ich schon mal : ein Raspi mit Python hat kommuniziert
(OPCuA)und gerechnet, ein Ardu seriell dran hat eine Delta-HW gesteuert.
Aber Hardware ist aktuell nicht mein Ding, ich tippe grad lieber und
gehe auf die Reise durch die neue Welt der Objektorientierung.
Auf einer Reise sollten man vorne beginnen !!!
Aber wie schon mehrfach gesagt mach das auf einem PC.
Den Python-Gedanken hat keiner aufgegriffen : AVR und Python, geht das ?
Mach doch nicht alle 5 Minuten neue Fässer auf wenn du in endlicher Zeit mit etwas fertig werden willst.
Wie ist das allgemein hier ?
Technisches Forum mit möglichst knapper, präziser Info, oder ist auch
Geplauder erlaubt ? Wenn nicht erwünscht, sollten wir das
Kaffeekränzchen stoppen, ansonsten macht's Spaß.
Hier ist es normal, dass solange diskutiert, gepöbelt und persönlich angegriffen wird, bis mindestens einer beleidigt das Feld räumt, der Admin was löscht oder der Thread geschlossen wird :-)
Wie ist das allgemein hier ?
Technisches Forum mit möglichst knapper, präziser Info, oder ist auch
Geplauder erlaubt ? Wenn nicht erwünscht, sollten wir das
Kaffeekränzchen stoppen, ansonsten macht's Spaß.
Hier ist es normal, dass solange diskutiert, gepöbelt und persönlich
angegriffen wird, bis mindestens einer beleidigt das Feld räumt, der
Admin was löscht oder der Thread geschlossen wird :-)
Persönliche Angriffe, Beleidigungen und Pöbeleien entlocken mir höchstens ein Grinsen, vor Allem, wenn sie üble grammatikalische Fehler enthalten. That's the price you have to pay !
Sollte einer der Admins was auszusetzen haben, und Teile löschen oder alles stoppen, ist das völlig ok : es ist euer Forum !
Du könntest dir auch das Leben leichter machen und Platinchen (Matrosen)
bauen. Ein kleiner MC und die Motortreiber darauf. Das würde dein
Softwareproblem und den Kabelverhau reduzieren und skalierbar sein.
Da hast du mit Sicherheit recht.
Wär ja auch spaßig, jede relevante Arbeit von nem kleinen Nano oder
sowas machen lassen, quasi "Hardwareobjekte", und das über ein Bussystem
zu vernetzen.
(Sowas hatte ich schon mal : ein Raspi mit Python hat kommuniziert
(OPCuA)und gerechnet, ein Ardu seriell dran hat eine Delta-HW gesteuert.
Aber Hardware ist aktuell nicht mein Ding, ich tippe grad lieber und
gehe auf die Reise durch die neue Welt der Objektorientierung. Den
Python-Gedanken hat keiner aufgegriffen : AVR und Python, geht das ?
Du fragtest für was getter und setter gut sein können.
Wenn du deine Software oo mäßig grundsätzlich auf einem Controller am Laufen hast, ist es nicht mehr weit, diese dann auf mehrere Controller zu verteilen.
Ob der Befehl des Segel einholens über einen seriellen Kanal an den Matrosen weiter gereicht wird, oder ob er den Befehl direkt bekommt, ist dann nämlich egal.
Also wenn du dich vorangig um Software kümmern willst, dann setze doch den Weg vom Kapitän über den Befehl an den Matrosen der dann genau ein Segel bedient und auch überwacht, um.
Wenn das einwand frei funktioniert, schnapp dir einen zweiten Ardunio und setze da einen weiteren Matrosen drauf. Der Code sollte der gleiche sein wie der vom ersten Matrosen, nur das er eben ein serielles Kommunikationsgerät hat 😉
Find ich extrem spannend. Ich hab die letzten Jahre viel mir Python
gespielt, natürlich nicht auf deinem Niveau, und rumgesucht, ob das auch
auf dem AVR möglich ist. Ich hab leider nix vernünftiges gefunden.
Es gibt meines Wissens zwei kleine Python-Interpreter namens Micropython [1] und Circuitpython [2], die aber nicht auf den ja doch sehr kleinen AVRs laufen. Aber auf dem ESP32, der hier im Thread schon erwähnt wurde, sollte zumindest Micropython gehen -- damit habe ich aber keine Erfahrung und kann deswegen leider nicht viel mehr dazu sagen.
Wenn du erlaubst, stelle ich dir dazu später ein paar Fragen. Soll ich
da ein extra topic machen, oder wie geht das ?
Ich werde diesen Thread weiterhin im Auge behalten. Im Kern sind Fragen zu Python hier zwar off-topic, aber es ist ja Dein Thread und Du entscheidest ob Du ihn thematisch ausweiten möchtest. Wenn Du Dich entschließt, einen eigenen Thread zu eröffnen, könntest Du hier ja einen Link dazu posten.
Darf ich auch mal ? Prima. Ich verspreche, ich tu's nur ein einziges Mal !
"fehler machen ist menschlich"
kleine empfehlung aus dem sprachlabor :
keine unlogischen satzzeichen, alles klein : schon sind die problemchen weg !
dann noch geplänkel oder wie das heißt : nach geschmack.
dazu emotionspartikel : macht nix !
"hätte hätte fahrradkette" ist ein bemerkenswerter ansatz ! weiter so !
wobei ich als verbesserungsvorschlag einbringen würde :
" hätte ? hätte fahrradkätte ! " (weil : dada ist nicht tot !)
jetzt is' aber gut mit sprachwissenschaft, es geht doch hier nicht um regeln, oder ?
Das hat Spaß gemacht.
Ich verstehe die Aussage nicht, daß AVR zu klein für Python sei. Das zu lösende Problem liegt doch im Compiler, nicht auf dem Prozessor, oder ?
Klärt mich auf !
(Zusammenhang zum Thema : ist OO mit Python statt C++ eine Perspektive ?)
Das zu
lösende Problem liegt doch im Compiler, nicht auf dem Prozessor, oder ?
Was meinst Du denn damit? Was ist denn Deine Vorstellung, wie eine interpretative Sprache abgearbeitet wird? Oder auch eine compilierte Sprache wie C++?
jetzt is' aber gut mit sprachwissenschaft, es geht doch hier nicht um
regeln, oder ?
Es geht um Umgangsformen. Die sind ein Teil einer Kommunikation, bei der die, die miteinander kommunizieren, voreinander nötigen Respekt zeigen.
Plenken ist wie schriftliche Koprolalie. Selbst am Stammtisch wird ständiges Rumrülpsen nicht goutiert.
Ich verstehe die Aussage nicht, daß AVR zu klein für Python sei.
Python ist keine compilierte Sprache, sondern wird mit einem Interpreter abgearbeitet (wie andere Skriptsprachen ebenfalls). Und dafür ist ein AVR wenig geeignet.
lösende Problem liegt doch im Compiler, nicht auf dem Prozessor, oder ?
Na ja, ich hatte da auch zunächst gezögert, mich aber dann daran erinnert, daß Basic z.b. vor 1000 Jahren auch eine reine Interpretersprache war, von der dann aber Compilervarianten erschienen. Das hat man damals wegen der Laufzeitoptimierung gemacht, es lief z.b. auf dem 6502 (8 bit).
Das meine ich ja, ist ein Compiler für Python nicht auch denkbar ?
(Ahnungslose Anmerkung : macht Microsoft mit .net nicht was ähnliches, also Python [IronPython ?] auf ne Zwischenebene complilieren, und dann in der Laufzeit ausführen ?)
Na ja, ich hatte da auch zunächst gezögert, mich aber dann daran
erinnert, daß Basic z.b. vor 1000 Jahren auch eine reine
Interpretersprache war
Ja, das waren noch Zeiten, damals auf dem KC85/3. Keine Leerzeichen, keine Kommentare und max 1-2 Zeichen Variablen, damit alles möglichst schnell lief. Wenigstens war das Basic schon im ROM.
Ich lese mich nochmal durch die fachlichen Beiträge, und hab dazu noch eine Frage. (Die PCINT brauche ich, weil die meisten anderen externen Interrupts in der HW belegt sind, also der I2c und seriell Port1).
Wie würdest du das machen, Timer 1 (der als Compare-Timer 100ms isochrone Echtzeit liefern soll) zum Entprellen von Inkrementflanken mitzuverwenden ?
Er muß ja beim Ereignis dann bis z.b. 30ms zählen, und das ist völlig asynchron mit dem Scheduling-Timer.
Meine Idee ist grad anders : Ich multiplexe mit dem RC-Empfänger. Dann hab ich halt kein Fernsteuersignal, solange ein Segel gesetzt oder geborgen wird (was eh fast nie passiert). Geht natürlich schief, wenn das Segel klemmt : dann ist die Steuerung tot ;-). Watchdog ?
//Timer 0 : PPM-Generator (für Servos und RC-Winden)
//Timer 1 : 10HZ-Generator für NPRM-Scheduler
//Timer 2 : PWM-Generator (CompA für Maschine )
//Timer 3 : PPM-Decoder (vom RC-Sender)
//Timer 4 : PWM für Fall-Winden in Gruppen
//Timer 5 : Entprellung der Inkrementgeber
//UART0 : USB zum PC
//UART1 : GPS
Timer5 brauchst Du nicht bzw. kannst das mit Deinem Timer1
zusammenfassen.
Und warum brauchst Du so viele externe PinChange-Interrupts?
(Die PCINT brauche ich, weil die meisten anderen externen
Interrupts in der HW belegt sind, also der I2c und seriell Port1).
Das ist keine hinreichende Begründung.
Externe Interrupts braucht man nur, wenn man das Problem nicht mit (wesentlich einfacher handhabbarem) Polling lösen kann.
Wie würdest du das machen, Timer 1 (der als Compare-Timer 100ms
isochrone Echtzeit liefern soll) zum Entprellen von Inkrementflanken
mitzuverwenden ?
Er muß ja beim Ereignis dann bis z.b. 30ms zählen, und das ist völlig
asynchron mit dem Scheduling-Timer.
Die Inkrementalgeber solltest Du pollen. Gerade weil sie prellen, was ich mir bei optischen Gebern eigentlich nicht vorstellen kann. Da ist ggf. noch ein HW-Problem verborgen.
Du lässt Deinen System-Tick-Timer (Timer1) mit 1ms laufen, und leitest davon alle Intervalle ab. Vielleicht hast Du ja auch eine RTC in dem AVR, dann kannst Du auch den nehmen, statt einen "wertvollen" Universal-Timer. Aber ich glaube der alter mega256 hat noch keinen RTC, oder?
(Die PCINT brauche ich, weil die meisten anderen externen
Interrupts in der HW belegt sind, also der I2c und seriell Port1).
Das ist keine hinreichende Begründung.
Externe Interrupts braucht man nur, wenn man das Problem nicht mit
(wesentlich einfacher handhabbarem) Polling lösen kann.
Ich hab einen 100ms-Scheduler. Damit kann ich die optischen Inkrementgeber an den Windenmotoren nicht erfassen (bis zu 10 Winden, jede bringt z.b. 20 Hz Inkrementsignal). Wenn ich den Scheduler ausreize (500 Hz ?), brauche ich z.b. für die Navigations-Task einen präemptiven Scheduler, weil mir sonst die Rechenzeit ausgeht für die Task. Nehm' ich Raspi und ein erwachsenes RTOS, saugen mir die Servos den Akku leer.
Ohne das alles jetzt ausführlich zu begründen : diese Signale kann ich nicht pollen.
Wie ich das Totzeit-Fenster (klassisches Anti-Bounce) von z.b. 10ms mit einem 8bit-Timer machen könnte fällt mir leider nicht ein ;-)
Du lässt Deinen System-Tick-Timer (Timer1) mit 1ms laufen, und leitest
davon alle Intervalle ab.
Aber Scheduler und Inkrementgeber sind doch asynchron.
Ja. Und?
Würdest du also lostickern, dann :
bei externem Ereignis Wert speichern und beim Nächsten dann
vergleichen ?
bei 100 resetten und Scheduling initiieren ?
Keine Ahnung was Du damit meinst.
Der Code zum Auswerten eines Quadraturencoders ist ja so, dass er sich automatisch "entprellt". Wobei ich ja annehme, dass Du ein elektrisches Problem an der Stelle hast. Hall- oder optische Geber "prellen" nicht.
Quadraturencoders ist ja so, dass er sich
automatisch "entprellt". Wobei ich ja annehme, dass Du ein elektrisches
Problem an der Stelle hast. Hall- oder optische Geber "prellen" nicht.
Tja mein Lieber, da trau ich mich jetzt mal zu widersprechen.
Das sind erstmal keine Quadraturencoder. Und die prellen sehr wohl, wobei man hier natürlich das falsche Wort benutzt. Klar federt da nix zurück. Aber die Optik ist so mies, daß beim hell/dunkel-Übergang mehrere Impulse resultieren, nicht reproduzierbar, je nachdem wie stark das eiert oder so. Antibounce bei solchen Gebern ist immer ne Totzeit hinter dem Impuls. Oder natürlich Totzeit mit Hardware. Aber ich find's mit dem Prozessor sportlicher und löte so ungern.
Quadraturencoders ist ja so, dass er sich
automatisch "entprellt". Wobei ich ja annehme, dass Du ein elektrisches
Problem an der Stelle hast. Hall- oder optische Geber "prellen" nicht.
Tja mein Lieber, da trau ich mich jetzt mal zu widersprechen.
Das sind erstmal keine Quadraturencoder. Und die prellen sehr wohl,
wobei man hier natürlich das falsche Wort benutzt. Klar federt da nix
zurück. Aber die Optik ist so mies, daß beim hell/dunkel-Übergang
mehrere Impulse resultieren, nicht reproduzierbar, je nachdem wie stark
das eiert oder so. Antibounce bei solchen Gebern ist immer ne Totzeit
hinter dem Impuls. Oder natürlich Totzeit mit Hardware. Aber ich find's
mit dem Prozessor sportlicher und löte so ungern.
Na gut. Du benutzt diesen Mist, weil Du gerne Probleme löst, die man bei einem gescheiten Aufbau nicht hätte.
Trotzdem kannst Du das ganz einfach mit periodischem Abtasten lösen.
Setze doch einfach die N20-Motörchen ein oder Schrittmotoren. Das vereinfacht vieles. Oder AS5147 als absoluten Positionsgeber.
Vorne (unten) die ersten beiden Winden (altes Bild).
Man sieht die Motoren aus den gelben Plastikgehäusen rausstehen. Im Gehäuse das Plastikgetriebe. Der Motor läuft in einer Art Lafette, von einer Feder abgestützt. Wenn die Anordnung referenziert wird (beim Einschalten), läuft das Fall gegen einen Anschlag und zieht den Motor in die Feder. Dort ist dann ein Endschalter (Referenzpunkt).
Links und rechts sind die Platinen der (billigen) Inkrementgeber.
Wenn ich besser sehen würde, würde ich auf die Platinchen ein Monoflop draufmurksen (mit nem C am Komporator), aber in SMD löte ich nicht mehr.
Na gut. Du benutzt diesen Mist, weil Du gerne Probleme löst, die man bei
einem gescheiten Aufbau nicht hätte.
Über Modellbau diskutiere ich hier nicht.
Wie Du willst.
Ich mache selbst Modellbau und setze für so etwas BLDC-Motoren mit Hall-Positionsgebern ein (Gimbal-Motoren) mit FOC. Auch das schafft ein AVR.
Kann man übrigens auch als Geber am Sender einsetzen und als Aktor im Modell. Somit hat man Haptic-Control: d.h. man spürt am Geber am Sender wie start im Modell am Aktor "gezogen" wird. Das ist nett ;-)
Und der N20 ist doch der Standardmotor im Funktionsmodellbau für so einen Kram.
Vorne (unten) die ersten beiden Winden (altes Bild).
Man sieht die Motoren aus den gelben Plastikgehäusen rausstehen. Im
Gehäuse das Plastikgetriebe. Der Motor läuft in einer Art Lafette, von
einer Feder abgestützt. Wenn die Anordnung referenziert wird (beim
Einschalten), läuft das Fall gegen einen Anschlag und zieht den Motor in
die Feder. Dort ist dann ein Endschalter (Referenzpunkt).
Oh je: noch was mechanisches ;-) Endabschaltung durch Strommessung geht auch ;-)
Links und rechts sind die Platinen der (billigen) Inkrementgeber.
Wenn ich besser sehen würde, würde ich auf die Platinchen ein Monoflop
draufmurksen (mit nem C am Komporator), aber in SMD löte ich nicht mehr.
