Kommunikation i hemmanätverk mellan µc:s typ RS232

[blueint]

Ifall man använder UART så kräver det väl också kristall, dvs den inbyggda RC oscillatorn är för instabil? ( => mer komponenter och kostnad)

[E85]

Jag hade problem en gång att kommunicera med UART µC <-> µC på interna oscillatorerna men PC <-> µC har aldrig varit något problem upp t.o.m 115.2Kbps. Kanske blir det skillnad med längre kablar osv, vad vet jag...

[Icecap]

Näpp! Välj kretsar med en 8MHz och den är rikligt precis att köra UART med.

[sodjan]

> ...dvs den inbyggda RC oscillatorn är för instabil?

Ja, men det gäller bara de äldre PIC modellerna som hade en intern *RC* oscillator.
Alla nyare PIC modeller som har kommit de senaste ca 5 åren har en betydligt bättre
INTOSC med oftast tillräckligt bra noggranhet för vanlig seriell kommunikation.

[v-g]

I mitt jobbprojekt som använder 9-bitarskommunikation har jag istället en nod med en microcontroller med dubbla uarter som interface mellan RS485 och PC, en sådan nod användes även som sniffer vid utveckling av protokollet.

Nu är du inne på något intressant här, jag kan ju såklart inte ett piss om detta pga att jag inte haft möjligheten att prova. Men är convertern jag lyckats hitta nåt att ha eller ska man satsa på någon annan? Hur fungerar INTE datorn med 9-bitar?..... kollade i hyperterminal och såklart kan man ju inte bara ändra till 9 bitar där

Hur är det tänkt att det hela ska fungera? Hur ställer man in och var? Eller är det såpass att jag _måste_ ha en extra PIC enkom för detta (iofs inget problem men)....

[rickardg]

Problemet med uC<->uC är att man får två stora fel så totala maxfelet blir nästan dubbelt så stort så då fungerar det sämre än uC<->PC för PC:n har en kristalloscillator med ett fel som är försumbart i förhållande till en intern dåligt kalibrerad RC-oscillator.

Interna oscillatorn i AVR:er är kalibrerad till 10% från fabrik, vilket inte duger för kommunikation mellan två noder om båda har rc-oscilaltor, detta oavsett hastighet om man använder fast neddelning utan nån form av autosense på hastighet, men efter kalibrering (tex med en vanlig AVRISPMKII) kan man få ned RC-oscillatorn till 1% och då funkar det att prata mllan två uC. Dock har RC-oscillatorn en temperaturvariation som gör att noden inte får variera mer än typ 20grader i förhållande till den temperatur vilken den kalibrerades för om inte båda noderna varierar i temperatur så de driver åt samma håll så de tål mer temptiff, en kristall är lite mer temp-stabil så det kan vara att föredra av den anledningen om man tänker sig en nod som sitter utomhus och kommunicerar med noder inomhus. Vad som gäller för PIC och andra MCU:er har jag inte koll på.

[blueint]

Mao, kommunikation som är självklockande kanske inte är så dumt?, iaf för enkla och billiga noder.

[rickardg]

Men är convertern jag lyckats hitta nåt att ha eller ska man satsa på någon annan? Hur fungerar INTE datorn med 9-bitar?..... kollade i hyperterminal och såklart kan man ju inte bara ändra till 9 bitar där

9-bitars kommunikation med adressbit är väl ett relativt nytt påfund, de flesta PC som säljs idag har inte es en RS232-port så i de fall de har en så är den väl för att vara bakåtkompatibel å då är väl inte 9-bitarskommunikation intressant för de flesta, har aldrig sett nån pc som har stöd för det iaf.

Hur är det tänkt att det hela ska fungera? Hur ställer man in och var? Eller är det såpass att jag _måste_ ha en extra PIC enkom för detta (iofs inget problem men)....

Är dock inte så mycket som ska till för att bygga en pryl som sitter mellan själv, har inte sett några färdiga sådana konverterare. Men sen måste du inte ha 8-bitarskommunikation heller, går att lösa med startsekvenser osv med 8-bitarskommunikation men det innebär att alla måste ligga och lyssna hela tiden istället.

[v-g]

En PICs interna oscillator är fabrikskalibrerad till 1% nogrannhet det ska räcka för de flesta ändamål.

rickardg:Fan blir svårt detta, iom att jag helst vill köra hårdvaruUSART:en Ska man då kommunicera över två gränssnitt krävs ju att man "pausar" det ena medan man lyssnar på det andra.

Hmm hitta detta:http://se.activexperts.com/activcomport/ verkar stödja RS485 men vad det hjälper vet jag inte. Iofs kan man ju ganska enkelt koda så att man sätter portens pinnar manuellt men även det kräver ju meck

[rickardg]

ser inte riktigt problemet, en uC med dubbla uartar som kommunicerar med interrupts på båda, å så lite buffrar för att både skicka och ta emot data så fugerar det fint, dock en hel del jobb att skriva ett multidrop-protokoll med kollisionsdetektering och omsändningar osv. En enklare variant är att göra ett master-slave system till att börja med och senare gå över till multi-master när du fått igång master-slave varianten.

[blueint]

Något som kan vara värt att tänka på är att många PC inte har RS-232 port längre. Så det kanske finns någon USB <-> 9-bit UART adapter?

[Icecap]

Jag har testat med 9-bit kommunikation och förkastat det! I mitt tycke är det såhär:
* All kommunikation utlöser "bara" en interrupt som är snabbt avklarat, det man vinner vid att använda 9-bit är att bara adress i en kommunikationsblock ger interrupt, å andra sidan ska den interrupt (vid rätt adress) sedan växla läge och hålla koll på detta, allt för att ta emot hela blocken.
* Vinsten är med 9-bit adress är obefintlig, pga. den mer tillkrånglade styrning kan varje interrupt t.o.m. ta längre tid och vid ganska få slaver på linjen kan det vara ett mycket litet prestandaförlust.
* Kommunikation som innehåller mer än en byte sker i block, det är lika bra att starta varje block med en unik byte.
* Har man dynamisk blockstorlek är det en bra idé att avsluta varje block med en unik byte.

[v-g]

Jag tror att jag bara rör till det i onödan och det enklaste är att börja från början och se vart jag hamnar.

blueint:Jo jag tänkte likadant men frågan är om de adaptrar som är USB-->RS485 inte är USB-->RS232-->RS485 annars tycker jag att man enkelt (tex på elfa) borde kunna hitta tex FTDI-chips. Jag sökte på ebay o visst de finns för 8$+frakt men frågan är ju om de är nåt bättre än den jag redan beställt? Och jag HAR port på min "server" och i backup har jag även USB-->seriell så det ska vara rätt lugnt

Icecap:Tack för bra info, tror jag börjar i det enkla, slänger på en "egen" adressdetektering och bygger på det. Sen tror jag att jag skippar stoppbyte utan helt enkelt får "veta" vilket svar som förväntas. Allt är ju kodat av moi så det ska nog kunna gå.

Som det är idag skickas bara datat "på kommando".

Jag tänkte dock väva in så att man kan välja vad som skickas skall så att man tex kan plocka ut innertempen om man skulle vilja visa den på en display i köket tex.

Drömma kan man ju iaf, hoppas tiden räcker till 1/100

[rickardg]

Att växla läge när man får rätt adress osv blir inte så många klockcykler jämfört med tiden det tar med alla extra interrupts man får av att ligga och kolla efter startbyte hela tiden

Tja, det är krångligare att hålla reda på läge jämfört med att inte göra det, men å andra sidan är det även krångligt att specialhantera start- och stop-byte när man vill skicka sådana bytes vid andra tillfällen än start/stop, så jag tycker tvärtom, med 9-bit blir krångligheten alltid vid samma ställe men med 8-bit blir krångligheten mer utspridd i hela paketen och då föredrar jag det förstnämnda

Det absolut starkaste argumentet mot 9-bit är att det inte går att det inte är helt standard så det går inte att sniffa med en PC och inte stödjs av alla MCU:er, sen blir det rätt mycket overhead om man har långa paket med 9-bit vilket slöar ner kommunikationen lite, men i övrigt ser jag mest fördelar med 9-bit.

[v-g]

Enklast är ju att ligga i sängen o sova antar jag

Jag får helt enkelt prova mig fram tror jag. Som tur är har man ju dig. oscilloscope så det är ju enkelt att kolla "facit". Utan detta skulle jag inte ens bemöda mig att försöka.

Man kan ju enkelt säga att om startbyte och adress inte detekteras korrekt så skippar man att kolla på kommunikationen på säg 50ms på så sätt slipper man interupta varje byte i kommunikationen.

Kan bli så illa att man kanske får köra CAN vad vet jag.

Det är ju inga "livsuppehållande"-krav på detta så bara man får till det hyffsat så duger det lång väg. Får ta det stegvis och avhjälpa ev buggar allt eftersom. Mitt nuvarande system tog nog ett halvår innan det var avlusat.

Det är heller inte tänkt att kommunikationen ständigt ska köras utan bara "on demand". Får smälla ihop två noder och experimentera mig fram helt sonika, att testa är att veta (så småningom).

Det viktiga är att grunden är rätt och där känner jag att jag borde kunna få fram nåt vettigt, det andra är bara mjukvara och sånt löser jag enklare än att riva upp och etsa om kort osv.