RS232-Kommunikation mit falschem Timeing

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

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... %)

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