Svenska ElektronikForumet

> Ja det är hardfault..troligen försöker du accessa en minnesarea du inte kan...

Kan det vara så enkelt som att man försöker allokera minne av samma "typ" som där koden körs?
Alltså sannolikt flash på ett inbyggt system, men troligtvis helt OK på en normal "dator".
Malloc mot flash-arean lär ju inte gå så bra...

Visst, man kan ju tänka sig att man skriver till en read-only area också, och det skulle kunna
upptäckas vid länkning. Jag fattade inte riktigt om felet uppstod vid build eller i runtime...

sodjan skrev: Jag fattade inte riktigt om felet uppstod vid build eller i runtime...

Felet uppstod vid körning. Man fick inte heller något förslag på vad som gick snett med min C-kod. Men min C-kod innehåller två malloc. En malloc finns i stdlib.h och en finns i a77_alloc.c. Men frågan är om just dessa två malloc är problemet? Jag menar, stdlib.h är ju standard i C.

Även null-pekare brukar kunna ge hardfault.

Görs kontroller att malloc verkligen ger en riktig pekare?
Vill minnas att man förut har klagat på att returvärdet från malloc ej kontrolleras. Skulle ju kunna vara så att malloc helt enkelt inte fungerar i uC, åtminstone med vald byggmiljö.

Tillägg: men att gissa är ju bortkastat när man har en debugger. Bara single-steppa genom programmet och se var det går fel.

Ni tror inte printf ställer till med problem för mig?

Edit. Jag verkar ha problem med GPIO.

Du kan köra en retarget på printf via stm32cube....bara använda dina egna funktioner for putchar ex. skicka ut på UART

Hur menar du? Finns det något alternativ man kan bocka i så printf går via serialen?

Använd sprintf i stället för printf och skicka strängen till serieporten.

Jag ska tänka på det. Men jag tror inte att jag har problem med printf.

Jag har testat följande:
1. Jag har tagit ett färdigt projekt som skickar ut data till USB porten. Jag har applicerat mitt C-bibliotek där, utan någon matrisalgebra. Det fungerar OK! Inga error eller bråk med CPU.
2. Jag har tagit samma färdiga projekt och lagt till min matris-C-kod och då kraschar CPU:n.
3. Jag har skalat bort kod mer och mer och tillslut hittar jag att programmet kraschar i denna funktion.

Detta var samma funktion som Valgrind klagade på för någon månad sedan. Lustigt att valgrind inte klagar på den nu.
Jag har även testat att ta bort ALL kod i triu-funktionen. Det bort fortfarande ett stop. Nu känner jag mig rätt vilsen, när tomma funktioner kan göra så att allt stannar.

Kod: Markera allt

void triu(float* A, float* B, int shift, int row, int column){

	// Reset our outut matrix B
	memset(B, 0, row*column*sizeof(float)); // Det är inte den här programmet styper i....Det spelar ingen roll om jag kommenterar bort denna memset.

	// Compensator - Else, we cannot use non-square matrix
	int t = row - column;

	// Create a triangular matrix
	for(int i = 0; i < row; i++){
		for(int j = 0; j < column; j++){
			// Do the "jump"
			if(j == 0){
				j = i + shift; // When we are at column 0 again, jump then n rows + shift at the right
			}
			// Write
			if(j != column)
				*((B + i*(row-t)) + j) = *((A + i*(row-t)) + j);
		}
	}
}

Denna kod kör jag. Den har noll koppling till mitt C-bibliotek.

Kod: Markera allt

float y[144] = { 0.00000, 0.49525, 1.43863, 2.13779, 2.30516, 2.05713,
			1.69220, 1.45608, 1.42777, 1.54146, 1.67927, 1.75624, 1.75400,
			1.70478, 1.65394, 1.62996, 1.63549, 1.65594, 1.67426, 1.68125,
			1.67752, 1.66930, 1.66285, 1.66102, 1.66300, 1.66621, 1.66842,
			1.66880, 1.66786, 1.66664, 1.66591, 1.66588, 1.66629, 1.66675,
			1.66698, 1.66695, 1.66678, 1.66661, 1.66654, 1.66657, 1.66664,
			1.66670, 1.66672, 1.66670, 1.66667, 1.66665, 1.66665, 1.66666,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66666, 1.66666,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667, 1.66667,
			1.66667, 1.66667, 1.66667, 1.66667, 1.66667 };

	float u[144] = { 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
			5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
			5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
			5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
			5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
			5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
			5, 5, 5, 5, 5, 5, 5, 5, 5 };

	// Toeplitz matrix
	float toe[144 * 144];
	toeplitz(u, toe, 144);

	// Upper triangular
	float tru[144 * 144];
	triu(toe, tru, 0, 144, 144); // <--- Här stannar mitt program.

Det slår inte i taket vad gäller RAM? Float 144*144 blir över 80 kbytes. Du har två såna, plus kankse lite till. Vad har mcun, 192 kB RAM? Då är det på gränsen.

512 Kbytes har jag som minne.
SRAM 96 Kbytes

Aj då!

Hur gör man nu? Bättre CPU helt enkelt?

Jag testar att köra på en 2x2 matris och ta inversen på den. Då stannar inte CPU:n. Men jag kan fortfarande inte få något resultat om CPU:n räknar rätt. Får fortfarande samma felmeddelande tillbaka att matrisen inte kunde hittas. Mystiskt nog. Det kanske existerar trots allt?

Kanske man ska satsa på att köra på typ en Raspberry Pi istället? Då kanske man ska passa på att göra ett grafiskt gränssnitt också i GTK+? Eller så gör man en brygga över till Java om man vill ha ett GUI.

Eller kör du stm32h7 med 1MB RAM och double i FPU.

Ja du kan få printf till uart. Googla på retarget print i för eclipse stm32. Coocox IDE och Atollic har inbyggda funktioner för det. I princip lägger du in skicka en char över uart i en funktion som heter typ Putchar

Om du har STlink kan du sätta brytpunkter på de ställen där matrisen används så du hittar var det går fel.

Java och Raspberry pi har så många andra nackdelar då nu när du är så när målet kör på, ge inte upp!

Funktionen man ska skriva om heter int putchar(int c).

Vid att skriva om den till vad man önskar kan man använda printf() fritt.
Om du inte har specifika hastighetskrav på utskriften kan du skriva byte för byte:

Kod: Markera allt

int putchar(int c)
  {
  while(UART_Upptagen); // Vänt på att UART'en blir ledig
  Sending_Register = c; // Sänd tecknet
  }

Själv använder jag interrupt-styrda utskrifter men sällan till debug, till debug ska det vara enkelt och dumt så det inte strular också.

Rick81 skrev:Eller kör du stm32h7 med 1MB RAM och double i FPU.

Ja du kan få printf till uart. Googla på retarget print i för eclipse stm32. Coocox IDE och Atollic har inbyggda funktioner för det. I princip lägger du in skicka en char över uart i en funktion som heter typ Putchar

Om du har STlink kan du sätta brytpunkter på de ställen där matrisen används så du hittar var det går fel.

Java och Raspberry pi har så många andra nackdelar då nu när du är så när målet kör på, ge inte upp!

Jag tror inte 1 mb ram räcker. Jag kom snabbt upp i 160 kb ram efter några rader kod.

Kanske man kan ansluta med externt RAM?

Jag skulle kunna använda min STM32 som I/O modul för USB och sedan utveckla ett program i JavaFX som talar med EmbeddedLapack.

Eller hitta en riktig fet uC att skriva till. Dem som har typ 256 mb ram osv.

Icecap skrev:Funktionen man ska skriva om heter int putchar(int c).

Vid att skriva om den till vad man önskar kan man använda printf() fritt.
Om du inte har specifika hastighetskrav på utskriften kan du skriva byte för byte:
Kod: Markera allt
int putchar(int c)
  {
  while(UART_Upptagen); // Vänt på att UART'en blir ledig
  Sending_Register = c; // Sänd tecknet
  }
Själv använder jag interrupt-styrda utskrifter men sällan till debug, till debug ska det vara enkelt och dumt så det inte strular också.

Tackar. Jag ska ordna detta.

Al_Bundy skrev:
Rick81 skrev:Eller kör du stm32h7 med 1MB RAM och double i FPU.

Ja du kan få printf till uart. Googla på retarget print i för eclipse stm32. Coocox IDE och Atollic har inbyggda funktioner för det. I princip lägger du in skicka en char över uart i en funktion som heter typ Putchar

Om du har STlink kan du sätta brytpunkter på de ställen där matrisen används så du hittar var det går fel.

Java och Raspberry pi har så många andra nackdelar då nu när du är så när målet kör på, ge inte upp!
Jag tror inte 1 mb ram räcker. Jag kom snabbt upp i 160 kb ram efter några rader kod.

Kanske man kan ansluta med externt RAM?

Jag skulle kunna använda min STM32 som I/O modul för USB och sedan utveckla ett program i JavaFX som talar med EmbeddedLapack.

Eller hitta en riktig fet uC att skriva till. Dem som har typ 256 mb ram osv.

Men alltså du behöver ju bara så mycket RAM som du behöver matriser. Eftersom du inte säger hur stora och hur många matriser du behöver går det ju inte säga. Du får plats med 12 st 144x144 matriser på en 1 MB. Behöver du verkligen ha så många samtidigt i RAM?

Och ja det går ansluta extrena RAM till STM32 men jag skulle inte rekommendera det om det går undvika då konstruktionen blir mer komlicerad.

Svenska ElektronikForumet

Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?

Re: Matrisberäkningar med för STM32?