Netzwerkprotokoll für RFM12

[markusj]

Du meinst also, dass ich ähnlich wie bei einer fehlerhaften Datenübertragung auch auf fehlerhafte Tokenübertragung mit direkter Sendewiederholung reagieren soll?
Was bringt mir das für Vorteile wenn die Unit direkt nochmal das Token bekommt anstatt erst in der nächsten Runde?

Nehmen wir Mal an, du brauchst jede Sekunde neue Daten. Wenn das "Token" bei einem Knoten nicht ankommt, wird er im besten Fall eine Sekunde später (bei der nächsten Iteration) regieren. Oder wenn irgendetwas die Verbindung stark verschlechtert, erst noch viel später. Dieser Aussetzer kann unter Umständen zu lange für deinen Anwendungszweck sein.

Ganz hab ich's sowiso noch nicht heraussen wie ich mein Programm schreiben muss, damit ich den kompletten Controller nicht sperre, wenn ich z.B. 3h FadeIn bei einer Halogenlampe machen will.

Ich glaube du möchtest dich Mal ein wenig in Richtung Multitasking auf µCs informieren. Solche einfachen zeitgesteuerten Aufgaben kann man relativ einfach über eine Warteschlange lösen, die in regelmäßigen Abständen (Timer!) gepollt wird. (Stichwort: Delta-Queue). Im Wesentlichen musst du dich einfach darauf einstellen, dass deine Funktionen nicht mehr blockierend warten, sondern sich ihren Zustand merken und dann andere Funktionen weiterrechnen lassen. Das nennt man kooperatives Multitasking.

mfG
Markus

[cd_brenner]

Nehmen wir Mal an, du brauchst jede Sekunde neue Daten. Wenn das "Token" bei einem Knoten nicht ankommt, wird er im besten Fall eine Sekunde später (bei der nächsten Iteration) regieren. Oder wenn irgendetwas die Verbindung stark verschlechtert, erst noch viel später. Dieser Aussetzer kann unter Umständen zu lange für deinen Anwendungszweck sein.

Okay - jetzt hab ichs. Ich bin zu optimistisch an die Sache rangegangen und hab gedacht, dass Sendefehler eh recht selten ist. Wenn eine von 20 Tokennachrichten schief geht wärs nicht so tragisch, wenn das Ergebnis erst 1sec später kommt. Aber offenbar ist Funk doch fehleranfälliger.

Das nennt man kooperatives Multitasking.

An sowas hab ich schon gedacht: Quasi immer ein Stückerl abarbeiten sodass die Main-While nicht zu lange unterbrochen ist. Ich denke, ich werde hier relativ oft Flags einsetzen müssen um eine längere Aufgabe wie "fade über 3h ein" zu koordinieren. So wird halt der PWM-Wert alle 20ms (50hz) erhöht - pro Schleifendurchlauf 1x.

http://stefanfrings.de/avr_io/protosockets.html

LG Markus

[markusj]

Okay - jetzt hab ichs. Ich bin zu optimistisch an die Sache rangegangen und hab gedacht, dass Sendefehler eh recht selten ist. Wenn eine von 20 Tokennachrichten schief geht wärs nicht so tragisch, wenn das Ergebnis erst 1sec später kommt. Aber offenbar ist Funk doch fehleranfälliger.

Muss nicht. Kann aber. Das hängt von deinem Funkmodul, dem Rauschen was sonst noch so in der Umgebung unterwegs ist, sowie der Umgebung selbst, ab. Wenn du einen der Knoten hinter eine Blechwand steckst, kommt halt wenig Pegel beim Empfänger an.
Worauf ich hinaus wollte: Es gibt eine (dir momentan unbekannte) Verlustwahrscheinlichkeit, du solltest das also berücksichtigen und Gegenmaßnahmen einplanen.

An sowas hab ich schon gedacht: Quasi immer ein Stückerl abarbeiten sodass die Main-While nicht zu lange unterbrochen ist. Ich denke, ich werde hier relativ oft Flags einsetzen müssen um eine längere Aufgabe wie "fade über 3h ein" zu koordinieren. So wird halt der PWM-Wert alle 20ms (50hz) erhöht - pro Schleifendurchlauf 1x.

Mal rein aus Neugierde: 3h alle 20ms ein Inkrement entspricht 19-Bit PWM. Mit welchem Mikrocontroller hast du so eine hohe PWM-Auflösung?! Mir ist kein 8-Bit AVR bekannt, der das bietet.
Und Flags ... naja, ich hätte eher an Zähler gedacht. Wie gesagt, sieh dir Mal die Delta-Queue an, das eignet sich perfekt für zeitgesteuertes Task-Management.

mfG
Markus

[cd_brenner]

Muss nicht. Kann aber. Das hängt von deinem Funkmodul, dem Rauschen was sonst noch so in der Umgebung unterwegs ist, sowie der Umgebung selbst, ab. Wenn du einen der Knoten hinter eine Blechwand steckst, kommt halt wenig Pegel beim Empfänger an.
Worauf ich hinaus wollte: Es gibt eine (dir momentan unbekannte) Verlustwahrscheinlichkeit, du solltest das also berücksichtigen und Gegenmaßnahmen einplanen.

Okay - danke für deine ausführliche Erklärung!

Mal rein aus Neugierde: 3h alle 20ms ein Inkrement entspricht 19-Bit PWM. Mit welchem Mikrocontroller hast du so eine hohe PWM-Auflösung?! Mir ist kein 8-Bit AVR bekannt, der das bietet.

Bei dieser Aussage hab ich das natürlich nicht bedacht - ist aber klar, dass die Auflösung bei so vielen Werten nicht mitspielt. Ich denke die PWM Frequenz muss sowiso an den entsprechenden Anwendungsfall angepasst werden. Bei LEDs würde ich diese höher wählen als bei recht trägen Halogenspots.

Frage am Rande: Welchen MOSFET kann ich für einen 20W Halogenspot mit 12V verwenden?

Ist es klug auf einem Microcontroller den Speicher für den FrameBuffer (Nachricht empfangen -> Buffer schreiben -> Tokenweitergabe -> Buffer lesen -> Nachricht senden) dynamisch zu allokieren (malloc) - denn es ist effektiver wenn der Buffer nicht wie ein FIFO funktioniert, sondern auch Frames "in der Mitte" aus dem Buffer lesen kann, oder?

Vielen Dank.

[markusj]

Frage am Rande: Welchen MOSFET kann ich für einen 20W Halogenspot mit 12V verwenden?

So ziemlich jeder Leistungs-MOSTFET wird sich da langweilen. Nimm den günstigsten n-MOS der 2,5A oder mehr ab kann und einen niedrigen RDS_on bei Logikpegeln (5V) hat. Günstig zu haben ist zum Beispiel der IRLZ24, mit einem RDS_on von 0,1Ohm macht das eine Verlustleistung von nur 0,17W bei den 20W/12V=1,7V die da fließen.
Ach ja: Die Lampe wird mit Gleichspannung betrieben, oder? Normale MOSFETs können keine Wechselspannung schalten.

Ist es klug auf einem Microcontroller den Speicher für den FrameBuffer (Nachricht empfangen -> Buffer schreiben -> Tokenweitergabe -> Buffer lesen -> Nachricht senden) dynamisch zu allokieren (malloc) - denn es ist effektiver wenn der Buffer nicht wie ein FIFO funktioniert, sondern auch Frames "in der Mitte" aus dem Buffer lesen kann, oder?

Dynamische Speicherallokation auf Mikrocontrollern ist normalerweise eine schlechte Idee. Langsam, benötigt größere Mengen Flash für die Speicherverwaltung und ist anfällig für Speicherfragmentierung.

Was du mit dem zweiten Teil der Frage meinst, erschließt sich mir leider nicht.

mfG
Markus

[cd_brenner]

Dynamische Speicherallokation auf Mikrocontrollern ist normalerweise eine schlechte Idee. Langsam, benötigt größere Mengen Flash für die Speicherverwaltung und ist anfällig für Speicherfragmentierung.

Also besser schon beim Compillieren den max. benötigten Speicher einplanen. Verstehe.

Was du mit dem zweiten Teil der Frage meinst, erschließt sich mir leider nicht.

Nun ja - aus einem FIFO kann ich ja nur den aktuell ältesten Datensatz (First Out) lesen. Ich möchte aber Frames nicht im Buffer lassen, nur weil es zur Zeit nicht an erster Position verfügbar ist, sondern möchte an beliebigen Stellen im Buffer zugreifen können. Das sollte aber mit einer verketteten Liste kein Problem sein, oder?

LG aus Graz.

[markusj]

Nun ja - aus einem FIFO kann ich ja nur den aktuell ältesten Datensatz (First Out) lesen. Ich möchte aber Frames nicht im Buffer lassen, nur weil es zur Zeit nicht an erster Position verfügbar ist, sondern möchte an beliebigen Stellen im Buffer zugreifen können. Das sollte aber mit einer verketteten Liste kein Problem sein, oder?

FIFOs sind dafür nicht geeignet, da liegst du richtig. Normalerweise parst man die Daten aus empfangenen Paketen raus und legt sie dann in geeigneten Datenstrukturen ab, wenn man sie für länger braucht. Insbesondere trennt man eigentlich den Netzwerkstack von der weiteren Datenverarbeitung, einfach der Modularisierung/Flexibilisierung wegen.

mfG
Markus