temp.beroende UART problem mellan två microcontrollers

[Micke_s]

Gå ner i hastighet och kanske köra 5bit. Där du sänder high/low nibble som två överföringar..

[Dalmas]

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

Jag tror dig. Temp.spannet är specat till +5 - +60. Normal drift är 20-30 grC.
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.

[Dalmas]

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.

[Icecap]

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?

[Dalmas]

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.

[Marta]

Ä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.

[Icecap]

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.

[Dalmas]

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.

[Micke_s]

titta annars på LIN-bus löser det. De skickar sync i början på varje paket..

[Dalmas]

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.

[Dalmas]

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.