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
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.
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.
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.
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.
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
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.
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
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.
@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.
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.
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???
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.
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.
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
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?
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
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.
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
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.
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 :-)
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
