Matrisberäkningar med för STM32?

[mankan]

Du menar att jag ska köra C++ på STM32 ? Hur gör man det ?

Jag vet inte vad som stöds i just din miljö men om den har GCC som i GNU Compiler Collection så finns troligen g++ (C++-kompilatorn) med, och om den finns med så är det också smidigt om delar av libstc+ och STL finns med (mycket i dessa är inte lämpat för inbäddade system men utan vissa delar så blir man lite handikappad). Har den bara GCC som i GNU C Compiler så får du välja en annan miljö alternativt utöka miljön själv.

[SvenW]

Jag får återkomma om ca 12 timmar för att försöka komplimera STM32 med GSL. Vore sjukt grymt om man kunde använda matrisberäkningar i moderna uC:er 

Troligen blir det problem. STM32 finns inte med i listan över "other platforms" för GNU GSL.
Möjligen man man klippa ut valda delar i källkodsform men man riskerar även då att trassla in sig i dependecy-problem.

Hoppas du vill rapportera för oss hur det går, men min spontana rekommendation är:
Lägg inte ner alltför mycket tid på detta!

Mitt sätt att lösa detta skulle vara att googla efter lämpliga algoritmer även på andra ställen. Även att titta vad som finns i GSL givetvis.
Därefter modifiera efter egna behov. Finns inte behov av 64 biter så byter man datatypen till 32, osv.

[sodjan]

Man kanske ska ta några steg tillbaka och fundera på hela lösningen.
En liten känsla är att lösningarna och verktygen är lite mer komplexa
än vad som kanske är rimligt för en "embedded" applikation...

[Al_Bundy]

Ni har kanske rätt! Att göra matrisberäkningar på inbyggda system kanske inte är en bra lösning. Kanske man får skrota dessa tankar och återgå till Java istället med UART-kommunikation, där Java sköter den svåra biten och C gör endast PWM, ADC osv.

[mankan]

Det är fullt möjligt att göra en massa matrisberäkningar och avancerade reglersystem på ett inbäddat system men för Al som mer gör enstaka system är det nog inte värt den extra utvecklingstiden det tar att få en billigare hårdvara.

[Al_Bundy]

Jag trodde mer bara att C eller C++ bibliotek gick använda överallt. Anhängare till dessa språk skryter om språkets ultimata portabilitet, mer än vad en narcissist gör.

[Glattnos]

Det lär väl inte vara några problem om man skriver koden själv men om man tänker använda kod skriven av nån annan för något annat ändamål så är det ju inte säkert att det är "plugnplay".

[AndLi]

Det är inget fel på C portabilitet, men det ger dig inte oändligt med lagringskapacitet på alla plattformar.

Och med allt annat handlar det ju också om den som sitter bakom spakarna, att det är skrivet i C är ingen garanti, det finns bara bra möjligheter..

[Al_Bundy]

Så om jag försöker programmera matriser i STM32 så kommer jag säkerligen få många problem att lösa ?

Jag kanske iallafall testa försöka få GSL att fungera. Jag är behov utav ett reglersystem och reglersystem dom körs på OS är kanske inte det bästa?

[AndLi]

Varför måste reglersystem köra på OS?

Jag tycker du ska försöka implementera matriser för STM32 i c, jag tror det är många som kommer heja på

Mitt huvud är inte helt överens med matriser, annars hade jag gärna försökt...

[Glattnos]

Fast jag inte fattar så mycket så låter detta väldigt intressant
Är det detta som alltså ska göras? http://www.matteguiden.se/matte-f/matri ... rakningar/
Ser ju ut att vara fullt applicerbart i C/C++ och inte omöjligt för någon uC så länge minnet räcker och det blir tillräckligt snabbt för det aktuella fallet. Eller vari ligger svårigheten för ett inbyggt system?

Det känns som att frågan om det går att köra matrisberäkningar på inbyggt system är omöjlig att svara på om man inte vet storleken på beräkningarna och tiden det får ta. T.ex. en 8-bit uC kan ju göra det som dom tar i exemplen i länken och det är ju också matrisberäkningar. En STM32 på 400MHz med flyttalsenhet lär klara ganska stora matriser ganska snabbt utan problem.

[AndLi]

[media][/media]Jag hittade en youtube video som förklara de grundläggande räknesätten på ett pedagogiskt sätt...


Tycker också det verkar möjligt att implementera, mycket minne att allokera från början för att få plats med resultaten av multiplikationerna.
Men allt är ju förutsägbart, så det går ju att veta vad som behövs.

[Glattnos]

En array kan alltså representera en matris. Array kan ju vara flerdimensionell så både rader och kolumner kan ju representeras.

[sodjan]

När jag skrev om att "ta ett par steg tillbaka", så menade jag hela lösningen.
Är just matriser (och de metoder som har nämnts) optimala eller ens nödvändiga
för det aktuella problemet? Eller är matriserna mer av ett akademisk intresse?

Och visst, om det enbart är ett par matrisoperationer som man behöver, så kanske
man kan fixa det med lite egen kod utan att ha ett komplett bibliotek för matriser
och komplexa tal. Men som sagt, det känns som att vi har kommit en bit från
själva grundproblemet (om det nu fanns ett sådant) som systemet ska lösa...

[Icecap]

Vad jag förstår är ditt nuvarande system utan stabil uppdatering - men du räknar som om att det är.

Detta kan vara orsakad av några saker (eller kombinationer av dom):
* Lag i OS.
* Dålig programmering.
* Dålig samplingssätt.

Windows och Linux är INTE realtids-OS, det finns dock "tillbehör" som kan köra vissa delar i realtid (känd responstid) men det är inte helt enkelt.

Så vill du ha stabil sampling och databehandling ska du antingen göra allt i en enda µC eller ha en realtidskärna. Jag känner till att det finns realtidskärnor men jag har aldrig använd dom.