Unerwünschtes Verhalten (WS2812B)

Hallo,

ich bastel gerade an meiner Equinox in AVR-GCC.

Der Code ist nicht fehlerfrei. Zumal derzeit noch keine Kommunikation mit der DS3231 erfolgt. Lediglich den SQW Takt von 1024kHz greife ich von dieser ab, welche ich zuvor mit RS1 und RS2 gesetzt hatte.

Nun habe ich das Problem, sobald ich #define ANTI_CLOCKWISE(gegen den Uhrzeigersinn ist bei mir Notwendig, da ich die Adafruit NeoPixel RIng nach hinten an die Wand strahlen lasse) setze, dass ich bei jeder vollen Minute eine falsche Led habe. Ich habe dazu testweise über die UART Schnittstelle einmal den Verlauf einer Minute ausgegeben mit -2 bis +2 (vor und nachgehende Sekunde/Led). Dort kann ich keinen Fehler feststellen.

*   Project: DS3231
*   Created: 19.08.2014 18:25
* Last Edit: 19.08.2014 18:25
*    Author: sschultewolter

00:(01|00|59|58|57)     01:(00|59|58|57|56)     02:(59|58|57|56|55)
03:(58|57|56|55|54)     04:(57|56|55|54|53)     05:(56|55|54|53|52)
06:(55|54|53|52|51)     07:(54|53|52|51|50)     08:(53|52|51|50|49)
09:(52|51|50|49|48)     10:(51|50|49|48|47)     11:(50|49|48|47|46)
12:(49|48|47|46|45)     13:(48|47|46|45|44)     14:(47|46|45|44|43)
15:(46|45|44|43|42)     16:(45|44|43|42|41)     17:(44|43|42|41|40)
18:(43|42|41|40|39)     19:(42|41|40|39|38)     20:(41|40|39|38|37)
21:(40|39|38|37|36)     22:(39|38|37|36|35)     23:(38|37|36|35|34)
24:(37|36|35|34|33)     25:(36|35|34|33|32)     26:(35|34|33|32|31)
27:(34|33|32|31|30)     28:(33|32|31|30|29)     29:(32|31|30|29|28)
30:(31|30|29|28|27)     31:(30|29|28|27|26)     32:(29|28|27|26|25)
33:(28|27|26|25|24)     34:(27|26|25|24|23)     35:(26|25|24|23|22)
36:(25|24|23|22|21)     37:(24|23|22|21|20)     38:(23|22|21|20|19)
39:(22|21|20|19|18)     40:(21|20|19|18|17)     41:(20|19|18|17|16)
42:(19|18|17|16|15)     43:(18|17|16|15|14)     44:(17|16|15|14|13)
45:(16|15|14|13|12)     46:(15|14|13|12|11)     47:(14|13|12|11|10)
48:(13|12|11|10|09)     49:(12|11|10|09|08)     50:(11|10|09|08|07)
51:(10|09|08|07|06)     52:(09|08|07|06|05)     53:(08|07|06|05|04)
54:(07|06|05|04|03)     55:(06|05|04|03|02)     56:(05|04|03|02|01)
57:(04|03|02|01|00)     58:(03|02|01|00|59)     59:(02|01|00|59|58)

Den Fehler kann ich auf diese beide Funktionen eingrenzen, dennoch habe ich den kompletten Code unten aus meiner Dropbox abgehangen.

// Korrigiert die fehlerhaften Zugriffe
int16_t leds_index(int16_t led)
{
	if(led < 0) led = NUM_LEDS + led;
	else if(led >= NUM_LEDS) led = led - NUM_LEDS;

	#ifdef ANTI_CLOCKWISE
	led = (NUM_LEDS -1) - led % NUM_LEDS;
	#endif
	
	return led;
}
void leds_clock2(int8_t _hour12, int8_t _minute, int8_t _second, int8_t index)
{
	leds_clear();
	
	leds_rgb(_second-2, 0, 0, fade[127-index]);
	leds_rgb(_second-1, 0, 0, fade[255-index]);
	leds_rgb(_second, 0, 0, fade[255]);
	leds_rgb(_second+1, 0, 0, fade[128+index]);
	leds_rgb(_second+2, 0, 0, fade[index]);
	
	leds_rgb(_hour12*5-1, 255, 0, 0);
	leds_rgb(_hour12*5, 255, 0, 0);
	leds_rgb(_hour12*5+1, 255, 0, 0);

	leds_rgb(_minute, 0, 255, 0);
	
	leds_update();
}

AVR-GCC Code:

Video:

Meinst du vielleicht eher das?

led = (NUM_LEDS - 1 - led) % NUM_LEDS;

Auch bei Modulo geht Punkt vor Strich

:frowning:

Das hatte ich vollkommen übersehen. Mir fällt aber auch ein, dass es hier überhaupt nicht hingemusst hätte.

	#ifdef ANTI_CLOCKWISE
	led = (NUM_LEDS -1 - led);// % NUM_LEDS;
	#endif

Nun verschluckt er 2 nachlaufende Sekunden,
habe es etwas übersichtlich mit der Ausgabe noch einmal gemacht

00:(01|00 (59) 58|57)

Richtige Sekunde:(LED-2|LED-1 (LED) LED+1|LED+2)

OT: Sieht jemand bei den 2. Zeilen hier drüber Smileys? Wenn nein, dann funnktioniert "Don't use smileys." für alle.

00:(01|00 (59) 58|57)   01:(00|59 (58) 57|56)   02:(59|58 (57) 56|55)
03:(58|57 (56) 55|54)   04:(57|56 (55) 54|53)   05:(56|55 (54) 53|52)
06:(55|54 (53) 52|51)   07:(54|53 (52) 51|50)   08:(53|52 (51) 50|49)
09:(52|51 (50) 49|48)   10:(51|50 (49) 48|47)   11:(50|49 (48) 47|46)
12:(49|48 (47) 46|45)   13:(48|47 (46) 45|44)   14:(47|46 (45) 44|43)
15:(46|45 (44) 43|42)   16:(45|44 (43) 42|41)   17:(44|43 (42) 41|40)
18:(43|42 (41) 40|39)   19:(42|41 (40) 39|38)   20:(41|40 (39) 38|37)
21:(40|39 (38) 37|36)   22:(39|38 (37) 36|35)   23:(38|37 (36) 35|34)
24:(37|36 (35) 34|33)   25:(36|35 (34) 33|32)   26:(35|34 (33) 32|31)
27:(34|33 (32) 31|30)   28:(33|32 (31) 30|29)   29:(32|31 (30) 29|28)
30:(31|30 (29) 28|27)   31:(30|29 (28) 27|26)   32:(29|28 (27) 26|25)
33:(28|27 (26) 25|24)   34:(27|26 (25) 24|23)   35:(26|25 (24) 23|22)
36:(25|24 (23) 22|21)   37:(24|23 (22) 21|20)   38:(23|22 (21) 20|19)
39:(22|21 (20) 19|18)   40:(21|20 (19) 18|17)   41:(20|19 (18) 17|16)
42:(19|18 (17) 16|15)   43:(18|17 (16) 15|14)   44:(17|16 (15) 14|13)
45:(16|15 (14) 13|12)   46:(15|14 (13) 12|11)   47:(14|13 (12) 11|10)
48:(13|12 (11) 10|09)   49:(12|11 (10) 09|08)   50:(11|10 (09) 08|07)
51:(10|09 (08) 07|06)   52:(09|08 (07) 06|05)   53:(08|07 (06) 05|04)
54:(07|06 (05) 04|03)   55:(06|05 (04) 03|02)   56:(05|04 (03) 02|01)
57:(04|03 (02) 01|00)   58:(03|02 (01) 00|59)   59:(02|01 (00) 59|58)

hi,

ich verstehe diesen zahlenfriedhof nicht ganz. vor einem jahr oder mehr hab' ich auch für eine equinox geschrieben, aber nicht fertiggemacht. damals hab ich das problem mit den 3 bzw. 5 leds, die faden sollen, mit einem array gelöst.

der code, den ich anhänge, war glaub' ich einer, der funktioniert. vielleicht bringt er Dich auf neue ideen.

#include <FastSPI_LED2.h>
#include <Wire.h> 

#define NUM_LEDS 60
struct CRGB { byte g; byte r; byte b; };
struct CRGB leds[NUM_LEDS];
WS2811Controller800Mhz<12> LED;

uint8_t h;
uint8_t m;
uint8_t s = 15;

byte sdim = 0;
byte mill_akt;
byte mill_alt = 39;

boolean neu = true;

byte loga[] = {0,0,0,0,0,1,1,1,2,2,3,4,5,6,7,8,9,10,11,13,14,16,18,19,21,23,26,28,30,
               32,35,38,40,43,46,49,52,55,59,62,66,70,73,77,81,85,90,94,98,103,108,112,
               117,122,127,133,138,144,149,155,161,167,173,179,185,192,198,205,212,219,
               226,233,240,247,255};
               
byte ledrf[] = {58,59,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,
                26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,
                50,51,52,53,54,55,56,57,58,59,0,1,2};

byte bcdToDec(byte val)
{
  return ( (val/16*10) + (val%16) );
}

boolean sek_sig() {
  if (digitalRead(8) == HIGH) {
    if (neu == true) {
      neu = false;
      return true;
    }
  } else {
    neu = true;
  }
  return false;
}

void holeZeit() {
  Wire.beginTransmission(0x68);
  Wire.write(byte(0));
  Wire.endTransmission(); 
  Wire.requestFrom(0x68, 7);
  s = bcdToDec(Wire.read() & 0x7f);
  m = bcdToDec(Wire.read());
  h = bcdToDec(Wire.read() & 0x3f);
  h = (h % 12)*5+int((m+5)/12);
}

void setLED(byte led_, byte r_, byte g_, byte b_) {
  leds[led_].r = r_;
  leds[led_].g = g_;
  leds[led_].b = b_;
}

void setLEDs() {
  memset(leds, 0, 180);
  setLED(ledrf[s+5], 0, loga[sdim], 0);
  setLED(ledrf[s+4], 0, loga[sdim+25], 0);
  setLED(ledrf[s+3], 0, loga[sdim+50], 0);
  setLED(ledrf[s+2], 0, loga[74-sdim], 0);
  setLED(ledrf[s+1], 0, loga[49-sdim], 0);
  setLED(ledrf[s  ], 0, loga[24-sdim], 0);
  setLED(ledrf[m+1], 30, 0, 0);
  setLED(ledrf[m+2], 255, 0, 0);
  setLED(ledrf[m+3], 30, 0, 0);
  setLED(ledrf[h+2], 0, 0, 255);
  LED.showRGB((byte*)leds, NUM_LEDS);
}

void setup() {
  pinMode(8, INPUT);
  Wire.begin();
  LED.init();
  memset(leds, 0, 180);
  LED.showRGB((byte*)leds, NUM_LEDS);
  Wire.beginTransmission(0x68);
  Wire.write(0x07);
  Wire.write(0x10);
  Wire.endTransmission();
  holeZeit();
  s--;
//  Serial.begin(9600);
}

void loop() {
  mill_akt = millis() % 40;
  if (mill_akt < mill_alt) {
    setLEDs();
    sdim++;
    if (sdim > 24) {
      sdim = 0;
    }
  }
  mill_alt = mill_akt;
  if (sek_sig() == true) {
    s++;
    sdim = 0;
    if (s>59) {
      holeZeit();
    }
  }
}

gruß stefan

Hi Stefan,

den Code kenn ich nur zu gut von dir :wink:

  setLED(ledrf[s+5], 0, loga[sdim], 0);
  setLED(ledrf[s+4], 0, loga[sdim+25], 0);
  setLED(ledrf[s+3], 0, loga[sdim+50], 0);
  setLED(ledrf[s+2], 0, loga[74-sdim], 0);
  setLED(ledrf[s+1], 0, loga[49-sdim], 0);
  setLED(ledrf[s  ], 0, loga[24-sdim], 0);

Den Teil werde ich bei mir noch einmal testen. Aber ich meine dass das Fade etwas abrupter aussah als bei meiner Lösung. Den Zahlenwirrwirr hab ich oberhalb (bunt) versucht zu erklären.

Die ArrayVariante hat mich immer gestört mit der Tipparbeit :smiley: und ich sehe keinen wirklichen Vorteil, dieses zu nutzen. Ich habe derzeit die Frequenz auf 128Hz stehen, in der die Leds geändert werden. Werde diese aber voraussichtlich wieder minimieren auf 64Hz. Habe eigentlich ordentlich Rechenzeit über. Laufen soll das ganze später bei 8MHz mit interen PLL Clock des Attiny84 oder 85.

Hab mit dem Attiny85 eigentlich alles am laufen bis auf die RTC. Dieser hat jedoch keine eingebaute I2C Schnittstelle. Muss da mal sehen wie ich die USI am besten zurechtbiege. Der Attiny macht dann nicht mehr sonderlich viel. Alle ~8000 Zyklen wird ein Interupt vom DS3231 kommen. (1024kHz).

Hatte ja bereits vieles getestet, dass die Zeit mit dem DS3231 immer übereinstimmt. Das hat immer Probleme mit der Anzeige bereitet, wenn ich diese mal wieder synchronisiert hab. Nun sollte ein Sync eigentlich nicht mehr nötig sein. Der einzige sync der dann erfolgt ist beim Reset bzw. Start.

Wobei eine Frage hätte ich, die mir vielleicht dazu einer beantworten könnte.

Ich habe vorhin mal Testweise die Uhrzeit gestoppt. Erst lief er richtig und vorhin noch einmal geschaut, da hatte er einen Versatz drin. Ist der 1024Hz SQW des DS3231 ebenfalls Temperaturkompensiert, oder erfolgt das lediglich in der RTC selber und nur über I2C auslesbar? Ich bin mir halt nicht sicher, ob ich zwischenzeitig doch einen neuen Code hochgeladen habe. Werd nun nochmal die Zeit abgleichen und bis morgen abwarten.

Hab es mit deinem Fadearray noch einmal versucht und auf mein System angewandt. Die Gammacorrection erfolgt innerhalb der leds_b() Funktion aus einem Array.

void leds_clock3(int8_t _hour12, int8_t _minute, int8_t _second, int8_t ct)
{
	leds_clear();
	
	leds_b(_second-4,	63-ct);
	leds_b(_second-3,	127-ct);
	leds_b(_second-2,	191-ct);
	leds_b(_second-1,	255-ct);
	leds_b(_second,		ct+192);
	leds_b(_second+1,	ct+128);
	leds_b(_second+2,	ct+64);
	leds_b(_second+3,	ct);

	leds_r(_hour12*5-1,	255);
	leds_r(_hour12*5,	255);
	leds_r(_hour12*5+1, 255);

	leds_g(_minute,		255);
	
	leds_update();
}

Inzwischen habe ich die Ursache für die Ungenauigkeit festlegen können. Problem ist, dass meine ISR 1024/s aufgerufen werden soll. Die WS2812B jedoch deaktiviert während der Ansteuerung den Interrupt, sodass einige Takte verschluckt werden.

Gibt es eine Möglichkeit, die Taktrate von 1024Hz zu reduzieren? 1Hz ist zu wenig für meine Genauigkeit. 64Hz wären genau passend. Hatte schon überlegt, einen kleinen Attiny85 (kleinere hab ich gerade nicht da) zu nutzen, der die Takte direkt von DS3231 zählt und nach jedem 16. Aufruf der ISR einen Ausgang toggelt, den ich auswerte.

Mann muss nicht immer µC für alles verwenden. Wenn du schon ein IC verbauen kannst, dann kann man dafür auch Flip-Flops oder Frequenzteiler verwenden. Die sind DIP14 oder DIP16, aber du musst nichts extra programmieren

74HC4060 ist ein 14-stufiger Binärzähler:

An QD solltest du 1/16 der Eingangsfrequenz haben

Oder ein Dual 4-Bit Binär-Counter in DIP14:
http://www.fairchildsemi.com/ds/74/74VHC393.pdf

Oder 8-Bit in DIP16:
http://www.nxp.com/documents/data_sheet/74HC590.pdf

Anders als beim HC4060 sind bei denen die ersten drei Flip-Flops auch herausgeführt, was Teiler von 2, 4 und 8 ermöglicht, falls es doch schneller gehen soll

Das mir schon klar, dass es nicht immer ein MCU sein muss. Hatte ich auch nicht zwingend vor, nur habe ich die Sachen gerade da.

Wobei, ich muss mal schaun, Flip-Flops dürfte ich sogar haben. Irgendwelche CD xy Teile. Bin mir da nicht sicher, muss mal schauen. Hab die damals für eine Tasterschaltung am PC bestellt (8-9Jahre her). Sind aber nie zum EInsatz gekommen.

Von den 74er habe ich auf jedenfall keine da. Lässt sich aber bestellen, DIP muss nicht sein :wink: Werde mir was im SOIC raussuchen.

Ein Flip-Flop macht geteilt durch 2. Mit einem Quad FF wärst du auch bei 1/16.

Okay, die CDx waren die falschen ICs die ich im Kopf hatte. Das sind Hex Buffer / Inverter : CD4049UBE.
Jedoch habe ich 74HC4017 noch rumliegen (ebenfalls aus der gleichen Zeit unbenutzt).
Scheint ein 10-stufiger Binärzähler zu sein.

Mit dem Reset des ICs dürfte es möglich sein, dass hochzählen bei 16 zu beenden. Müsste dann doch im Endeffekt so ablaufen, dass sobald Q4 HIGH kommt (16), der Reset(MR) aufgelöst wird. CP fängt somit dann wieder bei Q0 anzuzählen.
Damit wäre ich aber dann wenn ich das richtig sehe bei 17 Takten. Ein AND-Gatter habe ich nicht mehr rumfliegen leider. Mit 1 Takt versatz wäre nicht so schlimm für den Test. Möchte halt nur wissen, ob der 64Hz Takt ausreicht, das die Leds nicht in meinen Interupt reinfuschen.

http://www.nxp.com/documents/data_sheet/74HC_HCT4017.pdf

Alternativ vorerst mit Attiny85 bis die ICs da sind. Werde mir nachher mal einen paar Sätze holen.

Das ist kein Binärzähler, sondern ein Dezimalzähler. Der schaltet bei jedem Schritt den nächsten Ausgang ein. Ein Binärzähler ist wirklich ein astreiner Frequenzteiler:

Ein Dezimalzähler/decade counter sieht so aus:

Den kann man hier aber auch als Frequenzteiler verwenden. Eben mit dem Reset wie du es beschrieben hast. Aber du kannst dann nur maximal durch den Faktor 10 teilen! Wie du in dem Diagramm oben siehst, hast du bei einem 4-stufigen Dezimalzähler nur jeden 4. Eingangsimpuls ein Impuls an irgendeinem Ausgang. 16 ist also mit 10 Stufen nicht möglich.
Oder auch Seite 4 im HC4017 Datenblatt. Nach 10 Impulsen hast du wieder einen Impuls auf den Ausgängen. Lediglich um einen Takt versetzt.
Aber ca. 102 Hz wären da wohl möglich. Und das ohne extra Reset.

Und du solltest das auch als Frequenzteiler betrachten. Nicht so sehr als Zähler. Es geht darum dass an einem Ausgang nur jeder x-te Eingangs-Impuls erscheint.

Hab mir mal die 393 (DIP + SMD) sowie 590 (SMD) jeweils 5 Stk geordert. Werde dann berichten, wie es läuft, ob der ISR dann ausreichend Zeit hat.

hi,

schau' Dir nochmal meine loop an:

void loop() {
  mill_akt = millis() % 40;
  if (mill_akt < mill_alt) {
    setLEDs();
    sdim++;
    if (sdim > 24) {
      sdim = 0;
    }
  }
  mill_alt = mill_akt;
  if (sek_sig() == true) {
    s++;
    sdim = 0;
    if (s>59) {
      holeZeit();
    }
  }
}

ich arbeite mit dem sekundentakt der RTC und generiere mit millis und modulo die unterteilungen. hier im code nur 25mal in der sekunde, aber da kann man ja auch kleinere werte als 40 nehmen. probier' doch mit mod 20, also 50Hz, oder sogar mit 100 Hz.

miß einmal die millis, die nach dem LEDs beschicken "übrigbleiben" (aber auch in der 60. sekunde messen).

es müssen nicht einmal ganzzahlige werte rauskommen, weil jede sekunde durch das sekundensignal wieder "neu begonnen" wird.

gruß stefan

Hi Stefan,

ich habe vor einen Attiny85 ohne Quarz einzusetzen. Dieser sollte ohne Probleme auch mit 8MHz (internal PPL) mit den Ws2812B.
millis() Funktion habe ich derzeit keine bei mir eingebaut, da ich es so fein nicht brauche.

Das Problem ist, dass mir die interene Uhr immer auf dauer wegdriftet beim deaktivieren der Interupts. Einen Sync mit AVR-GCC habe ich noch nicht am laufen. Ich wollte auch einen Sync nicht unnötig häufig machen. Einmal bei Start und alle 24Uhr prüfen ob Abweichung und wenn Abweichung vorhanden ist, sync. mod 20 geht, jedoch finde ich es deutlich besser aussieht bei 14Hz mehr. 100 wird nicht nötig sein. Ich möchte mir halt die Frequenz zur Basis 2 bilden.

Mit millis müsste ich gleich mal eben in der IDE testen. Rein rechnerisch komme ich auf 1.800µs bei 60x24Bit.

hi, stefan,

man kann es nicht werten, aber ich finde es interessant, wie unterschiedlich man gewisse dinge sehen kann.

es ist mir schon oft aufgefallen, daß interrupts von vielen hier als "elegant" gesehen werden. vielleicht liegt es daran, daß sie nicht allzuleicht zu händeln sind und man stolz ist, wenn man's hinkriegt.
für mich sind interrupts eine notlösung, die man anwendet, wenn man nicht weiß, wann was passiert. manchmal ist das notwendig, aber Du baust eine uhr ! und gerade mit WS2812 und nointerrupts() ist das (für mich) alles andere als elegant.

da finde ich's schon besser, sich auszurechnen, wieviel zeit was braucht, einen schönen polster dazuzurechnen und dann den sketch danach zu schreiben.
den takt der RTC mit 1Hz kannst Du nicht verpassen, weil es ein gleichmäßiges rechtecksignal ist (1/2sek on, 1/2sek off) und man muß ja nicht wie ich jede minute einen sync machen, da hast Du natürlich recht.

ich hatte damals auch probleme, einen fernsteuerungscode dazuzubauen, wahrscheinlich wegen des gleichen problems mit nointerrupts. dann wollte ich die uhr zur (noch nicht existenten) neuen licht/haussteuerung mit RS485 anbinden, und dann ist mir (zusätzlich zu meiner natürlichen faulheit), die couch zusammengebrochen, und da stehe ich jetzt beim couchbau. :stuck_out_tongue:

wie willst Du Deine uhr einstellen /farben ändern usw.? da wird's sicher auch nicht leicht mit den interrupts. malerlein hat es damals mit IR gemacht, und er sagte, es geht.

übrigens: hat jemand was von malerlein (jürgen) gehört ??? ich mach' mir sorgen um den lieben, er ist ja noch älter als ich. :sweat_smile:

gruß stefan

[quote author=Eisebaer link=topic=262375.msg1852052#msg1852052 date=1408737049]
hi, stefan,

man kann es nicht werten, aber ich finde es interessant, wie unterschiedlich man gewisse dinge sehen kann.

es ist mir schon oft aufgefallen, daß interrupts von vielen hier als "elegant" gesehen werden. vielleicht liegt es daran, daß sie nicht allzuleicht zu händeln sind und man stolz ist, wenn man's hinkriegt.
für mich sind interrupts eine notlösung, die man anwendet, wenn man nicht weiß, wann was passiert. manchmal ist das notwendig, aber Du baust eine uhr !  und gerade mit WS2812 und nointerrupts() ist das (für mich) alles andere als elegant.

Mit elegant oder nicht elegant hat das nichts zu tun. Es gibt aber Sachen, die möchte man zählen oder was weiß ich, sobald sie eintreffen. Richtig, ich habe vor, überhaupt keinen Sync zu machen. Da sollte mir auch gelingen, wenn ich jeden Interupt erwische.

Denn das Problem ist, wenn der Sync erfolgt, ist es möglich, dass diese um mehrere Sekunden /Minuten falsch geht. Wenn man dann gerade sein Projekt zeigt und dieser Fehler offentsichtlich wird, sieht das mehr als unangenehm aus.

Mit der Fernsteuerng ist das gut möglich. Wie gesagt, ich nutzte nicht mehr die FastLed, wobei diese vermutlich nicht anders reagiert bei der Aktivität. Irgendwann ist man an einem Punkt. Alles würde theoretisch sauber laufen doch dann merkt man, es ist nicht synchron wegen fehlender Interrupts.

Derzeit stelle ich die Uhr über 2 Taster ein. Länger als x-ms gedrückt komme ich in den Config-Mode. Dort blinkt dann einer der Zeiger, die ich dann stellen kann.
Farben sind noch nicht geplant, wobei das bei Attiny85 ohne Hardware USART/UART schwierig wird.

Ähm, mit unseren Malerlein(Jürgen) macht mir übrigens auch sorgen. Nicht erst seit heute, sonder schon seit ein paar Wochen. Hatte auch schon geschaut, wann er zuletzt online war. Das ist etwas her.

Rentner war er ja soweit ich weiß schon. Kein C-Profi, aber ein netter Forumsuser. Hoffe mal, er hat einen längeren Urlaub und kommt wieder! Wird sonst etwas einsam hier. Ich würde sagen, 10 User kann ich hier gut einschätzen und Uwe habe ich persönlich auf der Maker Faire getroffen.
[/quote]

P.S. Blocking Code schreibe ich immer noch nicht. Meine loops bzw whiles durchlaufen immer den schnellstmöglichen Zeitraum. Aber gerade bei hartewn Timings kann es schnell mal sein, dass es hier mehr oder weniger 1-2ms dauert. Das aber immer noch besser als jeder Einsatz von delays

Edit 2: Wenn eine 1kHz im ISR nicht eingefamgem werden kann, wird es auch nichts, diese im normalen Ablauf zu erfassen. Bei einem Teiler von 16 sollte das weder in der ISR noch in der loop ein Problem sein.

@sschultewolter:
Ich habe mir deinen Code angesehen und muss schon sagen das hier alles auf kompakten performanten schlanken Code getrimmt ist.
Versuche alles was C (++) angeht aufzusaugen, und habe bei deinen Code etliche Dinge gesehen die hinterher einen "Aha Effekt" bei mir auslösten.
Inzwischen beginnt mir C++ sogar zu gefallen, und das sage ich als Pascal Mensch :wink:

Die Nutzung der ISR ist meiner Meinung nach doch immer besser als polling. (Wenn man nicht vorher weiß wann was passieren soll)
Innerhalb der ISR sollte man sich kurz fassen.
Und zu händeln sind ISR's sowohl in der Arduino Umgebung als auch im mbed Projekt sehr einfach.
(Bei meinem alten 8051 Pascalcompiler was das nicht so, da musste man sich um die Register,Stack kümmern.
Wenn es eine längere Funktion ist, setze ich in der ISR ein Flag, das ich dann in der mainloop auswerte und den Code dort ausführe.
Ist so meine Überlegung dies zu optimieren, ob es der richtige Weg ist weiß ich nicht. Bin reiner Autodidakt.

Wegen malerlein,
Ich habe diesen Nick auch schon in anderen Arduino Foren gesehen und anhand der Beiträge (Projekte) war zu erkennen das es sich um Jürgen handelt.
Auch dort ist er nicht mehr aktiv. Denken wir positv, das muss ja nichts schlimmes bedeuten.

rudirabbit:
...
Wegen malerlein,
Ich habe diesen Nick auch schon in anderen Arduino Foren gesehen und anhand der Beiträge (Projekte) war zu erkennen das es sich um Jürgen handelt.
Auch dort ist er nicht mehr aktiv. Denken wir positv, das muss ja nichts schlimmes bedeuten.

Hab ihm mal eine Email geschrieben.
Grüße Uwe

Jürgen macht sicher nun Massenfertigung von seinen Leuchttürmen, da bleibt keine Zeit im Forum herumzulungern ^^

Habe es nun mal versucht ohne externe Hardware.

Nutze T0 als externe Quelle und lese die fallenden Flanken. Sobald der Zähler auf 16 kommt, kommt der Overflow Interupt.
Das mit ISR hatte ich mir auch schon gedacht.
Das Problem hier ist/war jedoch nicht die Interuptlänge, sondern die Zeit, wo die Interupts fürs Bitbanging gesperrt wurden.

Werde gleich mal nur ein flag setzen, was dann in die Endlosschleife mit einfließt.

Werde gleich mal nur ein flag setzen, was dann in die Endlosschleife mit einfließt.

Da bin ich schon neugierig ob dies eine Verbesserung bringt ????