Arduino - är bibliotek som LiquidCrystal lika snabba som att skriva själv i assembler?

[BJ]

Om du funderar på en ascii display så kan du köra i vilket språk som helst helt ooptimerat och ändå kommer det att funka bra.
När det börjar fladdra beror på displayen, inte Arduinon...

Okej.

När det börjar handla om grafiska skärmar med färg och >320x240 i upplösning ... då är det en helt annan sak.

Ja, det kan jag tänka mig. Inte hållit på med det på
lösa skärmar, men däremot på Commodore 64 och pc
och Amiga. Där gick det åt mycket information, och tid.

[FormerMazda]

Och det Swech sa om "bero på skärmen" är också en sak att ta in.
LCDn i sig har ju en tid för att tända/släcka sina pixlar, där skulle jag säga är begränsningen i hastighet. Det syns ju på alla exempel som postats här, uppdateringen av text går fortare än LCDn i sig hinner med att tända/släcka pixlar.

[TomasL]

Har man en ren textskärm, finns ingen anledning att uppdatera snabbare än typ var annan sekund, eller enbart när data som presenteras ändrar sig (under förutsättning att data ändrar sig nån gång per 10 sekunder eller så.
Har man en grafisk skärm, så kanske man vill visa rörlig grafik, och då behövs uppdateringar lite oftare.
En grafisk skärm med enbart text, så uppdaterar man i regel på samma sätt som en ren textskärm.

Finns överhuvudtaget ingen anledning att uppdatera oftare.

[Icecap]

Min observation om max. 3gg/sek. har inget med displayens reaktiontid men om öga-hjärnans "reaktionstid".

I min test hängde displayen LÄTT med på mycket högre uppdateringshastighet.

[BJ]

Okej.

TomasL:
Jodå, det finns det visst.
Säg att man har en pulsgivare med ratt som man vrider på
för att välja olika menyer på en skärm.
Då är det bra om texten uppdateras lika fort som man
vrider på ratten. Jag har både gjort så själv, och sett det
på filmen som visades här.

[TomasL]

Nej, det finns ingen anledning, eftersom ögat ändå inte kan uppfatta så snabba förändringar, rent generellt.

[BJ]

Du har ofta rätt, Tomas, men här håller jag inte med.

[MadModder]

Måste flika in här att det är otroligt irriterande när en rattad meny bara ändrar sig med ett fåtal fps.
Minst 10 för att det ska bli något flyt.
Har man något gammalt mög som har en halv sekunds eftersläpningar så är det dags att skaffa ny disdplay.

Det är en helt annan sak med en knappstyrd meny.

[Electricguy]

Ja, rattade menyer och touch-lösningar måste vara responsiva. Annars blir man bara irriterad på skiten. Finns ingen anlending i dagens läge att göra en seg dålig lösning när högpresterande komponenter är praktiskt taget gratis många gånger.

[TomasL]

Om jag skrev, "När data ändras", naturligtvis så måste systemet vara responsivt, men det betyder ju inte att det måste uppdateras flera gånger i sekunden för jämnan.

[Icecap]

Jag har faktisk testat MMI (Man - Mashine Interface) så jag vet att man inte kan trycka på en tryckknapp (tänk t-bordsknapp) kortare tid än ~50ms och inte repetera snabbare än ~100ms.

Alltså kan man som debounce läsa knappar med 20Hz och om 2 läsningar efter varandra är identiska kan man anse att läsningen är stabil.

Ska man ha säkerhetskritiska knapptryckningar väljer jag 30Hz avläsningsfrekvens och 3 identiska läsningar.

Om man ska följa tal i ett display, t.ex. en DRO på en svarv eller så, är allt över 3 utläsningar/sekund likgiltigt.

Men det betyder INTE att det inte kan komma en utläsning mycket snabbt efter en knapptryckning.

I mitten av 90-talet byggde jag en tripmätare medelst en I80C196 μC. Jag hade ett 20x2 tecken LCD på samt en knappsats. Det var då jag testade detta för att upplösningen i längd hade jag i enstaka meter och vid 10,8 km/t blir det 3 m/s.

Det var då att jag indsåg att fladdrande tal inte ger något vettigt och att uppdatera utläsningen i lagom hastighet gav mycket bättre koll och uppfattning.

Dom som har en Janfire NH pelletsbrännare har sett detta i verkliga livet, den är responsiv men talen fladdrar inte.

[BJ]

Okej.

TomasL:
Då missförstog jag din formulering
"eller enbart när data som presenteras ändrar sig (under förutsättning att data ändrar sig nån gång per 10 sekunder eller så."

Självklart behöver man inte uppdatera den statiska texten
hela tiden när ingen vrider på ratten. Det gjorde inte jag heller.

[persika]

Uppdateringstid av LCD är normalt inget problem med Arduino.

Om du gör ett program som är större än bara några rader i Arduino, se då till att låta bli att använda classen String, använd istället strängar i C-stil char*. Med class String kan man få obegripliga konstigheter när programmet blir lite större.

[pi314]

Tankar om Arduino och bibliotek
Mina erfarenheter begränsar sig till dessa.

Inte sällan finns flera bibliotek att välja mellan. En del fungerar som man vill, men inte alla. Då får man leta vidare tills man hittar ett som fungerar. Ibland finns buggar i bibliotek. Ibland måste man fixa dessa.

Om jag skulle skriva ett bibliotek så skulle jag inte tveka om val av språk. Jag skulle välja C/C++ och kan inte se vad som skulle få mig att välja assembler.

Just nu överväger jag att skriva ett eget bibliotek till oled 128 x 64. Den från Adafruit tycker jag är för stor och Oscar Liangs tycker jag är lite för begränsad när det gäller val av teckenstorlek och hantering av specialtecken. Om det blir något så blir det i C/C++.

/Pi

[BJ]

Okej. Tack för tipsen.

Jag har tittat lite här:

https://docs.arduino.cc/learn/electronics/lcd-displays

och kan nog säga att jag förstår hur det mesta fungerar,
men jag är ganska nybörjare på Arduino.
Jag citerar:

Note that this circuit was originally designed for the Arduino UNO.
As the Arduino is communicating with the display using SPI,
pin 11 & 12 will change depending on what board you are using.
For example, on a MKR WiFi 1010, the SPI bus is attached to pin 8 & 11.

Fungerar det inte som på Pic-processorer, att man väljer
ett ben som kan ha en passande funktion, och så ställer man
in så att det blir den funktionen?
Så med Arduino så skulle man välja t.ex. ben 11, men enligt
texten så kan man tro att man måste välja just spi och
mosi eller miso...
Någon som förstår min enkla fråga?