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

[BJ]

Jag har tänkt länge att koppla en alfanumerisk lcd-skärm
till en mikrodator och programmera lite.
Tar man en stor pic-processor och programmerar i assembler
så får man programmera mycket (massor med inställningar).
Ett annat alternativ är att ta en Arduino och deras c-språk.
Då räcker det med mycket mindre egen programmering.
Jag har hittat ett bibliotek som heter LiquidCrystal.
Är det någon som vet hur snabbt det är, innan jag skaffar
grejer själv och börjar programmera?
Går det lika fort att köra som om man hade programmerat
allt själv i assembler? Jag vill ju helst inte att skärmen
ska upplevas som seg, och kunna köras fortare egentligen.

Här är länkar:

https://www.arduino.cc/reference/en/lib ... idcrystal/
https://docs.arduino.cc/learn/electronics/lcd-displays

En fördel till med Arduino är att det räcker med en usb-kabel
för att programmera. Till pic kostar en programmerare
ungefär 1200 kronor.

[FormerMazda]

Nej lika fort som assembler är det ju inte, beroende på hur assemblern är skriven förstås.
Men jag skulle nog påstå att en arduino kan uppdatera en LCD snabbare än LCD hinner uppdatera. Om vi nu menar typ 4x20 tecken.
Menar du grafisk LCD och bygga ett 3D-spel så blir det nog segt.

Vad ska du visa på skärmen, och vad är segt?

[AndLi]

Och vilken hårdvara ska du köra Arduino på? Gammal klassisk ATmega 8 bitars?

Idag skriver man väl oftast inte i assembler utan kastar mer hårdvara på det istället, själv har jag trillat ner i Raspberry Py Pico träsket och kör microPython! (Det efter 30 år som low level C kodare....)
Det är på gång att koppla en grafisk display till den, men det är så många andra projekt i mellan..

[BJ]

Ja, jag menar ungefär 4 x 20 tecken.

Ja, gammal klassisk Arduino som Uno t.ex.

Med segt menar jag att man hinner se att det tar tid att
skriva varje tecken eller alla tecknen när man fyller hela skärmen med text.
När jag har programmerat i assembler förut med lcd- eller
pled-skärmar så har texten kommit så gott som ögonblickligen,
och det är den upplevelsen jag är ute efter.
Jag vet att lcd är lite långsammare än pled.
Programmera spel och sådant hade jag inte tänkt.

[SeniorLemuren]

Jag har inget exempel med LCD men här kan du se ett test jag gjorde med en grafisk display och Arduino DUE. Detta kräver ganska ordentliga flyttalsberäkningar för att fungera och jag har även testat det med Arduino Mega som även det funkade bra.

[FormerMazda]

Du kan du vara lugn.
En hel skärms uppdatering sker utan att du ser tecken för tecken, sannolikt även på en äldre arduino.

Men som sagt innan, kasta hårdvara på det annars, en ESP32 kostar inget och har ganska brutalt mycket mer prestanda.
Och programmeras som en arduino med arduinos IDE och en USB-kabel.
Exempel: https://www.electrokit.com/produkt/esp32-devkit-lipo/

[mrfrenzy]

Uppdateringshastigheten beror inte på ifall programmet är skrivet i assembler eller C. Det beror på hur väl optimerat programmet är och i vilken ordning programmeraren valt att göra saker.
Det är inga problem att göra ett program som uppdaterar en LCD så snabbt att du inte hinner se förändringarna oavsett vilket programmeringsspråk man använder.

Här ser du ett exempel som använder LiquidCrystal. På videon ser man att hela skärmen uppdateras blixtsnabbt vid tryck på en knapp (Tid 11:12)


Inte speciellt förvånande att ett officiellt bibliotek är väl optimerat.

[BJ]

Vilka trevliga svar.
Mätaren där såg ju bra ut, och den sista filmen också.
Inga problem med uppdateringen där.

Mer hårdvara... Kanske längre fram.
Jag tror att jag börjar lite med vanlig Arduino så länge.

[Castor]

För att skriva snabb assemblerkod krävs väl att man är van programmerare på den processorarkitekturen, annars gör nog högnivåspråken generellt ett bättre jobb.
Dessutom får man väl snabbare en fungerande kod, felsökning av assembler kan ju ta rätt mycket tid, speciellt om man missförstått något i databladet

[hummel]

Som mrfrenzy säger är inte programspråket avgörande för prestandan.

I korta drag hur man designar ett program:
Fastställ kraven på programmet. Detta är det viktigaste steget!
Välj lämplig algoritm för att lösa problemet.
Implementera i lämpligt språk (typ det språk du kan).
Verifiera att kraven på programmet uppfylls.
Vid behov, justera och verifiera tills önskat mål är uppnått.

[BJ]

Ja, man blir ju van ganska fort om det inte är krångligt.
Om man har saker som är styrda av avbrott och som
är tidskritiska så tycker jag att det är lättare att göra det
i assembler. Då har man kontroll över varenda instruktion
och tiden som ett avbrott kan ta o.s.v.

hummel:
Det är väl ungefär så det brukar gå till i stora drag.
Kanske inte alltid lika hårddraget.

[Glenn]

Detta skrev jag i PBP 2008, med en väldigt simpel PIC på 4Mhz:




Att texten hackar i börtjan beror ju på att det är fasta teckenpositioner, min (fejkade) rasterbar i slutet (ca 0:31) däremot ser man ju hur snabbt det går att trycka ut ändringar till LCD'n,
trots urgammal PIC och högnivåspråk. (PBP är PICBASIC Pro, en BASIC-variant.)

..Så ja, det är inte så tidskritiskt.

[BJ]

Vad snitsigt.

Det såg ju ut att fungera bra.

[TomasL]

BJ, din fråga är som hur långt är ett snöre.
Det hela beror på hur bra och effektivt biblioteket är.
Det kan vara allt i från ett hafsverk skrivet i C++ med en nästan oändlig mängd onödig kod, till ett högoptimerat bibliotek, skrivet för en viss processor i maskinkod.

[hummel]

Det är väl ungefär så det brukar gå till i stora drag.
Kanske inte alltid lika hårddraget.

Min erfarenhet är precis det motsatta i många fall. Ibland gömmer man sig bakom agila arbetsmetoder ( inget ont om agilt sätt att arbeta) för att kunna ta genvägar och fuska med utvecklingen.