Svenska ElektronikForumet

jockwe skrev:

Al_Bundy skrev: I detta fall är jag nöjd med just denna hastighet. Jag ska ju bara ha 1 sekunds samplingsintervall.

Då kanske det räcker att köra mjukvaruräknad double? Varför jaga prestanda när det finns gott om tid över?

Mjukvaruräknad double?

Det gör jag inte

hummel skrev:

Al_Bundy skrev:Är det någon som har fått mer information om hur malloc beter sig hos STM32? Jag menar, STM32 verkar vara i framkant på allt, så dem kanske har löst det där med minnesallokeringen?

Hur menar du med löst minnesallokeringen?
Det är nog enbart du som designar programmet som kan avgöra det.

Okej. Som jag uppfattade många här i tråden så beskrev dem att malloc + uC = Kaoz.

Många avråder från malloc i uC miljöer ja, så även IAR.
Men det är ju upp till dig som utvecklare att bestämma hur du vill hantera ditt minne.

Jag kan förstå detta att man vill helst avråda att använda lite "dynamik" i en processor som ska göra in princip samma sak hela tiden och snabbt. Processorn kanske inte hinner med att ge minne?

Vilken del av processorn tänker du ger ut minne på en STM32F4?

malloc() och free() är vanliga användarfunktioner.
Googla t ex "do your own malloc" för att avmystifiera den.
T ex här https://danluu.com/malloc-tutorial/
Med reservation för att sbrk() kanske inte finns i uCn.

AndLi skrev:Vilken del av processorn tänker du ger ut minne på en STM32F4?

Har ingen aning. Jag kör bara malloc och jag får det jag får.

Nu testade jag med double och det blev samma resultat. Hmm...spår ett fel i qr.c filen....återkommer.

Mmm, du formaterar ju utskriften i printMatrix(). Eller missförstod jag funderingen?

printMatrix har inget med felet att göra. Jag misstänker att qr.c inte gör sin uppgift av någon lustig anledning. Kanske man har glömt något där.

Ok, trodde det var antalet decimaler du höll på med.

Hmm...Jag misstänker att C programmeringsspråk klarar inte av just att behandla dessa typer av tal. qr.c och svd.c fungerar felfritt. Men som jag misstänker så använder sig GNU Octave av andra typer av algoritmer för att lösa problemet. Jag misstänker att vissa värden blir så stora (e+308) och därmed kan C inte hantera dessa.

Så jag kan helt enkelt inte använda mitt C-bibliotek för dessa typer av signaler jag vill använda. Jag får helt enkelt gå över till Java som kommunicerar med GNU Octave. Detta innebär att det blir operativsystem + skript + java + socketprogrammering för att att kommunikation mellan java och octave. Eller så ger jag mig på ett Java bibliotek för matrisberäkningar. Ska ju finnas fullt.

Får du så stora, giltiga tal så är väl problemet illa-konditionerat. Har jag för mej det kallas.
Då är troligen din algoritm olämplig för just det exemplet.
Hur har octave implementerat rutinen som du har problem med?

>> Hur har octave implementerat rutinen som du har problem med?
30 års erfarenhet + massa svett och tårar uppe på sena nätter.

Jag tvivlar nästan på att Java skulle vara ett bra alternativ för matrisberäkninar, om inte C klarar av det med andra ord. Då återstår det bara kommunikation mellan Java och Octave via socket.

Finns det inte inbyggda datatyper med tillräckligt stor dynamik får du väl implementera de själv....

Det klarar jag inte av. Jag har redan gjort jobb med kommunikation mellan Java och Octave via socket, men jag föredrar C på uC då samplingsintervallet blir konstant.

Men nu vet man det! Eller så återgår jag till GSL igen. Det skulle ju tydligen fungera att använda, trots att den tog upp halva minnet.

Eventuellt så kanske man skulle titta på C++ för GNU Octave. Octave har en C++ API, men frågan om man kan köra denna API på uC?