LambdaSpeak CPC Sprach-Synthesizer, Sample Player, RTC, MP3, UART Erweiterung

[LambdaMikel]

Das passierte wenn der Wochentag "falsch" gelesen wird. Das kommt zwar statistisch nur selten vor, aber kann eben ab und an passieren.

Hast Du den Effekt auch beobachtet, TFM?
Ich muss gestehen dass ich die BASIC-Uhr nie länger also 20 Minuten an hatte... evtl. muss ich etwas länger warten, wenn ich das Resultat per I2C abhole von der RTC:

Code Select Expand


void ds3231_get(void) {

  twi_start();
  twi_send(0xD0);
  twi_send(0x00);

  twi_start();
 
  twi_send(0xD1);//ds3231 address+1 to read

  rtc_seconds = twi_receive(1);//1 to send ACK
  rtc_minutes = twi_receive(1);//1 to send ACK
  rtc_hours = twi_receive(1);//0 to send NACK

  rtc_hours &= 0b01111111;

  rtc_weekday = twi_receive(1);//1 to send ACK,read day
  rtc_date = twi_receive(1);//1 to send ACK,read date
  rtc_month = twi_receive(1);//1 to send ACK,read month
  rtc_year = twi_receive(0);//0 to send NACK,read year

  twi_stop();

  twi_start();
  twi_send(0xD0);
  twi_send(0x11);

  twi_start();
  twi_send(0xD1);//ds3231 address+1 to read
   
  rtc_msb_temp = twi_receive(0);

  twi_stop();

  rtc_hours_dec = BCDtoDEC(rtc_hours);
  rtc_mins_dec = BCDtoDEC(rtc_minutes);
  rtc_secs_dec = BCDtoDEC(rtc_seconds);

  rtc_year_dec = BCDtoDEC(rtc_year);
  rtc_month_dec = BCDtoDEC(rtc_month);
  rtc_date_dec = BCDtoDEC(rtc_date);
  rtc_weekday_dec = BCDtoDEC(rtc_weekday);


}


EVtl. brauche ich ein paar Delays... hier und dort.

Falls es nicht die CPC-Kommunikation ist, muss es die Leseroutine oben sein. Ich werde mal ein Testprogramm schreiben und laufen lassen auf dem ATmega, dass immer wieder die Zeit liest, und wenn was anderes für Wochentag für 1...7 kommt, weiss ich woran es liegt. Und kann entsp. Delays einbauen. Falls es das ist...

Aber zunächst bitte einmal die Port-Kommunikation mit dem KC Compact testen, mittels BASIC-Program oben. (&C5 mode).

[Rennert]

@Rennert, Hier ist noch einmal ein Test:

Code Select Expand


5 out &fbee,&C5
10 a=round(rnd(1)*255)
20 out &fbee,a
30 b=inp(&fbee)
40 if a<>b then print "*";
50 goto 10



Kannst Du das bitte einmal für ne Stunde laufen lassen und gucken, ob irgendwelche "*" auf dem Schirm erscheinen.

hab das mal über eine Stunde laufen lassen, du bekommst 0 Sterne!!!!

im RTC Prog hab ich mal eine Zeile eingefügt zum Test
845 if wd<1 or wd>7 then print"wd-error";wd:goto860

mal sehen was kommt.

[LambdaMikel]

0 Sterne ist schon Mal gut dass zeigt dass die Kommunikation prinzipiell I.O. ist. Der Rest kann durch Software Firmware etc. Korrigiert werden.

[TFM]

Cylon... in BASIC...

[TFM]

Das passierte wenn der Wochentag "falsch" gelesen wird. Das kommt zwar statistisch nur selten vor, aber kann eben ab und an passieren.

Genau, wir würden gerne den Wert von wd wissen, wenn out of range kommt.... 1 bis 7 kann es ja nicht sein, sonst würde es kein Out of Range geben. Ist muss also etwas > 7 sein.

Es ist &FF, das kommt kurz noch dem "zur Verfügung stellen" eines Wertes vor. In dem Falle einfach nochmal lesen.

[TFM]

Evtl. müssen wir ein Firmware-Update einspielen irgendwann, wenn das Problem mit TFMs MC auch auftritt...

Tut es, liegt aber in der Natur der Sache. Bei low-getters besteht dafür immer eine Chance, da der LS ja nicht "weiß" wenn der CPC gelesen hat. Bei &FF einfach nochmal lesen (also Kommando neu abschicken und lesen - natürlich :-))

[LambdaMikel]

Evtl. müssen wir ein Firmware-Update einspielen irgendwann, wenn das Problem mit TFMs MC auch auftritt...

Tut es, liegt aber in der Natur der Sache. Bei low-getters besteht dafür immer eine Chance, da der LS ja nicht "weiß" wenn der CPC gelesen hat. Bei &FF einfach nochmal lesen (also Kommando neu abschicken und lesen - natürlich :-))

Ich habe die Zeit für die "slow getters" reduziert... von 50 ms auf 10 ms. Ich kann das wieder hochsetzen. Ich denke, die 255 kommt NACH dem eigentlich Wert, nicht davor, oder? m.a.W., der CPC liest "zu spät" und verpasst den Wert.

In LS 1.95 und LS 1.99 war die slow getters Zeit glaube ich sogar 100 ms, nun sind es nur 10 ms, da ich dachte, das richt selbst für BASIC immer.

Falls es alledings os ist, dass ERST 255, dann der Wert, dann wieder 255, dann 0 gelesen wird, dann liest der CPC evtl. "zu schnell".

Für den Fall, das CPC "zu schnell" liest, kann man ja einfach noch einmal lesen, und sogar ohne Command:
also entweder reicht wie gesagt

dt = inp(&fbee)
dt = inp(&fbee)

schon, oder sowas wie

10 dt = inp(&fbee): if dt = 255 then goto 10

[Rennert]

Mit dem doppelten Abfragen hatte ich probiert, aber hat nix geändert.
Bei Zeit und Datum gibt's ja keine Probleme, da muss nix doppelt abgefragt werden. Nur der Wochentag zickt.

[Rennert]

So mein kleiner Test hat ergeben: siehe Foto
Habe wenn wd<1 oder >7 ist, dann das Prog beenden lassen und die gelesene Zahl anzeigen lassen.

[LambdaMikel]

Also 128... interessant.

Gut, probiere mal mittels

<zeile> wd= inp(&fbee): if wd = 128 then goto <zeile>

EDIT: Frage mich, ob das evtl. mit Garbage Collection etc. zu tun hat. Ich meine die Zeitverzögerungen.
Um das auszuschließen, dass das BASIC da kurzzeitig hängt, wäre es mal interessant, die Reihenfolge der Lese-Kommandos zu ändern. Also als erstes Wochentag, dann die anderen. Kommt dann evtl. der Lesefehler wieder beim letzten Lese-Kommando (Jahr oder so?)
Das spräche für die BASIC ist Schuld-Hypothese.

[LambdaMikel]

Evtl. müssen wir ein Firmware-Update einspielen irgendwann, wenn das Problem mit TFMs MC auch auftritt...

Tut es, liegt aber in der Natur der Sache. Bei low-getters besteht dafür immer eine Chance, da der LS ja nicht "weiß" wenn der CPC gelesen hat. Bei &FF einfach nochmal lesen (also Kommando neu abschicken und lesen - natürlich :-))

Prinzipiell könnte man natürlich die Hardware so auslegen, dass der LS mittels IOREQ & READ (also INP(&FBEE)) synchronisiert, dann wüsste LS, wenn der CPC gelesen hat. Würde aber andere Hardware erfordern.

Allerdings würde LS dann auch "hängen", wenn der CPC mal ein Byte nicht in dieser Weise "abholt". So ist es also asynchron und timing ist etwas kritisch. Synchron mit "Handshake" hätte sicherlich auch Vorteile.

[Rennert]

Müsste ich nochmal testen, obs wieder 128 ist.
Werde morgen mal Jahr mit Wochentag tauschen.

[LambdaMikel]

Hier ist mal eine Version mit der "if x = 128 then goto ..." Variante (RTC2.BAS)

[LambdaMikel]

Wenn es nur darum geht die Uhrzeit zu sehen, dann hab ich hier ein FutureOS Update (gerade frisch aus dem Ofen). Bitte mal angucken und bescheid sagen wenn was nicht tut oder fehlt. Viel Spaß damit. 

Hi TFM,
habe ich mit 6128 und M4 mit Installer installiert in Standard-ROM-Positionen.

Rom slot 10   ROM   RemoveUpload
Rom slot 11      RemoveUpload
Rom slot 12      RemoveUpload
Rom slot 13      RemoveUpload
Rom slot 14      RemoveUpload
Rom slot 15      RemoveUpload
Rom slot 16   ROM   RemoveUpload
Rom slot 17   ROM   RemoveUpload
Rom slot 18   ROM

|OS geht auch, und meldet auf das LS ROM - hatte alle anderen ROMs gelöscht btw. Also "firsches" M4.

Wie kann ich denn die Uhrzeit sehen damit?
Das Datum wird angezeigt, das kommt aber glaube ich vom M4... und die Uhrzeit started bei 0:0:0.

Sehe, dass das LS ROM da auch mit dabei ist??

EDIT - BZD Fehler für LS ROM... irgendwie kriege ich das gerade nicht deinstalliert mit dem M4 Browser. Zeigt keine ROMs, aber ist immer noch drin. Wie resette ich mein M4 Komplett???

[LambdaMikel]

OK, |lshelp zeigt das "LS ROM" in ROM 5 ist. Der Webbrowser vom M4 zeigt es aber als unbelegt an.
Weiss jemand, wie ich ein ROM per RSX aus dem M4 löschen kann?

EDIT - ah ok, M4 brauchte ein Reset... jetzt ist es weg. OK, noch mal mit neuem FOS installer versuchen...