TinyI2C_LCD

[pylon]

Das ist definitiv falsch mit dem 4.7k, da gehört ein 1k rein.

Wieso ist das so falsch? Nach der Theorie sollte der grössere Widerstand eine bessere Glättung bringen und somit auch besser funktionieren. Was ich nirgends finden kann, ist der Stromverbrauch dieser Leitung. An einigen Orten wird aber empfohlen, einen 470kΩ-Widerstand und einen 1µF-Kondensator zu nehmen.
Der Beitrag, der das am saubersten dokumentiert, will aber sogar einen Transistor, 3 Widerstände und einen Kondensator, wobei ich auch ähnliche Schaltungen ohne den Transistor gefunden habe. Wenn wirklich nur die Spannung entscheidend wäre und praktisch kein Strom fliesst, sollte es eigentlich besser funktionieren, je grösser der Widerstand gewählt wird.

Hier (http://www.electronics-lab.com/blog/?p=9946) wird sogar komplett auf den Widerstand verzichtet und nur ein Kondensator (dafür ein deutlich grösserer) genommen.

Nach der Formel in diesem Thread (http://www.mikrocontroller.net/topic/213575) sind unsere Werte für R und C sowieso viel zu klein, um einen vernünftigen Glättungsfaktor zu erhalten.

[boxtec-support]

Mit "ist falsch" meinte ich, dass mein Original einen 1K hat soweit ich das ablesen kann und das war ein ziemliche Probierei, mit Rechnen kam ich auf Werte die auf dem Breadboard nix brachten.

Ich hatte bei Low-pass Filtern einen Fensterplatz, aber die Formeln funktionieren IMHO nur solange ein sehr hoher Widerstand als Last anliegt. Nichtsdestotrotz geb ich Dir recht, bei hohem - 100% duty cycle sollte 1k oder 4.7k keine Rolle mehr spielen und es sollte genügen Spannung anliegen, damit der Kontrast angesteuert wird.
Ich muss jetzt mal zur Sicherheit nochmals eines mit 1K aufbauen, aber ich befürchte ich hab noch was anderes im PCB vergurkt, nur wo?

[boxtec-support]

Ich dreh hier langsam im Leeren... Meine tinyLCD_I2C Firmware kompiliert zwar aber läuft einfach nicht mehr richtig - auch auf dem v0.9 Prototypen, ich hab wohl irgendwo noch Leichen rumliegen, die ich auch mit einer neuen Arduino Installation noch habe.
Folgendes hab ich gemacht:
- git repo ausgecheckt
- neue Arduino IDE 1.0.5 entpackt
- libraries/TinyWireS aus dem checkout ins library Verzeichnis kopiert
- attiny cores von http://code.google.com/p/arduino-tiny/ installiert
- src/tinyLCD_I2C nach library kopier
- ATtiny Code aus irmware/tinyLCD_I2C/ auf den ATtiny geladen
- examples/tinyLCD_I2C_Test/tinyLCD_I2C_Test.ino auf einen Uno geladen
- I2C Verbindung erstellt

Was ich auch mache, das Display bleibt blank. Die Arduino Seite kann ich ausschliessen, ich hab mit einem Leonardo und mit einem Uno getestet und beide lösen an meinem ersten Prototypen Anzeigen aus, also I2C Daten gehen raus.
Auch das Display und der ATtiny sind in Ordnung, wenn ich z.B. testLCD(); unkommentiere wird das Display wunderbar angesteuert.

Bin grad ratlos, ich hatte den Verdacht, dass TinyWireS noch in einer anderen Version rumgammelt, aber ich finde nix.

Bzgl. dem Kontrastproblem glaube ich, dass an der neuen Version durch den höheren Widerstand immer zuviel Spannung anliegt. Soweit ich mich entsinne sind 0.5 - 1V etwa ideal Kontrasteinstellungen, darüber sieht man nix mehr. Versuch mal das Display etwas schräg zu halten, vielleicht siehst Du dann die Anzeige. Ansonsten würde ich mal versuchen einen 1K Widerstand parallel mit z.B. Krokoklemmen an den 4.7k zu hängen, das gibt dann etwas unter 1k (ca. 825R), ich wette dann klappts mit dem Kontrast.

Ich such jetzt noch ein bisschen und dann geh ich an eine jungfräuliche Maschine und installiere nochmals alles in der Hoffnung das es dann tut und vor allem dass ich rausfinde was ich zurzeit falsch mache.

Update: Könntest Du ev. mal ein gesundes HEX File der tinyLCD_I2C Firmware posten ? Damit ich weiss, dass Board sicher ok ist.

[pylon]

git repo ausgecheckt

Hast Du den master oder meinen development branch (SPI) ausgecheckt? Mit dem master ging's bei mir problemlos (mit dem alten Board).

Ich habe ein Kompilat des aktuellen Masters angehängt, so wie er bei mir läuft.

Ich habe mich so organisiert, dass ich ein Verzeichnis habe, das die Sandbox des git-Repos enthält. aus der IDE zeigen dann symbolic Links auf die Bibliotheks- bzw. Sketch-Verzeichnisse. So kann ich in git jeweils nur die checkouts ändern und einen beliebigen Branch kompilieren.

Ich werde voraussichtlich morgen mal mit verschiedenen Widerständen/Kondensatoren auf den neuen Boards Versuche machen.
Softwaremässig versuche ich aus dem TinyWireS ein TinyUSIS zu machen, also eine Bibliothek, die sowohl I2C als auch SPI mit der USI-Hardware kann.

[boxtec-support]

Hast Du den master oder meinen development branch (SPI) ausgecheckt? Mit dem master ging's bei mir problemlos (mit dem alten Board).

Ich habe ein Kompilat des aktuellen Masters angehängt, so wie er bei mir läuft.

Vielen Dank. Soweit sind meine git Kenntnisse noch nicht (was war falsch an CVS und SVN *argh*), um sicherzugehen, hab ich jeweils alles neu mit folgendem Befehl ausgecheckt, ich denke damit krieg ich den Master branch:

Code: [Select]

git clone https://github.com/boxtec/tinyLCD_I2C
Das Hex File hab ich mit folgendem Befehl auf mein altes Board gebrannt:

Code: [Select]

/home/boxtec/apps/arduino-1.0.5/hardware/tools/avrdude -C/home/boxtec/apps/arduino-1.0.5/hardware/tools/avrdude.conf -v -v -v -v -pattiny84 -cusbtiny -Uflash:w:/tmp/tinyLCD_I2C-1.0.hexHat anstandslos geflasht und geprüft, aber keine Änderung, nach x-mal resetten hab ich irgendwann mal das "W", mutmasslich vom lcd.print("HELLO - WORLD!"); erhalten, sonst nix. Mein Uralt-Prototyp zeigt mir aber, dass Kommandos auf dem I2C Bus kommen.
Ich hab jetzt noch zwei Dinge im Verdacht:

• Ich habe 3 defekte ATtiny84 auf dem Tisch die sich zwar problemlos programmieren lassen und auch auf allen I/O Pins die am LCD hängen tun, aber bei der I2C Kommunikation einen Schuss haben. Wär komisch, aber werd ich morgen mit einem Raubzug durch das Boxtec IC Lager ausschliessen.
• Meine Arduino Library tinyLCD_I2C ist matsch resp. eine falsche Version. Es ist wirklich schade, das git keine Macros wie z.B. cvs erlaubt, "Ich arbeite mit 1.23" wär dann ziemlich eindeutig. So schlecht kann git nicht sein, ich bin vermutlich einfach noch zu fest in der Denkwelt von cvs gefangen.
  

Auch mit und ohne Pullups auf dem Bus macht keinen Unterschied.

Ich hatte auch den Verdacht, dass durch den testloop für den Kontrast die Kontrastspannung zu hoch liegen bleibt und zwar alles angezeigt wird, ich aber nichts sehe. Das hab ich aber auch durch entfernen der beiden loops testweise ausgeschlossen.

Wäre es ev. möglich auch ein Hex Deines Arduino Testcodes zu bekommen ? Das würde mir min. sagen ob das Problem in Software oder Hardware liegt. Ev. ist ja wirklich einfach mein Board oder meine ATtinies defekt. Immerhin weiss ich dann in welche Richtung meine Reise geht.

[pylon]

was war falsch an CVS und SVN *argh*

Branching und Merging war viel mühsamer und komplizierter. Das Zusammenfassen von Commits war mit CVS nicht, mit SVN nur sehr risikoreich möglich. Offline-Arbeiten war mit beiden alten Versionverwaltungen praktisch nicht möglich. Git macht also durchaus Sinn :-).

ich denke damit krieg ich den Master branch

Ja, solltest Du. Mit "git status" kannst Du das jederzeit überprüfen.

Es ist wirklich schade, das git keine Macros wie z.B. cvs erlaubt, "Ich arbeite mit 1.23" wär dann ziemlich eindeutig.

Welche Art Macros meinst Du? Tags? Ich habe zwar nicht lange mit CVS gearbeitet, aber Makros, die automatisch Versionen ausgeben, sind mir nicht bekannt. Bei git gibt's die Hash-Codes, damit der Stand klar ist.

Auch mit und ohne Pullups auf dem Bus macht keinen Unterschied.

Ich habe meine Tests immer nur mit externen Pullups (4k7) gemacht.

Wäre es ev. möglich auch ein Hex Deines Arduino Testcodes zu bekommen ?

Ist im Anhang.

Mein 0.9-Board ist mit der Backlight-Option verändert (Pin 6 des Tiny mittels Widerstand an L+), obwohl ich nicht davon ausgehe, dass das einen Unterschied macht.

[pylon]

Ich glaube, ich habe den Board-Fehler gefunden. RS vom Display-Interface geht nach PB0 anstatt PA7 (beim Board 0.9). Das wäre eigentlich richtig, da beim alten Board (mit meinem Mod) PA7 (D3) doppelt belegt war.

Ersetzen von

Code: [Select]

LiquidCrystal lcd(3, 1, 9, 8, 7, 5);
durch

Code: [Select]

LiquidCrystal lcd(0, 1, 9, 8, 7, 5);
bewirkte bei mir ein Funktionieren der neuen Boards, vorausgesetzt, der Widerstand wurde auf 1kΩ ersetzt. Ich habe dann den Kondensator noch durch ein 10µF ersetzt, jetzt habe ich auch kein Flackern mehr, wenn ich den Kontrastwert verändere.

[MathiasW]

Salut,

ich habe die Platine durchgemessen und der einzige Unterschied ist diese Leitung, welche früher an PA7 ging und nun an PB0 liegt. Das entspricht auch der Fritzingzeichung vom 16.7. auf der der SMD Entwurf basiert. Somit ist diese Pinänderung bei beiden Boards gleich.
Ciao, Mathias

[boxtec_admin]

Ich glaube, ich habe den Board-Fehler gefunden. RS vom Display-Interface geht nach PB0 anstatt PA7 (beim Board 0.9). Das wäre eigentlich richtig, da beim alten Board (mit meinem Mod) PA7 (D3) doppelt belegt war.

Stimmt - sorry, wir mussten einen PWM Pin freikriegen, darum hab ich den gewechselt und wie Mathias sagt, hat er dann diesen Stand auf SMD portiert. Leider hab ich das nirgends dokumentiert und das Schema im Fritzing ist da ja nicht wirklich übersichtlich.

Danke für das Hex, jetzt weiss ich wenistens das mein 0.9 Board defekt ist - das ist zwar auch sehr mirakulös, aber ist mir lieber als wenn ich zwei einfach Sketche im x-ten Anlauf nicht kompiliert kriege. Auch ein neuer ATtiny mit der Firmware bepflanzt wollte nichts wissen/anzeigen, genausowenig wie ein anderes Uno Board...

Ich geh dann mal zurück an die Lötstation und mach mir nochmals ein neues 0.9