Hallo Leute, ich möchte gerne einen LIN Datenlogger mit einem FPGA realisieren. Dieser soll nur Daten vom Bus auslesen können. Meine erste Frage: Habe ich das richtig verstanden das die Frames auf dem Bus immer gleich aussehen? Sie haben einen Header und einen Response frame. Das eigentliche Problem liegt bei der Erkennung der Baudrate. Wie machen das die Slaves? Sie nutzen das Sync-feld um die Baudrate zu erkennen und sich zu synchronisieren. Aber wie machen die das? Generieren sie dann immer zur Laufzeit einen Clock der zum Sync-feld synchron ist? Wenn ja, kann ich das auch so einfach machen? So in der Art: Ich messe die zeit der fallenden Flanke des Startbits bis zum 7ten bit und teile den wert dann durch 8. So könnte ich die Frequenz berechnen. Ich nutze den Clocking Wizard IP von Xilinx. Aber mit diesem kann ich mir auch nicht jeden beliebigen Clock generieren... Oder gibt es da feste Standards welche benutzt werden? Beispielsweise werden vielleicht nur 3 verschiedene Baudraten eingesetzt. Danke schon mal für die Hilfe Franz
Franz schrieb: > Ich nutze den Clocking Wizard IP von Xilinx. Das ist der falsche Weg. Du nimmst einen hinreichend schnellen Oszillator und ermittelst mit einem Zähler die Dauer eines Bytes/Bits. Und dann nimmst du den selben Takt und zählst so lang, dass du die Mitte eines Bits triffst. Diesen Wert speicherst du dann ab. Dann zählst du his zur Mitte des nächsten Bits usw. Und an einer 01 oder 10 Flanke kannst du deinen Zähler zwischendurch wieder synchronisieren. Sieh dir einfach mal an, wie andere (käufliche) Bausteine das machen...
Hi Lothar, dein Weg hört sich sehr interessant an. Ich werde das mal so probieren. Danke dir mfg Franz
Franz schrieb: > Hi Lothar, > dein Weg hört sich sehr interessant an. Ich werde das mal so probieren. > Danke dir > > mfg > > Franz Von der Grundidee ist ist es ein eun Uart.
Aber bei UART muss ich die Baudrate doch schon vorher wissen oder? Da gibt es ja kein Synch-field
Franz schrieb: > Aber bei UART muss ich die Baudrate doch schon vorher wissen oder? Klar Antwort: Jain. > Da > gibt es ja kein Synch-field Synchronisiert wird auf das Start-Bit. Wenn man die kürzeste Zeit zwischen zwei Flanken misst, hat man mit einer gewissen Wahrscheinlichkeit auch die Bitrate. Gab es da nicht im 8052 so ein Autobaud-Feature? Da wurde die Länge von Space oder Enter ausgemessen, welches als erstes Zeichen kommen musste. Danach wurde die richtige Bitrate eingestellt. Duke
Duke Scarring schrieb: > Franz schrieb: >> Aber bei UART muss ich die Baudrate doch schon vorher wissen oder? > Klar Antwort: Jain. > >> Da >> gibt es ja kein Synch-field > Synchronisiert wird auf das Start-Bit. > Wenn man die kürzeste Zeit zwischen zwei Flanken misst, hat man mit > einer gewissen Wahrscheinlichkeit auch die Bitrate. > > Gab es da nicht im 8052 so ein Autobaud-Feature? > Da wurde die Länge von Space oder Enter ausgemessen, welches als erstes > Zeichen kommen musste. Danach wurde die richtige Bitrate eingestellt. > > Duke Ok ich verstehe. Warum gibt es dann beim LIN dieses Synch-field das 8 bits lang ist? Um die Genauigkeit zu erhöhen?
Franz schrieb: > Warum gibt es dann beim LIN dieses Synch-field das 8 bits lang ist? > Um die Genauigkeit zu erhöhen? Um auch billigen Sensoren mit einem RC-Oszillator verwenden zu können. Trotzdem kann/sollte/muss an jeder Signalflanke der Zähler neu aufsynchronisiert werden. Dafür gibt es extra das Stuff-Bit, das dafür sorgt, dass auch bei langen gleichen Signalpegeln spätestens nach 5 Bits ein Pegelwechsel kommt...
Lothar M. schrieb: > Franz schrieb: >> Warum gibt es dann beim LIN dieses Synch-field das 8 bits lang ist? >> Um die Genauigkeit zu erhöhen? > Um auch billigen Sensoren mit einem RC-Oszillator verwenden zu können. > Trotzdem kann/sollte/muss an jeder Signalflanke der Zähler neu > aufsynchronisiert werden. Dafür gibt es extra das Stuff-Bit, das dafür > sorgt, dass auch bei langen gleichen Signalpegeln spätestens nach 5 Bits > ein Pegelwechsel kommt... Mhh das mit dem Stuff-Bit verstehe ich nicht ganz. Meinst du die Start-Stop Bits? Vielleicht habe ich das Prinzip noch nicht ganz verstanden. Ich wollte das jetzt so machen das ich mir die Zählschritte vom ersten Bit im Synch-field merke. Sagen wir ich zähle mit einem 100Mhz clock bis 600 für ein Bit. Dann zähle ich wieder von 0 bis zur hälfte, also bis 300 und setze dann meinen Abtastclock auf 1. Nach erreichen von 600 setze ich ihn wieder auf 0. Usw. Dann hätte ich meinen clock zum abtasten vom Frame. Da ein LIN frame ja max. eine Baudrate von 20kBaud haben kann und ich mit 100Mhz zähle müsste der Fehler ja relativ gering sein oder nicht? Reicht das nicht wenn ich nur eine Synchronisierung pro Frame mache? Ich begreife nicht ganz wie ich nach dem Synch-Field wieder synchronisieren kann? Sagen wir mal ich will beim ersten Datenbyte aufsynchronisieren. Angenommen Nach dem Startbit folgen 8 Nullen und dann kommt das Stopbit. Woher soll ich jetzt wissen wielange ein Bit ist?
Miss die Frequenz am Anfang und gut. da kommt hlhlhlhlhl. (0x55 oder 0xAA(?)) Das wirst Du hinbekommen! 1 durch das durch zwei ist deine Zeit in Sekunden, die du sampeln musst. Axelr. DG1RTO
Franz schrieb: > das mit dem Stuff-Bit verstehe ich nicht ganz. Ähm ja, vergiss das mit dem Stopfbit... ;-) Sowas gibts nur bei "richtigen" Bussen. Aber der LIN ist offenbar nur ein UART, bei dem ein Framing-Error bewusst zur Paketsynchronisation verwendet wird... Axel R. schrieb: > 1 durch das durch zwei ist deine Zeit in Sekunden, die du sampeln musst. Ich würde einfach z.B. mit einem 1 MHz Zähler die Zeit mitzählen und hätte dann die Ziet pro Bit in us. Und dann würde ich einfach diesen Zählerstand als Bitdauer verwenden... Wie ein UART funktioniert sieht man dort: http://www.lothar-miller.de/s9y/categories/42-RS232 Und da muss jetzt nur noch die Bitdauer gemessen statt berechnet werden, und dann muss noch die Überprüfung auf Buskollision dazu (rezessive 1 ausgegeben aber dominate 0 liegt auf dem Bus --> Fehler). Und fertig.
:
Bearbeitet durch Moderator
Franz schrieb: > Hi Lothar, > dein Weg hört sich sehr interessant an. Ich werde das mal so probieren. > Danke dir Dieser "Weg" ist das, was seit 40 Jahren nahezu immer gemacht wird, um ein System auf einen fremden Takt einzustellen. Das machen Millionen von Microcontrollern so, die eine UART emulieren und zudem rund 100 Mia Chips, die irgendwas mit seriellen Interfaces machen.
Ok ich danke euch sehr. Das Hilft mir auf jeden Fall weiter. Eine Frage hätte ich noch. Ich habe gelesen das ein LIN Frame 0-8 Datenbytes haben kann. Woher weiss ich wieviele Daten der Frame gerade hat? Ich habe folgendes gefunden http://m.eet.com/media/1184085/cylin1.jpg Kann ich mich darauf verlassen dass die länge in diesem Identifier feld auszulesen ist? Oder hängt das vom Standard ab?
Meines Wissens nach werden die 2 Bit im Indentifier-Feld nur bei LIN 1.x für die Anzahl der Daten Bytes verwendet - bei LIN 2.x nicht mehr. Das Ende des Frames erkennst du am Bus Idle oder am nächsten Sync Break
Hallo Jens E. danke für die Antwort. Das mit dem nächsten Sync Break leuchtet mir ein aber mit Bus Idle nicht. Was ist wenn nach einem Frame kein Frame mehr kommt. Somit auch kein nächstes Sync Break. mfg Franz
Wenn kein Frame gesendet wird, befindet sich der Bus ja im rezessiven Zustand (logisch high), also 12V Bordspannung.
Thread beobachten
Seitenaufteilung abschalten
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.