RS-232 Schnittstelle
-
Vielleicht kannst Du mir das mal zeigen, wie man ein Ereignis behandelt, das von der COM Schnittstelle ausgelöst wird .. bin noch C++ Barfussläufer

Gruß
daMike
-
Da sind doch Beispiele dabei, oder? Was willst Du denn noch für Beispiele?
-
Ja es sind Beispiele dabei. Selbst wenn man das nicht bis ins Detail versteht kann man das zumindest ableiten. Ich hab das mal nur zum Testen mit festen Einstellungen und manueller Initialisierung gemacht. Realisiert hab ich das so (hab es im View meiner Anwendung stehen):
In der Header meines View:public: CSerialMFC m_serial; .... public: LRESULT OnSerialMsg (WPARAM wParam, LPARAM lParam); afx_msg void OnSchnittstelleStart();void CSerial2View::OnSchnittstelleStart() { // TODO: Fügen Sie hier Ihren Befehlsbehandlungscode ein. m_serial.Open(_T("COM1"),this,WM_NULL,0,0,0); m_serial.Setup(CSerialMFC::EBaud1200,CSerialMFC::EData7,CSerialMFC::EParNone,CSerialMFC::EStop2); m_serial.SetupHandshaking(CSerialMFC::EHandshakeHardware); }Anstatt des This-Zeigers kannst Du auch direkt den Zeiger des Fensters übergeben, in dem die Behandlung stattfinden soll. WM_NULL und die letzten drei Parameter kannst Du glaub ich auch weglassen.
Die Setupanweisung musst Du auf Deine Bedürfnisse zuschneiden. Dann muss noch die Nachrichtenbehandlung implementieren.
// CSerial2View IMPLEMENT_DYNCREATE(CSerial2View, CView) BEGIN_MESSAGE_MAP(CSerial2View, CView) // Standarddruckbefehle ON_COMMAND(ID_FILE_PRINT, CView::OnFilePrint) ON_COMMAND(ID_FILE_PRINT_DIRECT, CView::OnFilePrint) ON_COMMAND(ID_FILE_PRINT_PREVIEW, CView::OnFilePrintPreview) ON_WM_SERIAL(OnSerialMsg) //Nachrichtenbehandlung der WM_NULL der Klasse CSerialMFC ON_COMMAND(ID_SCHNITTSTELLE_SENDD, OnSchnittstelleSendd) ON_COMMAND(ID_SCHNITTSTELLE_START, OnSchnittstelleStart) END_MESSAGE_MAP()LRESULT CSerial2View::OnSerialMsg (WPARAM wParam, LPARAM lParam) { const CSerialMFC::EEvent eEvent = CSerialMFC::EEvent(LOWORD(wParam)); const CSerialMFC::EError eError = CSerialMFC::EError(HIWORD(wParam)); //Behandlung der auftretenden Möglichkeiten if (eError) .... if (eEvent & CSerialMFC::EEventBreak) .... if (eEvent & CSerialMFC::EEventError) .... if (eEvent & CSerialMFC::EEventRcvEv) .... if (eEvent & CSerial::EEventRing) .... if (eEvent & CSerialMFC::EEventSend) .... if (eEvent & CSerialMFC::EEventCTS) .... if (eEvent & CSerialMFC::EEventDSR) .... if (eEvent & CSerialMFC::EEventRLSD) .... if (eEvent & CSerial::EEventRecv) ... return 0; }Beim Beenden natürlich das hier nicht vergessen:
CSerial2View::~CSerial2View() { if (m_serial.IsOpen()) m_serial.Close(); }Bei mir läuft das soweit ganz gut.
-
Es funktioniert!!!
Habe jetzt bei CSerialMFC::EEventRecv ein sleep(100) eingefügt, damit die komplette Message in meinen Buffer wandert. Kann man das besser manchen?
Besten Dank an alle!!
Gruß
daMike
-
Ja! Du musst warten bis alle Daten da sind!!!
I.d.R. hat das "Protokoll" entweder eine Ende-Marke oder die Länger ist sonstwie irgendwie implizit/explizit bekannt...
-
Das mit dem Sleep finde ich nicht so gut. Jochen hat Recht: entweder Du weißt wie lang die Datenkette ist oder Du hast ein Ende-Zeichen was Du auswertest.
@Jochen: ich hab momentan das Gefühl das die Daten sehr langsam rüberkommen. Kann das leider nicht quantifizieren, da ich es noch nicht gemessen habe. Woran kann das liegen?
-
OK! Nun läuft es soweit ganz gut, NUR muss ich das ganze für insgesamt 4 COM Schnittstellen parallel laufen lassen! Kann ich dieses ...
LRESULT OnSerialMsg (WPARAM wParam, LPARAM lParam);COM-Portspezifisch definieren?
-
Das ist eine gute Frage. Habe bisher nur immer eine Schnittstelle bearbeitet. Habe dazu zwei Ideen ohne zu wissen ob die richtig sind oder funktionieren.
1. Unterschiedliche Windows-Messages
Bei Initialiseren kann man doch als Parameter eine Message übergeben. Wenn man die unterschiedlich macht könnte man anhand der Message erfragen, woher der Event gerade kommt.2. Verknüpfung der einzelnen Schnittstellen an eigene Views
Für jede Schnittstelle wird ein eigenes Fenster (View) geschaffen. Jedes View hat ja eine eigene Messagemap in der dann die Events verarbeitet werden.Kann mir gut vorstellen das letzteres funktioniert. Aber vielleicht liege ich ja auch total falsch.
Have a nice weekend....
-
Hallo, bin immer noch an der RS-232 dran .. habe auf der http://www.codeproject.com/system/serial.asp folgendes gefunden ..
I am using 4 serial ports to receive and transmit to 4 devices.
I have extended the CSerialEx class as my application is Win32
Console application, running on Windows 98. I have masked the
class the set an event of reception of an event character, 0x0a.
The data from the devices comes in about every half a second and
is about 100 to 150 bytes long.Könnt Ihr damit was anfangen?
Gruß
daMike
-
Ist da irgendwo eine Frage darin versteckt? Das ist doch nur eine Aussage...
-
Indirekt schon
Habe keine Ahnung was er meint, bzw. gemacht hat, damit er mehr als einen Port verwenden kann?!? Wie kann ich die Events der 4 RS-232 portselektiv gestalten?
-
Du hättest mal zu Ende lesen sollen.
I am using 4 serial ports to receive and transmit to 4 devices. I have extended the CSerialEx class as my application is Win32 Console application, running on Windows 98. I have masked the class the set an event of reception of an event character, 0x0a. The data from the devices comes in about every half a second and is about 100 to 150 bytes long.
The problem. Everything runs pretty good except that sometimes the data received from one port( device ) gets mapped to data from another port. For example, data supposedly from port 3, gets read in from port 4. It is as if, the ports are not unique and independent sometimes.
Does any one know how to resolve this?
Found the problem...in the demo app. where the data is read in(below), the array abBuffer is declared as static. The price you pay for just copyiong and pasting i guess
// Read data, until there is nothing left
DWORD dwBytesRead = 0;
BYTE abBuffer[100];
do
{
// Read data from the COM-port
serial.Read(abBuffer,sizeof(abBuffer),&dwBytesRead);
if (dwBytesRead > 0)
{
// TODO: Process the data
}
}
while (dwBytesRead == sizeof(abBuffer));Frage ist da auch keine drin versteckt. Ich denke aber, dass es Dein Problem trotzdem nicht löst. Hast Du das mal mit den verschiedenen Views ausprobiert?
Es steht ja jetzt immer noch die Frage im Raum ob man eine Nachrichtenbehandlungsroutine schreibt und in der dann rausfinden muss, von welcher Schnittstelle die Message kommt oder durch unterwschiedliche Messages verschiedene Routinen bedient werden.
-
Prinzipiell wäre es mir egal, von welchem Port die Daten kommen! Anhand der Message (header) kann ich den Port nachträglich identifizieren. Nun kann ich an alle COM-Ports senden, aber nur von COM1 empfangen, d.h. nur bei COM1 wird ein Event ausgelöst. Kann ich die anderen 3 Ports über die gleiche Schiene laufen lassen?
-
Warum nicht? Du musst einfach nur drei Instanzen der CSerialMFC erzeugen...
-
Sorry, habe nur von COM1 gelesen!! Mein Fehler! Was passiert eigentlich, wenn sich das Event von COM1 und COM2 überschneiden? Können Daten verloren gehen? Arbeite mit 115200Baud!!
-
Warum sollen da Daten verloren gehen? Die Events kommen ja bei Dir nacheinander an...
-
Ich habe 2 GPS Empfänger mit jeweils 2 COM Ports! Auf jedem PORT gebe ich eine bestimmt Message (v, Position, etc.) aus, d.h. das alle 4 Ports im 10Hz/100Hz Takt Daten an mich schicken. Wenn ich mit RTS/CTS übertrage, sollte es keine Probleme geben, oder?
-
daMike schrieb:
Wenn ich mit RTS/CTS übertrage, sollte es keine Probleme geben, oder?
kommt drauf an. wenn deine datenquellen schneller senden als du's abholst ist flusskontrolle ein 'muss', wenn du schneller bist brauchste es nicht. windoofs puffert rs232 daten. die puffergrösse kannste einstellen mit 'SetupComm' und den momentanen füllstand bekommste mit 'ClearCommError'.
-
Hey, nach längerer Zeit wieder eine Frage zur seriellen Schnittstelle ..
Daten empfangen und senden funktioniert .. sobald ich aber einen anderen Prozess anstoße, wird dieser durchgearbeitet und die Prozessorlast geht sofort auf 100%.
Ich empfange Daten im 1Hz Takt mit einer Messagelänge von ca. 150Byte! Schätze mal, dass der Header der ankommenden Daten nach FIFO Prinzip unbearbeiten durch den Buffer geschoben wird und meine Event-RoutineOnSerialMsg
dann vergeblich versucht aus den restlichen Daten schlau zu werden! Manchmal fängt sich die Event-Routine wieder .. evtl. davon abhängig wo er nach der Berechnung datenmäßig einsteigt?!?
Kann man paralle Berechnungen mit "niedriger Priorität" versehen, dass immer die COM Schnittstellendaten sauber behandelt werden, d.h. nur wenn keine Daten ankommen die prallele Berechnung durchgeführt/vorgesetzt wird??
Gruß
daMike
-
Ich verstehe Dein Problem nicht ganz...
Du musst ja irgendwie erkennen, wann Deine Nachricht beginnt... die Daten kommen ja meistens nicht gemeinsam an, sondern in mehreren "Happen"...Was das allerdings mit der Prozessorlast zu tun haben soll verstehe ich nicht ganz...