Kör du intern RC på AVR så driver den med temperaturen tillräckligt för att Uarten skall sluta fungera.
100% säker, du behöver inte leta efter något annat.
Har en hel hög olika produkter med detta problem.
Det finns två lösningar.
1. Byt till extern kristall
2. Synkronisera mot inkommande data i en av enheterna. Så som jag löste detta så hade jag en enhet som
alltid skickade ut data. Mottagande enhet startade med en kraftigt omkalibrerad RC (d.v.s på lägsta kalibrerade hastigheten)
och så vred den långsamt upp hastigheten samtidigt som den kollade om UART rapporterade fel.
När felen försvinner har man hittat en synk klocka som fungerar.
Kommer felen tillbaks så börja justera igen
Swech
temp.beroende UART problem mellan två microcontrollers
Re: temp.beroende UART problem mellan två microcontrollers
Sen är frågan om man kan ha ett protokoll som medger att fel kan upptäckas och att man kan justera i enlighet med detta.
*Tänkar fritt*
Om ett kommunikationsblock har en uppbyggnad av typen:
<STX>
<Data> // Kan vara kommaseparerat, t.ex. "15,2789,<CS>" som då betyder kommando 15, värde 2789, CS=checksum
<ETX> // Kan undvaras vid dödtid mellan block.
För att verkligen kunde separera olika block ifrån varandra ville det vara en stor fördel om man ÄVEN hade en viss dödtid mellan.
Om man väljer STX rätt borde man kunde få lite idéer om hur hastigheterna ligger i förhållande till varandra.
En UART börjar ju vanligtvis med '1' som start, innan sändning.
Startbit är en '0' och MSB skickas (oftast) först.
Så att ha STX som är t.ex. 0x00 kan man uppnå lite fördelar. Om den mottas och det måste vara en STX (tid & position):
* Är värdet == 0x00 OCH checksum passar är saken biff.
* Är värdet > 0x00 måste mottagande UART köra för snabbt vilket får Stopbit att glida in på LSB-platsen. Kan även utlösa Frame-Overrun om man kör med 1 stopbit.
* Frame-Overrun ihop med värdet 0x00 bör ju visa att mottagande UART kör för långsamt.
Med värde menas FÖRSTA byten som ju SKA vara STX.
Kör man textbaserat överföring kan man dels begränsa legala tecken till '0'-'9', <STX>, <ETX> samt separator.
Jag brukar ha checksum som hexadecimalt för att ha fast storlek, alla värden kan såklart använda det format också vilket kan vara mer effektivt - och då kan tecknen utökas med 'A' - 'F'.
Sedan kan man ju klura lite på bitmönster för olika tecken och i en del fall komma fram till att kommer det rent faktisk x borde enda möjliga vara y och mottagaren kör då för långsamt/snabbt. Då justerar man lite och skickar en "sorry, missade den, skicka igen, please" meddelande (om möjligt).
Det blir mycket jobb för något en billig keramisk resonator till 3:- hade fixat - och korrigeringsfunktionen ska vara aktiv konstant med intern RC.
*Tänkar fritt*
Om ett kommunikationsblock har en uppbyggnad av typen:
<STX>
<Data> // Kan vara kommaseparerat, t.ex. "15,2789,<CS>" som då betyder kommando 15, värde 2789, CS=checksum
<ETX> // Kan undvaras vid dödtid mellan block.
För att verkligen kunde separera olika block ifrån varandra ville det vara en stor fördel om man ÄVEN hade en viss dödtid mellan.
Om man väljer STX rätt borde man kunde få lite idéer om hur hastigheterna ligger i förhållande till varandra.
En UART börjar ju vanligtvis med '1' som start, innan sändning.
Startbit är en '0' och MSB skickas (oftast) först.
Så att ha STX som är t.ex. 0x00 kan man uppnå lite fördelar. Om den mottas och det måste vara en STX (tid & position):
* Är värdet == 0x00 OCH checksum passar är saken biff.
* Är värdet > 0x00 måste mottagande UART köra för snabbt vilket får Stopbit att glida in på LSB-platsen. Kan även utlösa Frame-Overrun om man kör med 1 stopbit.
* Frame-Overrun ihop med värdet 0x00 bör ju visa att mottagande UART kör för långsamt.
Med värde menas FÖRSTA byten som ju SKA vara STX.
Kör man textbaserat överföring kan man dels begränsa legala tecken till '0'-'9', <STX>, <ETX> samt separator.
Jag brukar ha checksum som hexadecimalt för att ha fast storlek, alla värden kan såklart använda det format också vilket kan vara mer effektivt - och då kan tecknen utökas med 'A' - 'F'.
Sedan kan man ju klura lite på bitmönster för olika tecken och i en del fall komma fram till att kommer det rent faktisk x borde enda möjliga vara y och mottagaren kör då för långsamt/snabbt. Då justerar man lite och skickar en "sorry, missade den, skicka igen, please" meddelande (om möjligt).
Det blir mycket jobb för något en billig keramisk resonator till 3:- hade fixat - och korrigeringsfunktionen ska vara aktiv konstant med intern RC.
Re: temp.beroende UART problem mellan två microcontrollers
Absolut enklaste är ju att aktivt mäta bit-längden och justera osc-calib så att bitlängd blur precis 1/9600.
Aktivera tex en timer som du läser av vid pin-change. Delta-tiderna ska alltid vara men multipel av 1/9600 sekunder om du kör 9600.
Aktivera tex en timer som du läser av vid pin-change. Delta-tiderna ska alltid vara men multipel av 1/9600 sekunder om du kör 9600.
Re: temp.beroende UART problem mellan två microcontrollers
Problemet är ju att då ska data ändå kopplas till en pinne med interrupt-on-change om den inte redan har den funktion vid UART aktiverat.
Detta vill då kräva ändring av mönsterkortet, vilket ju är ett mega problem.
Och ska man ändå ändra är en keramisk resonator enklare och löser "allting" på det "rätta" sätt.
Detta vill då kräva ändring av mönsterkortet, vilket ju är ett mega problem.
Och ska man ändå ändra är en keramisk resonator enklare och löser "allting" på det "rätta" sätt.
Re: temp.beroende UART problem mellan två microcontrollers
Att skippa kristallen/keram är en av dom mer dumsnåla ekonomiska optimeringarna man kan göra - du har säkert med din tid i felsökning av problemet spenderat i kostnad för flera tusen kristaller redan, och säkert flera tusen till kristaller innan problemet är löst...
Men vad jag förstår så har du en klock-kristall på 32768Hz - synka/kalibrera mot denna och i många MCU så kan man också genera mha. PLL uppväxling från klockan till sin önskade bruksfrekvens.
Annars göra som Swech säger - en får vara master och den andra leta med kalibrering på RC-oscillatorn tills lyckat länk upprättats (och placera sig i mitten av områdets upp och nedkant av den fungerande frekvensområdet) och vara beredd att göra om proceduren igen när länken tappas eller har för många felaktiga paket. Jag förmodar att du har kontrollsumma så att du vet att meddelandet är framkommet oskadat.
(ASCII-baserad protokoll tänkt för att kunna brukas av människa via terminal, är bland det värsta som finns att försöka kontrollera om meddelandet överfördes på rätt sätt - checkusmmor etc. är svåra att dölja och människa har inte förmåga att processa sådana i huvudet snabbt och verifiera mot meddelandet utan hjälp - den typen av överföring måste bygga på att det finns en lägre nivå av upptäckt och ev. felkorrigering - men på direkt RS232 är det inte lätt och dessutom endast på byte-nivå ifall paritet används och inte för hela meddelandet ihop, och paritet märker bara vid 1 bitfel, vid 2 fel kan det vara korrekt igen i avseende paritet)
---
Nu sitter man ofta i givna lösningar - men det hade varit bra att man i redan design tänker lite större när det gäller kommunikation, en av det viktigaste är att få bort DC-kopplingen och beroende av DC-nivåer så att man kan köra signaleringen högpassfiltrerat - dvs. via en trafo (tänk Ethernet) för galvanisk uppbrytning mellan näten eller via kondingar (används i PCIe bl.a) som DC-blockerare.
Med den tekniken så slipper man väldigt mycket krångel med störningar och vagabonderande strömmar mellan apparaterna så fort de är minsta bit isär distansmässigt från varandra, med kanske olika strömförsörjningspunkter och olika väggvårtor på olika grenar/faser av elnätet...
För att klara detta bättre så behöver man linjekoda datat så att den blir DC-neutral - dvs. lika många '1' och '0' räknat över ett antal bitars längd och hur många lika efterföljande tecken man kan skicka beror på hur stor trafons induktans eller kondenstorns kapacitans innan det mättas och börja distordera signalmässigt.
en av de klassiska är manchesterkod som är DC-neutral efter varje bit, men förbrukar dubbel bandbredd gentemot överföringen. i många fall används differentiell Manchestekod för att bli okänslig om man skulle växla polaritet på paren i tex. en RS485-nät
Idag har man mer effektiva linjekodare (mindre overhead) och vanligt använt är 8b/10b-kod (tex PCIe tom v.2), men finns också i 3b/4b, 4b/5b, 5b/6b
För 8b/10b är typisk att man slår upp i tabell och iden - förutom DC-neutral inom 10 bitars fönster så får man gynnsammare och mer brusformad frekvensspridning, med mindre innehåll av diskreta toner (viktigt vid EMC), en viss robusthet och möjlighet att upptäcka fel tidigt i överföringen då 'bit-slip' (tex. pga. klocka går lite olika mellan ändarna) ger 'ogiltiga' kombinationer eftersom kodrymden bara har 1/4-del giltiga kombinationer (några av de 'ogiltiga' kombinationer används dock för utombands-signalering) - mönstren på de giltiga koderna är noga genomtänkt både med i hur EMI-emissioner ser ut vid normal drift och hur fort man ramlar in i en 'ogiltig kod' och därmed feldetektering om man har störningar eller 'bit-slip' för att klockorna inte stämmer överens, vilket upptäcks på enstaka frames och inte först när checksumman för hela meddelandet sänds över (och checksumman i sig kan vara påverkad med fel så att meddelandet ändå bekräftas som korrekt med en mycket liten men ändå existerande sannolikhet)
Nu är tyvärr UART både väldigt standard och väldigt oflexibel om man funderar på kanalkodning - den startar alltid med en hög logisk '1' och slutar med en eller två (beroende på konfiguration) logiska '0', bit '9' (paritet) kan man heller ofta inte påverka då den är HW-genererad inom UART, vilket gör att det alltid kommer finnas en rest av en diskret ton i EMI-utstrålningen (från tex kablar) som är kopplad till frame(=byte)-takten
...så man kan förstå att sådant inte ligger i topprioritet på en utvecklares agenda - men har man förhoppning att sitt till en början 'lilla' system plötsligt bli populär och längderna mellan enheterna ökar (vilket dom _alltid_ gör...) så måste man förr eller senare tänka i dom här banorna - annars kommer man sitta en dag vid 'väggen', där systemen blir utstörda pga. galvaniska strömmar mellan enheterna när strömförsörjningen kopplas till olika elnät (pga. läckage och 'kommunikation' genom avstörningskondingarna i nätaggen), distorderad signal vid mottagaren (pga att kabeln har komplex impedans och därmed utsmetande på pulserna för att man kör i för långsam takt), kanske inte balanserade utgångar (läs inte RS485 eller liknande signalering med differentiella par) och det är enorma kostnader att göra allt från början igen, med kanske bakåtkompatibilitetskrav etc. att ta hänsyn till.
sådana produkter som tänkte på sådant redan från början är tex som senare blev Ethernet - utan det tänket så skulle man inte ha Ethernet som en standard utan annan produkt som tänkte på samma banor.
Men vad jag förstår så har du en klock-kristall på 32768Hz - synka/kalibrera mot denna och i många MCU så kan man också genera mha. PLL uppväxling från klockan till sin önskade bruksfrekvens.
Annars göra som Swech säger - en får vara master och den andra leta med kalibrering på RC-oscillatorn tills lyckat länk upprättats (och placera sig i mitten av områdets upp och nedkant av den fungerande frekvensområdet) och vara beredd att göra om proceduren igen när länken tappas eller har för många felaktiga paket. Jag förmodar att du har kontrollsumma så att du vet att meddelandet är framkommet oskadat.
(ASCII-baserad protokoll tänkt för att kunna brukas av människa via terminal, är bland det värsta som finns att försöka kontrollera om meddelandet överfördes på rätt sätt - checkusmmor etc. är svåra att dölja och människa har inte förmåga att processa sådana i huvudet snabbt och verifiera mot meddelandet utan hjälp - den typen av överföring måste bygga på att det finns en lägre nivå av upptäckt och ev. felkorrigering - men på direkt RS232 är det inte lätt och dessutom endast på byte-nivå ifall paritet används och inte för hela meddelandet ihop, och paritet märker bara vid 1 bitfel, vid 2 fel kan det vara korrekt igen i avseende paritet)
---
Nu sitter man ofta i givna lösningar - men det hade varit bra att man i redan design tänker lite större när det gäller kommunikation, en av det viktigaste är att få bort DC-kopplingen och beroende av DC-nivåer så att man kan köra signaleringen högpassfiltrerat - dvs. via en trafo (tänk Ethernet) för galvanisk uppbrytning mellan näten eller via kondingar (används i PCIe bl.a) som DC-blockerare.
Med den tekniken så slipper man väldigt mycket krångel med störningar och vagabonderande strömmar mellan apparaterna så fort de är minsta bit isär distansmässigt från varandra, med kanske olika strömförsörjningspunkter och olika väggvårtor på olika grenar/faser av elnätet...
För att klara detta bättre så behöver man linjekoda datat så att den blir DC-neutral - dvs. lika många '1' och '0' räknat över ett antal bitars längd och hur många lika efterföljande tecken man kan skicka beror på hur stor trafons induktans eller kondenstorns kapacitans innan det mättas och börja distordera signalmässigt.
en av de klassiska är manchesterkod som är DC-neutral efter varje bit, men förbrukar dubbel bandbredd gentemot överföringen. i många fall används differentiell Manchestekod för att bli okänslig om man skulle växla polaritet på paren i tex. en RS485-nät
Idag har man mer effektiva linjekodare (mindre overhead) och vanligt använt är 8b/10b-kod (tex PCIe tom v.2), men finns också i 3b/4b, 4b/5b, 5b/6b
För 8b/10b är typisk att man slår upp i tabell och iden - förutom DC-neutral inom 10 bitars fönster så får man gynnsammare och mer brusformad frekvensspridning, med mindre innehåll av diskreta toner (viktigt vid EMC), en viss robusthet och möjlighet att upptäcka fel tidigt i överföringen då 'bit-slip' (tex. pga. klocka går lite olika mellan ändarna) ger 'ogiltiga' kombinationer eftersom kodrymden bara har 1/4-del giltiga kombinationer (några av de 'ogiltiga' kombinationer används dock för utombands-signalering) - mönstren på de giltiga koderna är noga genomtänkt både med i hur EMI-emissioner ser ut vid normal drift och hur fort man ramlar in i en 'ogiltig kod' och därmed feldetektering om man har störningar eller 'bit-slip' för att klockorna inte stämmer överens, vilket upptäcks på enstaka frames och inte först när checksumman för hela meddelandet sänds över (och checksumman i sig kan vara påverkad med fel så att meddelandet ändå bekräftas som korrekt med en mycket liten men ändå existerande sannolikhet)
Nu är tyvärr UART både väldigt standard och väldigt oflexibel om man funderar på kanalkodning - den startar alltid med en hög logisk '1' och slutar med en eller två (beroende på konfiguration) logiska '0', bit '9' (paritet) kan man heller ofta inte påverka då den är HW-genererad inom UART, vilket gör att det alltid kommer finnas en rest av en diskret ton i EMI-utstrålningen (från tex kablar) som är kopplad till frame(=byte)-takten
...så man kan förstå att sådant inte ligger i topprioritet på en utvecklares agenda - men har man förhoppning att sitt till en början 'lilla' system plötsligt bli populär och längderna mellan enheterna ökar (vilket dom _alltid_ gör...) så måste man förr eller senare tänka i dom här banorna - annars kommer man sitta en dag vid 'väggen', där systemen blir utstörda pga. galvaniska strömmar mellan enheterna när strömförsörjningen kopplas till olika elnät (pga. läckage och 'kommunikation' genom avstörningskondingarna i nätaggen), distorderad signal vid mottagaren (pga att kabeln har komplex impedans och därmed utsmetande på pulserna för att man kör i för långsam takt), kanske inte balanserade utgångar (läs inte RS485 eller liknande signalering med differentiella par) och det är enorma kostnader att göra allt från början igen, med kanske bakåtkompatibilitetskrav etc. att ta hänsyn till.
sådana produkter som tänkte på sådant redan från början är tex som senare blev Ethernet - utan det tänket så skulle man inte ha Ethernet som en standard utan annan produkt som tänkte på samma banor.
Senast redigerad av xxargs 9 februari 2019, 13:48:28, redigerad totalt 1 gång.
Re: temp.beroende UART problem mellan två microcontrollers
Denna tråd bör jag skriva ut och läsa tror jag. Det är ganska mkt erfarenhet här. Jag är ganska grön på hur uart fungerar i detalj mellan microprocessorer. Har jobbat med SPI och I2C men sällan med uart. (Hmm....kanske SPI borde vara bättre?)
Denna gång hoppas jag verkligen att det inte är baudrate problem pga temperatur. Jag hoppas vi kan hitta "gammalt" skit/strukturella problem som blev kvar efter att koden kopierades från gamla versionen.
Hur det än är, denna tråd reser en varningens flagga vilket leder till att man bör göra nåt åt att säkerställa uart:ens funktion. Är det rätt uppfattat?
Denna gång hoppas jag verkligen att det inte är baudrate problem pga temperatur. Jag hoppas vi kan hitta "gammalt" skit/strukturella problem som blev kvar efter att koden kopierades från gamla versionen.
Hur det än är, denna tråd reser en varningens flagga vilket leder till att man bör göra nåt åt att säkerställa uart:ens funktion. Är det rätt uppfattat?
Re: temp.beroende UART problem mellan två microcontrollers
Med både SPI och I2C skickar du med en klocka mellan enheterna, det är då den som styr när mottagaren ska tolka dataledningen. En synkron överföring, ofta inga klockproblem.
Använder du UART /asynkron överföring måste mottagare och sändare ha bra synkade klockor för att inte få problem. Antingen genom att ha bra kristaller som ger de samma referens eller som föreslagits i tråden, mäta på inkommande signal och trimma sin egna klocka efter det.
Jag tror helt klart du bör titta över den interna RC-oscilatorn så att den är kalibrerad, det är relativt enkelt att råka skriva sönder det värdet. Det blir inte bra...
Använder du UART /asynkron överföring måste mottagare och sändare ha bra synkade klockor för att inte få problem. Antingen genom att ha bra kristaller som ger de samma referens eller som föreslagits i tråden, mäta på inkommande signal och trimma sin egna klocka efter det.
Jag tror helt klart du bör titta över den interna RC-oscilatorn så att den är kalibrerad, det är relativt enkelt att råka skriva sönder det värdet. Det blir inte bra...
Re: temp.beroende UART problem mellan två microcontrollers
Kan inte se nåt som hindrar att gå över till SPI i detta fall faktiskt. Då blir inte man beroende av en "bra" klocka. Jag förstår inte varför hw-konstruktörerna valde det spåret? Måste fråga imorgon...
Re: temp.beroende UART problem mellan två microcontrollers
Ja, med SPI slipper du tänka på synkningen.
Kanske du har tur och det är nåt som går att avlusa. Jag tänker att UART synkas på varje byte, så då borde felen också uppenbara sig i korta meddelanden, om "baudraten" är grundproblemet. (Men, samtidig är sannolikheten för fel i längre meddelanden större, eftersom det är fler bittar som kan bli fel.)
Kanske du har tur och det är nåt som går att avlusa. Jag tänker att UART synkas på varje byte, så då borde felen också uppenbara sig i korta meddelanden, om "baudraten" är grundproblemet. (Men, samtidig är sannolikheten för fel i längre meddelanden större, eftersom det är fler bittar som kan bli fel.)
Re: temp.beroende UART problem mellan två microcontrollers
Jag mätte upp tiden för ett helt byte som uarten skickade och det var typiskt 940 us. Testade olika produkter från olika batcher och det kunde diffa som mest typ +- 30 us mellan en tidig batch och en senare.
-
Jan Almqvist
- Inlägg: 1580
- Blev medlem: 1 oktober 2013, 20:48:26
- Ort: Orust
Re: temp.beroende UART problem mellan två microcontrollers
Är 940 us tid för startbit och 8 databitar dvs 9 bitar?
I så fall en baudrate på c:a 9574 och ett fel på mindre än 0.3 % dvs försumbart.
I så fall en baudrate på c:a 9574 och ett fel på mindre än 0.3 % dvs försumbart.
Re: temp.beroende UART problem mellan två microcontrollers
Ja. Det är också min uppfattning. Då har jag också i vissa prov kylt ner PCB:erna...Jan Almqvist skrev:Är 940 us tid för startbit och 8 databitar dvs 9 bitar?
I så fall en baudrate på c:a 9574 och ett fel på mindre än 0.3 % dvs försumbart.
-
Jan Almqvist
- Inlägg: 1580
- Blev medlem: 1 oktober 2013, 20:48:26
- Ort: Orust
Re: temp.beroende UART problem mellan två microcontrollers
+/- 30 us borde kunna gå.
Om du kör 8N1 så tycker jag att gränsen för när det absolut kommer att gå fel ligger runt c:a 4.5% sammanlagt fel i sändare och mottagare.
Därav kanske siffran max 2% fel som nämnts i ett tidigare inlägg.
Om du kör 8N1 så tycker jag att gränsen för när det absolut kommer att gå fel ligger runt c:a 4.5% sammanlagt fel i sändare och mottagare.
Därav kanske siffran max 2% fel som nämnts i ett tidigare inlägg.
-
Swech
- EF Sponsor
- Inlägg: 4694
- Blev medlem: 6 november 2006, 21:43:35
- Ort: Munkedal, Sverige (Sweden)
- Kontakt:
Re: temp.beroende UART problem mellan två microcontrollers
Säger igen, vis av erfarenhet, kör du RC oscillator på AVR med UART och ändrar temperaturen så går det åt he....vte.
Swech
Swech
Re: temp.beroende UART problem mellan två microcontrollers
Om enheterna inte har en tydlig master/slave roll är UART enklare, eftersom vilken av enheterna kan sända ut ett meddelande när som helst.Dalmas skrev:Kan inte se nåt som hindrar att gå över till SPI i detta fall faktiskt. Då blir inte man beroende av en "bra" klocka. Jag förstår inte varför hw-konstruktörerna valde det spåret? Måste fråga imorgon...
Om slaven vill skicka ett "spontant" meddelande på SPI måste den först göra mastern uppmärksam på att den har något att sända eller vänta till mastern bestämmer sig för att kolla om slaven har något att säga.
En standard SPI med dubbelriktat kommunikation med CS drar dubbelt så många pinnar som en UART, är det bara två enheter och man har full koll på bägge skulle man kunna skippa CS, men det är ändå 50% fler ledare/pinnar än UART.
