Heute habe ich auch einmal eine Frage:

Im letzten Jahr habe ich für das Projekt eines Diplomanden (ein Niederschlagssammler) nach seinen Vorgaben die elektronische Steuerung mitentwickelt. Wir haben dazu einen ATmega8 verwendet, den ich in BASCOM programmiert habe. Das Gerät steht im Betrieb ja dann irgendwo allein, verlassen und verschlossen in der Prärie und "wie's drinnen aussieht, geht niemand was an". Zumindest für das Ausprobieren des Programms hätte ich aber schon gern eine Anzeige gehabt, die mir zeigt, wo im Programm wir gerade sind und wo evtl. die Säge klemmt, weshalb wir die Steuerung mit einem LCD 2*16 ausgestattet haben.
Die Anschlüsse des ATmega8 waren ein bißchen knapp, weswegen wir die für die ISP-Schnittstelle verwendeten Anschlüsse als normale Ein- bzw. Ausgänge benutzt haben, was auch kein Problem darstellt. Zunächst hatte ich die Steuerung mit einem über Relais angeschlossenen Motor und einigen Optokopplern auf dem Tisch liegen und alles lief prima. Auch das fertige Gerät hat dann gut funktioniert. Das muß ich hier noch einmal explizit sagen: Das Steuerprogramm hat immer tadellos funktioniert! ABER:
Ab irgendeinem (nicht reproduzierbaren) Zeitpunkt zeigte das LCD Unsinn an, unsinnige Zeichen und an den falschen Stellen. - Wie gesagt, im Betrieb ist die Anzeige nicht zu sehen und wird eigentlich nicht gebraucht, aber wenn sie schon einmal dran ist, sollte sie auch richtig funktionieren.
Ich hatte die Fehlfunktion der Anzeige auf elektrische Störungen durch die Motoren, Ventile und einen (zumindest im Einschaltmoment) stromfressenden kleinen Kompressor geschoben und hatte noch ein paar Kondensatoren "fliegend" eingebaut, Auch hatten wir den Steuer- und den Laststromkreis völlig voneinander getrennt; es waren sogar zwei verschiedene Akkus. Trotzdem blieb der Fehler.
Da das Gerät aber von der Steuerung her einwandfrei funktionierte, ist die Arbeit des Diplomanden trotzdem gut bewertet worden und er wurde sogar gebeten, noch ein zweites Gerät zu bauen.

In der Steuerung des zweiten (verbesserten) Geräts habe ich die entsprechenden Kondensatoren von vorn herein schon vorgesehen und wir haben für "sensible" Eingänge abgeschirmte Leitungen verwendet. Diesmal werkelt ein ATmega32, um keinen Anschluß der ISP-Schnittstelle als normalen Anschluß verwenden zu müssen und das LCD hat die Größe 4*20, um mehr Informationen darstellen zu können. Einige kleinere Änderungen an der Steuerung gab es auch. Jedenfalls funktioniert die Steuerung wieder problemlos, aber das Anzeigeproblem ist auch wieder da...
Wir hatten nun die Idee, die Anzeige in 4 Variablen - eine für jede Zeile - im Speicher zusammen zu basteln und bei jeder nötigen Ausgabe die Anzeige ganz zu löschen und alle Zeilen neu anzuzeigen. Das bringt aber auch nichts. Bei einem Versuch blieb dann einmal der Bildschirm sogar ganz leer... Die Steuerung funktionierte aber weiter...

Ich habe nun einmal folgendes versucht: Alle Befehle, in denen ein Motor usw. eingeschaltet werden soll, habe ich auskommentiert, nur die entsprechenden Wartezeiten blieben erhalten. AUCH DA trat das Anzeigeproblem nach einiger Zeit auf. Es hat also definitiv nichts mit elektrischen Störungen durch "Großverbraucher" zu tun.

Bei meinen Überlegungen bin ich auf eine Sache gestoßen, die in BASCOM mit $FrameSize bezeichnet wird. So wie ich das verstehe, ist es ein Speicherbereich im SRAM, der für Zwischenergebnisse, z. B. Umwandlungen von Zahlen in Strings usw. und auch Variablen benutzt wird. Könnte hier der Fehler liegen? Wenn dieser Bereich nicht ausreicht und auf falsche Positionen des Speichers zugégriffen wird und dadurch falsche Befehle und Daten an das LCD gesendet werden? Zwar habe ich schon einmal den Wert $FrameSize (vielleicht zu zaghaft?) vergrößert, aber der Anzeigefehler tritt immer noch auf. Es ist, wie gesagt, mehr ein Schönheitsfehler, sollte doch aber trotzdem funktionieren. Und es wäre ein mächtiger Schritt nach vorn, wenn wir hinter die Ursache dieses Fehlers steigen würden.

Ich verwende auch nicht zum ersten Mal ein LCD mit einem ATmega und noch nie ist ein solches Problem aufgetreten. Und hier nun bei beiden Geräten...??

Falls das noch von Belang ist: Zur Stomversorgung wird ein 12-V-Akku mit 17 Ah verwendet und die 5 V für die Steuerung erzeugt ein kleines Schaltnetzteil von Herrn C... (Nr. 191136). (Es wird jetzt nur EIN Akku verwendet, aber elektrische Störungen, die auf die Anzeige durchschlagen, wurden ja schon ausgeschlossen.)

Hat vielleicht einer der µC-Gurus einen Tip für mich? Das wäre ganz super! Falls noch Informationen fehlen - so geheim ist das Projekt sicher nicht, daß ich nicht noch etwas davon preisgeben könnte.
Danke schon mal für das Lesen des langen Textes bis hierher!

Dann schreib dir doch mal ein kleines Programm was nur die LCD Ansteuerung beinhaltet und guck nach ob das Display dann richtig arbeitet. Dann stellst du vielleicht fest das der Bastelkasten der sich BASCOM nennt nicht wirklich sinnvoll ist wenns um Fehlersuche geht und das man besser eigene Routinen in Assembler fürs Display nutzt. Und wenn man schon so weit gekommen ist schreibt man gleich auch den Rest in Assembler, dann hat man reproduzierbare Ergebnisse und schneller isses auch noch.

_________________
Tschüüüüüüüs

Her Masters Voice
aka
Frank

***********************************
Der optimale Arbeitspunkt stellt sich bei minimaler Rauchentwicklung ein...
***********************************

Wie wird das Display betrieben (4-bit - Daten + 2 Steuerleitungen)?
BASCOM hat fest eingebaute Wartezeiten (wie auch immer realisiert) und hat evtl. Probleme bei Displays, die sich nicht genau an die Zeiten halten - BASCOM überprüft afaik nicht das Status Bit (busy) des LCD Controllers. Der bessere Weg ist der Weg über Abfrage des Status - Bit des LCD - und dann muss eine zusätzliche Steuerleitung (R/W) und min. 1 Datenleitung zum einlesen des Zusatndsbits des LCD zur Verfügung stehen. Dummerweise wird dann die Programmierung unter BASCOM wahrscheinlich übermässig aufwändig bis unmöglich - HMV hat den richtigen Weg schon angedeutet ... ASM oder C!

Edit: Dreckfuhler

[ Diese Nachricht wurde geändert von: hajos118 am 25 Jun 2007  9:32 ]

Hallo PhyMa-Lehrer,

Ich möchte nicht an Bascom rummeckern sondern würde vorschlagen, in Basic eine Routine selbst zu schreiben, die das LCD anspricht, inklusive dem Busyflag.

Ich hatte da mal eine, habe sie allerdings gelöscht, da ich keine Verwendung mehr dafür fand (ich schreibe mittlerweile nur in C, manchmal C++ und viel ASM).

Da ich mittlerweile in Bascom-Basic kaum noch drin bin, ist mein Kode wohl etwas eingerostet, aber so ungefähr könnte das aussehen:

sub lcd_schreibe_daten(daten as string)
dim i as byte 'max. länge des strings: 255 Zeichen; integer wäre länger

for i = 1 to len(daten)
lcd__schreibe_byte mid(daten, i, 1) 'Zeichen von Position i mit Länge 1 senden
Next i

end sub

lcd__schreibe_byte(datei as string)
'E setzen:
PORTA = PORTA or const_E or const_datenmodus 'const E hat nur ein Bit an antsprechender Stelle gesetzt, in C oder ASM wäre es 1<<pos_E (pos_E ist definiert mit der entsprechenden Bitposition, z.b. 4) Außerdem wird Datenmodus angestellt, das entsprechende Bit auf 1 gesetzt
'Nibble 1 schreiben
'E löschen
'Daten verschieben
'E setzen
'Nibble 2 schreiben
'E wieder löschen

lcd__waitbusyflag 'busyflag abfragen und erst weitermachen, wenn es 0 wird
end sub

sub lcd_waitbusyflag()
dim temp as byte
'Datenrichtung auf Eingang
do
temp=PINA
loop until temp and const_busyflag=0

'Datenrichtung auf ausgang
end sub


---

Boahar, ich hoffe, das hat überhaupt was gebracht...

_________________

Vielen Dank für die Antworten bis hierher! Ich werde sehen, was sich tun läßt...

Ich habe als Einfachstes zunächst den Tip ausprobiert, nur etwas auf's Display ausgeben zu lassen.
Jedenfalls gibt das Display seit ein paar Stunden mit einer gewissen Gelassenheit immer von vorn seinen Zeichensatz und den Wert der Variablen aus, die die Zehntelsekunden zählt. (Ich hatte nämlich auch irgendwie den Timerinterrupt in Verdacht, daß der sich zur Unzeit in die LCD-Ausgabe einmischt.)

Und läuft und läuft und läuft...

Da ich auch nur ASM schreibe, bin ich in Bascom auch nicht so fit.
In Bascom gibt es paar Sachen auf die geachtet werden sollte:
*Beachte das 32Byte HW-Stack-Minimum für ISR.
*Vermeide LOCAL Variable
*Vermeide SUB / FUNCTION mit Parameterübergabe
*Vermeide Bit-Variable
*Vermeide a>b, verwende a>=c oder b*Vermeide Double/Single/Long etc. und dazugehörige Matheoperationen (am besten nur Byte und Word)
*FrameSize sollte doppelt so groß wie die benutzten Variablen sein (Dim a,b,c as word = 12 Byte -> FrameSize=24 Byte)

_________________
mfg Jornbyte

Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.