boxtec Forum
Electronics => PCB Design => : boxtec-support June 25, 2013, 07:14:11 PM
-
Da möchte ich doch auch mitmachen und meinen Versuch ein I2C LCD Backpack auf Basis des ATtiny84 zu erstellen zeigen.
Funktioniert soweit alles wie gewünscht, nur hab ich noch das Problem mit meiner Library, dass alle paar dutzend Zeichen einfach eins verloren geht.
Wer Interesse hat an der Library mitzuhelfen, dem stelle ich gerne ein Kit zur Verfügung.
-
Ich wäre interessiert, daran mitzuarbeiten. Wäre mein erstes ATtiny-Projekt, aber daran soll's nicht scheitern.
-
Super, danke für das Interesse.
Ein Kit mit allen benötigten Bauteilen + PCB sowie ein 1602 Display geht am Montag (könnte eng werden) oder spätestens Dienstag auf die Post.
-
Salut,
ich hätte auch Lust, das Problem anzugehen. LCD ist vorhanden, so dass ich nur das PCB und die Bauteile bräuchte.
Ciao, Mathias
-
Es hat heute leider nicht auf die Post gerreicht, aber die beiden Kits (eines mit, eines ohne Display) liegen verpackt bereit und gehen morgen raus.
@Mathias: Nur zur Info, Deines ist als Geschenk mit einstelligem Wert deklariert, geht also hoffentlich gaaanz flink durch den Zoll...
Ich werde in der Zwischenzeit noch den bisherigen Code aufräumen und eine kleine Beschreibung zum Board machen obwohl es eigentlich soweit selbsterklärend sein sollte.
-
Hier wie versprochen der bisherige etwas chaotische Testcode:
tinyLCD_I2C.ino (http://forum.boxtec.ch/index.php?action=dlattach;topic=2225.0;attach=517) - die Firmware für den ATtiny84
tinyLCD_I2C.tgz (http://forum.boxtec.ch/index.php?action=dlattach;topic=2225.0;attach=518) - Library für Arduino (mehr oder weniger aufbauend auf einer Kopie von der LCDi2c Library (http://playground.arduino.cc//Code/LCDi2c))
Nur wenige Funktionen sind bisher ausimplementiert (scrollen etc.) wobei dies mehrheitlich darauf rausläuft einen 1byte Code zu vereinbaren der als Steuersequenz geschickt wird und auf ATtiny Seite wiederum in den entsprechenden Funktionsaufruf für die dort verwendete Standard LCD Lib übersetzt zu werden (zurzeit Funktion commandByte mit switch-case).
Die Idee ist, dass die Library durch Ersetzen der Initialisierungszeile ein drop-in replacement für die Standard LCD Lib ist.
Hier noch ein kurzer Test für einen Arduino I2C Master der das TinyI2C_LCD ansteuert:
#include <Wire.h>
#include <tinyLCD_I2C.h>
tinyLCD_I2C lcd(0x50,16,2);
float vdd;
void setup()
{
lcd.init(); // initialize the lcd
//lcd.backlight(); // not implemented yet
delay(1);
lcd.print("HELLO - WORLD!");
delay(1200);
lcd.setCursor(0,1);
lcd.print("B-O-X-T-E-C-1-3");
delay(1200);
lcd.showFirmware();
delay(1500);
lcd.clear();
lcd.print("Uptime now (us):");
}
void loop() {
lcd.setCursor(0,1);
lcd.print(millis()/1);
lcd.print(" us");
delay(10);
}
Dies funktioniert soweit nun auch ganz gut, bis darauf, dass nach einigen Sekunden, teilweise auch Minuten einzelne Zeichen unterwegs verloren gehen, wobei ich bisher nicht rausgefunden habe ob der Buffer überöläuft und die Zeichen zu langsam abegholt werden oder das auf der Leitung passiert etc..
Zusammenbau:
- Anbei noch ein Foto mit dem aufgebauten Kit, ich empfehle am Board female Headers und am Display male Headers anzubringen, dann kann das Backpack schön aufgesteckt werden
- Gegenüber dem angefügten Schema fehlt auf Eurem Prototyp R3, dieser ist für die Steuerung der Hintergrundbeleuchtung vorgesehen und ist erst vor kurzem draufgekommen, zurzeit ist das Hintergrundlicht fix an.
- Ansonsten denke ich sollte der Zusammenbau recht trivial sein mithilfe der Beschriftung, nur als Hinweis dies: Alle Komponenten auf die bedruckte Seite (Silkscreen) ausser den Header (m oder f) der kommt auf die Rückseite
(http://forum.boxtec.ch/index.php?action=dlattach;topic=2225.0;attach=523;image)
Ich prüfe zurzeit ein öffentliches Source Code Repository aufschalten. Ist Git da für alle ok ?
-
Erstmal vielen Dank, das Kit war heute in der Post.
Git ist für mich ideal.
Beim ersten Überfliegen des Codes ist mir aufgefallen, dass Du die Commands im Vergleich zum LiquidCrystal_I2C umdefiniert hast. Bei der jetzigen Definition kriegst Du aber Probleme, da es Überschneidungen gibt. Der Command muss in den oberen 4 Bits definiert sein, die unteren 4 Bits sind für die Optionen reserviert. Kann ich das wieder zurückdefinieren?
-
Danke für die Rückmeldung. Freut mich, dass das alles geklappt hat.
Bzgl. der Kommando Defintionen zurückdefinieren: Auf jeden Fall, ich wollte da schnelle Resultate und hab mal eben schnell mangels besseres Wissen ein paar "aus dem Stegreif" definiert.
Update: Ich habe heute gitlab (http://gitlab.org/) extensiv getestet, da ich es für diesen Zweck vorgesehen hatte. Ich habs aber nicht geschafft einen lesenden Zugang für anonymen Zugriff hinzukriegen und ich glaub, das wär schon noch gut.
Seid Ihr einverstanden wenn ich ein Projekt auf github eröffne ?
-
Seid Ihr einverstanden wenn ich ein Projekt auf github eröffne ?
Auf GitHub habe ich schon ein Konto (pylonsoft), von mir aus also ein Go!
-
Salut,
fast die Hälfte aller libs beziehe ich von Github, die OS tools von sunxi (Cubieboard und pcDuino) sind auch da - kein Problem
Ciao, Mathias
-
Ich hab einen Account und auch ein Repo eröffnet:
https://github.com/boxtec/tinyLCD_I2C (https://github.com/boxtec/tinyLCD_I2C)
Als jemand der zeitlebens mit cvs gearbeitet hat und noch heute subversion für das SCM von übermorgen hält könnte es sein, dass ich hin und wieder etwas Hilfe bei der Verwaltung brauche.
Muss ich Euch jetzt als Collaborators zu dem Projekt einladen oder kann da jetzt erst mal jeder commiten ?
-
Salut Christoph,
ich denke, Du musst uns einladen:
You are editing a file in a project you do not have write access to.
We are forking this project for you (if one does not yet exist) to write your proposed changes to.
Submitting a change to this file will write it to a new branch in your fork so you can send a pull request.Meine id ist GastonLagaffe2013
Ciao, Mathias
-
Hallo Mathias,
Danke fürs Testen, ist erledigt, Du bist als Collaborator eingetragen.
Man muss scheinbar Firefox auf WIndows nutzen damit der Add Button Farbe erhält und klickbar wird..
Grüsse - Christoph
-
Hallo Christoph,
könntest Du mich auch noch einladen? Meine ID ist pylonsoft.
Das Display läuft, der ATtiny kann auch Ausgaben darauf machen, aber auf dem I2C-Bus ist bei mir im Moment noch ziemlich Flaute, ich kriege keinen einzigen Ack vom Tiny. Ich suche weiter nach der Ursache.
Ich hätte aber gleich einen Verbesserungsvorschlag: Können wir die I2C-ID in das EEPROM verlagern, dann können wir auch mehrere Displays ansteuern, ein Kommando zum Ändern der ID genügt. Wenn das auch in Eurem Interesse ist, baue ich das mal ein.
-
Muss ich Euch jetzt als Collaborators zu dem Projekt einladen oder kann da jetzt erst mal jeder commiten ?
Typischerweise läuft das anders, nämlich dass sich Interessenten einfach eine eigene Kopie des Projekts “forken”, dann ihre Änderungen zu einem “Pull Request” zusammenfassen & Dir schicken.
-
Hallo Pylon,
Du bist als Collaborator eingeladen.
@microtherion: Danke für den Hinweis, ich selber bin wie gesagt völliger git-N00b. Ich stör mich aber immer dran, wenn ich von einem Projekt 7 Repos finde und nicht recht weiss welches aktuell ist und am Ende den Code vergleichen muss. Ich vermute bei der Anzahl Commiter hier ist das noch etwas Overkill, sehe aber den Sinn durchaus wenn wir von z.B. 5 Hauptentwicklern und 20 freiwilligen reden.
Das mit der I2C Adresse im EEPROM finde ich eine hervorragende Idee. Ich hatte mir lange überlegt einen I/O Pin mit Jumper dazu zu verwenden, aber dann ging der letzte freie für die Hintergrundbeleuchtung drauf und 2 Adressen zur Auswahl wären ja auch nicht übermässig berauschend gewesen.
Bzgl. I2C: In zwei Situation hatte ich solche Probleme:
- Wenn der ISP Programmer noch angeschlossen ist
- Mit 2 Displays auf dem Bus ohne externe Pullups (versuchs mal mit einem 1k-10k Pullup auf dem I2C Bus)
Zwischendurch musste ich auch alles mal stromlos machen und eins nach dem anderen wieder versorgen, gelegentlich hängen die Slaves irgendwo wartenderweise fest und lassen sich nicht mehr anders zu einem Neustart bewegen.
-
Hallo Christoph,
Bzgl. I2C: In zwei Situation hatte ich solche Probleme:
Wenn der ISP Programmer noch angeschlossen ist
Mit 2 Displays auf dem Bus ohne externe Pullups (versuchs mal mit einem 1k-10k Pullup auf dem I2C Bus)
Zwischendurch musste ich auch alles mal stromlos machen und eins nach dem anderen wieder versorgen, gelegentlich hängen die Slaves irgendwo wartenderweise fest und lassen sich nicht mehr anders zu einem Neustart bewegen.
Ich habe das Problem gefunden: der Tiny hatte sich verabschiedet bevor ich auf's Display geschaut hatte. Nachdem ich den Delay im Test-Sketch auf 1 Sek. raufgesetzt hatte, lief er stundenlang durch, ohne die geringsten Probleme zu zeigen.
Ich hatte mir erlaubt, das Projekt in eine File-Struktur zu giessen und im Git-Repo einzuchecken. Die neuste Version erlaubt auch schon die Änderung der Adresse, auch wenn ich das noch nicht getestet habe.
Ich werde versuchen, möglichst viel Code aus dem Interrupt-Handler herauszulösen und in den Loop zu verschieben, damit sollten wir die Race-Condition in den Griff kriegen (hoffe ich zumindest).
-
Hallo Pylon,
Juhu :) super, danke vielmals! Läuft seit 100, 200, 300s ohne Fehler durch.
Ich hab schon am Konzept gezweifelt und bin jetzt sehr erleichtert.
[Update]: Ich hab immer noch gelegentliche "Huster" drin, aber weitaus seltener und weniger vorhersehbar, der eingeschlagene Weg scheint auf jeden Fall das Problem anzugehen.
-
Hallo Christoph,
ich habe noch etwas aufgeräumt, den Code durchgesehen. TinyWireS ist nicht sehr sauber programmiert, einen unschönen Fehler habe ich hier gefixt:
case USI_SLAVE_GET_DATA_AND_SEND_ACK:
// put data into buffer
// Not necessary, but prevents warnings
rxHead = ( rxHead + 1 ) & TWI_RX_BUFFER_MASK;
// check buffer size
if (rxHead == rxTail) {
// overrun
rxHead = (rxHead + TWI_RX_BUFFER_SIZE - 1) & TWI_RX_BUFFER_MASK;
} else {
rxBuf[ rxHead ] = USIDR;
}
// next USI_SLAVE_REQUEST_DATA
overflowState = USI_SLAVE_REQUEST_DATA;
SET_USI_TO_SEND_ACK( );
break;
Das kommt ganz am Schluss von usiTwiSlave.c hin und stellt sicher, dass der Ringbuffer nicht sich selbst überholt. Eigentlich müsste man ein NACK zurückgeben, wenn der interne Buffer voll ist, aber das lassen wir mal für zukünftige Versionen.
Sehr unschön ist auch, dass der onReceive-Handler sowohl aus dem Interrupt-Kontext, als auch aus dem normalen loop()-Kontext aufgerufen wird. Das verhindert eigentlich eine saubere Programmierung. Bei uns ist das aber (im Moment) nicht relevant.
Ich habe auch noch etwas Debugging-Code eingebaut, die Geschwindigkeit etwas hochgeschraubt und festgestellt, dass die "Huster" bei der Übertragung über I2C passieren, der Master kriegt dann auch ein NACK zurück, könnte also die Übertragung nochmals wiederholen. Wie und warum es dazu kommt, ist mir noch nicht ganz klar, das untersuche ich aber noch.
-
Hallo Pylon,
Die Änderung den Buffer auf Überlauf zu prüfen macht absolut Sinn. Ich hab das dem Autor der ursprünglichen TinyWireS Library (brohogan) vorgeschlagen. Aber da dies hier "nur" die Firmware für den ATtiny betrifft würde ich vorschlagen, die modifizierte TinyWireS wird einfach Teil der Firmware und kommt auch ins Repo statt als externes Requirement. Da es eh eine Vielzahl von Forks gibt scheint mir das sinnvoll oder was meinst Du ?
Ich werd mich die nächsten Tage mal daran machen noch die eine oder andere noch fehlende Funktion einzubauen und ebenfalls den neuen Prototypen mit Hintergrundbeleuchtungssteuerung zu bestellen.
Gibts sonst noch Feedback bzgl. des PCBs was man für den nächsten Prototypen berücksichtigen sollte ?
-
Hallo Christoph,
ich nehme an, das Board-Layout, das Du hier im Thread gepostet hast, ist bereits die neuere Version als die, die ich habe (dort ist D10 herausgeführt). Ansonsten habe ich keine Wünsche, aber dieser Pin ist ganz praktisch, damit ich Pulse für den Logic Analyzer generieren kann. Ich greife ihn momentan am Chip ab, aber das ist nicht wirklich "convenient" :).
Ansonsten habe ich momentan keine Verbesserungsvorschläge.
Das Einbauen der TinyWireS-Sourcen macht sicher Sinn. Ich mache das noch und markiere es als Fork. Dann können wir auch die bereits erwähnten Erweiterungen später ohne Probleme anbringen.
-
Ich habe den Grund für die "Huster" gefunden. Der Tiny kommt bei einigen ACK zu spät, SDA nach Masse zu ziehen, was einem NACK entspricht. Ich suche mal im Code von TinyWireS nach der Ursache.
Das Mehrfachsenden habe ich implementiert, seit einer halben Stunde hatte ich kein einziges falsch übertragenes Zeichen mehr.
-
Salut Christoph,
kannst Du die Fritzing Source posten? Ich würde gerne das Design gegenchecken
Ciao, Mathias
-
Ich habe das Problem gelöst. Die Aussetzer traten auf, weil einzelne I2C-Übertragungen vom Tiny ignoriert wurden. Mittels Debug-Pin (D10) konnte ich das Timing nachvollziehen und sah, dass der Start-Condition-Interrupt-Handler erst aufgerufen wird, wenn die Condition schon nicht mehr existiert.
(http://www.linotux.ch/arduino/imgs/race_start_condition.png)
Da dies nur in einigen Fällen eintritt, es aber meist korrekt funktioniert, musste es sich um eine Race-Condition handeln. Der einzig plausible Grund dafür musste der Timer-Interrupt für die millis()-Funktion sein. Mit diesem auskommentiert (in wiring.c), konnte ich keine einzige Fehlübertragung mehr feststellen.
Wir müssten jetzt entscheiden, ob wir die Mehrfachübertragungen in Kauf nehmen oder die Firmware ohne Timer-Interrupt kompilieren wollen.
Edit: Das Zulassen von verschachtelten Interrupts im Millis-Handler genügt auch, damit funktioniert die millis()-Funktion immer noch.
Code-Ausschnitt:
ISR(MILLISTIMER_OVF_vect)
{
sei(); // enable nested interrupts
// copy these to local variables so they can be stored in registers
// (volatile variables must be read from memory on every access)
unsigned long m = millis_timer_millis;
unsigned char f = millis_timer_fract;
-
Sensationell, bestätige, dass die Fehler komplett verschwunden sind (auch nach 30min noch keiner).
Danke auch für die Beschreibung des Analysewegs, das ist sehr hilf- und lehrreich.
Ich bin definitiv der Meinung, dass wenn das Problem so komplett gelöst wird, dies sicherlich besser ist als Mehrfachübertragungen in Kauf zu nehmen. Auch wenn es die Suppe wahrscheinlich in 999 von 1000 Fällen nicht fett macht, dass der Master eine Wiederholung machen muss dreht dieser für die Wiederholung ein paar Cycles mehr.
Aber was wäre der einfachste Weg um die entsprechende ISR Funktion in wiring.c zu überschreiben/ersetzen ?
@Pylon: Das Layout, dass ich hier gepostet habe ist das aktuelle. Ich werde es noch etwas kleiner machen, damit es auch bei sehr kleinen LCD Modulen keinen Überhang gegenüber dem Display gibt.
@Mathias: Re: Fritzing: Ich würds gerne gleich ins git repo einchecken, ist es ok wenn ich es in ein neues Verzeichnis board importiere/commite ?
-
Aber was wäre der einfachste Weg um die entsprechende ISR Funktion in wiring.c zu überschreiben/ersetzen ?
Die in meinem vorherigen Post erwähnte Einfügung von "sei()" im wiring.c des tiny-Subbaums ist die einzige Methode, die mir in den Sinn kommt. Da es nur eine Zeile ist und diese Änderung auch bei anderen Tiny-Projekten keine Probleme bereiten sollte (sofern sie korrekt implementiert sind, also die IRQ-Handler kurz gehalten sind), würde ich es fix dort eintragen.
-
Ok, dann mach ich das als Notiz ins Readme. Wers dann ohne die Änderung baut hat ja noch keine Probleme deswegen aber verliert zwischendurch vielleicht etwas Rechenzeit. Für uns beim Bespielen der ATtiny ist es kein Problem.
Ist das Verzeichnis board für die Designdatei(ein) für Dich ok ?
-
Ist das Verzeichnis board für die Designdatei(ein) für Dich ok ?
Selbstverständlich.
-
Salut,
"board" ist ok für mich. Ich habe das Ganze anhand der Platine in Eagle aufgesetzt und etwas entflochten. Ich möchte auch vorschlagen, die I2C pins so anzuordnen, wie es auf anderen Boards der Fall ist: GND,Vcc,SDA,SCL und Befestigungslöcher (M3) anbringen.
@pylon: Ich bin tief beeindruckt, wie Du das Problem gelöst hast. Ich werde mich wieder der Auslese eines lCCD widmen und gegebenenfalls versuchen, Dich für das Debuggen zu begeistern (lCCD gibt es gratis dazu)
Ciao, Mathias
-
Das Fritzing File ist im Repo.
@pylon: Ich bin tief beeindruckt, wie Du das Problem gelöst hast.
Dem kann ich mich nur anschliessen!
-
Salut,
hier mein erster Versuch in Eagle. Ich habe das board auf 50x23 mm ausgelegt, damit man bei einem 50x50mm Prototyp zwei Boards erhält.
Ciao, Mathias
-
Danke für die Blumen. :)
Auf die Gefahr hin, mich als Banause zu outen: was ist ein lCCD (Google liefert zwar einige Resultate, aber nichts, das ich mit Arduino in Verbindung bringen würde)?
-
Salut Pylon,
lCCD ist ein lineares CCD (Charge Coupling Device). Ich arbeite mit dem ILX511B von Sony und dem TCD1201 von Toshiba. Das Sony sollte leichter auszulesen sein, aber bislang ist es mir nicht gelungen, das lCCD auszulesen. Es scheint immer so zu sein, dass ich nur den ersten Pixel sehe und die Ladung der anderen Pixel nicht durch gereicht werden. Nach einigen enttäuschenden Versuchen habe ich erst einmal einige Wochen davon Abstand genommen, will mich jetzt aber wieder daran wagen
Ciao, Mathias
-
Das wäre also das Lese-Element eines Scanners oder liege ich da falsch?
Vom Sony habe ich schon mal ein Datenblatt gefunden. Scheint mir durchaus machbar und tönt sehr interessant. Welchen AD-Wandler setzt Du denn ein? Den internen des Arduinos? Und als Treiber den empfohlenen 2SA1175?
-
Salut,
ich habe bislang den internen ADC verwendet, diesen aber im fast-ADC Mode betrieben. Da das Signal stark genug war, habe ich es nicht weiter verstärkt. Testweise habe ich den 2SA1175 durch einen pnp-Transistor ersetzt, den ich zur Hand hatte (BC557), was aber kaum einen Effekt hatte.
Aber ich denke, zu dem Thema sollten wir einen eigene Threat öffnen
Ciao, Mathias
-
Noch einmal zu TinyI2C_LCD-Board. Wenn wir den D10-Pin auch beim I2C-Stecker herausführen, könnten wir mit dersselben Hardware eine I2C und eine SPI-Version abdecken. Ich denke, der Aufwand auf dem Board wäre minim und die grössere Flexibilität müsste es wert sein. Was denkt Ihr?
-
Finde ich eine sehr gute Idee, ich kanns aber nicht von der Firmware her beurteilen wie gross der Aufwand ist SPI auch abzudecken, aber Platz im Flash wär definitiv noch genügend verfügbar.
Meinst Du aus dem 4-Pin I2C einfach einen 5-Pin Connector zu machen mit D10 oder eher einen zweiten Connector mit 5-Pins daneben als I2C angeschrieben ?
Anfängerfrage: Wie weiss die Firmware im ATtiny dann welcher Betriebsmodus gewünscht ist ?
Ich habe übrigens auch die Eagle Dateien von Mathias eingecheckt.
-
Ich bin zur Zeit an der Vereinfachung der I2C-Kommunikation, checke aber erst ein, wenn ich das fertig habe.
Meinst Du aus dem 4-Pin I2C einfach einen 5-Pin Connector zu machen mit D10 oder eher einen zweiten Connector mit 5-Pins daneben als I2C angeschrieben ?
So auf die Schnelle hätte ich den Pin einfach neben dem I2C-Connector plaziert, so dass ein 4-Pin-Stecker für die I2C-Variante und ein 5-Pin-Stecker für die SPI-Variante verwendet werden kann.
Anfängerfrage: Wie weiss die Firmware im ATtiny dann welcher Betriebsmodus gewünscht ist ?
Gar nicht, ich hätte nur das gleiche Board genommen und je nachdem eine andere Firmware aufgespielt. Alternativ könnte man MISO nehmen, um den Modus per Lötbrücke zu wählen, denn dieser Pin wird nur für ICSP genutzt. Aber das würde ich auf später verschieben, einfach nicht PCBs herstellen, die danach eine Funktionalität vermissen lassen.
Ich habe die Backlight-Control auch schon mal implementiert, aber das kann ich mit der Version 0.4 des Boards noch nicht testen. Ich versuche mal, einen PCB-Hack zu machen, nicht sehr hübsch, aber sollte funktionieren.
-
So auf die Schnelle hätte ich den Pin einfach neben dem I2C-Connector plaziert, so dass ein 4-Pin-Stecker für die I2C-Variante und ein 5-Pin-Stecker für die SPI-Variante verwendet werden kann.
Ich hab das mal angefangen und je länger ich dran war desto mehr hat mir die SPI Idee gefallen und desto weniger die Ausführung einfach den Pin neben den I2C Connector zu stellen.
Ich bin mittlerweile sehr dafür, daneben einen 5-Pin Connector zu stellen, mit SPI angeschrieben und mit den Daten-/Takt-Pins in der Mitte und Versorgung aussen. Der Anwender kann dann wählen ob er den 5-Pin oder 4-Pin Connector anbringt (oder beide).
Gar nicht, ich hätte nur das gleiche Board genommen und je nachdem eine andere Firmware aufgespielt. Alternativ könnte man MISO nehmen, um den Modus per Lötbrücke zu wählen, denn dieser Pin wird nur für ICSP genutzt. Aber das würde ich auf später verschieben, einfach nicht PCBs herstellen, die danach eine Funktionalität vermissen lassen.
Nachdem ich nun das Konzept verstanden habe bin ich dafür statt D10, wie Du auch vorschlägst den MISO zu nehmen als dritten SPI Pin. Dann bleibt D10 weiterhin verfügbar und kann falls man alles in denselben ATtiny84 gequetscht kriegt diesen für die Wahl des Modus (I2C/SPI) verwenden oder sonst halt für was anderes.
Ich hab mir das in ungefähr so vorgestellt:
(http://forum.boxtec.ch/index.php?action=dlattach;topic=2225.0;attach=540;image)
Was haltet Ihr davon ?
-
Nachdem ich nun das Konzept verstanden habe bin ich dafür statt D10, wie Du auch vorschlägst den MISO zu nehmen als dritten SPI Pin. Dann bleibt D10 weiterhin verfügbar und kann falls man alles in denselben ATtiny84 gequetscht kriegt diesen für die Wahl des Modus (I2C/SPI) verwenden oder sonst halt für was anderes.
Und welchen Pin hast Du für SS vorgesehen? SDO ist wahrscheinlich gar nicht notwendig, lesende Zugriffe sind ja (noch) nicht vorgesehen. Zudem würde ich SS in den SPI-Stecker integrieren, wobei ich wahrscheinlich D10 dafür verwenden würde. Ich bin mir nicht sicher, ob MISO als PCINT zur Verfügung steht, wenn das USI im SPI-Modus arbeitet.
Aber abgesehen davon finde ich Deine Idee mit dem separaten Stecker sehr gut, macht die Verwendung deutlich einfacher.
-
Den SlaveSelect hab ich natürlich voll vergessen, resp. mir fehlüberlegt diesen als gesetzt zu erwarten und dafür den Bus auf Master mit einem Slave zu beschränken, was aber natürlich blöd ist. Ich hab noch nie was mit SPI gemacht und wurstle mich da noch durch im Moment.
Ich werde den D10 als SS angeschrieben zwischen SCL und GND platzieren und den D10 Connector ganz rausnehmen, den SDO hab ich mal gelassen solange er nicht stört:
(http://forum.boxtec.ch/index.php?action=dlattach;topic=2225.0;attach=542;image)
Was meint Ihr dazu ?
-
Finde ich gut so, es bleibt uns dann immer noch die Möglichkeit, mittels Verkabelung von SDO (MISO) die Umschaltung auf SPI zu realisieren.
-
Fein, danke. Dann bestell ich jetzt nochmals 10 Protos davon (ich überleg mir noch ob mit Ground-Seed oder as-is).
Wenn noch jemand von Euch PCBs benötigt bitte bis Montag abend melden, ich würde das DHL shipping offerieren.
-
Salut,
kann es sein, dass beim neuen Design pin-13 statt pin-10 an SS geführt ist? Bei Eagle wird pin-13 als Aref/ADC geführt
Ciao, Mathias
-
kann es sein, dass beim neuen Design pin-13 statt pin-10 an SS geführt ist? Bei Eagle wird pin-13 als Aref/ADC geführt
Pin D10 ist der 13. Pin des ATtiny (in der PDIP-Ausführung, bei QNF ist es Pin 5). Fast jeder Pin am Tiny hat mehrere Funktionen. Da der Tiny kein Hardware-SS hat, muss die Funktion anders nachgebaut werden. D10 bietet zumindest einen Pin-Change-Interrupt an, damit sollte sich die Funktionalität implementieren lassen. Habe ich etwas übersehen?
-
Salut,
ok, in eagle ist der pin mit folgendem Label versehen:
(PCINT0/AREF/ADC0) PA0Warum nennt man ihn dann D10?
Ich habe die EagleDatei angepasst. Beim Fritzingmodell fehlen mir Befestigungslöcher.
Ciao, Mathias
-
Warum nennt man ihn dann D10?
http://playground.boxtec.ch/doku.php/arduino/attiny (http://playground.boxtec.ch/doku.php/arduino/attiny) siehe "Pin Mapping zum Arduino". Im Sketch wird er bei Verwendung der "tiny"-Hardware-Anbindung so angesprochen. Wir können auch von PA0 sprechen, dann ist es eindeutig und nicht vom Chip-Format bzw. dem Software-Framework abhängig.
-
Salut,
ich würde vorschlagen, bei der Portbezeichnung zu bleiben. Dadurch ist es dann auch verständlicher, die bits über PORTA und PORTB zu setzen.
Hat sich jemand mal die Eagle Files angeschaut (bin da immer noch ein Frischling)
Ciao, Mathias
-
Hat sich jemand mal die Eagle Files angeschaut (bin da immer noch ein Frischling)
Nicht, dass ich da der Experte wäre, aber fehlt nicht eine Verbindung von PA5 zu D7 des LCD-Steckers (Pin 14, gleich neben der Backlight-Versorgung)?
Dabei ist mir auch aufgefallen, dass dieser Pin für die Auswahl der Schnittstelle nicht mehr zur Verfügung steht. Nach meiner Rechnung haben wir auch keinen Pin mehr dafür zur Verfügung, ausser man könnte PB3 (Reset) noch irgendwie umnutzen.
-
Salut,
Danke, diese Leitung habe ich übersehen - ist korrigiert in der nächsten Version
Ciao, Mathias
-
Ich habe mir das mit der Reset-Leitung angesehen. Man kann die schon als GPIO brauchen (per Fuse), aber dann muss die Programmierung per High Voltage Serial Programming gemacht werden und das wollen wir uns nicht antun.
Man könnte für die Umschaltung trotzdem PA0 (D10) verwenden, indem wir beim Start oder besser etwas später den Zustand auslesen. Ist der HIGH, können wir von einer SPI-Anwendung ausgehen. Damit wir bei einer I2C-Verwendung aber einen konsistenten Zustand haben, müssten wir PA0 mit einem grossen Widerstand (z.B. 100k) nach Masse ziehen. So könnten wir mit I2C starten und auf SPI umschalten, sobald PA0 (D10) hochgezogen wird. Was meint Ihr?
-
Salut,
ich habe einen entsprechenden Widerstand eingebaut und die Bilder im Post (Anfang Seite 4) entsprechend geändert. Da der Widerstand neben dem SPI Pinheader liegt, kann man sich entscheiden, ob man ihn einbaut oder nicht.
Ich habe die Eaglefiles auf dem Githubrepository auch geändert.
Ciao, Mathias
-
Das mit dem 100K Widerstand find ich eine hervorragende Idee, hab ich so eingebaut. Das Board hab ich seit letztem Mal noch 5mm gekürzt, mehr halte ich mit THT Komponenten nicht mehr für sinnvoll, aber eine Varainte mit SMD Bauteilen wäre nocht interessant, alleine aufgrund der möglichen Baugrösse.
Anbei die letzte Version mit dem 100K Widerstand.
@MathiasW: Ich kann leider mit unseren momentanen Standard Linux (Debian Squeeze [6.x]) nicht das neueste Eagle installieren (dependency hell mit glibc) und daher die Dateien mit meinem Eagle 5.1 nicht öffnen. Daher möchte ich für den Moment mit der Fritzing Version weiterfahren bis ich das gelöst habe sonst kann ich nicht mal selber Gerbers erzeugen. Kann ich Dich ev. für eine Version mit SMD ATtiny begeistern, quasi die v2 ? Dein Design gefällt mir sonst sehr gut, aber wie gesagt bin ich zurzeit noch auf die vorletzte Version von Fritzing festgenagelt.
Beim Fritzingmodell fehlen mir Befestigungslöcher.
Einverstanden, andererseits kann ich mir keinen Fall für die Montage vorstellen in der das tinyLCD_I2C befestigt werden muss, darum hab ich diese auch weiterhin weggelassen. Aber ich bin da offen, 3-4 Bohrungen liessen sich sicher noch unterbringen.
-
Ich habe die neue Version der Software auf GitHub geladen. Achtung, da ich die I2C-Kommunikation geändert habe, müsst Ihr beide Seiten (Tiny und Arduino) updaten, sonst funktioniert es nicht mehr.
Meine Platine ist jetzt gemoddet:
(http://www.linotux.ch/arduino/imgs/front.jpg)
(http://www.linotux.ch/arduino/imgs/back.jpg)
Damit kann ich nun Kontrast und Hintergrundlicht verändern, was ich auch in den Test-Sketch eingebaut habe. Dort habe ich auch die Geschwindigkeit wieder auf 100 Updates pro Sekunde erhöht, was ohne Probleme funktioniert.
Ich beginne jetzt mal mit der Integration von SPI, meldet Euch, falls Ihr noch Ideen für weitere Features habt.
-
Salut,
ich habe eine SMD Version der Platine ins Repository geladen und die Gerberfiles für Itead erstellt
Ciao, Mathias
-
Ich kann leider mit unseren momentanen Standard Linux (Debian Squeeze [6.x]) nicht das neueste Eagle installieren (dependency hell mit glibc) und daher die Dateien mit meinem Eagle 5.1 nicht öffnen. Daher möchte ich für den Moment mit der Fritzing Version weiterfahren bis ich das gelöst habe sonst kann ich nicht mal selber Gerbers erzeugen. Kann ich Dich ev. für eine Version mit SMD ATtiny begeistern, quasi die v2 ? Dein Design gefällt mir sonst sehr gut, aber wie gesagt bin ich zurzeit noch auf die vorletzte Version von Fritzing festgenagelt.
Ich hatte auch kleinere Probleme mit Eagle unter Linux, die sich aber relativ einfach beseitigen liessen. Ich habe die neuste Version (6.4) heruntergeladen und in meinem Home-Directory installiert. Unter Ubuntu 13.04 (das mit Debian Wheezy relativ nah verwandt ist) brachte ich es mit folgendem kleinen Wrapper-Skript problemlos zum Laufen:
#!/bin/sh
export LD_LIBRARY_PATH=/home/$USER/eagle-6.4.0/lib
/home/$USER/eagle-6.4.0/bin/eagle
-
Danke für den Tip, zurzeit steht aber noch die ganze boxtec auf debian squeeze ;-/ und da lässt sich eagle ohne libssl1.0 schon gar nicht installieren. Dank Crazyflie hab ich jetzt aber auf dem Notebook eine wheezy (amd64) Partition und da läuft es nun. Für ein 64bit Debian sind folgende Vorbereitungen nötig:
dpkg --add-architecture i386
apt-get update
apt-get install ia32-libs ia32-libs-gtk
Danach installiert sich und läuft eagle einwandfrei.
Sobald ich was von den PCBs höre melde ich mich wieder.
@pylon: Danke für die vielen Commits! Läuft absolut solid, einzig vor dem ersten lcd.print in der demo musste ich das delay etwas erhöhen, ca. 35ms sind nötig, damit er nichts verliert. Danach läuft es absolut fehlerfrei, aber kurz nach der Initialisierung will er noch nicht so sauber und verschluckt genau die letzten 3 Zeichen ("HELLO WOR").
-
Läuft absolut solid, einzig vor dem ersten lcd.print in der demo musste ich das delay etwas erhöhen, ca. 35ms sind nötig, damit er nichts verliert.
Das kann ich hier nicht nachvollziehen. Womit testest Du? Ich verwende für die Tests momentan einen Seeeduino (V2, Duemillanove-kompatibel). Könnte es am Bootloader liegen? Ich grabe mal einen UNO hervor und versuche es dort.
-
Zurzeit hab ich einen Uno R3 angehängt über den auch das tinyI2C_LCD und das Display gespiesen wird. Ich hab aber auch mit einem Iteaduino V1.1 versucht (mit Duemilanove Bootloader und danach mit Uno Bootloader). Die Grenze ist genau 35ms, bei 33 und 34 frisst er das "!" und je kürzer desto mehr. Einen Seeeduino hab ich grad nicht zur Hand aber ich vermute den Unterschied eher auf der ATtiny Seite. Hast Du irgendwelche externen Pullups auf dem Bus ? Ich teste zurzeit ohne resp. nur mit den ATmega internen.
-
Ja, ich habe 4k7 Pullups für den I2C-Bus, aber ich vermute eher ein anderes Problem.
Setzt Du die TinyWireS-Bibliothek ein, die ich in's Repository eingecheckt habe? Dort habe ich nämlich die Puffer auf 32 Byte verdoppelt. Bei 16 Byte Pufferspeicher könnte der voll laufen, bevor die Initialisierung der LCD-Hardware abgeschlossen ist.
Wenn die Pullups etwas dazu beitragen würden, hätten wir durchgehend Probleme und nicht nur beim Aufstarten.
-
Ich wär zwar ziemlich sicher, dass ich alles neu aus dem github Repo gezogen und geflasht habe, aber ein erneutes Flashen des ATtiny hat Abhilfe geschaffen, also werd ich wohl irgendwo noch die alte TinyWireS hergehabt haben auch wenn ich jetzt grad nicht sehe wie - sorry für den falschen Alarm, jetzt mag er mich auch mit delay(1); .
-
Nach einigen gröberen Umstellungen in der Firmware ist die SPI-Basis jetzt integriert und der I2C-Teil läuft wieder (den hatte ich zwischenzeitlich mal komplett verschossen). Nun kommt die Bibliothek und das SPI-Debugging dran (meine Platine ist jetzt noch mehr gemoddet, davon darf ich aber keine Bilder mehr posten :) ). Die TinyWireS-Bibliothek musste auch ein paar Federn lassen, da SPI die gleiche Hardware (USI) benutzt und ich somit den Interrupt-Vektor mehrfach verwenden muss. Zum Glück hatten wir die ja schon in unser Projekt integriert.
-
Prima, ich freu mich schon drauf mit SPI zu testen. Die Änderungen hast Du aber noch nicht comitted oder ? Ein pull hat bei mir nichts neues gebracht.
Die neuen Boards (auch die von Mathias) hoffe ich nächste Woche zu erhalten, die gehen dann gleich an Euch beide wieder raus.
ATtiny84A in SOIC Gehäuse sind ebenfalls unterwegs und sollten auch in den nächsten tagen bei uns eintreffen.
-
Committed schon, aber noch nicht auf GitHub, aber das dürftest Du gemeint haben. SPI funktioniert noch nicht. Ich weiss zwar, dass ich irgendwas erhalte, aber ich muss wahrscheinlich noch einige Debugging-Session machen, bis das wirklich funktioniert. Die Doppelbelegung von MISO scheint mehr Probleme zu bereiten, als ich angenommen hatte.
-
Kein Problem, ich bin nur noch etwas unsicher mit git und deshalb die Nachfrage ;-)
Übrigens: Gerade eben angekommen:
(http://forum.boxtec.ch/index.php?action=dlattach;topic=2225.0;attach=555;image)
Leider fehlen noch die SOIC ATtiny, die hätten heute auch noch kommen müssen, nun wirds Freitag. Am kommenden Montag gehen SMD und normale Kits an Euch raus.
-
Die Kits gingen leider erst gestern abend raus, aber zumindest Pylon sollte seine heute erhalten haben. Leider ist mir nun aufgefallen, dass ich vor lauter "muss-noch-raus-heute" den female header vergessen habe beizulegen. Falls einer von Euch keine mehr hat, bitte kurz Bescheid geben damit ich diese nachsenden kann.
-
Vielen Dank für das Paket, meines war gestern in der Post. Die Header sind kein Problem, habe genug davon vorrätig.
Schon eher Richtung Problem geht bei mir das SMD-Löten (dass ich eher der Software-Typ bin, habt Ihr wahrscheinlich schon bemerkt). Wie macht Ihr das? Ich habe mitbekommen, dass das (im normalen Ausmass) Auftragen von Lötzinn und danach Entfernen desselben mittels Entlötlitze machbar wäre, wobei erst danach das SMD-Bauteil drauf kommt und durch kurzes Erhitzen fixiert wird. Ist das so machbar oder ratet Ihr zu anderem Vorgehen? Ist die Lötpaste, die Boxtec neu im Angebot hat, für solche Sachen gedacht?
Die Programmierung hängt immer noch, ich habe sehr komisches Verhalten, das auf knappen Speicher hindeutet, werde also mal den etwas optimieren. Bis morgen werde ich meine Version mal auf GitHub pushen, vielleicht findet ja einer von Euch den Fehler.
-
Freut mich, dass das mit den Kits geklappt hat.
Das ganze SMD Löten ist halb so wild, grundsätzlich brauchts gar nichts ausser einem temperaturgeregelten Lötkolben mit einer Lötspitze die sich noch nicht im letzten Drittel ihrer Lebenserwartung befindet.
Mir hat dieses Sparkfun Tutorial (https://www.sparkfun.com/tutorials/36) jegliche Angst (und auch den Respekt) vor SMD genommen und die ersten Erfolgserlebnisse mit FT232 ICs liessen dann auch nicht lange auf sich warten.
Ich persönlich verwende einen Flux Pen (http://shop.boxtec.ch/liquid-flux-pen-water-soluble-p-40689.html) und bestreiche damit die Pads vor dem Löten. Dann richte ich den IC mit einer Pinzette schön auf den Pads aus (er haftet durch den Flux Pen schon leicht) und fixiere/verlöte dann ein Bein an einer der Ecken wo ich am besten dazukomme. Sitzt er danach sauber kann man entweder jedes Bein von Hand mit ganz wenig Zinn verlöten oder einfach mit genügend Zinn einmal die ganze Seite zupflastern und danach mit Entlötlitze überflüssiges Zinn auf der ganze Seite entfernen.
Zweitere Variante ist vor allem bei vielen Beinen sinnvoll, bei 14 Pins würde ich mir den Aufwand sparen und jedes Bein kurz anlöten und ggf. am Ende überflüssiges Zinn mit Entlötlitze entfernen. Den Flux Pen kann ich beiden Methoden empfehlen. Zweitere setzt ihn voraus, bei ersteren wirds etwas sicherer/einfacher dadurch.
Einen Flux Pen schicke ich Dir gerne, lass mich wissen ob Du einen möchtest, ich würde Dir auch noch einen Reserve ATtiny84SSU mitschicken, das erhöht die gefühlte Sicherheit beim ersten Versuch auch noch etwas Reserve zu haben. Heut reichts nicht mehr, aber wenn wirs morgen per A-Post schicken hast Du es auch am Samstag im Briefkasten.
Lötpaste ist nur sinnvoll wenn Du einen Rework Ofen oder Rework Station hast. Diese wird, meist mit einer Stencil genannten Schablone, genau auf die Pads aufgetragen - selten auch von Hand, danach "pappt" man den IC exakt drauf und erhitzt die ganze Geschichte mit heisser Luft. Die Paste wird einfach gesagt zu Lötzinn und erstellt automatisch Lötstellen da wo es welche hat. Dies wird vor allem eingesetzt wenn es um viele Pins mit kleinen Abständen geht, z.B. ein TQFP48 oder gar ein BGA.
-
Einen Flux-Pen habe ich schon (von Euch :) ), auch wenn ich ihn bisher noch nicht einzusetzen wusste. Ich werde mich also mal am SOIC-Chip versuchen, aber nicht mehr vor den Ferien (bei mir ab Montag).
Das normale Kit ist auch noch nicht fertig, da in meinem ein 28-Pin-Sockel war und ich keine 14-Pin-Sockel in meinem Sortiment führe (bisher). Einen 16-Pin-Sockel zu verwenden (die hätte ich vorrätig), macht auch wenig Sinn, da dann R4 fast keinen Platz mehr hat. Das muss also auch bis nach den Ferien warten, dann habe ich auch genügend Zeit, mein Sortiment zu ergänzen.
Den aktuellen Stand (mit Debugging-Ausgabe auf dem Display) habe ich auf GitHub gepushed. Wenn einer von Euch mal Zeit hat und das testen könnte, wäre mir geholfen. Bei mir bekomme ich von der common_available()-Funktion immer 3 zurück (5. Zahl in der unteren Zeile), während die lokale Berechnung plausiblere Werte (3. Zahl untere Zeile) ergibt. Dieses Verhalten ist mir zur Zeit unerklärlich, ich suche zur Zeit nach Buffer Overflows und ähnlichem, ist die einzige Möglichkeit, die mir noch einfällt.
-
:-\
Das nennt man deformation professionelle, in der 328er Variante...
Entschuldigung, die BOM auf Github war auch falsch, damit hab ich die Kits zusammengestellt, die BOM ist nun korrigiert.
2x 14-Pin Sockel und ein Reserve SOIC ATtiny gehen heute per A-Post raus.
@MathiasW: Dir gebe ich diese gerne am nächste Freaky Friday mit, auch Du hast 28Pin Sockel erhalten.
-
Melde mich aus den Ferien zurück. Nun konnte ich endlich die neue Platine zusammenlöten, aber leider hatte ich keinen Erfolg damit. Obwohl ich meiner Meinung nach alle Verbindungen überprüft habe, kann ich das Display zu keinen Output bewegen. Die Hintergrundbeleuchtung zu verändern, klappt prima, aber sonst kriege ich keinen Feedback.
Zur Sicherheit hatte ich auch den ATtiny mit dem alten Board gewechselt, um diese Fehlerquelle auszuschliessen.
Funktioniert das neue Board bei Euch?
Edit: Meine Vermutung geht Richtung Kontrast-Regelung. Ohne Display kriege ich etwa einen Drittel so grosse Werte wie vorher, mit Display sind es immer mindestens 1.5V. Kann es sein, dass der vergrösserte Widerstand des RC-Glieds dafür verantwortlich ist?
-
Nach etwas Nachtarbeit ist jetzt auch das SMD-Board zusammengelötet (auch wenn die konv. Bauteile nicht leicht auf die SMD-Pads zu bringen waren). Leider habe ich den selben Effekt wie beim THT-Board. Beim Widerstand für den Kontrast (R1 bzw. R2) messe ich (auf der Prozessor-Seite) ca. 0.5V (beim einem PWM von 30), nach dem Widerstand (beim Kondensator) jedoch 1.9V. Am Widerstand fällt also fast 1.4V ab.
Bei der 0.9er Version habe ich 0.2V (vor) und 0.6V (nach dem Widerstand), somit fällt dort nur 0.4V ab. Mein Problem ist, dass ich bei den neuen Boards nicht unter die 1.5V komme, egal, welchen PWM-Wert ich einstelle. Kann sich jemand von Euch einen Reim darauf machen?
Interessant ist auch, dass ich diese Werte nur messe, wenn das Display angeschlossen ist. Ohne Display ergeben auch die neuen Boards 0.3V und 0.6V.
Ist das bei Euch auch so?
Die Werte ergeben, dass das Display auf dem Kontrastpin ca. 0.3mA konsumiert (wenn ich das richtig interpretiere). Schräg finde ich allerdings, dass die 1.4V am Widerstand auch abfallen, wenn ich einen PWM-Wert von 0 programmiere, beim alten Board jedoch in diesem Fall über den Widerstand keine Spannung messbar ist.
Es kann natürlich sein, dass mir das Multimeter bei den PWM-Werten keine korrekten Messwerte liefert, aber mir ist der Grund dafür nicht klar, vor allem, da die alte Version plausible und erklärbare Messwerte liefert.
Womit liege ich falsch?
-
Es tut mir leid, dass ich nicht früher geantwortet habe. Ich habe gehofft, das Wochenende lässt Zeit um da wieder einzusteigen nachdem ich es zugunsten anderer Sache abräumen musste, aber leider kamen dann aufwandintensive Netzwerkprobleme dazwischen und die Pendenzen haben sich in der Zwischenzeit aufgetürmt.
Ich habe einen ähnlichen Status zurzeit, aber bei beiden Boards, daher vermute ich eher ich hab beim "schnell Firmware hochladen" wieder irgendwo was altes reingenommen.
Ich melde mich morgen spät. Mittoch wieder mit fundierten Resultaten.
Die THT statt SMD Widerstände für das SMD Kit sind nicht wirklich clever von mir gewesen. Ich wollte da schon neue nachschicken und das dann melden, aber die sind leider noch nicht gekommen. (Da sollten dann auch wieder 150 Ohm Widerstände statt 180 dabei sein, wobei ich nicht wirklich überzeugt bin, dass dies das einzige Problem ist).
-
Ich habe einen ähnlichen Status zurzeit, aber bei beiden Boards, daher vermute ich eher ich hab beim "schnell Firmware hochladen" wieder irgendwo was altes reingenommen.
Bei mir ist das auch bei beiden neuen Boards der Fall, nur das alte funktioniert noch wie gewünscht (ausser der SPI-Software).
Da sollten dann auch wieder 150 Ohm Widerstände statt 180 dabei sein, wobei ich nicht wirklich überzeugt bin, dass dies das einzige Problem ist
Der 180Ω-Widerstand ist bei mir für das Backlight verbaut. War das nicht so gedacht? Beim Kontrast verwende ich den 220nF-Kondensator und den 4k7-Widerstand.
Ich werde nochmals durchgehen, ob ausser der Backlight-Regelung und dem Pull-Down-Widerstand für D10 (PA0) noch etwas anderes geändert hat. Diese Modifikationen hatte ich nämlich schon am alten Board vorgenommen, dann wäre nur noch der 4k7- anstatt 1k-Widerstand als Unterschied vorhanden, was ja relativ einfach zu ändern wäre.
-
Der 180Ω-Widerstand ist bei mir für das Backlight verbaut. War das nicht so gedacht? Beim Kontrast verwende ich den 220nF-Kondensator und den 4k7-Widerstand.
Ich werde nochmals durchgehen, ob ausser der Backlight-Regelung und dem Pull-Down-Widerstand für D10 (PA0) noch etwas anderes geändert hat. Diese Modifikationen hatte ich nämlich schon am alten Board vorgenommen, dann wäre nur noch der 4k7- anstatt 1k-Widerstand als Unterschied vorhanden, was ja relativ einfach zu ändern wäre.
Das ist definitiv falsch mit dem 4.7k, da gehört ein 1k rein. Ich seh auch woher ich das habe, im Schema war der offenbar als 4.7k. Auf meinem ersten Board ist natürlich auch ein 1k. An und für sich müsste aber bei 100% PWM duty auch da irgendwann eine vernünftige Spannung anliegen, da muss noch woanders ein Problem liegen, aber ich habs bisher nicht gefunden.
-
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 (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 (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.
-
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?
-
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/ (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.
-
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.
-
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:
git clone https://github.com/boxtec/tinyLCD_I2C
Das Hex File hab ich mit folgendem Befehl auf mein altes Board gebrannt:
/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.
-
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.
-
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
LiquidCrystal lcd(3, 1, 9, 8, 7, 5);
durch
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.
-
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
-
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 :(