MiaM: Det är väl det som är problemet. Om man inte lyckas tolka data med mottagarens program har man antagligen lika svårt att tolka data med ett separat "medhörningsprogram". Bättre att skicka ASCII då, eftersom det kan "avlyssnas" med vilket terminalprogram som helst.
Om jag hade haft ett float som skulle skickas hade jag helt enkelt gjort:
float value = 123.45;
WriteLine(value);
Vad som händer är att WriteLine(...) omvandlar värdet i variabeln till en textsträng och avslutar med ny rad och vagnretur.
Det betyder att det kommer att skickas 8 bytes: '1' '2' '3' '.' '4' '5' CR LF (ascii) eller som hex 31 32 33 2E 34 35 0D 0A.
Att ta emot tecken är alltid lite knepigare än att skicka. Man måste veta att man är synkad, alltså, när kommer första tecknet som ska läsas in?
Lämpligtvis tar man emot (acsii)-tecknen ett och ett och lägger i en buffer tills man får in CR ( = ny rad).
Fel som kan uppstå är att för många tecken kommer in utan att man får in CR = bufferten blir överfull och programmet kraschar eller nåt annat händer beroende på hur man lägger till data i bufferten.
I en del I/O-bibliotek finns färdiga sådana inläsningsfunktioner, även om de ofta saknar felhantering mm.... (Jag föredrar att skriva min inläsningshantering själv)
För att filtrera bort konstiga tecken som man inte vill ha med i talet kan man ta bort allt som är mindre än 0x20 och allt som är större än 0x7F.
Sedan försöker man omvandla strängen man fått in "123.45" till ett float med lämplig funktion. För att det inte ska bli error om indata är felaktigt kanske det undantaget måste hanteras.
