Bascom I2C : LCD ( auch Arduino ) mit PCF8574 OHNE LIB betreiben

[elektroniklaie]

Hi,
trotz des Compilier-Fehlers gibt's eine HEX-Datei. Und: -ratet mal: Das LCD funktioniert!
Die Fehlermeldung muss dann ja wohl ein Bascom-Fehler sein.
Danke an alle. Gruss, elektroniklaie

 

[dino03]

Hallo,

also ich hab mir die 2.0.7.6 jetzt auch mal installiert (bis jetzt nur 2.0.7.5 gehabt) und ich kann den Fehler nachvollziehen. Mal sehen wo da der Hase begraben ist (oder wie heißt das?)

EDIT: Wenn ich beim Hauptprogramm hinten zusätzliche Leerzeilen anfüge, dann wandert die gemeldete Zeilennummer auch nach hinten. Alles sehr komisch

EDIT2: Der Fehler taucht auch bei 2.0.7.5 und 2.0.7.3 auf. Ich habe allerdings jedesmal nur Syntax-Check gemacht.

@Cassio: Könntest du das eventuell mal bei deiner Version mit deinem Code nachvollziehen?

Gruß
Dino

 

[LotadaC]

Mysteriös...
Hab mal den Rechner hochgefahren, den Code (als neue Datei) und die beiden Dateien in 'nen Ordner, und das ganze compiliert...
mein Bascom (2.0.7.3.001) kennt den Mega8A noch nicht. Also mal das "A" weg ... derselbe Fehler.
Doppelklick auf die Fehlermelung scheint keinen Effekt zu haben.
Und die Zeile giebts da ja gar nicht...
Hmm...
Als letztes wird die Datei mit den Subroutinen inkludiert...
include auskommentiert, und den Quelltext direkt eingefügt...
dieselbe Fehlermeldung, jetzt in der letzten Zeile (Return) - außerdem kann man jetzt mit einem Doppelklick auf die Fehlermeldung dahin springen
Hmm...
dasselbe mal mit der Declare-Datei versucht...

Jetzt compilierts fehlerfrei!
(Aber 'ne Erklärung hab ich auch erstmal nicht... was macht "$lib "i2c_twi.lbx""?)

Nachtrag: Bei mir reichts, wenn man die declares mit rein nimmt - die subs selbst können extern bleiben...

jetzt seid Ihr drann...

 

[riesen]

Hallo

Die I2C_TWI.LIB benutzt die im Controller vorhandene Hardware,
um den I2C-Bus zu steuern. Ohne LIB erledigt dies Bascom in
Software, dafür kann man jeden Portpin für die I2C-Signale
verwenden. Ich benutze I2C für die LCD-Ansteuerung ohne LIB,
das reicht von der Geschwindigkeit her völlig aus. Die LIB habe
ich mal mit Multimasters benutzt, nur diese erkennt Sende-
Kollisionen.

Gruss
Thomas

 

[Cassio]

Das komische ist, dass DDRA (PortA) angemeckert wird obwohl der ATmega8a das PortA gar nicht hat.

@Cassio: Könntest du das eventuell mal bei deiner Version mit deinem Code nachvollziehen?

Hallo zusammen!

Na nu, da ist man einen Abend mal feiern und nicht online und schon gerät alles aus den Fugen.
Dabei ist die Lösung doch gaaaanz einfach.


Der "Fehler" liegt bei "elektroniklaie" mit Sicherheit hier:
(Beispielbild !)


Standdardmäßig ist in den BASCOM-Optionen für die I2C-Ports immer:
PORTA.x
PORTA.y
eingetragen!

Er muss also wenigstens einmal die Port-Angabe passend zum AVR geändert haben und schon meckert BASCOM auch nicht mehr.


Das Programm funktioniert vermutlich deshalb trotzdem, weil im Programm dann durch die LIB die Hardwarepins des AVR´s benutzt werden sollen:

' I2C-Hardware-Config
$lib "i2c_twi.lbx"

Also keine Panik....
alles ist gut !


Grüße,
Cassio

 

[dino03]

Hallo,

Der "Fehler" liegt bei "elektroniklaie" mit Sicherheit hier:
(Beispielbild !)
Anhang anzeigen 5546

Standdardmäßig ist in den BASCOM-Optionen für die I2C-Ports immer:
PORTA.x
PARTA.y
eingetragen!

Er muss also wenigstens einmal die Port-Angabe passend zum AVR geändert haben und schon meckert BASCOM auch nicht mehr.

so eine Sch... da stand bei mir für I2C und 1Wire auch noch was vom PortA drin. Geändert auf Pins vom PortB und es ist Ruhe

Wer denkt sich so einen Mist aus? Da soll mal einer drauf kommen das die Einstellung auch noch angesehen werden auch wenn man sie im Programm garnicht verwendet.

Gruß
Dino

 

[LotadaC]

Der Witz ist, daß ich da gestern sogar nach den LCD-Einstellungen geschaut hatte, den Reiter mit den Kommunikationsschnittstellen hab ich irgendwie ignoriert. Geistige Umnachtung zu fortgeschrittener Stunde oder so...

Dino... wir sind halt Assembler-belastet - was Du da nicht einbindest, gibts eben nicht.
Trotzdem ist das doch ein Bug, oder?
Normalerweise spielen die defaults doch keine Rolle, solange keine Funktion verwendet wird, die diese benutzt - klar.
Ok, jetzt wird TWI verwendet, aber über eine eigene lib, die die korrekten Ports verwendet.
Hmm...
Das muß irgendwas mit der Suchreihenfolge der/in den Bibliotheken zu tun haben.
Weil, wenn man die externen declares in stattdessen direkt in den Code nimmt, gehts ja auch ohne Fehlermeldung - trotz der falschen defaults...

P.S.: Ich ärger mich bezüglich Bonzes NEC-Code-Topic auch grad mal wieder mit dem Bascom-Simulator rum. Irgendwie hat readeeprom da keinen Effekt. Schreib ich sicher nachher noch was. Wenn ich'n LA und'n ZIF-Sockel für den SOIC-Tiny2313 hätte (*Augenbraue-zu-Dirk-hochzieh*), würde ich das in Hardware testen...

 

[elektroniklaie]

Da soll mal einer drauf kommen das die Einstellung auch noch angesehen werden auch wenn man sie im Programm garnicht verwendet.

Ich war schon drauf gekommen, habe aber in dem Options-Fenster nur nach rechts geschaut und da steht nur PortB...

Ich habe mich immer gefragt, wie die Options den Code beeinflussen. Z.B. wenn kein LCD benutzt wird, ob dann die Options doch was reintun (Resourcenverschwendung?), bzw. unter welchen Umständen sie es tun. Jedenfalls sehe ich es auch als Bug an, wenn da so etwas wie oben beschrieben passiert, noch dazu dass trotz der Fehlermeldung das Hex file erzeugt wird.
Gruss, elektroniklaie

 

[Cassio]

Hallo zusammen!

Ich mag es immer nicht, wenn man gleich nach einem Bug schreit.....
weil ich es nicht beurteilen kann.
Es wäre besser, sich mit dem Phänomen an das MCS-Forum zu wenden.


Es war eigentlich immer so, dass man ein I2CINIT nur ausführen musste, wenn man NICHT die Hardwarepins verwendet.
Vielleicht ist das inzwischen geändert worden und man sollte es immer mit einbinden?
Keine Ahnung, ob das etwas nützen würde.


Generell werden die Einstellungen in den Optionen überschrieben (oder ignoriert), wenn man im Programm etwas anderes angibt, oder eine Funktion gar nicht benötigt.
Lediglich beim I2C muss man einmal die Angabe in den Options geändert haben und dann ist Ruhe.


Wie heißt es aber immer so schön...
Manche "Fehler" passieren einem immer nur einmal.


Grüße,
Cassio

 

[elektroniklaie]

Hallo Cassio,
Ihr seid ja wirklich fix hier! Eigentlich wollte ich das I2C-LCD von Pollin nur deswegen benutzen, weil ich an (allen) ATtinys nicht genug Beine habe, um auch ein Parallel-LCD zu betreiben.
Nachdem nun Dein Code läuft, bemerke ich aber mit Schrecken (siehe Results-Fenster), dass selbst beim Mega8 nur noch 600 bytes frei sind. Damit geht's nicht auf 'nem Attiny -(ausser dem 1634, aber bei dem fehlt's mir an anderer Stelle).
Meine Frage: Ist in Deinem Code einiges an Luft drin, die man für meinen Zweck herauslassen könnte? Ich will nämlich nur einen (veränderlichen) Wert anzeigen, z.B. "30.2", wenn's geht, ziemlich grosse Ziffern.
Gruss, elektroniklaie

 

[Cassio]

Ist in Deinem Code einiges an Luft drin, die man für meinen Zweck herauslassen könnte? Ich will nämlich nur einen (veränderlichen) Wert anzeigen

Hallo!

Also der Hauptteil an Speicher geht wohl generell durch die I2C-Technik drauf.
Mein Code dürfte da nicht das Meiste ausmachen.

Vielleicht könnte man den Code für dein Vorhaben noch etwas einkürzen und Variablen weglassen bzw. Arrays verkleinern, aber ob das soooo viel bringt?

Es steht dir natürlich frei dies einmal zu probieren.

Wert anzeigen, z.B. "30.2", wenn's geht, ziemlich grosse Ziffern.

Das verstehe ich jetzt nicht.
Wie meinst du das, mit den "großen" Ziffern?

Da es hier nur um die Ansteuerung eines Charakter-LCD geht, ist die Schriftgröße natürlich baulich festgelegt.
Du kannst die Schrift also per Software nicht verändern!




Die einzige Idee die mir momentan in den Sinn kommt wäre ein GLCD als Charakter-LCD am I2C-Bus zu verwenden.
Damit hättest du die Vorteile der verschiedenen Schriftgrößen und einen kleineren Speicherverbrauch.
Wirf doch mal einen Blick in den Thread für GLCD als C-LCD verwenden.


Grüße,
Cassio

 

[dino03]

Hi LotadaC,

P.S.: Ich ärger mich bezüglich Bonzes NEC-Code-Topic auch grad mal wieder mit dem Bascom-Simulator rum. Irgendwie hat readeeprom da keinen Effekt. Schreib ich sicher nachher noch was. Wenn ich'n LA und'n ZIF-Sockel für den SOIC-Tiny2313 hätte (*Augenbraue-zu-Dirk-hochzieh*), würde ich das in Hardware testen...

ich hab für diese Zwecke von Reichelt die Challenger-Clips besorgt. Aber setz dich erstmal hin bevor du den Preis ansiehst Mit denen kannst du auch SOIC-ICs und teilweise auch noch TQFPs mit 0,8mm Raster kontaktieren.

Gruß
Dino

 

[elektroniklaie]

Danke, Cassio

Da es hier nur um die Ansteuerung eines Charakter-LCD geht, ist die Schriftgröße natürlich baulich festgelegt.
Du kannst die Schrift also per Software nicht verändern!

Das hatte ich nicht bedacht. Die Charaktergenerator-Programme sind wohl nur für die GLCDs.

Aber das mit dem Speicherverbrauch ist leider der Show-Stopper. Also werde ich wohl einen separaten Controller brauchen und dem die Werte seriell zuschicken.

Ich habe mal vor längerem bei Pollin zwei "Rapistan" serielle LCDs gekauft (sind schön gross, gibt's aber nicht mehr). Hat hier schon jemand so ein Ding am Laufen gehabt?
Gruss, elektroniklaie

 

[Cassio]

Hallo!

Wenn du sowieso einen separaten Controller benötigst, dann könntest du ja auch die I2C-GLCD-Variante nehmen.
So hast du gleichzeitig auch noch mehr Platz zum Darstellen.



Das serielle Display von Pollin kenne ich vermutlich nicht.....
aber dafür ist hier auch nicht der richtige Thread.


Eröffne dafür doch bitte ein neues Thema (z.B. im Bereich Hardware, oder Software/LED+LCD) und stelle dort mal das Datenblatt und ein Foto ein.
Dort können wir uns das dann ja mal ansehen.


Grüße,
Cassio

 

[adelinde]

Hartware TWI bei Atmega328P

Hallo Cassio,
Hallo Forum,

herzlichen Dank erst mal an Casio für LCD Treiber.
Ich experimentiere gerade etwas damit herum. Ich habe zum Testen eines von Pollien 16x2 und eines von Arduino 20x4 an eine Atmel 128 getestet und ohne große Schwierigkeiten zum laufen gebracht. (beim Aruino musste ich die Konstanten für Hgb ein und aus tauschen)

Nun wollte ich das Ganze auf einem Atmega328P testen und bekomme mit der Zeile:
$lib "i2c_twi.lbx" folgende Fehlermeldung:

Unknown Statement [.EQU not found for: DDRA] .....

Mit der Software TWI dagegen läuft es Fehlerfrei.

Kann man da was machen?

Liebe Grüße
Siggi

 

[dino03]

Hi Siggi,

Nun wollte ich das Ganze auf einem Atmega328P testen und bekomme mit der Zeile:
$lib "i2c_twi.lbx" folgende Fehlermeldung:

Unknown Statement [.EQU not found for: DDRA] .....

Mit der Software TWI dagegen läuft es Fehlerfrei.

das hatten wir hier letztens schonmal. Das liegt an Bascom.

Geh mal ins Menü:
Options >> Compiler >> Chip

Dann stell mal bei dem Reiter I2C/SPI/1Wire die Pins die auf PortA.irgendwas gehen auf PortB.irgendwas um.

Die Angaben werden zwar im Programm selber definiert aber Bascom sieht sich trotzdem noch die Angaben aus dem Menü an und spuckt dann Fehlermeldungen aus.

Gruß
Dino

 

[adelinde]

Hi Dino,

super, das war's.

Herzlichen Dank

 

[joho63]

DefLcdChar?

Hallo!
Ich lese schon geraume Zeit sehr interessiert in diesem Forum mit und habe schon einiges gelernt.
Für einen Anfänger wie mich eine Fundgrube!
Hab mich auch mal registriert.
Aber jetzt hab ich eine Frage.
Dieser Thread ist ja soweit abgeschlossen, es gibt jetzt Routinen für jedes exotische LCD.
Man braucht nur noch das passende rauszusuchen.
Mein Dank geht an alle Beteiligten!
Ich vermisse nur die Lösung für selbstdefinierte Zeichen.
Hab ich was übersehen, oder ist das untergegangen?
Joachim

 

[Cassio]

Hallo Joachim!

Willkommen im AVR-Praxis Forum!

Wie du selber schon bemerkt hast, ist dieser Thread etwas älter und es geht hier nicht unbedingt um die LCD`s sondern eher um die Ansteuerung der LCD`s via TWI I/O-Expander.
Da es verschiedene Möglichkeiten und fertige Platinen dafür gibt, hat sich hier quasi eine kleine "Sammlung" ergeben.

Ich selber habe die Ansteuerungen nicht mehr weiterentwickelt und darum sind die "DEFCHAR" auf der Strecke geblieben.


Der User "Riesen" hat aber meines Wissens nach dafür etwas programmiert.
Da seine Codemanipulation alle auf Basis meiner Ansteuerungen erfolgte, sollte es also keine Probleme mit seinem Programmcode geben.

Benutze einfach noch mal in die Suche des Forums, da sollte sich etwas finden lassen.


Grüße,
Cassio

 

[riesen]

Hallo Joachim

Wie Cassio erwähnte, habe ich da eine Lösung geschrieben. Das Prinzip meines Codes
ist zwar gleich wie bei Cassio, aber um eine universeele Ansteuerung zu ermöglichen,
wurde der Code doch neu entwickelt. Den Thread findest du hier:

http://www.avr-praxis.de/forum/show...-(inkl-DEFLCDCHAR)-ohne-LIB&highlight=pcf8574

Er wird rege eingesetzt, an Verbesserungsvoschlägen bin ich aber immer interessiert...

Viel Spass wünscht
Thomas