|
Anzeige
|
Grundsatzfrage zum BustransferIch habe mich ja nie damit beschäftigt und was ich bisher so gelesen hatte, wurde immer nur gewartet bis die Gegenstelle bereit ist und dann komplette Daten auf den Bus zum abholen gelegt. Jetzt fällt mir auf, dass zumindest der dht da ein zeitverschlüsseltes ein bit Protokoll verwendet. Das bedeutet, dass wenn das Timing nicht stimmt und man zwischendrin eine Pause macht, wieder von vorne anfangen muss. Wie löst ihr das?? Ich meine man braucht doch mindestens zwei ports, einer 0 oder 1 und der andere löst den Interrupt aus? Dann ist man doch zeittechnisch aus dem Schneider??
Öhhmm... Wir halten uns an das Protokoll des Herstellers, wenn wir damit erfolgreich sein wollen. Dann klappt das auch. Ohne Pause machen, ohne neu anfangen.
Und wie soll das gehen wenn die Uhrzeit über einen Interrupt kommt??
Das Protokoll richtig implementieren.
Das kein Protokoll, das ist eine Krankheit...
Schlafen und morgen meinen Swimmingpool weiterschaufeln.
Wenn es Dich stört und nicht programmieren kannst, nimm einen anderen Sensor. Zum Glück gibt es ja nicht nur den einen.
Wie soll die Uhrzeit über einen Interupt kommen. Darüber kann nur eine Unterbrechungsanforderung kommen. Die Daten für Stunden/Minuten/Sekunden müssen immer als Daten übertragen werden.
Wie soll die Uhrzeit über einen Interrupt kommen. Darüber kann nur eine Unterbrechungsanforderung kommen. Die Werte für Stunden/Minuten/Sekunden müssen immer als Daten übertragen werden.
Das passiert, wenn man für zeitkritische Dinge den IRQ nicht abschalten kann. ;-) Funktioniert hier zuverlässig, bin mit dem Schienenersatzverkehr (Bus) unterwegs! Der nächste Bus kommt Donnerstag. Beim CAN-Bus darf jeder zu jeder Zeit senden. Vielleicht solltest Du erstmal sagen, an welchen Bus Du gerade denkst.
da der dht aber keine ganze Sekunde braucht, kannst du nach dem Interrupt das abfragen. Moin, Matthias schrieb im Beitrag #7681158:
Scheint mir eines der wenigen vernuenftigen Vorhaben von dir. Jeder sollte das machen, was er am besten kann. scnr, WK Bus-Transfer hatte ich grad vom Flughafen zum Hotel
Wie hieß es doch in Caddyshack, "Well, the world needs ditch diggers, too." https://www.youtube.com/watch?v=eiRGRvE_Wqg Ich hab immer noch keine Lösung... Wenn ich die Interrupt abschalte, werden die anderen Übertragungen gestört und wenn ich die an lasse, bekomme ich keine 100 %ig sichere Übertragung hin? Vllt. den Interrupt vom Taskwechsel abschalten, da der ja recht lange dauert und die restlichen eben probieren und bei einem Fehler neu starten? Oder findet die Übertragung grundsätzlich nur nach Aufforderung statt und ich kann theoretisch DHT, RS485, CAN und Ethernet nacheinander abarbeiten (also Interrupt abschalten, eine Schnittstelle abfragen, Antwort einlesen und Interrupt wieder anschalten)?
Was ja? Ich müsste das schon wissen, damit ich jetzt nicht mit den Modulen anfange um dann festzustellen, dass das sequentielle abarbeiten nicht möglich ist... Der Can-Controller hat scheinbar einen eigenen Puffer, müsste also klappen. RS485 hat ja keinen Controller, da wird man die Daten schon direkt einlesen müssen, ohne die Interrupt abzuschalten, wenn man alle Werte haben will?
Vielleicht hast du keine Busfahrkarte gelöst? SCNR Scheiße, ihr wisst es selbst nicht 👻
Weil wir nicht wissen, was du weisst. Und deine Beschreibung macht uns auch nicht schlauer. Ausserdem: welcher Bus? Bahnbus, Postbus, Schienenbus, Omnibus. Zum Einlesen von DHT, RS485 und Ethernet braucht man keinen Bus.
Mei, mir hat halt beim dht11 ein serial.println beim einlesen, zwischen den Bits das Timing zerhauen und dann habe ich geschaut, warum...
Du hast mein volles Mitgefühl! Allerdings: Wundern tut mich das nicht!
Du weißt "Warum?" Dir sind sogar die möglichen Abhilfen bekannt. Und zwar: Solange du keinen 2ten Core nutzt, wirst du die Interrupts abschalten müssen.
kommt darauf an, ich kann mich gerade nicht in deine Config einarbeiten, aber ich fand für mich am AVR eine Lösung für IRMP gibt es alle 64µs einen IRQ, der sammelt die IR Bits, dauer im µs Bereich. für Pedas Tasten Entprellroutine gibt es einen 10ms Timer IRQ da im IRQ kein weiterer IRQ zugelassen ist könnte man im 10ms Timer IRQ für die Tastenentprellung ein IR Interrupt verpassen, also setzte ich ein Flag, eine Variable Bin_im_10ms_Timer_IRQ und gebe die IRQ für IR wieder frei mit sei(), wenn nun der nächste IR int kommt weiss ich ob ich im 10ms Timer IRQ bin oder nicht und muss entsprechend verzweigen/reagieren. Bin ich noch im 10ms Timer IRQ mache nichts ist der Timer 10ms abgearbeitet, also am Ende sperre ich für den IR int mit cli() wieder und verlasse den 10ms timer tasten IRQ. Das könnte auch bei dir funktionieren, aber die typischen IR senden Codes ja öfter so daß ein Bitausfall im IR nicht auffällt. Ich kenne deine Aufgabe ja nicht. Ist der Pool schon fertig geschaufelt oder glaubst du, der schaufelt sich von alleine? scnr, WK
Das blockiert zwangsweise mindestens für 8 Bit jeglichen Interrupt. Wenn jetzt von zwei solchen Teilen gleichzeitig Daten kommen, z. B. WR und Stromzähler, was passiert dann? Kann sein, dass ich mich jetzt als Vollhorst oute, aber da kommt der Interrupt und dann ist das Signal sofort auf 8 Bit abzutasten, oder man hat einen Übertragungsfehler... Und dann noch sowas, damit ich weiß, ob die Batterie es nicht evtl. kalt hat:
Ich probiere es ja, aber ob das zuverlässig läuft?? Also um genau zu sein, kommen die Daten für die Steuerung des Mistvieh mindestens von 3 x modbus und 2 x canbus:
Warum nimmt man für so ein Projekt den kleinstmöglichen Mikrocontroller und kämpft dann monatelang erfolglos mit rtos-Entwicklung, nicht vorhandener Rechenleistung, zu wenig Ressourcen und fehlendem Multitasking? Ausgeprägter Hang zu Masochismus? Wenn man die Shields zusammenstecken kann, geht man halt davon aus, dass das dann auch läuft und nicht ständig abstürzt... Kann ja keiner wissen, dass das Teil mit zwei Erweiterungsplatinen schon die Grätsche macht 🤔 Wahrscheinlich kann man die Erweiterungsplatinen auch an anderen Boards betreiben. Ich befürchte halt dass man sich dann wieder ewig in die Eigenheiten einarbeiten muss... Mal schauen, was daraus wird. Die Autobahnen sind ja auch ewig in der Schublade verstaubt! Jaja, Mr. "ich mach's möglichst umständlich" jammert mal wieder. Solchen Leuten ist nicht zu helfen. Der Rest der Welt findet eine pragmatische Lösung. Beitrag "ATmega328P Funktionsadresse in Register speichern und aufrufen"
Nein. Typisch hat man für RS485, CAN und Ethernet usw. einen Controller im MC, der die Daten puffert. Z.B. bei der UART im AVR werden bis zu 3 Bytes gepuffert, d.h. man hat 30 Bitlängen Zeit, in den Interrupt zu springen und die Daten in einem FIFO abzuspeichern. Es bleibt also genug Zeit, um andere Interfaces zu behandeln, ohne das es Konflikte gibt. Die Daten parst man dann bequem in der Mainloop. Etwas tricky wird es bei Sonderformaten, für die es keine Controllereinheit im µC gibt und die man mit Bitwackeln nachbilden muß. Da bietet es sich an, mit Interruptprioritäten zu arbeiten, d.h. die Interfaces mit Controller auf geringere Priorität zu setzen. Oder falls das nicht geht, die Interrupts in deren Handler frühzeitig wieder freizugeben. Wie man z.B. 1-Wire mit Interrupts behandelt, findest Du in der Codesammlung. Ein RTOS macht die gleichzeitige Benutzung mehrerer Interfaces deutlich komplizierter und zehrt vor allem stark an den Ressourcen der CPU. Daher ein RTOS nur mit Bedacht und viel Erfahrung benutzen. Wie heißt es doch so schön: Mit Linux wäre das nicht passiert! Übersetzt für dein Projekt: Mit einem Raspi wärst du längst fertig.
Bei einer Funktion, die so heißt, klingeln bei mir sämtliche Alarmglocken. Diese Implementationen sind wirklich nur für sehr eingeschränkte Anwendungen gedacht. Oft sind sie auch blockierend geschrieben und nicht über Interrupts. Für sinnvolles Programmieren sollte man schon die entsprechenden Controllereinheiten im µC benutzen und nicht alles in Software nachbilden. Es gibt natürlich auch UART-Implementationen mit Interrupts in Software, nur muß man dann auch deren Anforderungen an die anderen Tasks beachten. Unbekümmert nur Legosteinchen übereinander stapeln, geht dann nicht mehr. in Japan freuen sie sich wenn die Busfahrer streiken https://www.youtube.com/shorts/7BfdRDl9jFg?feature=share
Danke für den Denkanstoß, der Arduino Mega hat scheinbar 4 Hardware UART (der Uno nur einen). Damit müsste es gehen, ohne sich selbst ein nicht funktionsfähiges Software serial hinzufrickeln was dann doch nicht fehlerfrei läuft!! Für was ist eigentlich das SoftwareSerial, wenn es eh nur verbuggt läuft??
Wer behauptet sowas? Auf die Streckbank mit dem pösen Puben.
Der ist auch, aus meiner Sicht, sehr gut geeignet sich überhaupt einmal mit dem Bussystemen zu beschäftigen und daran zu lernen. So richtig hatte ich das damals aber auch erst verstanden, als ich mit nem LA dann das gesehen habe, was im Datenblatt steht.
Ich würde auch sagen, für die, die nur Legosteinchen stapeln wollen, ist es ungeeignet. Für schnell mal eben Testaus-/Eingaben zu zimmern, geht es durchaus. Jedes Werkzeug hat seine Vor- und Nachteile. Wer die Nachteile nicht verstehen möchte, sollte es nicht benutzen.
Du bist halt voll in die Arduino-Falle getappt. Die besteht darin dass man jedem Noob glaubhaft macht dass man nichts können oder wissen muss um per Copy-Paste embedded Software zu schreiben. Ist halt nicht so. Ahnung haben hilft. Echt, ungelogen. Ansonsten wird das wie immer Lernen durch Schmerzen. Da du dich jedoch wenig einsichtig zeigst funktioniert das mit dem Lernen noch nicht so. Es gibt Berufszweige, in denen komplette Inkompetenz sich jahrzehntelang durch selbstbewusstes Auftreten kompensieren lässt. Softwareentwicklung gehört nicht dazu.
Falls Du damit die Feuchtesensoren meinst, das ist eigentlich nicht schwer. Eine Bitzeit dauert 76..120µs. Beim AVR @16MHz hat man also >1200 Zyklen Zeit für andere Interrupts. Wenn man da nicht zu verschwenderisch ist, läßt sich das bequem wuppen. Wie gesagt, das länger dauernde Parsen macht man eh in der Mainloop. Da die Information in der Bitzeit liegt, bietet sich der Capture-Interrupt geradezu an. Das Einlesen erfolgt also per Interrupt im Hintergrund, ohne andere Tasks zu stören. Leider findet man kaum konkrete Codebeispiele, sondern immer nur die Benutzung fertiger Libs. Ich habe daher keine Ahnung, wie gut deren Qualität ist, d.h. wie sauber die programmiert wurden. In einem Artikel habe ich gelesen, daß die DHT22 gerne mal abstürzen und dann ein Power-Off benötigen. Das läßt nichts gutes ahnen. Ich vermute daher Probleme in dieser verwendeten Lib. Wie gesagt, es mit dem Capture-Interrupt auf dem AVR selber zu implementieren, stelle ich mir einfach vor. Zum Test würde ich zuerst mal alle 41 Capture-Werte im SRAM ablegen und per UART ausgeben (SW-Serial ginge dazu auch). 120 us * 40 Bit müssten 4,8 ms sein. Modbus hat, was ich so gelesen habe, scheinbar 19.200 bit/s, also 52,1 us pro Bit und 0,416 ms pro Byte. Es können also 11,5 Byte über modbus eintrudeln, während ich da die Feuchtigkeit auslese. Wenn der UART-Puffer tatsächlich nur 3 Byte hat, wird es mit einem blockierenden DHT11-Treiber wahrscheinlich nicht zuverlässig laufen. Die Batterie hat aber einen eigenen Temperatursensor. Wahrscheinlich kann ich auf den DHT11 verzichten und habe dann nur noch Controller, die sich per Interrupt melden wenn was angekommen ist. Idiotensicher sozusagen... Warum hat das Teil eigentlich keinen eigenen Controller? Dabei habe ich das extra genommen um die ohne Löten komfortabel zusammenzustecken... https://www.reichelt.de/arduino-shield-rs485-7lb184-pcd-shd-rs485-p151978.html
Man sieht doch eindeutig, daß da nur ein SN75LBC184D bestückt ist und mehr nicht.
Das war nicht die Frage.
Weil der Rest der Welt den nicht braucht. Nur Experten wie du . . . So kompliziert ist Interrupt Programmierung nicht. Man muß sich erstmal Gedanken machen, welchen Teil erledigt der Interrupt und welchen das Main. Man muß also eine Vorstellung entwickeln, was kostet viel CPU-Zeit und was ist zeitkritisch und dann diese Teile im jeweiligen Kontext ausführen. Ansonsten stößt man schnell an die Grenzen der blockierenden Programmierung. Ein RTOS oder Multicore versucht im Prinzip das gleiche, nur wird da keine Intelligenz des Entwicklers benötigt. Die Trennung erfolgt also nicht logisch, sondern Brute Force mit einer Unmenge an Ressourcen.
Ist also im Prinzip bei gegebener Hardware nur ein sehr komplizierter Weg, denselben Zustand "geht nicht wegen Verstoß gegen timing constraints" zu erreichen. Also wenn schon aus Gründen von Dummheit oder Faulheit oder Kostendruck die Verwendung eines RTOS attraktiv erscheint, dann gleich einen deutlich potenteren Rechenknecht als Target einplanen. Lizenskosten für's RTOS und höhere Hardwarekosten können übrigens den Kostenvorteil bei der Entwicklung auch durchaus mal auffressen, wenn man nicht aufpasst. Hängt stark von der Stückzahl des Produkts ab. Je größer die ist, desto größer ist auch die Gefahr, dass es in der Gesamtbilanz ordentlich in's Minus geht.
Was Du alles so liest... Mit wäre es neu, dass Modbus (RTU) mit nur einer einzigen Baudrate betrieben wird. Und hast Du, insbesondere bei der Implementierung eines Modbus-Slaves, auch mal Gedanken über T35 usw. gemacht? Vermutlich nicht.
Einfach so, auch wenn Dein Microcontroller der Master sein sollte? Interessant zu wissen. War bisher niemandem bekannt.
Nein und ich habe jetzt auch nicht vor darüber eine Doktorarbeit zu schreiben. Mir reicht es, wenn die Solaranlage mit Batteriespeicher irgendwann zuverlässig läuft, ohne dass da tagelang ein Relais klackert bis ich die Batterie manuell vom Stromkreis trenne. So ein Relais hat nämlich nur ein paar 10 tausend Schaltzyklen, bevor es den Geist aufgibt. Danach habe ich auch noch andere Projekte in der Schublade die traurigerweise wegen Zeitmangel verstauben 😭
Nö, wegen deiner Unfähigkeit und mangelndem Pragmatismus. Du bläst Probleme auch, anstatt sie zu lösen. Aber Jammern ist ja modern. Ich habe ja schon nicht viel Ahnung und lese solche Sachen eigentlich um zu lernen. Wenn ich das hier vom TO lese, dann frage ich mich, wieso macht man das? Wieso nicht in kleinere Brocken aufteilen und erstmal eins zum Laufen bringen. Man kann auch alles auf eigene Controller realisieren und wenn das alles klappt, Stück für Stück das in eine Hardware zusammen fassen. Dem Mut würde ich Respekt zollen, aber ich glaube nicht, dass es der Mut an Aufgaben zu wachsen ist.
Nein, ich hab jetzt 6 Monate mit der Steuererklärung zugebracht, weil irgendeiner gerne einen Doktor hätte und es die scheinbar bei Steuergesetzen nur gibt, wenn man es noch schwerer macht. Jetzt hatte ich ein kleines Zeitfenster für die Steuerung der Solaranlage und muss jetzt eben mit höchster Priorität den Garten fertig machen, bevor es wieder kalt wird. Klar, kann man auch Tätigkeiten outsourcen, aber die IT wird halt teilweise sehr schlecht bezahlt. Gut, es gibt auch Ausnahmen, wo die einen nach eine Woche gekritzele mit Gold überhäufen. Das sind aber eher die Einwohner auf der anderen Seite der Mauer vom Gazastreifen. Ich warte ja noch immer auf das, was ich bestellt habe 😎 Ein Schwätzer vor dem Herrn!
Nö, das ist entweder Naivität, Selbstüberschätzung oder einfach dumme Trollerei. Oder alles zusammen. Wann kommt der Korrektiv Faktencheck mit den Kraft-Knausergreisen und dem pleitegegangen Steinkohleläufer?? Nicht, dass es mich stören würde, aber 0 sind halt 0.
Du hast echt einen an der Klatsche.
was hat das mit deinen fehlenden Programmierkenntnissen zu tun? So oft wie du hier postest könntest du auch ein klitze programmieren lernen, braucht man sowieso um die Aufgabe in kleine passende Häppchen zu zerlegen.
Der nun wohl vorläufig ruhegestellt wurde, und damit viel mehr Zeit hat, seine unterentwickelten Programmierkenntnisse seinem Trollfaktor anzunähern.
Angehängte Dateien:
Nicht wirklich. Der wird wohl innert kürzester Zeit unter einem anderen Account wieder auftauchen. Zumindest wenn er nicht völlig blöd und Trollen sein eigentliches Ziel ist. Aber: er hat genug Stoff für die Trolldetektor-KI hinterlassen. Wenn er wieder auftaucht, ist er auch schnell wiedererkannt. Genau so, wie sie seine vorherigen Inkarnationen erkannt hat. Weswegen ich auch ziemlich sicher bin, dass er bald wieder auftauchen wird. Notorische Trolle sind psychisch gestörte Personen, genau wie Serienmörder, bloß nicht ganz so gefährlich für das Gemeinwohl. Aber wie diese können sie nicht ablassen von ihrem Tun. Zumal hier keine ernsthafte Strafe droht. Was andererseits auch irgendwie OK ist, es entsteht ja niemandem ein Schaden. Jedenfalls nicht, wenn man nicht bereit ist, freiwillig etwas zu tun. Also dem Troll zu antworten und tatsächlich Geistesleistungen aufzuwenden, um eine kompetente Antwort zu geben. Der Aufwand ist umsonst, klar. Aber es ist kein Schaden im Sinne des BGB, da er freiwillig und ohne vorherige Vereinbarung einer Gegenleistung erbracht wurde.
Glaube nicht dass Trollen sein eigentliches Ziel war. Sonst hätte er nicht mit Links um sich geschmissen, die ihn mit 2-3 Mausklicks mit vollem Realnamen, vollständiger Adresse usw. "enttarnen". Ich denke es ist eher das, was ich oben geschrieben habe: Der hat
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
