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
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.
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).
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
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.
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 ;)
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
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.
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...
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.