Hallochen.
Im Uhren-Fred hatte ich schon gefragt- da schaun offenbar viele nicht rein, drum noch mal hier:
Ich hab einen Uno.
Dazu ein 1.8" TFT und ne Ds1302.
Uno+TFT spielen miteinander.
Uno+RTC spielen miteinander.
Uno+RTC+TFT spielen nicht miteinander. Meine ganzen Uhrenprogramme, die aufm Mega wunderbar liefen (hab grad keinen frei um auch das noch gegenzutesten), laufen auf der Konstrumtion nicht. Auch dieses nicht:
#define DS1307_ADDRESS 0x68
#define sclk 13
#define mosi 11
#define cs 10
#define dc 9
#define rst 8
#include "Adafruit_GFX.h"
#include "Adafruit_ST7735.h"
#include "SPI.h"
#include "Wire.h"
Adafruit_ST7735 tft = Adafruit_ST7735(cs, dc, rst);
void setup()
{
Wire.begin();
Serial.begin(9600);
tft.initR(INITR_BLACKTAB);
tft.fillScreen(ST7735_BLACK);
tft.setTextColor(ST7735_RED,ST7735_WHITE);
tft.print("UHR");
delay(10);
}
void loop(){
tft.print("blub");
printDate();
tft.print("Blab");
delay(1000);
}
byte bcdToDec(byte val) {
// Convert binary coded decimal to normal decimal numbers
return ( (val/16*10) + (val%16) );
}
void printDate(){
// Reset the register pointer
Wire.beginTransmission(DS1307_ADDRESS);
Wire.write(0);
Wire.endTransmission();
Wire.requestFrom(DS1307_ADDRESS, 7);
int second = bcdToDec(Wire.read());
int minute = bcdToDec(Wire.read());
int hour = bcdToDec(Wire.read() & 0b111111); //24 hour time
int weekDay = bcdToDec(Wire.read()); //0-6 -> sunday - Saturday
int monthDay = bcdToDec(Wire.read());
int month = bcdToDec(Wire.read());
int year = bcdToDec(Wire.read());
//print the date EG 3/1/11 23:59:59
Serial.print(month);
Serial.print("/");
Serial.print(monthDay);
Serial.print("/");
Serial.print(year);
Serial.print(" ");
Serial.print(hour);
Serial.print(":");
Serial.print(minute);
Serial.print(":");
Serial.println(second);
}
Wenn ich die RTC ODER die Uhr deaktiviere, läufts.
Jemand ne Ahnung, wieso??
Mit der Arduino-TFT-Lib gehts übrigens auch nicht....
Hm, ich hab das eben mal mit der FreeMemory-Lib ausprobiert:
Deaktiviere ich das Display (dann läuft das Programm ja) gibt freeMemory 1499 aus-
wenn ich das Display aktiviere, 1499. Allerdings weiss ich nicht, ob das aussagekräftig ist (letzteres)- denn dann hängt das Programm ja.
Kann mir ehrlich gesagt auch nicht vorstellen, dass das bisschen Programm (das gepostete ist bisher alles, mehr gibts nicht!) nicht auf nem Uno laufen sollte...
Immerhin gibts das Shied (mit dem TFT) ja für den UNO auch...
Hallo Sly,
hilft dir zwar nix, aber bei mir läuft es sauber durch, ich habe es auf einem Uno und auf einem Nano V3 probiert, zusätzlich habe ich noch die Uhrenmodule getauscht DS 1307 gegen DS 3231.
Ein DS 1302 habe ich leider nicht.
Hm, hab eben nachgesehen: ich schätze, es ist auch ein 3231.
Das grössere, genauere mit I2C eben, was ichs chon immer benutze.
Das Ding funktioniert ja auch mit dem Uno probvlemlos. Nur eben nicht mehr, wenn ich das TFT dazu nehme (reicht schon, wenn ich es auch nur initialisiere), hängen bleibt das Programm dann bei der Zeitauswertung.
Sodele.
Ich hab mal ein wenig weiter geforscht.
Irgendwie kommen sich Display und Wire-Lib wohl in die Quere...der Code
#define DS1307_ADDRESS 0x68
#define sclk 13
#define mosi 11
#define cs 10
#define dc 9
#define rst 8
#include "Adafruit_GFX.h"
#include "Adafruit_ST7735.h"
#include "SPI.h"
#include "Wire.h"
#include <MemoryFree.h>
Adafruit_ST7735 tft = Adafruit_ST7735(cs, dc, rst);
int second;
int minute;
int hour;
int weekDay;
int monthDay;
int month;
int year;
int buttonPin=A2;
void setup()
{
pinMode(buttonPin,INPUT_PULLUP);
Wire.begin();
Serial.begin(9600);
tft.initR(INITR_BLACKTAB);
tft.fillScreen(ST7735_BLACK);
tft.setTextColor(ST7735_RED,ST7735_WHITE);
tft.println("UHR");
delay(10);
}
void loop(){
tft.setTextColor(ST7735_RED,ST7735_BLACK);
tft.println();
tft.print("freier Speicher:");
tft.println(freeMemory());
printDate();
Serial.print("freeMemory()=");
Serial.println(freeMemory());
tft.print("Blab");
delay(1000);
}
byte bcdToDec(byte val) {
// Convert binary coded decimal to normal decimal numbers
return ( (val/16*10) + (val%16) );
}
void printDate(){
// Reset the register pointer
Wire.beginTransmission(DS1307_ADDRESS);
Wire.write(0);
tft.print("TACK");
Wire.endTransmission();
tft.print("TICK");
Wire.requestFrom(DS1307_ADDRESS, 7);
second = bcdToDec(Wire.read());
minute = bcdToDec(Wire.read());
hour = bcdToDec(Wire.read() & 0b111111); //24 hour time
weekDay = bcdToDec(Wire.read()); //0-6 -> sunday - Saturday
monthDay = bcdToDec(Wire.read());
month = bcdToDec(Wire.read());
year = bcdToDec(Wire.read());
//print the date EG 3/1/11 23:59:59
Serial.print(month);
Serial.print("/");
Serial.print(monthDay);
Serial.print("/");
Serial.print(year);
Serial.print(" ");
Serial.print(hour);
Serial.print(":");
Serial.print(minute);
Serial.print(":");
Serial.println(second);
Serial.print("freeMemory()=");
Serial.println(freeMemory());
}
läuft bis vor die Zeile:
Wire.endTransmission();
das "TACK" kommt auf dem Display noch an, das "TICK" in der übernächsten bereits nicht mehr...das muss der Punkt sein, an dem alles abschmiert...
Jemand eine Idee wie man das umschiffen könnte?
Jo, ich blick das mit den RTC`s selber nicht mehr....und die Chinesen schreiben immer recht wenig auf die Platinen.
Mein grösster Chip auf dem Ding heisst DS3231N.
Ist das "genauere" Teil, was auch die Temperatur ausgeben kann. Pullups sind extra keine verbaut-hab ich noch nie gemacht bei diesem Modul, aller Wahrscheinlichkeit nach sind da bereits welche drauf (zwei 5,8K lümmeln da herum??)- es läuft ja einwandfrei.
Verbunden ist das Teil mit ner kleinen Adapterplatine per I2C- also an Analog 4, 5 und Stromversorgung, wie immer. Die Platine dazwischen nur deshalb, weil ich vielleicht nen Gehäuse drum herum zimmern will. Aufm Steckbrett gehts auch nicht.
Strom bekommt der Dino üblicherweise per USB-aber ich hab auch schon das (ausreichend kräftigt, damit lief auch der MEGA immer, samt dem Display und der Uhr) Netzteil dran gehabt-bingt nix, am Strom liegts auch nicht.
Wie schon gesagt: die RTC allein läuft. So lange ich das Display nicht starte geht das Programm. Aber irgendwie doof, wenn man zwar die Uhrzeit hat, sie aber nirgends ablesen kann.
Auch das Display geht- bis genau zu dem oben beschriebenen Punkt. Ab dem passiert gar nix mehr- keine Anzeigen weiter auf dem Display, nix in der seriellen Konsole-einfach Ruhe.
Der Mega2560 hat die I2C Pullups auf dem Board integriert, beim UNO muss man die selbst einsetzen. Kannst Du überprüfen, ob die 5k8 Widerstände wirklich zwischen Vcc und SDA bzw SCL sind?
Das Display und der RTC verwenden verschiedene Pins und verschiedene Hardwaremodule auf dem Prozessor, sind also logisch komplett getrennt. Wenn Du sonst nichts veränderst und die Komponenten einzeln funktionieren, ist ein Problem in der Stromversorgung nicht so unwahrscheinlich.
Wie hast Du die Tests gemacht? Hattest Du jeweils die Hardware mit beiden Geräten verbunden und nur den einen oder anderen Code benutzt oder war der Hardware-Setup immer anders? Falls Du das noch nicht versucht hast, lass die Hardware mal bei Vollausstattung und lade die einzelnen Sketches. Zeigt sich das gleiche Bild?
Das von Dir beschriebene Verhalten kann ich mir sonst nur mit ausgeschalteten Interrupts erklären, ich konnte allerdings in Deinem Code keine Hinweise darauf finden.
Ich habe den Code nochmals durchgecheckt und konnte keine Probleme finden, die auf einen Zusammenhang zwischen der RTC-Ansteuerung und der LCD-Lib schliessen lassen.
Meine Vermutung geht mehr Richtung Stromversorgung. Wenn das Display aktiviert wird, dürfte deutlich mehr Strom gezogen werden. Kannst Du mal die Spannung zwischen 5V und GND messen, wenn das Display aktiv ist, also der Sketch eingefroren ist?
Ich hätte erwartet, dass die Spannung mehr taucht. Scheint eine Sackgasse.
Hast Du die Möglichkeit, ein Oszilloskop (oder einen Logic Analyzer) anzuschliessen? Es wäre interessant, ob auf SDA/SCL überhaupt etwas rausgeht und ob allenfalls eine Antwort vom RTC kommt und wenn ja, wie das Timing dieser Signale aussieht.
Nein, hab ich leider nicht.
Was ich weis ist, dass es bis zu diesen Zeilen:
Wire.write(0);
tft.print("TACK");
Läuft. Also schmiert er definitiv danach erst ab (die TickTacs hab ich nur deswegen eingefügt um den richtigen Punkt zu finden).
Das Problem taucht also auf, sowie die Zeile:
Wire.endTransmission();
Aufgerufen bzw. ausgeführt wird. Genau dort.
Inzwischen beschäftigt mich die Frage, ob man das mit nem anderen Programmaufbau irgendwie umschiffen könnte...die früher benutzte Bibliothek (weiss grad nicht genau, glaub RTClib.h) macht das selbe Problem. Und die anderen laufen-nicht oder mangelhaft mit dem Ding.
Hm- ich hab mal weiter geforscht und kurzerhand die RTC gegen ein anderes I2C-Gerät ausgetauscht.
Den Kompass- da hab ich exakt das selbe Problem!
ENTWEDER geht der Kompass einwandfrei ODER das TFT- beides zusammen funktioniert-nicht.
Wäre es denkbar, dass ich Soft-SPI benutzen muss, damits klappt?
Momentan nutze ich ja die Hardware-Schnittstelle des Uno...würd das auch weiterhin tun wollen, wenns ne Lösung gäbe..
Auch das scheint keine Lösung zu sein- da ich mit ja nen Platinchen als Adapter gebaut hab, konnte ich nur die gleichen Pins benutzen für die Soft-SPI. Zum einen wird dann das Display elendig laaaaaangsaaaaammmmmm, und zum anderen bleibt das Problem bestehen.
Gut- das Tempo wäre soo kritisch nicht, allzu viel zugleich würde ja nur beim starten gezeichnet, danach hälts sich ja in Grenzen aber- das Problem bleibt leider bestehen.
Werd mal, wenn ich Lust drauf hab, andere Pins probieren....leider sind die Uno`s da ja etwas mager ausgestattet.
habe dein Sketch mal auf einem meiner Projekte angetestet, die Hardware ist ähnlich.
Mein TFT läuft via Hardware-SPI auf dem Uno. Habe die Pin-Deklaration für SCLK & Mosi aus deinem Sketch ausgeklammert. Und siehe da, dein Sketch funktioniert!
Laut Beispiel müsste deine Zeile für das TFT doch wie folgt ausschauen:
Adafruit_ST7735 tft = Adafruit_ST7735(cs, dc, mosi, sclk, rst);
Leider nicht...die von dir gepostete Zeile soll man bei Soft-SPI benutzen.
Das funktioniert auch (hab ich neulich schon getestet)- aber auch nur bis zu genau dieser Stelle.
Wie gesagt: Display läuft- Uhr läuft auch, nur beides gemeinsam läuft nen Stück und hängt dann fest...
Das Einzige was ich noch versuchen kann (und das werd ich nun auch weil nix anderes mehr übrig bleibt) ist, die Soft-SPI mal auf anderen Pins zu probieren. Gefällt mir ja gar nicht (ich ahn schon, was da kommt, weil die Soft-SPI jämmerlich langsam ist), aber wenn es eben nicht anders geht..
Eben hab ich die Schaltung noch mal zerrpuft, alles aufs Steckbrettl gepackt und....es läuft.
Mitm Hardware-SPI. Damit ist klar: in meiner anderen Schaltung muss was falsch sein-seltsam nur, dass beide Geräte getrennt ja funktionieren...
Also ran ans Multimeter..
Nachtrag....
Heute gerlernt: selber erfundene Schaltungen funktionieren auch, aber nur, wenn man sie dann auch so baut wie sie erfunden wurden. 8)
Die Ursache war, dass ich vergessen hatte, ein paar Kupferbahnen zu durchtrennen. Somit hat eine der I2C-Leitungen versucht, mit der SPI zu kommunizieren- wovon die offenbar aber nix wissen wollte. Sprechen wohl verschiedene Sprachen, die beiden...
