Also irgendwie komm ich mit dem Timing nicht so ganz mit.
Bei 1Mhz sind die Zeitschleifen zu lang (200ms bei 46msRoutine), bei 8 MHz sind es dann nur 28ms.
Auf jeden Fall bei mir im Simulator.
Der tiny24 hat auch keinen SPH?
Also irgendwie komm ich mit dem Timing nicht so ganz mit.
Bei 1Mhz sind die Zeitschleifen zu lang (200ms bei 46msRoutine), bei 8 MHz sind es dann nur 28ms.
Auf jeden Fall bei mir im Simulator.
Der tiny24 hat auch keinen SPH?
Ein Tipp von mir, wie ich es auch immer gemacht habe und immer noch mache bis die Displays Leben zeigen:
Baue zunächst eine "lange" Warteschleife die "mit Sicherheit" mindestens 100ms dauert.
Dann benutze diese "überall". So kannst Du zunächst mal ein Timing Problem ausschliessen,
wenn es dann noch nicht geht, liegt das Problem bei der Ansteuerung selbst.
Bis das Display läuft, solltest Du generell die Lange Wartezeit benutzen.
Auch bei den Signalen von Enable RS usw, LAAAAANGE Schleifen zum Testen, das tut ja keinem weh....
Man verheddert sich sonst. Schnelligkeit Optimierung erst wenn das Display läuft.
Es scheint ja noch nicht einwandfrei geklärt zu sein, wie lange deine Funktionen wirklich warten
Dann fällt mir grade noch auf:
Du initialsierst dein Display dauernd neu:
ich würde die Initialisierung wohl eher so machen:
Das SPH Register in deinem Tiny24 existiert tatsächlich nicht, hat wkrug recht, das gibts erst beim Tiny84 mit 512 KByte RAMCode:rcall lcd_init ; Initialisierung nur EINMAL DSP_MOD: .... rjmp dsp_mod ; Hauptschleife ohne neue Inititialisierung
Die Initialisierung gleich beim Start für den Stack scheint okay und somit universell. Ich denke das kann bleiben.
Es gibt jedoch Controller die bei derartigen Zugriffen (auf Registern die nicht existieren) mit einer Speicherschutzverletzung reagieren und das System anhalten,
ich glaub aber nicht bei deinem.
Mich wunderte zudem noch der "OUT" Befehl für den Stackpointer:
Aber der Stackpointer liegt tatsächlich im IO Bereich, ungewöhnlich aber völlig korrekt.
Siro
Geändert von Siro (01.01.2019 um 19:29 Uhr)
So hab mal durchgeschaut... und das ein oder andere wurde schon angesprochen wie z.B. der Stack oder die Init.
test3.txt
Wenn du das LCD richtig angeschlossen hast solltest du mal den Kontrast so einstellen das man die Dots 5x7 ein wenig sieht. Kommt hier mit Erhöhung des KOntrastet nur die erste Zeile zum vorscheinen ist die Init des LCD nicht komplett oder unterbrochen worden.
Sag mal wie fit bist du eigentlich im ASM beim AVR ?
1.
In die Initialisierung gehören alle Inits interner sowei externe Peripherie. Ebenso sollten alle Ints, also die gesamte Vectortabelle aufegführt werden entweder.
OderCode:.org $0000 rjmp INIT reti reti reti reti reti . . . . .
Denn wenn der SEI aktiv ist und man vllt sich mal vertan hat und der zugehörige Int wird ausgelöst und diese Tabelle fehlt kann es sein das dein Controller mitten in der Startinit wieder loslegt....Code:.org $0000 rjmp INIT .org $0001 rjmp ??? .org $0002 rjmp ???? . . . .
1.1
es steht zwar dahinter aber wenn man doch mal fix was ändern möchte istCode:ldi lcdd,0x28 ;cd_function_set_std: 4Bit,2Zeilen,5*7 Font rcall lcd_cmd4 ; Enthält bereits eine Zeitschleife
folgendes übersichtlicher
Die LCD -Deklarationen sollten ebenfalls im Hauptprogramm ganz oben stehenCode:;SET Function .equ F = 2 ;1 = 5x10 0 = 5x7 .equ N = 3 ;1 = 2line(4line) 0 = 1line .equ DL = 4 ;1 = 8bit int 0 = 4bit interface .equ HSF = 5 ;immer 1 setzen Symbolisiert das Ende ldi temp1,(1<<HSF|0<<DL|1<<N|0<<F) ;funktionset rcall lcd_command ;DatenLine1=8bit, N=1 2zeilig á 40 Zeichen d.h. 4zeilig á 20Zeichen ret
1.2
Zu den Registern sei gesagt die sollten nur einen allgm. Namen bekommen und haben nicht wirklich was mit den einzelnen Programmteilen, in textlicher Form, was zu tun. Ob es nun lcdd, tempx oder sonst wie benannt wird spielt keine Rolle da diese wirklich meist die absoluten temproären Daten sind und meist nur für die jeweilige Unterroutine wichtig sind.
Daten die über mehrere Funktionen z.B. Sekunden/Minuten einer Uhr von Interesse sind werden im SRAM vorgehalten.
Warum spreche ich das an ?
Hier hats dich ein wenig erwischt, Daten wurden in XL geschrieben obwohl du genau lcdd dafür vorgesehen hast somit wurde erst gar keine LCD-Daten ausgegeben.Code:; ldi XL,0x03 ;clr DSP, Curs > home (01) ; rcall lcd_cmd4 ; Erst wenn die komplette Init fertig ist Cursor Home schicken mit 0x01 ;woher also 0x03 ; rcall lcd_dlys ;dito ; ldi XL,0x06 ;also entry_mode DSP fest, Curs auto-inc ldi lcdd,0x06 ; Und warum plötzlich in XL und nicht in lcdd ? rcall lcd_cmd4 ; ; rcall lcd_dlys ;dito pop XL ret
Der Befehl 0x01 ist LCD löschen und setzen auf Cursorpostition 0 in Zeile 1, würde ich erst immer nach der fertigen Initialisierung des LCD aufrufen.
Das hier sollten die Hauptfehler gewesen sein, Wenn die Verkabelung stimmt ...
Kleine Hausaufgaben
1. Warum kannst du ohne weitere Deklarationen XL/ Z direkt nutzen ?
2. Welche Register können nicht direkt mit Konstanten geladen werden ?
2.
Datenbanken so wie die dazugehörigen Textausgaben inklusive der Adressen, sollten in einer Include gepackt werden siehe hier
https://www.roboternetz.de/community...Seriel-ATMega8 unter DbTxt_LCD.asm
3.
An Manchen Stellen hast du in der Unterroutine zum Schluss eine Zeitschleife und nachdem du diese Unterroutine verlassen hast folgt auf den Fuße wieder eine.
Warum ? Entweder du entwickelst die Unterroutinen so das diese in und ansich voll funktionsfahig aus sich heraus sind. Zumindest solltest du dich nur auf einen Weg festlegen.
puuhhhh jjaaaa das wars was mir erstmal aufgefallen war/ist...
Geändert von avr_racer (02.01.2019 um 09:20 Uhr)
Guten Morgen, Leute!
Erst mal vielen Dank für eure Zeit, die ihr für mein Problem aufwendet!
Und für die Tipps samt Lösungen!
Da ich das erst richtig verarbeiten muss, erbitte ich mir etwas Zeit, bis ich wieder Rückmeldung gebe.
Nur eines kurz @avr_racer:
die Sache mit den Daten in XL ist mir heute früh auch aufgefallen, auf lcdd geändert. Half nix.
Alles weiter werde ich beherzigen und umsetzen ...
Ich grins mich eins - mir gehts da wie Dir und dem LCD: wir brauchen alle mal ein paar waits wenns kompliziert wird *gg*... Da ich das erst richtig verarbeiten muss, erbitte ich mir etwas Zeit, bis ich wieder Rückmeldung gebe ..
Spass beiseite. Ich habe zwar keine Assemblerlösung. Aber in Assembler werden ja ähnliche Routinen nötig wie in C - und da kann ich ein bisschen was zu den Waits beitragen. Im folgenden Code sind die "waits" - heissen dort
......_delay_us (parameter)
rot hervorgehoben. Die Delays habe ich vor Jahren angepasst für 20 MHz Controllertakt (ist ja aber in µs angegeben) - und diese Routinen laufen bei mir so auf irgendwelchen, möglichst günstigen 2x16-LCDisplays. Vielleicht hilft Dir das ein bisschen weiter?
Code:// Erweiterte Fassung mit Routine für selbst definierte Zeichen // Stand = Erweiterung von lcd-routines.h und lcd-routines.c // vom 11. Apr. 2012 // 28 Nov 2012 16:24 Leichte Korrekturen // 27 Juni 2015, 19:27 Datenausgabe PC0..PC3, Steuerport PD // Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus // http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial // Die Pinbelegung ist über defines in lcd-routines.h einstellbar #include <avr/io.h> //#include "lcd-routines.h" #include "lcd_162_xt_ALCo.h" #include <util/delay.h> #include <avr/eeprom.h> // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // sendet ein Datenbyte an das LCD void lcd_data(unsigned char temp1) { LCD_PORT |= (1<<LCD_RS); // RS auf 1 setzen lcd_send(temp1); } // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // sendet einen Befehl an das LCD void lcd_command(unsigned char temp1) { LCD_PORT &= ~(1<<LCD_RS); // RS auf 0 setzen lcd_send(temp1); } // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Eigentliche LCD-Zugriffs-Funktion; 4-Bit-Modus void lcd_send(unsigned char data) { // oberes Nibble setzen LCD_PORT = (LCD_PORT & 0xF0) | ((data >> 4) & 0x0F); _delay_us(15); lcd_enable(); // unteres Nibble setzen LCD_PORT = (LCD_PORT & 0xF0) | (data & 0x0F); _delay_us (15); lcd_enable(); _delay_us (60); LCD_PORT &= 0xF0; } // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // erzeugt den Enable-Puls void lcd_enable(void) { LCD_PORT |= (1<<LCD_EN1); _delay_us (20); // kurze Pause // Bei Problemen ggf. Pause gemäß Datenblatt des LCD Controllers verlängern // http://www.mikrocontroller.net/topic/80900 LCD_PORT &= ~(1<<LCD_EN1); } // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Initialisierung: // Muss ganz am Anfang des Programms aufgerufen werden. void lcd_init(void) { LCD_DDR = LCD_DDR | 0x0F | (1<<LCD_RS) | (1<<LCD_EN1); // Port auf Ausgang schalten // muss 3mal hintereinander gesendet werden zur Initialisierung _delay_us (40); LCD_PORT = (LCD_PORT & 0xF0 & ~(1<<LCD_RS)) | 0x03; lcd_enable(); _delay_us (15); lcd_enable(); _delay_us (11); lcd_enable(); _delay_us (11); LCD_PORT = (LCD_PORT & 0xF0 & ~(1<<LCD_RS)) | 0x02; _delay_us (11); lcd_enable(); _delay_us (11); // 4Bit / 2 Zeilen / 5x7 lcd_command(CMD_SetIFOptions | 0x08); // Display ein / Cursor aus / kein Blinken lcd_command(CMD_SetDisplayAndCursor | 0x04); // inkrement / kein Scrollen lcd_command(CMD_SetEntryMode | 0x02); lcd_clear(); } // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Sendet den Befehl zur Löschung des Displays void lcd_clear(void) { lcd_command(CLEAR_DISPLAY); _delay_us (15); } // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Schreibt einen String auf das LCD void lcd_string(char *data) { while(*data) { lcd_data(*data); data++; } } // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - //String aus EEPROM laden und an LCD senden void lcd_eep_string(const unsigned char *data) { // unsigned char c; while(1) // { // c = eeprom_read_byte(data); // if(c==0) return; // lcd_data(c); // data++; // } } // Ende void lcd_eep_string(const // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Schreibt ein Zeichen in den Character Generator RAM // Daten liegen direkt im RAM void lcd_generatechar(uint8_t code, const uint8_t *data) { // lcd_command(LCD_SET_CGADR|(code<<3)); // Startposition des Zeichens einstellen for (uint8_t i=0; i<8; i++) // Bitmuster übertragen { // lcd_data(data[i]); // } // } // Ende void lcd_generatechar(uint8_t code, // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ciao sagt der JoeamBerg
Beides erledigt, siehe untenZitat von siro
Hab ich einfach vom M16 PGM rüber kopiert und nicht darauf geachtet - ist jetzt berichtigt
Was meinst du damit? Kenne ich nicht anders und finde ich in anderen Programmen auch so.
Stimmt (schon). Ich hab den Wert erhäht, damit das delay sicher lang genug ist, hab aber den Text dazu nicht geändert.
ldi lcdd, 0x01 ;*
$01 löscht das Display, von cursor setzen auf Zeile1 Pos1 hab ich nichts gelesen!
$03 setzt zusätzlich den cursor auf Z1P1.
Und der Befehl ist der letzte der Init-Prozedur.
Wie schon geschrieben:
Es kommt in der ersten Zeile gar nichts zum Vorschein, dafür in der 2. Zeile sofort nach Anlegen der Spannung 16 Blöcke. Ob nun ein T24 in der Schaltung ist oder nicht. also auch ohne Init oder sonstiger Ansteuerung!
Wie meinst du das, bzw. worum gehts dir?
Wie auch schon geschrieben: ich hab einige verschiedene, kleinere Programme für den T13, den M8 und eine Heizungssteuerung für den M16 geschrieben (mit dem Texteditor), mit AVR umgewandelt und wenns nötig war mit debug getestet.
Im Testprogramm sind keine Ints definiert, weil nicht benötigt.
Wenn, dann mach ich es mit .org.
Das kommt dann beim M16.
Im Testprogramm nicht zutreffend - weder Int definiert noch in Verwendung
???? Tut mir leid, kann damit nichts anfangen
Mich verwirrt sowas nur.
Das mag für dich zutreffen, nicht für mich. Denn durch eine zugeordnete Benennung wird für mich ein Programm, speziell wenn es länger ist, besser lesbar. So weiß ich in den einzelnen Routinen (auch später, wenn eine Routine in eine Bibliothek gewandert ist) wozu das Register dient. Das ist in mir drin - kommt aus dem Großrechnerbereich (sieh unten) und von der Clipper-Programmierung.
Manchmal werden direkt veränderbare Register zu wenig, dann muss ich klarerweise in den SRAM "ausweichen". Wird aber, soweit möglich, vermieden.
Wenn wenig direkt veränderbare Register zur Verfügung stehen, dienen X,Y,Z bei mir als "Arbeitsregister", die ständiger Veränderung unterliegen. Sind einfacher zu schreiben als Rxx oder benannte. Zudem tu ich mir leichter, wenn ich 16 Bit benötige. Da XYZ vordefiniert und für mich eindeutig. Sie sind auch durch die Großschreibung leicht erkenntlich. Wenn genug Register zur Verfügung stehen, werden andere unterhalb XYZ bis R16 als Arbeitsregister verwendet. Und dann neben den namentlich (nahezu) fix zugeordneten immer mit "WRKx" (WoRKregister) definiert (bei euch meist als "tempx" o.ä.). Die Mnemonic, die ich meist bei den Namen verwende, kommt aus dem Großrechnerbereich (alles englisch). Ist eine ganz andere Welt, prägt aber. Daher auch mein meist gemischter Text D/E.
Aus oben genannten, jahrzehntelang prägenden Tätigkeiten erklärt sich auch mein Programmierstil. Somit auch mein Problem mit "fremden" Bibliotheken.
Man möge mir verzeihen!
Siehe oben. Der Befehl befindet sich am Ende der Initialisierung (=also fertig).
zu 1.: Siehe 1.2
zu 2.: von R0-R15
Gewisse Grundlagen sind mir bekannt.
Sonst hätte ich meine vorherigen Projekt nicht lösen können.
Werd ich mir genau ansehen.
Wird aber erst schlagend, wenn das Test-Programm die Testphase bestanden hat und dann mit Mega16 voll programmiert wird ...
Hast recht.
Wurden eliminiert.
Antworten zu Text3 siehe Anhang
Um das Problem mit den Wartezeiten (delays) zu eliminieren, hab ich auf "Mechanik" umgestellt. Statt Wartezeiten in Routinen zu definieren verwende ich nun die "wait_key"-Routine. Die Wartezeit wird somit per "Taste" abgefragt. Händisch ist man sicher nicht zu schnell
Man sollte, da die Befehle nun per Tastendruck weitergeschaltet werden, auch jeden Schritt auf dem LCD verfolgen können.
Und trotzdem funktioniert ... NICHTS!
Nach Power on (ob LCD alleine oder an T24 angeschlossen):
1. Zeile: dunkel/leer
2. Zeile: voll mit Blöcken (aber nur, wenn Kontrast fast auf 0V), also keine "Anzeige".
Das bleibt unverändert, auch wenn mit der Taste weiter geschaltet wird.
Geändert von HeSt (02.01.2019 um 13:44 Uhr)
Deine Zeitverzögerungen habe ich mal versucht anhand des Datenblatts nachzurechnen:
Vorab:
Die CPU arbeitet intern (startet) mit einem 8 MHz Clock, dieser wird standardmäßig durch 8 geteilt,
somit bleibt ein Clock von 1 MHz bestehen.
Durch die "single pipeline" Struktur benötigen die meisten der Befehle dann auch entsprechend nur 1 Mikrosekunde.
Nehme ich jetzt mal deine Wartefunktion LCD_DLYL die 46ms dauern soll:
Es wird der Wert Hex 0xDAE0 dezimal 56032 ins X register geladen und in der Schleife kontinuierlich runtergezählt.
sbiw XH_XL,1 benötigt 2 Zyklen
brne ldl1 benötigt 2 Zyklen ausser beim letzten Durchlauf, dann nur einen.
Das sind also 56032 mal 4 Zyklen = 224128-1
nun kommen noch die anderen Befehle dazu
2 push XH
2 push XL
2 ldi
2 ldi
2 pop
2 pop
3 ret
3 der Aufruf der Funktion mit rcall
Also insgesamt 18 Zyklen
Das sind dann 224127+18 = 224145 also 224,145 Millisekunden
Bei 8 MHz wären es 28,0018125 Millisekunden
Jetzt können wir rückwärts rechnen welchen Wert wir wirklich brauchen für 46 ms
46000 - 18 = 45982
geteilt durch 4 für die innere Schleife
jedoch vorher noch einen abziehen
45981 / 4 = 11495,25
somit müste der Wert für das Laden des X Registers 11495 dezimal bzw. 0x2CE7 sein.
-----
Für die 2ms Sekunden wäre es dann
20000-18-1=19981 / 4 = 4994,25 also 49995 bzw. Hexadezimal 0x1383
----
Ich habe auf meinem Rechner nichts mit Atmel drauf,
aber das kann sicher mal jemand überprüfen mit dem Simulator.
Siro
Dies löst zwar nicht dein Problem, aber das Timing der Wartefunktionen sollte damit stimmen, sofern ich nix falsch gemacht habe...
Dein WAIT_KEY: hat aber ein Problem:
Du fragst den Pin ab und dann wird die entsprechende Funktion danach ausgeführt.
Das geht aber SOOOO schnell, das bei der nächsten WAIT_KEY die Taste noch garnicht losgelassen wurde
und somit wartet er garnicht mehr und führt die nächste Funktion sofort aus.
Thema Tastenentprellung.
So kommt leider immer ein Problem zum nächsten. Aber der Ansatz ist doch schonmal gut.
Bau mal einfach in die WaitKey eine lange Schleife rein bzw. rufe dort nur deine LCD_DLY funktion auf, unabhängig ob Taste gedrueckt ist.
und versuche es erneut.
Könnte es auch sein, dass der Watchdog zuschlägt ?
Das WDE Bit im Register WDTCSR mus auf 0 gesetzt sein.
Laut Datenblatt ist es undefiniert ??, hab ich aber auch noch nicht verstanden wie das geht.....
Geändert von Siro (02.01.2019 um 14:28 Uhr)
Guten Morgen,
jo nimm dir Zeit.
Ein Hinweis zur Zeile 1 und 2 als Deklaration.
$80 ist das SET-DD-RAM-ADRESS-Kommando den Cursor an die jeweilige Adresse springen zu lassen. $80 muss immer addiert werden zur Cursorposition in allen Zeilen!
Ebenso sind die Zeiten nochmal zu beachten.
Du hast das LCD an den ISP-PINs angeschloßen. Das kann manchmnal zu Problemen in der Kommunikation mit dem LCD führen da der ISP-Programmer unter Umständen die PINs nicht frei gibt.
Wäre es möglich mal ein Screenschot vom Aufbau zu machen ?
Berechtigungen
Zitieren
Lesezeichen