Hallo liebe Forumgemeinde, da ich im AVR Bereich noch am Anfang stehe, würde ich mich über "gute Praxis" Kommentare freuen: Chip: ATMEGA 8 Bsp: Nehmen wir an, ich will 4 langsame Sensoren auslesen (z.B. dht 22) Das Lesen dauert (weil man viel Warten muss) ca. 50ms Wenn jeder Sensor 1x Sekunde ausgelesen wird, dann sind das 200ms "warten", was dem Rest des Programms nicht gut tut. Was sind gute Lösungen? a) Über externe Interrups arbeiten - mit einem Multiplexer (weil nicht genug Interrups) b) Einen ATINY88 (etc.) dafür nutzen und z.B. via I2C einbinden c) Das Warten irgendwie besser machen Vielen Dank Tom
Und weil es unserer Katze wieder besser geht und ich gut drauf bin, gibt es sogar einen Lösungsansatz von mir: Timerinterrupts
Tom schrieb: > Wenn jeder Sensor 1x Sekunde ausgelesen wird, dann sind das 200ms > "warten", was dem Rest des Programms nicht gut tut. Wozu willst du einen Feuchtesensor ein mal pro Sekunde auslesen. Schon der gesunde Menschenverstand sollte einem sagen, dass das bei der Zeitkonstante des Sensorelements extrem wenig Erkenntnisgewinn bringt.
Natürlich ist auch das zu schnelle zyklische Auslesen nicht gut, auch weil sich die meisten Sensoren dabei selber erwärmen und das Ergebnis verfälschen. Es geht aber wohl eher um das delay das man sich einhandelt und damit evtl. andere Aktionen blockiert. Das liegt aber eher an den faulen Programmierern die eine einfache sensor.read() Methode bauen die blockierend arbeitet. Wenn man sich ansieht wie der Sensor arbeitet kann man in trigger / auslesen auftrennen. Dann kann man alle Sensoren erstmal triggern, was anderes machen, und nach x ms dann das Ergebnis abholen.
wie wäre es eigentlich, wenn wir statt des Bewertungssystems mal Preise für die dümmsten Antworten vergeben würden, und die Zahl rechts im Post dann immer anzeigt, wie viel dieser dummen Preise der USer bereits ergattert hat? Das gilt auch dann wenn man Fragen im Stil von Jeopady beantwortet Derzeit eine brauchbare Antwort..auch wenn ich nicht gut im erklären bin, versuche ich es auch mal. Mit Timern zu Arbeiten ist hier ein guter Ansatz entweder mit Timer Interrupt oder eben ohne. Du zählst eine Variable hoch, bei jedem Programmdurchlauf erhöhst du diese um 1 Stößt die Messung des Sensors an und gleich danach
1 | If counter >= 1000 THEN |
2 | Begin |
3 | Counter :=0; |
4 | readcounter := counterwert; |
5 | end; |
Tom schrieb: > Nehmen wir an, ich will 4 langsame Sensoren auslesen (z.B. dht 22) > Das Lesen dauert (weil man viel Warten muss) ca. 50ms > Wenn jeder Sensor 1x Sekunde ausgelesen wird, dann sind das 200ms > "warten", was dem Rest des Programms nicht gut tut. Warum? Was macht denn der Rest des Programms? Und wie kommst du auf 50ms? Ein Bit vom DHT22 braucht ~70µs (0) oder ~120µs (1). Für 32 Bits also im Mittel um die 3ms. Noch ein bißchen was drumherum und großzügig aufgerundet also vielleicht 5ms. Das sind dann 0.5% des 1-Sekunden Zeitintervalls. Also: was macht dein Programm so wichtiges, daß es keine 0.5% der Rechenleistung pro Sensor erübrigen kann? > Was sind gute Lösungen? Man kann das Problem natürlich mit Hardware totwerfen. Die unterschiedlichen Pulslängen vom DHT22 kann man mit einem Monoflop unterscheiden und die 0en und 1en in ein externes Schieberegister takten. Das muß der µC dann nur noch auslesen. Eine Variante davon ist ein Slave-µC, der mit dem DHT22 redet und dem Master Klartext-Daten z.B. via I²C liefert. Man könnte das Telegramm des DHT22 im Timerinterrupt samplen. Die kürzeste Zeit ist um die 20µs. Man müßte also mit wenigstens 20µs abtasten, besser aber mit 10µs. Bei angenommenen 8MHz Takt wäre das ein Interrupt alle 80 Takte. Knapp, aber machbar. Oder man verwendet die Capture-Hardware zur Erfassung der Flanken. Dann wird die ISR nur noch alle ~160 Takte aufgerufen. Beide Varianten sparen etwas Zeit gegenüber stumpfem Warten. Aber nicht wahnsinnig viel. Vielleicht die Hälfte. Oder man liest mal quer im Web und stellt fest, daß der DHT22 sowieso nicht das Gelbe vom Ei ist. Und entscheidet sich für einen anderen Sensor. Z.B. einen mit I²C Interface.
Tom schrieb: > Nehmen wir an, ich will 4 langsame Sensoren auslesen (z.B. dht 22) > Das Lesen dauert (weil man viel Warten muss) ca. 50ms Nein. Das Lesen selbst dauert weniger als 5ms, selbst bei lauter einsen (was ja nie der Fall sein kann). Bei DHT11 dauert das Startsignal min.18ms., bei DHT22 weniger als 1ms, ergibt 23ms bei DHT11 and 6ms bei DHT22. > Wenn jeder Sensor 1x Sekunde ausgelesen wird, dann sind das 200ms > "warten", was dem Rest des Programms nicht gut tut. Niemand liest die Sensoren 1 pro Sekunde, wozu auch? Bei DHT22 ist die max. Auslesefrequenz sogar nur 0.5Hz, also max. alle 2 Sekunden. Aber egal: Für 4 DHT22 Sensoren dauert das Ganze max.24ms. Für 4 DHT11 Sensoren dauert das Ganze max. 44ms (wenn man weisst wie). Wie du auf deine Zahlen gekommen bist, ist mir schleierhaft... P.S. Axel S. schrieb: > Oder man liest mal quer im Web und stellt fest, daß der DHT22 sowieso > nicht das Gelbe vom Ei ist. Und entscheidet sich für einen anderen > Sensor. Z.B. einen mit I²C Interface. Oder man nimmt einen M88 und arbeitet mit PCINT und TIMER, kostet (fast) keine CPU Zeit...
:
Bearbeitet durch User
Tom schrieb: > c) Das Warten irgendwie besser machen Richtig, mit Multitasking. Das gilt für fast alle langsamen Sensoren, auch z.B. die Temperatursensoren DS18x20. Ist einfacher als es klingt.
Multitasking??? - Ich lach mich kaputt! Warum nicht gleich Kavallerie, Coast-Guard und Force de Frappe? Hier braucht man einen freilaufenden Zähler mit passender Taktung und einen Pin-Change-Interrupt. Kostet 1..5% der Prozessor-Zeit und - JA LEIDER, GEHT NICHT OHNE: etwas Gehirnschmalz für die Pin-Change-Interrupt-Routine.
wofür man für so eine Aktion immer einen Interrupt verwendet erschließt sich mir hier nicht... Ein freilaufender Zähler ist hier mehr als ausreichend. Wer für bereits so einem Pillepalle einen Interrupt verwendet, murkst sich vermutlich auch sonst ziemlich einen zusammen
Jakob schrieb: > Multitasking??? - Ich lach mich kaputt! > Warum nicht gleich Kavallerie, Coast-Guard und Force de Frappe? > > Hier braucht man einen freilaufenden Zähler mit passender Taktung > und einen Pin-Change-Interrupt. Kostet 1..5% der Prozessor-Zeit > und - JA LEIDER, GEHT NICHT OHNE: etwas Gehirnschmalz für die > Pin-Change-Interrupt-Routine. Wenn man sowieso ein RTOS verwendet?!
Axel Shirakowski schrieb: > Ein freilaufender Zähler ist hier mehr als ausreichend. Ein freilaufender Zähler alleine nützt überhaupt nichts. Irgendwie wird der mit der Ablaufsteuerung im Programm kommunizieren müssen.
Wer Labormessungen macht, nimmt bessere Technik. Wer ein Atiny + Arduino nutzt, macht das folgendermaßen. Man ruft eine Sub-Routine auf, in der werden 10 Messungen in einer Schleife durchgeführt. Die Ergebnisse zusammengezählt und durch 10 geteilt um den Mittelwert zu ermitteln. Dann zurück in die Hauptroutine und wenn man nix besseres zu tun hat, legt man den Chip schlafen. Nach x Minuten (10 ist kein schlechter Wert für Klimamessungen) ruft man den Sub erneut auf und das Spiel geht von vorne los. JEDE !!!! Wetterstadion für die Wohnung die ich kenne arbeitet so. Sonst wäre die 2032 / bzw. 2 x AAA in 1 Tag leer. Gruß Pucki
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.