temp.beroende UART problem mellan två microcontrollers
Re: temp.beroende UART problem mellan två microcontrollers
Gå ner i hastighet och kanske köra 5bit. Där du sänder high/low nibble som två överföringar..
Re: temp.beroende UART problem mellan två microcontrollers
Jag tror dig. Temp.spannet är specat till +5 - +60. Normal drift är 20-30 grC.Swech skrev: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
Viktiga är att få beställaren att inse detta. Antingen FU (Förbyggande underhåll) eller oplanerat stopp. Förr eller senare kommer stopp att ske om det är så riskabelt som du säger.
Re: temp.beroende UART problem mellan två microcontrollers
Jag gillar idén med att ställa om RC-osc. kalibreringsvärden så comm genererar mycket fel. Sen trimmar processorn själv in sig, både nerifrån och uppifrån. Sen tar man ut mitten. Det gör systemet automatiskt. Det kan göras genom att ett "kalibrera-in-com-speeden" kommando skickas ut. Den som skickar ut kommandot börjar skicka kal.byten under en viss tid som mottagaren sen ska kalibrera in sig mot.
Re: temp.beroende UART problem mellan två microcontrollers
Men det betyder också att den kommunikation inte kan vara viktig!
Om det ska överföras värden som är av "stor" betydelse för systemets funktion är det ju ganska handikappande att en viss del inte kommer igenom för att systemet ska kalibreras till varandra - även om att det sker automatisk.
Data försvinner ju när det finns kalibreringsbehov.
Så själv-kalibreringen är en nödlösning och jag undrar varför det inte är vald en µC med bättre INTOSC från början.
Och finns det andra saker som kan bli drabbad av att hastigheten förändras i exekveringen?
Om det ska överföras värden som är av "stor" betydelse för systemets funktion är det ju ganska handikappande att en viss del inte kommer igenom för att systemet ska kalibreras till varandra - även om att det sker automatisk.
Data försvinner ju när det finns kalibreringsbehov.
Så själv-kalibreringen är en nödlösning och jag undrar varför det inte är vald en µC med bättre INTOSC från början.
Och finns det andra saker som kan bli drabbad av att hastigheten förändras i exekveringen?
Re: temp.beroende UART problem mellan två microcontrollers
Komm. är sporadisk i systemet och sker sällan. Då menar jag att det är minuter mellan då ett antal byten som ska över. Datat är inte direkt livsavgörande. Felaktig com får dock inte ske alltför ofta. Finns ingen gräns - än.
Att lägga in en kalibrering med en ev. justering som förebyggande underhåll i detta ser jag inte som en nackdel. Det kan ske kontinuerligt. Då menar jag att kalibreringen använder sig av egen oviktig data som testdata.
Orsaken till val av processor är *arv*. Alltså, produkten har genomgått ett antal uppdateringar under flera år och byte av processor(familj) har inte varit på agendan. Problemen och jobben har mer varit inne på att fixa funktionerna. Visst har det funnits en osäkerhetsfaktor i bakhuvudet med användandet av Intern RC-osc som klockkälla men det har inte legat högst på priolistan. Speciellt inte då vi testat comm under olika temperaturer.
Att lägga in en kalibrering med en ev. justering som förebyggande underhåll i detta ser jag inte som en nackdel. Det kan ske kontinuerligt. Då menar jag att kalibreringen använder sig av egen oviktig data som testdata.
Orsaken till val av processor är *arv*. Alltså, produkten har genomgått ett antal uppdateringar under flera år och byte av processor(familj) har inte varit på agendan. Problemen och jobben har mer varit inne på att fixa funktionerna. Visst har det funnits en osäkerhetsfaktor i bakhuvudet med användandet av Intern RC-osc som klockkälla men det har inte legat högst på priolistan. Speciellt inte då vi testat comm under olika temperaturer.
Re: temp.beroende UART problem mellan två microcontrollers
Är där kapacitet för det så skippa UART och kör bit-bang. T.ex. kort puls för nolla och lång för etta. Kan köras hyfsat snabbt. Har använt detta med hysad fart. Interrupt när puls kommer in. Nolla kortare än interruptlatensen och etta så lång att den alltid hinner läsas.
Maxim semi (Dallas) använder denna metod, men saktare, på sina "1-wire" prodkter.
Maxim semi (Dallas) använder denna metod, men saktare, på sina "1-wire" prodkter.
Re: temp.beroende UART problem mellan två microcontrollers
Om kommunikationen är "sällan" kan tiden däremellan ju användas för att skicka lite sync-tecken, t.ex. 0x00 direkt följd av 0xFF.
Då har mottagaren något att logga in på så att säga.
Då har mottagaren något att logga in på så att säga.
Re: temp.beroende UART problem mellan två microcontrollers
Ja. Ett simpelt protokoll är ju att föredra. Att UART valdes beror så vitt jag minns på att vi skulle uppdatera programvaran via Bootloader och den går på 38k. Sen är ju uart en stor standard. Så valet föll sig naturligt. Inget är dock skrivet i sten. Komm.metod kan styras med kommandon. Det finns redan en struktur för detta. Går ju att skapa ett kommando som heter "Gå över på Dallas-comm".
Kommentar till sista:
Ja. Den tanken har föresvävat mig. Använda dödtid till att skicka några sync-tecken. Vi måste dock tänka på batteriförbrukningen. Inte vara aktiv för länge.
Kommentar till sista:
Ja. Den tanken har föresvävat mig. Använda dödtid till att skicka några sync-tecken. Vi måste dock tänka på batteriförbrukningen. Inte vara aktiv för länge.
Re: temp.beroende UART problem mellan två microcontrollers
titta annars på LIN-bus löser det. De skickar sync i början på varje paket..
Re: temp.beroende UART problem mellan två microcontrollers
Epilog
1) Det visade sig att det var den ena processorn som klippte UART-porten trots att data kom in. Ibland laddades inte Timeouten korrekt.
2) Applikationen hade en kontrollerad slumpartad uppstartstid som vida kunde överstiga den som utrustningen trodde den hade så testutrustn. trodde att produkten hade startat men det hade den inte - ibland.
Dessa två saker är åtgärdade. Nu är det en spänningsmätning som ibland blir fel på vissa produkter om de kyls ner. Atmegan mäter m.h.a dess AD en spänning och på vissa enheter mäter den väldigt låg spänning vilket hindrar en normal uppstart.
1) Det visade sig att det var den ena processorn som klippte UART-porten trots att data kom in. Ibland laddades inte Timeouten korrekt.
2) Applikationen hade en kontrollerad slumpartad uppstartstid som vida kunde överstiga den som utrustningen trodde den hade så testutrustn. trodde att produkten hade startat men det hade den inte - ibland.
Dessa två saker är åtgärdade. Nu är det en spänningsmätning som ibland blir fel på vissa produkter om de kyls ner. Atmegan mäter m.h.a dess AD en spänning och på vissa enheter mäter den väldigt låg spänning vilket hindrar en normal uppstart.
Re: temp.beroende UART problem mellan två microcontrollers
Fel uppgifter från kollega. Det är inte spänningsmätningen som är fel när produkten är kylskåpssval. Det är troligtvis fel på 8MHz Interna klockan i 328P relativt 324PB processorn och det i sin tur påverkar 9600 baud uart-komm negativt. 324PB processorn tycks vara mer stabil med sin oscillator påstår han. Nu ska 328P processorns interna klocka kalibreras mot 32k kristallen.
Totala tiden för ett byte+1 stop är 932us för 324PB och 973us för 328P. Det var när de var nerkylda. Jag vet för lite för att uttala mig om detta - just nu.
Totala tiden för ett byte+1 stop är 932us för 324PB och 973us för 328P. Det var när de var nerkylda. Jag vet för lite för att uttala mig om detta - just nu.