Timm Thaler hat geschrieben: Mo 10. Mai 2021, 23:40
Btw: Bei Mikrocontroller.net werden regelmäßig Leute zusammengefaltet, die Drehgeber mit Interrupt auslesen wollen.
Stimmt. der überhebliche Ton den dort manche Member anschlagen nervt. Warum die Mods das Anflegeln von Einsteigern ins Thema akzeptieren ist mir schleierhaft. Ich nehms in Kauf, immerhin bekomme ich dort meistens irgendwann auch sehr gute Infos - seltsamerweise aber meistens eben gerade nicht von den Leuten die sich so oberlehrerhaft geben. Jeder beginnt bei jedem Thema mal als Anfänger, und hat Anfängerfragen, das ist keine Schande.
Bisher schalte ich ebenfalls Arduino Nanos vor, ich lese damit z.B. Messuhren aus
https://forum.zerspanungsbude.net/viewt ... 2&start=10. Das Lazarus Programm das ich da auch eingestellt habe läuft auf WIndows und Linux (Raspi). Die China-Teile - und das trifft auch auf die billigen Lineargeber zu (Siehe Shahe DRO Linear Scales, IGaging, EZ-DRO, Accuremote und Konsorten) liefern tatsächlich kein SPI oder RS-232 oder I²2, einfach nur blank Clock und Data. Es war übrigens mein Einstiegsprojekt ins Thema Multithreading mit Lazarus, und es mag eventuell gefinkeltere Lösungen geben, aber immerhin funktioniert es produktiv - man kann sogar die Messuhren im Lauf ab- und anstecken, so schlecht kann es also nicht sein. ENtwickelt zu 100% auf WIndows (wegen der besseren Anlage), debuggt und eingesetzt auf Linux. Hier sehe ich einen großen Vorteil für Lazarus, vielleicht sogar den *einzigen" Killer-Vorteil den Lazarus noch hat.
Das Thema mit den Interrupts kenne ich, wage aber leise zu zweifeln, und würde das nie öffentlich äußern, sonst gibt es wieder Haue von den Oberlehrern. Der Raspi 3 und seine Nachfolger haben 4 Cores. Für die Anwendungen, die ich im Auge habe, laufen dann einige Hintergrundprozesse und mein Lazarus Programm (das die Raspi-GUI zu 100% ersetzt, die ist also auch nicht aktiv), Das sollte doch reichen um Interrupts zeitnah zu bedienen, zumal es dann nicht passieren kann dass ein User probiert, parallel Videos zu codieren, im Internet rumzuhängen oder mit LibreOffice Briefe zu schreiben. Das Argument, man könne mit einer ISR einen Bitwechsel auch "versäumen", nun ja, das gilt für Polling genaus wenn nicht sogar noch mehr, und man wird sehen. In meiner (veralteten) Welt sperrt eine ISR andere Interrupts und damit m.E. auch das Multitasking bis sie abgearbeitet ist, das Auslesen erfolgt also mehr oder weniger unmittelbar nach dem Auslösen des Interrupts. Vielleicht geht dadurch die Systemuhr ein wenig nach - na und? Eher kitzlig (gedanklich): was wenn zwei Messgeräte gleichzeitig senden? Gibt es eine Queue so dass jeder Interrupt mal drankommt, oder fallen, wenn eine ISR getriggert wurde, alle anderen Interrupts ins Nichts?
Sobald mir jemand verraten hat, ob, und wenn ja wie man mit Lazarus eine ISR einhängen kann (Socke? Hast Du da einen Lösungsansatz?), probiere ich aus, ob die Bedenkenträger *immer* Recht hatten, oder ob es einfach nur ein paar Randbereiche gibt, in denen Interruptsteuerung tatsächlich nicht funktioniert. Mich überzeugen die Bedenken erst mal nicht hundertprozentig: da ist die Rede von prellenden mechanischen Gebern (die Hallsensoren waren grad aus?) oder supermepfindlichen Dingens die durch Vibration zu Geben beginnen. Hm. Das sind nicht unbedingt alltägliche Rahmenbedingungen, man könnte auch versucht sein, andere Geber einzusetzen.
Mir gehts übrigens nicht mal unbedingt darum, wegen 5 Euro Arduinos wegzurationalisieren. Platz ist ein Argument, und es wird bei den USB Anschlüssen am Raspi schnell eng: 1 für Maus und Tastatur, 1 für Touchscreen, einer für USB Stick zur Datenspeicherung, einer für die Messuhr, und schon sind sie weg. Klar gibt es Hub-Hats, aber da wären doch noch eine Batterie ungenützte GPIO Pins ... da kommt man schon auf die Idee sie nützen zu wollen.
Arduinos davorschalten kann ich immer noch

4 hab ich schon mal anghängt:
https://www.reichelt.de/raspberry-pi-us ... qVEALw_wcB, und kein Problem gehabt - wobei die Messuhren natürlich im Unterschied zu Weggebern sehr "harmlose" weil eher seltene und sicher prellfreie Signale senden.
Armin.