Hallo zusammen,
mein kleines Projekt mit RTC und LCD stellt mich für ein für mich
merkwürdiges verhalten. Ich sende die Zeitdaten über eine serielle
Schnitstelle an den Arduino Uno. Allerdings werden diese nur sporadisch
auch in die variablen für stunde sekunde etc. eingetragen. Im
beigefügten Screenshot sieht man dass erst beim letzen versuch die Daten
gespeichert und Datum und Uhrzeit korrekt ausgegeben wurde. Zuvor wurden
die daten zwar korrekt übertragen (Siehe fälschliche Ausgabe als Control
Byte) jedoch in der Routine für das schreiben der Daten auf die RTC von
den Serial Reads offensichtlich nicht aus dem Puffer gelesen.
Nach einigen schnell aufeinander foglenden Resends der Daten aus der
Konsole geht es dann. Ich kann den fehler nicht finden :(
cableer schrieb:> anyone? :(
Doch doch...
cableer schrieb:> Serial.read()
Evtl hast du vergessen die Doku zu lesen.....
Tipp:
Mach das mal...
(den Rest habe ich mir noch gar nicht angesehen)
Bitte schaut auch den Screenshot an. Das Problem liegt nicht beim
Handling der RTC. Das Problem liegt beim holen der Daten aus dem
Seriellen Stream von PC.
Von Zeit zu zeit Liest er in der Set Routine nicht die Daten aus dem
Fifo. Erst der
Serial.print("Done Withc Commad: ");
Serial.println(char(command));
Teil schreibt dann zeile für zeile die daten raus, die eigentlich in
void setDateDs1307()
{
Serial.println("In set Mode");
second = (byte) ((Serial.read() - 48) * 10 + (Serial.read() - 48));
minute = (byte) ((Serial.read() - 48) *10 + (Serial.read() - 48));
hour = (byte) ((Serial.read() - 48) *10 + (Serial.read() - 48));
dayOfWeek = (byte) (Serial.read() - 48);
dayOfMonth = (byte) ((Serial.read() - 48) *10 + (Serial.read() -
48));
month = (byte) ((Serial.read() - 48) *10 + (Serial.read() - 48));
year= (byte) ((Serial.read() - 48) *10 + (Serial.read() - 48));
ausgelesen hätten werden sollen.
Arduino F. schrieb:> cableer schrieb:>> anyone? :(> Doch doch...>> cableer schrieb:>> Serial.read()> Evtl hast du vergessen die Doku zu lesen.....> Tipp:> Mach das mal...> (den Rest habe ich mir noch gar nicht angesehen)
Das zeigt nur, dass du nicht alle Informationen die ich zur Verfügung
gestellt habe gelesen/angesehen hast.
Serial.read() sollte Byteweise aus dem Puffer lesen. Die Bytes sollten
dann NICHT MEHR im Puffer stehen, so wie ich die Doku interpretiere.
cableer schrieb:> Das zeigt nur, dass du nicht alle Informationen die ich zur Verfügung> gestellt habe gelesen/angesehen hast.
Stimmt!
Aber es hat gereicht, um wenigstens einen Fehler zu finden.
cableer schrieb:> so wie ich die Doku interpretiere.
Daran kannst du noch arbeiten ;-)
cableer schrieb:> Serial.read() sollte Byteweise aus dem Puffer lesen.
Ja! "sollte"
Und was passiert, wenn der Buffer leer ist?
Arduino F. schrieb:> cableer schrieb:>> Serial.read() sollte Byteweise aus dem Puffer lesen.> Ja! "sollte"> Und was passiert, wenn der Buffer leer ist?
Wenn du dir die mühe machen würdest die Bilder anzusehen und meine
Antwort richtig zu lesen wüsstest du dass der Buffer nicht leer ist. Es
wird ja der gesamte inhalbt, exact das was ich auch gesehen habe,
ausgegeben, allerdings erst NACH der set routine.
cableer schrieb:> allerdings erst NACH der set routine.
Ja...
Dann hat die Set Routine wohl nur eine Handvoll -1 bekommen.
cableer schrieb:> dass der Buffer nicht leer ist.
Wo soll ich das sehen?
Ein einziges mal prüft du, ob was im Bufffer ist.
Den Rest der Zeit geht dir das offensichtlich am Ars*h vorbei.
Arduino F. schrieb:> cableer schrieb:>> allerdings erst NACH der set routine.> Ja...> Dann hat die Set Routine wohl nur eine Handvoll -1 bekommen.
Die Set routine wird aber vom ersten byte des eingehenden streams erst
geriggert. Das macht so keinen Sinn.
cableer schrieb:> Die Set routine wird aber vom ersten byte des eingehenden streams erst> geriggert.
Und dann kommen zverlässig weitere Byte rein, so dann man gar nicht
prüfen muss, ob da eins ist...
Nee... sowas tuts nur in der Fantasie
cableer schrieb:> rduino F. schrieb:>> cableer schrieb:>>> allerdings erst NACH der set routine.>> Ja...>> Dann hat die Set Routine wohl nur eine Handvoll -1 bekommen.>> Die Set routine wird aber vom ersten byte des eingehenden streams erst> geriggert. Das macht so keinen Sinn.
Oder meinst du, dass die routine abgearbeitet wird bevor der buffer
tatsächlich ALLE daten enthält? Ich werde mal ein delay einbauen. Danke
für den Hinweis!
cableer schrieb:> Das Problem liegt beim holen der Daten aus dem> Seriellen Stream von PC.Arduino F. schrieb:> Und was passiert, wenn der Buffer leer ist?
gute Einwände, darauf habe ich nicht geachtet, ich habe mich nur auf die
Sonderbehandlung mit stop / start der DS1307 gestürzt.
Der TO muss auch noch mehr lernen (wie ich auch)
aber klar richtig einsammeln muss man auch aus serial.....
1
// --------------- serial in ---------------
2
if(Serial.available()>0)
3
{charincomingByte=(char)Serial.read();
4
if(incomingByte==13)// Wenn das Enter ankommt
5
{strcpy(serial_in_command,serial_in_buff);
6
chr_cnt=0;
7
strcpy(serial_in_buff,"");
8
}
9
else// Falls kein Enter kommt muss der Text gespeichert werden in dem inText Array
if(i2c_test_flags&(1<<I2C_RTC_1307))RTC.startClock();(i2c_test_flags&(1<<I2C_RTC_3231))?Serial.println(F(" DS3231 RTC ist gestellt")):Serial.println(F(" DS1307 RTC ist gestellt"));
Problem solved. Jetzt habe ich auch verstanden was du mir genau sagen
wolltest. Die Daten brauchen tatsächlich länger als der Durchlauf der
Routine. Und das selbst bei 57600 Baud. Das hätte ich so nicht vermutet.
Also, besten Dank für's Helfen!
Joachim B. schrieb:> es fehlt noch die Abfrage das es keinen Überlauf im In Buffer gibt.
Ich weiß, das Programm ist auch bei Weitem noch nicht fertig. Ich wollte
nur ein kurzes "proof of concept" machen um zu sehen ob es in etwa so
wird wie ich mir das vorstelle. Jetzt, da es tut, geht es an die
Feinheiten.
cableer schrieb:> Oder meinst du, dass die routine abgearbeitet wird bevor der buffer> tatsächlich ALLE daten enthält?cableer schrieb:> Problem solved.
das glaube ich nicht, jedenfalls mit delay ist Mist!
Joachim B. schrieb:> Der TO muss auch noch mehr lernen (wie ich auch)
Das will ich auch....
cableer schrieb:> Das hätte ich so nicht vermutet.
Ungeprüfte Annahmen sind oft genug die Grundbausteine des Versagens.
cableer schrieb:> Also, besten Dank für's Helfen!
Gern geschehen.
Axel R. schrieb:> hättest Du es als *.ino anhängen können? Gäbe sicher mehr Resonanz.>> StromTuner
hmmm, klar aber es sind nur Bausteine und eigentlich auch mit kleinen
Umbauten als C zu gebrauchen, ich wechsel manchmal zwischen AVR Studio
und Arduino, deswegen:
Joachim B. schrieb:> #if (ARDUINO>0)
Das ganze Ino braucht hier keiner und es ist ja noch nicht perfekt
Joachim B. schrieb:> cableer schrieb:> Oder meinst du, dass die routine abgearbeitet wird bevor der buffer> tatsächlich ALLE daten enthält?>> cableer schrieb:> Problem solved.>> das glaube ich nicht, jedenfalls mit delay ist Mist!
Ich habe es natürlich nicht als Delay implementiert sondern leere das
fifo in einer Schleife bis zum carriage return.
Man muss nicht immer alles schlecht machen. Designs unterscheiden sich
eben in konzeptphase und der ausgerollten Implementierung.
Klar kann man das auch selbst nachsehen. Alles per Hand machen. Am Ende
braucht es halt manchmal ein zweites paar Augen.
Cableer schrieb:> Ich habe es natürlich nicht als Delay implementiert sondern leere das> fifo in einer Schleife bis zum carriage return.
wo hattest du das geschrieben?
ich las nur:
cableer schrieb:> Ich werde mal ein delay einbauencableer schrieb:> Problem solved.
Als Chinesische Hersteller die Frechheit besaßen, PC's mit mehr als 8Mhz
Taktfrequenz zu bauen, funktionierten einige prominente Programme
plötzlich nicht mehr.
Die Programmierer konnten sich damals wohl nicht vorstellen, dass IBM
kompatible PC's mal schneller sein würden. Deswegen hatten viele rechner
damals den Turbo Schalter, damit konnte man sie heruntertakten.
Dann als später 386er auf den Markt kamen, vielen reihenweise Programme
aus, die mit Borland Pascal geschrieben wurden. Prinzipiell aus dem
selben Grund, dieses mal steckte der Fehler allerings in der
Laufzeitbibliothek von Borland - nicht im Anwednungsprogramm.
Und in den 15 Jahren danach kenne ich weitere Beispiele. Ich habe daraus
gelernt, dass Programme niemals von einer bestimmtem
Ausführungsgeschwindigkeit abhängig sein sollen. Ja man sollte nichtmal
davon ausgehen, dass die Geschwindigkeit nach Programmstart konstant
ist.
Das ist bei µC jetzt nicht ganz so wichtig, ich rate dennoch dazu. Denn
es wird nicht mehr lange dauern, bis auch "kleine" Mikrcocontroller
nicht mehr mit Konstanter Geschwindigkeit laufen werden. Für
Zeitmessungen nimmt man Timer, nicht CPU Leistung. Und damit
Kommunikations-Schnittstellen später mal durch andere ausgetauscht
werden können, sollte man sich auch dort nicht an feste
Übertragungsraten gewöhnen. USB, Ethernet, Bluetooth, WLAN, SD Karten
übertragen Daten nur unregelmäßig. An solche Verhältnisse sollte man
sich gewöhnen.
Wenn das alle Programmierer schon länger verinnerlicht hätten, dann
hätten wir jetzt nicht so viele serielle Geräte, die an USB Adaptern
versagen.
Stefan U. schrieb:> Wenn das alle Programmierer schon länger verinnerlicht hätten, dann> hätten wir jetzt nicht so viele serielle Geräte, die an USB Adaptern> versagen.
Na na na ....
Da liegt der Hase aber woanders im Pfeffer..
Heutzutage wird gern/blauäugig auf jegliches Handshake, auf der
seriellen, verzichtet.
Scheint irgendwie modern zu sein....
Aber vielleicht ist den meisten Entwicklern auch ein Handshake zu
kompliziert....
Das war "Früher" undenkbar.
Wenigsten XON/XOFF sollte doch drin sitzen...
;-)
Joachim B. schrieb:> Cableer schrieb:>> Ich habe es natürlich nicht als Delay implementiert sondern leere das>> fifo in einer Schleife bis zum carriage return.>> wo hattest du das geschrieben?>> ich las nur:>> cableer schrieb:>> Ich werde mal ein delay einbauen>> cableer schrieb:>> Problem solved.
Beschwerst du dich jetzt, daß er gegebene Ratschläge angenommen hat und
es richtig gemacht hat? Wäre es dir lieber gewesen, wenn er stattdessen
doch das delay verwendet hätte? :-D
---leute jibbet---
Huh schrieb:> Beschwerst du dich jetzt, daß er gegebene Ratschläge angenommen hat
nein niemals, sondern das er nicht geschrieben hat wie!
Huh schrieb:> ---leute jibbet---
jenau, du hast auch schon mal besser verstanden!
oder gibts von huh auch fakes wie von MaWin?