Forum: PC-Programmierung alte Turbo-C-Software unter win95 neu für WIN10.


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Walter L. (Gast)


Lesenswert?

Hallo,

ich würde mich über ein paar Tipps freuen, die helfen, mein Problem zu 
lösen.

Das ist vorhanden:

Konsolen-Software Source-Code geschrieben in Turbo-C unter win95. Über 
die Tastatur sind Zahlen eintippbar. Diese Zahlen stellen Befehle dar. 
Diese Befehlszahlen reichen von 3 bis 151.
Nach dem Eintippen des Befehls und ENTER werden  11 Byte 
unterbrechungsfrei über eine COM-Schnittstelle des PCs (9600 BAUD…) an 
eine CNC-Elektronik geschickt.
Diese reagiert mit einer bekannten Quittung usw. Das Protokoll ist 
bekannt.

Meine Vorstellung für eine neue Software unter WIN10:

Auf dem PC-Bildschirm sind die Bef‘s als kleine „Bef-Schalter“ sichtbar, 
die mit der Mouse angeklickt werden können. Beim Anklicken werden die 11 
Byte unterbrechungsfrei mit der entsp. Info gesendet und das Programm 
erledigt den Rest.

Oder es gibt ein kleines Eingabefeld, in das  ich die Bef.-Nummer 
eingeben kann und dann mit einem Start-Botton wird der Bef. an die CNC 
geschickt.

Auch eine Konsolenanwendung ist denkbar, wie mom. realisiert.

Mein Problem:

1.  Einen zu kaufenden USB-COMPORT-ADAPTER, der diese 11 Byte 
unterbrechungsfrei an die CNC sendet und auch Daten von der CNC 
empfängt.
2.  Ist das mit der kostenlosen  VISUAL STUDIO 2022 Umgebung zu 
schaffen?
3.  Welche Prog.-Sprache würdet ihr nehmen (C oder  BASIC, vorausgesetzt 
das geht mit der kostenlosen  VISUAL STUDIO 2022 Umgebung)?

Kenntnisse:

In VISUAL STUDIO 2022 habe ich eine C-Konsolenanwendung geschrieben, die 
aus einem File ein Kennwort sucht, und nach dem Finden den TEXT nach dem 
Kennwort ausgibt.

Frühere Erfahrungen mit USB-COMPORT-ADAPTER und der zugehörigen Software 
(MFC), die beim Senden der 11 Bytes zwischendrin eine Pause einlegte, 
was die CNC als Fehler interpretierte. Dieses Problem wurde damals nicht 
gelöst, und deswegen wurde die Sache abgebrochen.

Danke für  Antworten.

VG Walter

von Harald K. (kirnbichler)


Lesenswert?

Walter L. schrieb:
> Konsolen-Software Source-Code geschrieben in Turbo-C unter win95.

Das ist also einfach ein DOS-Programm.

Walter L. schrieb:
> Frühere Erfahrungen mit USB-COMPORT-ADAPTER und der zugehörigen Software
> (MFC), die beim Senden der 11 Bytes zwischendrin eine Pause einlegte,
> was die CNC als Fehler interpretierte. Dieses Problem wurde damals nicht
> gelöst, und deswegen wurde die Sache abgebrochen.

Hätte man aber lösen können. Wenn man mit der seriellen Schnittstelle 
auf die falsche Weise umgeht, passiert sowas, macht mans richtig, 
passiert das nicht.

Hast Du den Quelltext von dem damaligen Versuch noch?

von Walter L. (Gast)


Lesenswert?

>Hast Du den Quelltext von dem damaligen Versuch noch?

Nein.

In WIN10 V1809 (2018) hat sich da wohl einiges getan. Siehe
Serieller USB-Treiber (Usbser.sys)

VG Walter

von Motopick (motopick)


Lesenswert?

Das hat man doch in VB6 in einer Stunde zusammengeklickt. :)
Das haben sogar Elektor-Autoren geschafft.
Fuer die RS-232 gibt es eine DLL fuer VB6.

von Harald K. (kirnbichler)


Lesenswert?

Walter L. schrieb:
> In WIN10 V1809 (2018) hat sich da wohl einiges getan. Siehe
> Serieller USB-Treiber (Usbser.sys)

Das ist völlig irrelevant. Komplett falsche Fährte. USB-Seriell-Adapter 
lassen sich unter Windows schon sehr, sehr viel länger ohne Probleme 
verwenden. Die meisten nutzen eh' nicht den von MS zur Verfügung 
gestellten Standardgeräteklassentreiber, sondern ihren eigenen 
proprietären, denn die meisten USB-Seriell-Adapter sind keine 
CDC-Devices.

So ist es bei SiLabs, FTDI, WinChipHead, Prolific ...

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Wenn die Befehlszahlen alle bekannt sind, würde ich eine
Listbox in VB nehmen. Die Klicks in der Listbox kann man
ja auch abfragen. Oder auch eine Gridbox, wenn noch mehr
Infos über die entsprechende Befehlszahl angezeigt werden
sollen. Das spart halt durch das vertikale Scrollen einiges
an Platz. Man könnte auch eine Groupbox mit Radiobuttons
nehmen. Kommt halt ganz auf deinen Geschmack und Platz an.
Da geht ja einiges. Auch Auswahlboxen würden sich evtl. eignen.

Als Konsolenanwendung würde ich das nicht mehr machen.

: Bearbeitet durch User
von Walter L. (Gast)


Lesenswert?

ich habe hier ein paar cp210x liegen. Aber damit wollte ich nun nicht 
mit anfangen zu basteln.

Welchen USB-COMPORT-Adapter kann man kaufen?

VG Walter

von Walter L. (Gast)


Lesenswert?

Ich merke schon. Es geht in Richtung VB.
VB müßte ich aber dann mir neu aneignen.
Wenn ich das so lese mit "Groupbox mit Radiobuttons ...."

Da wäre mir doch C lieber.

Oder jemand hat ein VB-Beispielcode, den ich in Visaul Studio VB 
reincopieren kann. Dann muss aber auch der entsprechende USB_COM_ADABTER 
bekannt sein.

VG Walter

von Hans (ths23)


Lesenswert?

Walter L. schrieb:
> Da wäre mir doch C lieber.

Ne grafische Oberfläche mit C ist aber dann schon sehr ambitioniert, 
wenn das überhaupt funktioniert.

Wenn es eine grafische Oberfläche werden soll dann führt eigentlich kein 
Weg an einer passenden IDE, wo man die Oberfläche in wenigen Minuten 
zusammen geklickt hat vorbei. Ob das am Ende z.B. Qt mit C++, 
Visualstudio (C#, .NET), Delphi/Lazarus (Pascal) oder eben auch VB wird 
ist für's erste erst mal egal. Das Zusammenbauen der GUI funktioniert 
bei allen so ziemlich gleich. Der unvermeidbare Code der zum Auswerten 
der Klickevents nötig ist, ist je nach Programmiersprache natürlich 
unterschiedlich, aber kein Teufelswerk.

Ich kann das jetzt mal auf die Schnelle für Delphi erläutern. Da braucht 
es im Wesentlichen eine Liste, wo die ganzen Befehle namentlich drin 
stehen. Die Liste gibt es fix und fertig als Komponente, d.h. man zieht 
sie einfach auf ein Formular. Für das Füllen der Liste mit Einträgen 
gibt es einen Inplaceeditor der Komponente. Jeder Eintrag hat je nach 
Position in der Liste eine Nummer beginnend bei 0. Jetzt muß man nur 
noch definieren was passieren soll, wenn man auf so einen Eintrag 
klickt. Dafür gibt es eine vorgefertigte Eventfunktion, die man nur noch 
mit dem gewünschten Code füllen muß, also Nummer des Eintrags ermitteln 
und die Nummer dann einfach über die serielle Schnittstelle senden. Für 
die serielle Schnittstelle gibt es auch Komponenten mit allen was dazu 
gehört (auch Terminalkomponente, da könnte man sehen was die CNC 
antwortet). Die serielle Schnittstellenkomponente funktioniert mit allen 
vom PC angezeigten Schnittstellen.

: Bearbeitet durch User
von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Walter L. schrieb:
> Da wäre mir doch C lieber.

Na gut, wenn du ja schon mit C klarkommst oder kannst, nimm dir halt
einen C-Compiler und bau dir deine Anwendung zusammen. Aber, wenn du
noch nie eine GUI programmiert hast, wird das so oder so schwierig
für dich. Sicher, man kann solche Buttons auch in einer Konsole-
Anwendung nachempfinden, indem man einfach farbige Kästchen malt
und die Mauskoordinaten entsprechend abfragt. Bloß wird das für
ca. 100 Buttons ein riesiger Aufwand.

Oder such dir eine Sprache, mit der du am besten klar kommst.
VB hat halt den Vorteil, daß man seine GUI (Bedienoberfläche)
zusammenklickt. VB stellt dir dann automatisch die Button-Klicks als
Unterprogramme bereit, die du dann nur noch mit Leben füllen
brauchst (Befehl senden). Ist ja heutzutage kein Hexenwerk mehr.

Was den Adapter betrifft : am besten einer mit FTDI-Chip.
Persönlich kann ich den Digitus empfehlen.
https://www.amazon.de/DIGITUS-70156-Typ-Konverter-Verl%C3%A4ngerungskabel/dp/B0030IT780/ref=asc_df_B0030IT780?tag=bingshoppin0b-21&linkCode=df0&hvadid=80814161469019&hvnetw=o&hvqmt=e&hvbmt=be&hvdev=c&hvlocint=&hvlocphy=&hvtargid=pla-4584413736836314&psc=1

Und die cp210x - Treiber sind ja auch gut.

: Bearbeitet durch User
von Th S. (osszilierer)


Lesenswert?

Ich programmiere in Delphi und benutze nur Adapter mit FTDI Chip, dann 
im COM Treiber die Empfang und Sendebuffer auf 64 Byte stellen und die 
Polling Zeit über USB auf 2ms, dann das Protokoll mit 11 Byte in den 
Buffer schreiben und die kommen lückenlos am Empfänger an. Benutze als 
COM Treiber in Delphi dann CPORT, zwar mit eigenen Erweiterungen aber 
der normale sollte auch klappen

von Hmmm (hmmm)


Lesenswert?

Walter L. schrieb:
> Welchen USB-COMPORT-Adapter kann man kaufen?

Irgendwas mit FTDI-Chip, die sind i.d.R. stressfrei. Aber besser nicht 
billig bei Aliexpress kaufen, die Treiber des Herstellers mögen keine 
gefälschten FT232.

Hans schrieb:
> Ne grafische Oberfläche mit C ist aber dann schon sehr ambitioniert,
> wenn das überhaupt funktioniert.

Das geht ohne Probleme, aber dafür muss man sich mit der Windows-API 
befassen. Definitiv kein Anfängerprojekt.

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Hmmm schrieb:
> Das geht ohne Probleme, aber dafür muss man sich mit der Windows-API
> befassen. Definitiv kein Anfängerprojekt.

Daher sollte er sich auch eine Sprache nehmen, die die Windows-API
weitestgehend kapselt (versteckt). Wenn er sich damit auch noch
rumschlagen muß, wird das nichts.

Zuerst müssen wir ja mal wissen, wie der Wissensstand von
Walter L. ist. Oder hat er überhaupt schon mal programmiert.

von Hans (ths23)


Lesenswert?

Th S. schrieb:
> benutze nur Adapter mit FTDI Chip, dann
> im COM Treiber die Empfang und Sendebuffer auf 64 Byte stellen und die
> Polling Zeit über USB auf 2ms, dann das Protokoll mit 11 Byte in den
> Buffer schreiben und die kommen lückenlos am Empfänger an.
Also bei der COM-Port Komponente von Delphi, mußte ich noch nie 
irgendwelche Klimmzüge machen. Da funktionieren i.d.R. alle seriellen 
Ports die unter Windows angezeigt werden problemlos.

Was mir aber im Zusammenhang mit Ansteuerung externer Gerätschaften über 
eine beliebige Schnittstelle (LAN, RS232 etc.) aufgefallen ist, das es 
Probleme gibt wenn für die benutzte Schnittstelle irgendwelche 
Energiesparmodi aktiv sind. Da ist es mir schon öfter passiert das die 
Verbindung abbricht, weil Windows der Meinung war die Schnittstelle 
temporär abzuschalten, weil sie ja eh nichts macht. Speziell in Richtung 
von extern zum PC ist mir das aufgefallen, kann aber auch in die andere 
Richtung zu Problemen führen. Ich bin bisher immer gut damit gefahren 
den jegliche Energiesparmodi für diese Schnittstellen im Gerätemanager 
zu deaktivieren - hat mich bisher auch nicht in den finanziellen Ruin 
getrieben. Das bloß mal so als Denkanstoß, wo man auch mal bei Problemen 
nachschauen sollte.

von Udo K. (udok)


Angehängte Dateien:

Lesenswert?

Walter L. schrieb:
> Ich merke schon. Es geht in Richtung VB.
> VB müßte ich aber dann mir neu aneignen.
> Wenn ich das so lese mit "Groupbox mit Radiobuttons ...."
>
> Da wäre mir doch C lieber.
>
> Oder jemand hat ein VB-Beispielcode, den ich in Visaul Studio VB
> reincopieren kann. Dann muss aber auch der entsprechende USB_COM_ADABTER
> bekannt sein.
>
> VG Walter

Das kannst du auch in VS in 10 Minuten zusammenklicken.  Die serielle 
Schnittstelle hat schon seit Ewigkeiten einen Zeichenbuffer, der 
zumindest 16 Bytes gross ist.  Die ganzen USB <-> RS232 Konverter haben 
auch einen Buffer, der allerdings viel grösser ist. Du musst nach jedem 
11 Byte Befehl "Flush Buffer" ausführen, sonst wartet der USB Kontroller 
bis sein interner Buffer überläuft, und schreibt dann halbe Kommandos. 
Das Timing ist übrigens sehr reproduzierbar auf < 1 ms unter Win10.

Ich habe mir den Spass gemacht, und dir eine Win32 Anwendung mit 32 
Buttons zusammengeklickt.
Das hat kürzer gedauert, als diesen Beitrag zu verfassen.  Die Buttons 
sind aber im Help Dialog drinnen.
Den Dialog kannst du beim Start ausfüren. Jetzt musst du nur noch jeden 
Button mit einer SendCommando() Funktion versehen, und beim 
Programmstart die Serielle Schnittstelle mit OpenFile aufmachen.
Die 11 Bytes schreibst du dann mit WriteFile() in die RS232.

von Re D. (re_d228)


Lesenswert?

Hans schrieb:
> Wenn es eine grafische Oberfläche werden soll dann führt eigentlich kein
> Weg an einer passenden IDE, wo man die Oberfläche in wenigen Minuten
> zusammen geklickt hat vorbei.

Quatsch mit wx-Python o.Ä. hat man die Anwendung schneller geschrieben 
und ist universeller unterwegs als mit klicki bunti.

von Udo K. (udok)


Angehängte Dateien:

Lesenswert?

Ich habe dir noch ein Update gemacht, jeder der 32 Buttons ist mit einer 
Funktion verbunden, die einen String in ein Edit-Control reinschreibt.
Das kannst du als Startpunkt verwenden, wenn du möchtest.
Gruss, Udo

von Rbx (rcx)


Lesenswert?

Man könnte auch den Open Watcom Compiler nutzen. DOS geht zwar nicht 
mehr ohne EMU, aber 32 Bit. Dos-Konsole-Code kann man auch über den 
32bit-Linker in 32Bit-ProtectedMode übersetzen.

von Hans (ths23)


Lesenswert?

Re D. schrieb:
> Quatsch mit wx-Python o.Ä. hat man die Anwendung schneller geschrieben
> und ist universeller unterwegs als mit klicki bunti.
Ja alles klar Du schreibst ein paar Zeilen Code schneller, als ich ein 
Widget auf ein Formular ziehe - träum weiter.

von Walter L. (Gast)


Lesenswert?

Danke Udo, ich versuche das am Wochenende und melde mich dann...
VG Walter

von Εrnst B. (ernst)


Lesenswert?

Simples HTML-File mit Buttons und Javascript?
1
        const port = await navigator.serial.requestPort();
2
        await port.open({ baudRate: 9600 });
3
...
4
    <button onclick="sendCommand(1,'ABC123xxx')">Command 1</button>

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Billiges Mikrocontroller-Board (Arduino?) mit physischen Buttons 
versehen und per UART die Befehle rausschicken? Ist dann garantiert 
präzises Timing ohne Probleme durch den USB-Adapter und funktioniert 
auch ohne PC...

von Walter L. (Gast)


Lesenswert?

Hallo UDO,

RS232Cmd.vcproj gestartet.

Ergebniss: Fenster öffnet sich mit nichts drin, kein Botton.
Ist das so gepalnt?

Visual Studio sagt folgendes:

Erstellen gestartet...
1>------ Erstellen gestartet: Projekt: RS232Cmd, Konfiguration: Release 
Win32 ------
1>D:\Program Files\Microsoft Visual 
Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.Cpp.Analysis.p 
rops(24,5):
warning MSB4211: Die Eigenschaft "MsvcAnalysisPluginPath" wird zum 
ersten Mal auf einen Wert festgelegt,
doch dieser wurde bereits in
"D:\Program Files\Microsoft Visual 
Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CodeAnalysis.E 
xtensions.props  (33,5)" verwendet.
1>stdafx.cpp
1>RS232Cmd.cpp
1>Code wird generiert.
1>Previous IPDB not found, fall back to full compilation.
1>All 6 functions were compiled because no usable IPDB/IOBJ from 
previous compilation was found.
1>Codegenerierung ist abgeschlossen.
1>RS232Cmd.vcxproj -> D:\TEMP_HS\RS232Cmd\RS232Cmd\Release\RS232Cmd.exe
========== Build: 1 erfolgreich, 0 Fehler, 0 aktuell, 0 übersprungen

VG Walter

von Udo K. (udok)


Angehängte Dateien:

Lesenswert?

Rufe das Help Menü auf.  Ich habe die Buttons in den Help Dialog 
reingetan.
Ich habe dir noch schnell ein Program gemacht, das mit dem Button-Dialog 
startet.  Ist im Anhang.  Da gibt es jetzt eine Funktion WriteRS232(), 
die schreibt das Kommando in das Terminal.  Da musst du das richtige 
Handle auf die RS232 einsetzen.

: Bearbeitet durch User
von Ein T. (ein_typ)


Lesenswert?

Walter L. schrieb:
> Auf dem PC-Bildschirm sind die Bef‘s als kleine „Bef-Schalter“ sichtbar,
> die mit der Mouse angeklickt werden können. Beim Anklicken werden die 11
> Byte unterbrechungsfrei mit der entsp. Info gesendet und das Programm
> erledigt den Rest.

Hier wäre ein bisschen mehr Information zum "Rest" sinnvoll.

> 2.  Ist das mit der kostenlosen  VISUAL STUDIO 2022 Umgebung zu
> schaffen?

Ja.

> 3.  Welche Prog.-Sprache würdet ihr nehmen (C oder  BASIC, vorausgesetzt
> das geht mit der kostenlosen  VISUAL STUDIO 2022 Umgebung)?

Ich würde eine Sprache mit folgenden Eigenschaften empfehlen:

1. Du kannst sie oder bist daran interessiert, sie zu lernen.

2. Es ist damit ohne Verrenkungen möglich, eine GUI oder einen 
Webservice zu entwickeln.

3. Die Sprache (und eventuell die GUI-Library) ist plattform-unabhängig, 
so daß Dir die Geschichte nicht im Wege steht, wenn Du irgendwann mal 
auf einen Mac, ein Linuxsystem (etwa einen RasPi oder einen passenden 
Industrierechner) wechseln möchtest. Man weiß ja nie...

Meine ganz persönliche erste Wahl für so etwas wäre Go(lang) mit 
Gofiber, wenn ich einen Webservice entwickeln wollte, oder entweder 
Python oder C++ mit Qt, wenn es eine native GUI-Anwendung werden soll.

Was für einen Webservice spricht: Du kannst Deine Buttons und alles 
Weitere ganz einfach mit HTML erstellen und mit CSS hübsch machen. Wenn 
ein bisschen Interaktivität notwendig ist (siehe dazu oben unter dem 
Hinweis "Rest") sind allerdings leider JavaScript und eventuell 
Websockets das Mittel der Wahl.

Aber gut, das sind die Möglichkeiten, die ich in Betracht ziehen würde, 
und natürlich davon beeinflußt, daß ich die genannten Sprachen und 
Technologien bereits kenne. Für Dich kann die Wahl natürlich anders 
aussehen, aber dennoch solltest Du Dir möglicherweise die Frage stellen, 
ob ein Webservice für Dich in Frage kommen könnte.

von Stephan S. (uxdx)


Lesenswert?

Niklas G. schrieb:
> Billiges Mikrocontroller-Board (Arduino?) mit physischen Buttons
> versehen und per UART die Befehle rausschicken? Ist dann garantiert
> präzises Timing ohne Probleme durch den USB-Adapter und funktioniert
> auch ohne PC...

War auch meine erste Idee, eine Tastatur-Matrix z.B. 
https://www.ebay.de/itm/174939241575, ein X-duino (wenn Du C kannst, 
findest Du Dich schnell zurecht) oder ein beliebiger ESP, nach Wunsch 
noch ein OLED- oder LCD, das geht doch ganz schnell. Wenn Deine CNC 
echte RS232-Level braucht (+-12V), noch ein MAX3232.

von Rbx (rcx)


Lesenswert?

Von der Perspektive der schrittweisen Entwicklung wäre es vielleicht 
hilfreich, sich eines der Petzold-Bücher zu schnappen, und schauen, wie 
ein einfacher Button da eingerichtet wird. Das muss man sich natürlich 
erstmal ansehen, und verdauen - ist aber beim CP üblicherweise sehr gut 
erklärt.

Eines der Probleme ist auch, wie kompatibel ist der (alte) Code aktuell 
noch. Ein anderes, dass es die Bücher wohl nicht mehr aktuell gibt. Mit 
etwas Glück findet man was zum Ausleihen in einer Uni-Bib. Wichtig ist, 
"CP" mit C zu bekommen. Die anderen Bücher sind auch interessant - aber 
dann auch keine schrittweise Hilfe mehr.
Die nächste Ebene wäre dann .NET-Programmierung.

Eine andere Überlegung/Perspektive wäre das was Ein.T oben geschrieben 
hat.
Dann hat man auch eine Möglichkeit, Echtzeit-freundlichere 
Betriebssysteme einzusetzen.
(https://www.acontis.com/de/windows-and-realtime-Why-RT-Linux-is-the-Best-Solution-for-Adding-Real-time-Capabilities-to-Windows.html)

von Harald K. (kirnbichler)


Lesenswert?

Rbx schrieb:
> Eines der Probleme ist auch, wie kompatibel ist der (alte) Code aktuell
> noch.

Die grundlegende Art und Weise, mit der Win32-API mit seriellen 
Schnittstellen zu kommunizieren (Port öffnen, Baudrate etc. einstellen, 
Daten senden und empfangen), hat sich in den letzten drei Jahrzehnten 
nicht geändert.

Und wenn man aus irgendwelchen Gründen daran glaubt, daß es mit 
USB-Seriell-Adaptern aber Probleme geben muss, dann nimmt man halt 
einen von FTDI und spricht den nicht über die Win32-API, sondern mit den 
von FTDI zur Verfügung gestellten Funktionen der FTD2XX-DLL an.

Dokumentation dafür gibts hier:

https://ftdichip.com/wp-content/uploads/2023/09/D2XX_Programmers_Guide.pdf

von Sheeva P. (sheevaplug)


Angehängte Dateien:

Lesenswert?

Rbx schrieb:
> Eine andere Überlegung/Perspektive wäre das was Ein.T oben geschrieben
> hat.
> Dann hat man auch eine Möglichkeit, Echtzeit-freundlichere
> Betriebssysteme einzusetzen.

Hmmm, ich bin unsicher, ob diese Idee zielführend ist. Der Typ schlägt 
einen Webservice in Golang vor. Das heisst, dann wäre dabei auch noch 
ein Netzwerk mit all seinen Komplexitäten und Unzuverlässigkeiten 
beteiligt. Ich kenne ein paar recht zuverlässige, aber nur wenige 
echtzeitfähige Netzwerktechnologien, deren Gemeinsamkeit beachtliche 
Kosten sind.

Ich glaube auch nicht (vielleicht wissen die anwesenden Fachleute dazu 
mehr), dass es harte Echtzeit benötigt, um einen Puffer von wenigen 
Bytes auf eine Serielle Schnettstille zu schreiben und eine Antwort 
davon zu erhalten. Zur grössten Not würde ich mir einen RasPi nehmen, 
per Kernelparameter "isolcpus" einen oder zwei CPU-Kerne vom normalen 
Prozeßscheduler ausnehmen und mein Programm dann mit taskset(1) auf 
diese Kerne zwingen, so dass das Programm nicht vom Systemkernel 
unterbrochen werden kann. Dass dazu zusätzlich auch noch RT-Patches 
benötigt werden, halte ich für unwahrscheinlich (natürlich lasse ich 
mich immer gerne eines Besseren belehren).

Für einen einfachen Webservice in Golang habe ich hier einmal etwas aus 
einer anderen Software gebaut und angehangen. Da ist (noch?) nichts 
Serielles drin und es benutzt (IMHO) ein paar ganz schicke Tricks, zeigt 
aber ganz gut, wie mittels Golang ein kleiner, einfacher und enorm 
schneller Webservice gebaut werden kann. Von dem, was Ein Typ 
vorschlägt, weiche ich allerdings ab, denn meine Templates bleiben 
(noch?) externe Dateien, die ebenfalls deployt werden müssten. Mit dem 
Go-Modul "embed" würden sie sich aber auch leicht fix in das Executable 
integrieren lassen -- das habe ich zwar schon einmal erfolgreich 
gemacht, war jetzt gerade aber zu faul dazu. :)

Achtung, ich habe ganz bewußt kein Executable hineingelegt, einerseits 
wegen dessen Grösse und andererseits aus Sicherheitsgründen. Für 
jemanden, der eine halbwegs aktuelle Go-Entwicklungsumgebung (ab Version 
1.21 aufwärts), make(1) installiert und der keine Angst davor hat, 
Befehle auf einer Kommandozeile einzugeben, sollte das aber eine leichte 
Übung sein:
1
1. Zip-Datei entpacken
2
2. In das entpackte Verzeichnis wechseln
3
3. "make" aufrufen

Wenn dabei Probleme auftreten sollten, bitte hier melden, dann helfe ich 
natürlich gerne bei der Behebung. Wenn keine Probleme auftreten:
1
4. Programm mit "./sercmd" starten
2
5. Im Webbrowser "http://localhost:8000/" aufrufen

Wer zusätzlich noch den Komprimierer upx(1) installiert hat, kann mit 
"make compress" eine komprimierte Version des Executable erzeugen. Das 
Make-Target "windows" erzeugt (auch unter Linux) ein Windows-kompatibles 
Executable, und das Target "compress-windows" ein Windows-Executable, 
das zudem komprimiert und deswegen relativ klein ist. Ohne Komprimierung 
sind die Executables hier 7,6 für die Linux- und 9,5 MB für die 
Windows-Version gross.

PS: Bevor sich die Damen und Herren "ich weiss alles, vor allem besser" 
jetzt darüber echauffieren, dass die Executables doch bitte kleiner sein 
könnten: bitte bedenkt, dass das statisch gelinkte Executables sind, die 
die gesamte Go-Runtime und zudem einen Webserver enthalten, der je nach 
Benchmark sogar schneller und ressourcenschonender als der beliebte 
nginx ist. :)

von Harald K. (kirnbichler)


Lesenswert?

Sheeva P. schrieb:
> Ich glaube auch nicht (vielleicht wissen die anwesenden Fachleute dazu
> mehr), dass es harte Echtzeit benötigt, um einen Puffer von wenigen
> Bytes auf eine Serielle Schnettstille zu schreiben und eine Antwort
> davon zu erhalten.

Braucht es natürlich nicht. Man sollte nur nicht versuchen, zu viele 
Softwareabstrationsschichten zwischen die Win32-API (durch die letztlich 
jeder Schnittstellenzugriff erfolgt) und das eigentliche Programm zu 
stopfen.

von Sheeva P. (sheevaplug)


Lesenswert?

Hans schrieb:
> Re D. schrieb:
>> Quatsch mit wx-Python o.Ä. hat man die Anwendung schneller geschrieben
>> und ist universeller unterwegs als mit klicki bunti.
>
> Ja alles klar Du schreibst ein paar Zeilen Code schneller, als ich ein
> Widget auf ein Formular ziehe - träum weiter.

Ein Widget auf ein Form zu ziehen ist ja keine Kunst, das geht schnell.

Anfangs sieht auch alles leicht aus, einfach die GUI zusammen klicken, 
an den vorgesehen Stellen die eigenen Funktionen oder Methoden klimpern, 
fertig. Aber wenn das Ganze dann auch noch annehmbar aussehen, oder 
sogar wiederverwendbar sein oder automatisch generiert werden soll, ist 
das Ganze plötzlich gar nicht mehr ganz so einfach und leicht und 
schnell wie anfangs gedacht. Und wehe Du willst etwas bewerkstelligen, 
das die Entwickler Deiner Widgets nicht bedacht haben... dann hast 
eventuell sogar ein echtes Problem und kannst im übelsten aller üblen 
Fälle den Buildprozess Deines Werkzeugs hacken. BTDT, und das war nicht 
einmal ansatzweise vergnügungssteuerpflichtig.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Mit C# und WinUI geht sowas auch recht gut, da sind die Frameworks auch 
vorinstalliert und man bekommt Installer/Uninstaller integriert, es 
funktioniert mit Touchscreen und wäre sogar mit dem Microsoft Store 
kompatibel und auch ARM-Windows.

von Sheeva P. (sheevaplug)


Lesenswert?

Rbx schrieb:
> Man könnte auch den Open Watcom Compiler nutzen. DOS geht zwar nicht
> mehr ohne EMU, aber 32 Bit. Dos-Konsole-Code kann man auch über den
> 32bit-Linker in 32Bit-ProtectedMode übersetzen.

Natürlich kann man das machen, und für Leute, die sich mit dem Compiler 
gut auskennen, ist das vielleicht auch eine feine Sache.

Aber wir schreiben mittlerweile das Jahr 2024. Es gibt andere frei 
verfügbare Compiler für C und C++, allen voran sicherlich GCC und LLVM. 
Warum sollte sich jemand für ein neues Projekt ausgerechnet den Open 
Watcom aussuchen und sich damit im Prinzip eine Altlast an die Backe 
kleben? Ok, ich weiß, das ist ein feines Stück Software und meine 
Aussagen lesen sich viel negativer als meine Meinung tatsächlich ist, 
und Open Watcom wird auch von einem kleinen Team von Galliern in einem 
"Dorf der Unbeugsamen" immer noch weiter entwickelt.

Aber ich frage mich leider trotzdem nach dem tieferen Sinn, solche 
Exoten für neue Projekte einzusetzen. Das zieht doch sekundäre Probleme 
nach sich: wenig aktuelle Dokumentation und Unterstützung aus einer 
kleinen Community, weniger gute Anpassungen an aktuelle Hardware... und 
das ist ja nur der Anfang.

Insofern, bitte sei doch so lieb und erklär' mir (bitte besonders 
langsam und  ausführlich, ich bin ja nicht mehr der Jüngste): welchen 
Vorteil hätte es für den TO, OpenWatcom zu benutzen? Welche Nachteile 
hätte er zu gewärtigen? Und inwieweit würden die Vorteile für ihn die 
Nachteile überwiegen? Lieben Dank.

von Sheeva P. (sheevaplug)


Lesenswert?

Udo K. schrieb:
> Ich habe dir noch ein Update gemacht, jeder der 32 Buttons ist mit einer
> Funktion verbunden, die einen String in ein Edit-Control reinschreibt.
> Das kannst du als Startpunkt verwenden, wenn du möchtest.

Wow, das ist wirklich absolut beeindruckend! Danke dafür, daß Du die 
Eier hast, etwas zu entwickeln und hier einzustellen, das finde ich 
richtig gut (auch wenn ich Cpp-Code für Windows nicht lesen kann). 
Danke!

von Sheeva P. (sheevaplug)


Lesenswert?

Harald K. schrieb:
> Man sollte nur nicht versuchen, zu viele
> Softwareabstrationsschichten zwischen die Win32-API (durch die letztlich
> jeder Schnittstellenzugriff erfolgt) und das eigentliche Programm zu
> stopfen.

Zu Microsoft Windows kann ich (*1) nichts sagen, und verlasse mich daher 
natürlich auf Dein fachmännisches Urteil.

(*1) "Leider" oder "glücklicherweise", wer weiss das schon. :-)

von Sheeva P. (sheevaplug)


Lesenswert?

Niklas G. schrieb:
> Mit C# und WinUI geht sowas auch recht gut, da sind die Frameworks auch
> vorinstalliert und man bekommt Installer/Uninstaller integriert, es
> funktioniert mit Touchscreen und wäre sogar mit dem Microsoft Store
> kompatibel und auch ARM-Windows.

Ja, da habe ich keine Zweifel. Was Entwicklungswerkzeuge angeht, waren 
die Leute bei Microsoft immer sehr gut, weil sie schon vor Jahrzehnten 
verstanden haben, dass man Benutzer über Software und Softwareentwickler 
über Werkzeuge anziehen kann. Deswegen investiert Microsoft auch so viel 
in diesem Bereich, beispielsweise Powershell, Mono, WSL2, Iron Python 
und Visual Studio Code, um nur einige bekanntere Beispiele zu nennen.

Angelegentlich muss man auch feststellen, dass Microsoft in diesen 
Bereichen traditionell Vorsprünge gegenüber seinen Wettbewerbern hat. 
Eine konsistente API für System und Applikationen, na klar, das hat was. 
Anständige Werkzeuge wie Visual Studio, sogar kostenlos: yay. Ich 
verstehe das sehr gut.

Aber trotzdem ist das nicht meine Welt und wird es auch nicht mehr. Ich 
bin glücklich mit UNIXoiden, heutzutage mit Linux. Alles gut, oder? :-)

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Walter L. schrieb:
> Ich merke schon. Es geht in Richtung VB.
> VB müßte ich aber dann mir neu aneignen.
> Wenn ich das so lese mit "Groupbox mit Radiobuttons ...."

Genau da liegt ja schon das Problem, egal jetzt welche Sprache
für WIN der TO nutzen möchte. Wenn man die grundlegenden Elemente
schon nicht kennt, obwohl man fast täglich in WIN mit ihnen arbeitet ?

Er meint wohl, daß die GUI-Elemente nur bei VB drin sind.

Jedenfalls scheint das mit einem Windowsprogramm eher schwierig
für ihn zu werden. Es läuft dahin hinaus, wie schon so oft gesehen
(ob hier im Forum oder andere), daß das Projekt schlußendlich beim
ihm in der Tonne landet.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Hans schrieb:

> Also bei der COM-Port Komponente von Delphi, mußte ich noch nie
> irgendwelche Klimmzüge machen. Da funktionieren i.d.R. alle seriellen
> Ports die unter Windows angezeigt werden problemlos.

Benutzt aber auch nur das COMM-Api. Damit hast du letztlich exakt 
dasselbe, als wenn du es mit einer .NET-Sprache machst (egal ob C# oder 
VB.net). Der SerialPort aus dem .net-Framework setzt letztlich auch nur 
auf dieses seit Urzeiten bekannte COMM-Api auf.

Warum auch nicht? Warum sollte man etwas, was einfach und logisch ist 
und seit Jahrzehnten problemlos funktioniert, durch was anderes ersetzen 
wollen?

von Walter L. (Gast)


Lesenswert?

HAllo Udo,

danke für deine konstuktive HILFE.

Habe dir eine PN geschickt.

VG Walter

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Walter L. schrieb:
> HAllo Udo,
>
> danke für deine konstuktive HILFE.
>
> Habe dir eine PN geschickt.
>
> VG Walter

Falls du das nicht verstanden hast: auch der prähistorische C-Kram von 
Udo K. nutzt letztlich nur das COMM-Api...

Einfach deshalb, weil es unter WindowsNT niemals einen anderen als 
diesen Weg gab und jedes Windows, was in den letzten zwei Jahrzehnten 
relevant wurde, ein Erbe von Windows-NT ist.

Bei den DOS-basierten Windows-Versionen (1,2,3.x, 95, 98 und ME) gab es 
noch die Möglichkeit, am OS vorbei auf die Hardware der COM-Ports 
zuzugreifen, das aber natürlich nur auf die mit echter UART-Hardware. 
Für virtuelle COM-Ports (z.B. über USB bereitgestellt) war auch bei 
diesen Krüppel-Windows-Versionen der Zugriff auf das COMM-Api 
beschränkt. Maximal ging was über IOCTL-Funktionen des Treibers, die 
aber fast nie dokumentiert waren.

von Walter L. (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich habe aus 2013 einen cp210x angeschlossen.
Im Gerätemanager taucht com5 auf.
Soweit ich das hier verstanden habe, ist so eine Anwendung mit
Visual Studio 2022
in 30 Minuten programmiert, eine Konsolenanwendung in 10 Minuten.

Mir würde zunächst schon eine Konsolenanwendung reichen (um da 
reinzukommen)

die

11 Bytes

unterbrechungsfrei sendet und danach sofort

1 bis 16 Byte empfängt.

Danach Pause von 1 Sek oder länger.

MODE COMx:9600,N,8,1.

Keine handshake leitungen.

Danke für ein Beispiel.

VG Walter

von Norbert (der_norbert)


Angehängte Dateien:

Lesenswert?

Hans schrieb:
> Ja alles klar Du schreibst ein paar Zeilen Code schneller, als ich ein
> Widget auf ein Formular ziehe - träum weiter.

Der Ratschlag lautet:
Nicht über Dinge reden von denen man keine Ahnung hat.

Ach ja, zum Schluss lässt man sich den Code generieren.

: Bearbeitet durch User
von Monk (roehrmond)


Lesenswert?

Ein Betriebssystem-unabhängiges Beispiel mit Qt in C++
http://stefanfrings.de/serial_io/index.html#qtexample

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Was die RS232 betrifft, wäre noch zu klären, wie die CNC
den Input haben möchte. Eine Zahl zwischen 3 und 151 kann
man ja unterschiedlich interpretieren. Wenn ich jetzt die
151 senden möchte, habe ich als Hexzahl die 97 oder kann
die Ziffern auch hintereinander einzeln senden : 1,5,1
Im ersten Fall sind es nur 1 Byte und im zweiten Fall
sind es 3.
Da der Byterahmen ja 11 Bytes groß ist, fehlen da noch
einige Bytes, entweder als Füllbytes oder mit sonstigen
Infos oder gar beides.
Da braucht man dann schon entweder eine Beschreibung von der
Hardware oder den Quellcode des Programms.

Eine andere Frage ist, wieviele Befehle gibt es ?
Der Wertebereich des TO läßt eher 148 (3-151) vermuten
oder sind es weniger ?

Desweiteren muß man daran denken, daß sich da 2 Welten treffen.
Einmal ASCII (OEM) bei der Hardware und zweitens ANSI in der
Windowswelt. Damals konnte ich auch keine Antwort von meinem
AVR empfangen. Erst, als ich beim Programmieren des AVR ein
Chr$(0) an den String anhängte, empfing ich den auch in meiner
Windows-Sprache.

Soll heißen, wenn die Hardware kein abschließendes Nullbyte dranhängt,
muß man es als Bytesequenz empfangen und händisch ein Nullbyte
dranhängen, um es etwa in einem MultiEdit darstellen zu können.

Das sind halt so Stolpersteine.

von Walter L. (Gast)


Lesenswert?

@hbrill

Alles irrellvant.

Aber ein Bsp. für sie, der BEf3

Byte

0  1  2  3  4  5  6  7  8  9  10

3  0  0  0  0  0  0  0  0  0   3

alles dezimal.

Das zente Byte ist die Summen über  0 bis 9.

Und die CNC will das so, und nicht anders.

In der jetzige C-Software läuft das so.

Also, wo ist der 10 Min. Bsp.-Code hbrill?

Danke.

VG Walter

von Stephan S. (uxdx)


Lesenswert?

Walter L. schrieb:
> 0  1  2  3  4  5  6  7  8  9  10
>
> 3  0  0  0  0  0  0  0  0  0   3

Das sind mit ENTER in der Windows-Welt aber 12 (zwölf) Bytes und nicht 
11. In Windows wird ENTER mit CR LF übergeben, also 0xD 0xA

: Bearbeitet durch User
von Walter L. (Gast)


Lesenswert?

Uxdx nix...
Von Enter LF und CR war keine Rede.
Lesen, und, wo ist dein code?

VG walter

von Rbx (rcx)


Lesenswert?

Sheeva P. schrieb:
> Insofern, bitte sei doch so lieb und erklär' mir (bitte besonders
> langsam und  ausführlich, ich bin ja nicht mehr der Jüngste): welchen
> Vorteil hätte es für den TO, OpenWatcom zu benutzen? Welche Nachteile
> hätte er zu gewärtigen? Und inwieweit würden die Vorteile für ihn die
> Nachteile überwiegen? Lieben Dank.

Möchtest du die Antwort als
a) geschätzter Forenteilnehmer
oder
b) Mitglied einer Kaste, die mir das Skyrimspielen auf Linux 
vermiest/vermurkst?

Ich biete nur eine zur Auswahl.
Beide Antworten gehen mehr oder weniger ins OT - aber da möchtest du ja 
auch unbedingt hin?


@Walter: eventuell ist die Setup-Beschreibung oben doch etwas zu sehr 
eingegrenzt.
Die Frage hinsichtlich der Softwarelösung ist eventuell auch etwas zu 
grob ohne Einsicht in problematische Code-Felder im bereits vorhandenem 
Programmcode.

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Walter L. schrieb:
> Also, wo ist der 10 Min. Bsp.-Code hbrill?

Das war wohl ein anderer, der dir das versprochen hat :
Udo K. schrieb:
> Das kannst du auch in VS in 10 Minuten zusammenklicken.

Außerdem kann ich auch gar kein C und arbeite auch nicht mit VS.
Da meine Basicsprache nur Strings schicken und empfangen kann,
müßte ich erst eine entsprechende DLL finden, die auch Speicherbereiche
senden und empfangen kann.

Also die erste (0.Byte) 3 ist der Befehl und das 10.Byte ist
die Summe, also auch 3.
Wäre bei einem Befehl z.b. 125
1 2 5 0 0 0 0 0 0 0 8

oder bei 88 :
8 8 0 0 0 0 0 0 0 1 6

Sehe ich das so richtig ?

von Walter L. (Gast)


Lesenswert?

Macht zu das Ding.

Bei so vielen Honk-ytonks wird das nix mehr.

VG Walter

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Ja, besser zu machen.
Da es ja Befehle von 3 bis 151 gibt, erschließt es sich mir nicht,
wie ich eine zweistellige Zahl (Summe) in einem einzigen Byte 
unterbringen
kann.
Irgendwas ist da nicht richtig.
Ich bin da mal auch raus.

von Walter L. (Gast)


Lesenswert?

Ein un. Byte umfasst den Zahlenbereich von 0 bis 255.
Wieso passt 155 nicht in ein Byte, hbrill?

von Stephan S. (uxdx)


Lesenswert?

Der TE möchte, dass ihm geholfen wird, pöbelt aber gebetsmühlenartig mit 
dummen Fragen "wo ist der Code" rum.

Da sehe ich keine Sympathie, einem solchen Menschen zu helfen, der frech 
nur Forderungen hat.

von Walter L. (Gast)


Lesenswert?

Uxdx Hilfe kommt vom codebeispiel, den der TE in C wünscht, sonst nix.
Auch sie haben nix konstruktives geliefert.

von Thomas W. (dbstw)


Lesenswert?

Es sind ein paar Sachen nicht ganz klar:
9600Baud ist eine Ewigkeit fuer einen aktuellen Computer, insbesondere 
weil ja RS232 das eigene Timing macht. Da das Ding ja fuers Geschaeft 
ist, waere ein Industrie-PC (oder zwei PCs mit seriellen Port als 
Reserve) angesagt.

Raus war ich bei ersten Absatz:

> Diese reagiert mit einer bekannten Quittung usw. Das Protokoll
> ist bekannt.

Zeige das Protokoll, dann haette man reden koennen.

von Walter L. (Gast)


Lesenswert?

dbstw ich kann nix daran ändern das da Ihnen was nicht klar ist.
Es werde nun mal immer 10 Bytes plus ein byte checksumme an die uart der 
Steuerung gesendet. Punkt.

Das erstes Byte ist der Bef.....

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Walter L. schrieb:
> Ein un. Byte umfasst den Zahlenbereich von 0 bis 255.
> Wieso passt 155 nicht in ein Byte, hbrill?

Schon mal was von einer ASCII bzw. ANSI Tabelle gehört ?
Ein Chr$(155) ist NICHT die Zahl 155. Die 0 - 255 sind
Indexe, wo das in der Tabelle steht. Ein Chr$(65) ergibt z.b.
ein großes A . Die indexe 48 - 57 enthalten die Ziffern 0 - 9.
Stell dirs halt vor, wie ein Array mit 256 Zeichen, wobei die
ersten 32 nicht druckbar sind.

Und überlege mal : 1 Byte fürs Kommando und 1 Byte für die
Checksumme. Da sind 9 von den 11 Bytes unnütz, würde also auch
in einen 2-Byte-Rahmen passen.

Aber ich lasse es lieber bei soviel Unkenntnis.

: Bearbeitet durch User
von Klaus S. (kseege)


Lesenswert?

Heinz B. schrieb:
> Aber ich lasse es lieber bei soviel Unkenntnis.

Das ist auch besser. Die Unkenntnis ist jedenfalls nicht auf der Seite 
des TO.
Das ist die höflichste Umschreibung, die mir einfiel.

Es ist für jeden, der auf diesem Gebiet arbeitet, auf den ersten Blick 
ersichtlich, daß es sich um ein binäres Protokoll handelt, das nichts 
mit ASCII-Zeichen zu tun hat. Dementsprechende Bemerkungen sind einfach 
nur überflüssig.

Just my 2  cents

von Sheeva P. (sheevaplug)


Lesenswert?

Rbx schrieb:
> Möchtest du die Antwort als
> a) geschätzter Forenteilnehmer
> oder
> b) Mitglied einer Kaste, die mir das Skyrimspielen auf Linux
> vermiest/vermurkst?

Warum so giftig? Du hattest den OpenWatcom-Compiler empfohlen und ich 
habe lediglich gefragt, welche Vorteile Du darin für den TO siehst. Du 
wirst ja schließlich Gründe dafür haben warum Du ein Werkzeug 
empfiehlst, das nicht einmal Code für aktuelle Prozessoren erzeugen 
kann, wenn ich Deine Aussage richtig gelesen und verstanden habe.

Davon abgesehen will Dir vermutlich niemand das Spielen von Skyrim 
vermiesen oder vermurksen, ich jedenfalls habe nicht diese Absicht. Ich 
halte es nur für wenig zielführend, daß Du den Zustand und die Qualität 
von Linux immer wieder ausgerechnet anhand eines Spiels beurteilen 
möchtest, das für ein vollkommen anderes Betriebssystem entwickelt 
worden ist.

von Walter L. (Gast)


Lesenswert?

Danke kseege.

Also hier noch einmal:

ich habe aus 2013 einen cp210x angeschlossen. Im Gerätemanager taucht 
com5 auf. Soweit ich das hier verstanden habe, ist so eine Anwendung mit 
Visual Studio 2022 in C++ oder C# oder VB in 30 Minuten programmiert, 
eine Konsolenanwendung in 10 Minuten.

Mir würde zunächst schon eine Konsolenanwendung reichen (um da 
reinzukommen)

die

11 Bytes

unterbrechungsfrei sendet und danach sofort

1 bis 16 Byte empfängt.

MODE COMx:9600,N,8,1.

Keine handshake leitungen.

Danke für ein Beispiel.

VG Walter

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Ich hatte mal vor etlichen Jahren was ähnliches für eine
8fach Relaiskarte vom großen C in (X)Profan gemacht. Da
brauchte ich einen 4-Byte Rahmen. Ist jetzt allerdings
in einem BASIC - Dialekt. Hier mal das wesentliche. Evtl.
kannst du ja das relevante rauslesen und analog für C umsetzen.
Ich denke mal, daß das bei deiner Hardware recht ähnlich funktioniert.
1
Proc GetComInput
2
 Parameters id%
3
 Declare in$
4
 in$ = ReadCom$(f%,8) ' 8 Zeichen einlesen
5
 Case Len(in$):SetText statusbar%, "Antwort : " + Str$(ord(in$))
6
 EndProc
7
8
 Proc Senden
9
    ' 4 Byte - Rahmen zum Senden erstellen
10
    Pruefsumme% = XOR(XOR(kommando%, adresse%), daten%)
11
    send$ = Chr$(kommando%) + Chr$(adresse%) + Chr$(daten%) + Chr$(Pruefsumme%)
12
    WriteCom(f%, send$)
13
    ComError(f%)
14
    GetComInput(f%)
15
    Sleep 1000
16
 EndProc

Da du ja schon ein anderes Konsolenprogramm gemacht hast, dürfte
es dir ja nicht schwer fallen. Die Schnittstellennr. + Einstellungen
kannst du ja vorerst fest lassen. Ansonsten brauchst du ja nur
eine Schleife, in der das Kommando entgegen genommen, in den Rahmen
gesetzt und gesendet wird.

Die Bytes 1 - 9 scheinen ja leer bzw. 0 zu bleiben, sodaß als
10. Byte ja nur der Wert des Kommandos übergeben wird. Die leeren
Bytes würde ich als Chr$(48) belegen, sodaß bei einem Kommando 155
der zu sendende String send$ wie folgt zu belegen ist :
1
send$ = Chr$(kommando) + Chr$(48) + Chr$(48) + Chr$(48) +Chr$(48) + Chr$(48) + Chr$(48) + Chr$(48) + Chr$(48) + Chr$(48) + Chr$(kommando)

Das mußt du halt selber ausprobieren. Oder reicht statt Chr$(48) ein
Chr$(0) ?

Das ist jedenfalls mein Wissen, das ich hiermit mit dir teilen kann.

von Monk (roehrmond)


Lesenswert?

Sheeva P. schrieb:
> Ich halte es nur für wenig zielführend, daß Du den Zustand und die
> Qualität von Linux immer wieder ausgerechnet anhand eines Spiels
> beurteilen möchtest, das für ein vollkommen anderes Betriebssystem
> entwickelt worden ist.

Die Motoren von Mercedes sind auch ganz schlecht, weil keiner davon in 
meinen Berlingo passt.

von Paule M. (martin_mu)


Lesenswert?

Frag mal im Freepascal Forum, da bastelt dir das sicher jemand 
kostenlos, als Programmierübung oder versuch es selbst mit lazarus / 
freepascalhttps://www.lazarus-ide.org/

von Klaus S. (kseege)


Lesenswert?

Walter L. schrieb:
> Mir würde zunächst schon eine Konsolenanwendung reichen (um da
> reinzukommen)
> die
> 11 Bytes
> unterbrechungsfrei sendet und danach sofort
> 1 bis 16 Byte empfängt.
> MODE COMx:9600,N,8,1.

Aus meiner (natürlich unmaßgeblichen) Sicht ist das Eingeben und 
Absenden tatsächlich in 10 Minuten zu machen, wenn man seinen Compiler 
in- und auswendig kennt und nirgendwo etwas nachschlagen muß. Für mich 
würde ich in TCL 20 Minuten und in C das Dreifache veranschlagen.

Das eigentliche Problem liegt aus meiner Sicht im Empfang der Antwort. 
Woher weiß das Programm, daß die Antwort vollständig ist? Dazu hast Du 
noch nichts angegeben. Die logische Folge wäre, daß man das mit einem 
Timeout realisiert.

Dann muß man die Antworten scannen, ungültige aussortieren und die 
gültigen verarbeiten. Das kann leicht mal 2 Tage dauern, je nach 
Kompexität der Antworten.

Die fertige Konsolenanwendung kann ich nicht liefern,  weil der letzte 
Microsoft-C-Compiler, den ich benutzt habe, die Version 3.0 von ca.1984 
ist, die noch älter als Turbo-C ist. Außerdem ist microcontroller.net 
ein Forum zur Unterstützung der Selbsthilfe, kein Lieferant kostenloser 
Software.

Wie wäre es, wenn Du einfach anfängst und den Code so einfach wie 
möglich hältst, damit er leicht verstanden werden kann und den dann hier 
vorstellst und nach Verbesserungen fragst? Da Du in C programmieren 
kannst und die "basics" des UART-Transfers offensichtlich gut verstanden 
hast, solltest Du das bequem wuppen können, auch ohne Vorgabe (die einen 
auch ganz leicht in unnötige Komplexität führen kann).

Aus meiner Sicht ist z.B. die Lösung, 148 Buttons für 148 Befehle zu 
realisieren, einfach lebensfremd. Ein Eingabefeld, in das man den Befehl 
dezimal eintippt und nach dem "Enter" abschickt, erscheint mir erheblich 
einfacher zu sein. Aber das ist Geschmackssache.

Gruß Klaus (der soundsovielte)

von Klaus S. (kseege)


Lesenswert?

Heinz B. schrieb:
> Das mußt du halt selber ausprobieren. Oder reicht statt Chr$(48) ein
> Chr$(0) ?

Ratespielchen mit Halbwissen. Warum soll man sich sowas antun? Und dann 
noch die falsche Checksum in
> send$ = Chr$(kommando) + Chr$(48) + Chr$(48) + Chr$(48) +Chr$(48) +
> Chr$(48) + Chr$(48) + Chr$(48) + Chr$(48) + Chr$(48) + Chr$(kommando)

Warum führst Du den TO auf falsch Fährten? Dummheit oder Absicht?

Just my 2 cents

von Ein T. (ein_typ)


Lesenswert?

Steve van de Grens schrieb:
> Sheeva P. schrieb:
>> Ich halte es nur für wenig zielführend, daß Du den Zustand und die
>> Qualität von Linux immer wieder ausgerechnet anhand eines Spiels
>> beurteilen möchtest, das für ein vollkommen anderes Betriebssystem
>> entwickelt worden ist.
>
> Die Motoren von Mercedes sind auch ganz schlecht, weil keiner davon in
> meinen Berlingo passt.

Im Fall von Rbx ist es ja eher so, daß der Berlingo schlecht ist, weil 
die Motoren von Mercedes nicht hineinpassen... aber ich glaub, das ist 
nur ein marginales Detail Deines Gleichnisses.

von Norbert (der_norbert)


Lesenswert?

Hier mal ein Beispiel wie man bequem Daten sendet und empfängt. Zu einer 
graphischen Oberfläche hatte ich ja weiter oben schon etwas geschrieben.
Ich sehe das jetzt nicht als sooooo schwierig an.
1
#!/usr/bin/python3
2
# -*- coding: UTF-8 -*-
3
# vim:fileencoding=UTF-8:ts=4
4
5
from serial import Serial, EIGHTBITS, PARITY_NONE, STOPBITS_ONE
6
7
port = '/dev/ttyACM0'
8
speed = 9600
9
timeout = 0.1  # in seconds
10
with Serial(port, speed, EIGHTBITS, PARITY_NONE, STOPBITS_ONE, timeout=timeout) as ser:
11
    # prepare data_out
12
    data_out = bytearray(11)
13
    data_out[0] = 13    # CR
14
    data_out[1] = 10    # LF
15
    data_out[2] = 4     # Ctrl-D
16
    # checksum
17
    data_out[10] = sum(data_out[0:10]) % 256
18
    # send data
19
    ser.write(data_out)
20
    # receive up to 16 bytes into data_in
21
    data_in = []
22
    for numbytes in range(16):
23
        byte = ser.read()       # receive ONE byte
24
        if len(byte) == 0:      # test timeout
25
            break               # break for loop prematurely
26
        byte = byte[0]          # uses the first byte only (of one byte received)
27
        data_in.append(byte)    # append to data_in array
28
    print('>>>', data_in)
29
30
# >>> [13, 10, 77, 80, 89, 58, 32, 115, 111, 102, 116, 32, 114, 101, 98, 111]

von Thomas W. (dbstw)


Lesenswert?

Ich habe ja keine Ahnung davon, aber bevor ich anfange haette ich gerne 
die Protokollbeschreibung (und nicht die Interpretation des TOs!). Wie 
erkennt die Maschine (der Empfaenger) den Anfang des Kommandos, wie ist 
Rueckmeldung aufgebaut. Wie sind die Parameter nach dem Kommando 
aufgebaut, wie wird die Pruefsumme erstellt (Nur ein Byte ist bei 10 
Bytes nicht ausreichend, bei der Summe sind zwei Bytes noetig).

Wenn der TO das nicht weiss: Vielleicht gibt es ja einen Hersteller und 
ein Typenschild, man koennte eine Suchmaschine benutzen um Informationen 
zu finden.

Wenn man dann die Suchmaschine schon gestartet hat, koennte man mit den 
Suchbegriffen "Visual basic serial port example" bei Microsoft die 
Programmbeispiele finden. Dort kann man auch den Event-Handler fuer den 
Empfang (der noch nicht definiert ist) finden. Ich persoenlich finde "C# 
serial port example" schoener, aber vielleicht habe ich einfach genug 
Basic im Leben programmiert. Und man kann auch sehr einfach die GUI 
erstellen (Visual Studio ist schon nicht schlecht).

Vielleicht koennte der TO auch mal zeigen, was er gemacht und probiert 
hat,
denn man koennte dieses alte Bonmot herausholen (aus 
Beitrag "Re: Hilfe bei Z80 Opcodes"):

> Und nein, dieses Forum ist zwar hilfreich, aber es ist kein
> Cola-Automat, wo man auf den Knopf drückt und schon kommt der Pappbecher
> mit dem fertigen Drink heraus. Etwas eigene Arbeit (auch
> Einarbeitungsarbeit in den Z80) wäre vonnöten gewesen, schließlich ist
> es DEINE Maschine, die jetzt doof herumsteht und nicht mehr benutzbar
> ist.

Viele Gruesse, schoenes WE

von Walter L. (Gast)


Lesenswert?

Hallo,

ich danke für alle konstruktiven Beträge.
Allen kann ich mom. nun nicht gezielt antworten.

Zur Info.:
Die Steuerung der CNC habe ich bis 1998 entwickelt.
Jetzt war die CNC defekt (Maschinenteil) und ist wieder Rep.
Das Prog. ist für den SERVICE gedacht gewesen...
Es ist eine Privatangelegenheit...

Mom. bin ich dabei den damalige RS232_Versuch mit VISUAL 6 zu finden...

Ich melde mich, wenn ich da was zeigen kann.

VG Walter

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Klaus S. schrieb:
> Ratespielchen mit Halbwissen. Warum soll man sich sowas antun? Und dann
> noch die falsche Checksum in

Mit solchem Halbwissen und Ratespielchen hatte ich damals erst die 
Platine
in Win zum Laufen gebracht. Da war auch nur ein uraltes MS-DOS Programm
und etwas QuickBasic-Quelltext dabei.

Da der TO damals die Steuerung selbst entwickelte, wird es doch wohl
für ihn ein Leichtes sein, die richtige Bytesequenz zu schicken. Die
Antwort der CNC kann er ja einfach empfangen. So schnell kann der
den nächsten Befehl gar nicht tippen, daß er dafür einen Timeout
bräuchte.

Daß er die CNC selber entwickelte wußten wir ja bis jetzt gar nicht.
Warum läßt er uns dann ewig herumraten ?

Zumindest ein kleines Konsoleprogramm wird er dann doch hin bekommen.
Das Forum hier ist ja nicht da, um mundfertiges zu presentieren. Ein
wenig Hand anlegen muß er da schon selber.

Und wenn das läuft, kann er immer noch mit einer GUI anfangen.
Wenn er dann unbedingt Buttons haben will, ist so ein GUI-Designer
nicht gut geeignet. Da bekommt er für jeden Button eine Eventprozedur.
Das wird dann ein Monster an Quellcode. Da ist es besser, die Buttons
in einer Schleife zu erstellen und das jeweilige Handle in ein Array
zu legen. In der Ereignisschleife wird dann in einer extra Schleife
der Klick abgefragt. Natürlich muß die Sprache das auch unterstützen.

von Norbert (der_norbert)


Lesenswert?

Heinz B. schrieb:
> Und wenn das läuft, kann er immer noch mit einer GUI anfangen.
> Wenn er dann unbedingt Buttons haben will, ist so ein GUI-Designer
> nicht gut geeignet. Da bekommt er für jeden Button eine Eventprozedur.
> Das wird dann ein Monster an Quellcode.

Ich weiß ja nicht womit du arbeitest, aber hier bei mir können Hunderte 
von Buttons präzise einen Event auslösen und ihren Index übergeben. Das 
wird dann ein Winzling an Quellcode.

von Monk (roehrmond)


Lesenswert?

Heinz B. schrieb:
> Das Forum hier ist ja nicht da, um mundfertiges zu presentieren.

Wirklich nicht? Na sowas aber auch!

von Heinz B. (Firma: Privat) (hbrill)


Angehängte Dateien:

Lesenswert?

Norbert schrieb:
> Ich weiß ja nicht womit du arbeitest, aber hier bei mir können Hunderte
> von Buttons präzise einen Event auslösen und ihren Index übergeben. Das
> wird dann ein Winzling an Quellcode.

Ich dachte, das wäre bei VB so. Sorry.

Bei mir macht das auch nur 36 Zeilen Quellcode incl. Auslesen des
Handle und des Textes und Anzeigen in der Statusbar.

: Bearbeitet durch User
von Klaus S. (kseege)


Lesenswert?

Heinz B. schrieb:
> Mit solchem Halbwissen und Ratespielchen hatte ich damals erst die
> Platine
> in Win zum Laufen gebracht. Da war auch nur ein uraltes MS-DOS Programm
> und etwas QuickBasic-Quelltext dabei.

Das ist das Positive an Dir, Du kannst mit Fummeln und Ausprobieren was 
zum Funktionieren bringen.

Heinz B. schrieb:
> Die
> Antwort der CNC kann er ja einfach empfangen. So schnell kann der
> den nächsten Befehl gar nicht tippen, daß er dafür einen Timeout
> bräuchte.

Das ist das Negative an Dir. Du behauptest im Brustton der Überzeugung 
Dinge, die nach meinem Wissen grottenfalsch sind. Eine Antwort kann vom 
Programm nur dann als vollständig erkannt werden, wenn entweder
1.) die Länge der Antwort vorher bekannt ist
2.) ein Endezeichen vereinbart ist
3.) eine Zeitüberschreitung erkannt wird

Da 1.) und 2.) nicht erfüllt sind, bleibt nur 3.).
Egal ob über einen automatischen Timeout in der Funktion oder durch 
permanentes Polling der Länge und Erkennen der ausbleibenden Änderung.

Gruß Klaus (der soundsovielte)

von Walter L. (Gast)


Lesenswert?

Verehrte Community,

das Grundproblem um 2003 waren die Unterbrechungen beim Senden der 11 
Bytes durch das Betriebssystem Windows (die Erinnerungen sind zurück).

Das Unternehmen, mit dem ich damals zusammenarbeitete, setzte die 
Kithara Real Time Suite ein, um das Problem zu lösen.

Da mir die Kithara Real Time Suite nicht zur Verfügung steht werde ich 
einen kleinen Controller nehmen, der dieses kleine aber entscheidenden 
Schlagloch ausbügelt.

Bei gegebener Zeit berichte ich gerne über die Lösung.

VG Walter

von Monk (roehrmond)


Lesenswert?

Das Problem wird wohl mit einem USB Serial/CDC Adapter nicht auftreten, 
weil da immer bis zu 64 Bytes im Block übertragen werden. Deine 11 Bytes 
passen da rein. Windows hat keinen Grund, die 11 Bytes zu splitten, 
solange dein Programm sie auch in einem Stück sendet, gefolgt von einem 
flush oder Warten auf Antwort.

: Bearbeitet durch User
von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Klaus S. schrieb:
> Das ist das Negative an Dir. Du behauptest im Brustton der Überzeugung
> Dinge, die nach meinem Wissen grottenfalsch sind. Eine Antwort kann vom
> Programm nur dann als vollständig erkannt werden, wenn entweder
> 1.) die Länge der Antwort vorher bekannt ist
> 2.) ein Endezeichen vereinbart ist
> 3.) eine Zeitüberschreitung erkannt wird

Das sind ja Grundlagen, die man vorraussetzt. Das ist auch bei jeder
Doku der RS232 im Netz dabei.
zu 1. Klar, die Längen der Antworten können immer variieren, deswegen
      auch der Puffer.
      Natürlich muß der Empfangspuffer groß genug sein. Die 1024
      Bytes genügen im allgemeinen. Solche Hardware gibt ja sicherlich
      keine Romane zurück. Normalerweise weiß man in etwa die 
Höchstlänge.
      Demnach richtet man sich den Puffer ein und liest ihn auch ganz
      aus. Danach kann man den sogar mit der API PurgeCom löschen,
      damit keine Restdaten zurück bleiben.
zu 2. Da der TO die Hardware und somit die Software darauf selber
      gebaut hat, weiß er auch das Endezeichen, das die Hardware
      zurück gibt.
zu 3. hatte ich noch bei keiner Hardware. Im Gegenteil : Wenn man
      ca. 200 - 300 ms nach dem Senden mit dem Lesen wartet ist das ok.
      Das Timeout wird dann relevant, wenn periodisch und automatisch
      in ganz kurzen Abständen gesendet wird. Aber da würde ich lieber
      die Handshake-Leitungen in Betracht ziehen.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Stephan S. schrieb:

> Walter L. schrieb:
>> 0  1  2  3  4  5  6  7  8  9  10
>>
>> 3  0  0  0  0  0  0  0  0  0   3
>
> Das sind mit ENTER in der Windows-Welt aber 12 (zwölf) Bytes und nicht
> 11. In Windows wird ENTER mit CR LF übergeben, also 0xD 0xA

Das ist offensichtlich ein binäres Protokoll, kein Textprotokoll. 
Dementsprechend spielen irgendwelche Zeilenende-Zeichen keinerlei Rolle. 
Es gibt keinerlei Zeilen.

von Klaus S. (kseege)


Lesenswert?

Heinz B. schrieb:
> zu 3. hatte ich noch bei keiner Hardware. Im Gegenteil : Wenn man
>       ca. 200 - 300 ms nach dem Senden mit dem Lesen wartet ist das ok.
>       Das Timeout wird dann relevant, wenn periodisch und automatisch
>       in ganz kurzen Abständen gesendet wird. Aber da würde ich lieber
>       die Handshake-Leitungen in Betracht ziehen.

Dann ist das ein Streit um des Kaisers Bart. Für mich ist "300 ms 
warten" ein Timeout und die Handshake-Leitung eine vereinbarte 
Endekennung. Damit sind wir uns wohl in der Sache, aber nicht in der 
Benamsung einig. Mir geht es einfach nur darum, daß spätere Leser nicht 
auf falsche Fährten gesetzt werden.

Gruß Klaus (der soundsovielte)

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Walter L. schrieb:

> das Grundproblem um 2003 waren die Unterbrechungen beim Senden der 11
> Bytes durch das Betriebssystem Windows (die Erinnerungen sind zurück).

Das passiert, wenn man wirklich Zeichen für Zeichen sendet. Da kann 
schonmal ein Taskwechsel dazwischen hauen und die Sache für 10ms oder 
mehr unterbrechen. So ist das nunmal bei Multitasking-Systemen.

Sowas konnte aber sogar unter DOS passieren, obwohl das kein MT-System 
ist. TSR-Programme (AKA: "Hintergrundprogramme") machten es möglich. Die 
ergeben (zusammen mit dem eigentlichen Programm) auch so eine Art 
Multitasking-System. Funktioniert im Prinzip genauso, wie Programme auf 
kleinen µC, die Interrupts nutzen.

Aber die Lösung ist natürlich einfach und logisch: Man schreibt eben 
nicht jedes Zeichen einzeln, sondern übergibt einen 11 Byte großen 
Buffer zum Schreiben an den Gerätetreiber. Das nennt sich asynchrones 
IO. Damit alleine ist zwar, genau genommen, die Unterbrechungsfreiheit 
immer noch nicht sicher gestellt, aber hier hilft die geringe Größe der 
Nachricht. Die ist so klein, dass sie garantiert sowohl in den 
Hardwarepuffer eines echten  COM-Ports passt (jedenfalls, wenn man es 
nicht gerade mit einem ziemlich historischen Rechner mit 8250-UART zu 
tun hat) als auch in den Sendebuffer des Hosts für ein USB-CDC-Device.

> Das Unternehmen, mit dem ich damals zusammenarbeitete, setzte die
> Kithara Real Time Suite ein, um das Problem zu lösen.

Die hatten entweder keine Ahnung oder sie wollten es besonders gut und 
"zukunftssicher" machen. Nötig ist das hier nicht. Unter der günstigen 
Randbedingung der geringen Nachrichtengröße kann man das allein mit dem 
Win32-COMM-Api völlig problemlos umzusetzen.

Benutzt man den SerialPort des .net-Frameworks, wird es noch einfacher. 
Das benutzt nämlich von Hause aus asynchrones IO. Sprich: hier brauchst 
du bloß ein 11 Byte großes Array erzeugen, mit dem gewünschten Inhalt zu 
füllen und dann die Write-Methode des SerialPorts (in der Überschreibung 
für ein Byte-Array) aufrufen und der Drops ist gelutscht.

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Der TO wird wohl eher Probleme mit dem Stringende-Zeichen
bekommen, wenn das was als Windowsprogramm werden soll.
Das hatte ich vor Jahren mit meinem selbst programmierten
AVR auch. Da bin ich fast verzweifelt. An den String, den
ich mit dem AVR senden wollte, ein Chr$(0) in BASCOM drangehängt,
und schon ging es. Ich muß auch dazu sagen, daß meine Programmier-
sprache für Windows nur Strings über die RS232 senden und empfangen
konnte.

Ich denke mal nicht, daß der TO damals (1998) daran gedacht hatte,
zumal das damals über ein DOS-Programm betrieben wurde. Da muß er
schauen, ob seine Sprache auch Speicherbereiche senden und empfangen
kann. So ein Speicherbereich läßt sich ja einfach in einen String
mit Nullbyte am Ende konvertieren.

Da er die Hardware ja selber baute, könnte er sie ja auch
softwaremäßig updaten. Das ginge dann auch.

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Wenn mich eines an diesem Forum fasziniert, dann sind es die ›Annahmen‹ 
die sich einige ausdenken um ein gegebenes Problem in ihre eigene 
spezielle Gedankenwelt zu transponieren.

von Harald K. (kirnbichler)


Lesenswert?

Walter L. schrieb:
> das Grundproblem um 2003 waren die Unterbrechungen beim Senden der 11
> Bytes durch das Betriebssystem Windows (die Erinnerungen sind zurück).

Das klingt nach Humbug. Auch 2003 konnte man unter Windows über eine 
serielle Schnittstelle elf Bytes so ausgeben, daß sie ohne Unterbrechung 
ausgegeben wurde. Ohne große Klimmzüge, einfach durch Nutzung der 
Win32-API.

> Das Unternehmen, mit dem ich damals zusammenarbeitete, setzte die
> Kithara Real Time Suite ein, um das Problem zu lösen.

Kann man natürlich machen, um seine elementare Unfähigkeit in der 
Nutzung der Win32-API zuzudecken, und es klingt sehr, sehr 
beeindruckend. "Real Time". Klar. Braucht man für elf Bytes. Bei 9600 
Baud.

O weh.

von Hmmm (hmmm)


Lesenswert?

Heinz B. schrieb:
> Der TO wird wohl eher Probleme mit dem Stringende-Zeichen
> bekommen, wenn das was als Windowsprogramm werden soll.

Windows interessiert sich nicht dafür, was das für Daten sind. Wäre auch 
fatal, wenn es so wäre, weil WriteFile() für deutlich mehr als nur 
serielle Kommunikation verwendet wird.

Heinz B. schrieb:
> Ich muß auch dazu sagen, daß meine Programmier-
> sprache für Windows nur Strings über die RS232 senden und empfangen
> konnte.

Dann lag das Problem dort.

von L.S. (lagerschaden)


Lesenswert?

Walter L. schrieb:
> 0  1  2  3  4  5  6  7  8  9  10
>
> 3  0  0  0  0  0  0  0  0  0   3
>
> alles dezimal.

Es ist immer noch nicht klar, ob eine 3 eine '3' ist oder 0x03.

Wird der Befehl 89 mit 0x59 binär codiert, mit '89' als ASCII, mit 0x08 
0x09, mit '089' oder mit 0x00 0x08 0x09 (die Befehle gehen ja bis 151)?

Da sollte der TE mal endlich Stellung nehmen.

von Klaus S. (kseege)


Lesenswert?

Norbert schrieb:
> Wenn mich eines an diesem Forum fasziniert, dann sind es die ›Annahmen‹
> die sich einige ausdenken um ein gegebenes Problem in ihre eigene
> spezielle Gedankenwelt zu transponieren.

Techniker sind eben nicht so phantasielos, wie man manchmal meinen 
möchte.

Vielen Dank übrigens für das Python-Programm. Da ich gerade darin 
dilettiere, kam es mir wie gerufen.

Gruß Klaus (der soundsovielte)

von Klaus (feelfree)


Lesenswert?

Dir
L.S. schrieb:
> ist immer noch nicht klar, ob eine 3 eine '3' ist oder 0x03.

Schade für dich, allen anderen längst.

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Hmmm schrieb:
> Windows interessiert sich nicht dafür, was das für Daten sind. Wäre auch
> fatal, wenn es so wäre, weil WriteFile() für deutlich mehr als nur
> serielle Kommunikation verwendet wird.

Und bei ReadFile() auch.
Wenn ein Chr$(0) am Stringende da ist, liest es das mit, andernfalls
eben nicht. Und das ist ja auch nicht das Thema. Das liegt eher an
den 2 Welten (Controller-Welt vs. Windows-Welt). Weil nullterminierte
Strings mittlerweile Standard sind, klappt das dann auch nicht, wenn
der Mikrocontroller kein Chr$(0) dranhängt. Die Programmiersprache 
erkennt
den String dann nicht. So einfach ist das.
Dann geht es, wie oben schon erwähnt, nur über einen Speicherbereich.

: Bearbeitet durch User
von Walter L. (Gast)


Lesenswert?

kirnbichler

Wo ist der Nachweis.
Müsste für sie eine Kleinigkeit von 10 Minuten sein das Prog. hier 
einzustellen. (VS 2022, Kon.-Anwendurg, C++ oder C# 11 Bytes senden, 
CP2102, COM5).

VG Walter

von Hmmm (hmmm)


Lesenswert?

Heinz B. schrieb:
> Das liegt eher an den 2 Welten (Controller-Welt vs. Windows-Welt).

Das ist bei Dir eher BASIC-Welt vs. richtige Welt. Windows will einen 
Pointer und die Anzahl zu sendender Bytes, der Inhalt ist völlig egal.

Nur die Byte Order kann natürlich bei übertragenen Werten mit >8 Bit 
Ärger machen, wenn man sich darüber keine Gedanken macht, aber auch die 
ist dem Betriebssystem egal und betrifft nur Deine Anwendung.

Heinz B. schrieb:
> Weil nullterminierte
> Strings mittlerweile Standard sind, klappt das dann auch nicht, wenn
> der Mikrocontroller kein Chr$(0) dranhängt.

Wenn Du mit einer Murks-Sprache arbeitest, die sowas erwartet, mag das 
stimmen. Üblich ist das jedenfalls nicht, selbst bei menschenlesbaren 
Protokollen hängt man vielleicht noch CR und/oder LF dran, aber eher 
kein 0x00.

Intern kann man selbstverständlich mit nullterminierten Strings 
arbeiten, aber man sendet sie nicht mit.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Walter L. schrieb:

> Wo ist der Nachweis.
> Müsste für sie eine Kleinigkeit von 10 Minuten sein das Prog. hier
> einzustellen. (VS 2022, Kon.-Anwendurg, C++ oder C# 11 Bytes senden,
> CP2102, COM5).

Er will halt keine stinkenfaulen Hassler unterstützen. Genausowenig, wie 
ich das will oder jeder andere, der tatsächlich was vom Problem 
versteht.

Du hast alles an Hilfe bekommen, was nötig ist, um selber ohne große 
Probleme eine Lösung zu implementieren. Sogar mit mehreren möglichen 
Ansätzen. Wenn du wenigstens grundlegend willig und fähig wärest, 
selber zu programmieren.

Das ist aber offensichtlich nicht der Fall. Du willst dein konkretes 
Problem für lau von Anderen erledigen lassen.

Also ein Scheiß-Parasit. Sowas mag echt niemand...

von Thomas W. (dbstw)


Lesenswert?

Walter L. schrieb:
> kirnbichler
>
> Wo ist der Nachweis.
> Müsste für sie eine Kleinigkeit von 10 Minuten sein das Prog. hier
> einzustellen. (VS 2022, Kon.-Anwendurg, C++ oder C# 11 Bytes senden,
> CP2102, COM5).
>
> VG Walter

Wo ist Dein Ansatz, Dein Versuch? Du kannst nicht erwarten, dass jemand 
fuer Dich arbeitet. Oder Muenzen einwerfen (dann aber das Protokoll und 
Lastenheft vorlegen).

Hast Du denn die Beispiel von Microsoft mal ausprobiert und kannst 
berichten? Nein? Auch gut.

P.S.: Warum hat diese Schoene Forum-Software keine Kill-File?

: Bearbeitet durch User
von Walter L. (Gast)


Lesenswert?

Jetzt kommen von hinten durch die Brust ins Auge die Dollarzeichen in 
die Augen.

Was kosten die 10  Minuten?

Um von vornherein Klarheit bei diesen tollen Hechten zu schaffen:
Es gilt in diesen Fälle die alte Kaufmenschregel, erst die Ware, dann 
das Geld...

VG Walter

von Klaus (feelfree)


Lesenswert?

Walter L. schrieb:
> Was kosten die 10  Minuten?

10 Minuten kosten 10 Minuten.
Allerdings kenne ich so viele Menschen, denen ich lieber 10 Minuten 
meiner Zeit schenke als dir.

von Walter L. (Gast)


Lesenswert?

Hoffentlich verstößt das nicht gegen Forumsregeln..

Ich schlage vor:

Gefliefert wird zunächst ein EXE-File.

Eingebbar muss die COMSCHNITSTELLE sein.
Gesendet werden 11 Bytes, Pause 10mSek +-1mSek, wieder 11 Bytes, usw.
VS 2022, Kon.-Anwendurg, C++ oder C#, CP2102.

Den EXE-file starte ich auf einem isolierten PC...

Die Daten leite ich in einen Kontroller, der den lückenlosen Strom der 
11  Bytes prüft.

Schaun wir mal.

VG Walter

von Walter L. (Gast)


Lesenswert?

@feelfree Heiße Luft. Die brauche ich nicht.

von Klaus (feelfree)


Lesenswert?

Walter L. schrieb:
> Heiße Luft

Mehr bekommst du nach diesem Auftritt hier auch nicht mehr.

Walter L. schrieb:
> Pause 10mSek +-1mSek,

Ah, eine neue Scheibe der Salami.

von Hmmm (hmmm)


Angehängte Dateien:

Lesenswert?

Walter L. schrieb:
> Pause 10mSek +-1mSek

Darauf würde ich mich insbesondere über USB nicht verlassen.

Walter L. schrieb:
> VS 2022, Kon.-Anwendurg, C++ oder C#, CP2102.

Kein VS und in C.

Walter L. schrieb:
> Den EXE-file starte ich auf einem isolierten PC...

COM-Port als Parameter, z.B. "comtest COM5". Viel Spass!

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Hmmm schrieb:
> Walter L. schrieb:
>> Pause 10mSek +-1mSek
>
> Darauf würde ich mich insbesondere über USB nicht verlassen.
>
> Walter L. schrieb:
>> VS 2022, Kon.-Anwendurg, C++ oder C#, CP2102.
>
> Kein VS und in C.
>
> Walter L. schrieb:
>> Den EXE-file starte ich auf einem isolierten PC...
>
> COM-Port als Parameter, z.B. "comtest COM5". Viel Spass!

Ich würde mal davon ausgehen, dass das nicht wirklich den Intentionen 
dieses Hasslers entspricht ;o)

Der hat ganz sicher viel von dem unerwähnt gelassen, was er eigentlich 
will. Das erste Anzeichen dafür war natürlich, dass er das (ihm 
offensichtlich bekannten) Protokoll nicht offengelegt hat. Es ist davon 
auszugehen, dass in diesem 11Byte-Paket eine Prüfsumme steckt, die mehr 
als ein Byte umfasst. Und es ist davon auszugehen, dass die vielen 
Nullbytes längst nicht bei jedem Kommando Null sein werden, sondern 
Parameter des Kommandos sind.

Dieser Typ ist einfach nur ein Nassauer. Aber sogar als solcher: 
dramatisch inkompetent. Der wird nix mehr, nichtmal Manager...

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Hmmm schrieb:
> Das ist bei Dir eher BASIC-Welt vs. richtige Welt. Windows will einen
> Pointer und die Anzahl zu sendender Bytes, der Inhalt ist völlig egal.

Also ich hatte bis jetzt auf keinem Mikrocontroller ein MS-DOS
oder Windows oder sonst was gefunden. Das einzig gemeinsame ist
der ASCII (OEM) Zeichensatz und das war es.

Und außerdem geht es hier nicht ums Senden sondern ums Empfangen.
Wenn die Sprache halt nur Strings senden/empfangen  kann, muß man
halt mit der Windows-API und Speicherbereichen oder entspr. DLL 
arbeiten.
Das habe ich ja jetzt schon öfter angedeutet.

Und einen Speicherbereich bzw. Pointer darauf kannst du auch nicht
einfach ausgeben. Die Zeichen darin muß man mal zuerst in eine
Stringvariable kopieren. Und dann bist du wieder dort, wo du warst.
Da ist es egal, ob BASIC, C oder sonstige Sprache. Das funktioniert
überall gleich.

Ich gebe hier mal ein Stichwort aus den Anfangsjahren von Windows :
DELPHI + DLL erstellen + Strings (PascalString vs. TCHAR)

von Klaus (feelfree)


Lesenswert?

Heinz B. schrieb:
> Wenn die Sprache halt nur Strings senden/empfangen  kann

dann ist entweder der Horizont seines Anwenders zu beschränkt oder die 
Programmiersprache für den Anwendungszweck völlig ungeeignet.
Ich vermute ersteres.

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Schaut mal z.b. hier :
https://www.c-howto.de/tutorial/strings-zeichenketten/nullterminiert/
Vielleicht fällt bei euch dann der Groschen.
Oder nehmt mal die renomierte Sprache DELPHI. Dort ist es besonders 
krass.
Warum halten die sich nicht einfach nur an Standards ?

Man könnte jetzt in dem Zusammenhang noch mehrere Sachen nennen,
z.b. UTF8 bzw. UNICODE, wo eine ähnliche Problematik besteht.
Das ist zwar heute standardisiert, war es aber nicht seit Anfang an.
Aber dafür seit ihr wahrscheinlich zu jung und habt es erst gar nicht
mitbekommen.

Und dafür ist euer Horizont wiederrum zu beschränkt, weil ihr
einfach gar nicht wißt, was unter der Haube geschieht.

Damit ist das Thema für mich erledigt.

: Bearbeitet durch User
von Harald K. (kirnbichler)


Lesenswert?

Heinz B. schrieb:
> Vielleicht fällt bei euch dann der Groschen.

Du bellst den komplett falschen Baum an. Es geht überhaupt nicht um 
Strings, es geht nur um elf dämliche Bytes.

Tatsächlich aber geht es um etwas noch ganz anderes, was der tolle 
Threadstarter als Salamischeibe gerade vorhin erst rausgerückt hat:

Walter L. schrieb:
> Gesendet werden 11 Bytes, Pause 10mSek +-1mSek, wieder 11 Bytes, usw.

Nämlich daß hier eine Sendepause von 10 +/- 1 msec gefordert wird.

Die kann zwar ein Windows selbst durchaus hinbekommen (wenn man weiß, 
wie man die Timergranularität verändert), aber die sind mit einem 
USB-Seriell-Adapter aufgrund der Funktionsweise von USB durchaus eine 
Herausforderung.

von Klaus (feelfree)


Lesenswert?

Heinz B. schrieb:
> Und dafür ist euer Horizont wiederrum zu beschränkt, weil ihr
> einfach gar nicht wißt, was unter der Haube geschieht.

Schreibt einer, der offensichtlich zu blöd dafür ist, 11 beliebige Bytes 
über eine serielle Schnittstelle zu schicken.

Kannst du dir nicht ausdenken sowas...

Heinz B. schrieb:
> Damit ist das Thema für mich erledigt.

Das ist eine gute Nachricht.

von Hmmm (hmmm)


Lesenswert?

Harald K. schrieb:
> Die kann zwar ein Windows selbst durchaus hinbekommen (wenn man weiß,
> wie man die Timergranularität verändert), aber die sind mit einem
> USB-Seriell-Adapter aufgrund der Funktionsweise von USB durchaus eine
> Herausforderung.

Ein weiteres Problem ist der FIFO. Zwischen WriteFile() und "letztes 
Stopbit gesendet" vergeht also viel Zeit, die kaum exakt bestimmbar ist.

Im Fall von RS485 habe ich das seinerzeit gelöst, indem ich das eigene 
Echo gelesen (und das Timing nicht zu eng gemacht) habe, aber das 
scheidet hier ja aus.

Allerdings passt die komische 10ms-Anforderung auch nicht zur früheren 
Aussage, dass eine Antwort vom Gerät kommen soll.

von Monk (roehrmond)


Lesenswert?

Hmmm schrieb:
> Wenn Du mit einer Murks-Sprache arbeitest, die sowas erwartet ...

Ich kann mir kaum vorstellen, dass sein Basic Dialekt keine Byte-Arrays 
unterstützt.

> Intern kann man selbstverständlich mit nullterminierten Strings
> arbeiten

Was in Basic allerdings ungewöhnlich wäre, denn da haben Zeichenketten 
das normalerweise nicht. Stattdessen haben sie eine Längen-Angabe.

: Bearbeitet durch User
Beitrag #7655711 wurde vom Autor gelöscht.
von Monk (roehrmond)


Lesenswert?

Heinz B. schrieb:
> Und einen Speicherbereich bzw. Pointer darauf kannst du auch nicht
> einfach ausgeben. Die Zeichen darin muß man mal zuerst in eine
> Stringvariable kopieren. Und dann bist du wieder dort, wo du warst.
> Da ist es egal, ob BASIC, C oder sonstige Sprache. Das funktioniert
> überall gleich.

Nein, das funktioniert eben nicht in jeder Sprache gleich.

Wie bereits korrekt angemerkt wurde, erwartet die Windows API (ebenso 
wie Linux) einen Zeiger auf die Bytes und eine Längenangabe. Das 
betrifft letztendlich alle mir bekannten Programmiersprachen. Wer auch 
immer etwas andere als eine Anzahl von byte senden will, benutzt 
(eventuell unbewusst) Hilfsfunktionen, die darauf aufbauen.

Visual Basic kann nicht nur Strings senden, sondern auch eine Anzahl von 
Bytes.
> Public Sub Write (buffer As Byte(), offset As Integer, count As Integer)

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

Klaus schrieb:
> Schreibt einer, der offensichtlich zu blöd dafür ist, 11 beliebige Bytes
> über eine serielle Schnittstelle zu schicken.

Darum geht es ja gar nicht. Dann halt nochmal :
Ob die Sprache nur Strings schicken kann, ist doch egal. In einen
String bekommt man auch pro Stelle ein Byte unter.
Unter der Haube schreibt sie auch mit der WriteFile - API. Ob ich
nun selber einen Speicherbereich allociere oder die Sprache macht
das vorm Senden intern. Die nimmt einfach den String entgegen,
ermittelt die Länge des Strings, allociert entsprechend Speicher, 
schreibt
den Stringinhalt rein und schickt mit WriteFile an die Schnittstelle.
Im Grunde genommen ist es für den Nutzer eine Vereinfachung, da er nicht
noch zuerst Speicher allocieren und füllen muß, sondern den String 
sofort
mit der Funktion der Sprache wegschicken kann. Das hintere Nullbyte
vom String interessiert da gar nicht.

Und genauso geht es auch anders rum.

Die kochen alle nur mit Wasser und erfinden nicht jedes mal das Rad
neu.

Beitrag #7655719 wurde vom Autor gelöscht.
von Monk (roehrmond)


Lesenswert?

Heinz B. schrieb:
> Ob die Sprache nur Strings schicken kann, ist doch egal. In einen
> String bekommt man auch pro Stelle ein Byte unter.

Ja, aber die Null Bytes mitten drin sind beim Null-Terminierten Strings 
problematisch, eben weil sie bei einigen Programmiersprachen das Ende 
des Strings kennzeichnen.

Man nimmt hier bitteschön Byte-Arrays. Das geht auch in Basic.

von Klaus (feelfree)


Lesenswert?

Heinz B. schrieb:
> Dann halt nochmal :

Wie oft willst du noch bestätigen, dass du keine Ahnung hast?

von Harald K. (kirnbichler)


Lesenswert?

Hmmm schrieb:
> Ein weiteres Problem ist der FIFO. Zwischen WriteFile() und "letztes
> Stopbit gesendet" vergeht also viel Zeit, die kaum exakt bestimmbar ist.

Fifos lassen sich abschalten. Auch bei USB-Seriell-Bridges.

Ausreichend präzise funktionierende Timer vorausgesetzt, könnte man auch 
bei Beginn der Übertragung einen solchen Timer aufziehen, der nach x 
Bytezeiten auslöst. Wie lang eine Bytezeit ist, sollte man ausrechnen 
können ...

> Im Fall von RS485 habe ich das seinerzeit gelöst, indem ich das eigene
> Echo gelesen (und das Timing nicht zu eng gemacht) habe, aber das
> scheidet hier ja aus.

Das ist ja nun völlig überflüssig, seitdem es UARTs mit 
Hardwareunterstützung  für RS485 gibt - und jede etwas bessere 
USB-UART-Bridge hat die, so z.B. FTDI. Da muss man sich nicht selbst um 
die Sender-/Empfänger-Umschaltung kümmern.

Und wenn man (in der vorderen Altsteinzeit) mit 8250/16450 gearbeitet 
hat, musste man halt auf die Kombination von THRE und TEMT im LSR 
warten.

von Hmmm (hmmm)


Lesenswert?

Harald K. schrieb:
> Ausreichend präzise funktionierende Timer vorausgesetzt, könnte man auch
> bei Beginn der Übertragung einen solchen Timer aufziehen, der nach x
> Bytezeiten auslöst.

Klar, kann man alles tun, aber für +-1ms würde ich unter Windows mit 
USB-Seriell-Adapter nicht meine Hand ins Feuer legen wollen. Das wäre 
eher etwas für einen externen Controller.

Harald K. schrieb:
> Das ist ja nun völlig überflüssig, seitdem es UARTs mit
> Hardwareunterstützung  für RS485 gibt - und jede etwas bessere
> USB-UART-Bridge hat die, so z.B. FTDI.

Deshalb schrieb ich "seinerzeit", das ist über 20 Jahre her. Heute würde 
ich mir das dank FT232 nicht mehr antun.

Harald K. schrieb:
> Und wenn man (in der vorderen Altsteinzeit) mit 8250/16450 gearbeitet
> hat, musste man halt auf die Kombination von THRE und TEMT im LSR
> warten.

War im Mittelalter, daher 16C550A unter Windows NT. Die Echo-Methode 
funktionierte tadellos.

von Harald K. (kirnbichler)


Lesenswert?

Hmmm schrieb:
> War im Mittelalter, daher 16C550A unter Windows NT. Die Echo-Methode
> funktionierte tadellos.

Der aber hatte die gleichen Register, und das Fifo ließ sich abschalten.

Allerdings - das ging natürlich nur auf Devicetreiberebene, die 
Win32-API hat dir da wenig Möglichkeiten gegeben. Und mit dem DDK zu 
hantieren, war immer schon eine Art des Masochismus, keine Frage.

von Walter L. (Gast)


Lesenswert?

@Hmmm

comtest.exe fkt nicht. Getestet auf einem LABTOP mit XP. Sicher liegt es 
an XP, da ist jetzt eine völlig andere CPU drin. Die Platte habe ich neu 
formatiert.

Was halten die tollen Hechte von

public class SerialPort : System.ComponentModel.Component

und

public void Write (char[] buffer, int offset, int count);

Und das P... nicht vergessen.

von Hmmm (hmmm)


Lesenswert?

Walter L. schrieb:
> comtest.exe fkt nicht.

Bitte etwas präziser.

Walter L. schrieb:
> Getestet auf einem LABTOP mit XP. Sicher liegt es
> an XP, da ist jetzt eine völlig andere CPU drin.

Das sollte theoretisch sogar unter Windows 98 laufen.

Walter L. schrieb:
> Was halten die tollen Hechte von

Da bekommt man so richtig Lust, Dir zu helfen.

von Walter L. (Gast)


Lesenswert?

@Hmmm

Wo nix erscheint, kann man auch nix präzisieren, sonst hätte...

Ich erwarte hier kein Hilfe mehr.

Schon gemerkt?

von Hmmm (hmmm)


Lesenswert?

Walter L. schrieb:
> Wo nix erscheint, kann man auch nix präzisieren, sonst hätte...

Nicht vom Command Prompt gestartet? Das ist eine Consolenanwendung, 
schon vergessen?

Lässt sich hier übrigens problemlos in einer XP-VM starten.

Walter L. schrieb:
> Ich erwarte hier kein Hilfe mehr.
> Schon gemerkt?

Du willst nur noch trollen?

: Bearbeitet durch User
von Klaus (feelfree)


Lesenswert?

Hmmm schrieb:
> Walter L. schrieb:
>> Pause 10mSek +-1mSek
>
> Darauf würde ich mich insbesondere über USB nicht verlassen.
>
Mit dem CP2102 unter Win11 macht dein Progrämmchen bei mir ca. 4.2ms 
Pausen zwischen den Paketen.

: Bearbeitet durch User
von Hmmm (hmmm)


Lesenswert?

Klaus schrieb:
> Mit dem CP2102 unter Win11 macht dein Progrämmchen bei mir ca. 4.2ms
> Pausen zwischen den Paketen.

Ich sende die Pakete stumpf mit 10ms Delay zwischen den 
WriteFile()-Calls, der Abstand könnte also je nach Chip und Treiber 
erheblich abweichen.

Bei einem Onboard-16550 gibt es vermutlich gar keinen Abstand, weil das 
erste Paket direkt im FIFO landet und das zweite vor den knapp 11.5ms, 
die die Übertragung braucht, nachgeschoben wird.

: Bearbeitet durch User
von Harald K. (kirnbichler)


Lesenswert?

Hmmm schrieb:
> Ich sende die Pakete stumpf mit 10ms Delay zwischen den
> WriteFile()-Calls, der Abstand könnte also je nach Chip und Treiber
> erheblich abweichen.

Naja, da elf Bytes bei 9600,8n1 auf der Leitung etwa 11.5 msec brauchen, 
geht da beim Timing offenbar was schief.

Hast Du Dich denn um die Timergranularität gekümmert? Die beträgt unter 
heutigem Windows 10 msec, d.h. ist deutlich zu grob, um Wartezeiten von 
10 msec irgendwie zuverlässig hinzubekommen.

Man kann die Timergranularität aus Usermode-Programmen verändern, das 
geht mit den "Multimedia"-Timerfunktionen. Ein Aufruf von 
timeBeginPeriod genügt.

https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod

Damit lässt sich die Timergranularität auf 1 msec verringern.

von Hmmm (hmmm)


Lesenswert?

Harald K. schrieb:
> Hast Du Dich denn um die Timergranularität gekümmert?

Nein, mir war seine neue Anforderung mit den exakten Delays schlichtweg 
egal, weil sie nicht zur angeblichen Anwendung (11 Bytes ohne 
Unterbrechungen senden, dann kommt erstmal eine Antwort) passt.

Harald K. schrieb:
> Die beträgt unter heutigem Windows 10 msec

Ungenaues Windows-Timing wäre eine Möglichkeit. Ein weiterer Punkt ist, 
wie lange WriteFile() blockt.

von Norbert (der_norbert)


Lesenswert?

Walter L. schrieb:
> und danach sofort > 1 bis 16 Byte empfängt.
> Danach Pause von 1 Sek oder länger.

Walter L. schrieb:
> Gesendet werden 11 Bytes, Pause 10mSek +-1mSek, wieder 11 Bytes

Ja, ja. Bis zu 16 Bytes empfangen in max 10+1ms über 9600baud.
Wie lange soll dieser Schwachsinn hier noch weiter gehen?

von Harald K. (kirnbichler)


Lesenswert?

Hmmm schrieb:
> Ein weiterer Punkt ist,
> wie lange WriteFile() blockt.

Muss es gar nicht, es gibt schließlich Overlapped-IO.

von Klaus (feelfree)


Lesenswert?

Harald K. schrieb:
> es gibt schließlich Overlapped-IO.

Und das puffert dann beliebig viele Daten, bevor die schließlich auf der 
Schnittstelle landen?

von Udo K. (udok)


Lesenswert?

Klaus schrieb:
>> es gibt schließlich Overlapped-IO.
>
> Und das puffert dann beliebig viele Daten, bevor die schließlich auf der
> Schnittstelle landen?

Das verwendet den Buffer, den du der Funktion übergiebst.  Du darfst den 
Buffer erst wieder anfassen, wenn alle Daten geschrieben worden sind.
Overlapped-IO ist hier völlig unnötig.  Aber lass den Thread doch 
endlich sterben, der TE erfindet seine Probleme, der hat seinen Spass 
daran wenn alle hier hüpfen.

von Franko S. (frank_s866)


Lesenswert?

LOL was für ein Thread.

Die serielle Schnittstelle, 2024, für manche immer noch Voodootechnik.

von Fritz F. (fritz1)


Lesenswert?

Hallo,

ich habe das Prog. mit VISUAL STUDIO 2022 C#.

https://learn.microsoft.com/de-de/dotnet/api/system.io.ports.serialport?view=netframework-4.8#examples

mit Änderungen als Konsolenanwendung zum Laufen gebracht (C# .NET 
Framework 4.8).

Änderungen sind:

Das C#-Prog. sendet nach ENTER 11 Bytes (das 11-te ist die Summe über 
die 10) an einen Controller. Der prüft die Checksumme und sendet O.K. 
zurück, sonst ERRO. Die Verbindung erfolgt über eine USB-Seriell-Adapter 
CP2102.

Jemand Interesse an dem SOURCE-CODE?

VG Fritz

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