Serieller Port
-
Hallo zusammen,
es soll ein Windows-GUI-Programm in C++ geschrieben werden, das auf ein seriell (LIN-Bus) angeschlossene Gerät zugreift.
Es werden Telegramme zwischen TestProgramm und Gerät ausgetauscht.
Auf einen bestimmten Befehl-Code soll das Gerät mit einer bestimmten Antwort reagieren.... Befehl B1 --> Antwort A1 , Befehl B2 --> Antwort A2 usw.
Die Aktivitäten von den verschieden Modulen im Gerät selbest sollen mit dem TestProgramm angezeigt und gespeichert (protokolliert) werden.
Wie greift man auf den seriellen Port?Hat jemand eine Idee, wie man ein Konzept erstellt und wie man an die Aufgabe rangeht !?
Für eure Unterstützung wäre ich euch sehr dankbar.
Danke, lion
-
hat nichts mit Standard C++ zu tun das erfordert eine API!
Unter Windows WinAPI. Nichtmal Bjarne Stroustroup (hoffe hab den sei Name richtig geschrieben) seinem Buch würdest Du sowas finden.http://www.winapi.net/index.php?inhalt=t3
http://www.google.de/search?hl=de&q=COM+%2B+Serielle+Schnittstelle+WinAPI&meta=
-
LIN-Bus da musst Du dann halt mal die Spezifikation zu Deinem LIN-Bus halt suchen wie die Daten dort aussehen.
Also ein bisschen mehr Experimentierfreude muss man da schon haben
-
lion schrieb:
Hallo zusammen,
es soll ein Windows-GUI-Programm in C++ geschrieben werden, das auf ein seriell (LIN-Bus) angeschlossene Gerät zugreift.
Es werden Telegramme zwischen TestProgramm und Gerät ausgetauscht.
Auf einen bestimmten Befehl-Code soll das Gerät mit einer bestimmten Antwort reagieren.... Befehl B1 --> Antwort A1 , Befehl B2 --> Antwort A2 usw.
Die Aktivitäten von den verschieden Modulen im Gerät selbest sollen mit dem TestProgramm angezeigt und gespeichert (protokolliert) werden.
Wie greift man auf den seriellen Port?Hat jemand eine Idee, wie man ein Konzept erstellt und wie man an die Aufgabe rangeht !?
Für eure Unterstützung wäre ich euch sehr dankbar.
Danke, lionDa kann ich desweiteren nur sagen hol Dir entsprechende Spezifikationen von den
Geräten und eben zu den Protokollen fuer den LIN-Bus
http://carbussystems.com/pdfs/ECT2002Workshop.pdf
Wenn ich mir das so ansehen koennte man "fast" meinen es läuft wie bei
einer Kommunikation ueber das Nullmodemkabel, wenn ich das in diesem PDF so sehe. Also ein ist mal klar Du brauchst auf jedenfall auch ein Experimentierhardware sonst kannst deine Softwarelösung nichtmall testen.Bücher gibt es ueber diesen LIN-Bus nach Internetrechereche ja auch zuhauf.
LIN-Bus scheint recht neu zu sein zielt auf CAN-Bus und Netzwerke in teueren Autos ab. Also mit der Klasse fuer die Serielle-Schnittstelle kannst ja schonmal ne Brücke zur Hardware bauen. Wenn das ne Studienarbeit sein soll oderso musst doch auch ein Labor auftreiben koenne wo Du das testen kannst....
Naja ueber den Rest musst Du Dir noch nen Kopf machen
mfg sclearscreen
http://dkc3.digikey.com/PDF/DE051/0217.pdf
so nun is aber gut
und weil ich heute ganz nett bin habe ich auch noch diese PDF aus dem
Netzt ausgegraben
http://www.rubran.ch/Datenblaetter/BA%20SM-CAS-1-D-22-1-05.pdf der/die/das/ ist sehr interessant weil es die Befehle als ASCII-Zeichen zeigt und wie die eben aufgebaut sind die Befehle.Da meine Arbeit auf mich wartet mache ich mich auf den Weg
Du schickst nen Befehl (der muss immer mit ENTER-Zeichen abgeschlossen sein)
und wenn ich das richtig verstanden habe bekommst Du von der Baugruppe auch prompt ne Antwort als "Antwotbefehl" zurueck. Ist ja im letzten PDF schoen beschrieben musst halt nur die ASCII-Zeichen die Du als Response bekommst interpretieren.
Wenn Du ne Experiementieranordnung hast und somit auch weisst welche Geräte dran sind kann man sich per
#define COMMAND_GERAET_A "......"so Standardbefehle machen die Du ueber die Klasse fuer die COM-Schnittstellen
in den LIN-Bus schickst fertig ist grob gesehen der Lack.
Als Standard scheint zu sein das die Serielle-Schnittstelle im LIN-BUS mit 9600
Baud läuft. Aus dem Code fuer die Klasse wird ersichtlich das der Zugriff unter Windows auf COM 1...4 wie der Zugriff auf eine Datei ist.
-
Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum WinAPI verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Für die serielle Schnittstelle empfehle ich:
http://www.codeproject.com/system/serial.asp
-
Hallo und vielen Dank für die Antworten
Ich habe mir jetzt die Links und die Dateien, die mir gepostet haben gleich runtergeladen. Ich werde sie mir dann nachher anschauen. Merci
@sclearscreen: mit Hilfe des TestProgramms sollen die aktivitäten (Telegramme) zwischen den verschiedenen Module im (Steuer-) Gerät (ASCII-Kodiert) dargestellt werden (selbesttest). Fehler werden zuerst in einem Memory im Gerät gespeichert, die man mit dem TestProgramm abrufen kann.
Auf einen bestimmten Befehl soll das Gerät mit einer bestimmten Antwort reagieren.
Mann trägt den Befehl in einem bestimmtem Eiingabefeld und klickt dann auf die Schaltfläche "senden" und die Antwort wird dann in dem vorgesehenen Anzeigefeld angezeigt.Beispiel: die 6-stellige SEN des Gerätes ablesen (XX = 1Byte in Hex)
S: Quelle = Tester ----- WortLänge = 03 ----- Ziel = Gerät(Modul)----- Command-Byte = XX ----- Prüfsumme = XX
E: Quelle = Gerät(Modul) ----- WortLänge = 03 ----- Ziel = Tester ----- Command-Byte(s) = 52 A3 2F ----- Prüfsumme = XX
Ich habe zwar schon einige kleine Aufgaben mit C++ geschrieben (z.B. Parabelfunktion, Zahlumwandlungen, Strings-eingeben/ausgebben, usw.), aber es fehlt mir leider noch die Erfahrung und weiss noch nicht ganz genau, wie ich an die Aufgabe rangehe.
Ich muß zuerst ein Konzept für den Test erstellen, aber wie !!!
Ich werde mir jetzt zuerst die Beispiele für die COM-Schnittstelle anschauen.Bis dann.
Gruß, Lion
-
lion schrieb:
Hallo und vielen Dank für die Antworten
@sclearscreen: mit Hilfe des TestProgramms sollen die aktivitäten (Telegramme) zwischen den verschiedenen Module im (Steuer-) Gerät (ASCII-Kodiert) dargestellt werden (selbesttest). Fehler werden zuerst in einem Memory im Gerät gespeichert, die man mit dem TestProgramm abrufen kann.Laut Spezifikation von LIN-Bus wird nicht zwischen den Modulen komuniziert!
Es ist ein reines Master einer oder mehrere Slave - Verhalten!
Master ist Steuerrechner ==> Der Rechner mit deinem Testprogramm sozusagen
Einfacher Befehl an ein Gerät:
Der Master schickt eine Befehl (in Form von ASCII-Zeichen) an ein bestimmtes Gerät.Das betreffende Gerät gibt prompt Antwort zurück auch ueber eine Datenstrom (ASCII-Zeichen)
Generalbefehl:
Ist ein Befehl an alle Geräte des Bus. Generalbefehle sind Befehle die alle Geräte im Bus betreffen. Als Antwort erhälst Du immer eine Antwort von dem ersten Modul was im Bus ist, diese Antwort gilt stellvertretend fuer alle Geräte im Bus.
Das habe ich aus dem letzten PDF aus meine Post herausgelesen!
Die Kommunikation wird dann in Gang gesetzt wenn Du als letztes Zeichen
im Befehl ein Enter [CR/LF] drin hast.Beispiel in etwa:
>A01[Befehl][Enter] das schickst du ueber die COM raus die Elektronik der Modul reagiert nun so ob es ein passender Befehl da ist in dem das entsprechend Gerät
guckt ob im Befehl seine Nummer drin ist Bsp A01 dann liesst dieses Gerät
den Befehl aus und schickt prompt Antwort zurueck.
Alle Geräte lesen den Datenstrom mit es Antwortet aber nur das Gerät was seine Addressierung im Datenstrom entdeckt (Wie bei der Anwesenheitskontrolle in einer Klassen). Spricht der Master ein fasches Modul an bleibt es stumm auf der Leitung weil es diesen Kollegen eben im Bus nicht gibt.So verstehe ich das.
Man brauch laut LIN-Bus was ich gelesen habe keine Kollisonsabfrage auf dem Bus beruecksichtigen. Weil der Master immer mit einem Gerät spricht, selbst beim Generalbefehl an alle Modul wird nur A01 stellvertretend fuer alle Modul antworten. Schickst Du eine Gerätenummer die nicht existiert gehe ich davon aus
das der Eingansdatenbuffer einfach leer bleibt das kann man durch auslesen der COM prüfen.Der witz ist bei LIN-Bus eben Protokoll sehr einfach
Befehl schicken und quasi im Augenblick kommt die Antwort vom betreffenden Modul zurueck.Also bei dem Protokoll scheint es echt nach dem Prinzip zu laufen ....
Wenn der Kuchen (Master) redet haben die Krümmel (Slaves) Pause.
Ist der Master durch Versendung fertig wichtig ist das ein Befehl immer Enter
als ASCII-Zeichen enthält abgeschlosen und verschickt worden, Antwortet eben der betrefende Slave sofort (bei Generalbefehl ist Gerät A01 eben Gruppensprecher fuer alles seine Modulkollegen und spricht fuer diese mit dem Master). Nach einem quasi ganz kurzen Moment kürzer als ein Wimpernschlag hast du im Eingangspuffer eine Nachricht vom Modul Ich sehe da wirklich kein Problem wenn ich jetzt im Labor vor den Geeräten sitzen wuerde!
Ich hoffe ich konnte Dir das Prinzip was ich aus dem letzten PDF rausgelesen habe plausibel machen.
Befehl sieht nochmal grob gestrikt eben so aus:
1. Zeichenfolge fuer den Slave den der Master auswählt = A
2. Zeichenfolge/zeichen fuer den Steuerbefehl an diesen Slave = B
oder
2.1 Generalbefehl irgend ne ASCCI-Zeichenfolge = C
3. Ob Einzelmodulbefehl oder Generalbefehl ASCII-Zeichen fuer Enter = DAus diesen 4 Punkten baust du jetzt eine Sequenz die Du ueber die COM1...4
in den LIN-Bus schickst!// Pseudocode // Welche ASCII-Zeichen Zur Sprache der Master/Slave-Kumunikation wirklich genommen werden musst Du den Spezifikationen zu den Modulen entnehmen char Masterbefehl_Fuer_Einzelnes_Modul[] = "ABD"; // Bespielenzelbefehl char Masterbefehl_Fuer_Alle_Modul[] = "CBD"; // Generalbefehl //TODO: Befehl Ueber COM1 oder es gibt ja 4 COMs rauschicken .....; //TODO: Antwort ist Prompt da gleich auslesen man kann jetzt aber auch noch ne // Zeitverzögerung einbauen um den Modulen wirklich Zeit zur Antwort zu verschaffen // Auslesen aus der COM ....;Was Einzergerätebefehle sind und was Generalbefehl steht aber alles im letzten PDF.
1. Konzept Top/Down Forward Engineering: Also aus diesen Infos muesste man ein Konzept bauen koennen. Solltest Du immer noch keinen Plan haben dannn.
2.Konzept Bottom/Up Reverse Egineering: Nimm das letzte PDF und schau Dir die Beispielbefehl an. Dann nimm dir die
Spezifikation zu nem LIN-Bus aus deinem Versuchlabor in deiner FH/UNI und lies den Kram durch. Bau Dir aus diesen Info ne kleine Konsolenanwendung
die einen einfachen Befehl in diese Anordnung schickt. Versuch dann in dieser
Anwendung die erwartet Antwort diese LIN-Bus-Versuchaufbaues auszulesen.
Auf Grundlage dieser Variante mach ein paar Experimente bist Du das Verstanden hast. Bau dann darauf deine Studienarbeit auf.Spieltrieb und Experimentierfreude falls Du Angst hast nimm Dir den Laborbetreuer dazu. Wozu ist das Labor sonst da -----> zum rumfrickeln und verstehen. Der Laborbetreuer hat den Hut fuer dad Anlage auf lass Ihn Dir auch ueber die Schulter schauen.
Weiter kann ich Dir nun wirklich nicht helfen ich hoffe der Funke ist irgendwie übergesprungen.
-
includiere im Konsolenprogramm auf Basis C++ die windows.h
Kopier dir den Code der Klasse dieses Links http://www.winapi.net/index.php?inhalt=t3
in dieses Programm
Mach eine Instanz von der Klasse und nutze deren öffentliche (public)
Methoden um mit dem LIN-Bus ueber die Serielle Schnittstell zu kommunizieren.Bspcode etwa so:
#include <windows.h> #include <iostream> #include <string> using namespace std; class CSerial { public: CSerial(); // Konstruktor ~CSerial(); // Destructor BOOL Open (int, int, int, int, int); // Öffnen BOOL Close (void); // Schließen BOOL ModeSet (int, int, int, int); // Änderung int ReadData (char*); // Lesen int SendData (const char*, int); // Schreiben BOOL WriteCommByte (unsigned char); // Schreiben eines Zeichens private: HANDLE hComm; // Handle für den Zugriff DCB dcb_alt; // Um die alten Parameter zu merken COMMTIMEOUTS timeouts_alt; // Um die alten Parameter zu merken }; CSerial::CSerial() : hComm(INVALID_HANDLE_VALUE) { } CSerial::~CSerial() { Close (); } BOOL CSerial::ModeSet (int nBaud, int nBits, int nStopp, int nParity) // Ändern von Baudrate (nBaud), Bits (nBits), Parität (nParity) { if (INVALID_HANDLE_VALUE == hComm) // COM-Port überhaupt geöffnet? return (FALSE); DCB dcb; // Struktur vom Typ DCB erzeugen ZeroMemory (&dcb, sizeof(dcb)); // ..und schön löschen (wichtig!) // Die bestehenden Parameter holen. Bei Fehler ist hier Schluss! if (!GetCommState (hComm, &dcb)) { Close (); MessageBox (NULL, "Fehler beim Ändern der COM-Port Parameter\nGetCommState()", NULL, NULL); return (FALSE); } // neue Parameter in die Struktur kopieren (Baud: z.B. 9600) dcb.BaudRate = nBaud; // neue Parameter in die Struktur kopieren (Bits: z.B. 7 oder 8) dcb.ByteSize = (BYTE)nBits; // neue Parameter in die Struktur kopieren (Parität:(siehe MSDN)) dcb.Parity = (BYTE)nParity; // Anzahl Stoppbits (siehe MSDN) dcb.StopBits = (BYTE)nStopp; // neue Parameter setzen. Bei Fehler ist hier Schluss! if (!SetCommState (hComm, &dcb)) { Close (); MessageBox (NULL, "Fehler beim Ändern der COM-Port Parameter\nSetCommState()", NULL, NULL); return (FALSE); } return (TRUE); // fertig } // Öffnen von / mit Portnummer (nPort), Baudrate (nBaud), Bits (nBits), Stoppbits (nStopp), Parität (nParity) BOOL CSerial::Open (int nPort, int nBaud, int nBits, int nStopp, int nParity) { if (INVALID_HANDLE_VALUE != hComm) // COM-Port überhaupt geöffnet? return (TRUE); char szPort[15]; // Aus einer "1" in nPort schreiben wir so "COM1" in szPort z.B.. wsprintf (szPort, "\\\\.\\COM%d", nPort); hComm = CreateFile (szPort, // COM-Port öffnen GENERIC_READ | GENERIC_WRITE, // wir wollen lesen und schreiben 0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); // nicht OVERLAPPED, wir holen uns den Port exclusiv if (hComm == INVALID_HANDLE_VALUE) // hat es geklappt? Bei Fehler ist hier Schluss! { MessageBox (NULL, "Fehler beim Öffnen des COM-Ports!\nCreateFile()", NULL, NULL); return (FALSE); } // Alte Timeouts merken. Bei Fehler ist hier Schluss! if (!GetCommTimeouts(hComm, &timeouts_alt)) { Close (); MessageBox (NULL, "Fehler beim Öffnen des COM-Ports!\nGetCommTimeouts()", NULL, NULL); return (FALSE); } // Eine Struktur vom Typ COMMTIMEOUTS erzeugen und neue Timeouts setzen COMMTIMEOUTS timeouts; timeouts.ReadIntervalTimeout = 200; timeouts.ReadTotalTimeoutMultiplier = 200; timeouts.ReadTotalTimeoutConstant = 200; timeouts.WriteTotalTimeoutMultiplier = 200; timeouts.WriteTotalTimeoutConstant = 200; // Neue Timeouts setzen. Bei Fehler ist hier Schluss! if (!SetCommTimeouts(hComm, &timeouts)) { Close (); MessageBox (NULL, "Fehler beim Öffnen des COM-Ports!\nSetCommTimeouts()", NULL, NULL); return (FALSE); } DCB dcb; // Struktur vom Typ DCB erzeugen ZeroMemory (&dcb, sizeof(dcb)); // ..und schön löschen (wichtig!) // Die bestehenden Parameter holen. Bei Fehler ist hier Schluss! if (!GetCommState (hComm, &dcb)) { Close (); MessageBox (NULL, "Fehler beim Öffnen des COM-Ports!\nGetCommState()", NULL, NULL); return (FALSE); } dcb_alt = dcb; // alte Parameter sichern dcb.DCBlength = sizeof(DCB); dcb.fBinary = TRUE; // muss immer "TRUE" sein! dcb.fParity = TRUE; dcb.fOutxCtsFlow = FALSE; dcb.fOutxDsrFlow = FALSE; dcb.fDtrControl = DTR_CONTROL_ENABLE; dcb.fDsrSensitivity = FALSE; dcb.fTXContinueOnXoff = TRUE; dcb.fOutX = FALSE; dcb.fInX = FALSE; dcb.fErrorChar = FALSE; dcb.fNull = FALSE; dcb.fRtsControl = RTS_CONTROL_ENABLE; dcb.fAbortOnError = FALSE; dcb.wReserved = 0; // muss immer "0" sein! // neue Parameter in die Struktur kopieren (Baud: z.B. 9600) dcb.BaudRate = nBaud; // neue Parameter in die Struktur kopieren (Bits: z.B. 7 oder 8) dcb.ByteSize = (BYTE)nBits; // neue Parameter in die Struktur kopieren (Parität:(siehe MSDN)) dcb.Parity = (BYTE)nParity; // Anzahl Stoppbits (siehe MSDN) dcb.StopBits = (BYTE)nStopp; dcb.fParity = (dcb.Parity != NOPARITY); // neue Parameter setzen. Bei Fehler ist hier Schluss! if (!SetCommState (hComm, &dcb)) { Close (); MessageBox (NULL, "Fehler beim setzen der COM-Port Parameter\nSetCommState()", NULL, NULL); return (FALSE); } return(TRUE); } BOOL CSerial::Close (void) { if (INVALID_HANDLE_VALUE == hComm) // COM-Port überhaupt geöffnet? return(TRUE); if (!SetCommTimeouts(hComm, &timeouts_alt)) { MessageBox (NULL, "Fehler beim Schließen des COM-Ports\nSetCommTimeouts()", NULL, NULL); return (FALSE); } // alte Parameter zurückschreiben. Bei Fehler ist hier Schluss! if (!SetCommState (hComm, &dcb_alt)) { MessageBox (NULL, "Fehler beim Schließen des COM-Ports\nSetCommState()", NULL, NULL); return (FALSE); } CloseHandle (hComm); // Port schließen hComm = INVALID_HANDLE_VALUE; // das Handle zurücksetzen return (TRUE); } BOOL CSerial::WriteCommByte (unsigned char ucByte) // Das zu übertragene Byte (ucByte) { if (INVALID_HANDLE_VALUE == hComm) // COM-Port überhaupt geöffnet? return(FALSE); // ein Zeichen direkt übertragen. Bei Fehler ist hier Schluss! if (!TransmitCommChar(hComm, ucByte)) { MessageBox (NULL, "Fehler beim Schreiben auf COM-Port!\nTransmitCommChar()", NULL, NULL); } return (TRUE); } int CSerial::SendData (const char *buffer, int iBytesToWrite) // Buffer (*buffer), mit den zu sendenen Zeichen und deren Anzahl (iBytesToWrite) { if(INVALID_HANDLE_VALUE == hComm) // COM-Port überhaupt geöffnet? return(0); DWORD dwBytesWritten = 0; // die angegebene Anzahl der Bytes schreiben WriteFile(hComm, buffer, iBytesToWrite, &dwBytesWritten, NULL); return ((int) dwBytesWritten); // die Anzahl der geschriebenen Bytes zurückgeben } int CSerial::ReadData (char *buffer) // Buffer (*buffer), der die Zeichen bekommt { if (INVALID_HANDLE_VALUE == hComm) // COM-Port überhaupt geöffnet? return(0); DWORD dwRead = 0; char chRead; int i = 0; while (ReadFile(hComm, &chRead, 1, &dwRead, NULL)) // wurde ein Zeichen gelesen? { if (dwRead != 1) // ..wenn nicht, dann ist hier Schluß break; buffer[i++] = chRead; // wann ja, dann das Zeichen in den Buffer schreiben } return (i); // die Anzahl der gelesenen Bytes zurückgeben } //////////////////////////////////////////////////////////////////// // Hauptprogramm int main(void) { CSerial SerielleSchnittstelle; /* Versuch COM 1 mit 9600 Baud, 8 Datenbits 1 Stopbit etc zu öffnen */ if(SerielleSchnittstelle.Open(1,9600,8,1,0) == TRUE) { // Befehl fuer Modul 1 im LIN-Bus aufbauen char buffer[] = "........."; // Befehl an Modul 1 schicken int nBytesToSend = strlen(buffer); int nBytes = SerielleSchnittstelle.SendData(buffer, nBytesToSend); if(nBytes == nBytesToSend) // Daten erfolgreich in LIN-Bus geschickt { // TODO: eventuell hier enine kleine Verzögerung einbauen um Modul 1 Zeit zum Antworten zu geben ...; // Antwort des LIN-Busmodul 1 auslesen char Response[255]; int nBytesRead = SerielleSchnittstelle.ReadData(Response); // Antwort des Modul 1 ausgeben cout << Response << endl; SerielleSchnittstelle.Close(); } else // Fehler beim schreiben der Daten in COM 1 aufgetreten { cout << "Es besteht eine Diskrepanz beim Schreiben der Daten ueber die COM1 zum LIN-Bus" << endl; } } else { cout << "COM1 nicht bereit" << endl; } cin.get(); return 0; }Also jetzt habe ich dir mit dem Code also fast alles in den Mud gelegt und vorgekaut. Eine Versuchanordnung werde ich mir nicht extra kaufen
Nimm dad Besielcode und pass es fuer deine Sachen an. Sorry fuer die Einrueckungen habe ich jetzt keinen Draht mehr. kopier obiges in deine IDE
und modifiziere es wie Du es brauchst.
-
Hallo sclearscreen,
Danke nochmal für die ausführliche Erklärung, die mir auf jeden Fall ein Stück weitergebracht hat.Beim Themabeschreibung ist mir leider (indirekt) ein Verständnisfehler unterlaufen und zwar über das Bussystem, das hier verwendet wird.
Die (kurze) Beschreibung des Studienarbeitsthema habe ich mündlich von unserer Fachbereichsskretärin (als Stellvertreterin vom zuständigen Dozent, der krank war) erhalten, die ich auch hier im Beitrag weitergegeben habe.Heute habe die Email mit der genaueren Themabeschreibung vom zuständigen Dozent erhalten... richtig gesagt "gelesen", da das Erhalt-Datum vom Freitag war.
In der Beschreibung wird I/K-Bus als Bussystem verwendet und nicht LIN-Bus, wie mir die Sekretärin gesagt hat.I/K und LIN Busssysteme habe die gleiche ISO-Standard 9141
sclearscreen schrieb:
Laut Spezifikation von LIN-Bus wird nicht zwischen den Modulen komuniziert!
Es ist ein reines Master einer oder mehrere Slave - Verhalten!
Master ist Steuerrechner ==> Der Rechner mit deinem Testprogramm sozusagen
Am I-Bus werden neben dem Steuergerät andere TLN angeschlossen (z.B. NAVI, RADIO, MID, KOMBI ...)
Zwischen die TLNs werden auch Telegramme ausgetauscht.
Beispiel 1: ein TLN fordert die Klemmenstatus vom KOMBI an.
Beispiel 2: CD Changer Command vom RADIO zu CD-Wechsler.Um die Telegramme zwischen den verschieden Teilnehmern zu "belauschen", soll dann beim Start des TestProgramms veranlasst werden, dass der COM-Port offen sein soll !!?
sclearscreen schrieb:
Auf Grundlage dieser Variante mach ein paar Experimente bist Du das Verstanden hast. Bau dann darauf deine Studienarbeit auf.
Spieltrieb und Experimentierfreude falls Du Angst hast nimm Dir den Laborbetreuer dazu. Wozu ist das Labor sonst da -----> zum rumfrickeln und verstehen. Der Laborbetreuer hat den Hut fuer dad Anlage auf lass Ihn Dir auch ueber die Schulter schauen.
Mein erster Arbeitsstag ist erst am 01.06. Ich muss mich noch 10 Tage gedulden, bis ich was experementieren kann. Ich hoffe, dass mir dabei der Labor-Ing. ein wenig unterstützt.
Gruß, Lion