Matrisberäkningar med för STM32?

[hummel]

1 mikrosekund i jitter? Då får du nog fundera på programmerbar logik istället för en billig mikrokontroller. Måste det vara sådan precision?

[bearing]

Varför skulle 1 mikrosekund vara svårt?

Är rätt säker på att den ATmega328 som ligger och samplar i min bil med 8kHz varje dag, har ett jitter på ett hundratal nanosekunder. Är inte svårt alls att få till på en mikrocontroller med interrupts. Sen driver kanske klockan mer än så, men det är en annan sak.

Men om man förlitar sig på schemaläggaren i ett operativsystem blir väl under 1ms svårt att åstadkomma.

[sodjan]

Med en timer som triggar beräkningen så kanske. Men å andra sidan så har vi ju inte
en aning om vad som föregår beräkningen. Vara kommer alla värden i matriserna från?
Är det inte mätvärden som kommer "utifrån"? Med tanke på den övriga komplexiteten
så reagerade även jag på kravet (eller ett önskemål var det väl) på 1 mikrosekund.
Förutom att jag undrade varför det angavs som just 0.001 ms...

[Al_Bundy]

1 mikrosekund i jitter? Då får du nog fundera på programmerbar logik istället för en billig mikrokontroller. Måste det vara sådan precision?

Okej. Ska jag vara helt ärlig så vet jag inte. Trodde detta ska vara uppenbart med tanke på att jag ger inget korrekt svar.

Men jag blir nöjd och glad om det är mätdata med +-1 millisekund. Supernöjd.

[Al_Bundy]

Nu har jag testat EmbeddedLapack på min gamla Raspberry Pi B+ 32 bit, med Linux till att börja med. Det fungerade utmärkt att kompilera och köra och gav samma resultat som på min Windows dator 64 bit Intel och Linux dator 64 bit Intel.
Så det betyder att min C-kod är portabel samt CLapack är också portabel, trots att den var anpassad för operativsystem och datorer i form av IBM, Sun Microsystems och Intel. Jag ändrade lite i CLapack för att den inte skulle få för sig att gräva i hårdvara.

Tiden för att köra på min Raspberry Pi B+ 32 bit var 0.117 sekunder. På denna dator jag skriver nu så är det 0.004 sekunder. Min Paj är dock sliten och kass.

För er som klagade på att det var svårt att kompilera så har jag gjort det enklare nu. Nu kör man bara make och sedan är allt klart. Nu behöver man inte länka "include" mappen längre.

[bearing]

Jittret beror lite på processorarkitektur och så vidare. En ATmega har ett jitter på upp till 3 klockcykler beroende på att den måste fullfölja aktuell instruktion innan den hoppar till interruptrutinens adress. Så vid 10MHz handlar det om upp till 300ns. Om en ATmega skulle kunna köra i 1GHz, skulle det alltså handla om bara 3ns. Dock har mer komplicerade processorarkitekturer, som kör avancerade instruktioner, ofta betydligt fler klockcyklers jitter än en ATmega. Så jag gissar att en ARM från Raspberry pie kan ha högre jitter vid 1GHz, än en ATmega i 10MHz. Men jag har inte satt mig in i dessa avancerade ARM, så kan inte säga med säkerhet. Oavsett, gissar jag att under en mikrosekund borde kunna nås.

Sodjan har ju en bra poäng med att undra vad som ska samplas?
Du visade tidigare en graf som såg ut att visa stegsvaret på en signal. Är det alltså en enda insignal signal som ska samplas och behandlas?

[Al_Bundy]

Sodjan har ju en bra poäng med att undra vad som ska samplas?
Du visade tidigare en graf som såg ut att visa stegsvaret på en signal. Är det alltså en enda insignal signal som ska samplas och behandlas?

Det är insignal och utsignal som ska samplas. Grafen som jag visade var uppmätt signal och estimerad digital signal.

Jag håller på med machine learning. Så jag kan förklara mina steg:

Steg 1: Mät insignal och utsignal.
Steg 2: Använd Observer Kalmanfilter Identification för att räkna ut impulssvaret
Steg 3: Använd Eigensystem Realization Theory för att räkna ut en diskret tillståndsmodell av impulssvaret.
Steg 4: Använd tillståndsmodellen för att modellprediktivt räkna ut framtidens bästa signaler.
Steg 5: Applicera den första signalen av alla dessa "bästa framtidens signaler" och applicera det som insignal på systemet.

GOTO 1:

[sodjan]

> Jittret beror lite på processorarkitektur och så vidare.

Ja, det du nämner är ju enbart det hårdvaruberoende jittret.
Det jag pekar på är att det kan finnas applikationsberoende jitter också.
Sen så har jag inte en susning om hur en insignal "mappas" till en matris,
och är också totalt ointresserad av just det.

[bearing]

Jo det är ju sant, i ett komplext program kan det ju vara svårt att vara säker på att ingen exekvering blockerar annan och fördröjer samplingar eller utsignaler.

I mitt program i ATmegan har jag sett till att det är tillräckligt simpelt så att jag kan veta att behandlingen av signalerna samt kommunikationen aldrig tar längre tid än att det hinns med. Kommunikationen (utsignalerna från systemet) har jitter, men inte samplingen av insignalerna. Jittret från kommunikationen skulle jag nog kunna få bort om det vore nödvändigt.

[Al_Bundy]

Nyfiken fråga. Jag har inte börjat än att programmera till ARM utan Linux. Jag har lagt ned tid och fokus på att kompilera över mitt C bibliotek för Raspberry för att undersöka om biblioteket fungerar för 32 bit ARM. Det gör den.

Men hur blir det om jag rensar mitt SD kort på min Paj och sedan kört jag in ett färdigkompilerat C-program på SD kortet. Jag matar in SD kortet och startar upp min Paj. Programmet ska typ blinka eller göra något specifik vald händelse.

Fungerar det då att bara mata in C programmet på SD kortet och processorn snappar upp detta direkt? Det känns för enkelt för att vara sant. Man måste väll ha något som bootar C programmet, eller hur?

[bearing]

Det behövs ju något i processorn som kopierar in programmet från kortet till RAM. Verkar handla om en liten firmware. Om du klickar på mrfrenzy's länk, följt av första sticky-tråden, samt första länken, kommer du hit:
https://www.raspberrypi.org/forums/view ... 2&t=201556
Och hit, där du kan läsa en sammanfattning av vad det handlar om:
https://github.com/bztsrc/raspi3-tutorial

När programmet är laddat behöver det bara köras från startadressen, precis som i din STM32.

[Al_Bundy]

Men om man vill köra allt till RAM så borde man kunna göra det via initramfs på Linux.

Jag hade byggt ett eget Linux OS för en tid sedan. Då körde jag in allt på ram. Supersnabbt! Linux OS et var bara ca 5 mb.

[Al_Bundy]

Det är ingen som har testat mitt C-bibliotek och kollat om de kan göra några simpla beräkningar?

Jag funderar på att hitta enklare algoritmer som kräver mindre data. Jobbar fortfarande mot mått realtids mål.

[hawkan]

Inte mer än det som var i testfilen du la upp. Den funkar.

Raspberry Pi-spåret tycker jag verkar intressant och önskar lite att du går den vägen för då kan jag passa på att lära mej en del. Det kan vara nyttigt framöver. Men det är ju ditt problem så du väljer det du känner bäst för.

Om du har jobbat med linux och gjort en miniversion så kan det gott vara en första väg. Kan nämna att vi som kör linuxcnc har ett jitter kring 10 microsekunder med RT-patchar. Finns även de som testat på RPi, det har väl iofs inte gått så bra. Men det ska gå att få "bra", i alla fall inte katastrofal, rt-prestanda från en Linux. Inte så bra som en dedikerad mcu, men det kanske räcker för det du ska ha den till? Så du skulle mycket väl kunna prova med en mini-linux på RPi och om det duger så är du i hamn. Känd miljö och allt sånt. Annars så har du möjligheten att kasta ut linux och köra rakt på hårdvaran och då ska la det vara sjutton om inte tajmingen ska räcka till.

[Al_Bundy]

Inte mer än det som var i testfilen du la upp. Den funkar.

Tackar. Jag kommer lägga upp ytterligare en funktion då nu håller jag på göra en MPC. Tidigare exempel var OKID/ERA algoritm.

Raspberry Pi-spåret tycker jag verkar intressant och önskar lite att du går den vägen för då kan jag passa på att lära mej en del. Det kan vara nyttigt framöver. Men det är ju ditt problem så du väljer det du känner bäst för.

Jadu. Det är inget fel på Linux, men problemet är just att ett Linuxsystem, eller vilket OS som helst kan ju få lite brytningar har jag för mig. Men samtidigt så är Linuxsystem enkla att jobba med.

Om du har jobbat med linux och gjort en miniversion så kan det gott vara en första väg. Kan nämna att vi som kör linuxcnc har ett jitter kring 10 microsekunder med RT-patchar. Finns även de som testat på RPi, det har väl iofs inte gått så bra. Men det ska gå att få "bra", i alla fall inte katastrofal, rt-prestanda från en Linux. Inte så bra som en dedikerad mcu, men det kanske räcker för det du ska ha den till? Så du skulle mycket väl kunna prova med en mini-linux på RPi och om det duger så är du i hamn. Känd miljö och allt sånt. Annars så har du möjligheten att kasta ut linux och köra rakt på hårdvaran och då ska la det vara sjutton om inte tajmingen ska räcka till.

Jag lutar mer mot att köra Linux på ramminnet, helt. Men då räcker det att man i praktiken bygger eget Linux.

Om du vill vara delaktig i detta projekt, så vore det hjälpsamt om du kunde kolla lite närmare på hur mycket arbete det krävs för att bygga egen Linux dist på en godtycklig dator t.ex Raspberry Pi. Allt ska köras på RAM också via initramfs.

Då tror jag att mitt program kommer vara otroligt snabbt, trots att den körs på ett OS.

Just nu håller jag på att lösa detta problem:

\(A^n n \in \Re, A \in \Re^{mxn}\)