Hallo Marko,
Zitat
Gleichzeitig wollen wir ne Auslese- und Loggingfrequenz von 1Hz haben vom RaspPi, wobei diese weil ja n OS drauf läuft nur relativ präzise realisierbar sein wird, bin da selber schon gespannt.
Ja und nein, der RaspPi kann hier 'nix' garantieren ohne irgend etwas im Treiber (Kernelspace) zu machen.
Den Messtakt MUSS der Controller machen.
Der RaspPi kann z.B. bei Schreiben auf DISK mehrere Sekunden im Userspace blockieren.
Außerdem gibt es auf dem BUS Signal Laufzeiten ...
Also RaspPi sammelt 'nur' die Daten vom Bus und schreibt die Weg.
Wann wie viele Daten er bekommt schwankt viel zu stark.
Er muss sich hier auf die sekündliche Lieferung vom Controller verlassen, ggf. werden die Daten gequeued.
Anfänglich ist eine Synchronisation zu absoluten Zeiten (von der Echtzeituhr) erforderlich.
Wenn der Controller nicht exakt die absolute Sekunde einhalten kann,
wird auch zur Laufzeit eine Anpassung an die absolut Zeiten nötig sein.
Ich würde meinen, dass man so die absolute Zeiten +- 2 Sekunden genau halten kann.
Zitat
Allerdings kann die Drehzahl bei der Windmessung mitunter unter 1 Hz sein
Ja, kann sein, dann gibt es aber auch keinen Wind, zumindest keinen, der Energie genug hätte.
Es wird schwierig, das Lösen zu wollen, falls ja, müsste der Controller
a) Dynamisch, seine Update Rate bestimmen
b) Bei den Messwerten einen eigen (32 Bit) Zeitstempel mit liefern
c) Die Auswerte Software solche dynamischen Update Intervalle berücksichtigen
d) auch der (32 Bit) Zeitstempel läuft irgendwann über, das gilt es korrekt auf dem PI zu behandeln.
Lohnt sich dieser Aufwand für kaum Wind?
Alternativ kann der Controller zusätzlich zum 1 Sekunden (Mittel) alle 10 Sekunden auch z.B. ein 10 Sekunden Mittel liefern.
Hier wären dann Frequenzen von 0.1 Hz mit aufführbar. Wobei dann 16 Bit zur Darstellung nicht ausreichen, aber das wäre wohl verschmerzbar ...
Zitat
der Messwert steht aber in jedem Fall dann als quasi Zählwert a x Mikrosekunden zur Weiterverarbeitung im RasPi dann an
Ja, geht, muss aber nicht, der Controller könnte die schon gemittelte Periodendauer liefern, müsste jedoch dafür eine 16 Bit Division machen, was 'teuer' ist. Also count und summierte Periodendauer sind OK wie ich finde, den Rest macht der PI, klingt vernünftig.
Zitat
Von der Verarbeitung her wären die reinen Timerwerte von der Programmierung her ideal, weil eben 16 Bit, das geht flott von der Hand sozusagen
Ja, klar, im Controller so simple wie möglich, und so aufwändig wie nötig. Einfach binär hoch schubsen.
Zitat
der nächstegelegene Baudratenquarz wäre 14,7456 MHz
Das funktioniert genauso, wird halt was krummer auf dem PI zum umrechnen,
es gibt aber bestimmt 'nen vernünftigen Bruch, so dann man kein Float verwenden muss oder?
Mir ist was eingefallen, eigentlich ist kein externer 16 Bit Timer erforderlich.
Wenn man den Ausgang vom prescaler (1024) direkt an ein IRQ vom Controller anbringt
wird man alle 1024 Takzyklen, also dann mit einer Frequenz von 14,7456 KHz 'geweckt'.
Im IRQ dann ein 32Bit increment auf eine Adresse im Ram,
Fertig ist ein 32Bit Software Timer (die untersten 16 Bit laufen mit 14,7456 KHz oder so über).
Was meinst du?
Zitat
Ja, die RTC kann in Hardware nen Takt liefern, ich meine es wäre 1Hz als Pin ausgeführt.
Macht es Sinn, das auch als IRQ an den Controller zu binden?
Und das IRQ als Event zum Hochschubsen der Messwerte Richtung PI zu nutzen?
Damit geht man doch einigen Problemen aus dem Weg,
z.B. entfällt eine Zeitsynchronisation währen der Laufzeit zwischen Controller und PI.
Um die gelieferten Daten immer recht genau absoluten Zeiten zuzuordnen.
Wie viele IRQ's hat denn so ein Controller
Zitat
hängt damit zusammen, dass ich mir vor Ewigkeiten mit dem C64-Handbuch damals selber das Programmieren beibrachte
Good old times, da kenne ich noch was von
Tja Lehrer gab es damals keine die sich damit aus kannten, zumindest keine in meiner Nähe ...
Ich habe auch die ersten Schritte in Basic und nachher Assembler auf der Brotkiste gelernt
Achso, stimmt, ich habe auch Grundkenntnisse in ASM, mache einfach zu wenig mittlerweile damit.
Hin und wieder ASM lesen, wenn der c Layer 'esotherisch' wird hihi, ASM ist dann zweifelsfrei die gute Seite der Macht.
@Uwe
So wie ich es verstehe, bekommt die Lösung mit dem PI 'Probleme' wenn die Sekunden Daten mehrere Jahre vorgehalten werden sollen.
Mal sehen wo das Ganze dann tatsächlich landet, aber im Moment spricht nichts dagegen die Daten
mindestens ein Jahr lang zu halten.
Für die gemittelten Daten könntest du ja mal ein paar Vorgaben machen,
Es geht um möglichst einheitliche und einfach vergleichbare Werte, was also üblich und praktikabel ist ..
1 s
1 min
1 h?
24 h?
7 Tage?
1 Monat?
1 Jahr?
Gruss Frank