Forum: Mikrocontroller und Digitale Elektronik LIN Bus mit Atmega als Master (Botschaft senden)


von Tom (Gast)


Lesenswert?

Hallo zusammen,
ich möchte mittels eines Atmegas 48/88 oder 168 und einem Transceiver 
einen LIN Master aufbauen mit dem ich beliebige Botschaften mittels 
Knopfdruck an Slaves schicken kann z.B. zum manuellen Ausfahren eines 
LIN Motors. Ich habe einige Berichte hier im Forum schon gefunden z.B.

Beitrag "UART mit LIN-Protokoll"
Beitrag "Beispiel Projekt AT90CAN128 AVRStudio  LCD  Timer"

Das ApplicationSheet von AVR322 habe ich mir auch durchgelesen ! 
Eigentlich beinhalten die beigefügten Dateien ja eine komplette LIN 
Kommunikation, doch ich würde gerne erst mal ein Programm zum testen der 
Schaltung haben, welches eine Art "HalloWelt" LIN Botschaft schickt.

Meine Fragen:

1. Gibt es eine Art abgspecktes LIN Protokoll womit man nur Botschaften 
verschickt oder muss immer dieses ganze drum herum mit Checksumme usw 
vorhanden sein? laut LIN Specs schon, aber ich will ja nur mal was 
Testen...

2. Gibt es noch einen Beitrag, den ich vielleicht übersehen hab?

3. Zum experimentieren brauche ich noch einen Transceiver der DIL 
Gehäuse Form hat kann ich dne MCP201-E/P verwenden?

4. Leider sind die Atmel Dateien mit IAR geschrieben worden, kann man 
die in AVR Studio anpassen? Oder ist das zu aufwendig?

ich hoffe auf eure Antworten

von Harald (Gast)


Lesenswert?

1. Wenn Du auch die andere Seite programmierst, dann kannst Du das 
machen wie Du möchtest. LIN ist ja physikalisch nichts anderes als eine 
1-wire serielle Halbduplex-Verbindung. An dieser Stelle gibt es noch 
kein "Regelwerk". Wenn Du allerdings einen fremden LIN-Baustein als 
Empfänger verwendest, der die korrekte Einhaltung des Protokolls 
einfordert, dann musst Du das auch tun (oder er reagiert halt nicht)

2. schwer zu sagen

3. MCP201 ist durch den verbesserten Typ MCP2021 abgelöst worden. Der 
MCP201 hat etwas undurchdachte Ansätze zum Wechseln der Modi 
Standby/Run. Insbesondere dann, wenn man den integrierten 5V/3.3V Regler 
zum Betrieb der eigenen Schaltung verwendet (man sägt an dem Ast, auf 
dem man sitzt). Alternative ist noch der TJA1050 von NXP. Auch ein 
schönes Teil.

4. Wieso soll das ein Problem sein? Reinladen, anpassen, 
ändern/compilieren bis fehlerfreier Zustand erreicht.

Warum überhaupt für das erste HalloWelt ein Stack? Einfach die serielle 
Schnittstelle initialisieren, Baudrate auf 1/2 Baudrate, Break senden, 
Baudrate wieder hochsetzen, ID senden, Daten und Checksumme hinterher. 
Fertig. Wenn man es professioneller gestalten will noch den RX-Interrupt 
aufsetzen und hier eine State-Machine aufsetzen. Den TX-Interrupt 
benötigt man nicht, da man jedes gesendete Byte wieder zwangläufig 
zurückliest.

von Frederik K. (n0ll4k)


Lesenswert?

Es gibt von Atmel übrigens auch so Kombinationen die bereits nen 
Transceiver und einen Spannungsregler drin haben, sind allerdings im QFN 
Gehäuse.

Ansonsten wie Harald schon sagte, entweder nimmst du nur die LIN 
Hardware und baust dir dein eigenes Protokoll. Wenn du aber einen 
vorgegebenen LIN Slave hast musst du die Spezifikation auch einhalten.

Wenn man LIN verstanden hat ist der Treiber auch recht fix geschrieben. 
Wenn man eine passende Hardware, LIN Emulator, zum testen da hat gehts 
noch komfortabler.

Ansonsten aber keine große Kunst, den Code aus der AppNote kann man von 
IAR auch fix zu WinAVR portieren. Sind ja nur die Definitionen.

von Harald (Gast)


Lesenswert?

TJA1050 ist übrigens falsch, ich meine den TJA1020

von Tom (Gast)


Lesenswert?

Danke für die Antworten, ich werde jetzt erst mal die Specs vom 
Lin-Protokoll mit dem Protokoll der "Verbraucher" vergleichen, um zu 
sehen das ich da vielleicht was einsparen kann. Ich möchte das ganze 
möglichst schlank halten. Eine Frage habe ich aber noch:

Die Transceiver sind doch fertige Bausteine ähnlich wie zum Bsp. MAX232 
und brauchen nicht mehr programmiert zu werden? Sprich Hardware 
anschließen und fertig.

von Frederik K. (n0ll4k)


Lesenswert?

Tom schrieb:
> Die Transceiver sind doch fertige Bausteine ähnlich wie zum Bsp. MAX232
> und brauchen nicht mehr programmiert zu werden? Sprich Hardware
> anschließen und fertig.

Jop so siehts aus.

Was hast du denn für Verbraucher? Wenn das fertig ausgelieferte Geräte 
mit LIN Schnittstelle sind kannst du mal davon ausgehen das du alles 
implementieren musst.

von Tom (Gast)


Angehängte Dateien:

Lesenswert?

Harald schrieb:
> Warum überhaupt für das erste HalloWelt ein Stack? Einfach die serielle
> Schnittstelle initialisieren, Baudrate auf 1/2 Baudrate, Break senden,
> Baudrate wieder hochsetzen, ID senden, Daten und Checksumme hinterher.
> Fertig. Wenn man es professioneller gestalten will noch den RX-Interrupt
> aufsetzen und hier eine State-Machine aufsetzen. Den TX-Interrupt
> benötigt man nicht, da man jedes gesendete Byte wieder zwangläufig
> zurückliest.

1.
Heißt das also, dass ich mittels UART und der richtigen Baudrate 
"einfach" eine Bitfolge für eine komplette Botschaft verschicken kann? 
(ein Bsp wäre toll)

2.
Aber dann brauch ich ähnlich wie in folgender Datei die komplette 
aufgelöste binäre Darstellung der Nachricht, in einem LDF File verwendet 
man ja aber immer Schlüssewörter wie zum Bsp "EngineOn", woher bekomm 
ich dann die Botschaft in der Form?

Quelle: 
http://www.nibis.de/nli1/bbs-cms/Berufsbereiche/Fahrzeugtechnik/Unterrichtsmaterialien/Kooperation/BeleuchtungGolfV/PDF/5.3-Nachri-format%202.pdf

von Frederik K. (n0ll4k)


Lesenswert?

Im LDF stehen ja die einzelnen Bits für die Signale drin. Die musst du 
dann per Schiebeoperationen zu einem Byte zusammen basteln was der, nach 
LDF, korrekten Reihenfolge entspricht. Das Byte (oder die Bytes) kannst 
du dann versenden.

Beispiele dazu hast du in der Atmel App Note.

Am besten du machst dir mal ne Tabelle oder so wo die einzelnen Bits der 
Signale aufgelistet sind. Aus denen baust du dir dann mal die Bytes 
zusammen. Dann musst du nur noch die Checksumme berechnen und du kannst 
dir aus ID, Daten, ChkSum dein Datenpaket zusammenstellen was.

Dann Break und NAchricht senden. Natürlich auf die Reihenfolge der 
Nachrichten im Netzwerk achten, falls da schon eine Vorgabe besteht.

von Osche R. (Gast)


Lesenswert?

Harald schrieb:
> TJA1050 ist übrigens falsch, ich meine den TJA1020

Der TJA1020 gehört ins Museum. Wenn Du welche zum Basteln geschenkt 
bekommst (oder haben willst) ist das ok, aber Geld ausgeben würde ich 
dafür nicht mehr.

Wenn's Philips sein soll, dann der aktuelle TJA1021. Ansonsten empfiehlt 
sich der TLE7259-2GE oder der ATA6662 / ATA6663. Letzerer bietet sehr 
gute Störfestigkeit bei relativ günstigem Preis.

Die sind alle im SO-8 - Gehäuse, aber lassen sich problemlos in eine 
DIP-Fassung reinwursteln.


Patrick

von Holger (Gast)


Lesenswert?

Thema: Analyse mit dem BREAK, wie geht das da im LIN-BUS  ab ??
------------------------------------------------------------------------ 
------------------------
LIN-LISTEN OHH a BREAK is on the LINE, @STATE-ENGINE STEP_SYNCHRON
######################################################
Holger: Tabelle-(Trigger-Timing)LIN-BUS
Halbe Baudrate:    @@BREAK >_................_### -->SIGNAL 9600    Baud 
LIN-BREAK
Normale Baudrate:  @BREAK >_........_###         -->SIGNAL  2*9600 BBaud
------------------------------------------------------------------------ 
---------------------------------

@Harald Ist das der "Syc- Trick" den du da anwendest.???
>Baudrate auf 1/2 Baudrate, Break senden,
Einen Break kann man doch nicht senden, ???oder ergiebt sich das,indem 
du die
0x00 mit halber Baudrate sendest, und so einen langen BREAK auf der 
Leitung
erzeugst. Der von dem normalen Bus-Timing so lang ist, u somit die 
TX-RahmenZeit
2 mal so gross setzt... also via (Buss-Stetching) ....Siehe 
Holger:Tabelle.

@Harald schrieb:
> Warum überhaupt für das erste HalloWelt ein Stack? Einfach die serielle
>
> Schnittstelle initialisieren, Baudrate auf 1/2 Baudrate, Break senden,
>
> Baudrate wieder hochsetzen, ID senden, Daten und Checksumme hinterher.
>
> Fertig. Wenn man es professioneller gestalten will noch den RX-Interrupt
>
> aufsetzen und hier eine State-Machine aufsetzen. Den TX-Interrupt
>
> benötigt man nicht, da man jedes gesendete Byte wieder zwangläufig
>
> zurückliest.

von Holger (Gast)


Lesenswert?

@Harald
------------------------------------------------------------------------ 
------------------------
Bist du nicht der mit dem "ZILOG ZNEO" 16Bit MCU-Teil, 100 pin LQFP 
@20Mhz.
Als Helicopter Project. ???
Einfach genial gemacht...
Frage:
Kennst du dich wegen der  "ZILOG ZNEO MCU"  so gut mit dem LIN-Bus aus 
??
#####################################################

Ich habe mir die neue MCU 16 BIT "ZILOG ZNEO" näher angeschaut,u. 
untersucht,
unter anderem mit der internen "LIN-BUS" Schnittstelle,

Da ich später noch  auch auf die "ZNEO MCU" umsatteln möchte.
Habe ich da noch Fragen offen in Bezug auf den LIN-BUS,
mit dem speziellen  @BREAK >_........_### -->SIGNAL. via "PULL-UP" 
ca.-4K7

Kleine Vorgeschichte:
Wir machen mit der 8-Bit "ZILOG eZ8 Encore" gute solide Projekte.
(Da das IRQ-Handling ist "fast" wie bei der Motorola MCU gemacht)
######################################################
Gruss Holger.

von Holger (Gast)


Lesenswert?

Hallo @Forum:
 //LIN KOMMUNIKATION STARTET HIER
  Sync_Break=Receive_Byte();

  if (Sync_Break){
  //Ein Frame Error wird durch ein Sync-Break hervorgerufen

    UCSR0A &= 0b11100011;      //Frame Error Flag löschen;
######################################################################## 
#
Die ATMEGAS haben leider keine detector für Break,Snc Signal.
Die FTDI Chip z.B kann dagegen unter anderem eine Break von einem 
Frame-Error unterscheiden.

Siehe Code Sniplet.
//Ein Frame Error wird durch ein Sync-Break hervorgerufen
Gruss Holger.
Der LIN-Bus ist extrem teuer in den Tools, aber dahinter
steckt erst mal nur ein Protokoll... trick, wie ich das so sehe.
Fast wie Bitbus 75-176  Chip.. oder ???
Gruss Holger.

von Tom (Gast)


Lesenswert?

Momentan bin ich mit dem Compilieren des Codes des Atmel 
Applicationsheet AVR322. Da der Code ja urspünglich mit IAR geschrieben 
wurde, muss man das ganze für AVR Studio (was ich auch benutze) 
abändern.

Jetzt stehe ich vor dem Problem, dass der Compiler mit der Headerdatei 
inavr.h nicht zurechtkommt!!!

avr/io.h
signal.h

habe ich schon ausprobiert, funktioniert nicht. Mit IAR hätte ich das 
Problem nicht, aber wie kann man den Code anpassen???

von Harald (Gast)


Lesenswert?

Ich lese erst jetzt wieder mit.

Ja, der Break kann erzeugt werden, indem man die Baudrate einfach auf 
die Hälfte setzt (oder < 9/13 der Ursprungsbaudrate). Dann sendet der 
einfach eine entsprechend lange Lücke (Startbit=0 + 8*Datenbits=0). Der 
Empfänger weiß ja nichts von der Umschaltung und interpretiert dass dann 
als Break. Aufpassen muss man nur, dass das nächste Byte nicht einfach 
so losgeschossen wird, sondern dass man auf Abschluss der Übertragung 
des Breaks wartet. Die meisten Controller haben ein entsprechendes 
Busy-Bit in der UART. Sonst geht das nächste Byte nämlich vollends 
daneben, entweder mit falscher Baudrate oder gar mit 
Baudratenumschaltung mitten im Byte.

Eleganter geht es natürlich, wenn die UART eine entsprechende Funktion 
zur Erzeugung eines Breaks bietet. Das ist aber nur selten der Fall.

von Harald (Gast)


Lesenswert?

Patrick S. schrieb:
> Wenn's Philips sein soll, dann der aktuelle TJA1021.

OK, da hat Patrick natürlich Recht. Ich hatte mich mit dem Thema 
NXP/Philips länger nicht mehr beschäftigt.

von Reiner O. (elux)


Lesenswert?

Harald schrieb:

> Eleganter geht es natürlich, wenn die UART eine entsprechende Funktion
> zur Erzeugung eines Breaks bietet. Das ist aber nur selten der Fall.

Ein Soft-UART macht das mundgerecht; das habe ich seinerzeit bei einem 
LIN-Projekt so verwendet. Dabei braucht man die Umschalterei der 
Geschwindigkeiten nicht; Pin runter, Bit-Zähler bis 13 hochzählen, Pin 
hoch f. Delimiter ...

> Der MCP201 hat etwas undurchdachte Ansätze zum Wechseln der Modi
> Standby/Run. Insbesondere dann, wenn man den integrierten 5V/3.3V Regler
> zum Betrieb der eigenen Schaltung verwendet (man sägt an dem Ast, auf
> dem man sitzt).

Das ist aber wirklich nett ausgedrückt! Vor Allem in Verbindung mit ISP 
könnte man ...

Das Ergebnis ist irgendwo in dem "Zeigt her Eure Kunstwerke"-Th. auch 
abgebildet.

Gruss aus Berlin
Elux

von Harald (Gast)


Lesenswert?

Reiner O. schrieb:
> Ein Soft-UART macht das mundgerecht;

Ein Software-UART ist die allerletzte Bastelkrücke, wenn wirklich nichts 
anderes mehr übrig bleibt und man nur auf dem Labortisch mal etwas 
ausprobieren möchte (aber auch nur für den Prototypen einer 
Bastelschaltung)

Gerade bei LIN macht HW-UART mit 3fach Abtastung pro Bit beim Empfang im 
Sinne der kaum vorhandenen Fehlerkorrektur extrem Sinn. Außerdem, wie 
soll das Rücklesen der Bytes vom Bus zur Kollisionserkennung mit SW-UART 
funktionieren. Kann man sich sicherlich mit Assembler hinferkeln, aber 
warum sollte das jemand ernsthaft vorhaben?

von Reiner O. (elux)


Lesenswert?

Harald schrieb:

> Ein Software-UART ist die allerletzte Bastelkrücke...

Sorry, aber das sehe ich anders.

> Außerdem, wie soll das Rücklesen der Bytes vom Bus zur
> Kollisionserkennung mit SW-UART funktionieren.

Hmmm, hatte LIN nicht das Delegated-Token-Prinzip ?


Gruss aus Berlin

Elux

von Harald (Gast)


Lesenswert?

Reiner O. schrieb:
> Sorry, aber das sehe ich anders.

WO speziell ist denn ein SW-UART sinnvoller, wenn ein HW-UART zur 
Verfügung steht?


Reiner O. schrieb:
> Hmmm, hatte LIN nicht das Delegated-Token-Prinzip ?

Schönes Wort, dafür gibt es sicher ein dickes Plus vom Prof.

Auf jeden Fall gibt es Anwendungsfälle im LIN, wo es zu Kollsionen 
kommen kann. Siehe auch offizielle CAN-Spec. Dazu braucht es aber noch 
nicht einmal kommen, denn das kann man getrost als Sonderfall 
abstempeln. Es geht vielmehr um die permanente Überwachung eines 
1-Draht-Bus, dieser ist schon mal von Natur aus sehr viel anfälliger 
gegen externe Einflüsse. Ich hätte also von "Störungen" anstelle von 
"Kollisionen" sprechen sollen. Genau aus diesem Grund arbeiten alle mir 
bekannte LIN-State-Machines nur mit einem Receive-Interrupt, in diesem 
wird das letzte zurückgelesene Byte (vom HW-UART einigermaßen sicher 
zurückgelesen ;-) mit dem Sollwert verglichen. Nur wenn alles i.O. ist, 
wird weitergemacht, ansonsten neuer Versuch mit neuem Frame.

von Reiner O. (elux)


Lesenswert?

Harald schrieb:
> WO speziell ist denn ein SW-UART sinnvoller, wenn ein HW-UART zur
> Verfügung steht?

WENN ein HW-UART zur Verfügung steht ist Einer in SW nicht sinnvoller, 
da hast Du schon recht.

> Schönes Wort, dafür gibt es sicher ein dickes Plus vom Prof.

Ooch Harald, mit meinen 45 Lenzen; ob mich das noch sonderlich "erregt"? 
;-)

> Es geht vielmehr um die permanente Überwachung eines
> 1-Draht-Bus, dieser ist schon mal von Natur aus sehr viel anfälliger
> gegen externe Einflüsse.

Stimmt. Nur wird das Bitmonitoring doch z.B. beim MCP2021 schon intern 
erledigt, ebenso "short to +/-" und über den FAULT/TXE Pin gemeldet; 
also Alles, was ich vom Master aus "sehen" kann. Der Rest geht per 
Status Bit (bzw. Response Error Bit) über die Bühne oder es kommt eben 
kein Response und wie ich darauf zu reagieren habe, ist zumindest in den 
Spez. nicht festgelegt (bzw. die Fehlerbehandlung dazu).
Von daher sehe ich keinen Grund, den UART nicht in Software auszuführen 
(siehe oben) und sehe in einem Software-UART nicht "... die allerletzte 
Bastelkrücke...".


Nichts für ungut ;-)

Gruss aus Berlin

Elux

von Holger H. (holger-h-hennef) Benutzerseite


Lesenswert?

http://www.vector-elearning.com/index.php?&wbt_ls_seite_id=454290&root=376493&seite=vl_einfuehrunglin_de
Sehr gut.
@Reiner O. (elux)
Der Tip mit Delegated-Token-Prinzip.
Da ist das gut beschrieben.
Ich habe da den ez8 XP ZILOG Prozi. dran.
Danke für den Tip.

Gruss Holger.

von Holger H. (holger-h-hennef) Benutzerseite


Lesenswert?

http://www.youtube.com/watch?v=VIKB4tn6yXc
Die Cisco Router Con-USB@V24-sole ist auch "break sensitive...
Kann das ein FTDI232 auch,via USB als event schnell genug.
Kawasaki-Chip z.B für Palm xx(USB) App. Ist auch schnell genug,
für den "Break" detect.
Danke Harald für die Infos hier.

von judas (Gast)


Lesenswert?

Beim mcp 2021 sollte man nicht vergessen den Vreg zu stabilisieren!!! 
Ich hab das wohl nicht getan und mich gewundert wieso da niichts 
rauskommt, wo doch so viel reingeht ;-)
Also 10µF Elko ran, wenn man das Ding nicht braucht und mehr nicht!
Dachte den könnte man nc lassen, falsch gedacht :-)

von judas (Gast)


Lesenswert?

Hi,
ich bin auch am LIN-Bus proggern,
möchte die Baudratenumschaltung im Interrupt machen, allerdings mit 
Xplain-Board. Hierzu die AVR1510 von Atmel umgebaut.
Im Interrupt Abfrage i==1, dan baudrate verdoppeln führt dazu, dass aus 
breakfield 0x55 ein 0xAA wird... was tun?
danke

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.