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

[Mindmapper]

Intressant att höra hur ofta du går in och optimerar om din adaptiva regulator?

Har själv ingen aning om hur snabbt man kan behöva göra det vid snabba processer. Intressant att höra både i det program som du håller på med nu. Samt vid en process där du har behov av en extremt snabb uppdatering av optimeringen!

[jesse]

Jag begriper inte hur kvadratisk programmering fungerar, och orkar inte heller läsa om det då jag inte orkar med de matematiska uttrycken. Diskret matematik var det jag var sämst på att begripa... Jag fattar fortfarande inte hur det kan tillämpas. Men jag tänkte fråga dig, AlBundy, vad det är för egenskaper hos kvadratisk programmering som krävs för dina beräkningar och på vilket vis det skiljer sig från enklare regulatorer (som t.ex. PID) ?
Exempelvis det där med fjädringen.... Har du jämfört resultatet med hur en enklare algoritm hade löst problemet? Jag tycker om matematik, men vid en viss nivå så slutar min hjärna att fungera. När det gäller numeriska metoder (alltså hur man med hjälp av dator kan beräkna olika saker) så brukar jag hitta på mina egna eftersom jag ofta förstår grundproblemet bättre än andras invecklade förklaringar.

Personligen tycker jag det är enklast att lösa matematiska problem med C-kod , allt annat är mest krångel.

Och det problem du jobbar på nu, är väl hemligt antar jag, men vad är det du behöver göra, rent praktiskt? Varför en långsam PWM? Vad ska regleras? Hur många insignaler handlar det om? Är det bara en utsignal (PWM)?

[Icecap]

Oftast är det så att om man fläskar på med maskiner och regleringar där ett enklare system hade varit fullt funktionsdugligt har man inte fattat problemet.

Jag kör med en 32-bitars µC och har fixat all hardware-interface medelst datablad i handen. Visst är det ett meck till en början men sedan har man full kontroll och tydliga rutiner.

[lillahuset]

Den här tråden blir det snart nöjeskatt på om inte Al lugnar ner sig.

[AndLi]

Kod: Markera allt

  HAL_TIM_Base_Start_IT(&htim3); <--- Denna har jag gjort för att starta räknaren.

Kod: Markera allt

while (1)
  {
    /* USER CODE END WHILE */
	  int value = htim3.Instance->CNT;
	  if (value == 400){
		  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET);
	  }else if (value == 500){
		  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_RESET);
	  }else{

	  }
    /* USER CODE BEGIN 3 */
  }

Ok! En 555 timer var en dålig ide

Och du tyckte din implementation var en bra ide?
Initieringen ser ju fin ut, du startar timern med funktionen som kommer enabla ett interrupt (som sannolikt slår när räknaren slår runt)

Men för att sen istället använda detta interrupt gör du en while(1) loop i main som ligger och läser registret konstant.
Var det inte precis detta du ville undvika? Hur tänker du gå vidare och implementera din seriekommunikation?
Vad händer när din seriekommunikationsrutin tar mer än 1 tick på din räknare att köra klart?

[Al_Bundy]

Intressant att höra hur ofta du går in och optimerar om din adaptiva regulator?

Har själv ingen aning om hur snabbt man kan behöva göra det vid snabba processer. Intressant att höra både i det program som du håller på med nu. Samt vid en process där du har behov av en extremt snabb uppdatering av optimeringen!

Jag begriper inte hur kvadratisk programmering fungerar, och orkar inte heller läsa om det då jag inte orkar med de matematiska uttrycken. Diskret matematik var det jag var sämst på att begripa... Jag fattar fortfarande inte hur det kan tillämpas. Men jag tänkte fråga dig, AlBundy, vad det är för egenskaper hos kvadratisk programmering som krävs för dina beräkningar och på vilket vis det skiljer sig från enklare regulatorer (som t.ex. PID) ?
Exempelvis det där med fjädringen.... Har du jämfört resultatet med hur en enklare algoritm hade löst problemet? Jag tycker om matematik, men vid en viss nivå så slutar min hjärna att fungera. När det gäller numeriska metoder (alltså hur man med hjälp av dator kan beräkna olika saker) så brukar jag hitta på mina egna eftersom jag ofta förstår grundproblemet bättre än andras invecklade förklaringar.

Personligen tycker jag det är enklast att lösa matematiska problem med C-kod , allt annat är mest krångel.

Jag kan förklara kvadratisk programmering på en förenklad nivå. Låt oss säga att vi har en variabel T som är våran temperaturvariabel över tid. Vi har våran R som är en referens. Dit vill vi nå. Om R == T så har vi uppnått vårat mål. Vi har våran önskade temperatur. Men vårat system som tillverkar denna temperatur, drivs av energin U. Vi kan säga att U är t.ex. strömmen in till en doppvärmare eller värmeelement.

Om vi jämför energin in och energin ut så får vi skillnaden U - T. Om U - T = 0 så betyder det att vi har ett väldigt effektivt system som inte har några förluster. Systemet kan tolkas då som statiskt då det är dynamiken som orsakar förluster. I praktiken sker detta aldrig.

I praktiken så ser det mer ut som så här (R-T) - U. Om (R-T) - U = 0 så har vi ett perfekt system. I verkligheten så kommer (R-T) - U aldrig vara noll för T är beroende av U. Tänk nu om vi har en matematisk modell av vårat system och sedan simulerar vi vårat system med olika U = {0,1,2,3,4,5,6,7,8....1023} över t.ex. 10 sekunder. Då kommer vi få 1024 olika variabler av U och T som varierar över tid. Vi sätter in dem formler:

J0 = (R-T0) - U0;
J1 = (R-T1) - U1;
J2 = (R-T2) - U2;
J3 = (R-T3) - U3;
J4 = (R-T4) - U4;
.
.
.
.
J1023 = (R-T1023) - U1023;

Här betyder det att t.ex U4 är {4,4,4,4,4,4,4,4,4,4,4,4,4,4,4} över hela simuleringstiden 10 sekunder. Nu har vi alla J0 till J1023. Nu kollar vi vilken J som är minst. Om vi hittar att J75 är minst så vet vi vilken som är den bästa signalen.

Då applicerar vi signal U75 i en itteration hos CPU:n och sedan gör vi samma beräkning igen. Därför krävs det MYCKET processorkraft om man ska använda kvadratisk programmering då hålla på simulera över 1000 gånger är ännu mera krävande. Med kavadratisk programmering så är tänket fortfarande det samma.

Men jag tänkte fråga dig, AlBundy, vad det är för egenskaper hos kvadratisk programmering som krävs för dina beräkningar och på vilket vis det skiljer sig från enklare regulatorer (som t.ex. PID) ?

Med kvadratisk programmering kan man sätta gränser i systemet att man kan t.ex. inte "köra så fort upp" eller "man kan inte passera dessa insignalsvärden". Randvillkor eller signalmättningar som det heter.

En PID kräver att du hittar P,I,D värderna. En regulator med kvadratisk programmering kräver endast att du talar om hur mycket data den ska beräkna. Sådant höftar man bara till t.ex. 20 sekunder i framtiden ska regulatorn förutspå. Då räknar regulatorn och tar hänsyn till t.ex. dötider och begränsingar och sedan spottar den ut ett värde som du ska ha.

Notera att regulatorer med kvadratisk programmering är riktigt dyra. Men ska man ha ett optimerat system så duger inte en PID.

Exempelvis det där med fjädringen.... Har du jämfört resultatet med hur en enklare algoritm hade löst problemet? Jag tycker om matematik, men vid en viss nivå så slutar min hjärna att fungera. När det gäller numeriska metoder (alltså hur man med hjälp av dator kan beräkna olika saker) så brukar jag hitta på mina egna eftersom jag ofta förstår grundproblemet bättre än andras invecklade förklaringar.

Med enklare algoritm så hade jag fått överskjut och den inte kan ta hänsyn till fördröjning. Skit i matematik. Lär dig att läsa vetenskapliga rapporter och istället. Det viktigaste är att man förstår tanken bakom varför man gör detta, inte att man ska förstå exakt varje formel. Linjär algebra är ett måste att förstå. Men det är bara veta vad man gör, inte hur man med papper och penna räknar ut det.

Personligen tycker jag det är enklast att lösa matematiska problem med C-kod , allt annat är mest krångel.

Lycka till med kvadratisk programmering med C. Du kan väll titta på GNU Scentific library. Jag föredrar högnivåspråk.

Och det problem du jobbar på nu, är väl hemligt antar jag, men vad är det du behöver göra, rent praktiskt? Varför en långsam PWM? Vad ska regleras? Hur många insignaler handlar det om? Är det bara en utsignal (PWM)?

Rent praktiskt så ska jag använda min STM32 som ska fungera som en I/O modul. Denna modul ska ha UART kommunikation med en PC. STM:en ska även läsa temperatur som skickas till datorn. Datorn ska beräkna temperaturen i en matematisk modell och sedan spotta ut ett värde och ge den till STM:en via UART och STM:en ska ändra "PWM:en". I detta fall så ändras bara ett värde.

Det ska vara 3 stycken utgångar som ska "pulseras".

[Al_Bundy]

Oftast är det så att om man fläskar på med maskiner och regleringar där ett enklare system hade varit fullt funktionsdugligt har man inte fattat problemet.

Jag kör med en 32-bitars µC och har fixat all hardware-interface medelst datablad i handen. Visst är det ett meck till en början men sedan har man full kontroll och tydliga rutiner.

Jo. Men ska man ha ett självinstälande system så krävs det faktiskt beräkning på högre nivå.

[Al_Bundy]

Kod: Markera allt

  HAL_TIM_Base_Start_IT(&htim3); <--- Denna har jag gjort för att starta räknaren.

Kod: Markera allt

while (1)
  {
    /* USER CODE END WHILE */
	  int value = htim3.Instance->CNT;
	  if (value == 400){
		  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET);
	  }else if (value == 500){
		  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_RESET);
	  }else{

	  }
    /* USER CODE BEGIN 3 */
  }

Ok! En 555 timer var en dålig ide

Och du tyckte din implementation var en bra ide?
Initieringen ser ju fin ut, du startar timern med funktionen som kommer enabla ett interrupt (som sannolikt slår när räknaren slår runt)

Men för att sen istället använda detta interrupt gör du en while(1) loop i main som ligger och läser registret konstant.
Var det inte precis detta du ville undvika? Hur tänker du gå vidare och implementera din seriekommunikation?
Vad händer när din seriekommunikationsrutin tar mer än 1 tick på din räknare att köra klart?

Ja. Tyckte ja.

Så ska jag inte ha starten i denna statiska funktion?

Ja. Jag läser konstant då detta värde 511 ska ju vara variabelt. Finns det ett annat sätt att kontrollera pullstiden så lyssnar jag gärna. Det var därför jag tänkte att en extern enhet borde sköta PWM:en och bara STM:en säger åt vad denna enhet skall göra.

Jag har inte kommit så långt och tänkt på seriekommunikationsrutinen.

[jesse]

Jag kan förklara kvadratisk programmering på en förenklad nivå. ...

Intressant. Jag tror jag ska försöka sätta mig in i detta vid senare tillfälle.

Du menar att du t.ex. skapar 1024 olika gissningar hur du ska reglera.... Och sedan kollar vilken av dessa som kommer närmast målet.
Men hur kan du det utan att testa alla 1024 varianterna i verkligheten för att jämföra dem? Om du reglerar på ETT visst sätt, och 20 sekunder senare visar det sig ge ett hyfsat resultat med litet fel... hur ska du kunna gissa att en annan av de 1024 alternativen skulle fungera bättre (eller sämre)? Jag tror jag missat något väsentligt här... ???

[AndLi]

Så ska jag inte ha starten i denna statiska funktion?

Ja. Jag läser konstant då detta värde 511 ska ju vara variabelt. Finns det ett annat sätt att kontrollera pullstiden så lyssnar jag gärna. Det var därför jag tänkte att en extern enhet borde sköta PWM:en och bara STM:en säger åt vad denna enhet skall göra.

Jag har inte kommit så långt och tänkt på seriekommunikationsrutinen.

Starten är bra, men din jämförelsekod borde ligga i interruptrutinen, på så sätt kommer den bara köras när värdet har ändrats, inte konstant som i din kod.
(Se min tidigare förklaring/exempel)

[Al_Bundy]

Problemet är att jag vet inte hur man gör en interrupt när ett värde har uppdateras. STM32's utvecklingsverktyg är ingen självklarhet, som många andra verktyg är.

Är det någon global interrupt timer jag ska bocka i? Om jag gör det då? Vad ska jag göra då sedan?

[Al_Bundy]

Jag kan förklara kvadratisk programmering på en förenklad nivå. ...

Intressant. Jag tror jag ska försöka sätta mig in i detta vid senare tillfälle.

Du menar att du t.ex. skapar 1024 olika gissningar hur du ska reglera.... Och sedan kollar vilken av dessa som kommer närmast målet.
Men hur kan du det utan att testa alla 1024 varianterna i verkligheten för att jämföra dem? Om du reglerar på ETT visst sätt, och 20 sekunder senare visar det sig ge ett hyfsat resultat med litet fel... hur ska du kunna gissa att en annan av de 1024 alternativen skulle fungera bättre (eller sämre)? Jag tror jag missat något väsentligt här... ???

Exakt! Med QP så behöver man inte gissa

QP-programmering behöver ha en matematisk modell av systemet.

[AndLi]

Problemet är att jag vet inte hur man gör en interrupt när ett värde har uppdateras. STM32's utvecklingsverktyg är ingen självklarhet, som många andra verktyg är.

Är det någon global interrupt timer jag ska bocka i? Om jag gör det då? Vad ska jag göra då sedan?

Ja sannolikt för den timer du har valt, använder inte cubeMX så jag vet inte hur man gör där..
Sedan bör det väl skapas en interrupt rutin där du kan fylla i din kod.

[Al_Bundy]

Här hittade jag en liten funktion som man ska applicera utanför main() i main.c

Kod: Markera allt

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
    // Placera din kod här
}

Hur vet jag att denna funktion anropas efter timerna har gjort sin cykel? Mystiska C programmering!

[svanted]

Jag kan förklara kvadratisk programmering på en förenklad nivå. ...

Intressant. Jag tror jag ska försöka sätta mig in i detta vid senare tillfälle.

Du menar att du t.ex. skapar 1024 olika gissningar hur du ska reglera.... Och sedan kollar vilken av dessa som kommer närmast målet.
Men hur kan du det utan att testa alla 1024 varianterna i verkligheten för att jämföra dem? Om du reglerar på ETT visst sätt, och 20 sekunder senare visar det sig ge ett hyfsat resultat med litet fel... hur ska du kunna gissa att en annan av de 1024 alternativen skulle fungera bättre (eller sämre)? Jag tror jag missat något väsentligt här... ???

tycker Al använder fel storheter energi istf effekt,
och T finns på 2 ställen.

och är inte så att effekten ut hela tiden varierar? alltså uttagen effekt från ett system, om man ska simulera måste man ju mäta den för att få en korrekt simulering och om man mäter den ska ju den vara samma som effekten in som man då ska reglera.
men det kommer inte att fungera då minsta mätfel adderas över tid...
så i slutänden måste väl ändå ärvärdet vara det man reglerar mot.