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.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.
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.