Matrisberäkningar med för STM32?

[lillahuset]

Om man vill är det inget problem att allokera minne dynamiskt vid programstart Sedan kan det vara praktiskt att ha en flagga för varje matris för att se om den är ledig eller inte.

[hummel]

Jag tycker att man borde kunna retunera flera värden samtidigt, utan att använda pekare. Detta skulle vara bra. Och lägg till objektorientering i C!

Sockret?

Objektorienterad funktionalitet fixade Bjarne S för drygt 35 år sedan när han skapade C++. Använd C++ om du vill köra objektorienterat. Jag skulle inte rekommendera C++ för inbyggda system. Kolla gärna på MISRA att använda som hjälp vid embeddedprogrammering.
Mr Andersson beskriver väldigt bra ovan vad vi menar med socker.

[TomasL]

Jag vet inte annars vad jag ska använda.

Heltal är bra och snabbt.
Och alla STM32 har inte FPU

[Al_Bundy]

Jag ska lägga detta på minnet mitt. Just nu måste jag planera för att skriva om:

Kod: Markera allt

*(ptr + i*n + j)

Till

Kod: Markera allt

A[i][j]

En nyfiken fråga! Ska man anpassa koden efter ANSI C eller C99? Jag vet att vissa företag kör fortfarande med gammal C standard. Varför vet jag inte.

[TomasL]

Du behöver inte anpassa nånting, egentligen. dock fram till C11 så har det tillkommit en del saker, främst med "multithreading" och liknande.

Sen är frågan, vad du menar med ANSI-C, eftersom det egentligen inte finns något sådant, dock gissar jag att du menar C89.
Desto äldre standard, desto bättre kompabilitet.
Dock, eftersom GCC stöder de senaste standarderna, så spelar det ingen roll.

[Al_Bundy]

Okej. int32_t istället för float och inte använda dynamisk allokering.

Då väljer jag C11.

[TomasL]

Du kan villkora koden mot existens av FPU.

typ:
#ifdef FPU_1PREC
#define float float
#endif
#ifdef FPU_2PREC
#define float double
#endif
#ifdef NO_FPU
#define float int32_t
#endif
dock är det lite farligt och du bör använda ett annat namn än float när du sedan skpar dina variable, och byta ut "float" i första kollumnen ovan mot detta

Till exempel
#ifdef FPU_1PREC
#define al_bundy_type float
#endif
#ifdef FPU_2PREC
#define al_bundy_type double
#endif
#ifdef NO_FPU
#define al_bundy_type int32_t
#endif

då använder du "al_bundy_type" när du skapar dina variabler

[Al_Bundy]

Japp.

https://www.st.com/en/microcontrollers/stm32f401re.html

The STM32F401xD/xE devices are based on the high-performance ARM®Cortex® -M4 32-bit RISC core operating at a frequency of up to 84 MHz. Its Cortex®-M4 core features a Floating point unit (FPU) single precision which supports all ARM single-precision data-processing instructions and data types. It also implements a full set of DSP instructions and a memory protection unit (MPU) which enhances application security.

Så det går helt enkelt snabbare att använda heltal än flyttal.

[TomasL]

Nej, inte nödvändigtvis, om du har en FPU, och din kompilator kan utnyttja den, så är flyttal lika snabbt, för det mesta.
Man får helt enkelt testa vilket som är snabbast

[Al_Bundy]

Du kan villkora koden mot existens av FPU.

typ:
#ifdef FPU_1PREC
#define float float
#endif
#ifdef FPU_2PREC
#define float double
#endif
#ifdef NO_FPU
#define float int32_t
#endif
dock är det lite farligt och du bör använda ett annat namn än float när du sedan skpar dina variable, och byta ut "float" i första kollumnen ovan mot detta

Till exempel
#ifdef FPU_1PREC
#define al_bundy_type float
#endif
#ifdef FPU_2PREC
#define al_bundy_type double
#endif
#ifdef NO_FPU
#define al_bundy_type int32_t
#endif

då använder du "al_bundy_type" när du skapar dina variabler

Kan jag inte bara använda int32_t när jag beräknar och kasta om det till float när jag vill skriva ut det på skärmen?

[TomasL]

Varför krångla till det, lättare att göra tvärtom, skriva ut en int, och sätta decimalkommat där du vill ha det, för det mesta är ju man ointresserad av mer än en decimal, möjligtvis två.

[Al_Bundy]

Nej, inte nödvändigtvis, om du har en FPU, och din kompilator kan utnyttja den, så är flyttal lika snabbt, för det mesta.
Man får helt enkelt testa vilket som är snabbast

Okej! Där lurade du mig lille Tomas. Jag får nog behålla floats då.

Jag kommer sitta vid 32-bits CPU:er som har FPU. Det är en sådan kod jag skriver till. Inte till dem som inte har FPU.

[Al_Bundy]

Varför krångla till det, lättare att göra tvärtom, skriva ut en int, och sätta decimalkommat där du vill ha det, för det mesta är ju man ointresserad av mer än en decimal, möjligtvis två.

Inte när det kommer till QR-faktorisering. Där kan värderna stiga upp till e+308 om den känner för det. Så det är viktigt att man ständigt dividerar värderna för att hålla ned talet, tills QR konvergerar till sina rätta matriser.

QR används för lösa linjära beräkningar som har brus.

När det kommer till systemidentifiering så finns det inte ett enda heltal. Minst 4 decimaler brukar jag använda.

[Al_Bundy]

Detta är orsaken varför jag valde allokera minne.

Kod: Markera allt

float values2[6][6] = { { 2, 3, 1, 0.5, 4, 44.3 },
				{ 4, 5, 7, 0.1, 1, 5.3 },
				{ 5, 3, 6, 19.2, 9, 34.2 },
				{ 1, 4, 1, 4, 7, 4.24 },
				{ 3, 1, 6, 2, 6, 5.3 },
				{ 3, 1, 6, 2, 6,6.23}};


	 
	   int column = sizeof(values2[0]) / sizeof(float);
	   int row = sizeof(values2) / sizeof(values2[0]);

	   printf("Number of rows: %d\n", row);
	   printf("Number of columns: %d\n", column);


	testFunction(values2);

>> Number of rows: 6
>> Number of columns: 6

Men om jag sätter ett macro i en huvudfil declareFunctions.h.

Kod: Markera allt

#define columns(arr) ((int) sizeof(arr[0]) / sizeof(float))
#define rows(arr) ((int) sizeof(arr) / sizeof(arr[0]))

Sedan kör jag denna funktion.

Kod: Markera allt

#include "declareFunctions.h"

void testFunction(float** arr){
	int m  = columns(arr);
	printf("Kolumnen är m = %d", m);
}

Då får jag utskriften.

Kolumnen är m = 2

Det blir nog ingen omskrivning. Jag får helt enkelt acceptera att C kan inte hantera 2D arrayer igenom funktioner. Eller så får man gå över till C++.

P.S Hittade en fiende till Tomas. Undra vilken dynamit han skulle ha använt om jag hade sagt detta?

https://www.quora.com/Why-is-malloc-har ... ed-systems

Fråga: Why is malloc() harmful in embedded systems?

Svar:
I’ve used malloc() in embedded systems for decades. malloc() is only harmful if you don’t know what you are doing and/or you are not paying attention to detail.

Myself, I don’t consider malloc() harmful.

[hawkan]

Nattugglor? hehe

Tänker du dej att göra en mikro-version av matlab (eller matlab-syntax i alla fall)? Dvs att användaren interaktivt ska kunna ange olika matlab-rader och de utförs?
Det har en stor betydelse för hur man lägger upp programmet och utformar de olika funktionerna du jobbar med.
Har man en stängd miljö som en µC kan sägas vara och all beräkning är på förväg känd så gör man på ett visst sätt
för att få allt så effektivt och förutsägbart som möjligt.
Har du däremot en interaktiv miljö där man på förväg inte kan säga exakt ordning på beräkningar så måste man göra
det hela flexibelt så att alla tänkbara situationer kan hanteras.