Multinode USART?

[Icecap]

Med USART menas oftast en enhet som kan fungera dels som UART och dels som USRT. Alltså att inställningen av funktionen anger om det ska vara en asynkron eller synkron överföring.

[Nerre]

Jesse, du verkar inte förstå hur synkron överföring fungerar.

Det går ingen separat klocklina mellan enheterna, de synkar sina klockor mot startflaggan i varje paket. (Och är paketen långa så finns det oftast stöd för att lägga in synkpaket i mitten.)

Som sagt var, ethernet använder synkron överföring.

[blueint]

Synkron överföring i ett MCU nät vore inte dumt.

[jesse]

Jesse, du verkar inte förstå hur synkron överföring fungerar.

Det finns förstås flera sorters synkron överföring. Jag tror den som finns i AVR-controlers använder en klocka parallellt med data linjen. Det var det jag tänkte på.

[Nerre]

Det är väl SPI du tänker på?

En USART borde rimligen klara "riktig" synkron kommunikation.

[jesse]

Jag tycker inte det ser ut så här: AVR USART explained

[Pajn]

Jag kan ha blandat ihop USART och UART. Jag har inte full koll på skillnaderna och vad de betyder i praktiken.
Alla enheter kommer ha en egen klocka så ingen ska klockas via nätet.

Jag vill kunna använda den in byggda modulen i mikrokontrollers. I de flesta PICar verkar det vara USART vilket blev anledningen till att jag skrev USART.

Antagligen behöver jag inte de extra funktionerna den ger, men jag vet faktiskt inte

Jag ska iaf. inte snacka åt båda hållen samtidigt (full duplex som det heter i ethernet) om det har med saken att göra.

[Nerre]

Här hittade jag en rätt bra beskrivning av det jag har pratat om.

http://www.quatech.com/support/comm-over-syncserial.php

Notera särskilt andra stycket under rubriken Clock Synchronization:

All three methods derive the clock signal for the reception line from the incoming data.

Jag höll på och mekade med Z80 SIO för en herrans massa år sen och den snackade både synkront och asynkront, så jag tog för givet att USART handlade om nåt som klarar samma sak. Men det verkar ju onekligen inte riktigt så.

Här fanns det lite mer info
http://sangoma.com/support/tutorials/sync_n_async.html

Att jämföra med hur ethernet frames ser ut:

http://en.wikipedia.org/wiki/Ethernet_frame

Som synes är det ganska stora likheter.

[jesse]

Ja, det där är ju en helt annan typ av synkron överföring och det fungerar nog inte med en USART.

[Pajn]

Nu är det lite mycket snack och lite lite verkstad
Om jag skaffar några SP485 (tyckte inte de verkade sämre än MAX485 så jag snålar lite ) så kan jag iaf. börja testa lite.

Några snabba frågor bara:
Ska jag använda både A och B? Verkade så i MAX485s datablad iaf.
Det värsta som händer om jag snackar "i mun" är att meddelandet går åt skogen, jag pajjar iaf. inget. Korrekt?
Är det bara att använda dem som när jag snackar 232?
Måste jag använda någon spec. baud? Annars tror jag nog jag börjar med 19200, jag tror inte jag behöver snabbare så då är det väl lika bra att köra långsamt. Det borde väl vara mindre känsligt?

[jesper]

Koppla A till A, B till B. Även en gemensam jord.
Hastigheten spelar ingen roll.
Även om du skulle komma att aktivera sändarna i flera samtidigt har de nog ett viss skydd mot det, se databladet.
Du måste ha en pinne som aktiverar sändaren för att skicka data. Vissa U(S)ART'er har en special funktion för detta, annars får du bitbanga det. Bortsett från det kör du som 'vanligt 232'.

[jesse]

Problemet med 485 är just att de inte får prata i mun på varandra. Drar du DE-pinnen hög på mer än en nod samtidigt kommer du att kortsluta dem (om data ut är olika). Det kan i värsta fall bränna kretsarna (Nu står det visserligen max 250mA vid kortslutning i databladet, så det kanske funkar ändå)... Och om detta händer så kan den sändande enheten inte se något fel, då den antagligen ser sin egen nivå på ingången.

Det var därför jag föreslog MCP2551 som kan hantera hur många noder som helst som kör samtidigt med hjälp av OPEN DRAIN. Men med den finns väl kanske andra nackdelar, t.ex för att nå hög hastighet måste du ha lågohmiga pull-up på bussen, och det drar ju mer ström i längden än vad enstaka 250mA kortslutningar på en rs485-buss ger.

Kanske andra som har mer erfarenhet av dessa databussar vet mer om för och nackdelarna med de olika sätten att jobba.

Om du ändå ska använda SP485 tycker jag du istället ska köpa SP483 - den har långsammare flanker och emitterar därmed mindre radiostörningar. Den kan köras i max 250 kbps.

[Pajn]

Tackar!
SP485 har två pinnar en för att aktivera läs och en för att aktivera skriv. De är inverterade så visst borde jag kunna sätta ihop dem och läsa när de är låga och skriva när de är höga? (För jag antar att jag inte vill läsa samtidigt som jag skriver med samma krets)

Jag hittar inget om kortslutningsskydd förutom det som jesse nämner så jag vet inte, jag får kanske testa det

Vad tror ni om att ha en separat tråd som är hög när nätet är "låst" och låg när det är fritt fram att "låsa" det och börja skriva?
(Eller om jag bör vända så låg = "låst")
Det känns ju ganska failsafe, visserligen kostar det en extra ledning men det kan jag nog ta.

Jag är även intresserad av respons på jesses förslag.

Att den sändande inte kan se något fel är ok eftersom det då aldrig kommer komma något svar och en omsändning kommer ske

[jesse]

Du kan lägga ihop DE och RE. Fast vissa kretsar har även en "sleep"-funktion som aktiveras om RE och DE är avstängda samtidigt, som då sparar ström. Det gör väl ingen stor skillnad egentligen, om du inte har batteridrivna noder som ska stå länge inaktiva, så det kan man gärna hoppa över.

[Pajn]

Jag såg det och blev frestad ända tills jag kom på att det då inte kommer gå att snacka med noden.
Systemet behöver kunna snacka med noden när som helst så det funkar ju inte.

En nod som inte går att accessa är antingen trasig eller ej längre ansluten så den ska bort ur systemet.

Möjligtvis blir det några noder som bara kommer sända (och lyssna på svar ofc.). Men om det blir sådana får jag väl designa de annorlunda.