Matrisberäkningar med för STM32?

[Al_Bundy]

Aha! Okej 0xFF == ~(ADC << 8 ) Då förstår jag. Då kan man lika använda detta.

Så nu när jag har tagit ett tal och delat upp det i två bytes och skickat dessa. Då är min fråga: Brukar det finnas inbyggd ACK inom STM32 eller datorvärlden?

Jag menar om jag t.ex. skickar 15 och sedan 202, vilket ska symbolisera första bitarna och sista bitarna. Då måste jag pussla ihop dessa på ett snyggt sätt, eller hur? Görs detta automatiskt eller i C? Typ som att C väntar på ett ACK? Eller jag kanske får skicka ut detta ACK helt manuellt?

Det är väll ett ACK som man ska skicka? Något typ av stoppsignal måste det väll vara?

[bearing]

En vanlig serieport har inga ack. Det finns möjligtvis lite dataflödeskontroll, men har själv aldrig använt detta, och vet inte om det skulle hjälpa dig. Om du gör om din USB-kommunikation till något annat än en serieportsemulering går det säkert att ordna paketbaserad kommunikation med ACK, men jag kan inte hjälpa dig med det.

Och anledningen till att vi föreslagit metoden att reservera en bit av åtta till att flagga "start av paket" är ju just att serielänken inte är paketbaserad, så man får hitta på något eget istället.

Ifall du väljer att köra ASCII kan du även bara använda '\n' (d.v.s CR) för att markera "slut av paket". Som jag pratade om på förra sidan. Men som vanligt blir allt en röra i dina trådar. Du växlar hit och dit och fram och tillbaka. Och du tycks absolut vägra att följa goda råd.

[Rick81]

Du sätter ihop ADC = (data1 << 8 )+ data2

Ack är ju beroende på protokollet och inte C.

Enkelt ack är ju att du skickar samma data tillbaks till stm32 och då slutar den skicka om data.

Tror vi gett dig förslag på protokoll med start, stop och checksumma tidiagare

[Al_Bundy]

En vanlig serieport har inga ack. Det finns möjligtvis lite dataflödeskontroll, men har själv aldrig använt detta, och vet inte om det skulle hjälpa dig. Om du gör om din USB-kommunikation till något annat än en serieportsemulering går det säkert att ordna paketbaserad kommunikation med ACK, men jag kan inte hjälpa dig med det.

Och anledningen till att vi föreslagit metoden att reservera en bit av åtta till att flagga "start av paket" är ju just att serielänken inte är paketbaserad, så man får hitta på något eget istället.

Ifall du väljer att köra ASCII kan du även bara använda '\n' (d.v.s CR) för att markera "slut av paket". Som jag pratade om på förra sidan. Men som vanligt blir allt en röra i dina trådar. Du växlar hit och dit och fram och tillbaka. Och du tycks absolut vägra att följa goda råd.

Nu tycker jag du är inte oförskämd. Bara för att jag inte följde just ditt råd, betyder inte att jag förkastade dig. Jag kanske följde någon annans råd. Tänk på det?

[Krille Krokodil]

Man behöver kanske inte uppfinna egna hjul för allting...

Jag hade ungefär samma problem för något år sedan där jag vill skicka ut floats med UDP och få det plottat och
med lite Google så kunde man finna färdiga lösningar, bla har jag för mig att jag hittade ett sådant program till
Matlab [vilket jag inte jobbar i].

[Al_Bundy]

Du sätter ihop ADC = (data1 << 8 )+ data2

Ack är ju beroende på protokollet och inte C.

Enkelt ack är ju att du skickar samma data tillbaks till stm32 och då slutar den skicka om data.

Tror vi gett dig förslag på protokoll med start, stop och checksumma tidiagare

Fungerar inte.

Kod: Markera allt

int ADC = 3025;
	u_int8_t data1 = (u_int8_t) (ADC >> 8);
	printf("Sending first data %i\n", data1);
	u_int8_t data2 = (u_int8_t) (ADC & 0xFF);
	printf("Sending last data %i\n", data2);
	u_int8_t data3 = 0x06; // ack
	printf("Sending ack data %i\n", data3);
	int complete = data1 + data2;
	printf("Reading complete data %d\n", complete);

Sending first data 11
Sending last data 209
Sending ack data 6
Reading complete data 220

Edit:

Nu fungerar det

Kod: Markera allt

int ADC = 3025;
	u_int8_t data1 = (u_int8_t) (ADC >> 8);
	printf("Sending first data %i\n", data1);
	u_int8_t data2 = (u_int8_t) (ADC & 0xFF);
	printf("Sending last data %i\n", data2);
	u_int8_t data3 = 0x06; // ack
	printf("Sending ack data %i\n", data3);
	int complete = data1*256 + data2;
	printf("Reading complete data %d\n", complete);

Sending first data 11
Sending last data 209
Sending ack data 6
Reading complete data 3025

[Al_Bundy]

Nu har jag fått det att fungera.

Kod: Markera allt

int readUSB(struct USB* stm32) {

	/*
	 * Reset with zeros
	 */
	memset(stm32->readBuffer, '\0', sizeof(stm32->readBuffer));

	/*
	 * Flush
	 */
	tcflush(stm32->serialPort, TCIFLUSH); // Get the latest values

	/*
	 * Collect bytes until the ACK is comming
	 */
	int receiveBytes = read(stm32->serialPort, stm32->readBuffer,
			sizeof(stm32->readBuffer));

	/*
	 * Print
	 */
	int count = 0;
	int adc = 0;
	for (int i = 0; i < receiveBytes; i++) {
		if (count == 1) {
			adc = (int) stm32->readBuffer[i] * 256;
			count++;
		} else if (count == 2) {
			adc += (int) stm32->readBuffer[i];
			count = 0;
			printf("value %d\n", adc);
			adc = 0;
		}

		/*
		 * This finds the ACK value and then we can start counting
		 */
		if (stm32->readBuffer[i] == 0x06) {
			count = 1;
		}

	}

	/*
	 * receiveBytes is the number of bytes read. receiveBytes may be 0 if no bytes were received, and can also be -1 to signal an error.
	 */
	if (receiveBytes < 0) {
		printf("Error reading: %s", strerror(errno));
	}

	return 0;
}

Kod: Markera allt

while (1) {
		/* USER CODE END WHILE */
		// rxData contains three bytes, 0 to 255 and htim1 period is 2550, wich is 1 second.
		htim1.Instance->CCR1 = rxData[0] * 10;
		htim1.Instance->CCR2 = rxData[1] * 10;
		htim1.Instance->CCR3 = rxData[2] * 10;

		// send 8 bits at the time, due to UART is 8 bit

		for (int i = 0; i < 3; i++) {

			/*
			 * adc is beteen 0 to 4095
			 */
			int adc = adcValues[0]; // We store adcValues[i] into a temporary array due to changes of adcValues

			/*
			 * Send
			 */
			uint8_t data = (uint8_t) (adc >> 8); // First data
			HAL_UART_Transmit(&huart2, &data, sizeof(data), TIME_OUT);
			data = (uint8_t) (adc & 0xFF); // Second data
			HAL_UART_Transmit(&huart2, &data, sizeof(data), TIME_OUT);
			data = 0x06; // ACK
			HAL_UART_Transmit(&huart2, &data, sizeof(data), TIME_OUT);

		}

		/* USER CODE BEGIN 3 */

	}

value 4092
value 4091
value 4091
value 4089
value 4090
value 4089
value 4090
value 4090
value 4092
value 4091
value 4090
value 4091
value 4092
value 4092
value 4091
value 4089
value 4089
value 4090
value 4089
value 4090
value 4091
value 4091
value 4089
value 4091
value 4093
value 4090
value 4089
value 4091
value 4091
value 4090
value 4090
value 4091
value 4090
value 4091
value 4092
value 4090
value 4090
value 4089
value 4090
value 4089
value 4090
value 4089
value 4092
value 4090
value 4090
value 4090
value 4089
value 4090
value 4092
value 4090
value 4090

[sodjan]

> Brukar det finnas inbyggd ACK inom STM32 eller datorvärlden?

För det första så är ACK ett definierat kontrolltecken inom ASCII.
Alltså bara ett tecken med värdet 0x06. Att sända eller ta emot
ett ACK är så vitt jag har sett aldrig inbyggt i någon hårdvara, det
är en del av det protokoll som programmen implementerar.

(Ja, det finns även en typ av paket i TCPIP som heter "ACK", men det ligger
ju lite utanför seriell kommunikation.)

> Det är väll ett ACK som man ska skicka? Något typ av stoppsignal måste det väll vara?

Ett "ACK" är ett meddelande som säger att mottagaren har mottagit/förstått meddelandet.
Och det är i princip aldrig sändaren som skickar ett ACK...

ACK är en förkortning av engelskans "acknowledged" eller bekräfta/acceptera på svenska.
Och det är i de allra flesta fall mottagaren som ska kvittera att meddelanden var
mottaget och förstått. Det finns för övrigt även ett NAK definierat vilket (om
programmen och protokollet är designade så) kan trigga en omsändning...



Om du vill använda något standardtecken som avslutning så är nog ETX mest logiskt.
Men observera! Om du gör det, så kan du inte skicka binära värden där 0x03 kan
förekomma, eftersom det värdet är just ETX. Om du bara skickar 0x00 - 0x09 så
kan ett CR fungera bättre.

Seriell överföring där alla värden 0x00 till 0xFF kan förekomma som "data" är alltid
betydligt mer komplext att hantera, eftersom det uppstår problem kring hur pakets
start och slut ska markeras. Inga enskilda tecken kan användas eftersom de kan
finnas som "data" också.

[bearing]

Nu tycker jag du är inte oförskämd. Bara för att jag inte följde just ditt råd, betyder inte att jag förkastade dig. Jag kanske följde någon annans råd. Tänk på det?

Jag tycker att det är befogat att vara oförskämd. Jag talar inte om endast de här senaste inläggen. Jag talar om majoriteten av din tråd.

Om du följde någon annans råd för att komma fram till ditt senaste försök så tycker jag fortfarande att det jag skrev är helt sant, att du inte lyssnar på bra råd.

Kod: Markera allt

      /*
       * This finds the ACK value and then we can start counting
       */
      if (stm32->readBuffer[i] == 0x06) {
         count = 1;
      }

Så om du tar emot en massa mätdata mellan 0x0600 och 0x06FF, så kommer count alltså aldrig att bli 2, så att du inte sparar den datan?

Du måste förstå att många har stått inför samma problem som du gör. Och dom har redan misslyckats på alla sätt man kan misslyckas. Tills dom hittade lösningen. Och detta har du fått gratis serverat. Men vägrar att inse fördelarna med, tydligen.

Jag tror att det beror på att du vill lösa saker själv. Du vill inte att andra ska hjälpa dig, för då känner du inte samma tillfredsställelse som när du tar fram lösningen själv. Och det är såklart helt OK. Men skriv då inte om dina projekt på nätet, och engagera hundratals, som lägger tid på att vara hjälpsamma, om du inte tänker använda hjälpen.

Gratis tips innan jag går: skicka varje värde från 0 till 4095 vid varje test, så kommer du upptäcka felen själv utan att någon på ett nätforum ev. upptäcker dem. Sen håller jag med i vad någon annan skrev. Text-baserad kommunikation är att föredra i det här fallet, och i alla fall där det hinns med. När hastigheten behöver vara högre kan man gå över till att skicka rå data.

[Shimonu]

Seriell överföring där alla värden 0x00 till 0xFF kan förekomma som "data" är alltid
betydligt mer komplext att hantera, eftersom det uppstår problem kring hur pakets
start och slut ska markeras. Inga enskilda tecken kan användas eftersom de kan
finnas som "data" också.

Nu tycker jag att du får det att låta mer komplext än det behöver vara. Jag skulle säga att man behöver start och stopp som är skilda från 0 sen behövs ett escape-tecken för att hantera fall då data i meddelandet matchar start, stopp eller escape-tecknet. Det har fungerat galant för mig iaf och jag ser inga problem med det. Skicka start först, sen data och använd escape-tecken där det behövs, avsluta med stopp.

[bearing]

Hanterar inte situationen då mottagaren sätts igång precis efter escape-tecknet när rådatan matchar start.

[sodjan]

Det är bl.a den komplexiteten som jag menar. Escape-tecken gör bl.a. att buffrar
behöver vara större, i "worst-case" är hela meddelandet "escapat". Eller så får
mottagningen vara lite mer komplex innan bufferten fylls på.

Men visst, det är ingen raketforskning direkt, men om man har problem med att
förstå binär lagring och olika sätt att representera värden i skrift, så lär det
nog bli en del problem med det också.

Mitt råd är att skicka all data som "text", det underlättar i kommunikationen och
det underlättar vid test/felsökning (simulera ena änden med med t.ex. Putty).

[Al_Bundy]

> Brukar det finnas inbyggd ACK inom STM32 eller datorvärlden?

För det första så är ACK ett definierat kontrolltecken inom ASCII.
Alltså bara ett tecken med värdet 0x06. Att sända eller ta emot
ett ACK är så vitt jag har sett aldrig inbyggt i någon hårdvara, det
är en del av det protokoll som programmen implementerar.

(Ja, det finns även en typ av paket i TCPIP som heter "ACK", men det ligger
ju lite utanför seriell kommunikation.)

> Det är väll ett ACK som man ska skicka? Något typ av stoppsignal måste det väll vara?

Ett "ACK" är ett meddelande som säger att mottagaren har mottagit/förstått meddelandet.
Och det är i princip aldrig sändaren som skickar ett ACK...

ACK är en förkortning av engelskans "acknowledged" eller bekräfta/acceptera på svenska.
Och det är i de allra flesta fall mottagaren som ska kvittera att meddelanden var
mottaget och förstått. Det finns för övrigt även ett NAK definierat vilket (om
programmen och protokollet är designade så) kan trigga en omsändning...



Om du vill använda något standardtecken som avslutning så är nog ETX mest logiskt.
Men observera! Om du gör det, så kan du inte skicka binära värden där 0x03 kan
förekomma, eftersom det värdet är just ETX. Om du bara skickar 0x00 - 0x09 så
kan ett CR fungera bättre.

Seriell överföring där alla värden 0x00 till 0xFF kan förekomma som "data" är alltid
betydligt mer komplext att hantera, eftersom det uppstår problem kring hur pakets
start och slut ska markeras. Inga enskilda tecken kan användas eftersom de kan
finnas som "data" också.

Problemet att när jag skickade en sträng från början så hade jag ingen kontroll över hur mycket jag skickade.

Hur fungerar ett CR? Jag kanske kommer skicka 0x03. Det vet man aldrig.

Nu tycker jag du är inte oförskämd. Bara för att jag inte följde just ditt råd, betyder inte att jag förkastade dig. Jag kanske följde någon annans råd. Tänk på det?

Jag tycker att det är befogat att vara oförskämd. Jag talar inte om endast de här senaste inläggen. Jag talar om majoriteten av din tråd.

Om du följde någon annans råd för att komma fram till ditt senaste försök så tycker jag fortfarande att det jag skrev är helt sant, att du inte lyssnar på bra råd.

Tyvärr, jag ger dig inte rätt på denna punkt. Jag har lyssnat på er alla och tagit del av kunskapen samt tillämpat olika metoder som ni har förslagit för mig.
Vissa har fungerat, vissa inte. Sodjan var den som föreslog att skicka text, jag gjorde det, men jag kunde inte få någon kontroll över hur mycket jag skickade. Sedan var det du eller någon annan som föreslog att dela upp bitarna, det gjorde jag och det fungerade.

Kod: Markera allt

      /*
       * This finds the ACK value and then we can start counting
       */
      if (stm32->readBuffer[i] == 0x06) {
         count = 1;
      }

Så om du tar emot en massa mätdata mellan 0x0600 och 0x06FF, så kommer count alltså aldrig att bli 2, så att du inte sparar den datan?

Detta är jag medveten om. Jag vet dock inte hur jag ska lösa detta. När jag skickade talet 4095 så skickade jag först det lilla bitvärdet t.ex. 15 och sedan stora bitvärdet 251. Det kunde se ut så här:

15
251
15
251
15
251
15
251
15
251
15
251
15

Men helt plötsligt blev det så här

15
251
15
251
15
15 // <--- här. Dubbla
251
15
251
15
251
15
251

Du måste förstå att många har stått inför samma problem som du gör. Och dom har redan misslyckats på alla sätt man kan misslyckas. Tills dom hittade lösningen. Och detta har du fått gratis serverat. Men vägrar att inse fördelarna med, tydligen.

Jag tror att det beror på att du vill lösa saker själv. Du vill inte att andra ska hjälpa dig, för då känner du inte samma tillfredsställelse som när du tar fram lösningen själv. Och det är såklart helt OK. Men skriv då inte om dina projekt på nätet, och engagera hundratals, som lägger tid på att vara hjälpsamma, om du inte tänker använda hjälpen.

Gratis tips innan jag går: skicka varje värde från 0 till 4095 vid varje test, så kommer du upptäcka felen själv utan att någon på ett nätforum ev. upptäcker dem. Sen håller jag med i vad någon annan skrev. Text-baserad kommunikation är att föredra i det här fallet, och i alla fall där det hinns med. När hastigheten behöver vara högre kan man gå över till att skicka rå data.

Men jag testar alla lösningar som ni ger mig. Självklart vill jag lösa problemen, men jag gör ju det av alla råd och förslag som ni ger mig.

Jag kunde inte ha textbaserad kommunikation. Jag har både hört från min lärare att det är dumt att skicka text och har insett detta också.

[guckrum]

Text är i princip alltid att föredra, bland annat av skäl som angetts tidigare i tråden.

[sodjan]

> Hur fungerar ett CR?

Humor!

> Sodjan var den som föreslog att skicka text, jag gjorde det, men jag kunde inte få någon kontroll över hur mycket jag skickade.

Väldigt märkligt! Det är ju det absolut enklaste att fixa.

> Sedan var det du eller någon annan som föreslog att dela upp bitarna, det gjorde jag och det fungerade.

Och av det drar du slutsatsen att det första "inte fungerar" generellt? Medan det faktum att du hade
lite tur med det andra gör att det "fungerar". Dessutom är att "dela upp bitarna" något helt annat än
frågan om hur man kodar och skickar data. Du är fullständigt lost här...

> Jag kunde inte ha textbaserad kommunikation.

Självklart kan du det! Det är den absolut enklaste lösningen av alla. Inte helt optimal
då det gäller volym men det har knappast någon betydelse i detta fall. Problemet är att
du inte fattar en hel del väldigt grundläggande sakar (se tidigare inlägg).

> Jag har både hört från min lärare att det är dumt att skicka text...

Vilken komplett idiot...

> ...och har insett detta också.

Men han är i alla fall inte ensam. Skönt för honom.