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.
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?
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.
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.
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?
Senast redigerad av Al_Bundy 30 januari 2019, 00:07:19, redigerad totalt 1 gång.
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.
