Hastigheter mellan PC och uC?

[Al_Bundy]

Hej!

Jag håller på med prediktiv reglerteknik, dvs avancerad reglerteknik. Målet är att en STM32 Nucleo kort på 180 Mhz CPU ska kunna göra matrisberäkningar för prediktion och där efter så ska den utföra dessa beräkningar. Notera att även kalmanfilter är inbyggt. Jag har ett annat system som jag har testat detta på, men då är det ett långsammare system. Men detta system ska vara ett hydrauliskt system med hängande last. Det är bara för test.

På min dator tar det 0.000126 sekunder för att beräkna och det är gjort allt i C-kod. Dessutom har jag Eclipse, Firefox, Octave samt Linux OS igång samtidigt.
I min dator så har jag två kärning Intel(R) Celeron(R) CPU N2830 @ 2.16GHz och 2 GB ram. Datorn är från 2014.

Då är min fråga:
Hur motsvarar denna siffra 0.000126 i ett 180 Mhz NUCLEO-F446RE kort?
Någon som har erfarenheter när det kommer till hastigheter mellan en PC och en uC?

[sodjan]

Komplett omöjligt att svara på. Det beror helt på implementeringen.
Datatyper, algoritmer o.s.v.

[Al_Bundy]

Jo. Det vet jag att det är en svår fråga.

Men hur brukar det vara på ett ungefär? Jag behöver ingen siffra. Mest intressant och höra om man ska köpa snabbt kort som är dyrt, eller billigare kort som är långsammare, när det kommer till reglering.

En uC på 180 Mhz gör ju inte 180 miljoner iterationer per sekund.

Jag bifogar projektet. Projektet är skapat i Eclipse IDE för den som vill testa. Bara klicka start så räknar den fram det bästa värdet.

[Shimonu]

180/2160=0.08333333333=8.333..%

100*0.000126/8.3333333=0.001512 s

En ungefärlig siffra baserad bara på skillnad i klockhastighet. Går som sagt inte att ge så bra svar utan det är mätningar som gäller med informationen som finns. Analys av det här slaget är inte direkt enkel heller.

[Al_Bundy]

Tack.

Jag tycker ditt svar är bra ändå. Ska jag satsa på högprestandahårdvara eller räcker det att man bara var typ några MHz när det kommer till reglering?

[Glattnos]

Är det inte så att en dator som kör OS ofta har nån sorts loop-time då den gör vissa saker så man kan inte vara säker på att beräkningar görs från början till slut utan avbrott, medan en bra kod på en uC gör just detta?
För snabb reglering bör man väl inte ha en dator med OS alls?

Jag är ju inte insatt i detta men det är lite intressant att veta

[Shimonu]

Tack.

Jag tycker ditt svar är bra ändå. Ska jag satsa på högprestandahårdvara eller räcker det att man bara var typ några MHz när det kommer till reglering?

Det beror ju helt på hur programmet ser ut och vad du har för krav! Jösses!

Ska jag ha motor med hög prestanda eller räcker det med några hästar när det kommer till transport?

[tingo]

Ofte så har man en viss anelse om hvor raskt regulerings "loopen" må gå: holder det med å oppdatere to ganger per minutt? eller må man ha ti ganger per sekund?

I de tilfeller hvor man ikke har peiling hva som kreves, så bygger man ofte en prototype og tester ut hvor sakte / enkelt / billig man kan gjøre det og det fortsatt er godt nok.

[hummel]

Lämplig metodik är att identifiera problemet. Finn algoritm för lösning av problemet. Välj hårdvara baserat på algoritm. Vid behov optimera/ny algoritm som passar hårdvara (tillgänglig FPU, GPU, programmerbar logik osv).

[svanted]

ett sätt att göra saker mera avancerade är att göra dem mera komplicerade än vad de e.g. är.

[Icecap]

En kompis berättade vad en besiktningsman hade sagt en gång:
"Om man har onödigt många datorer i ett ventilationssystem, då har man inte fattat vad som ska göras."

Och det gäller även TS' system:
* Det finns ingen uppdateringskrav.
* Det finns ingen krav på vilken maximal belastning dessa uppdateringar få utgöra.
* Det finns ingen data på hur den nuvarande hårdvara klarar jobbet.

Al, lär dig 80/20-regeln:
* Välj rätt sak att optimera och man får 80% effekt för 20% investering.
* Optimera fel sak och få 20% effekt för 80% investering.

Ett OS är alltid en "tjuv" uti CPU-kraft - men om man kan tillåta detta beror på vad som krävs av systemet. Jag har aldrig kört med RTOS i någon form men alltid tagit hand om alla interrupts på egen hand så för mig känns valet lätt.

Med tanke på vad jag vet om TS' kännedom till datorsystem kan jag fint fatta att h*n anser att det nog är bäst att kasta mycket hårdvara på saken istället för att faktisk veta vad som rent faktisk behövs.

Jag känner att detta definitivt är ett resultat på 20% som bäst enl. 80/20-regeln.

[Lennart Aspenryd]

Om man inte känner målet,
då kvittar det vart man går!

Man kan inte gå vilse,
Om man inte vet vars man är!

Pareto har rätt. Utom i en femtedel.

[Al_Bundy]

Är det inte så att en dator som kör OS ofta har nån sorts loop-time då den gör vissa saker så man kan inte vara säker på att beräkningar görs från början till slut utan avbrott, medan en bra kod på en uC gör just detta?
För snabb reglering bör man väl inte ha en dator med OS alls?

Jag är ju inte insatt i detta men det är lite intressant att veta

En uC är ett realtidsystem och en PC har fördröjningar vilket skapar ojämn samplingstid = ostabilitet.

Tack.

Jag tycker ditt svar är bra ändå. Ska jag satsa på högprestandahårdvara eller räcker det att man bara var typ några MHz när det kommer till reglering?

Det beror ju helt på hur programmet ser ut och vad du har för krav! Jösses!

Ska jag ha motor med hög prestanda eller räcker det med några hästar när det kommer till transport?

Det är enkelt program. Mest bara matrisberäkningar i storlek 40x40 för att lösa lägre triangulära hessenbergmatriser med Gaussian Elimination. Om ni vet vad det är?

Ofte så har man en viss anelse om hvor raskt regulerings "loopen" må gå: holder det med å oppdatere to ganger per minutt? eller må man ha ti ganger per sekund?

I de tilfeller hvor man ikke har peiling hva som kreves, så bygger man ofte en prototype og tester ut hvor sakte / enkelt / billig man kan gjøre det og det fortsatt er godt nok.

Det ska gå ca 0.01 millisekund per loop.

Lämplig metodik är att identifiera problemet. Finn algoritm för lösning av problemet. Välj hårdvara baserat på algoritm. Vid behov optimera/ny algoritm som passar hårdvara (tillgänglig FPU, GPU, programmerbar logik osv).

Är en looptid på 0.01 sekund krävande?

En kompis berättade vad en besiktningsman hade sagt en gång:
"Om man har onödigt många datorer i ett ventilationssystem, då har man inte fattat vad som ska göras."

Och det gäller även TS' system:
* Det finns ingen uppdateringskrav.
* Det finns ingen krav på vilken maximal belastning dessa uppdateringar få utgöra.
* Det finns ingen data på hur den nuvarande hårdvara klarar jobbet.

Al, lär dig 80/20-regeln:
* Välj rätt sak att optimera och man får 80% effekt för 20% investering.
* Optimera fel sak och få 20% effekt för 80% investering.

Ett OS är alltid en "tjuv" uti CPU-kraft - men om man kan tillåta detta beror på vad som krävs av systemet. Jag har aldrig kört med RTOS i någon form men alltid tagit hand om alla interrupts på egen hand så för mig känns valet lätt.

Med tanke på vad jag vet om TS' kännedom till datorsystem kan jag fint fatta att h*n anser att det nog är bäst att kasta mycket hårdvara på saken istället för att faktisk veta vad som rent faktisk behövs.

Jag känner att detta definitivt är ett resultat på 20% som bäst enl. 80/20-regeln.

I detta fall har jag optimerat C coden igenom att använda minimalt med for-loopar och använda så mycket memset och memcpy som det bara går.

[Findecanor]

Om det är riktigt mycket data så spelar det roll i vilken ordning man läser och skriver minne: så att man utnyttjar cachen bra. Och då spelar det roll vad den har för vidd och storlek.
Det kan finnas olika optimala gränsvärden för olika dimensioner av dina arrayer i minnet beroende på hur cachen ser ut på just den processor som du använder.
Det är en anledning till att din mätning på din Celeron-processor inte går att jämföra direkt.

Om det är mycket flyttalsberäkningar så spelar det roll hur koden är kompilerad och hur många flyttalsoperationer processorn kan göra samtidigt. Dagens kompilatorer för x86-64 och AArch64 producerar kod för snabba vektorenheter medans äldre kompilatorer för x86-32 och 32-bittars ARM producerade kod som använder en äldre flyttalsenhet.
Stödjer mikrocontrollern flyttal överhuvudtaget? Om inte, så måste alla flyttalsoperationer emuleras i mjukvara, vilket skulle bli riktigt långsamt. Om talen du hanterar håller sig inom vissa gränser och du inte behöver både precision och ett stort intervall så vore det i så fall bättre att skriva om koden att räkna med "fixed-point" istället.

Föresten, överlag när man gör prestandatester så brukar man inte testa bara en körning, utan ett lagom antal körningar som man sedan beräknar medelvärde av.

[Nerre]

Instruktionsuppsättningen är ju enormt viktig för att veta skillnader i exekveringstid för olika delar av kod. Det är ju därför det inte går att ens ge en ungefärlig siffra.

Även arkitekturen påverkar ju, de flesta moderna arkitekturer gör väl en instruktion per klockcykel, men det kan krävas två klockcykler eller mer per instruktion på en enklare processor (som jag misstänker att mikrocontrollern är).

Jag har suttit och skrivit serieöverföringsrutiner i assembler på ABC80 och då fick man sitta med Z80-manualen och kolla igenom hur många klockcykler varje instruktion tog (och "runda av" med några NOP efter fördröjningslooparna). Idag finns det väl verktyg som gör en sån analys av koden, men det kräver ju att den är kompilerad till assembler. Att göra en sån analys på C-kod funkar inte, för du vet inte hur kompilatorn löser koden.

Exemplet med cachen är bra, när jag gjorde mitt exjobb så skulle jag skriva ett filter på en TMS 320C80. Där tog det typ 15 klockcykler att läsa från externt minne, alltså fick jag skriva koden så nästa sampel började läsas in innan beräkningarna började. Loopen började alltså med att initiera läsning av nästa sampel innan jag började räkna på det som redan var inläst. Visserligen hade jag då fortfarande minst 15 cykler fördröjning, men hade jag väntat på inläsningen innan beräkningen började hade det ju blivit 15+vad nu beräkningen tog.