8 Bit Interface auf mehere Ports aufteilen

[Enloo]

Guten Tag,

ich würde gerne mein 12232 Display von Pollin über einen Mega8 zum laufen bringen. Jedoch müsste ich das 8 Bit Interface auf 3 Ports (Port B, C und D) aufteilen.
In Bascom scheitere ich schon bei der Config da ich ja hier nur den einen Port für die 8 Bit angeben kann. Vlt kenn hier jemand ein "Hintertürchen"

Ein andere Idee wäre das ganze in Assembler zu machen. Allerdings hab ich so gut wie keine Ahnung von Assembler, hab jedoch sowieso vor mich da mal ein wenig umzusehen…

Ich hoffe mir kann jemand weithelfen.
Wäre echt genial.

MfG Enloo

 

[oldmax]

Hi
Nun, schau dir mal den Beitrag "keine Angst vor Assembler" an. Ist in den FAQ's zu finden. Wenn dann noch Fragen sind, hier wird dir geholfen.
Bits auf ausgänge zu verteilen mach ich sowieso nur in den Ausgaberoutinen. Zuerst werden Bytes beackert. So ist das schön einfach zuzuordnen. Wenn sich dann die Hardware ändert, wird nur in den Ausgaberoutinen angepasst.
Da ich es in Assembler schreibe sieht's dann so aus...
Out_Byte_A: .Byte 1 ;Bit 0 = Port A Bit 5 .. LED 0 an
;Bit 1 = Port C Bit 0 .. Hupe ein
; etc.

Out_A_Ctrl: .Byte 1 ; Hier stehen die Ergebnisse der Bearbeitung drin

In Programm wird dann kräftig auf das Out_Byte_A draufgeschrieben....
LDS Reg_1, Out_Byte_A ; Ausgabebyte holen
ANDI Reg_1, =b11111110 ; zuerst das Bit löschen
LDS Reg_2, Out_A_Ctrl ; Bearbeitungsergebnisse holen
OR Reg_1, Reg_2 ; Gilt jetzt nur für Bit 0, sonst Maske anpassen
STS Out_Byte_A, Reg_1 ; So ist mein Bit im Ausgabebyte

In einer Ausgaberoutine wird dann verzweigt:

Hupe:
      LDS  Reg_1,Out_Byte_A      ; Ausgabebits holen
      ANDI Reg_1,0b00000001     ; Bit 0 testen auf "1"
      BREQ Hupe_Aus                 ; Bit ist 0
      In     Reg_1, Port_C           ; Port erst lesen
      ORI   Reg_1, 0b00000001    ; Bit 0 setzen
      OUT  Port_C, Reg_1
      RJMP End_Hupe
Hupe_Aus:
     In      Reg_1, Port_C           ; Port erst lesen
     Andi   Reg_1, 0b11111110    ; Bit 0 löschen
     OUT   Port_C, Reg_1
End_Hupe: Ret

So etwa sieht's dann aus.
Gruß oldmax

 

[Enloo]

Hi
Nun, schau dir mal den Beitrag "keine Angst vor Assembler" an. Ist in den FAQ's zu finden. Wenn dann noch Fragen sind, hier wird dir geholfen.
Bits auf ausgänge zu verteilen mach ich sowieso nur in den Ausgaberoutinen. Zuerst werden Bytes beackert. So ist das schön einfach zuzuordnen. Wenn sich dann die Hardware ändert, wird nur in den Ausgaberoutinen angepasst.
Da ich es in Assembler schreibe sieht's dann so aus...
Out_Byte_A: .Byte 1 ;Bit 0 = Port A Bit 5 .. LED 0 an
;Bit 1 = Port C Bit 0 .. Hupe ein
; etc.

Out_A_Ctrl: .Byte 1 ; Hier stehen die Ergebnisse der Bearbeitung drin

In Programm wird dann kräftig auf das Out_Byte_A draufgeschrieben....
LDS Reg_1, Out_Byte_A ; Ausgabebyte holen
ANDI Reg_1, =b11111110 ; zuerst das Bit löschen
LDS Reg_2, Out_A_Ctrl ; Bearbeitungsergebnisse holen
OR Reg_1, Reg_2 ; Gilt jetzt nur für Bit 0, sonst Maske anpassen
STS Out_Byte_A, Reg_1 ; So ist mein Bit im Ausgabebyte

In einer Ausgaberoutine wird dann verzweigt:

Hupe:
      LDS  Reg_1,Out_Byte_A      ; Ausgabebits holen
      ANDI Reg_1,0b00000001     ; Bit 0 testen auf "1"
      BREQ Hupe_Aus                 ; Bit ist 0
      In     Reg_1, Port_C           ; Port erst lesen
      ORI   Reg_1, 0b00000001    ; Bit 0 setzen
      OUT  Port_C, Reg_1
      RJMP End_Hupe
Hupe_Aus:
     In      Reg_1, Port_C           ; Port erst lesen
     Andi   Reg_1, 0b11111110    ; Bit 0 löschen
     OUT   Port_C, Reg_1
End_Hupe: Ret

So etwa sieht's dann aus.
Gruß oldmax

Ok also erst mal recht herzlichen dank für die Antwort,
verstehe zwar das ganze bis jetzt nur teilweise aber ich glaub darauf kann ich aufbauen…

 

[dino03]

Hallo,

Ein andere Idee wäre das ganze in Assembler zu machen. Allerdings hab ich so gut wie keine Ahnung von Assembler, hab jedoch sowieso vor mich da mal ein wenig umzusehen…

Ok also erst mal recht herzlichen dank für die Antwort,
verstehe zwar das ganze bis jetzt nur teilweise aber ich glaub darauf kann ich aufbauen…

Assembler ist was schönes Aber es ist auch stark unterschiedlich zu einer
Hochsprache. Das ist so als ob du von Windows auf Linux umschwenkst. Es
ist eine komplett andere Philosophie dahinter. Die grundsätzlichen Strukturen
im Programm kann man beibehalten aber der Rest landet dann auf dem Müll.
In Assembler gibt es keine Variablen im eigentlichen Sinn mehr. Es gibt nur noch
Bits und Bytes. Es kommt nur darauf an was du daraus machst Also fang in
Assembler bitte mit Grundstrukturen an sonst kommt schnell der Frust.
Wenn man es einmal gelernt hat möchte man es aber nicht mehr missen

Ach ja ... Beim Befehl für GLCDs kann man den Datenport bei Bascom nicht
aufteilen. Entweder man verwendet einen ganzen Port dafür oder man läßt es
ganz sein.

Gruß
Dino

 

[Cassio]

Ach ja ... Beim Befehl für GLCDs kann man den Datenport bei Bascom nicht
aufteilen. Entweder man verwendet einen ganzen Port dafür oder man läßt es
ganz sein.

Hallo Dino!

Das Gleiche hatte ich Enloo schon in einer PN mitgeteilt......
Deswegen fragt er vermutlich auch, ob man dies nicht mit einer C oder ASM Routine ändern kann.

Grundsätzlich ist es eben etwas schwieriger, ein GLCD an einem Mega8 zu betreiben. Der Gute hat einfach zu wenig PIN`s..... für ein 8Bit-LCD, 6 Steuer-Pin`s und dazu noch Ein-/Ausgänge für das Programm.


Nun ja, es sein denn man nimmt das OLED von Dirk.
Da braucht man nur die 5 Adern für den SPI-Anschluss und hat dann sogar ein grafisches LCD mit über 262000 Farben.

Grüße,
Cassio

 

[Enloo]

Assembler ist was schönes Aber es ist auch stark unterschiedlich zu einer
Hochsprache. Das ist so als ob du von Windows auf Linux umschwenkst. Es
ist eine komplett andere Philosophie dahinter. Die grundsätzlichen Strukturen
im Programm kann man beibehalten aber der Rest landet dann auf dem Müll.
In Assembler gibt es keine Variablen im eigentlichen Sinn mehr. Es gibt nur noch
Bits und Bytes. Es kommt nur darauf an was du daraus machst Also fang in
Assembler bitte mit Grundstrukturen an sonst kommt schnell der Frust.
Wenn man es einmal gelernt hat möchte man es aber nicht mehr missen

Grüß dich,
ja also ich hab mir jetzt auf alle Fälle fest vorgenommen auf Assembler umzusteigen. Da es mich nebenbei auch sehr interessiert wie so ein Ding im Detail funktioniert und nicht nur die reine Programmierung.

Am Rande: Kann mir einer ne gute ausführliche Lektüre dafür empfehlen?
Mir ist dem Beitrag von oldmax nicht so recht anfreunden... (nimms nicht persönlich )

@ Cassio:
Du sagtest doch ich solle ein Thema eröffnen...

MfG Enloo

 

[dino03]

Hi,

Das Gleiche hatte ich Enloo schon in einer PN mitgeteilt......
Deswegen fragt er vermutlich auch, ob man dies nicht mit einer C oder ASM Routine ändern kann.

das konnte ich dann natürlich schlecht wissen. Hab kein cc oder bcc bekommen

Grundsätzlich ist es eben etwas schwieriger, ein GLCD an einem Mega8 zu betreiben. Der Gute hat einfach zu wenig PIN`s..... für ein 8Bit-LCD, 6 Steuer-Pin`s und dazu noch Ein-/Ausgänge für das Programm.

Aber an so einem kleinen Controller auf Biegen und Brechen nen GLCD zu
setzen und dann noch diese Klimmzüge machen. Im Endeffekt ist es die
Arbeit und Mühe nicht wert. Dann lieber nen größeren nehmen. Notfalls wenn
es auf die Größe ankommt nen Mega8535 im PLCC44-Gehäuse mit Sockel.
Die bekommt man noch bei Reichelt. Oder nen Mega32 im TQFP44. Da ist das
löten aber dann wieder etwas schwieriger.

Nun ja, es sein denn man nimmt das OLED von Dirk.
Da braucht man nur die 5 Adern für den SPI-Anschluss und hat dann sogar ein grafisches LCD mit über 262000 Farben.

Als reinen Bedien-Satelliten mit nen paar Tasten, Display und ner Schnittstelle
zur Zentrale mag das bei so einem kleinen Controller ok sein. Aber ... naja ...
Wobei das Display schon recht nett ist ...

Gruß
Dino

 

[Dirk]

Hi Dino,

Als reinen Bedien-Satelliten mit nen paar Tasten, Display und ner Schnittstelle zur Zentrale mag das bei so einem kleinen Controller ok sein. Aber ... naja ...
Wobei das Display schon recht nett ist ...

ich würde auch einen größeren Mikrocontroller verwenden, wenn die IOs nicht ausreichen, Auswahl gibts ja genug . Eine günstigere Alternative zu dem OLED-Modul wäre zum Beispiel das FSTN-Grafikmodul XV-GDM128X64-RGB mit seriellem Interface (SPI, 5 Signale). Leider bin ich bis jetzt noch nicht dazu gekommen, mein C-Programm für das Displaymodul nach Bascom umzuschreiben, werde ich aber noch machen.

Grüße,
Dirk

 

[laplace]

Hallo Enloo,

ich gehöre ja auch zur Fraktion "billig, will ick" (und bereue es doch recht oft), aber das Display inkl. der Aufgabe ist schon etwas "abenteuerlich".
8 Bit in Assembler auf 3 Ports zu verteilen ist schon möglich (es sind übrigens 9 Bit mit Chip Select), aber, hast du überhaupt eine Dokumentation, wie das Teil konkret angesteuert wird?
Z. B. "clockt" das Teil die Bits mit dem Timer IC 555 die Datenbits ein?
Oder andere Frage: gibt das Teil Zeichen oder Pixel aus?
Hab' mal in das Datenblatt gelinst: das sieht nach seeeeeeeeeeeeeeeeeeeeeehr viel Arbeit aus. Ob der Zeitaufwand lohnt?


LG
Werner

 

[Markus]

Hallo Enloo,

also ich für meine Person würde mir Deine Konfiguration mit Mega8 und Assembler wirklich nochmal sehr gut durch den Kopf gehen lassen.

Ich will ja nicht unbedingt Werbung für BASCOM machen, wegen mir nimm C, z.B. den WinAVR aber ....

... ich würde:

1. Definitiv einen größeren Controller verwenden und keine Hackschnippselei bei den Port betreiben, schau Dir doch mal z.B. den Mega16 an.

2. BASCOM oder C zur Programmierung verwenden oder hast Du Assembler-Erfahrungen? Ich bin der Meinung, dass Du Dich mit C oder BASCOM schneller der Materie annähern kannst und schneller erster Erfolge hast als in Assembler.

Grüße,
Markus

 

[Enloo]

Ok damit hab ich jetzt nicht gerechnet, dass mir so viele davon abraten…
Also dann werd ich mich mal nach einem anderen µC für das Display umsehen…

Noch mal kurz zu den SPI-Displays:
Sind die schwerer bzw. anders anzusteuern als die anderen GLCDs ?

 

[Cassio]

@ Cassio:
Du sagtest doch ich solle ein Thema eröffnen...

Hallo Enloo !

Ja, genau! Und das ist auch absolut OK so.

Dadurch hast du auch erfahren, dass die Anderen selbst eine Programmierung in ASM mit dieser Kombination (Mega8 & GLCD) nicht anstreben würden.

Noch mal kurz zu den SPI-Displays:
Sind die schwerer bzw. anders anzusteuern als die anderen GLCDs ?

Nun generell ist es im SPI-Mode nicht "schwieriger" ein GLCD anzusteuern, als im "normalen" 8Bit-Mode.
Es kommt wie immer auf das Display und den Controller an.....

Das OLED von Dirk ist aber kein "Standard" für SPI-Displays, weil es einfach MEHR ist als nur ein farbiges GLCD!
Das OLED hat einen internen Speicher in dem du gleich mehrere Font-Dateien und Grafiken direkt ablegen kannst.
Das kann sonst kein Displaymodul von sich behaupten.
Du sendest dann also per SPI nur noch "Positions- & Farbangaben" und schon werden Linien, Vierecke, Kreise, Texte, Bilder usw. vom Display selbstständig dargestellt.
Dies ist auch der Grund, warum sich Dirk`s OLED-Display weder technisch noch preislich sich direkt mit anderen fabigen GLCD`s (und OLED`s) vergleichen lässt.
Die anderen Display`s sind eben einfach nur Anzeigen...... ohne besondere Intelligenz und Speicher.

Du kannst dir das ganze ja HIER mal durchlesen.
Dort habe ich beschrieben, wie die Komunikation via SPI mit dem Display funktioniert und welche Besonderheiten es hat.
Vielleicht interessierst du dich dann ja doch dafür.



Grüße,
Cassio

 

[oldmax]

Hi

Am Rande: Kann mir einer ne gute ausführliche Lektüre dafür empfehlen?
Mir ist dem Beitrag von oldmax nicht so recht anfreunden... (nimms nicht persönlich )

Neee, nehm ich nicht, ich kenne meine Schwächen. Aber diese findest du unter Umständen auch in teuren Büchern. Ich hab mal zur Zeit des 286ger eine Info gesucht, wie die serielle und parallele Schnitstelle per Interrupt angesprochen wird. Da man in den Bücherläden in der Stadt nicht stundenlang Bücher lesen kann, hab ich in das Inhaltsverzeichnis geschaut. Ja, Interrupt... kein Problem.... Während Grafik und anderer Kram hunderte von Seiten füllten, stand bei der Erklärung zum interrupt: "Das geht ganz einfach" und Punkt. Erst im 3. 100 DM Buch bin ich dann auf die entscheidenden 2 Seiten gestoßen.
Das Problem ist halt, wo der Schreiber seinen Schwerpunkt gesetzt hat. Aus diesem Grunde steht auch folgender Satz:

Wenn dann noch Fragen sind, hier wird dir geholfen.

Also, einen guten Start im neuen Jahr.
Gruß oldmax

 

[Enloo]

Nun generell ist es im SPI-Mode nicht "schwieriger" ein GLCD anzusteuern, als im "normalen" 8Bit-Mode.
Es kommt wie immer auf das Display und den Controller an.....

Das OLED von Dirk ist aber kein "Standard" für SPI-Displays, weil es einfach MEHR ist als nur ein farbiges GLCD!
Das OLED hat einen internen Speicher in dem du gleich mehrere Font-Dateien und Grafiken direkt ablegen kannst.
Das kann sonst kein Displaymodul von sich behaupten.
Du sendest dann also per SPI nur noch "Positions- & Farbangaben" und schon werden Linien, Vierecke, Kreise, Texte, Bilder usw. vom Display selbstständig dargestellt.
Dies ist auch der Grund, warum sich Dirk`s OLED-Display weder technisch noch preislich sich direkt mit anderen fabigen GLCD`s (und OLED`s) vergleichen lässt.
Die anderen Display`s sind eben einfach nur Anzeigen...... ohne besondere Intelligenz und Speicher.

Du kannst dir das ganze ja HIER mal durchlesen.
Dort habe ich beschrieben, wie die Komunikation via SPI mit dem Display funktioniert und welche Besonderheiten es hat.
Vielleicht interessierst du dich dann ja doch dafür.

Dann werd ich vorerst, wie schon gesagt…

Also dann werd ich mich mal nach einem anderen µC für das Display umsehen …

35€ sind ja dann doch immerhin ein paar € mehr als ca. 2-3 für nen neuen Chip

@ oldmax

Neee, nehm ich nicht, ich kenne meine Schwächen.

puh… :to_pick_ones_nose3:

Aber diese findest du unter Umständen auch in teuren Büchern. Ich hab mal zur Zeit des 286ger eine Info gesucht, wie die serielle und parallele Schnitstelle per Interrupt angesprochen wird. Da man in den Bücherläden in der Stadt nicht stundenlang Bücher lesen kann, hab ich in das Inhaltsverzeichnis geschaut. Ja, Interrupt... kein Problem.... Während Grafik und anderer Kram hunderte von Seiten füllten, stand bei der Erklärung zum interrupt: "Das geht ganz einfach" und Punkt. Erst im 3. 100 DM Buch bin ich dann auf die entscheidenden 2 Seiten gestoßen.

Naja zum Glück gibt es ja noch meinen Freund und Helfer Google
Buch wäre zwar schöner gewesen weil mans halt mit aufs Klo und so nehmen kann, aber wenn da auch oft so viele Lücken sind…

Also, einen guten Start im neuen Jahr.

Von mir auch nen guten Rutsch

MfG Enloo