Är en STM32 bra att använda som USB I/O-modul?

[AndLi]

> Och vad är fel ställe?

Om du kollar kommentarerna i delen nedan så *måste* du väl se att något är fel.
Det är möjligt att koden ändå gör vad som är avsett, det bryr jag mig inte om.

Kod: Markera allt

   /* Infinite loop */
   /* USER CODE BEGIN WHILE */
   while (1) {
      /* USER CODE END WHILE */
      temperatureValues[0] = adcValues[0];
      temperatureValues[1] = adcValues[1];
      temperatureValues[2] = adcValues[2];
      /* USER CODE BEGIN 3 */
   }
   /* USER CODE END 3 */

Jag har inga andra synpunkter på koden eller på "problemet", mer än att
sådant här inte ger något förtroende generellt.

Precis det jag också tyckte såg fel ut, det påverkar inte C kompilatrn, men kan på cubeMX att bli förvirrad..

Har du något i din while(1)?
Har du någon optimering påslagen för kompilatorn?

Det är inte alls säkert att bara för att du skrivit en rad C att kompilatorn kommer skapa någon kod för den raden om den kommer på ett effektivare sätt att göra det.
Det är inte heller säkert att du kan göra en watch på en variabel varsomhelt i en funktion, det kan vara så att den bara existerar just under de rader du använder variabeln.
Sen återanvänder kompilatorn registret den var lagrad i till något annat.

[sodjan]

> Men dessa kommentarer är automatiskt genererade.

Och hur såg det ut direkt efter automatgenereringen innan du stoppade in dina rader?

> Men programmet hoppar inte till while(1)

Det kanske den gör. Men sedan har du inget interrupt.
Men det är väl skitenkelt att kolla/verifiera om den är i while loopen...

> Nu fungerar det.

Varför lägger du dina rader *efter* "USER CODE END WHILE"?
Varför ligger "USER CODE BEGIN 3" *inne* i while loopen?

Det är mycket möjligt att din delay döljer en race-condition orsakad av att du
ligger och läser ADC "så fort det går" i while loopen. Jag kan inte se annat
än att hela den designen är helt fel. Skulle det inte hanteras i ett interrupt?

[hawkan]

Prova med

Kod: Markera allt

volatile uint32_t adcValues[3] = { 55, 54, 53 }; // ADC values from temperature sensors

Globala variabler som ändras i irq behöver detta.
https://embedds.com/using-volatile-keyw ... dded-code/

[Al_Bundy]

Sannolikt optimering gjord av kompilatorn.

Deklarera adcValues som volatile.

Kod: Markera allt

volatile uint32_t adcValues[3] = { 55, 54, 53 }; // ADC values from temperature sensors

Då får jag en varning.

[sodjan]

Och det är självklart väldigt hemligt *vilken* varning du fick?
Du måste förstå att flera blir väldigt frustrerade av din stil och
du kan göra mycket mer för att undvika det. Bättring!

[Al_Bundy]

> Men dessa kommentarer är automatiskt genererade.

Och hur såg det ut direkt efter automatgenereringen innan du stoppade in dina rader?

> Men programmet hoppar inte till while(1)

Det kanske den gör. Men sedan har du inget interrupt.
Men det är väl skitenkelt att kolla/verifiera om den är i while loopen...

> Nu fungerar det.

Varför lägger du dina rader *efter* "USER CODE END WHILE"?
Varför ligger "USER CODE BEGIN 3" *inne* i while loopen?

Det är mycket möjligt att din delay döljer en race-condition orsakad av att du
ligger och läser ADC "så fort det går" i while loopen. Jag kan inte se annat
än att hela den designen är helt fel. Skulle det inte hanteras i ett interrupt?

>> Och hur såg det ut direkt efter automatgenereringen innan du stoppade in dina rader?
Så här:

Kod: Markera allt

int main(void) {
	/* USER CODE BEGIN 1 */

	/* USER CODE END 1 */

	/* MCU Configuration--------------------------------------------------------*/

	/* Reset of all peripherals, Initializes the Flash interface and the Systick. */
	HAL_Init();

	/* USER CODE BEGIN Init */

	/* USER CODE END Init */

	/* Configure the system clock */
	SystemClock_Config();

	/* USER CODE BEGIN SysInit */

	/* USER CODE END SysInit */

	/* Initialize all configured peripherals */
	MX_GPIO_Init();
	MX_DMA_Init();
	MX_USART2_UART_Init();
	MX_ADC1_Init();
	MX_TIM3_Init();
	MX_TIM2_Init();
	/* USER CODE BEGIN 2 */

	/* USER CODE END 2 */

	/* Infinite loop */
	/* USER CODE BEGIN WHILE */
	while (1) {
		/* USER CODE END WHILE */

		/* USER CODE BEGIN 3 */
	}

	/* USER CODE END 3 */
}

>> Varför lägger du dina rader *efter* "USER CODE END WHILE"?
Varför ligger "USER CODE BEGIN 3" *inne* i while loopen?

CubeMX. Troligtvis så betyder dessa ändå inget för kompilatorn.

>> Det är mycket möjligt att din delay döljer en race-condition orsakad av att du
ligger och läser ADC "så fort det går" i while loopen. Jag kan inte se annat
än att hela den designen är helt fel. Skulle det inte hanteras i ett interrupt?

Det fungerar även med delay 0. Jo. Den ska hanteras i ett interrupt. Men ST's HAL kanske slutar vid sista HAL-funktionen?

[Al_Bundy]

Och det är självklart väldigt hemligt *vilken* varning du fick?
Du måste förstå att flera blir väldigt frustrerade av din stil och
du kan göra mycket mer för att undvika det. Bättring!

Varningen jag fick var att det blev fel i själva pekaren på denna rad. Alltså adcValues passade inte in.

Kod: Markera allt

HAL_ADC_Start_DMA(&hadc1, adcValues, 3);

Väldigt blir "frustrerad" också när du upprepar samma fråga angående om kommentarerna, och får samma svar.

[Al_Bundy]

> Och vad är fel ställe?

Om du kollar kommentarerna i delen nedan så *måste* du väl se att något är fel.
Det är möjligt att koden ändå gör vad som är avsett, det bryr jag mig inte om.

Kod: Markera allt

   /* Infinite loop */
   /* USER CODE BEGIN WHILE */
   while (1) {
      /* USER CODE END WHILE */
      temperatureValues[0] = adcValues[0];
      temperatureValues[1] = adcValues[1];
      temperatureValues[2] = adcValues[2];
      /* USER CODE BEGIN 3 */
   }
   /* USER CODE END 3 */

Jag har inga andra synpunkter på koden eller på "problemet", mer än att
sådant här inte ger något förtroende generellt.

Precis det jag också tyckte såg fel ut, det påverkar inte C kompilatrn, men kan på cubeMX att bli förvirrad..

Har du något i din while(1)?
Har du någon optimering påslagen för kompilatorn?

Det är inte alls säkert att bara för att du skrivit en rad C att kompilatorn kommer skapa någon kod för den raden om den kommer på ett effektivare sätt att göra det.
Det är inte heller säkert att du kan göra en watch på en variabel varsomhelt i en funktion, det kan vara så att den bara existerar just under de rader du använder variabeln.
Sen återanvänder kompilatorn registret den var lagrad i till något annat.

>> Har du något i din while(1)?
Har du någon optimering påslagen för kompilatorn?

Ja. Detta:

Kod: Markera allt

while (1) {
		/* USER CODE END WHILE */
		temperatureValues[0] = adcValues[0];
		temperatureValues[1] = adcValues[1];
		temperatureValues[2] = adcValues[2];


		HAL_Delay(0);
		/* USER CODE BEGIN 3 */
	}

Nej.

[Klas-Kenny]

Det löser du enkelt med en cast.

Kod: Markera allt

HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adcValues, 3);

Sen är varningar bara just det, varningar. Inte fel. Så, fungerar det med volatile?

[Al_Bundy]

Ja! Nu löste det sig. Varför då?

Kod: Markera allt

volatile uint32_t temperatureValues[3]; // Send to PC
volatile uint32_t adcValues[3] = { 55, 54, 53 }; // ADC values from temperature sensors

[Rick81]

För att kompilatorn inte vet att interupt kommer köras de i de inte finns i "flödet' och optimerar bort dessa variabler. Volatile tvingar kompilator att intr optimera bort dem. Så kör alltid volatile på variabler i interuptfunktioner.

[Al_Bundy]

Om jag minns rätt så ska man undvika hålla på med flyttal så mycket som det går i en uC?

[Al_Bundy]

För att kompilatorn inte vet att interupt kommer köras de i de inte finns i "flödet' och optimerar bort dessa variabler. Volatile tvingar kompilator att intr optimera bort dem. Så kör alltid volatile på variabler i interuptfunktioner.

Tack för ett bra tips! Denna ska jag komma ihåg.

[Rick81]

stm32f4 har fpu villket betyder den kan göra flyttalsoperationer i princip lika snabbt som integer men der måste aktiveras i kompilatorn typ fpu_hard
Men annars är tumregel undvika floats i inbyggda processorer

[sodjan]

Har frågan om flyttal något med kontexten kring volatile att göra?
Eller var det bara en generell fråga inkastad i flödet? Nu så går det
ju inte att svara generellt på frågan om flyttal, "det beror på". På en
processor med hårdvarustöd för flyttal så har det ju så klart mindre
betydelse än på processorer utan det. Men, det är ju oklart varför
du frågar också, så det går inte riktigt att svara på det...

Och OK, uppenbarligen så genererar HAL lite underliga kommenterar
på ologiska platser. OK...