Man könnte ja das _delay_ms durch ein Timer-basiertes delay ersetzen,
oder durch eine ausgezählte Schleife, wenn die Displays zu langsam sind.
Falls nur Optimierung das Ziel ist, kann man die 100 ms vielleicht nach
geeigneten Vorversuchen kürzen, wenn einem nicht Exemplarstreuung oder
Temperaturabhängigkeit einen Strich durch die Rechnung machen.
Das "_delay_ms(x)" spielt hier keine Rolle. Kann auch einen Timer
verwenden, hilft hier nicht weiter. Das Problem ist, dass die Libary
selber für den Sendevorgang delays verwendet.
Herr Bert schrieb:> Das Problem ist, dass die Libary> selber für den Sendevorgang delays verwendet.
Ich weiss nicht, was dein Display genau kann, aber viele Displays lassen
sich über ein Flag oder eine Leitung abfragen, ob sie fertig und bereit
für neue Daten/Kommandos sind.
Eine Interrupt-Leitung des Displays existiert vielleicht auch?
Leider ist immer noch nicht klar, um was für ein Display es überhaupt
geht.
Auch die u8glib unterstützt eine Menge.
Und das Problem wurde auch nicht wirklich hinreichend beschrieben.
Ein Display mit I2C Schnittstelle und u8glib Unterstütung wäre eines mit
einem SSD1306 Controller.
Und in der Timing-Tabelle aus dem Datenblatt erkenne ich jetzt erstmal
keinen Grund für Delays.
Die ganz unten erwähnten t_idle mit 1,3µs sind ja die Wartezeit zwischen
zwei Übertragungen und nicht etwa zwischen den einzelnen Bytes einer
Übertragung.
Die Lib wird ja hoffentlich nicht jedes Zeichen einzeln übertragen, aber
auch dann sind 1,3µs nicht wirklich viel.
Aber, ein Problem könnte das I2C sein, gerade die I2C Einheit in den
AVRs ist ja eher stumpf und somit schwer Software-lastig.
Pro Byte das auf den I2C gelegt werden dauert das ja schon mindestens
20µs.
Da ziehe ich SPI einfach vor, mit nur zwei Pins mehr für den Anschluss
an sich und einem Pin pro Baustein mehr wird man den ganzen
Address-Overhead los und kann die Daten auch noch erheblich fixer los
werden.
Der SSD1306 Controller läuft am SPI bis 10MHz.
Tja, bei sowas hilft eigentlich nur die Library zu zerpflücken und an
die Anforderungen anzupassen oder gleich selber entsprechenden Code zu
schreiben.
Dear Bert,
Look what the author of ug8lib said on Arduino forum:
"Hi
There is no clear screan as such, instead you can say, that FirstPage
will clear the screen.
To implement the switching between your sensors, you should implement
two or more "draw" precodures. Let me call these procedures draw1() and
draw2().
Now you need a new master draw procedure, let me call this "draw()".
draw1() and draw2() are called from draw(), but this depends on a
globale "state" variable, like this:
Code: [Select]
void draw(void)
{
if ( state == 0 )
draw1();
else
draw2();
}
Now you need to call draw() within the picture loop (like in your code).
Additionally you must change "state" from 0 to 1 and back to 0 every 10
seconds. I think this often refered as "blink without delay()" problem.
Another option is to implement the picture loop twice The first picture
loop calls draw1(), then add a 10 sec delay, then implement second
picture loop with draw2() and add a delay again."
Hope it halps you.
Best regards
Das ist ein alter Beitrag. Die u8glib wird auch nicht mehr weiter
entwickelt. Es gibt bereits eine u8glib2. TROTZDEM gibt es gute Gruende
auf diese Frage noch einmal zu antworten.
Die u8glib ist nach meiner Erfahrung ziemlich klein. Fuer ein OLED
128x64 mit SSD1306 (iC2) VIEL KLEINER als die Adafruit SSD1306 und auch
kleiner als die u8glib2.
Ich benoetige sie auf einem Arduino nano. Da ist sie bei mir fast ca.
30% kleiner, was vorwiegend die dynamischen Variablen betrifft. Das
heist am Ende, mit einer Adafruit SSD1306 library bin ich bei 106%
Speicherauslastung und das ganze System funktioniert nicht. Mit u8glib
bin ich gerade bei so ca. 65%.
ALLERDINGS hat der Autor dieser Frage ganz Recht. Das delay im "picture
loop" stoert GANZ GEWALTIG, weil es natuerlich alle anderen Prozesse
ganz stoppt. Mein Arduino nano kommuniziert ueber das Internet mit
Blynk. Dort lese ich temp. Sensore aus und schalte auch die Ausgaenge
des Nano. Mit einem "delay" funktionert das ganze nicht richtig.
Den "picture loop" habe ich natuerlich aus dem "loop" entfernt und
anstelle des "delay" lasse ich zaehlen. Bei jeweils ca. 5
"Wiederholungen" von "draw1" und "draw2".....schaltet das display
ungefaehr im Rhythmus von 1,5 sek. zwischen den beiden Seiten draw1 und
draw2 hin und her. Das beeinflusst den gesamten Ablauf am wenigsten. Bei
Interesse poste ich den ganzen code. Jetzt hier nur der entsprechende
Teil zur Frage :
....und wer das besser kann und weiss.....bitte hier beschreiben !! :-)
1
voidsendSensor1(){
2
for(inti=0;i<5;i++){//XXXXXXXXXXXXXXXXXXX
3
u8g.firstPage();
4
do{draw1();}
5
while(u8g.nextPage());};
6
7
sensors.requestTemperatures();
8
temperature1=sensors.getTempC(tempSensor1);// temp in F. getTempF
9
dtostrf(temperature1,1,2,temperatureString1);
10
Blynk.virtualWrite(V1,temperature1);// Send to Blynk virtual V1 "pin"
11
}
12
13
voidsendSensor2(){
14
for(inti=0;i<5;i++){//XXXXXXXXXXXXXXXXXX
15
u8g.firstPage();
16
do{draw2();}
17
while(u8g.nextPage());};
18
19
sensors.requestTemperatures();
20
temperature2=sensors.getTempC(tempSensor2);// temp in F. getTempF
21
dtostrf(temperature2,1,2,temperatureString2);// Format
22
Blynk.virtualWrite(V2,temperature2);// Send to Blynk virtual V2 "pin"
