Ich gestehe. (nicht geplenkt) 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. Aber jetzt genug der Plenkelei ;-)
Reiner D. schrieb: > Hans-Georg L. schrieb: >> 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.
Reiner D. schrieb: > Ist doch geplenkt viel schöner : > > Beispiel : das ist geplenkt ! Nein. Ist es nicht. Auch wenn Du es im Restaurant schöner finden magst, mit offenem Mund zu kauen, es ist nicht schöner. Und Plenken ist wie mit offenem Mund zu kauen.
Reiner D. schrieb: > 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 :-)
Wilhelm M. schrieb: > Reiner D. schrieb: >> 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 !
Reiner D. schrieb: > Hans-Georg L. schrieb: >> 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 😉
Reiner D. schrieb: > das fragezeichen z.b. hat meiner empfindung nach nix mit > dem wort direkt davor zu tun Solche Diskussionen kannst du mit deinem C++ Compiler nicht führen. Es gibt Regeln, die für alle gelten und an denen es nichts zu rütteln gibt. Punkt.
Reiner D. schrieb: > Den Python-Gedanken hat keiner aufgegriffen : AVR und Python, geht das ? Nein, AVR sind dafür viel zu klein. https://micropython.org/
Reiner D. schrieb: > 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. [1] https://micropython.org/ [2] https://circuitpython.org/ > 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.
Reiner D. schrieb: > üble grammatikalische Fehler > That's the price you have to pay ! Plenken ist ein übler orthografischer Fehler.
Sheeva P. schrieb: > Fehler Fehler machen, ist menschlich. Aber bewusst über allgemeingültige Konventionen hinwegsetzen.... Ein solcher ist nicht an einer fruchtbaren Kommunikation interessiert. Dasselbe bei OOP.... > Kapselung interessiert mich nicht! Wer so spricht ist nicht an den OO Konzepten interessiert.
:
Bearbeitet durch User
Arduino F. schrieb: > Fehler machen, ist menschlich. Fehler, machen ist menschlich. Fehler machen ist, menschlich. Fehler, machen, ist, menschlich. Woher kommt nur die Neigung mancher Zeitgenossen, völlig willkürlich an falsche Stellen Kommata in ihre Sätze einzubauen? Kurzatmigkeit? Jungejunge.
Harald K. schrieb: > Woher kommt nur die Neigung mancher Zeitgenossen, völlig willkürlich an > falsche Stellen Kommata in ihre Sätze einzubauen? Woher kommt nur die Neigung mancher Zeitgenossen, völlig willkürlich Formfragen für viel wichtiger als den Inhalt zu nehmen? Jungejunge.
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 ?)
:
Bearbeitet durch User
Reiner D. schrieb: > 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++?
Und vor allem hat Python eine automatische Speicherverwaltung. Bei den paar kB eines AVR wird man mit der garbage collection nicht glücklich.
Reiner D. schrieb: > 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.
Wilhelm M. schrieb: >> 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 ?)
:
Bearbeitet durch User
Reiner D. schrieb: > 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.
Sachen gibt's ... aber gewisse Kombinationen gehen nicht, zB das waere dann Interpreter, Objektorientierung und Echtzeit.
Peter D. schrieb: > Wenigstens war das Basic schon im ROM. Stimmt, und den Compiler mußte man erst von der Datasette reinjodeln. Man hat sich gefühlt wie James Bond ;-)
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 ? Wilhelm M. schrieb: > Reiner D. schrieb: >> //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?
Reiner D. schrieb: > (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.
Reiner D. schrieb: > 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?
MaWin O. schrieb: > Reiner D. schrieb: >> (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 ;-)
Was sind das denn für Windenmotoren? Die N20-Getriebemotörchen? Die kenne ich nur mit Hallgebern.
Wilhelm M. schrieb: > Du lässt Deinen System-Tick-Timer (Timer1) mit 1ms laufen, und leitest > davon alle Intervalle ab. Aber Scheduler und Inkrementgeber sind doch asynchron. Würdest du also lostickern, dann : - bei externem Ereignis Wert speichern und beim Nächsten dann vergleichen ? - bei 100 resetten und Scheduling initiieren ? Geht nicht, weil wegen asynchron der Counter beim externen Klick sporadisch überläuft, oder ?
Angehängte Dateien:
-
winden.jpg
110 KB
Wilhelm M. schrieb: > Was sind das denn für Windenmotoren? > Die N20-Getriebemotörchen? Die kenne ich nur mit Hallgebern. Die billigen Dinger aus den kleine Arduino-Wägelchen. Davon hab ich massig rumliegen. Man sieht auch die Inkrementgeber an den Winden.
Reiner D. schrieb: > Wilhelm M. schrieb: >> 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.
Wilhelm M. schrieb: > 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.
Reiner D. schrieb: > Wilhelm M. schrieb: >> 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.
Wilhelm M. schrieb: > Reiner D. schrieb: >> Man sieht auch die Inkrementgeber an den Winden. > > Da kann ich nix erkennen 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.
Wilhelm M. schrieb: > 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.
Reiner D. schrieb: > Wilhelm M. schrieb: >> 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.
Reiner D. schrieb: > Wilhelm M. schrieb: >> Reiner D. schrieb: >>> Man sieht auch die Inkrementgeber an den Winden. >> >> Da kann ich nix erkennen > > 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. Wie gesagt: Abtasten!
Etwas verwandtes: Es gibt eine Java VM für AVR, die habe ich auf einem Lego NXT Computer verwendet. http://www.harbaum.org/till/nanovm/index.shtml
Die optischen Encoder zB in Druckern sind komplexe Chips, da prellt nix, die hell/dunkel Übergänge sind am Ausgang der Encoder digital.
Stefan F. schrieb: > Etwas verwandtes: Es gibt eine Java VM für AVR, die habe ich auf einem > Lego NXT Computer verwendet. > > http://www.harbaum.org/till/nanovm/index.shtml 512 Bytes Java-Bytecode
Wilhelm M. schrieb: > 512 Bytes Java-Bytecode Hast du da etwas missverstanden? "The complete 512 Byte EEPROM space of the CPU are available as Java program space" Vom uralten ATmega 8, dem kleinsten dafür geeigneten Mikrocontroller.
Stefan F. schrieb: > Wilhelm M. schrieb: >> 512 Bytes Java-Bytecode > > Hast du da etwas missverstanden? > > "The complete 512 Byte EEPROM space of the CPU are available as Java > program space" Was sollte ich denn missverstanden haben?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.