Svenska ElektronikForumet

Det var rätt svårt att skicka över data från uC till min dator. I min IDE så kan jag se att ADC-värden placeras in som en char sträng.

Det har jag gjort via denna kod i min while(1) loop. Datatyperna på följande är: Jag kunde inte ha volatile på char, men det tycks fungera ändå.

Ändå får jag konstiga tecken på min terminal, vilket jag beslutar att ta CuteCom terminalen, vilket visar fina värden. Jag har kopplat en potentiometer till min ADC och därmed kan jag styra värderna.
Det är bara 4.59 och dessa decimaltal jag kan skriva ut. Det verkar som att jag skriver endast ut hex? Detta är något jag inte har förväntat mig. Men finns det något sätt som kan göra så man får hem datan?

olof_n skrev:Hej!

Skicka ditt heltal som Micke_s rekommenderar.
Rätt onödigt att skicka tal som text.

Kod: Markera allt

uint16_t adcval = .......; (Lägg ditt 12 bitars värde i en 16 bitars integer)

uint8_t lowbyte = adcval & 0xff;
uint8_t highbyte = (adcval >> 8);

Skicka över lowbyte och  highbyte.

Slå ihop igen med:
uint16_t value = (highByte << 8) | lowByte ;

Jag brukar lägga till en extra byte med checksumma (och eventuellt något "starttecken") så att jag kan kontroller att allt överfördes som det ska.

/Olof

Hej Olof!

Jag ska testa ditt exempel!

Hej Al!

Eftersom du är intresserad ska du få ett tips över hur du använder en checksumma.
Jag råkade ut för ett problem när jag skulle skicka data via I2C till en Raspberry PI hemma (UART ingången var upptagen).
Kabeln som jag kommuncerade över var 2 meter lång så jag fick väldigt många felaktiga värden. Lösningen var att lägga till en enkel checksumma på det som skickades.

Säg att du har tre bytes som ska skickas.

I ditt fall skulle det kunna vara DataToSend[0] = startbyte, DataToSend[1] = lowbyte, DataToSend[2] = highbyte.
1. unsigned char DataToSend[3];

Räkna ut checksumma med bifogad funktion. Funktionen är en standardfunktion som jag stulit.
2. uint8_t CRC = CRC8(DataToSend, sizeof(DataToSend));

3. Skicka DataToSend + CRC

Ta emot datat. Räkna ut ny checksumma med samma funktion.
Byte 1-3 ska ligga i "RecivedData".
Checksumman (byte 4) ska ligga i CRC.
Jämför!
4. if (CRC == CRC8(RecivedData,sizeof(RecivedData)))

Det ska jag göra. Men först måste jag få rena värden. Det verkar som att min UART inte spottar ut det jag vill att den ska spotta ut.

Edit: Vet ni vad? Jag ska sluta använda DMA för UART. Det känns som det är svårt att hålla koll på just när saker och ting anropas. Helt plötsligt så skrivs halva meddelandet ut, bara för att något annat ska vara före. För ADC fungerar det fint.

Jag håller med sodjan här. Att skicka text är inte lika effektivt som binär data. (Men om man inte behöver skicka flera Mbps spelar det någon roll?) Däremot underlättar det extremt mycket vid felsökning om man kan använda valfritt terminalprogram istället för något specialskrivet program för att tolka binärdatan.

Så där ja! Då var IO-modulen klar. Tre stycken PWM på 1 sekunds intervall där 255 är 100% full PWM och 0 är 0% PWM. Tre stycken 12-bit ADC som anropas via DMA och en UART så gör ett interrrupt när den får tre stycken bits med en upplösning på 8 bit. Så om jag sänder ÿÿÿ så betyder det 100% på alla dessa tre PWM-utgångarna. Eller om jag sänder nullnullnull, hur man nu ska uttrycka detta med mitt tangetbord, då blir det 0% på alla dessa tre PWM-utgångarna.

Sedan skickar UART:en adcvärderna. Det jag tänkte fråga er är varför denna 12-bits ADC har lite fladdrande värden? Jag har anslutit 3.3 volt direkt in i ingången och referensen är ju 3.3 volt. Jag borde få 4095 på alla dessa tre?

Övrigt så måste jag säga att jag är helt klart imponerad av STM att utveckla ett sådant verktyg så vanligt folk kan programmera lite grundläggande och enkla saker. Jag är bara behov av lite I/O för USB för mina reglertekniksprojekt. Jag ska ju inte bygga Philips nya LED skärm eller Mercedec Benz CDI-boxar.

Räkna ut 3.3V/4096 så inser du nog fladdret.

Jo. Men sådant sker inte på en MCP3008 eller när jag körde Arduino. Gav jag full spänning in i ADC:n så gjorde den fullt utslag. Men det kanske detta som är priset för denna ARM 32-bit flashiga produkt jag har betalat för? 150 kr för ett sådant litet kort är ett riktigt bra pris.

https://www.st.com/content/ccc/resource ... 211314.pdf

Läste nu att för att undvika fladder så kan man antingen sätta en 1 uF kondensator mellan analog in och jord, eller öka samplingen. Jag tror jag sätter en keramikkondensator

Kul att det fungerar!

Mr Andersson och Sodian:
Angående att vara bekväm och skicka allt som text.
Har lite svårt för det argumentet, har man ett projekt vill man väl göra det bra och inte på enklaste sätt?
Att kunna köra debug i textläge känns inte som ett måste. Många terminalprogramvaror kan visa inkommna byte i hex, decimal eller binärt så det brukar gå bra att tolka vad man skickar.
Mentaliteten att slösa minne och CPU-cykler är tråkig. Blir värre och värre för varje år.

Att skicka ett värde tex 1335607,1312341 (float) som text tar upp 15 tecken och 4 binärt. Skicka i flera Mbps? Är väl knappast alltid fallet, kan lika gärna vara 9600bps eller lägre.
Rätt som det är vill samma program skicka via något långsamt radio protokoll tex LORA som har väldigt låg hastighet.
Kolla hur merparten av alla temperatur sensorer m.m. skickar data, inte är det som text.

Ta det lite lungt nu olof_n, det är ju inte som att din checksumma är gratis att räkna vare sig i cpu-cykler eller minne...
Men av erfarenhet så kan jag säga att någon form av felkontroll på data är ju inte negativ

Min erfarenhet säger oxå att så länge man har kontroll på signalvägen så fungerar det med binära data.
Men sen kanske man kommer på att man ska stoppa in något kul på vägen, som i mitt fall en nätverksserieport, och då har man inga garantier för att binära data kommer igenom när det sammanfaller med kontrolltecken.

Det är lugnt, har inga problem med olika åsikter.
Ville bara svara eftersom ett flertal förespråkade att skicka data som text med mindre bra argument.

Problemet med felaktig data blir inte mindre av att skicka text utan snarare större (fler tecken = större chans till fel). Någon kontroll har du väl även när du skickar text eller litar du alltid på att allt kommer fram korrekt?
Jag har också skickat data som text men ser inte det som enklare, man ska ju använda det man skickar så att konvertera tal -> text -> tal blir ju lite kod det med.

Har aldrig använt en nätverksserieport men om den inte klarar av att vidarbefodra kontrolltecken verkar det illa, kanske handlar det om konfiguration? I linux har jag för mig att jag fick ställa in serie porten i "raw mode" när jag skulle snacka med den "binärt".

/Olof

Att data kan komma i omkastad ordning är inte obekant i paketorienterade nät, datapaketen kan åka olika och parallella vägar med olika fördröjningar och beroende av köbildningar i routers och switchar så kan de anlända i tidmässigt annan ordning vid mottagaren.

TCP/IP-stacken är till stor del för att säkra upp att datat som levereras kommer i rätt ordning ( och frågar om efter saknade paket när det är hål i paketkedjan) när det levereras vidare medans tex. UDP-paket så finns det ingen garanti för sådant eller att det inte förekommer dubbletter som anländer i olika tid för att det gått flera olika parallella vägar med olika tidsfördröjning.

Man kan ana konflikten mellan paketorienterade nät och kretskopplade nät här - något som telebolagen har stångats med att kunna sända paketorienterad data över kretskopplad system som GSM och GPRS och senare UMTS för dryga 10 år sedan och idag har omvänd problemet att köra VOIP och Volte över rena paketorienterade nät som över LTE för att duga för talad telefontrafik så att det av användaren skall upplevas som kretskopplat nät (dvs. låg tidsfördröjning mellan A och B som räknas i max 2 siffrigt antal ms, garanterad bandbredd och utan avbrott och hack i konversationen pga. data datapaket som köar och fördröjs sig i någon länk på vägen igenom)

Se paketorienterade nät som att skicka en bunt paket med postnord - bara för att det går till samma adressat innebär det inte att de olika paketen anländer i samma ordnings som de skickades eller ens samma dag då någon gjorde omvägen till Bryssel och sedan till Luleå innan det hittar rätt igen.

---

jag håller med att ASCII-värden är väldigt skönt att ha om man skall hantera produkter vars källkod och dokumentation av formaten kanske är borta efter 10 år och man kan ganska lätt gissa ut hyr det fungerar bara genom att studera dataflödena.

men ASCII-orienterande kommandon har en svaghet som är svårhanterbar - det är när man har opålitlig överföring med risk för bitfel, burststörningar och skräptecken mitt under dialogen. och via terminal som är tänkt för radorientera interaktion för människa så är det extremt svårt att få till en feldetektion och snygg hantering av kommandosatserna då man inte kan beräkna och få över checksumma på ett bra och osynligt sätt i konversationen för varje kommando man skickar eller kontrollerar svars-satserna med sin egna checksumma när man tar emot datapaketen....

En modern och "normal" portserver (t.ex. Moxa NPort 5110) har inga problem att skicka och ta emot råa bytes men jag har faktiskt stött på en äldre och udda portserver som inte hanterar binära data rätt. (Ska kolla fabrikat och modell.)

Använder man en portserver bör man alltid ha någon typ av checksumma. Kör man bara tcp/ip hela vägen behövs ingen checksumma eftersom detta redan är "inbyggt".

Edit: RiTex LT-30 hette portservern. Troligen inköpt runt år 2002.

http://www.hedindata.se/dokument/ld-30.pdf

> Ville bara svara eftersom ett flertal förespråkade att skicka data som text med mindre bra argument.

Mitt argument för ASCII för både numeriska data och annat har inget annat argument
än att det har fungerat bra och underlättat under de 35 år som jag har implementerat
kommunikation och loggning mellan produktionssystem och all möjlig utrustning.

Och visst, terminalservers (har jobbat mycket med både de klassiska DECServer av
olika modeller från DEC och senare modeller från Lantronix) har normalt inställningar
för att stänga av olika kontrollfunktioner och få linjen mer "raw" än normalt.

På applikationssidan är det även enklare att dumpa meddelandet till en loggfil om man
bara kan ta det rakt av utan konverteringar, som i sig kan förvanska värdena om man
har lite otur...

Sen så är det ju lite olika då man har full kontroll över båda ändar av kommunikationen
jämfört med om man ska implementera bara den ena änden och då den andra redan är
given utifrån en maskinleverantörs specifikation. Då blir det som det blir...

Sen så är det klart att det finns många färdiga protokoll idag, och har man tillgång
till drivers eller annan programvara i båda ändar så är det ju bara att köra det...

Slutligen så är det inte så mycket "seriekommunikation" som har en äkta RS232 länk i
kedjan idag. I vårat fall så går allt nytt direkt mellan t.ex. en LAN-ansluten PLC till vårat
produktionssystem, men internt på vårat system så ser det ut som att det kommer
seriellt genom terminaldrivern. Det gör att våran kommunikationsrutin i princip ser ut som
för 30 år sedan då det drogs RS232 kablar över fabriken. Så utvecklingen har varit:
- Fysiska RS232 portar med seriekabel (ofta 20 mA loop) över hela fabriken.
- Terminal servers (DECservers) med LAT portar och RS232 sista biten till utrustningen.
- Terminal servers med TCPIP med telnet portar och RS232 sista biten till utrustningen.
- Nätverksansluten utrustning (ofta PLC) med telnet portar direkt mot utrustningen.

Och den yngre generationen undrar vad vi diskuterar om. ASCII, binärt, checksummort?
WHAT! Bara att implementera ett REST API i MicroPython och leverera data i JSON format över TCP/IP