Hi Ich habe einen Assembler Code geschrieben um mein 240x64 Pixel großes Grafik LCD mit T6963C Kontroller mit nem ATmega8515 anzusteuern aber der code funzt nicht. Warum was habe ich falsch gemacht?? Code als Anhang gepostet. Gruß Merle
Hoppala war der Falsche code Hier istb der richtige. Mfg. Merle
@Merle:
>Ich habe einen Assembler Code geschrieben
Aneignung von Code ? :-)
Der wahre Author wird sich bedanken. ;-)
Vielleicht kann der Author Dir ja beim Debuggen helfen.
@Herr Shark: Ist der Code für 4 oder 8 MHz geschrieben? Ansonsten: Respekt! ---- (QuadDash).
Durch Zufall bin ich der wahre Autor. Ich habe den Code für einen PIC geschrieben und dann versucht, ihn in AVR-Assembler zu übersetzten. Ich habe Merle in den letzten Wochen die Grafikansteuerung mit T6963C erklärt und den Code für ihn übersetzt. Seit einigen Wochen versuchen wir, den AVR Code zum laufen zubekommen. Gestern hat Merle vorgeschlagen, den Code ins Forum zu stellen. Da ich denke, die Probleme besser beschreiben zu können, wollte ich dies übernehmen, so dass die Fehleranalyse schneller gehen kann. Dass Merle den Code als seinen gepostet hat und gleichzeitig meinen Namen nicht gelöscht hat, ist natürlich äußerst amüsant. Obwohl zugleich nur die Prozessordatei und eine Übnerschrift hinzugefügt wurden, und das ganze dann als seinen eigenen Code anzupreisen, dass ist dann doch etwas dreist. Das wichtigste hat Merle aber komplett vergessen. Und zwar die Fehlerbschreibung. Da ich keine AVR-Hardware habe, habe ich Merle einige Tests machen lassen, mit dem folgenden Ergebnissen: Der AVR hängt in der Abarbeitung der Befehle bzw. geht zu früh in den Reset. Im Code verteilt wurden Testbits eingebaut. Kommt der Code zu dieser Stelle, so wird das Testbit an einem freinen Port gesetzt. Das war aber schon beim ersten Unterprogramm nicht mehr der Fall. Ich rufe als erstes Unterprogramm die Statusabfrage auf, die die Bits STA0 und STA1 aus dem Display ausließt. Um die Steuerleitungen Read, Write, CE, CD einzlen setzten zu können und das im Programm später nachvollziehen zu können, habe ich den Steuerport am µC (z.B. Portb) mit dcmd ("DisplayCommand") definiert. Der AVR hängt bei der Abarbeitung dieser Befehle jedoch schon: SBI dcmd,CD SBI dcmd,WR1 CBI dcmd,RD1 bis heier geht alles CBI dcmd,CE hier nicht mehr. Ich verstehe jedoch nicht, wieso der AVR bei so einem Portzugriff hängen beleiben kann. Als ich testweise die SBIs und CBIs durch nops ersetzten liess, hing der AVR angeblich nicht mehr. Dann wurde mir gesagt, dass man die Befehlsfolge doch mal anders schreiben kann. Ungefähr so: ldi r16,0b00000101 out dcmd,r16 damit kam laut Merle der AVR weiter. Jedoch diese Änderung in writecommand0, writecommand1 und writecommand2 (meine Unterporgramme, die SBIs und CBIs benutzten) brachte nichts. Laut dem Testergebnissen von Merle hängt der AVR bereits wieder in writecommand0. Jetzt hat Merle aber leider zu früh ans Forum verwiesen. Die genaue Stelle, and der der Avr hängt, wisssen wir nicht. Ob das ohne SBIs und CBIs etwas gebracht hat und der AVR dann nicht nach gleicher Anzahl von Befehlen hängt bzw. in reset geht, weiss ich nicht. Das hat Merle nicht mehr getestet, soweit ich informiert bin. Ich kann mir nur einen Hardware-Reset vorstellen, der die Befehlsarbeitung unterbricht. Also entweder ein Interupt, eine Schwankung in der Stromversorgung (kein 100nF Kondensator?), der Watchdog, oder am Resetpin irgendwas störendes. Der Watchdog ist doch standardmäßig deaktiviert, oder nicht? Der AVR hing bzw. ging in reset (mit dem SBIs und CBI-befehlen) nach ca. 25µs. Dass kann dann der Watchdog doch eigenltich nicht sein, weil das zu kurz wäre. Das Grundproblem ist also, dass der AVR die Befehle nicht durcharbeitet, sondern entweder hängt, oder in den reset geht. Das wäre ja die interessanteste Frage: Geht der AVR dutch irgendeine Unstimmigkeit in den Reset, oder hängt er? Ersteres ist wohl anzunehmen. An der Verwendung der SBIs und CBIs wirds wohl nicht liegen (?), denn das sind doch zugelassene Befehle für die PortA-D. Ich könnte Merle zwar mit dem Code alleinlassen, und sollte das eigentlich auch tun, nachdem er meinen Code als seine Leistung dargestellt hat, aber ich bin mal nicht so. Mich interessiert aber natürlich auch, wo die Fehler liegen können, zumal der Code auf dem PIC wunderbar funktioniert.
Den Code habe ich (Wolfram Hildebrandt, ungleich Merle) für 1Mhz geschreiben (für 4Mhz beim kleinen und mittleren PIC). Das sollte aber sehr leicht auf 8 oder mehr Mhz angepasst werden können.
@Wolfram: Die Frage nach der Taktung war auch nur ne "Fangfrage" ob er wenigstens den Kommentar in deinem Code gelesen hat. Außerdem ists gleichzeitig ein dezenter Hinweis auf einen eventuellen Fehler gewesen. War also nicht nur Boshaftigkeit von mir. "Respekt" war mein Ausruf über Merle für wie dumm er das Forum eigentlich hält. ---- (QuadDash).
Ich hab' mich schon gewundert. Der Code ist zwar funktionsfähig, aber doch sehr umständlich, wenn man viele Zeichen darstellen will.
Hallo ich möchte mich bei allen besonders Wolfram OFFIZIELL für diese und auch andere Dinge die ich schon im Forum Verbockt habe entschuldigen. Dank an alle die mir helfen wollte und auch dank an die die mich über meine Fehler informiert haben. Ich hoffe ihr alle könnt mir Verzeihen Und ich schwör bei meiner Ehre das soe twas niewieder vorkommt. Danke das ihr diesen Text gelesen habt. Gruß Merle (Beni)
Ich rufe im Code zuerst das Unterprogramm writecommand0 auf. Dann direkt das Unterprogramm "status". das zweite unterprogramm (status) wird bis zum ende ausgeführt, aber der Rücksprung klappt nicht. beim avr muss man sich ja um einiges kümmern, damit die Unterprogramme richtig funktionieren, sowas wie stackpointer initalisieren etc. Ist der Code richtig für zweifach verschaltelte unterprogramme geschrieben?
Unterprogramme: Naja, "einiges" isses ja nicht. Eben nur Stackpointer initialisieren. Ein "etc." gibts nicht mehr. Die Initialisierung ist so O.K., daran liegts nicht.
Hi thakiser Wasist denn mit dem Stackpointer?? Wird er falsch initialisiert? Gruß Merle
Hab ich doch geschrieben, ist so richtig. Ich glaube eher, daß der Atmel fürs Display um einiges zu schnell ist. Falls vorhanden, versuchs mal mit einem kleineren Quarz (um 1 Mhz) oder mit NOPs zwischen den Buszugriffen. Ich habe das Programm nicht intensiv durchgesehen, aber grobe Fehler habe ich jetzt nicht gesehen.
Hallo, hab schonmal einen Fehler gefunden: Bei der Status-Bit Auswertung fragt ihr den PORTB ab. Um von einem Port den aktuellen Zustand der Eingangspins zu lesen, müßt ihr PINB nehmen. Lesen von PORTB ergibt den Zustand des aktuellen Ausgabepins oder den Zustand der Pull-Ups.
Da ist bei mir der PIC durchgekommen. So einen Blödsinn wie Stackpointer initialisieren und hunderte extra-Register wie z.B. PINB hat der PIC nicht, bzw. man muss sich nicht darum kümmern. Aber daran kann die nicht richtig endende Rückkehr aus dem Unterprogramm doch eigentlich nicht liegen. Zur Taktung: die einzigste Stelle, wo evtl. die Taktung eine Rolle spielt, habe ich schon früher mit 4mal (PIC teilt durch 4) so viel nops ergänzt. Die Unterprogramme hängen trotzdem. Um herauszufinden, ob der AVR am Rücksprung hängt, oder in den reset geht, kann man doch mit einem anderen µC den Reset-pin abfragen. Der erste Hardware-Reset (durch RC-Strecke) wird vom zweiten µC erkannt und dann wird solange der Reset-Pin abgefragt, bis evtl. eine zweite zum reset ausreichende "Low-Zeit" erkannt wurde. Wenn der zweite µC dies erkennt, weiss man, dass es sich um einen ungewollten Hardware-Reset handelt. Was meint ihr dazu? Reset oder hängen des AVRs? Ich würde mir eher vorstellen, dass die Unterprogramme nicht richtig funktinieren. Aber das kann man ja mit Testunterprogrammen, die freie Portbits setzten testen. Nur wie gesagt, ich habe keine AVR-Hardware und kann daher nicht selber testen, sondern kann Merle nur anweisen, bestimmte Tests durchzuführen.
Naja, man kann sich über die verschiedenen Architekturen der AVRs und PICs streiten - mir gehts andersrum, ich "mag" die PICs nicht - aber das ist hier nicht das Thema ;-) Es ist sicherlich schwierig, sich auf eine vollkommen andere Architektur umzustellen, wenn man sich mal "eingeschossen" hat. Ich habe früher 68000 programmiert, dadurch fühlte ich mich beim Atmel sofort pudelwohl. Die Übergabe der Parameter per SRAM ist auch sehr ungewöhnlich, beim Atmel hat man so viele Register zur Verfügung, daß man eigentlich zu solchen Schritten nicht greifen muß (aber eine interessante Lösung, auf die ich noch nicht kam, weil die "kleinen" Atmels die STS/LDS-Befehle garnicht haben). Ich habe hier ein 240x128 Display liegen, das schon Schimmel ansetzt, und ich bin gerade dabei, zu überlegen, ob ich einen 4414 rauskrame und ihn dranhänge; wollte ich schon immer mal machen - vor allem das touch-panel endlich mal abfragen.... In diesem Programmteil habe ich noch etwas gefunden: ; auswerten des Statusbytes vom Display SBIC ddata,0 ; STA0=H? rjmp statuscheck SBIC ddata,1 ; STA1=H? rjmp statuscheck Laut dem T6963 Datenblatt ist der Status bei high O.K., bei Low muß gewartet werden. SBIC bedeutet "Skip if Bit in I/o is Cleared", also "ignoriere den nachfolgenden Befehl wenn das Bit gelöscht ist". Das macht dann genau das Gegenteil von dem, was gewünscht ist... Ersetzt das mal durch "SBIS", denn der Rücksprung zu "statuscheck" soll ja nur bei Status=low erfolgen. Abgesehen davon, wie bereits schon gepostet, daß mit PINx abgefragt werden muß. Üblicherweise Resettet der Atmel nur unter folgenden Bedingungen: 1. Per Hardware. Reset ist ein EINGANG, man kann daran nicht erkennen, daß der µC gerade einen Reset ausführt. 2. Per Software, wenn man zu Adresse $0000 springt 3. Per Watchdog (muß erst initialisiert werden, ein einschalten "aus Versehen" ist ausgeschlossen) 4. Durch einen Software-Bug (Stack o.ä.) Schaut mal, ob sich durch die Änderungen was tut. Irgendwann werden wir das Ding doch zum Laufen kriegen (ehrgeiz entwickel) Gruß
Mit dem Springen ist das beim AVR doch wenig konsequent. Z.B. der Befehl BRNE hier. D.h. springe zur Sprungmarke hier, solange das Zerobit nicht gesetzt ist, also springe zu hier, wenn die Bedingung erfüllt ist. Jetzt habe ich mir dementsprechend gedacht, statuscheck SBIC ddata,0 ; STA0=H? rjmp statuscheck heißt, springe zu statuscheck, wenn das Portbit 0 in ddata Null ist. Also sollte der AVR, wenn STA0 und STA1 High ist, die Schleife verlassen. Jetzt wird dann bei der Bedingung nicht dahin gesprungen, was angegeben ist, sondern es wird übersprungen. Tja, aber eben sowas muss man lernen. Dass ddata falsch ist, und durch PINB ersetzt werden muss, habe ich bei dem Sprungbeispiel mal weggelassen. Bezüglich des Ehrgeizes stimme ich dir voll und ganz zu. So eine triviale Ansteuerung muss man doch hinkriegen. Ich habe den Code mal so erweitert, dass ein Testunterprogramm aufgerufen wird, dass dann einige Testbits an einem freien Port setzt. Dann kann man schnell sehen, ob Unterprogramme prinzipiell funktionieren. Das muss Merle dann aber noch testen.
Mit den SBIS/SBIC tappe ich ab und an auch noch in eine Falle... Wenn man die Mnemonik-Kürzel aber (im Geist) ausschreibt, klappts meistens. Der Lötkolben raucht bereits, negative Spannung ist da, der 4414 ist gefunden (nach langem suchen, ist der einzige "große" Atmel den ich zu Hause rumliegen habe), die ISP funktioniert auch schon. Noch ein wenig gefummel und das Ding ist dran...
Sehr schön. Mein Code ist ja nur für ein 240x64 Pixel Display geschrieben. Aber solang dein Display größer ist, geht das wohl. Obwohl dann natürlich nicht alle Pixel gelöscht werden, da ich nur den angezeigten RAM lösche, also 240*64 Pixel im Grafik-RAM. Hast du ein T6963C Display mit integriertem Touchscreen? Oder ist der Touchscreen einzeln? Bei Reichelt gibt es ja ein Display mit intergriertem Touchscreen, den man, glaube ich, über RS232 konfiguriert. Ab 150 Euro aufwärtz. Im Anhang noch mal der überarbeitete Code. Prozessor ist der ATmega8. PORTA sind die Testbits, PORTC der Steuerport fürs Display und PORTB der Datenport fürs Display. Kann aber ganz leicht angepasst werden. Ich habe immer ddata bzw. dcmd mit dem ports vernüpft. also man muss nur die prozessordatei ändern und einmal ddata als PORTX und dcmd als PORTY einstellen (direkt am Anfang). Aber das siehst du sicher. Das Testunterprogramm ist auch schon drin. Porta zeigt dann, obs geklappt hat.
Ich habs mal runtergeladen und getestet - es funktioniert. Aber: In den Schleifen hast Du als Schleifenzähler R16 benützt. Eben dieses Register wird aber in den ganzen Status-Prüf und Display-Schreib- Subroutinen auch geändert, und somit geht die Schleife ins Nirwana -> bricht nie ab. Angehängt die korrigierte Datei, sie funktioniert auf dem Display. Meine Hardware sieht allerdings komplett anders aus, weshalb ich ein wenig dran rumgestrickt habe. Ich arbeite gerade an einer String-Ausgabefunktion, die die Text-Ausgabe wesentlich vereinfacht. Außerdem habe ich schnell noch die serielle Schnittstelle drangebastelt, das hilft bei der Fehlersuche auch enorm g Gruß Thomas
Ach so, ich vergaß: Das Display ist das 240x128 von Conrad (da ist Conrad ausnahmsweise mal relativ preiswert) und auch das Touch -Panel (analog). Allerdings muß man das Touch-Panel selbst irgendwie dranbasteln. Die Fertiglösungen sind doch langweilig g Es ist garnicht so einfach, nachträglich Touch-Panels zu bekommen, da war Conrad auch (wieder ausnahmsweise) der Günstigste.
Ach. Das ist toll. Geändert hat du also im Prinzip außer ein paar schöneren Umschreibungen nur meinen Denkfehler in Bezug auf Sprünge (SBIS anstatt SBIC), das einlesen (PINB), und natürlich meine aufgrund von erwiesener Dusseligkeit überschriebene Clearschleife Aber das passiert, wenn ein PIC-User seinen ersten AVR-Code schreibt und dämlicherweise auch noch das Zählregister als Zwischenspeicher benutzt ;) Aber eins ist doch merkwürdig: Wie kann ein Unterprogramm nicht zurückspringen, und plötzlich geht das ohne Probleme und keine Änderungen wurden daran vorgenommen? Die Fehler wirken sich zwar klar auf das Display aus (besonders die SBIC Geschichte), aber mit dem Sprüngen im Unterprogramm hat das ja nichts zu tun. Aber ich konnte es ja auch nicht selber testen. Aber das interessiert ja jetzt alles nicht. Hauptsache, es läuft. Ich danke dir sehr für die Korrektur des Codes!!
Jupp, Dein Code war eigentlich, bis auf den "Dusselfehler", in Ordnung. Aber mach Dir mal keine Sorgen, so etwas passiert immer wieder mal... und dann sucht man sich einen Wolf. Wenn man etwas Distanz hat, sieht man so etwas sofort. Ich gehe davon aus, daß die "Unterprogramm springt nicht zurück"-Sache eine Fehlinterpretation war.
Ich denke auch, dass es mit dem Unterprogramm daran lag. Ich habe den Code jetzt mal für Merles AVR [ich hätte automatisch beinahe PIC geschrieben ;)] angepasst. Den Grafikram habe ich wieder zurück auf das 240x64 Pixel Display geschrieben. Mal sehen, was der Test von Merle ergibt.
Hier noch mein bisheriger geistiger Erguß, ist für Debuggen des Displays ein nettes Tool: Das Display wird nicht initialisiert, man muß alles von Hand per serieller Schnittstelle senden (ich habe ein Programm, das HEX sendet und ausgibt). Befehle (Hex) 80 = Sende ein Command ohne Datenbyte 81 = Sende ein Command mit einem Datenbyte 82 = Sende ein Command mit zwei Datenbytes 88 = Sende 8 Datenbytes im Auto-Write Modus FF = Reset des Displays. Damit kann man mit dem Display rumspielen und verschiedene Initialisierungen austesten. Löschen des Displays ist allerdings etwas mühselig g könnte aber durchaus als weiterer Befehl implementiert werden. Man erspart sich halt das neu Flashen, wenn man an den Einstellungen des Displays rumbasteln will. Beispiel: Die Sequenz 80-97 80-80 82-00-00-40 82-1E-00-41 82-00-00-24 88-01-02-03-04-05-06-07-08 initialisiert das Display (nur Text), setzt Text-Home-Adress und Area, setzt den Adress-Pointer und gibt die ersten 8 Zeichen aus. 80-A3 setzt den Cursor auf 3 Linien usw.
Wie genial. Wie hast du das denn jetzt so schnell hinbekommen? Welches hex-Programm benutzt du dafür?
Wird der stackpointer beim ATmega8515 genau gleich wie beim ATmega8 Initialisiert?? Gruß Merle
Eine schlechte Nachricht: Bei Merle funktioniert der wieder von mir abgeänderte Code nicht. Es kann jetzt an seiner Hardware liegen, oder ich habe wieder neue Fehler in den Code eingebaut. Im Anhang ist noch mal der Code. Wenn ihr bzw. du (thkaiser) noch mal drübergucken würdest? Der Display-Reset liegt bei Merle aber nicht am µC, sondern per RC-Strecke an Masse und VCC.
Hi thkaiser du brauchst nichtmehr nachzuschuen. Es funktioniert. Wolfram und ganz besonders ich Danke dir für deine Hilfe und geduld. Gruß Merle
Der Merle hatte ein kurzen zwischen Read und Write. Jetzt läufts.
Na wunderbar, dann habe ich meine gute Tat für heute erledigt ;)
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.