www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik DOG-M & ATMega88 = Verzweiflung


Autor: M a X x (maxx673)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe damit begonnen AVR´s zu programmieren und habe mir zu diesem
Zwecke mehrere verschiedene kommerzielle und freie
C-Programmierumgebungen angeschaut.Auch wenn die meisten kommerziellen
Programmierumgebungen einige nette Features haben (vorgefertigte
Includefiles oder Codewizards) habe ich so meine Schwierigkeiten als
"AVR Anfänger" mich in die "verschiedenen" C-Dialekte einzulesen
und habe mich daher fuer den WinAVR entschieden ,da man hier im Forum
und auch im Netz viele hilfreiche Includes,Tutorials und Codeschnipsel
findet.

Mein neustes Projekt mit einem DOG-M LCD Display (mit einem leicht
abgewandelten Includefile das ich hier im Forum gefunden habe, habe ich
das Display schon mit dem CodeVision zum laufen gebracht) ist bisher
leider mit dem WinAVR nicht so erfolgreich gewesen.Da es beim DOG-M
leicht abgewandelte Inits gibt im Gegensatz zu herkömmlichen
LCD-Displays habe ich mir unter zurhilfenahme von
Includefiles,Codeschnipseln und dem original Datenblatt des Controllers
vom DOG-M(ST7036)versucht ein eigenes Includefile zu schreiben(im
Anhang).Leider bekomme ich das Display nicht so richtig zum
laufen.Eventuell habt Ihr ja eine Idee wo mein Fehler im Code liegen
könnte (probier das nun schon 2 Tage das zum laufen zu bekommen)Über
hilfreiche Informationen würde ich mich freuen.

MfG M a x x

Autor: Marten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist denn schon irgendwas zu sehen auf dem Display?
evt. mal längere Pausenzeiten ausprobieren und nach der Init. mal eine
längere Zeit (ein paar ms) warten, damit das Display auf die
vorgegebene Kontrastspannung regeln kann.

Autor: M a X x (maxx673)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich werd leich mal längere pausen probieren, diese finde ich allerdings
auch nicht in den anderen includes.
zu sehen ist mit meinen "eigenbau" includes erstmal ein garnichts,
wenn ich das mit codevision compilierte programm flashe klappts jedoch
wieder auf anhieb.

ich bin ziemlich sicher, dass ich irgendwo in den eigentlichen includes
fehler eingebaut habe, die ich allerdings selbst nicht ausmachen kann -
zumindest nicht offensichtlich (die includes durchlaufen während meiner
versuche ständig änderungen/verbesserungen.
nachteilig ist sicher, dass man leider rein gar kein ergebnis sieht,
bevor die schreibroutinen zumindest halbwegs richtig sind, sonst könnte
ich immerhin stückchenweise zum ziel gelangen. daher hoffe ich, dass
jemand mit fundierterem c bzw. avr-gcc wissen irgendwelche
offensichtlichen (leichtsinns-) fehler sichtet ;)

zumindest bei der busy-abfrage kann ich einen hänger ausschliessen, da
ich nach erfolgtem init und diversen schreibversuchen mit dem oszi noch
schön datenfluss auf den steuerleitungen ausmachen kann wenn ich z.b. in
der while() schleife testweise dauerhaft daten zum display schicke.

ich hoffe auch, dass evtl. der bereits bestellte avrdragon beim
debuggen solcher schlecht nachvollziehbaren fehler hilfreich sein wird
(sofern er bald kommt).

Autor: TobyTetzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo MAXX,

ich habe irgendwo hier im Forum auch eine abgewandelte P.Fleury
Version für das DOG-M.
Läuft mit WinAVR!

Such mal, sonst mail ich es dir mal!

Gruß Toby

Autor: M a X x (maxx673)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

vermutlich ist das eine der versionen, die ich als grundlage verwendet
habe.
doch einerseits haben alle versionen gewisse nachteile (z.B. zu
spezifisch auf eines der displays zurechgeschrieben) oder sind einfach
nicht universell genug (z.B. the custom character etc.).
irgendwie habe ich gehofft, die vorteile aller verwandten versionen
ohne ihre spezifischen "nachteile" in einem include-set vereinen zu
können (und insbesondere dabei als nebeneffekt mein avr und c wissen
etwas zu festigen).

wie auch immer, ich habe vorhin einige gravierende fehler in meinen
bit-shift operationen bemerkt (beinahe peinliche leichtsinnsfehler) und
auch während diverser korrekturversuche erste lebenszeichen vom display
erhalten. leider allesamt kauderwelsch und bisher noch nicht auf
konkrete ursachen zurückführbar, aber man soll ja die hoffnung nie
aufgeben ;).
ich denke, in der aktuellen version (die duch diverse test fast schon
wieder unbrauchbar ist - "trial and error" als letzte massnahme beim
fehlersuchen ist nicht immer optimal) sind es noch 2-3 patzer beim hin
und herschieben der bits, hauptsächlich aber probleme beim timing bzw.
bei der reihenfolge der i/o operationen.

Autor: M a X x (maxx673)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

also was ein wenig kaffee, ruhe und kopf frei machen alles bewirken
kann ;)

nach einigen massiven aufräumarbeiten in dogm.c und einer "zündenden"
idee sh´cheint nun alles soweit zu laufen. persönlich kann ich etwaige
details vorerst nur mit einem 8x1 und 16x2 dog-m testen, daher wäre
eine rückmeldung, ob 16x3 displays zumindest ohne ihre sonderfunktionen
(der 2-zeilen modus) funktionieren sehr hilfreich.

wie gesagt... als jemand mit  vergleichsweise mässiger c-praxis hatte
ich meine grössten pobleme mit den bitoperationen und der richtigen
zeitlichen abfolge.

zudem scheint es nun so, dass das ausgeben eines festen strings (aus
dem flash) komplett fehlerhaft ist :( als folge bekam ich ständig das
zuvor erwähnte kauderwelsch. als mir der gedanke kam, dass da
vielleicht der wurm drin steckt stellte ich einfach fom dog_putsf() auf
dog_puts() um, kopierte den text zu laufzeit und VOILA! wir haben eine
ausgabe auf dem display un die steuerbefehle (gotoxy etc) funktionieren
auch (genaugenommen kam ich auf die idee, nachdem mir aufgefallen war
dass ich zwar nur kauderwelsch ausgeben konnte, die dog_clear() befehle
zwischendrin aber komischerweise richtig interpretiert wurden.
lediglich bei der kontrastschleife ist noch ein kleine unstimmigkeit
drin, das kommt nachher dran ;)

Wie auch immer, ich hänge mal die aktuelle version für diejenigen an,
die gerne mal auch selbst damit herumexperimentieren wollen. in den
nächsten tagen werde ich wohl auch noch die letzten funtionen einbauen
und ein paar optimierungsversuche unternehmen.
zumindest bin ich erstmal heilfroh, dass ich mein begonnenes projekt
inklusive der fertig gebauten schaltung nun auch unter meiner winavr
umgebung weiterbenutzen kann ;)

Autor: Dominik T. (dom) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich versuche momentan auch so ein LCD anzusteuern...
Bei den normalen HD44780 kompatiblen LCDs war vor der Initialisierung
immer die erste Zeile mit "schwarzen Kästchen" gefüllt. Ist das bei
den DOG-LCDs auch so? Bei mir tut sich da nämlich leider garnichts.

Dominik

Autor: M a X x (maxx673)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

soweit ich das beurteilen kann, gibts ohne saubere initialisierung
keinerlei ausgabe, auch keine kästchen.

wie auch immer, nach langem hin und her, einigen ausgebügelten (dummen
;) ) fehlern und verbesserungen läuft meine routine nun
zufriedenstellend.
zumindest mit meinem 8x1 und 16x2 dog-m kann ich im moment alle
grundfunktionen sauber nutzen (inkl. gotoxy, automatischem
zeilenumbruch, "rücksprung" in die erste zeile bei umbruch in der
letzten etc.).
ich werde auch noch ein paar weitere dinge nachträglich einbinden, aber
im moment gilt mein hauptinteresse dem eigentlichen projekt, und das
kann ich mit der momentanen funktionalität bereits weiterführen.

ich häng' nachher (aktuelle daten sind auf dem notebook) nochmal die
derzeitige version an, damit kanst du ja gerne herumspielen. es ist
sicher nicht allzu optimiert und vielleicht auch noch nicht ganz 100%
logisch durchdacht, aber für den anfang einfach und nachvollziehbar
anzuwenden.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach meiner Erfahrung benötigt das Display "nur" eine spezielle
Initalisierung und läuft anschließend auch problemlos mit der
originalen Fleury Lib. Die Wartezeiten sind dabei von besonderer
Bedeutung das steht aber alles im Datenblatt


Bis dann

Dirk, der trotzdem auch Stunden gebraucht hat das Teil zum laufen zu
bekommen...

Autor: M a x x (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

das ist grundsätzlich richig.
mein "problem" war ldiglich, dass die auffindbaren libs (fleury,
modifizierte radig, modifizierte codevision) mir persönlich zu
"mächtig" oder einfach nur zu spezifisch (z.b. die codevision mod)
gehalten waren. auserdem wollte ich auf diee art auch den umgang mit
winavr und mit den displays üben.
das timing ansich gestaltete sich überraschend unproblematisch (wohl
auch, weil ich eher grosszügig dimensioniert habe und da sicher nch
viel platz für optimierungen ist, wenn man das wirklich unbedingt
braucht (im bereich < 1us).
am ende habe ich wenigstens einiges über die unterschiede zwischen
cvavr und avr-gcc gelernt, besonders als es um die umsetzung des inline
assemblers ging (ich hatte wenig lust nochmal controllerspezifisch
assembler zu lernen und wollte weitestgehend bei einfachem c bleiben).

wie gehabt, alle grundfunktionen laufen scheinbar sauber mit meinem 8x1
und 16x2 und sobald ich etwas luft habe werde ich alle sinnvollen
displayspezifischen bonusfeatures in form weiterer funktionen einbauen.
je weniger displayspzifisch ich in späteren projekten denken muss umso
besser, das ist im grunde meine treibende kraft (ohne die ich die
ersten 2 erfolglosen nächte sicher nicht überstanden hätte ;) ).

Ciao...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.