Hur skicka strängar via ASCII?

[Al_Bundy]

Personligen tycker jag att man ska använda allt som C erbjuder. Jag använder bland annat goto minst en gång per program. Exempelvis "Är du nöjd med dessa värden? Tryck * = tillbaka på ruta 0 eller # = OK", istället för att ha en megastor while-loop eller massvis med små irriterande funktioner när man vill bara ha enkelt flöde av frågor.

[Nerre]

Men en double är inte en sträng!

Har du ett värde i en double som du ska skriva ut måste du går två steg:

1. Gör om din double till en sträng
2. Skriv ut strängen

[svanted]

Jag kan skicka talet 70 direkt, men talet 500 kan jag inte skicka. Jag tror att det begränsar sig max till 256 tecken i från av tal från 0 till 256.

Nu gäller det bara för mig att lista ut hur att skicka flyttal via Simulink.
Problemet är att om konverterar om double 89.04 till uint8 så blir det 89 då int kan bara ha heltal.

googla på
"float2Bytes"

så:
gör om din float till bytes...(float2Bytes)
skicka dem som typ 4 st ui8
sedan bytes2float, om du nu vill ha tillbaka din float

[bit96]

Tycker inte om break;

Hmm, okej...

Du citerade mitt inlägg om att använda 'break' i en 'for-loop', men jag förstår inte riktigt vad du vill säga.
Innan jag eventuellt svarar med min 10-i-topplista på nyckelord i C kanske du kan motivera vad som inte är bra med 'break'.
Kanske har du lärorik information som trådskaparen och vi andra kan få ta del av.

[MiaM]

Jag kan skicka talet 70 direkt, men talet 500 kan jag inte skicka. Jag tror att det begränsar sig max till 256 tecken i från av tal från 0 till 256.

Om det du skickar ska kunna tas emot som läsbar text med t.ex. terminalprogram så kan du inte skicka "talet" 70 direkt. Du kan däremot skicka ascii-koden 70 direkt och se bokstaven F i terminalprogrammet.

[Al_Bundy]

Jag kan skicka talet 70 direkt, men talet 500 kan jag inte skicka. Jag tror att det begränsar sig max till 256 tecken i från av tal från 0 till 256.

Nu gäller det bara för mig att lista ut hur att skicka flyttal via Simulink.
Problemet är att om konverterar om double 89.04 till uint8 så blir det 89 då int kan bara ha heltal.

googla på
"float2Bytes"

så:
gör om din float till bytes...(float2Bytes)
skicka dem som typ 4 st ui8
sedan bytes2float, om du nu vill ha tillbaka din float

Det går inte göra så i Simulink.

Om jag har en double som är på 65.3 och gör jag om den till uint8 så blir det bara 65.

[Al_Bundy]

Jag kan skicka talet 70 direkt, men talet 500 kan jag inte skicka. Jag tror att det begränsar sig max till 256 tecken i från av tal från 0 till 256.

Om det du skickar ska kunna tas emot som läsbar text med t.ex. terminalprogram så kan du inte skicka "talet" 70 direkt. Du kan däremot skicka ascii-koden 70 direkt och se bokstaven F i terminalprogrammet.

Hängde inte med.
Jag skickar 65 och när jag tar Serial.println(mySerial.read()); så får jag fram vad mySerial.read() är för något.
Tänk att jag har två stycken arduinos. Ena är programmerad med Simulink där jag skickar talet 65 ut ur TX/RX gångarna och sedan till en annan Arduino som är programmerad med C.

Den arduino som är programmerad med C tar emot och skickar vidare till min dator.

Om jag har talet 65.66 så måste jag dela upp 65 och 66 i två delar. 66 delar jag med 100 och sedan addera med 65.

[sodjan]

> Om jag har en double som är på 65.3 och gör jag om den till uint8 så blir det bara 65.

En int har självklart inga decimaler! Du får skala värdet så att det passar i en int.

65.3 * 10 = 653

Om nu uint8 betyder en 8 bitars integer, så får du hantera det...

[Al_Bundy]

Problemet är att en uint8 inte kan hantera mer än 256
Jag får nog dela upp 65.64 till 65 och 64 och addera 65 + 64/100.

[sodjan]

Självklart. Man får göra vad som krävs, helt enkelt.
Den exakta lösningen är omöjlig att säga utan att sitta
själv med prylarna framför sig.

[danei]

Nej. Uint8 kan inte anta värdet 256.

[Nerre]

Om jag har en double som är på 65.3 och gör jag om den till uint8 så blir det bara 65.

Alltså, du verkar ju totalt sakna grepp om hur olika datatyper lagras...

Om vi har fyra bytes (32 bitar) som lyder:
01000010 10000010 10011001 10011010

Då kan de tolkas som:
1. 16-bitars flyttalet 6.53000030517578125E1 (d.v.s 65.3)
2. De två 16-bitars heltalen 8513 och 19661 (med little endian, orkar inte räkna vad det blir med big endian)
3. De fyra 8-bitars unsigned heltalen 66, 130, 153 och 154
4. Strängen "B‚™š" (enligt ISO 58859-1, fast egentligen ska det vara ett NULL på slutet för att kunna vara en sträng)
och några varianter till (jag har skippat signed heltal t.ex.)

Och man behöver väl inte SE att decimalerna försvinner när man konverterar något till ett heltal? Definitionen av heltal är ju just hela tal utan decimaler. Det är ju självklart att inte decimalerna hänger med!

[Al_Bundy]

Alltså, du verkar ju totalt sakna grepp om hur olika datatyper lagras...

Jag brukar inte bry mig så mycket vad som egentligen händer. När jag ser att decimaltalet försvinner när float -> int så accepterar jag att den bara hugger bort "svansen".

Nej. Uint8 kan inte anta värdet 256.

Så vilka värden kan Uint8 anta då? 0 till 255?

[Mr Andersson]

> Jag brukar inte bry mig så mycket vad som egentligen händer.
Och det är väl där problemet ligger. Men google brukar kunna hjälpa till ganska ofta.
http://se.mathworks.com/help/matlab/mat ... meric.html
http://se.mathworks.com/help/matlab/mat ... tring.html

> Så vilka värden kan Uint8 anta då? 0 till 255?
Testa ta fram miniräknaren. 2^7 + 2^6 + 2^5 + 2^4 + 2^3 + 2^2 + 2^1 + 2^0

[Al_Bundy]

Om jag har en double som är på 65.3 och gör jag om den till uint8 så blir det bara 65.

Alltså, du verkar ju totalt sakna grepp om hur olika datatyper lagras...

Om vi har fyra bytes (32 bitar) som lyder:
01000010 10000010 10011001 10011010

Då kan de tolkas som:
1. 16-bitars flyttalet 6.53000030517578125E1 (d.v.s 65.3)
2. De två 16-bitars heltalen 8513 och 19661 (med little endian, orkar inte räkna vad det blir med big endian)
3. De fyra 8-bitars unsigned heltalen 66, 130, 153 och 154
4. Strängen "B‚™š" (enligt ISO 58859-1, fast egentligen ska det vara ett NULL på slutet för att kunna vara en sträng)
och några varianter till (jag har skippat signed heltal t.ex.)

Och man behöver väl inte SE att decimalerna försvinner när man konverterar något till ett heltal? Definitionen av heltal är ju just hela tal utan decimaler. Det är ju självklart att inte decimalerna hänger med!

Som jag sa!

> Jag brukar inte bry mig så mycket vad som egentligen händer.
Och det är väl där problemet ligger. Men google brukar kunna hjälpa till ganska ofta.
http://se.mathworks.com/help/matlab/mat ... meric.html
http://se.mathworks.com/help/matlab/mat ... tring.html

> Så vilka värden kan Uint8 anta då? 0 till 255?
Testa ta fram miniräknaren. 2^7 + 2^6 + 2^5 + 2^4 + 2^3 + 2^2 + 2^1 + 2^0

Ja. 255. Skulle jag skicka 256 så blir det 0 igen.
Med andra ord så har uint8 8 stycken 0:or eller 8 stycken 1:or, där en bit är antingen sant eller falskt.