Micropython vs C/C++ RPI Pico

[hummel]

Pascal och C är båda imperativa och procedurella språk.
Delphi och C++ är objektorinterade språk.
Pascal och C är väldigt lika på samma sätt som Delphi (objekt Pascal) är väldigt likt C++.

[H.O]

Inte helt nöjd !?
Nej, OK det blir man kanske aldrig med det där tycker jag ser väldigt bra ut (!) och det luktar Heidenhain lång väg. Vad är det gjort i/med?

[Micke_71]

Med lite halvtaskiga Delphikunskaper så förklarar det ju tydligt varför C++ inte känns så främmande medans C är något som jag inte riktigt vill bli klok på.

[Micke_71]

Inte helt nöjd !?
Nej, OK det blir man kanske aldrig med det där tycker jag ser väldigt bra ut (!) och det luktar Heidenhain lång väg. Vad är det gjort i/med?

Det är programmerat i Delphi och jag tror grafiken tillhör Firemonkey delen.

Tidigare så gjorde jag lite mjukvara inom skytte i olika kategorier men det är typ 20 år sedan.

Ett projekt som gav lite utmaning var realtidsstyrning av LPT porten till en skyttesimulator för hagelträning. Video på när jag lyckades få lite flyt i lasern utan ryckningar.

[Micke_71]

Varje svar jag får väcker en ny fråga.

Att C är avsevärt lägre nivå än C++ är inget nytt egentligen. Det har jag väl vetat om.

Men hur ser det ut i mikrokontrollers. Skillnaden i hastighet? Och är det fritt fram o mixa så man använder C till en mindre tidskritisk rutin och skriver resten i C++?

Micropython verkar enkelt i all ära men i snabba tidskritiska applikationer så är det mycket jitter. Har testat lite och en simpel instruktion med en rad som borde tagit typ 0.1 uS går på 20 uS med ett jitter på 5uS

Lite längre instruktioner på typ 5 rader kan diffa 20uS

Då klockar jag på 250MHz.

Ett projekt kan vara att spara time.tick_us() på 3 -10st ingångar relativt tidskritiskt och helst inom 1uS.

Pico har ju 2kärnor och det ska ju gå o köra vissa rutiner på olika kärnor.

Jag lyckades till slut lösa ett matteproblem med TDOA med sensorer på linje (trigometri utan hyperboler) utan iteration. Jag kanske attackerar detta med typ 10 st lösningar som sedan har en iteration i ljudhastigheten till de stämmer bäst överens och sedan räknar medelvärde på dessa.

[Icecap]

Det är ingen skillnad mellan C och C++ i hastighet!
C++ inför extra funktioner (klasser) som kan ha inbyggda start- och slutfunktioner och har striktare typning och lite andra småsaker.

[pfyra]

...
Men hur ser det ut i mikrokontrollers. Skillnaden i hastighet? Och är det fritt fram o mixa så man använder C till en mindre tidskritisk rutin och skriver resten i C++?

Micropython verkar enkelt i all ära men i snabba tidskritiska applikationer så är det mycket jitter. Har testat lite och en simpel instruktion med en rad som borde tagit typ 0.1 uS går på 20 uS med ett jitter på 5uS

Lite längre instruktioner på typ 5 rader kan diffa 20uS

Då klockar jag på 250MHz.

Ett projekt kan vara att spara time.tick_us() på 3 -10st ingångar relativt tidskritiskt och helst inom 1uS.
...

Det är svårt att mäta så korta tider med precision, oavsett språk.
Jag vet inte om det är möjligt att klara tidskraven du sätter upp för projektet med python (men jag tvivlar starkt på det!), så det kan ju mycket väl vara en bra ide att kika på C/C++ redan från början när man vet att tidskravet finns. Det kan även hända att du kan dra nytta av de hårdvarublock som finns och läsa av ett antal gpio-pinnar periodiskt mha timer och dma.

C är en delmängd av C++ och använder du en C++ kompilator kan du mixa och blanda bäst du vill. Men med så korta tidsintervall som du nämner så är det klokt att undvika vissa delar av språken då de påverkar prestandan negativt (malloc/free i C, new/delete och exceptions (och säkert fler finesser) i C++).

[sodjan]

Men dessa mätningar gör man normalt inte direkt i/med koden.
Koden används till att sätta upp hårdvaran (timers) för att göra mätningen.
Sedan läser koden av resultatet då mätningen är klar.

Kod som är beroende av enskilda instruktioners exekveringstid är "a bug waiting to happen".
Sen så spelar det ingen större roll vilket språk man använder.

Men visst, om dessa mätningar även ska upprepas med samma intervall så har man
ju andra problem än bara för en enskild mätning. Och 10 timers kan vara en utmaning.

[agehall]

Fungerar bra att använda t.ex. Visual Studio Code för att utveckla, debugga och programmera Arduino-hårdvara om man inte gillar Arduino-IDE.

Arduino IDE är ju urusel. Det är ett under för mig att man inte integrerat med VS Code eller liknande för att få en vettig miljö.

För den som vill ha en bra utvecklingsmiljö, oavsett om man vill köra med Arduino's ramverk eller inte, kan jag varmt rekommendera VS Code och PlatformIO. Den kombinationen går att växa med till andra platformar och man slipper lära sig nya IDE:er varje gång man byter miljö.

[Micke_71]

Men dessa mätningar gör man normalt inte direkt i/med koden.
Koden används till att sätta upp hårdvaran (timers) för att göra mätningen.
Sedan läser koden av resultatet då mätningen är klar.

Kod som är beroende av enskilda instruktioners exekveringstid är "a bug waiting to happen".
Sen så spelar det ingen större roll vilket språk man använder.

Men visst, om dessa mätningar även ska upprepas med samma intervall så har man
ju andra problem än bara för en enskild mätning. Och 10 timers kan vara en utmaning.

Tidmätningen som jag hittills enkelt testat är

Timer.tick_us() för att kunna se repeterbarheten och hur snabbt vissa saker går.

I det eventuella projektet så ska 3-10 st interrupts helt enkelt
t1 = timer.tick_us()

Och dessa t1, t2, t3 osv ska sedan subtraheras från den första interruptet.

Kvarvarande värden representanter TDOA värden och beräknas.

[Lennart Aspenryd]

Jag har följt denna tråd med intresse och tänkt att jag skulle lägga in den om Bläckfisken!
En intelligent bläckfisk sägs ju ha autonoma hjärnor dvs. kan reagera med ryggradskänsla, vad den nu sitter på en slik tingest!
Men min grej var att föreslå flera enheter som har sitt uppdrag, grejorna är ju så billiga.
Men nu förstår jag att det rör sig om ett mycket intressant område som jag har berört lite tidigare LPS istället för GPS.
Så då faller mitt förslag. Men på golvet här ligger en kartong med 12 st MDEK1001
https://www.mouser.se/datasheet/2/412/M ... 878639.pdf
Kan det vara intressant att komplettera med? Det finns många vägar!

[Micke_71]

Det finns många roliga applikationer med både LPS o GPS om man kombinerar med diverse sensorer/givare. Kan hitta på en hel jäkla bunt med projekt.

[rvl]

TDOA med Pico låter intressant och då är jag nog överens om att Python är fel.

[Micke_71]

Testade lite snabbt igår kväll med lite olika angreppsvinklar.

Viper code emitter med @micropython.viper

Loopen på 1e+6 varv gick ner från 2.89sek till 0.14sekunder och jittret i tid minskade till 3uS från 30uS

Samma fast Native code emitter hamnade på 0.28sek

Förbättring på 10 och 20ggr

Mesta tiden gick åt att försöka komma igång med VS Code. Har nog aldrig känt mig så jävla korkad i hela mitt liv. Installerar alla extensions och funktioner.

Kommer till punkten att jag kan starta nytt projekt med platformIO och välja RPi Pico och där finns ett enda alternativ. Arduino framework. Men blir inte det som att köra Arduino IDÉ fast i VS Code utvecklingsmiljön.

Hittade RPi Pico SDK som jag laddade ner. Försöker installera detta som extension/tillbehör/framework (jag har ingen aning om vad jag håller på med nu) och får bara fel över att någon Json fil saknas. Online hjälp säger ta bort defekta extensions???

Jag har aldrig haft problem med att installera, skriva kod och kompilera i Delphi, Objekt Pascal osv. Men nu känner jag mig lika begåvad som en analfabet i ett bibliotek. Jag är totalt vilse där. Kanske trötthet också. Ska titta på det idag igen.

Online guider, jo tack. 99% är för linux med en hel bunt (typ 2km) manuella kommandon för installation.

Kunde man inte ha haft något mer streamlined , typ installera tillägg för Pico C SDK som ett färdigt paket. Skriv kod, klicka på kompilera….

Arduino IDE för Pico var ju barnlek o komma igång med men jag blir lite fundersam på funktionaliteten och fastnar lite på att micros() är ett 32bitars värde medans micropythons motsvarighet time.ticks_us() är 64 bitar.

I Arduino kod så blir det rollover var 70 minut medans det i micropython tar typ 585 000år.

[swesysmgr]

Jag tycker det är med Python som med Matlab, man måste göra på det sätt som språket är byggt för dvs. använda de inbyggda bibliotekens funktioner och lösningsmodeller. Programmerar man som i enkel C med en massa loopar då blir prestandan dålig.

Att använda Arduinos bibliotek är inte konstigare än att använda någon annan mikrodatortillverkares färdiga bibliotek för olika funktioner istället för att skriva dem själv.