Matrisberäkningar med för STM32?

[bearing]

Jag hade en kollega som var övertygad om att högskolorna måste sluta lära ut matlab/simulink som det primära verktyget. För då lär man sig inte programmering, så han. Jag börjar förstå nu vad han menade...

Al, det du vill göra löser man vanligtvis med metoden maskning/shiftning. Mycket enklare och effektivare.

[Al_Bundy]

Kan du visa ett exempel?

Orsaken varför Simulink och MATLAB finns har med brist på tid att göra.

[bearing]

Se icecaps inlägg. Hans metod med 7 bitar data per byte, samt att flagga sista byten med åttonde biten hög är en robust metod som jag använt själv. Då är det väldigt enkelt att dela upp inkommande data i "paket". Annars kommer du inte kunna avgöra hur inkommande data hör ihop, precis som när du körde textkommunikation här innan.

Matlab är ju ett matteverktyg. Väldigt bra på det. Men ger inte någon bra grund för att förstå datorer och programmering.

[AndLi]

Hur menar du?

Vi säger att jag har talet 510. Då kan jag dela upp det i 255 och 255. Dvs jag skickar 8 bitar två gånger. Eventuellt om jag har 610 så skickar jag 255, 255, 100. Men det känns som det blir många iterationer om man har ett värde på 4095.

Ska du skicka 510 skickar du en byte med 0x1 i och en med 0xfe i... och hex är ju bara ett sätt att presentera ett värde.. alltså skickas ju 0xFE och 254 på samma sätt... blanda nu inte ihop det med att skicka strängar...

[Al_Bundy]

Se icecaps inlägg. Hans metod med 7 bitar data per byte, samt att flagga sista byten med åttonde biten hög är en robust metod som jag använt själv. Då är det väldigt enkelt att dela upp inkommande data i "paket". Annars kommer du inte kunna avgöra hur inkommande data hör ihop, precis som när du körde textkommunikation här innan.

Matlab är ju ett matteverktyg. Väldigt bra på det. Men ger inte någon bra grund för att förstå datorer och programmering.

Det var ett väldigt rörigt inlägg och jag kunde inte associera något till mitt problem. Men jag antar att man man skickar t.ex numret 4043. Måste man inte då dela upp det i antal nummer som man skickar hela tiden? Typ som jag har gjort.

[Al_Bundy]

Hur menar du?

Vi säger att jag har talet 510. Då kan jag dela upp det i 255 och 255. Dvs jag skickar 8 bitar två gånger. Eventuellt om jag har 610 så skickar jag 255, 255, 100. Men det känns som det blir många iterationer om man har ett värde på 4095.

Ska du skicka 510 skickar du en byte med 0x1 i och en med 0xfe i... och hex är ju bara ett sätt att presentera ett värde.. alltså skickas ju 0xFE och 254 på samma sätt... blanda nu inte ihop det med att skicka strängar...

Så 0x01 är alltså en markering för start och 0xFE är en markering för slut? När jag kollar ASCII tabellen så är 0xFE = 254 och därmed ■

Du kanske menar att man skickar numret 2 och sedan sin 8-bit data och sedan numret 3 ?

Exempel: Jag har dessa nummer som jag ska skicka 503

För 503 så kommer jag skicka: 0x02 0x35 0x30 0x33 och sedan 0x03

Alltså jag delar om 503 till '5','0','3'

[bearing]

Du vet helt enkelt inte hur tal sparas i processorn, eller vad maskning och shiftning är. Om du hade vetat det hade du inte tyckt att hans inlägg var rörigt.

Vi kan ju för att förenkla börja med att räkna med basen 10.
Talet du vill skicka är 3456, och du kan bara skicka två siffror i taget. Då skickar du 34 samt 56. Om talet är 789 skickar du 07 och 89. Om talet är 45 skickar du 00 och 45.

Samma system gäller med basen 16. 5A8F ska skickas, då skickar du 5A samt 8F. Om talet är 3B5 skickar du 03 och B5. Och så vidare.

För att få 8F ur 5A8F kan man maska:
5A8F & 00FF = 8F
För att få 5A ur 5A8F kan man skifta
5A8F >> 8 = 5A

Låt säga att du skickar två samples som hör ihop, t.ex samplingar av in och utgång:
6A9 och 70C

I mottagande ände får du en ström av bytes, inklusive dessa fyra bytes:
.. 06 A9 07 0C ..
Hur ska du kunna avgöra att just dessa fyra hör ihop?

Det skulle man kunna göra genom att markera den första av dessa fyra på ett speciellt sätt, låt säga med en prick:
•06 A9 07 0C
Då blir det enkelt i mottagande sida. Bara att vänta på en byte markerad med en prick. Sen kombinerar man den prick-markerade med nästkommande byte och vet att detta är ingång:
•06A9, eller utan pricken 6A9
Och de två följande är utgång:
70C

I en dator kan man ju dock inte markera data med en prick. Allt som finns är bitar. Så man får "offra" en bit från varje byte för att kunna markera en skickad byte som första i en grupp samples.

Och det är därför icecap maskar med 007F ist för 00FF, samt skiftar 7 bitar ist för 8. För att hela tiden ha en bit ledig för "pricken"

[Al_Bundy]

Nu har jag hittat en enkel lösning, som är dessutom pedagogisk. Visst fungerar eran metod också, men jag tycker det är enklare att dela upp 4021 till "4,0,2,1" och sedan skicka. Det är alltså inte strängar jag talar om.
Denna metod nedan läser bara 4 bytes, dvs tal mellan 1000 till 4095. Så jag måste komma på ett sätt där jag endast behöver läsa t.ex. 1 byte eller 2 byte. Återkommer om det. Funderar på att lägga dit ett ACK på slutet av det jag skickar.

Min C-kod för att läsa.

Kod: Markera allt

while (1) {

		/*
		 * Reset with zeros
		 */
		char collected[4];
		memset(collected, '\0', sizeof(collected));
		memset(stm32->readBuffer, '\0', sizeof(stm32->readBuffer));

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

		/*
		 * Collect total 4 bytes before proceed
		 */
		int receiveBytes = 0;
		while (receiveBytes < 4) {
			int bytes = read(stm32->serialPort, collected, sizeof(collected));

			for (int i = receiveBytes; i < receiveBytes + bytes; i++)
				stm32->readBuffer[i] = collected[i-receiveBytes]; // We start at 0 for collected array, but not for readBuffer

			/*
			 * Increase the counting
			 */
			receiveBytes += bytes;

			/*
			 * 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));
			}
		}

		/*
		 * Print it out
		 */
		printf("Read %i bytes. Received message: ", receiveBytes);
		for (int i = 0; i < receiveBytes; i++) {
			printf("%d", (int) stm32->readBuffer[i]);
		}
		printf("\n");

	}

Min C-kod för att skicka. Dock inställd på att bara skicka från en analog ingång.

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++) {
			int adc = adcValues[0];
			int length = (int) floor(log10(adc)) + 1; // Get the length of the integer
			uint8_t sendArray[length];

			/*
			 * Fill
			 */
			int i = length - 1;
			while (adc > 0) {
				int digit = adc % 10;
				adc /= 10;
				sendArray[i] = (uint8_t) digit;
				i--;
			}

			HAL_UART_Transmit(&huart2, sendArray, sizeof(sendArray), 10);
			HAL_Delay(10);
		}

Resultat när jag kopplar 3.3 volt till analog in 0.

Kod: Markera allt

Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4089
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4089
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4089
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4095
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4095
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4089
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4095
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4086
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4086
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4085
Read 4 bytes. Received message: 4095
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4089
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4089
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4089
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4089
Read 4 bytes. Received message: 4089
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4094
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4093
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4094
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4089
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4095
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4084
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4086
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4095
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4091
Read 4 bytes. Received message: 4090
Read 4 bytes. Received message: 4092
Read 4 bytes. Received message: 4091

[AndLi]

Hur menar du?

Vi säger att jag har talet 510. Då kan jag dela upp det i 255 och 255. Dvs jag skickar 8 bitar två gånger. Eventuellt om jag har 610 så skickar jag 255, 255, 100. Men det känns som det blir många iterationer om man har ett värde på 4095.

Ska du skicka 510 skickar du en byte med 0x1 i och en med 0xfe i... och hex är ju bara ett sätt att presentera ett värde.. alltså skickas ju 0xFE och 254 på samma sätt... blanda nu inte ihop det med att skicka strängar...

Så 0x01 är alltså en markering för start och 0xFE är en markering för slut? När jag kollar ASCII tabellen så är 0xFE = 254 och därmed ■

Du kanske menar att man skickar numret 2 och sedan sin 8-bit data och sedan numret 3 ?

Exempel: Jag har dessa nummer som jag ska skicka 503

För 503 så kommer jag skicka: 0x02 0x35 0x30 0x33 och sedan 0x03

Alltså jag delar om 503 till '5','0','3'

Nej 0x01 är värdet i MSB byten och 0xFE är värdet i LSB byten.
Det är hela värdet. Det finns ALDRIG något behov av att överföra fler bytes än 2 för att få över ett 12 bitars värde.
Glöm ASCII det har inget med effektiv överföring att göra...

Det har tagit ovanligt lång tid innan du hävdat att det är c som språks fel.....

[svanted]

Kan du visa ett exempel?

Orsaken varför Simulink och MATLAB finns har med brist på tid att göra.

dina okunskaper vad gäller binära tal är ett bra exempel, om du lärt dig assembler/maskinkod och C ordentligt hade du förstått att
talet 503 behöver minst 9 bitar: 1 1111 0111
och:
3984 = 1111 1001 0000, alltså minst 12 bitar.

och om du har talet 3984 i ditt program så ÄR det redan = 0000 1111 1001 000,
om du har 16 bitars int.
och att tilldela ett 8 bitars int MSB eller LSB i protokollet gör man genom maskning och högershift/division.

den tid du och kanske flera påstås spara under utbildning genom att hoppa över de mest basala delar man MÅSTE ha för att programmera
förlorar man flera gånger om då man behöver tjafsa om dem i långa trådar på forum för att be om hjälp.
och att skriva mjukvara för mikrokontrollers att passa simulink/matlab bara för att man inte kan det mesta basala är verkligen att gå över ån efter vatten.

min åsikt är att ASCII i protokoll via en socket är bra att använda då man kan simulera sändare och mottagare med vanlig telnet för felsökning och utveckling, detta när det gäller att överföra enkla mätdata, typ några kb/s, har omvandlingstider ingen som helst betydelse.

[bearing]

Al, är det garanterat att det funkar?

Kan aldrig sändare och mottagare hamna i otakt? Du läser ju bara blint 4 bytes på raken. Hur vet du att den aldrig tar t.ex sista siffran från en sample, och sedan de tre följande från nästa sample?

Metoden med att markera med en "prick" fungerar alltså även för ASCII, om du inte använder den utökade teckenuppsättningen, utan bara använder vanliga siffror, bokstäver, punkt, komma, osv.

Sen att du använder floor och log istället för enkla operationer som normalt tar ett par cykler är ju egentligen så roligt att man vill kasta sig på golvet och skratta.

Visst fungerar eran metod också, men jag tycker det är enklare att dela upp 4021 till "4,0,2,1" och sedan skicka. Det är alltså inte strängar jag talar om.

Hehe.. en sträng är ju just det. En printf ger ju samma resultat som din kod.

[sodjan]

Ja jösses så rörigt det blir då man inte kan hålla isär fysisk lagring av
värden (hur de lagras binärt) med olika sätt att representera det i text.
I höstas la jag ner tid på ett antal mail för att för våra indiska konsulter (HCL)
förklara skillnaden mellan t.ex. 0x2B och "2B". Jag var lika förvånad då...

> att dela upp 4021 till "4,0,2,1"

Men det är väl inte det du gör. Du omvandlar värdet 0xFB5 (ett 16 bitars värde)
till de fyra värdena 0x04, 0x00, 0x02 och 0x01 (4 st. 8 bitars värden).
Inte till strängen "4,0,2,1".

Eftersom du ändå skickar binära värden (som kommer att matcha de 10 lägsta
"kontroll" tecknen i ASCII, vilket i sig kan ha oväntade konsekvenser beroende
på hur de miljöer man använder hanterar STX, ETX, BEL, NUL o.s.v...), så kan du
lika gärna skicka 0x0F och 0xB5 och spara halva överföringen...

Om det vore jag så skulle jag fixa en sträng "4021" samt skicka den med något
lämpligt start och stopptecken. Eller i alla fall ett stopptecken, t.ex. <CR>. Det
behövs inget starttecken eftersom den synkar på stopptecknet i alla fall. C har
färdiga rutiner för konvertering mellan binära integers och strängar.

[Krille Krokodil]

Jag hade en kollega som var övertygad om att högskolorna måste sluta lära ut matlab/simulink som det primära verktyget. För då lär man sig inte programmering, så han. Jag börjar förstå nu vad han menade...

Både och ska man väl hinna med. På LTH hade vi labbar på AVR, PIC, FPGA, PLC och Matlab/Simulink. En labb handlade just om att implementera PID med precision på 20 bitar eller så i C på en 8 bitars PIC.

[Al_Bundy]

Al, är det garanterat att det funkar?

Kan aldrig sändare och mottagare hamna i otakt? Du läser ju bara blint 4 bytes på raken. Hur vet du att den aldrig tar t.ex sista siffran från en sample, och sedan de tre följande från nästa sample?

Metoden med att markera med en "prick" fungerar alltså även för ASCII, om du inte använder den utökade teckenuppsättningen, utan bara använder vanliga siffror, bokstäver, punkt, komma, osv.

Sen att du använder floor och log istället för enkla operationer som normalt tar ett par cykler är ju egentligen så roligt att man vill kasta sig på golvet och skratta.

Visst fungerar eran metod också, men jag tycker det är enklare att dela upp 4021 till "4,0,2,1" och sedan skicka. Det är alltså inte strängar jag talar om.

Hehe.. en sträng är ju just det. En printf ger ju samma resultat som din kod.

Den fungerar för tal som har 4 i längd. Men jag lade till en ACK så att nu kan jag läsa alla tal.

Kan du visa ett exempel?

Orsaken varför Simulink och MATLAB finns har med brist på tid att göra.

dina okunskaper vad gäller binära tal är ett bra exempel, om du lärt dig assembler/maskinkod och C ordentligt hade du förstått att
talet 503 behöver minst 9 bitar: 1 1111 0111
och:
3984 = 1111 1001 0000, alltså minst 12 bitar.

och om du har talet 3984 i ditt program så ÄR det redan = 0000 1111 1001 000,
om du har 16 bitars int.
och att tilldela ett 8 bitars int MSB eller LSB i protokollet gör man genom maskning och högershift/division.

den tid du och kanske flera påstås spara under utbildning genom att hoppa över de mest basala delar man MÅSTE ha för att programmera
förlorar man flera gånger om då man behöver tjafsa om dem i långa trådar på forum för att be om hjälp.
och att skriva mjukvara för mikrokontrollers att passa simulink/matlab bara för att man inte kan det mesta basala är verkligen att gå över ån efter vatten.

min åsikt är att ASCII i protokoll via en socket är bra att använda då man kan simulera sändare och mottagare med vanlig telnet för felsökning och utveckling, detta när det gäller att överföra enkla mätdata, typ några kb/s, har omvandlingstider ingen som helst betydelse.

Du har övertygat mig. Jag får nog helt enkelt lära mig bitwise operationer. Så låt mig demonstrera om jag får visa att jag förstår vad du menar.

Steg 1:
Om jag har talet 4021, vilket är binärt 111110110101 och Hex 0xFB5

Steg 2:
Min UART är på 8 bit, Alltså kan jag bara skicka 111110110101 >> 8 vilket blir 000000001111 som jag skickar först. Detta motsvarar 0xF i hex och 1111 i binärt då de första nollorna utesluts.

Steg 3:
Så nu när jag har skickat 1111 så är det 10110101 kvar att skicka. Det jag gör då är att jag tar 000000001111 << 8 så det blir 111100000000.
Där efter tar jag 111110110101 & ~111100000000 vilket blir 000010110101 då ~111100000000 = 000011111111

Steg 4:
Nu kan jag skicka 10110101

Så en liten sammanfattning. Så länge jag har ett ADC tal som är större än 255 och under 65536 så måste jag utföra detta:

Kod: Markera allt

int ADC = 3025;
u_int8_t data = (u_int8_t) (ADC >> 8);
printf("Sending first data %i\n", data);
data = (u_int8_t) (ADC & ~(data << 8 ));
printf("Sending last data %i\n", data);

[Rick81]

Nästan:

uint8_t data = (uint8_t) (ADC >> 8 ); // Skicka de första bitarna
skicka_funktion(data);
data = (uint8_t) (ADC & 0xFF); // Skicka resterande bitarna.
skicka_funktion(data);