SLIP-orientiertes Protokoll

Hallo, allerseits,

ich bin neu im Forum, habe bisher nur ein wenig mitgelesen. Ich bin seit September in einer Firma als Elektronik-Entwickler angestellt, wo ATMEL und AVRCo die Standard-Plattform für die Produktentwicklung ist. Da beides für mich neu war, mußte ich mich erst ein wenig einarbeiten. Jetzt ist das erste Projekt soweit gediehen, daß ich doch mal die Hilfe der "Altvorderen" brauche.
Ich hab ein kleines Master-Slave-System mit max. 32 Slaves, das ich im Polling nach Anwesenheit und Ereignissen abfragen möchte. Als Kommunikationsprotokoll möchte ich das SLIP-orientierte Verfahren einsetzen, ohne den SLIP-Treiber aus der Profibibliothek benutzen. (Manual Standard-Driver, Abschnitt 3.11.6).
Das funktioniert soweit schon super, aber ich habe hier ein Zeitproblem: Die Pollingrunde soll so schnell wie möglich stattfinden, da Ereignisse noch an eine übergeordnete Instanz weitergegeben werden müssen. Für die Kommunikation insgesamt komme ich netto mit 2-4 Byte pro Datenblock aus. Nur im Diagnose-Modus wird's mehr, aber da spielt die Zeit keine Rolle. Um EMV-Probleme zu umgehen, möchte ich die Datenrate auch nicht so hoch wählen, obwohl das System mit Leitungslängen unter 20m sicher mehr hergibt als 19,2 kBaud.
Nach meinen Tests sendet ein SerOutSLIP aber brutto immer 20 Byte. Start- und Stopbyte ( $c0), Netto-Blocklänge 1 Byte, die Checksum, die Nettodaten, und der Rest wird mit $00 aufgefüllt.
Meine Frage:
1. Gibt es eine Möglichkeit, die Brutto-Blocklänge z.B. auf 10 Byte zu verkürzen ?
2. Gibt es Alternativen, wo ich mich nicht um die gesamte serielle Kommunikation kümmern muß?

Danke im Voraus, daß sich jemand meines Problems annimmt.

MfG

Schnutzibär

Hallo, rh,

danke für die schnelle Antwort. Ich hätte vielleicht dazusagen sollen, daß ich als physikalisches Übertragungsmedium LIN-Treiber (z.B. ATMEL ATA6620) benutze. Falls nicht schon bekannt: LIN ist ein Drei-Draht-Bus, +UB (z.B. 24V), Masse und eine Datenleitung. Die logischen Pegelgrenzen für die Datenleitung liegen dicht unter +UB bzw. etwas über Masse. Wird oft als "Unterbus" zu CAN verwendet. Nur strenges Master-Slave-Regime möglich.
Mit der höheren Geschwindigkeit muß ich nochmal sehen, welchen Aufwand ich mir mit der EMV auflade.

Danke nochmal.

CF

Hallo, rh,

ja, man muss nur mal das ganze Gehirn einschalten und nicht nur das Stück, das den Kuhherden-Effekt verwaltet. Die Erklärung ist natürlich einleuchtend.
Entscheidung für die LIN-Treiber war schon gefallen, als ich hier angefangen habe. Das habe ich dann unbesehen als gesetzt akzeptiert und nicht weiter drüber nachgedacht. Kannte den LIN-Bus vorher auch nicht. Jetzt, wo ich am Realisieren bin, geht eine Lampe nach der anderen an. Ein Glück jetzt, und nicht in acht Wochen !!

Danke, danke danke !!

CF

Hallo Cf,

1. wenn das LIN nur eine Laune und keine Notwendigkeit ist, dann weg davon.
RS485 ist immer die erste Wahl bei langen Leitungen.

2. Da gibt es kein Problem dieser Art in den Programmern. Wenn sowas auftritt
wie oben beschrieben, dann sind entweder die OSC-Fuses falsch eingestellt
oder der SPI/Prog Clock ist zu hoch gewählt, sodass es zu Programmier Fehlern
kommt.

Wenn es noch geht, dann auf JTAG umsteigen, da gibt es diese Probs nicht
und man kann damit auch in-circuit debuggen. Bei grösseren Apps sehr wichtig.
Oder gleich den XMega nehmen. Dann wird auch das ICE zur wahren Freude :3some:

rolf