Svenska ElektronikForumet

Ja, om allting var nytt, och allting var billiga lösningar som någon glad
"på nätet" har hackat ihop, så vore ju allt enkelt.

För övrigt så har vi sedan snart ett år även ett REST API (mot en
lokal server men där anropen sedan går mot en AWS miljö) som körs
från Python. Där (i AWS) genereras serienummer och andra IDn som
får tillbaka som JSON, lagrar och sedan överför till PLCer i produktionen.
Alltså från samma 35 år gamla produktionssystem.

olof_n: då vet nog inte den yngra generationen vad ett inbyggt system är

Sodjan: Kul att det gamla systemet fortfarande körs efter 35 år. Det är kvalité det!

Rick81: Jo så är det nog.
Det tråkiga är att när hårdvaran blir mer och mer kraftfull kommer utvecklingen bli den samma som på "PC" sidan. Stora ramverk med ooptimerad kod.
Lite av det jag tycker är kul med mikroprocessorer är just att resurserna är begränsade. Det ger lite av glädjen man kände när man pysslade med hemdatorer i sin ungdom.

Får hoppas att det alltid kommer att finnas kvar lite lågnivåprogrammering

Stora ramverk och ooptimerad kod är väl en sak men många tror ju att man kör linux på varje inbyggt system med som du nämner python, tcp, json m.m. men det är ju mycket smartare med en billig, liten inbyggdprocessormed inbyggt RAM och flash jämfört med all HW som behövs för att kunna köra linux

Hur hade du tänkt dig om man skulle vilja implementera ML eller DL i ett inbyggt system? Du kan inte implementera en kvadratisk programmerare eller ett DL-nät i en liten uC.

Jag kör alla mina algoritmer i MATLAB där jag har kommunikation med Java. Så MATLAB sköter beräkningen, medan Java sköter själva grafiska gränssnittet på webben och har kommunikation med hårdvaran.

Om sin algoritm inte tar hänsyn till tid, vilket mina algoritmer inte gör, så kan man bara anta att samplingsintervallet är konstant, trots att den varierar.
Självklart blir det ett problem vid snabba processer, men för sega processer, vilket prediktiv reglering används till, så ska det inte vara några problem.

Ack så okunnig du är.

En liten ųC klarar det galant! Ett exempel jag känner väl: Renesas RX210.
32 bit
50 MHzn
64kB RAM och 512kB flash i den version jag använder.
15 x 15 mm vilket är ganska litet.

Timers, UART, 12 bit A/D och en massa annat HW inbyggd.
Drar 10mA vid 5V.

Tidiga PC med '386 körde max 33MHz och slök enormt med ström.

En STM32 skulle helt säkert klara det galant också.

Vet du ens vad subrymdidentifiering och kvadratisk programmering ens är? Det är rätt förvånade på detta forum att folk verkar tro att C och uC är Gud's gåva som löser allt. Om det hade varit så, så hade högnivåspråk aldrig existerat.

Det är tonvis med matriser för att kurvanpassa i olika dimensioner. Man jobbar med matriser som kan vara typ 400x400 eller mer.

Den kvadratiska programmeringen måste få in rätt matriser för att göra sina beräkningar. Det betyder t.ex. ytterligre 400x400 gånger 20 matriser extra.

Varför så mycket data? Jo, desto större modell man har, desto mer kan den ta olinjäriteter.

Om vi gör en uppskattnin och sägervarje multplikation tar 5 instruktioner blir detta 400x400x20x5 = 16 miljoner instruktioner. Om vi gör 20 sådana per sekund blir detta 320 miljoner instruktioner. En stm32h7 på 400 MHz kör 400 miljoner instruktioner per sekund så det borde gå.

Nu är detta bara ett grovt räkneexempel för att visa kraften i stm32h7 och jag har bara gissat 5 instruktioner per multiplikation.

Matlab och java käkar ju instruktioner i overhead så detta förutsätter ju C eller Assembler.

Hur vore det om du specifierade ungefär hur mycket data det innebär och hur många matematiska operationer (+, -, *, /) som går åt. Är det något annat som också behövs kan du väl specifiera det också.
Det känns inte speciellt produktivt att vi ska sitta här och gissa.

Rick81 skrev:Om vi gör en uppskattnin och sägervarje multplikation tar 5 instruktioner blir detta 400x400x20x5 = 16 miljoner instruktioner. Om vi gör 20 sådana per sekund blir detta 320 miljoner instruktioner. En stm32h7 på 400 MHz kör 400 miljoner instruktioner per sekund så det borde gå.

Nu är detta bara ett grovt räkneexempel för att visa kraften i stm32h7 och jag har bara gissat 5 instruktioner per multiplikation.

Matlab och java käkar ju instruktioner i overhead så detta förutsätter ju C eller Assembler.

Japp. MATLAB och Java käkar mycket minne. Men trots detta så är ett MATLAB-script inte långt ifrån vanlig C-kod. När man kör ett MATLAB-script så skapas det en instruktionsfil som C-kod läser. Vi alla vet att C-kod läser instruktionsfiler i ett svep.

Det vore ändå dock kul om man skulle kunna implementera en kvadratisk programmerare i en uC. Jag har iallafall inte hittat någon.

Rick81 skrev:Om vi gör en uppskattnin och sägervarje multplikation tar 5 instruktioner blir detta 400x400x20x5 = 16 miljoner instruktioner. Om vi gör 20 sådana per sekund blir detta 320 miljoner instruktioner. En stm32h7 på 400 MHz kör 400 miljoner instruktioner per sekund så det borde gå.

Nu är detta bara ett grovt räkneexempel för att visa kraften i stm32h7 och jag har bara gissat 5 instruktioner per multiplikation.

Matlab och java käkar ju instruktioner i overhead så detta förutsätter ju C eller Assembler.

Fråga! Är samplingstiden alltid konstant? Vi säger att om processorn blir ca 10 grader varmare då?

Borde vara konstant då det väl följer klockfrekvensen?

Det beror precis som Glattnos säger på klockfrekvensen, men sen kan ju den driva pga av temperatur.
Men i praktiken har jag svårt att se att du skulle märka av det...

Att instruktionsfilen läsas i ett nafs har inget med saken att göra.
Det är likaväl (som jag fattar det) en interpeterat kodning som definitivt inte är hastighetseffektiv.

Så en rätt vald ųC klarar biffen med samplingen och beräkningarna utan större svårigheter.
Och såklart med fast sample-rate.

Visst kan man implementera detta i min STM32? Jag använder F401RE modellen.

https://www.gnu.org/software/gsl/doc/html/index.html

Detta bibliotek är rent C bibliotek. Om den fungera för inbyggda system vet jag inte. Men jag vet att den har SVD-funktion, vilket man kan göra både Observer Kalman Filter och Eigensystem Realization. Dessa två algoritmer är utmärkta för systemidentifiering då dessa kräver:

1. Lite data till skillnad från annat
2. Inga intrimningsparametrar

Enkelt förklarat kan man säga att om vi har lite dötid + PWM till en matematisk modell:
Nu har vi både y som är utgång, u som är ingång och t som är tidsvariabeln.

Om vi stoppar in dessa i Observer Kalman Filter Identification algoritmen. Egentligen är inte denna rad den faktiska algoritm. Denna algoritm är den teoretiska då den praktiska är mer invecklad för att den praktiska algoritmen applicerades på gamla system från 80-talet. Medan den här kan kan användas enkelt i en enda rad för datorerna idag är mycket mer kraftfullare.
Då får vi markov-parametrarna, vilket betyder impulssvar.

Om jag simulerar min modell, med ett impulssvar och jämför sedan med markov-parametrarna.
Då får vi vårat impulssvar.
Sedan jämför vi det med markovparametrarna.
Vilket ger exakt samma resultat som impulssvaret. Varför är impulssvaret viktigt? Jo! För eigensystem realization vill ha ett impulssvar för att kunna räkna fram den matematiska modellen. Men ett impussvar så kan man få reda på exakt allt! Höjd, dämpning, insvägning...ja allt!
Då återkommer vi till att om vi kan kvadratiskt programmera en sådan modell i en uC igenom att använda en förenklad kvadratisk programmerare som endast kan ha hänsyn till signalmättning.

Då är min fråga till er:
1. Kan man använda GNU Scientific library i STM32
2. Klarar STM32, iallafall min uC av att beräkna matriser och flyttal på en snabb nivå?