  INFO - FAQ - CC2-Forum - CCPro-Forum |
|
||
|
Hallo zusammen! Um die gesamte Tragweite des in der "neuen" C-Control und Conrad-Micro enthaltenen Fehlers zu verstehen, ist es sinnvoll, sich mit dem internen Aufbau der Portstruktur des 68HC08-Kontrollers auseinanderzusetzen. Die Portstruktur vom 68HC08 ist genauso wie die des 68HC05 aufgebaut und im folgenden Bild dargestellt.  Die Ports, genauer die I/O-Ports, kennen nur drei Zustände: Entweder sind sie auf Eingang geschaltet, wodurch sie hochohmig sind und eine am Port angeschlossene Signalquelle so gut wie nicht belasten. Oder sie sind auf Ausgang geschaltet, wodurch der Kontroller den Port aktiv, also niederohmig, entweder auf 0 Volt oder auf 5 Volt legt. Das sogenannte "Data Direction Register" (DDR) legt fest, ob der Port auf Eingangs- oder Ausgangsbetrieb geschaltet ist. Und das "Data Register" (DATA) legt bei Ausgangsbetrieb fest, welchen Zustand der Port annehmen soll. Wie im Bild ersichtlich, ist DATA mit einem Latch, also einem Zwischenspeicher, ausgestattet. Der Fehler in der C-Control V1.2 und V2.0 und Conrad-Micro erklärt sich dadurch, daß das Betriebssystem den Port auf Ausgang schaltet, bevor das Latch auf den gewünschten Portzustand gesetzt wurde. Der Port nimmt deshalb aus Sicht des Anwenders für kurze Zeit einen zufälligen Zustand an, bis DATA gesetzt wird. Je nach den Rahmenbedingungen kommt es zu einem Störimpuls, auch "Glitch" genannt.  Es ist bekannt, daß diese Störungen auftreten können, wenn die Register in der falschen Reihenfolge beschrieben werden. Sogar im vom Kontrollerhersteller herausgegebenen Manual wird bei der Beschreibung jedes Portregisters auf die Gefahr von Glitches hingewiesen. Die oben stehende "NOTE" stammt aus dem Manual zum GT16-Kontroller. Diese Hinweise wurden bei der Erstellung des Betriebssystems der "neuen" C-Control-Versionen offensichtlich ignoriert. Obwohl ich den Entwickler des Betriebssystems bereits im August 2005, also vor über einem Jahr, auf den Fehler aufmerksam machte, ist bisher kein Betriebssystemupdate zur Behebung dieses und anderer Fehler erschienen! > Noch eine Frage: Gibt es irgendeine Möglichkeit (Workaround) mit dem dieser Fehler umgangen werden kann? Der Fehler tritt grundsätzlich immer auf, wenn ein Port vom Eingangsbetrieb in den Ausgangsbetrieb umgeschaltet wird. Da die Portlatches nach einem Reset undefiniert sind, tritt der Bug somit zumindestens bei jeder Erstinitialisierung eines Ports auf. Ob er aber so gut zu erkennen ist, wie im Oszilloskopbild dargestellt, hängt von den jeweiligen Pegeln ab. Mal angenommen, ein Port ist auf Eingang geschaltet und wird mittels Pullup-Widerstand auf 5 Volt gelegt. Wenn anschließend der Port vom Kontroller mittels PORT=OFF auf 0 Volt geschaltet wird, ist mit dem Oszilloskop zwar normalerweise kein Glitch zu erkennen, er ist aber trotzdem vorhanden. Wenn das Portlatch auf 0 stand, wird der Port verfrüht auf 0 Volt geschalten, was aber genaugenommen kein Problem ist. Wenn das Portlatch jedoch 1 war, wird der Port nicht nur vom Pullup-Widerstand, sondern zusätzlich vom Kontroller niederohmig auf 5 Volt gelegt, wodurch bei entsprechender Beschaltung ein Kurzschluß an den Ports auftreten kann. Der Fehler ist besonders heimtückisch, weil der Störimpuls nur unter bestimmten Voraussetzungen auftritt. Es könnte sogar sein, daß der Fehler in Abhängigkeit der Leitungslänge auftritt. Verschleiert wird das ganze auch durch Read-Modify-Write-Befehle, die die Portlatches mit dem Portzustand laden. Ich werde diesen Fehler wahrscheinlich noch einmal auf einer Extraseite dokumentieren und in den FAQs verlinken. Die hier stehende Erklärung ist nur ein Rohentwurf. Bitte weist mich darauf hin, falls irgendetwas unklar sein sollte. Viele Grüße Dietmar Meine Homepage: http://ccintern.dharlos.de |
| Antwort schreiben |
