- LiTime Speicher und Akkus         
Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 24

Thema: Netzwerkprotokoll für RFM12

  1. #11
    Benutzer Stammmitglied
    Registriert seit
    05.10.2012
    Beiträge
    33
    Anzeige

    Praxistest und DIY Projekte
    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.

  2. #12
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    20.08.2008
    Ort
    Karlsruhe
    Alter
    36
    Beiträge
    1.225
    Zitat Zitat von cd_brenner Beitrag anzeigen
    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
    Tiny ASURO Library: Thread und sf.net Seite

  3. #13
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    2.187
    Thema FET:

    Meine "Waffe" für solche Fälle ist der IRF3708.
    Hat schon bei 5V sehr geringen RDS On ( 12mOhm ).
    Genügend Reserven ( 63A ) - Bis 10A ohne Kühlkörper.
    Leicht erhältlich, Preislich OK.

    U-DS darf dabei allerdings 30V nicht überschreiten.

    Wenn's was im SO8 Gehäuse sein soll - Wie wär's mit dem IRF7455.
    Den verbau ich in kleineren Brushless Reglern. Ist aber etwas schwerer zu bekommen.

    Da eine Halogen Lampe einen sehr geringen Kalt Widerstand hat, würde ich den FET 10fach überdimensionieren - Deshalb solche Oschis von FET Typen.

    Die RFM12 Funk Module sind etwas Tricky, hast Du schon etwas Erfahrung mit den Bausteinen?

    Thema Puffer:
    Ich nehm für die Eingangs - Rohdaten gerne einen fixen Ringpuffer mit Schreib- und Lesezeigern.
    Das schafft für den empfangenden Controller etwas Zeit für die Abarbeitung und es sollten keine Bytes verloren gehen.
    Aus diesem Puffer kann man sich dann die Daten rausparsen und wieder Puffern oder in String Variablen oder struct's zur weiteren Verarbeitung ablegen.

    Wenn Du die Daten schon verschlüsseln willst, würde ich versuchen ein Protokoll zu nehmen, das auch zumindest eine Einzelbit- Fehlerkorrektur erlaubt.
    Wobei ich den Sinn einer Verschlüsselung für Deinen Zweck eigentlich nicht so richtig erkennen kann - Ausser als Lerneffekt, oder Kopierschutz für eventuelle Nachbauer.
    Geändert von wkrug (06.10.2012 um 08:54 Uhr)

  4. #14
    Benutzer Stammmitglied
    Registriert seit
    05.10.2012
    Beiträge
    33
    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.
    Thema Puffer:
    Ich nehm für die Eingangs - Rohdaten gerne einen fixen Ringpuffer mit Schreib- und Lesezeigern.
    Das schafft für den empfangenden Controller etwas Zeit für die Abarbeitung und es sollten keine Bytes verloren gehen.
    Aus diesem Puffer kann man sich dann die Daten rausparsen und wieder Puffern oder in String Variablen oder struct's zur weiteren Verarbeitung ablegen.
    Generell lauft es ja so ab, dass das RFM12 einen Interrupt verursacht in dem ich dann die Daten abholen kann. Wenn der Frame komplett ist, muss auf den Units natürlich entschlüsselt und geantwortet werden. Das würde ich auch noch in der ISR erledigen sodass dann das Frame im Reinformat im Buffer liegt um dann im normalen Programmablauf (nicht mehr zeitkritisch) abgearbeitet wird. (z.B.: LampeX in 3sec auf 10% dimmen)
    Der Buffer soll die Schnittstelle zwischen Protokoll und Ausführung sein.

    Meine "Waffe" für solche Fälle ist der IRF3708.
    Hat schon bei 5V sehr geringen RDS On ( 12mOhm ).
    Genügend Reserven ( 63A ) - Bis 10A ohne Kühlkörper.
    Leicht erhältlich, Preislich OK.
    Das klingt schon mal gut - vielen Dank!

    Die RFM12 Funk Module sind etwas Tricky, hast Du schon etwas Erfahrung mit den Bausteinen?
    Ich hab schon gelesen, dass die Dinger recht trickreich sind - allerdings ist der Preis natürlich TOP.
    Erfahrung habe ich leider noch keine - aber die fehlt generell auf dem gesamten Microcontroller- und Elektronikbereich.
    Ich denke die Umsetzung dieses Projekts kann im schlechtesten Fall noch Jahre in Anspruch nehmen.
    Aber ich habe großes Interesse mir Fähigkeiten im Herstellen und Programmieren von Platinen in Kombination mit Microcontrollern anzueignen - insbesondere weil ich einen großen Mehrwert für mein Informatik-Studium daraus ziehen kann.

    Wenn Du die Daten schon verschlüsseln willst, würde ich versuchen ein Protokoll zu nehmen, das auch zumindest eine Einzelbit- Fehlerkorrektur erlaubt.
    Wobei ich den Sinn einer Verschlüsselung für Deinen Zweck eigentlich nicht so richtig erkennen kann - Ausser als Lerneffekt, oder Kopierschutz für eventuelle Nachbauer.
    Also ist es ratsam einen Hamming Code in das Datenframe einzuarbeiten?
    Verschlüsselung deshalb, weil ja auch recht sensible Daten über die Funkstrecke übertragen werden sollen (irgendwann mal zu mindest).
    Zum Beispiel der Befehl zum Öffnen der Haustür kann - mitgehorcht und erneut eingesendet - kritisch werden. Um die Authentizität der übertragenen Daten zu wahren muss ich verschlüsseln. Mit der ID und der Sendezeit können Frames dann quasi nur 1x verwendet werden.

  5. #15
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    2.187
    Generell lauft es ja so ab, dass das RFM12 einen Interrupt verursacht
    Stimmt, kann man so proggen.
    Du kriegst aber pro Interrupt nur ein Byte.
    Damit kannst Du erstmal gar nichts anfangen.
    Ausserdem kann es ja sein, das Dir ein Byte durch die Lappen geht. Wenn das gerade ein Sync Byte war hast Du ein Problem.
    In meinen unverschlüsselten ASCII Übertragungen hab ich deshalb immer ein eindeutiges Startbyte, z.B. $ und eine feste Endsequenz <CR><LF>.
    Die Auswertung einen Strings erfolgt dann immer erst, wenn <CR><LF> empfangen wurde. Dann setz ich im Interrupt ein Flag und das Hauptprogramm weiss, das es etwas tun muß.
    Ein $ Byte setzt bei mir den Zeiger des Auswertepuffers immer auf 0.
    Verbunden mit einer CRC Checksumme kann dann eigentlich nicht mehr viel passieren, was die Datenübertragung aus dem Tritt bringen könnte.

    Tritt in einem String ein Bitfehler auf der zufällig ein $ ergibt, stimmt die Checksumme nicht und der String wird verworfen.
    Kommt ein <CR><LF> nicht, wird beim näcsten String wieder alles gut, weil das $ ja den Auswertestringzeiger wieder auf 0 setzt.

    Den Ringpuffer muss man allerdings dann so groß machen, das mindestens 2 komplette Strings rein passen, da ja wie gesagt das <CR><LF> ja auch mal nicht kommen kann.

  6. #16
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    20.08.2008
    Ort
    Karlsruhe
    Alter
    36
    Beiträge
    1.225
    Zitat Zitat von cd_brenner Beitrag anzeigen
    Generell lauft es ja so ab, dass das RFM12 einen Interrupt verursacht in dem ich dann die Daten abholen kann. Wenn der Frame komplett ist, muss auf den Units natürlich entschlüsselt und geantwortet werden. Das würde ich auch noch in der ISR erledigen sodass dann das Frame im Reinformat im Buffer liegt um dann im normalen Programmablauf (nicht mehr zeitkritisch) abgearbeitet wird. (z.B.: LampeX in 3sec auf 10% dimmen)
    Der Buffer soll die Schnittstelle zwischen Protokoll und Ausführung sein.
    Kann man tun. Oder man parst die Daten schon während du sie bekommst. Ich fahre in der Regel ein hybrides Konzept, die ersten Protokollschichten arbeiten ohne Pufferung, und irgendwann beginnt dann der Bereich, in dem die Daten zwischengelagert werden. Momentan plane ich eine flexible Stack-Architektur, mit der man da relativ frei einzelne Schichten zusammenstöpseln kann, ohne allzugroßen Overhead.

    mfG
    Markus
    Tiny ASURO Library: Thread und sf.net Seite

  7. #17
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    19.05.2005
    Ort
    Berlin
    Beiträge
    316
    Tokenring zusammen mit Koordinator finde ich ein wenig "komisch". Tokenringe sind ja extra dafür da, dass man keinen zentralen Koordinator braucht. Je nach deiner gewünschten Systemarchitektur würde ich entweder einen Master einsetzen, der alle Slaves pollt (imho nich so schön), oder allen Knoten das Senden erlauben und CSMA/CD einsetzen.
    Weiterhin würde ich mich ein wenig am OSI-Modell orientieren und die einzelnen Aspekte der Datenübertragung in entsprechende Layer verpacken. So kannst du dich immer um ein Problem alleine kümmern/adressieren. Falls du später noch andere Übertragungskanäle hinzu nimmst, ist deine Software auch besser wiederverwendbar.

    Zum Thema AES:
    -du bräuchtest dafür ja einen zentralen Schlüssel => wenn dir mal ein Knoten abhanden kommt (z.B. Aussenthermometer), dann ist das gesamte System komprommitiert und du musst an allen Knoten den Schlüssel ändern
    -Schlüsselweitergabe: Wie? Per Hand an den Knoten, oder per Software über Funk (unsicher)

    Wenn du verschlüsselst, dann besser Asymmetrisch. Broadcasts fallen dann allerdings aus . Alternativ natürlich Schlüsselübergabe asymmetrisch und dann gemeinsam symmetrisch. Ist aber ein riesen Aufwand. Vor allem, die Algorithmen sicher zu implementieren.
    Deswegen solltest du überlegen, ob die Nachrichten wirklich geheim, oder "nur" gesichert sein müssen.
    Viel einfacher ist es, die Nachrichten zu signieren und so die Integrität derselben sicherzustellen. So kann jeder Knoten überprüfen, ob eine Nachricht wirklich legitim, oder von außen in das System eingebracht worden ist (Stichwort Türöffner ;D).
    Man könnte z.B. ein Challenge-System einsetzen, mit dem sich die Knoten untereinander authentifizieren können. Nur sone Idee, da gibt es noch tausend andere Möglichkeiten.

    Auf jeden Fall hast du dir da ein interessantes Aufgabengebiet rausgesucht. Ich wünsche dir viel Spaß beim rumexperimentieren und lernen!

  8. #18
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    2.187
    Eventuell ist für dich ja auch das Keylock Sytem von Microchip für Dich geeignet?!
    Dabei wird ein fester Schlüssel verwendet, aber mit einem Counter jede Nachricht mit einem anderen Code verschlüsselt.
    Die Slaves haben wiederum einen jeder für sich einen eignenen Schlüssel, der vom Master eingelernt werden muß.
    Erst nach 65636 Nachrichten kommt wieder der erste Code zur Anwendung.
    Die letzten 32000 Schlüssel werden ignoriert.

  9. #19
    Benutzer Stammmitglied
    Registriert seit
    05.10.2012
    Beiträge
    33
    Tokenring zusammen mit Koordinator finde ich ein wenig "komisch". Tokenringe sind ja extra dafür da, dass man keinen zentralen Koordinator braucht. Je nach deiner gewünschten Systemarchitektur würde ich entweder einen Master einsetzen, der alle Slaves pollt (imho nich so schön), oder allen Knoten das Senden erlauben und CSMA/CD einsetzen.
    Ich glaube, dass "Tokenring" hier einfach der falsche Ausdruck ist.
    Im Endeffekt sitzt in der Mitte ein Master der nacheinander zu jedem Slave eine Verbindung aufbaut und so die Daten von einem Slave zum anderen durchroutet.
    Beim echten Tokenring baut ja der Slave die Verbindung zum nächsten Slave in der Runde auf.

    -du bräuchtest dafür ja einen zentralen Schlüssel => wenn dir mal ein Knoten abhanden kommt (z.B. Aussenthermometer), dann ist das gesamte System komprommitiert und du musst an allen Knoten den Schlüssel ändern
    Du meinst jetzt, wenn das komplette Gerät entführt wird? Ist es denn so einfach den Sourcecode auf einem Microcontroller auszulesen und v.a. dort den Schlüssel auszulesen?

    Wenn du verschlüsselst, dann besser Asymmetrisch. Broadcasts fallen dann allerdings aus
    Wenn ich jetzt mal davon ausgehe, dass mir keine Einheit (physisch) abhanden kommen kann, verwende ich einfach ein gemeinsames Geheimnis mit dem alle Daten ver- und entschlüsselt werden. Das sollte ja eigentlich relativ easy funktionieren, oder?

    Vielen Dank!

  10. #20
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    20.08.2008
    Ort
    Karlsruhe
    Alter
    36
    Beiträge
    1.225
    Zitat Zitat von cd_brenner Beitrag anzeigen
    Du meinst jetzt, wenn das komplette Gerät entführt wird? Ist es denn so einfach den Sourcecode auf einem Microcontroller auszulesen und v.a. dort den Schlüssel auszulesen
    Wenn du die entsprechenden Lockbits deines µC setzt, nein.

    mfG
    Markus
    Tiny ASURO Library: Thread und sf.net Seite

Seite 2 von 3 ErsteErste 123 LetzteLetzte

Ähnliche Themen

  1. Netzwerkprotokoll im kleinen Maßstab
    Von Technipion im Forum Software, Algorithmen und KI
    Antworten: 14
    Letzter Beitrag: 18.08.2012, 20:57
  2. Funkmodul RFM12
    Von Thomas$ im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 31
    Letzter Beitrag: 31.07.2009, 11:55
  3. RFM12 ATMega8
    Von Goldenflash im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 1
    Letzter Beitrag: 20.01.2009, 00:28
  4. Grundschaltung RFM12
    Von Jaecko im Forum Elektronik
    Antworten: 6
    Letzter Beitrag: 31.08.2008, 12:03
  5. RFM12 Funksteckdose
    Von Micha.Berlin im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 0
    Letzter Beitrag: 20.05.2008, 23:46

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test