Avr32 linux-utveckling (rs485)

[daffy]

Hej!

Bakgrund:
Jag har tidigare endast utvecklat för Atmels 8-bitars mcu'er, och har i dagsläget i princip obefintlig erfarenhet av linuxutveckling för Atmels AP7000 -processor.
Jag har 8 st slav-enheter som för närvarande pratar med en Atmega128 via en rs485-slinga. Kommunikationen sker i form av 9-bitars "multi processor communication mode" där den extra biten indikerar ifall det är "adress" eller "data" som skickas. Jag önskar byta ut Atmega128'an till ett ngw100-kort för att på ett enkelt sätt utöka funktionalitetn med exempelvis web-konfigurering osv.

Problem:
Det verkar inte finnas något stöd för 9-bitars uart i linux.

Alternativa lösningar jag klurar på:
1. Koda till eget stöd för 9 bitars uart i linux. (Jag anser mig dock inte tillräckligt kompetent till detta.)

2. Fixa en eller flera 8bitars SPI-slavar som jag kopplar till ngw100, vilka i sin tur översätter informationen till 9bitars uart och skickar ut via rs485. (Känns lite overkill.)

3. Koppla upp 8st rs485-slingor (kabeldragning separat till varje slav-enhet ute i rummen) och skriv om mjukvaran i slavarna så att de kommunicerar med 8 bitars uart.

Jag tycker det lutar åt alternativ 3, vilket leder mig till följande följdfråga:

4. Någon som har tips på hur kan jag göra för att styra kommunikationen till olika rs485-slingor? Min tanke är att använda något i stil med en Maxim MAX1481 per slinga, och inifrån linux styra vilken av slingorna som för närvarande är "aktiv". Borde väl gå att styra genom att helt enkelt stänga ner de som inte skall användas med hjälp av GPIO på något sätt?

Låter min planerade lösning i fråga 4 vettig?

Hoppas att någon sitter på lite information som kan hjälpa mig på traven!

Tackar på förhand,
/D

[blueint]

Ett tips är att länka till t.ex. NGW100 eftersom alla kanske inte vet vad det är.
Samt dess AVR32 baserade AT32AP7000 cpu.

(1) Att koda stöd för 9-bits kanske inte är så omöjligt. Du får helt enkelt gräva lite i källkoden. Brukar inte vara supersvårt, men kräver tålamod och noggranhet. Alternativt kör NetBSD, dess källkod kan vara något enklare att hantera.

(2) Slav-cpu som översätter mellan 8-bit och 9-bit känns väldigt tillkrånglande. Kanske funkar nu, men så fort du vill bygga vidare på din lösning så behövs samma krångel tas om.

(3) Om du ska använda en slinga per slav så tar du bort en hel del av fördelarna med EIA-485.

(4) Slingdelning mha MAX 1481 tycker jag stupar på samma anledning som punkt (3).

Varför måste du använda 9-bit's mode övh?, borde gå att använda 8-bit på något elegant sätt. Så slipper du hela problematiken

[daffy]

Tack för ditt svar, och tack för hjälpen med att länka in relevant information vilket jag inte tänkte på.

(3) Om du ska använda en slinga per slav så tar du bort en hel del av fördelarna med EIA-485.

(4) Slingdelning mha MAX 1481 tycker jag stupar på samma anledning som punkt (3).

...Men å andra sidan riskerar jag inte att samtliga slavar dör ifall en kabel går av / kortsluts, vilket är av stor betydelse för mig. Har du (eller någon annan) tips angående bättre val av kommunikationskrets?

Varför måste du använda 9-bit's mode övh?, borde gå att använda 8-bit på något elegant sätt. Så slipper du hela problematiken

Det är så slavarna är implementerade i dagsläget. Som jag skrev i mitt ursprungliga inlägg är min tanke i dagsläget att skriva om slavarna så att de kommunicerar med 8 bitar.

"Går" det att koppla in 8st 485-kretsar till en AT32AP7000 och styra vilken av dem som för närvarande används med hjälp av GPIO?

Tackar på förhand!
/D

[blueint]

Du kan alltid ha flera enheter på EIA-485 om du kan addressera dom separat.

[TomasL]

Använder du något specifikt protokoll eller är det hemmasnickrat?

[daffy]

Du kan alltid ha flera enheter på EIA-485 om du kan addressera dom separat.

Japp, det är så jag använder det i dagsläget. Men nu vill jag ändra på det och använda separat kablage till varje slav för att minimera skadan ifall en kabel går av.

[daffy]

Använder du något specifikt protokoll eller är det hemmasnickrat?

Det är hemmasnickrat.

[TomasL]

Det är väl tämligen normalt inom de protokoll som normalt körs på rs485 typ modbus RTU att man behöver en UART som stöder 9 bitar, 2 stoppbitar eller 1 stoppbit och paritet är inte helt ovanligt och då behöver man den 9de biten i UART.
Om du inte har hårdvarustödet för 9 bitar är väl det enklaste att köra det i mjukvara trots allt.
De PICar jag använder för RS485 har stöd för 9 bitar i uarten, vilket är ett krav om jag skall kunna köra med två stoppbitar, vilket modbus-rtu kräver.

Men enligt Atmels datablad skall den stöda 9-bitars data

5- to 9-bit full-duplex synchronous or asynchronous serial communications

[TomasL]

Och linux skall stöda 9 bitar.
Hittade detta på linux.org

Characters are normally transmitted with either 7 or 8 bits (of data). An additional parity bit may (or may not) be appended to this resulting in a byte length of 7, 8 or 9 bits. Some terminal emulators and older terminals do not allow 9 bits. Some prohibit 9 bits if 2 stop bits are used (since this would make the total number of bits too large: 12 bits total).

Däremot kan är det nog så att du får manipulera den 9de biten separat, den skickas väl näst sist efter MSB, så det borde inte vara några problem för dig att sätta eller släcka den beroende på om det är data eller kommando.
Eftersom den normalt används som paritetsbit alternativt som en andra stoppbit, så kan du nog börja leta där.

[sodjan]

Men som paritetsbit så har man normalt inte kontroll över biten, USART'en
beräknar den "biten" automatiskt. En nionde databit måste man kunna styra
från koden om den ska ha någon praktiskt funktion alls.

Man skulle även kunna skriva ett rent 8 bitars protokoll med separata
funktioner för adresseringen, detta med 9 bitar känns lite förlegat. Frågan
är hur det fungerar när asynk trafik körs över t.ex USB/RS232 konverters
eller liknande...

[TomasL]

Normalt kan man konfigurera om paritetsbiten skall beräknas i hårdvara eller inte, så fattar jag Atmels dokumentation.

Sodjan, visst är det förlegat att använda 9 data-bitar, extra stoppbitar och/eller paritet, men de flesta i dag använda industriella protokoll är så gamla att man är tvungen till det, för att vara kompatibel.

[TomasL]

Frågan
är hur det fungerar när asynk trafik körs över t.ex USB/RS232 konverters

Hmm, jag kör över en RS485 konverter till USB, 8N2 det funkar problemfritt. Komprogram/terminalprogram brukar väl tillåta denna manipulering, och ställer porten därefter.

[sodjan]

> Hmm, jag kör över en RS485 konverter till USB, 8N2 det funkar problemfritt.

Alltså där den nioende biten är en "äkta" databit ? 8N2 är väl 8 data + 2 stopp (utan paritet) ?

[vfr]

Skall man köra 9-bitars läge med adresseringsbit över USB-omvandlare så måste omvandlaren stödja det läget, precis som vilken UART som helst. Jag har ingen aning om hur USB/serie-omvandlare har, vad gäller stöd för detta.

För att bygga ett 8-bitars protokoll så måste man ha endera av två saker.

1. Unika teckenavdelare

Unika tecken för <Start of message>, <End of message> och sedan omkodning av mellanliggande tecken så att man aldrig får dessa unika tecken ut på linan.

2. Start och stopphantering med definierade tider

Detta sätt körs av en del protokoll, t.ex vissa (alla?) Modbus-varianter

Själv har jag kört på alt. 1 i ungefär 12 år nu. Nackdelen är att omkodade tecken blir dubbla och paketet blir lite längre. Nackdelen med alt. 2 är att då är man inte bara beroende av vilka tecken som sänds, utan också av timingen mellan dem. Det gör felsökningen avsevärt jobbigare. Alt 1 går alldeles utmärkt att felsöka huvudsakligen med en vanlig linjelyssnare för serieport. Eftersom tiderna inte spelar någon roll (eller iallafall väldigt liten roll), så kvittar det i stort sett när tecknen sänds, utan man kan koncentrera sig på vad som sänds. Någon form av timeout vid uteblivet svar måste man ha, men den brukar vara rätt enkel att hantera.

[TomasL]

hittade denna länken

http://electronicdesign.com/Articles/In ... cleID=6245

Man behöver naturligt vis speciella drivrutiner som "fångar upp" paritetsbiten innan den skrivs till paritetsregistret i UARTen och på så sätt kan man manipulera den.
Men detta med "multi processor communication mode" är ju "hundra år gammalt" typ.
Det verkar som att det implementerades fysiskt i 8051or bla.