Portbelegung auf ATMega für LCD1602

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 ?

Zitat:

---

Zitat von siro

Baue zunächst eine "lange" Warteschleife die "mit Sicherheit" mindestens 100ms dauert.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:

---

Beides erledigt, siehe unten

Zitat:

---

Zitat von siro

Das SPH Register in deinem Tiny24 existiert tatsächlich nicht, da hat wkrug recht ...

---

Hab ich einfach vom M16 PGM rüber kopiert und nicht darauf geachtet - ist jetzt berichtigt

Zitat:

---

Zitat von siro

Mich wunderte zudem noch der "OUT" Befehl für den Stackpointer:

---

Was meinst du damit? Kenne ich nicht anders und finde ich in anderen Programmen auch so.

Zitat:

---

Zitat von wkrug

Also irgendwie komm ich mit dem Timing nicht so ganz mit.

---

Stimmt (schon). Ich hab den Wert erhäht, damit das delay sicher lang genug ist, hab aber den Text dazu nicht geändert.

Zitat:

---

Zitat von avr_racer

So hab mal durchgeschaut... und das ein oder andere wurde schon angesprochen wie z.B. der Stack oder die Init.test3.txt

---

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.

Zitat:

---

Zitat von avr_racer

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 Kontrasts nur die erste Zeile zum Vorschein ist die Init des LCD nicht komplett oder unterbrochen worden.

---

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!

Zitat:

---

Zitat von avr_racer

Sag mal wie fit bist du eigentlich im ASM beim AVR ?

---

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.

Zitat:

---

Zitat von avr_racer

1.
In die Initialisierung gehören alle Inits interner sowie externe Peripherie.

---

Im Testprogramm sind keine Ints definiert, weil nicht benötigt.
Wenn, dann mach ich es mit .org.
Das kommt dann beim M16.

Zitat:

---

Zitat von avr_racer

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....

---

Im Testprogramm nicht zutreffend - weder Int definiert noch in Verwendung

Zitat:

---

Zitat von avr_racer

1.1
Code:
ldi lcdd,0x28 ;cd_function_set_std: 4Bit,2Zeilen,5*7 Font
rcall lcd_cmd4 ; Enthält bereits eine Zeitschleife
es steht zwar dahinter aber wenn man doch mal fix was ändern möchte ist
folgendes übersichtlicher
Code:
;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

---

???? Tut mir leid, kann damit nichts anfangen
Mich verwirrt sowas nur.

Zitat:

---

Zitat von avr_racer

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.

---

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!

Zitat:

---

Zitat von avr_racer

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.

---

Siehe oben. Der Befehl befindet sich am Ende der Initialisierung (=also fertig).

Zitat:

---

Zitat von avr_racer

Kleine Hausaufgaben
1. Warum kannst du ohne weitere Deklarationen XL/ Z direkt nutzen ?
2. Welche Register können nicht direkt mit Konstanten geladen werden ?

---

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.

Zitat:

---

Zitat von avr_racer

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

---

Werd ich mir genau ansehen.
Wird aber erst schlagend, wenn das Test-Programm die Testphase bestanden hat und dann mit Mega16 voll programmiert wird ...

Zitat:

---

Zitat von avr_racer

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.

---

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.
:(

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.....

Gut dein LCD zeigt nen Balken an, ohne Init, also ist erstmal die Versorgung i.O..
Kontrast mal ganz auf Anschlag gedreht ?

Ebenso ein Bild vom Aufbau oder Stromlaufplan, ich sag mal so ich sehe nichts... Und das LCD heißt auch wirklich 1602 ?
Hast du deine Programmierhwardware mal abgezogen von dem ISP Sockel?
RESET ist wie bescaltet ?

Nur mal so:
die Datenleitung sind zufälliger Weise nicht irgendwie vertauscht mit DB0-DB3 ?
Oder
DB04 = PA07
Db05 = PA06
DB06 = PA05
DB07 = PA04

Der RW-Pin liegt auf Masse und auch mit RS oder Enable nicht vertauscht ?
Oder Masse/Plusschluss eines Pins ?

Ebenso mal die Frage was ist von den Bits am Controller eingestellt ?


Mit dem Wait_Key, wenn dein Taster nicht entprellt per Hardware oder nach der Tasterabfrage keine >150ms Wartezeit drin sind, LASS ES!

Den weiteren Text hab ich vernommen aber das führt uns erstmal nicht weiter und sind viel Schönheitsdinge....

Wie sieht denn dein aktueller Code aus ?

Zitat:

---

Zitat von Siro

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.....

---

Wenn der nicht aktiviert ist passiert auch erstmal nichts !

@ Siro,
Für die Zeiten hab ich mir vor Jahren eine Excel-Tabelle erstellt mit der ich die Zeiten errechne.
Bislang hat das noch immer (annähernd) gestimmt (diverse Laufzeiten nicht berücksichtigt) und alle Anwendungen funktionieren damit. Allerdings hab ich noch keine Schleifen mit Doppelregistern realisiert. Vielleicht gibt es da einen größeren Unterschied.

Was die Tastensache betrifft, so sehe ich meine Routine als abgesichert.
Denn:
WAIT_KEY:
in XL,key_pin ;solange eine Taste gedrückt ist, geht's
cpi XL,0 ;nicht weiter. Somit kann kein versehentlicher
brne wait_key ;"Durchlauf" passieren. Erst nach dem Loslassen
;gehts weiter und ...
WK1:
in XL,key_pin ;... steht dann hier an, bis wieder eine Taste
cpi XL,0 ;gedrückt wurde.
breq wk1
ret

Somit gehts nur Schritt für Schritt von Befehl zu Befehl.

Zum Thema "watchdog":
Ich hab noch nie ein watchdog-Bit bewusst gesetzt. Weder 0 noch 1. Und es gab noch nie Probleme deshalb.

@ avr_racer,
die Sache mit den ISP-Pins wäre mir neu!
Bei allen meinen Projekten habe ich auch die ISP-Pins verwendet.
Teils auch für ISP. Und ich hatte noch nie Probleme damit.
Das einzige was Zores macht ist JTAG (M16). Das gibts beim T24 aber nicht.

Zitat:

---

Zitat von avr_racer

Gut dein LCD zeigt nen Balken an, ohne Init, also ist erstmal die Versorgung i.O..
Kontrast mal ganz auf Anschlag gedreht ?

---

Ja, 1. Zeile bleibt leer bzw. ohne Blöcke.

Zitat:

---

Zitat von avr_racer

Ebenso ein Bild vom Aufbau oder Stromlaufplan, ich sag mal so ich sehe nichts... Und das LCD heißt auch wirklich 1602 ?
Hast du deine Programmierhwardware mal abgezogen von dem ISP Sockel?
RESET ist wie bescaltet ?

---

Morgen mach ich ein Bild vom Aufbau zum besseren Verständnis.
es ist eine kleine Steckplatine ohne ISP und "reset" ist nicht beschaltet.

Zitat:

---

Zitat von avr_racer

Nur mal so:
die Datenleitung sind zufälliger Weise nicht irgendwie vertauscht mit DB0-DB3 ?
Oder
DB04 = PA07
Db05 = PA06
DB06 = PA05
DB07 = PA04

---

Auch aus Angst was versehentlich vertausch zu haben - x-mal geprüft = ok.

Zitat:

---

Zitat von avr_racer

Der RW-Pin liegt auf Masse und auch mit RS oder Enable nicht vertauscht ?
Oder Masse/Plusschluss eines Pins ?

---

Nichts vertauscht und RW ist offen.

Zitat:

---

Zitat von avr_racer

Ebenso mal die Frage was ist von den Bits am Controller eingestellt ?

---

Welche sollten das sein??
Da wurde nichts eingestellt, keine Fuses geändert oder dergleichen.

Zitat:

---

Zitat von avr_racer

Wie sieht denn dein aktueller Code aus ?

---

Siehe Anhang letzter post.

[edit]
Werde morgen noch RW auf GND setzen.
Ob's was bringt?
[endedit]

Digitale Eingänge sollten immer beschalten sein, teilweise müssen diese auch Beschalten sein (entweder mit Widerständen oder direkt). Wenn die Pins als Ein- und Ausgang verwendet wird muss ein Widerstand verwendet werden.

Der Reset sollte auch beschalten sein (mindestens ein Pullup-Widerstand). Ohne Widerstand kann es funktionieren, muss aber nicht. Hast du auch eine Led o.Ä. angeschlossen die du zum Testen verwenden kannst? So könntest du feststellen ob Resets auftreten bzw ob das Programm überhaupt läuft.

MfG Hannes

Wenn ein Pin nicht beschaltet ist, dann zieht ein interner Pullup im Prozessor den Pin nach High, sofern er als Eingang configuriert wurde.
Der R/W Pin vom Display muss auf Low sonst steht das Display immer auf Read Mode. Ich weis nicht ob die einen Pullup haben,
ein Pulldown vermutlich aber nicht. Ich mess das mal bei meinem....

Mein R/W Pin am Display liegt ohne Beschaltung auf High. Das würde demnach dann nicht funktionieren.

Ich hoffe, Du hast nicht mein Display erwischt, das verleitet regelrecht dazu es falsch anzuschliessen,
das ist mir nämlich auch passiert....Man beachte die Zählweise der Pins....
Anhang 33909

Standardmäßig sind bei den AVRs (zumindest die ich kenne) die Ports als Eingang ohne Pullup-Widerstand konfiguriert. Den Pullup schaltet man ein wenn man ins Portregister schreibt (den jeweiligen Pin auf 1 setzen).

MfG Hannes

Erst muss ich mich für eine Fehlmeldung entschuldigen,
denn beim Umbau von µC auf absolut händisch ist mir bewusst
geworden, dass ich das LCD verkehrt rum "gesehen" hab.
Weil ich das LCD so im Board hab, dass die Anschlüsse unten
sind und nicht oben. Zeile 1 ist bei den Anschlüssen.
Somit hat die Zeile 1 die Blöcke und nicht Zeile 2!
Zeile 2 ist leer.
DIE LCD-ANSCHLÜSSE WAREN/SIND IMMER RICHTIG BESCHALTEN!!
Hab nur die Zeilen vertauscht gesehen!

Aufbau mit T24:
Hab RS + R/W gegroundet.
Resultat: keine Änderung.

Pullup hin, pullup her ....

Aufbau manuell:
Nun hab ich statt dem µC ein Mäuseklavier installiert und
die entsprechenden commands darüber eingegeben.
RS + RW immer auf GND - also nur Befehle.
EN mit 4,7k gegen GND.
Per Taste + auf EN, bei Loslassen - über R.
CMD-Abfolge (x = per Taste EN > +/-):
$30 3x
$20 1x noch im 8-Bit Mode (4-Bit-Mode)
$28 2x erst 2 dann 8 (4-Bit, 2 Zeilen, 5x7)
$0F 2x erst 0 dann F (DSP on, Cursor on blink)
$06 2x erst 0 dann 6 (DSP fest, C autoincr)
$01 2x erst 0 dann 1 (clr DSP, C > home)
Pegel/V-levels an den Anschlüssen mit V-Meter kontrolliert - ok.
Somit sollte der Zeitfaktor (Warteschleifen zu kurz) eliminiert sein.
Oder "vergisst" das LCD nach gewisser Zeit, welche Befehle es schon erhalten hat!?

Resultat: keine Änderung ggü. µC oder keiner Beschaltung.
Es tut sich ggü. dem Status nach dem Spannung anlegen einfach ...
NICHTS, GAR NICHTS am LCD!!!
Die Blöcke bleiben unverändert und keine weitere Reaktion.

Bin ratlos ... Was nun?
Doch LCD defekt??

Und damit ihr euch den Testaufbau vorstellen könnt, die Fotos dazu.

Werde morgen noch DB4-DB7 mit R gegen GND hängen.

In solchen Fällen, wenn ich gar nicht weiter komme, neige ich dann dazu, ein neues Teil zu kaufen - also hier ein neues Display - um zu sehen, ob sich das auch so verhält oder ob das alte defekt ist.
Oder ich würde mir ein Programmcode aus dem Internet ziehen, der auf dem Display was anzeigt und das dann damit versuchen.
Was aber auch eine Lösung wäre, das Teil zu jemandem schicken, der damit vertraut ist und versucht es zum Laufen zu bekommen.

MfG

Ich habe es mal eben probiert:

Verkabelung:
DB0 frei
DB1 frei
DB2 frei
DB3 frei
DB4 über Widerstand nach Plus
DB5 über Widerstand nach Plus
DB6 an Masse
DB7 an Masse

RS an Masse
RW an Masse
E über Widerstand nach Plus

V0 (Kontrastpin) nach Masse

Wir simulieren das Datenbyte 0x30 indem wir DB4 und DB5 an High legen
und DB6 und DB7 an Masse legen.

Nun müssen wir mehrfach das Enable Signal nach Masse und wieder nach Plus schalten.
Ich habe den Draht rein und wieder raus gezogen.
Dann sollte das Display ALLE Zeichen im Kontrast zeigen.

Bilder:
Aufbau:

Anhang 33914

Versorgund einschalten
Anhang 33915

Enable Pin Mehrfach rausgezogen und wieder reingesteckt.
Anhang 33916

Dann sollte es Grundinitialisert sein.

Ich habe die Pullup Widerstände an DB4 und DB5 mal eben weggelassen, auch dann ging es.
Der Widerstand am Enable Pin nach Plus ist aber zwingend erforderlich bei dem Test, der Pin "schwebt" sonst...

Muss doch in den Griff zu bekommen sein....;)
Siro

Hi Siro!

DANKE!! Dein Test hat mir immens geholfen!

1. Dass nach der Spannungsversorgung dein LCD ebenfalls die Blöcke in Zeile 1 hat und
2. dass alleine das Senden von $30 beide Zeilen "habt 8" stehen lässt.
Ich werde morgen deinen Aufbau bei mir rekonstruieren und mal schauen ...
Danke nochmals!

Falls wieder nichts passiert ist mit Sicherheit das LCD defekt.

Mir ist eingefallen, dass ich eine alte Graupner-Computerfunke rum liegen habe (nicht mehr in Gebrauch), die auch ein LCD eingebaut hat.
Es ist ein 2x16er Display. Allerdings weiß ich nicht welches. Werd es mal genauer unter die Lupe nehmen.
Es ist größer und mit Sicherheit über 20 Jahre alt ...
Könnte ich eventuell ausbauen und versuchen ...

Die Displays haben sich eigentlich seit Jahrzehnten nicht geändert. Hab die vor 20 Jahren schon in ähnlicher Form bernutzt.
Die arme Graupner.. ;) Hab auch noch eine, aber aus der neuesten Generation.
Viel Erfolg, ich bin gespannt.

Siro

Danke für den Erfolgswunsch! Kann ihn gebrauchen! ;)
Ja, irgendwie wäre mir um die MC20 leid. Aber mal schauen, ob sich das LCD leicht ausbauen lässt.
Aber nur, wenn das neue defekt ist.

Bei Amazon gibt es jetzt blaue Displays für 1,17 Euro, kostenlose Lieferung:
https://www.amazon.de/Zeichen-Display-HD44780-Backlight-Arduino-Blau/dp/B009GEPZRE


Aber die Bewertungen sind teils schlecht, dauert wohl ewig und es wurden wohl auch defekte verkauft...:(
Wobei bei 1,77 kann man nicht viel verkehrt machen.

Bei Pollin hätte ich da mehr vertrauen
https://www.pollin.de/p/lcd-modul-tc1602a-09-120422

Zitat:

---

Zitat von HeSt

Erst muss ich mich für eine Fehlmeldung entschuldigen,
denn beim Umbau von µC auf absolut händisch ist mir bewusst
geworden, dass ich das LCD verkehrt rum "gesehen" hab.
Weil ich das LCD so im Board hab, dass die Anschlüsse unten
sind und nicht oben. Zeile 1 ist bei den Anschlüssen.
Somit hat die Zeile 1 die Blöcke und nicht Zeile 2!
Zeile 2 ist leer.
DIE LCD-ANSCHLÜSSE WAREN/SIND IMMER RICHTIG BESCHALTEN!!
Hab nur die Zeilen vertauscht gesehen!

---

Alles gut ein nicht initialisiertes LCD muss immer in der ersten Zeile eine Balken haben, deshalb hab ich drüber hinweg geschaut siehe weiter oben.

Zitat:

---

Zitat von HeSt

Aufbau mit T24:
Hab RS + R/W gegroundet.
Resultat: keine Änderung.

Pullup hin, pullup her ....

---

Wenn denn nur R/W grounden. RS ist für das Schreiben auf dem LCD notwendig.

Zitat:

---

Zitat von HeSt

Aufbau manuell:
Nun hab ich statt dem µC ein Mäuseklavier installiert und
die entsprechenden commands darüber eingegeben.
RS + RW immer auf GND - also nur Befehle.
EN mit 4,7k gegen GND.
Per Taste + auf EN, bei Loslassen - über R.
CMD-Abfolge (x = per Taste EN > +/-):
$30 3x
$20 1x noch im 8-Bit Mode (4-Bit-Mode)
$28 2x erst 2 dann 8 (4-Bit, 2 Zeilen, 5x7)
$0F 2x erst 0 dann F (DSP on, Cursor on blink)
$06 2x erst 0 dann 6 (DSP fest, C autoincr)
$01 2x erst 0 dann 1 (clr DSP, C > home)
Pegel/V-levels an den Anschlüssen mit V-Meter kontrolliert - ok.
Somit sollte der Zeitfaktor (Warteschleifen zu kurz) eliminiert sein.
Oder "vergisst" das LCD nach gewisser Zeit, welche Befehle es schon erhalten hat!?

Resultat: keine Änderung ggü. µC oder keiner Beschaltung.
Es tut sich ggü. dem Status nach dem Spannung anlegen einfach ...
NICHTS, GAR NICHTS am LCD!!!
Die Blöcke bleiben unverändert und keine weitere Reaktion.

Bin ratlos ... Was nun?
Doch LCD defekt??

Und damit ihr euch den Testaufbau vorstellen könnt, die Fotos dazu.

Werde morgen noch DB4-DB7 mit R gegen GND hängen.

---

Rein für die Init könnte man das so machen bleibt die Frage der Entrprellung der Taster/Schalter was es wahrscheinlich scheintern lässt.
Danke für die Bilder. Und prüfe Leitungen oder Stecklöcher auf dem Board...

So hoffe ich das dir folgendes weiterhilft

Das "Ur-LCD" auf dem auch dei KS0077/67 usw angelehnt sind hat Seite 39 des HD44780 foglenden Hinweis:

"4-bit operation, 8-digit ´ 1-line display with internal reset
The program must set all functions prior to the 4-bit operation (Table 12). When the power is turned on,
8-bit operation is automatically selected and the first write is performed as an 8-bit operation. Since
DB0 to DB3 are not connected, a rewrite is then required. However, since one operation is completed in
two accesses for 4-bit operation, a rewrite is needed to set the functions (see Table 12). Thus, DB4 to
DB7 of the function set instruction is written twice."

Ich muss zugeben das habe ich das letzte mal vor 5/6 Jahren gelesen nachdem ich mir dann meine 8-Bit-Erweiterung mit nem Schieberegister gebaut habe um Pins zu sparen. Seit dem hatte ich 4bit nie wieder angefasst weil dort einfach zuviele Fehlinterpretation möglich sind. Gerade in Eng wenn man da nicht sattelfest ist.

Musste mir mein Board nochmal schnappen und es für den 4bit-Mode aufbauen was schief geht... Die Routine sollte eigentlich sofort bei dir funktionieren wenn folgende Bedigungen eingehalten sind

Takt 1Mhz eingestellt wenn
CLKDIV8 = Haken raus
!!!!!!!!!!!!
Jetzt VORSICHTIG wirklich drauf achten das folgende Einstellung gewählt ist
SUT_CKSEL = Int. RC. Osc. 8Mhz.... egal was oder Ext. Crystal 0,9-3Mhz.... egal was

Finger WEG von Ext. CLOCK der Chip lässt sich nur dann durch anlegen eines externen Taktes in den Fues umstellen!!!
!!!!!!!!!!!!
KONTRAST BISSCHEN STÄRKER EINSTELLEN
RW = GND
RS/E = vom Crontroller wie gehabt
DB0-DB3 = offen da sie eh in Tristate geschaltet werden
DB4-DB7 = vom Controller wie gehabt

Wenn LCD i.O. sollte jetzt Texte in beiden Zeilen zeilen erschienen.

Sollte dein LCD nach ca 5s, ohne das du Einstellungen verändert hast, nur wieder einen Balken in der Zeile 1 haben ist es defekt.

Ich habe schon vor längerem 2 PDFs gefunden http://www.epemag.wimborne.co.uk/lcd1.pdf und http://www.epemag.wimborne.co.uk/lcd2.pdf vielleicht hilft es weiter. Ich könnte noch eine Hex kompilieren damit du das LCD mit einem uC testen kannst.

MfG Hannes

Ich habs jetzt leider nicht gefunden oder gelesen, ob das Display neu war oder schon im Betrieb. Wenn es noch nie in Betrieb war: hast Du schon mal die Platine / Lötstellen inspiziert? Ich habe die Erfahrung mit Teilen aus China gemacht, dass man das kontrollieren sollte, weil manchmal Lötzinnreste Brücken auf der Platine bilden. Wenn nichts zu finden ist, könnte man noch alle Lötstellen nachbearbeiten, ob das Display schon im Betrieb war , vor längerer Zeit, oder nicht. Vielleicht kommt irgendwo ein Signal nicht durch.

MfG

(Guten) Morgen,

die Erklärung zur Klammer:
Mein LCD ist defekt :(
Ich hab den Aufbau genau so wie Siro gemacht.
Die LCD-Anzeige nach der Spannungsversorgung siehe Foto.
Sie bleibt unverändert, egal wie oft E gegen + getippt wird.

Danke für eure Mühe, Zeit und die vielen Tipps!

Ich melde mich wieder ...

Gruß Heinz

- - - Aktualisiert - - -

Zitat:

---

Zitat von Moppi

Ich habs jetzt leider nicht gefunden oder gelesen, ob das Display neu war oder schon im Betrieb.

---

War/ist neu. War deshalb, weil vor einigen Jahren gekauft, aber nie verbaut ...
Die Lötstellen hab ich mit der Lupe kontrolliert und auch - soweit möglich - nachgelötet - alles ok.

Werd mir heute noch beim großen "C" ein neues holen. Ist grad mal 5km entfernt ...

nur als Tipp bei ähnlichen Problemen:
Auch wenn bei mir Hardware auf speziellen Plattformen nicht zum Funktionieren zu bringen ist (z.B. am Raspi): zum testen habe ich da immer einen Arduino für 5 EUR in Reserve, zu dem es super-simple fertige Beispielprogramme gibt, das ist eine Sache von 3 Minuten - es spart einfach Wochen-lange nervige Fehlersuchereien auf der eigentlichen genutzten Plattform.

Zitat:

---

Sie bleibt unverändert, egal wie oft E gegen + getippt wird.

---

E liegt über einen Widerstand an Plus,
Du musst E dann 3 mal nach Masse ziehen.;)

Zitat:

---

Zitat von Siro

E liegt über einen Widerstand an Plus,
Du musst E dann 3 mal nach Masse ziehen.;)

---

Lieber Siro,
es steht doch "egal wie oft" gegen Masse gezogen ...;)
Aber dein Testaufbau hat mir geholfen!

Hab mir ein neues 1602 LDC besorgt (€ 13,-)

Und ....
BINGO !!!!!!!!!!!!

@ avr_racer,
hab daraufhin gleich dein text3-progrämmchen adaptiert (statt portD > portA).
Und alles funktioniert!

Danke euch allen!

Jetzt kann ich mal beruhigt weiter machen ... bis ich auf das nächste Problem stoße ...
Dann rühr ich mich wieder (bin mir sicher!).
Spätestens jedoch, wenn ich fertig bin - und das wird noch lange dauern .................. ;)

Schön zu hören das es funktioniert, weniger schön das ein nicht benutztes und nagelneues einfach defekt war/ist. So kann man sich eben nen Wolf suchen warum das Programm nicht funktioniert obwohl es das tut vllt auch nur in Ansätzen.... Seuftz ;)

So, bin schon wieder da ;)

Nichts tragisches ...!

@avr_racer,
ich hab mir deine Zeitenrechnung genauer angesehen und bin zur Ansicht gekommen, dass sie nicht stimmt.
Jetzt gibt es zwei Möglichkeiten:
1. sie stimmt wirklich nicht oder
2. meine Rechnung stimmt nicht!

Dein Beispiel aus text3: (cc = cpu clock cycle = 1µs)
wait25us:
ldi r20,$20 ;1cc
wait25us1:
dec r20 ;1cc
brne wait25us1 ;1/2cc
ret
Nehmen wir brne mit 1cc an (=1µs), dann ergibt das folgende Rechnung:
$20 sind dezimal 32. Also 32 Durchgänge/Schleifen.
32 mal 2 (dec + brne á 1µs) ergibt 64µs und keine 25.

Wo liegt nun der Gedanken-Fehler?
Bei mir oder bei dir?

@alle:
Übrigens stehe ich schon länger auf der Leitung und komm nicht weiter.
Ich will/muss einen ADC-Wert (8Bit ADLAR genügt) in Volt umrechnen (Akkuspannung 12V, max. 13,7 Ladeschlussspannung).
Folgende ADC-Beschaltung: 15V-68k-ADC-50kPot-GND.
Bei exakt 15V wird mit einem Spindelpoti der ADC-Maximalwert genau auf 5V eingestellt.
Somit hab ich eine Reserve, sollte die Spannung mal über 13,7V ansteigen.
Zudem dient eine 5V Z-Diode als Schutz.
Bei 15V liegen nun 5V am ADC. Das ergibt einen ADC-Wert von 255 (ADCH).
Das ist Basis für die weiteren Berechnungen.
Nehmen wir nun als zu messende Spannung 10,4V an.
Das ergibt folgende Schlussrechnung:
15V.....255
10,4V....?
10,4*255/15=177 gerundet.
Umgekehrt:
255.....15V
177......?
15/255=0,0558 Und da haperts schon! Wie rechne ich mit 0,0588?
177*0,0588=10,4

Auch hab ich nachstehende Divisions-Routine im Netz gefunden.
Allerdings rechnet die nicht richtig.
Da steht im Rest (=Nachkommastelle) bei einer Rechnung 177/17, statt 4 eine 8!
Wo liegt hier der Fehler, bzw. wie/wo kann man das berichtigen?
Ich möchte bei den Zehntel-Volt schon relativ genau sein.

Sonst schaut bisher alles gut aus ... :)

Code:

---

; 8Bit Division mit Rest; Laufzeitverhalten im schlechtesten Fall (255/1) 103 Taktzyklen
; Achtung:
; Divison durch 0 wird nicht abgefangen und führt zu einer Endlosschleife
; Dieser Algorithmus funktioniert nur für vorzeichenlose 8Bit-Werte
; Nach Division steht das Ergebnis in r18 und der Rest in r16

.def divident =    r16
.def divisor =    r17
.def ergebnis =    r18
.def zw =    r19
    ldi    divident,177        ; Berechnet 177/17 !
    ldi    divisor,17     
division:
    clr    ergebnis        ; Ergebnis initialisieren
    ldi    zw,1            ; Teilbarkeit durch 1 annehmen
    tst    divisor
loop:
    brmi    div_loop        ; Den Divisor linksbündig ? -> JA
    lsl    zw            ; Zwischenergebnis und
    lsl    divisor            ; Divisor einen Schritt nach links
    rjmp    loop            ; ... und nochmal prüfen
div_loop:
    cp    divident,divisor    ; divident >= divisor
    brlo    division_weiter        ; -> nein
    add    ergebnis,zw        ; Ergebnis vergrößern und
    sub    divident,divisor    ; Dividenten verkleinern
division_weiter:
    lsr    divisor            ; Divisor und Zwischenergebnis
    lsr    zw            ; einen Schritt nach rechts
    brne    div_loop        ; zw!=0 ? ->JA
    nop                ; Ergebnis in ergebnis
                    ; Rest in divident !
end:    rjmp    end

---

Zitat:

---

Zitat von HeSt

Da steht im Rest (=Nachkommastelle) bei einer Rechnung 177/17, statt 4 eine 8!
Wo liegt hier der Fehler, bzw. wie/wo kann man das berichtigen?
Ich möchte bei den Zehntel-Volt schon relativ genau sein.

---

Hallo HeSt,
Rest ist nicht gleich Nachkommastelle. Ich habe den Code mal durch meinen BASCOM Simulator laufen lassen und bekomme als Rest nicht 8 sondern eine 7. 177/17 ist ja gleich 10 Rest 7. Um auf die erste Nachkommastelle von 4 zu kommen, könnte man nun den Rest von 7 wieder durch 17 teilen. Um den gleichen Code zu nutzen erst den Rest von 7 mit 10 multiplizieren und dann den Code mit 70 und 17 füttern.

Gruß
Searcher

Servus Searcher,
danke für die Antwort!
Werde es dann gleich probieren ....

Eine andere Frage noch an alle:
Im Datenblatt des Mega16 steht auf Seite 32 in Tabelle 14, dass der µC von den Timern nur durch Timer 2 geweckt werden kann.
Oder lese ich das falsch!?
Im AVR-Studio funktionieren aber sehr wohl auch T0 und T1 OVF.
Kann ich davon ausgehen, dass das auch in der Realität so ist?
Anhang 33926

Es kommt drauf an, welchen Sleep Mode Du möchtest, dann kannst Du sehen, was man nutzen kann, zum Aufwecken (im Datenblatt steht es dann ja). Oder Du entscheidest Dich für eine bestimmte Art und Weise, den aufzuwecken (weil es keine andere Möglichkeit gibt), dann muss geschaut werden, welcher Sleep-Mode dazu möglich ist. Je tiefer der Schlaf, desto weniger Möglichkeiten gibt es zurück zu kehren.

Beim ATmega328P steht auch nur Timer2. Ich verwende aber Timer1, der dann bei Überlauf einen Interrupt auslöst und auch zum Aufwachen führt.
Allerdings muss ich darauf achten, dass im jeweiligen Sleep-Mode dann der Timer1 auch aktiv ist. In manchen Modi sind bestimmte Dinge abgeschaltet, dann kann man die nicht nutzen.

MfG

Zitat:

---

Zitat von HeSt

So, bin schon wieder da ;)

Nichts tragisches ...!

@avr_racer,
ich hab mir deine Zeitenrechnung genauer angesehen und bin zur Ansicht gekommen, dass sie nicht stimmt.
Jetzt gibt es zwei Möglichkeiten:
1. sie stimmt wirklich nicht oder
2. meine Rechnung stimmt nicht!

Dein Beispiel aus text3: (cc = cpu clock cycle = 1µs)
wait25us:
ldi r20,$20 ;1cc
wait25us1:
dec r20 ;1cc
brne wait25us1 ;1/2cc
ret
Nehmen wir brne mit 1cc an (=1µs), dann ergibt das folgende Rechnung:
$20 sind dezimal 32. Also 32 Durchgänge/Schleifen.
32 mal 2 (dec + brne á 1µs) ergibt 64µs und keine 25.

Wo liegt nun der Gedanken-Fehler?
Bei mir oder bei dir?

---

Bei 1Mhz
;Call = 3 Takte (3µs)
wait25us:
ldi r20,$20 ;1cc ; 1Takt (1µs)
wait25us1:
dec r20 ;1cc ; 1Takt (1µs)
brne wait25us1 ;1/2cc ; 1Takt bei 0 und 2 Takte wenn !=0 also (1µs oder 2µs)
ret ; 4Takte (4µs)

3µs + 1µs + (32*3µs(!=0) - 1µs(bei 0)) + 4µs = 103µs bei 1Mhz

Ich habs mir mal geschrieben und passe es auf die Frequenz an, ja es geht auch anders und manchmal verwirrend ;)

Zitat:

---

Zitat von HeSt

@alle:
Übrigens stehe ich schon länger auf der Leitung und komm nicht weiter.
Ich will/muss einen ADC-Wert (8Bit ADLAR genügt) in Volt umrechnen (Akkuspannung 12V, max. 13,7 Ladeschlussspannung).
Folgende ADC-Beschaltung: 15V-68k-ADC-50kPot-GND.
Bei exakt 15V wird mit einem Spindelpoti der ADC-Maximalwert genau auf 5V eingestellt.
Somit hab ich eine Reserve, sollte die Spannung mal über 13,7V ansteigen.
Zudem dient eine 5V Z-Diode als Schutz.
Bei 15V liegen nun 5V am ADC. Das ergibt einen ADC-Wert von 255 (ADCH).
Das ist Basis für die weiteren Berechnungen.
Nehmen wir nun als zu messende Spannung 10,4V an.
Das ergibt folgende Schlussrechnung:
15V.....255
10,4V....?
10,4*255/15=177 gerundet.
Oder anders rum:
255/15=17*10,4=177 gerundet (was ADC dann tatsächlich bingt? 176/177?)
Jetzt drehen wir die Sache um:
177/17=10,4 gerundet.

---

Ja ADLAR lässt den ADC auf 8Bit schrumpfen somit ist deine Auflösung 5V (AREF) / 256bits = 0,0195..V also 19,5mV pro Bit
Diesen Wert deklarierst du dir als z.B: 195 in der Init und MULTIPLIZIERST du dir dann mit den im ADCH zu Verfügung stehenden BITS z.B.: mit 256 = 49920.
Dein Widerstandsteilerverhältnis ist 3:1 heißt 49920*3 = 149760 den Punkt richtig setzen und du hast deine 14.976V ohne geschönt zu haben.

1. 10,4*255/15 sind verkehrt denn 8bit ADC hat 256 Stufen die 0 gehört mit dazu
richtig also 10,4*256/15 =177,493bits. Abgeschnitten sinds dann nur 177 wie es auch korrekt ist. Aufgrund das dir jetzt aber im Wandler die Nachkommastellen fehlen wirds halt ungenauer.
Nur mit der Multiplikation ist es einfacher

177bits * 195(bits/V) = 34515(V) * Teiler 3 = 103545(V) jetzt nur den Punkt im LCD richtig setzen und du hast deine 10.3545V auf dem LCD, ohne DIVISION.
Nur über FESTKOMMAARETHMETIK

Zitat:

---

Zitat von HeSt

Nun hab ich nachstehende Divisions-Routine im Netz gefunden.
Allerdings rechnet die (auch) nicht richtig.
Da steht im Rest (=Nachkommastelle) nach obiger Rechnung, statt 4 eine 8!
Wo liegt hier der Fehler, bzw. wie/wo kann man das berichtigen?
Ich möchte bei den Zehntel-Volt schon relativ genau sein.

Sonst schaut bisher alles gut aus ... :)

Code:

---

; 8Bit Division mit Rest; Laufzeitverhalten im schlechtesten Fall (255/1) 103 Taktzyklen
; Achtung:
; Divison durch 0 wird nicht abgefangen und führt zu einer Endlosschleife
; Dieser Algorithmus funktioniert nur für vorzeichenlose 8Bit-Werte
; Nach Division steht das Ergebnis in r18 und der Rest in r16

.def divident =    r16
.def divisor =    r17
.def ergebnis =    r18
.def zw =    r19
    ldi    divident,177        ; Berechnet 177/17 !
    ldi    divisor,17     
division:
    clr    ergebnis        ; Ergebnis initialisieren
    ldi    zw,1            ; Teilbarkeit durch 1 annehmen
    tst    divisor
loop:
    brmi    div_loop        ; Den Divisor linksbündig ? -> JA
    lsl    zw            ; Zwischenergebnis und
    lsl    divisor            ; Divisor einen Schritt nach links
    rjmp    loop            ; ... und nochmal prüfen
div_loop:
    cp    divident,divisor    ; divident >= divisor
    brlo    division_weiter        ; -> nein
    add    ergebnis,zw        ; Ergebnis vergrößern und
    sub    divident,divisor    ; Dividenten verkleinern
division_weiter:
    lsr    divisor            ; Divisor und Zwischenergebnis
    lsr    zw            ; einen Schritt nach rechts
    brne    div_loop        ; zw!=0 ? ->JA
    nop                ; Ergebnis in ergebnis
                    ; Rest in divident !
end:    rjmp    end

---

---

Wo hast denn die Routine her ? Ähm der Rest steht nicht zufällig im DIVIDENT R16 drin mit 7 ??

177/17 = 10, ;10*17 = 170
177 -170 = R 7 ;7/ 17 schwer also 7*10 = 70
70/17 = 4 also 10,4 ;4*17 = 68 somit
70-68 = R 2 ;2/17 schwer also 2*10 = 20
20/17 = 1 also 10,41 ; 1*17 = 17
20-17 = R 3 ; 3/17 schwer also 3*10 = 30
30/17 = 1 also 10,411 usw...

Zitat:

---

Zitat von HeSt

Im AVR-Studio funktionieren aber sehr wohl auch T0 und T1 OVF.
Kann ich davon ausgehen, dass das auch in der Realität so ist?

---

NEIN das Datenblatt weiß mehr als der Simulator ausser es ist unter der Hilfe angegeben. Grundsätzlich aber das Datenblatt ausschlaggebend.

Man kann aber den Timer laufen lassen oder den Prescaler vor den SLEEP-Befehl zu setzen ist nun nicht wirklich kein Problem oder ?

Danke für die Antworten!

Zitat:

---

Zitat von Moppi

Es kommt drauf an, welchen Sleep Mode Du möchtest, ...

---

In diesem Fall ist nur Timer2 angegeben, egal welcher Modus.

Zitat:

---

Zitat von Moppi

Beim ATmega328P steht auch nur Timer2. Ich verwende aber Timer1, der dann bei Überlauf einen Interrupt auslöst und auch zum Aufwachen führt.
Allerdings muss ich darauf achten, dass im jeweiligen Sleep-Mode dann der Timer1 auch aktiv ist.

---

Das gibt mir Hoffnung. Im Datenblatt des ATmega328P ist auch nur Timer2 angegeben.

Zitat:

---

Zitat von avr_racer

25µs versus 103µs bei 1Mhz

---

Mir gings nur darum, ob mein Gedankengang richtig ist.
Ob da noch vorne und hinten ein paar µs dazu kommen, darum gings nicht.
Aber danke für die exakte Erklärung!

Zitat:

---

Zitat von avr_racer

Ja ADLAR lässt den ADC auf 8Bit schrumpfen somit ist deine Auflösung 5V (AREF) / 256bits = 0,0195..V also 19,5mV pro Bit

---

2 Hundertstel Volt an Genauigkeit genügen mir. Wenn die Zehntel stimmen passt es schon.

Zitat:

---

Zitat von avr_racer

Diesen Wert deklarierst du dir als z.B: 195 in der Init und MULTIPLIZIERST du dir dann mit den im ADCH zu Verfügung stehenden BITS z.B.: mit 256 = 49920.
Dein Widerstandsteilerverhältnis ist 3:1 heißt 49920*3 = 149760 den Punkt richtig setzen und du hast deine 14.976V ohne geschönt zu haben.

---

Die Multiplikationen hatte ich ja auch schon im Kopf.
NUR: ein 16Bit Register (word) fasst nur bis 65535.
Laut Datenblatt wird das Ergebnis einer Multipikation in R1-R0 geschrieben = 16Bit.
Wie aber funktioniert diese Multiplikation: 49920*3 = 149760?
Wo soll 149760 gespeichert werden?
Oder hier:
177bits * 195(bits/V) = 34515(V) * Teiler 3 = 103545(V)
Da fehlt mir noch einiges an Wissen ...

Zitat:

---

Zitat von avr_racer

Wo hast denn die Routine her ?

---

Irgendwo aus dem Netz. Woher weiß ich nicht mehr.

Der Timer2 ist glaub ich ein besonderer. Zumindest beim ATmega328P kann man den auch unabhängig takten, selbst, wenn sonst alles schläft und auch der übliche Taktgenerator abgeschaltet ist.
Das man auch Timer1 verwenden kann oder einen andern, liegt beim 328P daran, dass der auch durch so ziemlich jeden Interrupt geweckt werden kann. So löst auch der Timer1 bei Überlauf einen Interrupt aus und weckt also den µC. Auch wenn der Timer1 jetzt namentlich nicht direkt in der Tabelle steht. Auch Signalwechsel an den I/O-Ports können einen Interrupt auslösen und so zum Wecken führen. So könnte man auch eine Real Time Clock extern anschließen.


MfG

Ja, T2 ist ein async Timer, die anderen nicht.
Und PCInts hab ich beim Mega16 auch schon vermisst. Offenbar gibts die wirklich nicht :(
Beim Mega328 allerdings schon.

Zitat:

---

Zitat von HeSt

Die Multiplikationen hatte ich ja auch schon im Kopf.
NUR: ein 16Bit Register (word) fasst nur bis 65535.
Laut Datenblatt wird das Ergebnis einer Multipikation in R1-R0 geschrieben = 16Bit.
Wie aber funktioniert diese Multiplikation: 49920*3 = 149760?
Wo soll 149760 gespeichert werden?
Oder hier:
177bits * 195(bits/V) = 34515(V) * Teiler 3 = 103545(V)
Da fehlt mir noch einiges an Wissen ...

---

Na so als wenn du eine schriftliche Multiplikation machst. Heißt z.B: bei 49920*3 = 40000*3 + 9000*3 + 900*3 + 20*3 + 0*3 = 120000 + 27000 + 2700 + 60 + 0 = 149760 .
Im Link siehst du das ich erst 1low*2low + 1low*2high + 1high*2low + 1high*2high rechne
https://www.roboternetz.de/community...ine-Bibliothek unter Mathe.asm ;)
http://www.avr-asm-tutorial.net/avr_...nen/index.html

Das Wissen fehlt dir nicht sondern es ist nur verschüttet im Unterbewusstsein, man hats ja mal in der 2-4Klasse gelernt

Wo es gespeichert wird hängt von der Rechenart ab, Bei der Multiplikation fest verankert IMMER in R0:R1 heißt wenn dort die Werte vorher geladen werden, werden sie danach überschrieben.
Addition/Subtraktion Add r16,r17 wird das Ergebnis immer in das Register vor dem Komma geschrieben siehe Datenblatt Instructionset

Einfach mal im Simulator Werte laden und mit den Rechnarten probieren zum Verständnis.

Zum Timer 2 der kann ASYNCHRON bzw für SLEEP muss sogar ASYNCHRON betrieben werden.

Der MEGA16/32 sind die älteren Generationen Atmega 48/88/168/328 sind alles Atmega8 nur mit 4-32Kbyte Flash und kleinen Unterschiedlichkeiten in der Adressierung der Hawrdwere aber sonst identisch

Mein lieber Schwan!!
Das soll einer behirnen!?
Bei deinem "Mathe.asm" Beispiel steige ich komplett aus!!
Tut mir leid. Das pack ich einfach nicht. Das ist mir viel zu verwirrend.
Dafür gehts bei der Routine "Hardware Multiplikation von 16- mit 8-Bit-Zahl" aus dem Tutorial.
Danke!

Zitat:

---

Zitat von avr_racer

177bits * 195(bits/V) = 34515(V) * Teiler 3 = 103545(V) jetzt nur den Punkt im LCD richtig setzen und du hast deine 10.3545V auf dem LCD

---

Das stimmt so nicht!
103545 ist eine "Zahl"! Die kann ich am Display nicht anzeigen.
Einen 8-Bit Registerinhalt in Text umzuwandeln geht ja. Dazu hab ich eine Routine im Netz gefunden.
Aber wie geht das mit 3 Registern zu je 8-Bit?
Da kann ich nicht einfach jedes einzelne Register in Text umwandeln.
Für eine Zahl aus 3 Registern in ASCII bin ich im Netz leider nicht fündig geworden.
Ich kapier das alles leider (noch) nicht. :(

(fang mal irgendwann ganz sachte mit C++ an)

Zitat:

---

Zitat von HeSt

Mein lieber Schwan!!
Das soll einer behirnen!?
Bei deinem "Mathe.asm" Beispiel steige ich komplett aus!!
Tut mir leid. Das pack ich einfach nicht. Das ist mir viel zu verwirrend.
Dafür gehts bei der Routine "Hardware Multiplikation von 16- mit 8-Bit-Zahl" aus dem Tutorial.
Danke!

---

Ausgangsbasis sind immer 2*16bit Zahlen die jeweils aus 2*8bit Registern zu 1*16bit zusammen gefasst sind. Die Ergebnissregister sind 4*8bit somit ist der Zahlenbereich 0-4294967296 Zahlen möglich womit deine 103545 locker reinpasst.
Das Ergebnis steht auch relativ sichtbar
Was ist dennn angeblich so verwirrend ?

Nur weil das Carry also der Übertrag bei der Addition mit hinzukommt ? Wenn du selber schriftlich multiplizierst rechnest du doch genauso:

.....1234 * 5
.........20
.......150
......1000
......5000
.= ..6170

Rein in binär kann man das auch rechnen nur das wird absolut zuviel.
Das Problem bei dieser Routine ist das du die Restbildung zum Erweitern sich deutlich verkompliziert.
Denn hier bist du schon in der Floatingpointoperation heißt mit Kommastellen rechnen...

Zitat:

---

Zitat von HeSt

Das stimmt so nicht!
103545 ist eine "Zahl"! Die kann ich am Display nicht anzeigen.
Einen 8-Bit Registerinhalt in Text umzuwandeln geht ja. Dazu hab ich eine Routine im Netz gefunden.
Aber wie geht das mit 3 Registern zu je 8-Bit?
Da kann ich nicht einfach jedes einzelne Register in Text umwandeln.
Für eine Zahl aus 3 Registern in ASCII bin ich im Netz leider nicht fündig geworden.
Ich kapier das alles leider (noch) nicht. :(

---

Warum kannst du diese Zahl im Display nicht dastellen ? Du wandelst die 8bit in Text ? Eher nicht du meinst du wandelst es von 8Bit in DEZIMAL.
Die Routine ist nichtsweiter als ein Vergleich z.B.:
von 2300
>=1000 ? ja 2300 minus 1000 = 1 Durchgang Rest 1300
>=1000 ? ja 1300 minus 1000 = 1 Durchgang Rest 300
Durchgänge incrementieren oder Subtrahieren Wert als 2 speichern = tausender Stelle
>= 100 ? ja 300-100 = 1 Durchgang Rest 200
>= 100 ? ja 200-100 = 1 Durchgnag Rest 100
>= 100 ? ja 100-100 = 1 Durchgang Rest 0
Speichern als hunderter Stelle 3
>= 10 ? nein also 0 speichern als Zehner Stelle
>= 1 ? nein also 0 speichern als einer Stelle

Jetzt zu deiner Frage wie macht man das für x-8Bit-Register?
1byte 8 bit = 255 = Zahlenbereich also 100 ist dein Grundwert mit dem man beginnt abzuziehen
2byte 16 bit = 65535 = Zahlenbereich also 10000 ist dein Grundwert mit dem man beginnt abzuziehen
3byte 24 bit = 16777215 = Zahlenbereich also 10Mio ist dein Grundwert mit dem man beginnnt abzuziehen
usw

Hinweis Wertebereich 8bit = 256 Zustände. Der Zahlenbereich ist immer Wertebereich minus 1 deshalb 255 Trotzdem bleiben es 256 Zahlen 0-255

SO und auch dafür gibs eine Lösung im selbigen Link und nennt sich HEX_DEZ_Wandlung auch in der MATHE.ASM zu finden nur mit dem Unterschied das es eben für 4*8Bit ausgelegt ist der Zahlenbereich 0-4294967296.
Wenn du nach der Wandlung dir die Werte ins SRAM speicherst, stehen diese gleich als DEZIMAL zu Verfügung und man kann sich das Ergebniss sofort anschauen. DEBUG-Option im Simulator

Wie stark nutzt du den Simulator ? Also spielst du jede Änderung durch ?

Nachtrag: Sich mit diesen Grundlagen zu beschäftigen ist im ersten Moment schwer nur ohne gehts einfach nicht. Rate mal warum viele soviele Probleme in Hochsprachen haben obwohl diese es eigentlich einfacher machen sollten...

Zitat:

---

Zitat von Moppi

(fang mal irgendwann ganz sachte mit C++ an)

---

Klar 2 Jahre erstmal den Syntax lernen ohne das man irgendwas am Controller als Ergebnis sieht.... Auch die Wandlungen macht C+/C++/C# und alle anderen Hochsprachen ebenso nur mit anderen Ausdrücken... ;)

Zitat:

---

Zitat von avr_racer

Was ist dennn angeblich so verwirrend ?
Nur weil das Carry also der Übertrag bei der Addition mit hinzukommt ?

---

Nein, das ist es nicht.
Wenn man, so wie du, mit der Materie auf du + du ist, ist das leicht(er) zu verstehen.
Das fehlt bei mir leider noch fast völlig. Ich hab solche Rechnereien bislang nicht benötigt und mich somit auch nicht damit befasst.
Deshalb brauche ich jetzt Zeit zum behirnen. Bitte um Geduld.

Zitat:

---

Zitat von avr_racer

SO und auch dafür gibs eine Lösung im selbigen Link und nennt sich HEX_DEZ_Wandlung auch in der MATHE.ASM zu finden nur mit dem Unterschied das es eben für 4*8Bit ausgelegt ist der Zahlenbereich 0-4294967296.
Wenn du nach der Wandlung dir die Werte ins SRAM speicherst, stehen diese gleich als DEZIMAL zu Verfügung und man kann sich das Ergebniss sofort anschauen. DEBUG-Option im Simulator

---

Das, was davor noch an Erklärung steht, muss ich erst ganz genau durcharbeiten ...
HEX_DEZ_Wandlung hilft mir nichts! Oder reden wir da aneinander vorbei?
Wenn ich zB einen Wert von 174 in einem 8-Bit Register habe, ist für mich dieser Wert DEZIMAL. Das kann ich aber nicht am Display anzeigen.
Ich muss die einzelnen Ziffern erst einzeln in ASCII/Text (1=$31,7=$37,4=$34) in einzelne Register umwandeln damit sie anzeigbar sind. Oder was meinst du mit dezimal anzeigen?

Zitat:

---

Zitat von avr_racer

Wie stark nutzt du den Simulator ? Also spielst du jede Änderung durch ?

---

Das kommt auf den Code/die Änderung an. Wenn ich den Code "verstehe" und somit weiß wie er funktioniert, was er tut, meist nicht.
Bei diesen Rechnereien JEDE!

Zitat:

---

Zitat von avr_racer

Nachtrag: Sich mit diesen Grundlagen zu beschäftigen ist im ersten Moment schwer nur ohne gehts einfach nicht. Rate mal warum viele soviele Probleme in Hochsprachen haben obwohl diese es eigentlich einfacher machen sollten...

---

Deshalb ist mir, auch wenn es aufwändiger ist, Assembler lieber, weil ich weiß (oder hoffe zu wissen) was der Prozessor wie macht.
Ich hab wahrscheinlich noch einen Knopf im Hirn, den es erst gilt zu lösen.;)
Dann wirds mir leichter fallen diese Rechnereien zu verstehen und dann auch zu codieren. Ich lerne bei jedem Projekt wieder was dazu.
Bei diesem ist es halt im Moment heftig, weil mir ein gewisses Grundverständnis (und damit meine ich nicht der Codierung) fehlt.
Ich werd's schon noch hinkriegen ...

Zitat:

---

Zitat von HeSt

HEX_DEZ_Wandlung hilft mir nichts! Oder reden wir da aneinander vorbei?
Wenn ich zB einen Wert von 174 in einem 8-Bit Register habe, ist für mich dieser Wert DEZIMAL. Das kann ich aber nicht am Display anzeigen.
Ich muss die einzelnen Ziffern erst einzeln in ASCII/Text (1=$31,7=$37,4=$34) in einzelne Register umwandeln damit sie anzeigbar sind. Oder was meinst du mit dezimal anzeigen?

---

Dezimal sind Werte auf Basis von 10.
Hexadezimal Werte auf Basis von 16.
Binär oder Dual Werte auf Basis von 2.

In einem Bit kann nur Dual gespeichert werden.
In einem Byte, das aus 8 Bit besteht, wird Hexadezimal gespeichert. Hier sind Werte von 0 bis einschließlich 15 möglich.

Umgewandelt werden muss deshalb von Hexadezimal nach Dezimal , zur Ausgabe in einzelne Stellen (der darzustellenden Dezimalzahl) zerlegt und als ASCII-Wert abgebildet.

dezimal (Basis 10): 123
hexadezimal (Basis 16): 7B
binär (Basis 2) 8 Bit: 01111011


MfG

- - - Aktualisiert - - -

Zitat:

---

Zitat von avr_racer

Klar 2 Jahre erstmal den Syntax lernen ohne das man irgendwas am Controller als Ergebnis sieht....

---

Na, na! Wenn man das erlernt, sieht man schon was... ;)

In der Tat sind die ersten Schritte schwer. Überall. Auch bei Assembler bzw. Maschinensprache braucht man Geduld. Nicht so schnell, immer eins nach dem andern. Ich glaube HeSt wird gerade etwas überrumpelt.

MfG

Zitat:

---

Zitat von HeSt

Nein, das ist es nicht.
Wenn man, so wie du, mit der Materie auf du + du ist, ist das leicht(er) zu verstehen.
Das fehlt bei mir leider noch fast völlig. Ich hab solche Rechnereien bislang nicht benötigt und mich somit auch nicht damit befasst.
Deshalb brauche ich jetzt Zeit zum behirnen. Bitte um Geduld.

---

Na lass mal genau wie du hab ich auch damit angefangen ohne solche Umherrechnen nur irgendwann gehts halt nicht mehr weiter. Also keine Angst dieser Lernzustand ist ganz normal ;)

Zitat:

---

Zitat von HeSt

Das, was davor noch an Erklärung steht, muss ich erst ganz genau durcharbeiten ...
HEX_DEZ_Wandlung hilft mir nichts! Oder reden wir da aneinander vorbei?
Wenn ich zB einen Wert von 174 in einem 8-Bit Register habe, ist für mich dieser Wert DEZIMAL. Das kann ich aber nicht am Display anzeigen.
Ich muss die einzelnen Ziffern erst einzeln in ASCII/Text (1=$31,7=$37,4=$34) in einzelne Register umwandeln damit sie anzeigbar sind. Oder was meinst du mit dezimal anzeigen?

---

Das sind nur die Namen der Register und fügst diese in deiner Hauptdatei zum Anfang ein oder "schaltest" es in der Mathe-Datei einfach frei.
Also HEX_Dez_Wandlung brauchst du trotzdem. denn wie willst du das A als DEZ darstellen bzw es sind ja 2 ASCII-Zeichen §31 und $30 nur das wären doch schon 2byte für zwei einezelne Ziffern die als Zehn interpretiert werden.
Einfacher ist es doch 1byte mit HEX 10 zu beschreiben und in der Ausgabe zum LCD
1. Kopie von $10 anlegen
2. swapst du das Highbyte auf lowbyte und addierst $30 dazu
3. $31 als Datensatz zum LCD schicken, 1 wird angezeigt
4. Kopie Highbyte ausmaskieren und wieder mit $30 addieren
5. $30 als Datensatz zum LCD schicken, 0 wird angezeigt

Hinweis: Die Mathe.asm bringst das Ergebnis steht in den Registern richtig drin, je nach Ansicht in Dezimal oder HEX. Ich entnnehme deiner Aussage das du es auf Dezimal eingestellt hast im Simulator.
Es gibt jetzt verschiedene Ansätze wie du diese Ergebnis jetzt wann wandelst.
1. Du nimmst die Register wie sie sind und wandlest erst bei der Ausgabe in ASCII-Zahlen was aber die Ausgabe komplizierter macht.
oder
2. Ergebniss berechnen lassen dann von HEX in Dezimal wandeln und im RAM ablegen ACHTUNG je nach ANSICHT im Simulator: HEX-Ansicht dann sind es PSEUDO-HEXEN da du es schon in DEZIMAL betrachtest oder in Dezimal dann sind die Werte als DEZ interpretiert falsch, Ausgabe der DEZ-Zahlen da in der mit der Addition des Wertes von $30

Noch mal einfach.
Du brauchst eine reine:
TEXTAUSGABE
ZAHLENAUSGABE

Hab mal zwei Bilder angehängt. $1312 * $0100 = $131200 da die ALU nur in Binär/(HEX) rechnen kann funktioniert die Registerübergreifende Darstellung in DEZIMAL nicht da die Zahlen von UNS falsch interpretiert werden
Damit du es richtig interpretierst müsstest du
19*256 + 18 = 4882 und 1*256 +0 = 4882 * 256 = 1249792
Das Ergbeniss richtig zu interpretiern
19*65536 + 18*256 + 0*256 = 1249792

Anhang 33932

Zitat:

---

Zitat von HeSt

Das kommt auf den Code/die Änderung an. Wenn ich den Code "verstehe" und somit weiß wie er funktioniert, was er tut, meist nicht.
Bei diesen Rechnereien JEDE!

Deshalb ist mir, auch wenn es aufwändiger ist, Assembler lieber, weil ich weiß (oder hoffe zu wissen) was der Prozessor wie macht.
Ich hab wahrscheinlich noch einen Knopf im Hirn, den es erst gilt zu lösen.;)
Dann wirds mir leichter fallen diese Rechnereien zu verstehen und dann auch zu codieren. Ich lerne bei jedem Projekt wieder was dazu.
Bei diesem ist es halt im Moment heftig, weil mir ein gewisses Grundverständnis (und damit meine ich nicht der Codierung) fehlt.
Ich werd's schon noch hinkriegen ...

---

Wie gesagt das ist ein Frage deiner Darstellungsform im Simulator am besten auf HEX lassen wenn es Rgeisterübergreifend arbeitet.

genau moppi, ich dachte eigentlich, das wäre einem asm-Programmierer bekannt...

Zitat:

---

Wenn ich zB einen Wert von 174 in einem 8-Bit Register habe, ist für mich dieser Wert DEZIMAL.

---

DAS stimmt natürlich nicht.
174 ist (ohne Vorzeichen) gespeichert als 10101110 bzw in 1 Byte-Register als 0xAE (editiert)
nun muss man diese Zahl in eine andere Schreibweise (mit dezimalen Ziffern) umwandeln (der Zahlenwert bleibt dabei ntl identisch), erst dann erhält man die drei Ziffern 1, 7, 4
und dann müssen die einzelnen Ziffernstellen 0-9 in Zeichen '0' bis '9' umgewandelt werden, erst dann lassen sie sich als Zeichen (nicht als Zahl) aufs Display bringen.

Zitat:

---

Zitat von HaWe

genau moppi, ich dachte eigentlich, das wäre einem asm-Programmierer bekannt...

DAS stimmt natürlich nicht.
174 ist gespeichert als 10101110 bzw in 2 Byte-Registern als 0xA 0xE
nun muss man diese Zahl in eine andere Schreibweise (mit dezimalen Ziffern) umwandeln (der Zahlenwert bleibt dabei ntl identisch), erst dann erhält man die drei Ziffern 1, 7, 4
und dann müssen die einzelnen Ziffernstellen 0-9 in Zeichen '0' bis '9' umgewandelt werden, erst dann lassen sie sich als Zeichen (nicht als Zahl) aufs Display bringen.

---

FALSCH
174 ist 1 BYTE die jeweils aus dem A als Highbyte und dem E als Lowbyte zusammengesetzt sind als 0xAE = 1Byte