SLIP-orientiertes Protokoll

Blocklänge verringern ?

  • 1
  • 2
  • Page 2 of 2
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: SLIP-orientiertes Protokoll

 · 
Posted: 21.01.2013 - 21:16  ·  #9
Hallo Claus,
sind die Daten binär oder ASCII bzw. Strings?
Bei binären Daten kann es vorkommen, dass ein Byte mal verschwindet
und dann die Kommunikation nie wieder richtig synchronisiert.
Aber evlt. hat das LIN da Abhilfe mit Start und Stop Byte Erkennung.
Genau aus diesem Grund gibt es SLIP, eindeutige Daten Frame Erkennung.

rolf
schnutzibaer
 
Avatar
 
Subject:

Re: SLIP-orientiertes Protokoll

 · 
Posted: 21.01.2013 - 22:24  ·  #10
Hallo, Rolf,

noch bin ich mit der Gestaltung der Kommunikation völlig frei. Eigentlich hatte ich die komplette Palette von $00 bis $ff als Datenmaterial vorgesehen. Aber im Interesse einer stabilen Verbindung kann ich das noch umstellen. Da kommt hier und da vielleicht noch ein Byte dazu, aber immer noch weniger als 20 SLIP-Bytes am Stück. Es geht hier um eine permanente Kommunikation im Bereich der Lichtrufanlagen für Krankenhäuser und Pflegeheime. Es gibt hier eine Norm, die mir vorschreibt, in welcher Zeit bestimmte Aktionen (z.B. "Schwester rufen") zu einer Reaktion des Systems führen müssen. Im Moment beschäftige ich mich mit der Kommunikation zwischen Ebene 0 und 1. Das Signal muß aber u.U. bis zu Ebene 4 durchgereicht werden. Deshalb muß ich mich so beeilen, die Geräte in Ebene 0 zu pollen. Da wir uns im Low-Budget-Bereich tummeln, sind z.B. 50 Cent mehr für einen anderen Prozessor schon ein Problem. Dazu kommt das Platzproblem, da ich meine Platine in einer Standard-Unterputzdose Durchmesser 50 mm versenken muß.

Morgen mache ich neues Konzept für die Ebene 0- Ebene 1 - Kommunikation.

Hast mir sehr weitergeholfen.

Das Problem mit dem neuen Programmer habe ich trotzdem nicht verstanden. Mit dem alten ging's, mit dem neuen nicht. Ich hab jetzt die Fuse-Bits so gesetzt, daß mein externer 8-MHz-Keramik-Resonator der Taktgeber sein sollte, aber ob das geklappt hat ? Kann man das testen ?
Der neue Programmer geht nur, wenn ich die SPI-Frequenz auf 4 MHz oder niedriger runtersetze. Der alte ging auch mit 8 MHz, ist aber leider kaputt.

Gute Nacht.

Claus
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: SLIP-orientiertes Protokoll

 · 
Posted: 22.01.2013 - 00:42  ·  #11
Hallo Claus,

die neuen Programmer sind wesentlich schneller als die alten. Wenn da die CPU nicht mit
dem speed läuft, die der Programmer/SPI erwartet dann kommt es mindestens zu sporadischen
Fehlern. Aber ich werde da für Abhilfe sorgen und den SPI speed beim Programmieren etwas
runtersetzen um mehr Sicherheits Abstand zu dem maximalen speed (vorgegeben durch OSC)
zu erhalten. Sollte im nächsten AVRco Update mit drin sein.

rolf
Gunter
Administrator
Avatar
Gender:
Location: Frankfurt Main / Germany
Posts: 1697
Registered: 02 / 2003
Subject:

Re: SLIP-orientiertes Protokoll

 · 
Posted: 22.01.2013 - 00:57  ·  #12
Hi @ Rolf und Claus,

ich meine mich zu erinnern, dass da nur ein bestimmter Built vom M128
betroffen war.
Entweder wegen der Speed oder der Anforderung an die Signalsteilheit.
Vielleicht kann Claus ja mal das niederohmige R-Array reinsetzen?
Ansonsten würde ich da keinen Schnellschuss bei der Speed machen.
Für Ausnahmen gibt es ja

Define_Fuses
SPIclk = ...

Gruß
Gunter
schnutzibaer
 
Avatar
 
Subject:

Re: SLIP-orientiertes Protokoll

 · 
Posted: 22.01.2013 - 08:34  ·  #13
Guten Morgen @Gunter und Rolf,

ich habe das Widerstandsnetzwerk im Programmer getauscht, kein Erfolg. Der Prozessor läuft mit 8 MHz, die SPI-Frequenz für den Programmer muß ich auf 4 MHz runtersetzen, dann gehts.

Gruß Claus
rh
Administrator
Avatar
Gender:
Location: Germany
Age: 24
Homepage: e-lab.de
Posts: 5558
Registered: 03 / 2002
Subject:

Re: SLIP-orientiertes Protokoll

 · 
Posted: 22.01.2013 - 14:11  ·  #14
Hallo Claus,

Firmware Update ist in der Mache

rolf
schnutzibaer
 
Avatar
 
Subject:

Re: SLIP-orientiertes Protokoll

 · 
Posted: 06.02.2013 - 02:08  ·  #15
@alle Beteiligten

wollte mich zum Abschluss des Themas noch mal melden. Habe wie gesagt mein Protokoll selber definiert. Ich hab den Frame mit zwei festen Bytes (Start- und Stopbyte) eingerahmt: erste Kontrollmöglichkeit. Nach dem Startbyte Framelänge 1 Byte. Startbyte und Framelänge lese ich einzeln ein. Nachdem ich die Framelänge habe, wird der Rest incl Stopbyte im Block eingelesen mit Timeout. Vorletztes Byte ist Checksum (einfache Byte-Addition, Überlauf wird weggeschmissen): Zweite Kontrollmöglichkeit.
Da ich binäre Daten verschlüsseln muss, werden diese vor dem Senden auf zwei ASCII-Zeichen aufgesplittet (z.B. binär $7E werden zu "7E" also $37 und $45). Der Bereich von 0..9 und A..F ist für die Verwendung der sonst benutzten Control-Codes einfach verboten. So weiss der Empfänger, dass einem Zeichen 0..9/A..Byte Netto-Daten. Vorteil: Ich vermeide das Senden binärer Nullen, wie mir angeraten wurde.

@rh: Schön, das Du ein Firmware-Update machst. Es ist ja nicht so wild. Das Beschreiben des Flash dauert halt 2 sec. länger. Man gewöhnt sich dran.

Nochmal danke für alle Tipps.
Nächstes Projekt eine Platine mit einem xMega. Da bin ich bestimmt bald wieder bei euch.

Claus
  • 1
  • 2
  • Page 2 of 2
Selected quotes for multi-quoting:   0

Registered users in this topic

Currently no registered users in this section

The statistic shows who was online during the last 5 minutes. Updated every 90 seconds.
MySQL Queries: 15 · Cache Hits: 14   119   133 · Page-Gen-Time: 0.050757s · Memory Usage: 2 MB · GZIP: on · Viewport: SMXL-HiDPI