Bytevergleich fehlerhaft

[fredred]

Hallo demmy,

Der Hinweis von Willy ist OK aber wenn es nur Probleme mit Crs sind, können wir dies ausschließen.
Mit Bascom(keile Sache) sollte doch schon einiges beachtet werden. Nur weil im Name BAS erscheint, hat dies nichts mit dem alten Dos- Basic gemein. Der BASCOM- Compiler ist schon sehr nah an Hardware für Controller dran.
Nach Meinen bescheidenen Erfahrungen, sind es häufig nur Fehler der Variablen Einstellungen. Noch schlimmer ist, wenn eine IF- oder Caseabfrage ins Leere läuft.
Nun habe ich mich die Zeit genommen deinen Code nachzuvollziehen. Ist nicht so einfach da sehr viele Schleifen verschachtelt sind.
Frage: hast du in deiner Bascom Umgebung [Line number und Draw Indention Lines] aktiviert. Somit ist ein Abgleich besser möglich.
Infoaustausch sollt dann besser mit PN erfolgen. Endergebnis dann im Forum.
Wir wollen Forum ja nicht „vermüllen“.
Vorab Hinweis: (Incr Aktuelle_karte) in Zeile 244 kann ich nachvollziehen, müsste dies nicht erst vor End If stehen.
Leider habe ich zur Zeit nicht die Möglichkeit dein Programm hardwaremäßig zu testen.

Mit freundlichen Grüßen
fredred

PS. den letzten Kommentar gelesen.
Somit nehme ich an eine Abfrage/Entscheidung verursacht Fehler.
Ist ja nach wie vor immer das gleiche Problem, man kann sehr viel im Programmablauf abfragen, aber hängt das „Ding“ in einer Schleife fest, kommt keine Fehlermeldung(macht ja alles so wie Programmiert) Somit alles im Terminal anzeigen lassen und an den kritischen Punkten ein Stop einfügen.
Schaust du mal im Bascom Code für 2 UART abfragen, wirst du erkennen, nur wenn der erste den Status „ich bin fertig“ meldet wird UART zwei freigegeben.

[demmy]

Guten Morgen zusammen,

ich möchte euch die Lösung des Problems nicht vorenthalten.

An dieser Stelle möchte ich auch nochmal recht herzlich bei allen und speziell bei Fredred bedanken, der mit sehr bei der Findung des Problems geholfen hat.

Also die Lösung des Problems war es, einen Quarz unter 16MHz zu verwenden. Bei verwendung eines Quarzes über 16MHz kommt es scheinbar zu Timingproblemen. Im zusammenhang mit zu langen Flanken aufgrund von 5V-betrieb anstelle von 3,3V.

Aber vielleicht kann Fredred noch ein paar Worte dazu sagen? Er kann das viel besser erklären als ich.

Viele Grüße

[fredred]

Hallo demmy,

wir bedanken uns auch für die Rückmeldung. Machen einige nicht wen Problem gelöst ist.
Profitieren ja auch von praktischen Erfahrungen.

Aber vielleicht kann Fredred noch ein paar Worte dazu sagen? Er kann das viel besser erklären als ich.

Na hier würde ich sagen Nein.

Aber eine kleine Erklärung versuche ich mal.
In der Digitaltechnik war viele Jahre die Betriebsspannung 5Volt der Standart. Die Zeit von L nach H oder umgedreht, reichten völlig aus bis zu 16MHz Systemtakte(Physikalisch bedingt) Nun haben wir aber nicht mehr so viel Zeit, wollen ja immer schneller werden. Die Zeit von 0 bis 5 Volt zu erreichen ist viel zu lang.
Nun kommt die neue Technologie 3,3 Volt als Betriebsspannung.
Die Flanken werden kürzer somit alles viel schneller. Bin mich sicher eine neue Technologie kommt, aber bei 1,7 Volt ist Schluss.
Oder wir verlassen die Erde. Es sei denn, es werden nicht mehr Siliziumtransistoren verwendet, sondern Lichtspeicher für diese Aufgaben erfunden (siehe Albert Einstein). Hat ja Anregung veröffentlicht.

Bestimmt kommt nun bald der Hinweis: Digital ist nur 0 oder 1 und Schuss... du Spinner.

Kann ich wiedererlegen. Der Maschinenzyklus(Takt) für MCU hat für Register lesen und schreiben, immer ein Zeitverhalten. Ein 100% es Digital = Zeit ist vernachlässigbar, werden wir wohl nicht mehr erleben.

Schlusswort:
Warum soll der MCU mit Maximemalen Takt tasten, wenn nicht nötig, Abgesehen vom Stromverbrauch.
Meine persönliche Meinung ist, ein optimaler Systemtakt ist das A & O für sichern Betrieb.
Wo ist der Sinn? Drücke Taste einmal pro Minute, Ergebnis an LED anzeigen, abfrage aber alle µs.
Ist schlimm für mich, wenn ich sehe, wie „schlampig“ ein MCU vergewaltigt wird.
Motto einiger, ich habe ja ein schnellen und großen Mega im Einsatz Muss ja viel besser sein .

Gruß
fredred

[Peter(TOO)]

Hallo fredred,

Aber eine kleine Erklärung versuche ich mal.
In der Digitaltechnik war viele Jahre die Betriebsspannung 5Volt der Standart. Die Zeit von L nach H oder umgedreht, reichten völlig aus bis zu 16MHz Systemtakte(Physikalisch bedingt) Nun haben wir aber nicht mehr so viel Zeit, wollen ja immer schneller werden. Die Zeit von 0 bis 5 Volt zu erreichen ist viel zu lang.

Das Problem nennt sich Flankensteilheit, also dU/dt, also wie schnell die Spannung ansteigt, bzw. abfällt.
Eine hohe Flankensteilheit ist zwar machbar, erzeugt dann aber hohe Stromimpulse in der Versorgungsspannung und macht mehr Probleme bei der Störstrahlung (EMV). Steilere Flanken erzeugen höhere Frequenzen (Oberwellen) und eine grösserer Spannungshub gibt diesen auch noch mehr Sendeenergie mit.

Nun kommt die neue Technologie 3,3 Volt als Betriebsspannung.
Die Flanken werden kürzer somit alles viel schneller. Bin mich sicher eine neue Technologie kommt, aber bei 1,7 Volt ist Schluss.

Nö, aktuelle PC-CPUs arbeiten heute schon mit Kernspannungen um 1V, meine RAMs im PC mit 1.4V.

Sinnvoll ist eine Norm mit um die 1V, dann reicht eine einzelne 1.2V NiMh-Zelle zum Betrieb. Die jetzigen Spannungen um 3V sind ideal für direkten Betrieb an eine Lithium-Zelle.

Der Maschinenzyklus(Takt) für MCU hat für Register lesen und schreiben, immer ein Zeitverhalten. Ein 100% es Digital = Zeit ist vernachlässigbar, werden wir wohl nicht mehr erleben.

Habe ich auch vor 40 Jahren nicht erlebt!
Ein typisches Problem war schon immer das Prellen eines Schalters in der Digitaltechnik.
Aber auch manche Schaltungen, welche das Laufzeitverhalten nicht berücksichtigt haben, erzeugen Spikes, also ungültige kurzzeitige Schaltzustände. Bei rein kombinatorischer Logik, konnte man das meist hinnehmen, bei sequenzieller Logik schalten da aber die Flip-Flops schon
Da war das typische Problem ein asynchroner Zahler, welcher nicht binär zählen soll.

Probleme mit dem Oszillator hatte ich vor 20 Jahren mal mit dem NS16450/550 (UART).
NS machte da einen Die-Shrink, d.h. der Chip wird einfach optisch verkleinert, weil man eine neue Technologie mit kleineren Strukturen beherrscht. Da passen dann mehr Chips gleichzeitig auf einen Wafer, was natürlich die Herstellung vergünstigt. Bei CMOS werden dann aber auch die Transistoren schneller, da, unter anderem, auch die Gatekapazitäten kleiner werden.

Mein Effekt war, dass dann der Quarz-Oszillator manchmal auf eine Oberwelle schwang, was natürlich eine andere Baudrate ergab.
Toll war, dass die Kapazität des Oszilloskops gereicht hat, die Flankensteilheit zu verringern, sodass der Effekt beim Messen nicht auftrat

Das Gemeine an der Geschichte war, dass schon um die 200 Geräte mit Chips vor dem Die-Shrink fabriziert wurden und problemlos funktionierten.

Naja, das gute daran war, dass ich so direkten Kontakt ins Entwicklungslabor von NS bekam und ein paar gute Fachgespräche möglich waren. Musste dann halt mit angeklebten 10pF am Ausgang des Oszillators raus gehen.
So nach einem dreiviertel Jahr bekam ich dann noch einen Anruf von NS, dass ab jetzt das Problem behoben sei.

MfG Peter(TOO)

[fredred]

Hallo Peter(TOO)

Danke für deinen Kommentar und wieder was dazu gelernt.
Ich bin kein Fachmann auf diesem Gebiet, wollte nur drauf Hinweisen, dass eine Übertaktung das Problem von demmy war.
Ich konnte nach einigen Abgleichs der Software auch kein Fehler finden.
Somit hatte ich nur noch die Idee, er soll mal den internen Oszillator(8MHz) für Softwaretest nutzen
(sein externer Takt mit 5 Volt Betriebsspannung war ja schon extrem).
Hat er gemacht und siehe da, kein Problem mehr.Einen 14,7456MHz externen Quarz eingebaut immer noch alles OK
Kein Softwarefehler.
Wie du es bestätigst das Laufzeitverhalten, nicht nur des MCU, sonder das gesamte Projekt sollt immer betrachtet werden.

Nö, aktuelle PC-CPUs arbeiten heute schon mit Kernspannungen um 1V, meine RAMs im PC mit 1.4V.

Die Bemerkung 1,7 Volt bezog sich auf die AT Mega IC’s.

Mit freundlichen Grüßen
fredred