Forum: PC-Programmierung RS232-Kommunikation mit falschem Timeing


von Michael R. (Gast)


Angehängte Dateien:

Lesenswert?

Moinsen...

Ich hab hier einen Porsche Cayenne S (leider nur als Model) und hab das
etwas beleuchtet... und um vernünftig schalten zu können bzw. damit er
auch selbst schalten kann läuft das ganze über nen µC (ATMega16)... Is
halt mein kleines ich lerne was neues Projekt... ;)

Nun hab ich den µC programmiert, LEDs und alles eingebaut und lässt
sich auch klasse über das HyperTerminal steuern... nur natürlich is das
net sonderlich schön... Daher hab ich mich mal mit C++ und dem Borland
C++ Builder befasst und probiert damit ein Programm zu schreiben... es
sieht auch ganz toll aus... nur leider schaltet es nicht richtig!

Connection klappt so weit (verbindung kappen geht leider nicht)...
Klickt man nun aber auf Abblendlicht so, geht dies zwar im normalfall
an, aber es gehen auch teilweise noch andere Sachen mit an und dabei
gibt es leider keine Regelmässigkeit und damit fängt es leider auch nur
an, den das Licht bekommt man dann auch nicht mehr aus...

die Einstellungen zur Kommunikation (baud, stopbit usw...) müssten auch
alle passen und runtersetzen der baud-rate bringt leider auch nix... das
Kabel ist auch nicht zu lang (ca. 20cm von der Controllerkarte zum
Porsche)...

Ich habs auch schon mit ner DLL probiert, die hier schonmal
"angepriesen" wurde
(http://www.mikrocontroller.net/forum/read-8-105583.html#106003) - nur
damit ist das gleiche problem...

Schon jetzt wieder Danke für eure Hilfe!

bye, Micha!

von Andreas (Gast)


Lesenswert?

Hallo,

ich habe mir mal Deine Programme auf die Schnelle angesehen.

Habe das ganze so verstanden, daß es mit Hyperterminal geht aber mit
dem C++-Builder-Programm nicht.

in der senden()-routine sendest Du immer abblendlicht ein/aus und alles
andere. Auch wenn sich der Zustand nicht geändert hat. Das Problem
scheint mir zu sein, daß der üC das so schnell nicht verarbeiten kann
wie Du es sendest.

Setz mal zum testen einen Breakpoint auf die Senden-Routine und Trace
die mal.
Wenn es dann funktioniert, bin ich mir ziemlich sicher, daß der PC zu
schnell sendet.
Helfen würde dann, wenn Du nach jedem Senden eine Antwort vom uC
bekommst. Also entweder nur ein Zeichen (z.B. ACK dezimal 6) oder er
schickt dir einen String "ok" zurück.
Wenn Du innerhalb einer Timeoutzeit nichts erhälst, hat der Porsche es
nicht erhalten.
Erst nach der Quittung, darf der nächste Befehl (Hupe ein/aus oder
welche es sonst waren) gesendet werden.

Bin mir eigentlich ziemlich sicher, daß es daran liegt.

Grüße
Andreas

von Michael R. (Gast)


Angehängte Dateien:

Lesenswert?

Ja, ist richtig... mit HyperTerminal gehts und mit meiner geschriebenen
Software nicht...

Habe jetzt in die µC-Software das so reingebaut, das nach dem empfangen
von beiden benötigten Dingen (code für das zu ändernde Teil + Status)
jeweils ein "ok" gesendet wird... in die sende routine hab ich noch
ein wait4answer eingebaut, welches prüft, ob eine antwort kommt und
gegebenenfalls ein nochmal senden veranlasst...

Es sieht so auch klasse aus und würde auch sinn machen, wenn es daran
liegen würde - nur helfen tut es nicht!!! Der µC schaltet immernoch,
wie er grade lustig ist - was ich net lustig finde...

Was etwas komisch is, ich habe jetzt im mom im C++-Code noch ein paar
befehle drin, die mir ausgeben, was gesendet wurde und ob es angekommen
ist... Die Werte für den Status hab ich auch geändert (n=no - also aus
und y=yes - also an) und diese ausgaben listen sich komischer weise so
auf:

a --> TRUE
y --> FALSE
y --> TRUE
c --> FALSE
c --> TRUE
n --> FALSE
n --> TRUE
b --> FALSE
b --> TRUE
n --> FALSE
n --> TRUE
...

und so geht es immer weiter... außer dem ersten befehl wird keiner beim
ersten mal senden empfangen... um mal ein bisschen zu testen, hab ich
grade schonmal ein Nullmodemkabel von Com5 auf Com6 gelegt und
HyperTerminal auf Com6 laufen lassen und das PorscheProg auf Com5...
Ergebniss war eine spitzen kommunikation ohne irgendwelche fehler...
und ich muss ganz ehrlich sagen, ideen hab ich im mom absolut keine
mehr... %)

von AxelR. (Gast)


Lesenswert?

Hi,

setz mal den Prescaler vom Timer hoch. Der wird dir dazwischen funken.
Du kannst auch ganz auf den Timer verzichten, indem Du - nur als
Voraschlag - die beiden ASCCI Zeichen z.B. "ay" für Lichtan nicht als
ASCCI Zeichen empfängst, sondern dir eine WORDVariable machst un diese
mit einem Waitkey einliest. Wäre dann 0x6179 für"ay". Jetzt schickts
du beim 2ten Waitkey ein /n (0x0D)hinterher. und erst wenn 0x0D von der
Schnittstelle empfangen wurde, läufts Du einmal deine Hauptschleife
durch und klapperst die Bedingungen ab. Danach gehtst Du wieder an den
Angfang und wartest auf deine Zeichen.

Ich habe auffa arbeit sowas Durch: eine simple Relaisbox mit acht
Ausgängen und als Kommando ein "::OS11" für ersten Ausgang
einschalten, "::OS10" für ersten Ausgang ausschalten usw.
"::OSX"(wert), um die Ausgänge gemäß Ihres Bitmusters in (wert) zu
schalten.
Hat auch super funktioniert bis mein Chef ::OS30::OS11::OS81::OS41
gesendet hat. Da ging dann garnichts mehr.
Hier gehen die Zeichen auch als ASCCI Zeichen ein und ich musste mir
einen Zeichenpuffer sowie einen Kommandozähler zulegen. Daher kann ich
gut nachvollziehen, was hier für KLimmzüge zu machen sind. Waren auch
nur 9K6 8N1. Bietet BASCOM (es scheint sich ja um BASCOM zu handeln)
einen gepufferten, oder wenigstens einen Interruptgesteuerten Betrieb
der UART an? Dann verwende diesen. Ich programmiere in FastAVR, daher
kenne ich mich mit BASCOM nicht soo gut aus.

Viele Grüße
Axel

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.