Hallo miteinander...
Ich hatte heute einen wunderbaren Vortrag in der Schule bei dem es um
ein kleines Projet (Sensor mit MCU auswrten und entsprechendes C++
Programm) geht.
Aus mehreren Gründen hatte ich zuhause und im Betrieb meine Umgebung in
Visual C++ Express 2008 geschrieben. Soweit so gut. Die Anwendung
funktionierte auch überall (mehrere PC's und Notebooks im Betrieb und
bei mir zuhause getestet, alle mit Win XP und >= SP2).
Doch wie schon oft, ist ein guter Kollege von mir Murphy heute wieder
mal im Schulzimmer anwesend gewesen...
Ich konnte zwar die Releas-Datei ausführen, aber die Datei selber lief
nicht ganz so wie sie es sollte:
-> Automatische Sensor/MCU Suche über RS232 funktionierte nicht, die
Software wollte einfach nichts finden...
-> 2. Versuch: Statisch den Comport zuweisen und konntinuierlich die
Messwerte abfragen -> keine Antwort
die Kommunikation mit dem MCU läuft einwandfrei (Terminal und Borland
CPP)
Hat jemand eine Ahnung, wieso es nicht mit Visual C++ läuft??
hab mich mal zwischendurch selber etwas im www umgesehen, und bin auf
folgendes Thema gestossen:
- Statisch Linken... CRT
Dort wird aber jeweis beschrieben, dass beim Ausführen der EXE-Dateien
schon Fehlermeldungen erscheinen, ist bei mir aber nicht so...
Ich weiss echt nicht weiter (Ihr könnt euch ja sicherlich vorstellen,
wie dann die Präsentation noch verlief...)
Danke für die Infos
MFG
Patrick
Patrick B. schrieb:
> Ich weiss echt nicht weiter (Ihr könnt euch ja sicherlich vorstellen,> wie dann die Präsentation noch verlief...)
Kann ich.
Was lernen wir daraus?
Mach eine Präsentation nie auf einem Rechner, den du vorher noch nie in
den Fingern hattest. Spätestens 1 Tag vorher eine Präsentation
duchspielen. Dabei auch den Rechner runterfahren und neu starten und
kontrollieren obs dann immer noch geht.
> Danke für die Infos
Welche Infos?
Zu welcher Frage? Du hast zwar viel geschrieben aber keine verwertbare
Information gegeben.
> die Kommunikation mit dem MCU läuft einwandfrei (Terminal und> Borland CPP)
Woher weißt du das?
> Hat jemand eine Ahnung, wieso es nicht mit Visual C++ läuft??
Hast du dir ins Programm ein paar Testausgaben eingebaut?
Kannst du mit Sicherheit (zb dadurch dass dir eine Messagebox "ok" bzw.
"nicht ok" gibt) sagen, dass der COM Port geöffnet werden konnte? Wenn
du Kommandos zur MCU schickst, was schickt sie dann zurück? Kennst du
den Text (oder die Bytes bei binärer Kommunikation) den die MCU
zurückschickt? Hast du dir das mal ausgeben lassen?
Stochern im Nebel bringt dich nicht weiter. Du musst Debuggen! Wenn du
auf dem Zielsystem keinen Debugger hast, dann muss eben das Programm dir
Debug-Info geben. Mach dir Ausgaben rein. Alles und jedes was dich
interessiert wird in einer Messagebox (oder auf stdout bei einem
Command-Line Porgramm) ausgegeben, damit du eben nicht im Nebel
stocherst, sondern nachvollziehen kannst, was wann warum im Programm
geschieht.
Karl heinz Buchegger schrieb:
> Welche Infos?> Zu welcher Frage? Du hast zwar viel geschrieben aber keine verwertbare> Information gegeben.
Die Frage lautete, ob jemand weiss an was dass das liegen kann?
>> die Kommunikation mit dem MCU läuft einwandfrei (Terminal und>> Borland CPP)>Woher weißt du das?
ganz einfach:
auf der MCU Ebene mussten wir so Standarttockens vom Lehrer verwenden
('{' senden und '}' zurückbekommen oder '?' senden und Systeminfos
zurückkriegen)
Dies lief mit mehreren Terminals wunderbar.
PC Seitig habe ich die ersten Versuche auf Borland gemacht: * senden und
Messwerte erhalten...
Das Problem war jetzt volgendes: die Suche läuft so ab: @ senden und
Systemname als Antwort überprüfen. * senden Messwert empfangen
Nur lief das Programm nur beim Schul-PC bei der suche von ComPort 1 bis
50 durch und fing wieder vorne an. Ohne beim Com10 den MCU zu finden.
wenn ich Com10 als Standart eingestellt habe, sendete er ein * empfieng
dann aber nichts. => keine Verbindung.
OK, das ob der Comport überhaupt geöffnet werden konnte habe ich nicht
überprüft, und das werde ich erst in 3 Wochen wieder nachschauen können.
Das Interessante daran war, dass das Programm auf einem CAD PC, auf
einem normalen PC (ca 3jährig) und einem älteren Notebook einwandfrei
lieft.
Alle hatten XP und >= SP2 aber nur auf den PC's war VC++ Express
installiert.
Ist es möglich, dass der Comport nicht geöffnet werden konnte, selbst
wenn das identische Programm verwendet wurde?
Was ist, wenn die Schul-PC's nicht sauber aufgesetzt wurden? kein
aktuelles Framework? kann das einen Einfluss haben, auf nur gewisse
Teile des Programms?
MFG
Patrick
Auf den Schul-PC's ist Borland 2007, VC++ 2006, XP Pro, SP2 und noch
andere Software drauf, da die PC's vorallem für GAL, C und C++ verwendet
werden, in dem Schulzimmer...
Ist es möglich, dass du immer noch nicht begriffen hast, dass man
Fehlerursachen nur in den seltensten Fällen richtig erraten kann.
Schau deinem Programm auf die Finger!
Wenn du einen Debugger hast, dann lass das Programm im Debugger laufen
und sieh nach was schief geht, indem du Returnwerte ansiehst, Variablen
verfolgst und generell den Programmfluss im Debugger verfolgst.
Wenn du keinen Debugger hast, dann bau Ausgaben ins Programm ein, die
die gleiche Aufgabe erfüllen.
Alles andere ist Stochern im Nebel und Ratespielchen spielen. Es ist
müssig darüber zu spekulieren was warum nicht funktioniert. Spekulieren
machen die Banker und Wahrsager. Wir sind Techniker. Wir sehen uns die
harten Fakten an und entscheiden dann. Dazu benötigt man aber Mittel und
Wege um sich die Fakten zu besorgen.
Methoden dazu (im konkreten Fall)
* Debugger
* Ausgaben ins Programm einbauen
In jedem Programm, welches länger als 10 Zeilen ist, gibt es tausende
Möglichkeiten, was schief gehen kann! Vor allen Dingen dann, wenn
Systemcalls oder Systemresourcen im Spiel sind.
> OK, das ob der Comport überhaupt geöffnet werden konnte habe ich> nicht überprüft,
Das ist schon mal der erste Fehler.
Man überprüft IMMER, ob die Allokierung eines Gerätes gut gegangen ist.
Sind das immer noch die Routinen aus dem anderen Thread?
Beitrag "comtools Baudrate höher als 57600?"
Falls ja, sieh dir mal den zitierten Teil der Funktion ComOpen an, dazu
hComFile, bIsOpen und MAX_COM_PORTS...
Außerdem muss für Schnittstellennummern > 9 eine andere Syntax für deren
Namen verwendet werden:
COM1 .. COM9
aber
\\.\COM10 .. \\.\COM256
In einer C-String-Konstanten ist \ das Escapezeichen und muss also \\
geschrieben werden:
Karl heinz Buchegger schrieb:
> Ist es möglich, dass du immer noch nicht begriffen hast, dass man> Fehlerursachen nur in den seltensten Fällen richtig erraten kann.
Dem stimme ich dir zu, nur bin ich ratlos, da das identische programm
auf mehreren Rechnern mit unterschiedlichen OS und Benutzeraccounts
funktioniert hat, und dann plötzlich nicht mehr.
>> OK, das ob der Comport überhaupt geöffnet werden konnte habe ich>> nicht überprüft,>> Das ist schon mal der erste Fehler.> Man überprüft IMMER, ob die Allokierung eines Gerätes gut gegangen ist.
hätte ich lieben gerne in der Schule gemacht, nur ist dor Visual C++
2006 und Borland 2007 installiert. Da ich mein Projekt aber in Visual
C++ 2007 erstellt hatte und dafon eine Release-Version benutzte, konnte
ich auch mit noch so guten Absichten am Programm selber nichts ändern.
Leider konnte ich auch nicht Visual C++ 2007 installieren (fehlende
Adminrechte auf dem Laufwerk C und auf dem Persönlichen auch nicht.)
Die Debuggerei so wie du sie beschreibst mit Labels hatte ich, da wie
üblich das ganze Programm nicht von Anfang an so lief, wie ich es wollte
(Probleme mit Substrings, und Timern... => zu schnelles Abfragen)
Arc Net schrieb:
> Sind das immer noch die Routinen aus dem anderen Thread?> Beitrag "comtools Baudrate höher als 57600?">> Falls ja, sieh dir mal den zitierten Teil der Funktion ComOpen an, dazu> hComFile, bIsOpen und MAX_COM_PORTS...
Ja, es sind die gleichen Klassen aber ein anderes Projekt. Mal abgesehen
davon, dass ich MAX_COM_PORTS so definiert habe
1
#define MAX_COM_PORTS 50
und nicht die Defines der COM1 bis COM4 verwende, und den Sensor (RTC
DS1307) so suche
hätte das doch nie und nimmer auf 4 anderen Rechnern laufen dürfen, wenn
der FT232 einen höheren Comport als 9 installiert hätte (Dumme Eigenheit
der FT232 ist, dass JEDER Chip sich eine neue Schnittstelle installiert:
50 Geräte mit USB RS232 Wandler entsprechen 50 "vorgemerkten" Comports,
die man manuel zurücksetzen kann/muss)
@ Rufus t. Firefly
Bei der ComTool-Klasse ist dies schon vordefiniert (die ersten Zeilen
der ComOpen Funktion):
Das ist kein C++ und erst recht kein C, sondern "Managed C++", eine
MS-Perversion, um das .Net-geraffel mit einer C++-artigen Sprache
programmieren zu können.
Mit einem Borland-Compiler kann man das nicht übersetzen.
Patrick B. schrieb:
> Karl heinz Buchegger schrieb:>> Ist es möglich, dass du immer noch nicht begriffen hast, dass man>> Fehlerursachen nur in den seltensten Fällen richtig erraten kann.> Dem stimme ich dir zu, nur bin ich ratlos, da das identische programm> auf mehreren Rechnern mit unterschiedlichen OS und Benutzeraccounts> funktioniert hat, und dann plötzlich nicht mehr.
Vergiss das gleich wieder.
Interessiert nicht wirklich.
Es gibt einen Rechner auf dem es nicht funktioniert und dem muss man
nachgehen. Irgendetwas im Programm stimmt nicht und bei einigen (vielen)
fällt das nicht auf.
Suche die Schuld erst mal nicht bei den unterschiedlichen OS Versionen
oder Accounts, das ist praktisch immer eine Sackgasse (*), sondern suche
die Schuld in deinem Programm und wie es auf diese Unterschiede nicht
richtig reagiert.
(*) vor allen Dingen deshalb, weil du ohnehin nichts dagegen tun kannst.
Dein Programm muss sich an das OS anpassen, nicht umgekehrt.
> generiert so allerdings immer noch nicht die richtigen Strings...
wie müsste diese den aussehen?? Es war die Rede von den beiden \\, wenn
ich mich nicht täusche
Rufus t. Firefly schrieb:
> Mit einem Borland-Compiler kann man das nicht übersetzen.
Das sagte ich auch nie, ich sagte lediglich, dass Borland installiert
ist, aber das Programm mit Visual C++ erstellt und damit auch eine
Releasdatei erstellt wurde.
Ich werde mich über die Ferien wohl noch ein wenig mit dem Problem
beschäftigen, vielleicht finde ich den Fehler...
ein Ansatz ist das Problem, das Arc Net beschreibt.
Danke für die Beiträge...
MFG
Patrick
Patrick B. schrieb:
> Arc Net schrieb:>> Die Zeile>>
1
>>cName[7]='1'+Nr;
2
>>
>> generiert so allerdings immer noch nicht die richtigen Strings...>> wie müsste diese den aussehen?? Es war die Rede von den beiden \\, wenn> ich mich nicht täusche
Na, indem man sich zb mit sprintf den String aus den konstanten Teilen
und der Zahl zusammensetzt.
Bestimmt hast du auch eine String-Klasse zur Verfügung, mit der man da
arbeiten kann.
Alles ist gut, ausser von einem fixen Format auszugehen und ein
einzelnes Zeichen direkt im ASCII Code da reinzupfriemeln.
Ich habs noch nicht gerallt:
hast du die auf einem Rechner erstellete .exe-Datei auf einem Anderen
ausgeführt und dann gings nicht?
Oder hast du das Quell-Code-Projekt auf jedem Rechner in der
Entwicklungsumgebung geöffnet und von dort aus probiert es zu starten?
Ich denke, er ist in das klassische Problem aller Windows Entwickler
geraten. Auf einem Rechner ein EXE gebaut um festzustellen, dass es auf
einem anderen nicht richtig läuft.
Kennt jeder der Windows-Software verkauft. Bei 100 Kunden hast du immer
ein paar dabei, bei denen es einfach nicht so will, wie vorgesehen. Ist
der Kunde gutmütig, kann man das eventuell aussortieren. Ist er nicht
gutmütig, dann hat es keinen Sinn: Geld zurück und hoffen, dass ein
anderer Kunde das gleiche Problem hat, mitspielt und bereit ist ein paar
mit MessageBoxen gespickte Programmversionen durchzutesten.
ok, hab den Fehler gefunden:
Es ist genau das, was Arc Net beschrieben hat: die ComPorts ab 9 lassen
sich nicht öffnen...
(hab mal die Ports manuell geändert und siehe da, es läuft nicht... das
label sagt auch, dass sie nicht zu öffnen sind)
sorry, aber ich kappiers einfach nicht. hab gerade nen riesen
blackout...
1
TCHARcName[]=Z("\\\\.\\COM1");
2
cName[7]='1'+Nr;
der String sieht doch so aus: \\\\.\\COM1 oder?? an der 8ten Stelle ist
aber nicht die Zahl sondern das C oder werden die 3 ersten \ ignoriert??
ausserdem wie handhabe ich jetzt das ganze mit createfile, da bei COMs
über 9 irgendwie nicht gleich zu öffnen sind?
das einzige was ich im moment sehe ist, dass es irgenwie so gehen
sollte:
Patrick B. schrieb:
> sorry, aber ich kappiers einfach nicht. hab gerade nen riesen> blackout...>>
1
>TCHARcName[]=Z("\\\\.\\COM1");
2
>cName[7]='1'+Nr;
3
>
>> der String sieht doch so aus: \\\\.\\COM1 oder?? an der 8ten Stelle ist> aber nicht die Zahl sondern das C oder werden die 3 ersten \ ignoriert??
[/c]
Der String steht im Speicher als '\\.\COM1' und das C steht an der 5.
Stelle.
Ich frage mich, aus welchen hirnverbrannten Gründen man sich bei Windows
und anderen unbedingt für den Rückstrich als Pfadtrenner entscheiden
musste.
Patrick B. schrieb:
> sorry, aber ich kappiers einfach nicht. hab gerade nen riesen> blackout...>>
1
>TCHARcName[]=Z("\\\\.\\COM1");
2
>cName[7]='1'+Nr;
3
>
>> der String sieht doch so aus: \\\\.\\COM1 oder?? an der 8ten Stelle ist> aber nicht die Zahl sondern das C oder werden die 3 ersten \ ignoriert??
\ ist in einem C-String ein Escape-Zeichen (\n, \t, \" oder eben \\ für
einen \ der im String auftauchen soll)
> ausserdem wie handhabe ich jetzt das ganze mit createfile, da bei COMs> über 9 irgendwie nicht gleich zu öffnen sind?
\\.\COM12345 geht immer
> das einzige was ich im moment sehe ist, dass es irgenwie so gehen> sollte:>
> aber dann hab ich das Problem dass cName kein LPCWSTR ist.
char cName[40];
sprintf(cName, "\\\\.\\COM%d", Nr)
bzw. sprintf(cName, "\\\\.\\COM%u", Nr) wenn Nr unsigned ist
http://msdn.microsoft.com/en-us/library/56e442dc(VS.100).aspx
Sven P. schrieb:
> Ich frage mich, aus welchen hirnverbrannten Gründen man sich bei Windows> und anderen unbedingt für den Rückstrich als Pfadtrenner entscheiden> musste.
Warum nutzt man auf anderen Systemen ein Trennzeichen, das durchaus
sinnvoller Bestandteil eines Names sein kann?
Wobei auch das bei Windows nicht geht, da es dort die Trennung von / und
\ eigentlich noch nie gab (ausser bei UNC-Pfaden)...
http://blogs.msdn.com/larryosterman/archive/2005/06/24/432386.aspx
Und aus
http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#paths
"Note File I/O functions in the Windows API convert "/" to "\" as part
of converting the name to an NT-style name, except when using the "\\?\"
prefix as detailed in the following sections."
Arc Net schrieb:
> char cName[40];> sprintf(cName, "\\\\.\\COM%d", Nr)> bzw. sprintf(cName, "\\\\.\\COM%u", Nr) wenn Nr unsigned ist
Nach einer Warnung habe ich sprintf_s verwendet, aber wie schon vorher
erwähnt, hab ich jetzt das Problem, dass ich den char nicht in LPCWSTR
convertieren kann.
Arc Net schrieb:
> Warum nutzt man auf anderen Systemen ein Trennzeichen, das durchaus> sinnvoller Bestandteil eines Names sein kann?
So wie man |\?*<":>+[]/ bis Win95 verboten hat?
sprintf_s kannste dir schenken, der Sicherheitsgewinn tendiert dabei
gegen Null.
Für das WSTR-Gedöhns vermutlich sowas: MultiByteToWideChar
Einfacher gehts, wenn du vor die Stringkonstante ein L setzt und dann
mit dem breitzeichenverträglichen sprintf arbeitest.
Sven P. schrieb:
> Arc Net schrieb:>> Warum nutzt man auf anderen Systemen ein Trennzeichen, das durchaus>> sinnvoller Bestandteil eines Names sein kann?> So wie man |\?*<":>+[]/ bis Win95 verboten hat?>> sprintf_s kannste dir schenken, der Sicherheitsgewinn tendiert dabei> gegen Null.
sprintf_s ist eigentlich ganz sinnvoll, da die max. Anzahl der Zeichen
übergeben werden muss und zum anderen garantiert wird, dass der
generierte String null-terminiert ist.
>> Für das WSTR-Gedöhns vermutlich sowas: MultiByteToWideChar> Einfacher gehts, wenn du vor die Stringkonstante ein L setzt und dann> mit dem breitzeichenverträglichen sprintf arbeitest.
oder CreateFileA statt CreateFile
Arc Net schrieb:
> Sven P. schrieb:>> sprintf_s kannste dir schenken, der Sicherheitsgewinn tendiert dabei>> gegen Null.>> sprintf_s ist eigentlich ganz sinnvoll, da die max. Anzahl der Zeichen> übergeben werden muss und zum anderen garantiert wird, dass der> generierte String null-terminiert ist.
[ ] ich kenne snprintf
Ist sogar ISO-C.
ok, hab jetzt ein wenig herumgespielt und das Resultat ist zwar, dass
der Compiler keine Fehlermeldung mehr bringt, wegen
Convertierungsproblemen, aber jetzt lässt sich kein Comport mehr öffnen,
weder die über 9 noch 1 bis 9.
neu sehen die erstel Zeilen der ComOpen-Funktion so aus:
oh, mist, da hab ich ja vergessen die max Bytes zu übergeben und das
andere Problem wäre eigentlich auch logisch.
nur wiso hat der Compiler nicht gemeckert??
ausserdem hab ich vergessen, dass die Zählvariable von 0 anfängt und als
ComPort übergeben wird.
so siehts momentan bei mir aus. Hat jemand noch Verbesserungsvorschläge?
und nochmals danke für die gute Unterstützung, selbst bei einem so
schönen verschneiten Wochenende (und schön kalt -12° bei mir in der
Schweiz)
MFG
Patrick
Sven P. schrieb:
> Arc Net schrieb:>> Sven P. schrieb:>>> sprintf_s kannste dir schenken, der Sicherheitsgewinn tendiert dabei>>> gegen Null.>>>> sprintf_s ist eigentlich ganz sinnvoll, da die max. Anzahl der Zeichen>> übergeben werden muss und zum anderen garantiert wird, dass der>> generierte String null-terminiert ist.> [ ] ich kenne snprintf>> Ist sogar ISO-C.
ich dachte ihr wollt c++ schreiben?
was soll da der ganze scheiß, von wegen char* sprintf sprintf_s
snprintf?
Vlad Tepesch schrieb:
> ich dachte ihr wollt c++ schreiben?> was soll da der ganze scheiß, von wegen char* sprintf sprintf_s> snprintf?
was sind das denn für dich für Befehle?? also printf gibst ja sogar bei
c als standart Output-String-Funktion.
Für C++ sind die 'Befehle' dann eher cout und cin. Is nur blöd, dass man
damit ziemlich schnell wieder an der Wand steht und auf die blöden
'C-Befehle' zurückgreifen muss, da die aktuelle Standardbibliothek von
C++ recht akademisch ist :-}
> Is nur blöd, dass man damit ziemlich schnell wieder an der Wand steht> und auf die blöden 'C-Befehle' zurückgreifen muss, da die aktuelle> Standardbibliothek von C++ recht akademisch ist :-}
Naja, für die Teile, die ich in C++ als "akademisch" bezeichnen würde,
gibt es in C gar nichts.