FT232RL

[crize]

Har länge använt kretsen FT232RL (USB till UART) och detta har fungerat mycket bra. Men i vissa fall då jag vill skicka en stor
mängd data från PC:n till mikrokontrollern så hinner koden inte riktigt med. Detta resulterar i att vissa bytes "hoppas över". Då detta
inte är önskvärt skulle jag vilja implementera någon form av flödeskontroll.

Nu har jag googlat en del om detta och blir bara mer och mer förvirrad ju mer jag läser. I vilket fall som helst verkar FT232 innehålla 128 byte mottagningsbuffert samt 256 bytes sändningsbuffert. FT232 har även följande signaler: RTS, CTS, DTR, DSR, DCD, RI.

Min teori om hur detta fungerar är att data som skickas via PC till den virtuella serieporten hamnar i FT232RL:s mottagningsbuffert. Om pinnarna jag nämnde ovan inte är inkopplade så passerar datat direkt genom bufferten till AVR, d.v.s. scenariot blir detsamma som om det inte hade funnits någon buffert överhuvudtaget. Om jag använder signalerna ovan kan jag få FT232 chippet att sluta skicka data till mikrokontrollern och på så vis få användning av bufferten. D.v.s. bufferten fylls tills dess att dess att den innehåller 128 byte data och därmed är full. Vad skulle kunna hända när datorn skickar ytterligare en byte? är FT232 smart nog att skicka någon signal till drivrutinen som säger att datorn inte får skicka mer? eller börjar FT232 att kasta bort data?

Är det någon som har erfaranhet av detta och därmed kan bekräfta min teori alternativt rätta mig?

[Swech]

Är det i din AVR som det inte hängs med?
Isåfall så bör du kunna använda dig av CTS (clear to send)
Denna signalerar till din FT232 att det är grönt att skicka data till din AVR

CTS bör alltså emulera samma funktion som CTS har/hade på de seriella portarna.

Swech

[sodjan]

Normalt är det enklaste att låta AVR'n skicka något till PC'n
när det är klar att ta imot mer data. Har du dubbelriktad
kommunikation idag ?

[crize]

swech: det låter bra, ska försöka testa det nästa gång jag gör ett kort. På det nuvarande kortet har jag bara lämnat dessa pinnar oanslutna.

sodjan: man kan säga att det finns möjlighet till dubbelriktad kommunikation. Det är bara så att jag brukar föredra hårdvarulösning framför en mjukvarulösning. I det här fallet användes dock enkelriktad kommunikation. Jag öppnade serieporten med ett terminalprogram och klistrade in en stor textfil, detta överförs sedan via radiokretsen CC1101 till en mottagare där den senare skrivs ut. I utskriften saknas då vissa delar som fanns med i ursprungstexten.

[victor_passe]

det är inte så att radiolänken sabbar en del?
Du bör kanske skicka paket med cheksumma så du vet att allt har kommit fram korrekt.

[Swech]

Vilken radiolänk?

[bearing]

Från hans andra inlägg:

detta överförs sedan via radiokretsen CC1101 till en mottagare där den senare skrivs ut. I utskriften saknas då vissa delar

[crize]

victor_passe: nej, radion fungerar utmärkt. CC1101 är en mycket bra radiokrets med bl.a. CRC / FIFO / paket hantering. Kan därför se
att alla paketen når fram och att dessa även har korrekt CRC summa.

I flera tidigare projekt har jag implementerat en enklare kommandotolk som låter mig använda ett terminalprogram för att ge kommandon till mina byggen. Dessa projekt lider av samma problematik: Om jag öppnar ett terminalprogram och skriver in kommandon manuellt via tangentbordet så fungerar det utmärkt men om jag istället skriver in alla kommandon jag vill skicka i filen kommandon.txt och sedan skickar alla kommandon samtidigt genom t.ex:

cat kommandon.txt >/dev/ttyUSB0

så börjar systemet att missa kommandon. En enkel lösning är väl t.ex. att låta mikrokontrollern skriva ut ett OK eller ERROR meddelande efter varje utfört kommando för att visa att den nu är klar att exekvera nästa. Men detta kräver givetvis mer av "PC" sidan. För att behålla kompabilitet med enkla verktyg som t.ex. "cat" kommandot ovan krävs det någon form av flödeshantering som gör att PC:n inte kan översvämma AVR:en med data som denna inte har någon möjlighet att behandla inom rimlig tid. Hmm... vet inte om jag förtydligade problematiken eller krånglade till det =)

[sodjan]

> Det är bara så att jag brukar föredra hårdvarulösning framför en mjukvarulösning.

Ja men alltså...

Hårdvaruhandskakning fungerar bra när det är en enkel länk med två ändar/parter.
I ditt fall med flera olika länkar och olika media (USB/radio/seriellt) så kan det vara
svårt att få en hårdvaruhandskakning att "replikera tillbaka" genom hela kedjan. Betydligt
enklare då med en "ACK" från mottagaren när det är klart att skicka nästa paket.
Din radiolänk verkar också ha packethantering, så hur ska du få en hårdvaruhandskakning
att gå fram till andra sidan från din AVR ?

*Eller*, kör så pass långsamt att det alltid fungerar utan handskakning...

[bearing]

Om det är lika enkelt att skicka från microcontrollern till datorn borde du ju snabbt kunna fixa att den skickar tillbaka det som kom in för att se om samma kommer tillbaka.

USARTen i en microcontroller brukar kunna berätta om det blir buffer overflow. USARTen i en PIC stänger helt av mottagaren ifall bufferten flödar över, har jag för mig. Om bufferten i FT232RL blir fylld borde ju även den kunna kommunicera det på något sätt, tycker jag.

[crize]

sodjan: håller med om att det är en enkel och bra lösning att låta mottagaren skicka ett ACK när denna
har tagit emot ett paket och är redo att hantera nästa.

bearing: Ja det stämmer, har använt eko-metoden förut men i det fallet så krävs det som sagt någon form av egenutvecklad mjukvaran i PC:n för att
kontrollera om jag verkligen får tillbaka samma sak. Jag kan därmed inte direkt kommunicera med de enklaste funktionerna t.ex:

cat fil.txt > /dev/ttyUSB0 // linux
type c:\fil.txt > COM2 // windows
print #1, $kommandon; // basic
fwrite(ser,4); // matlab

Det jag är ute efter här är att skapa kod som inte är beroende av att saker sker på ett visst sätt. Mitt radio API är t.ex. konstruerat för att på ett så enkelt sätt
som möjligt kunna integreras i olika byggen. Nackdelen med detta är givetvis att resurserna aldrig kan användas optimalt. Fördelen är att jag får ett mycket
enkelt sätt att överföra data mellan punkt a och punkt b vilket illustreras nedan:

cc1101_transmit_frame(IF0, 0x00, &h, 4, "hej");
cc1101_transmit_frame(IF0, 0x00, &h, sizeof(GPS_DATA), &d);
cc1101_transmit_frame(IF0, 0x00, &h, sizeof(double), 3.14);

Jag överlåter allt ansvar för datakommunikationen till mitt radio API så jag därmed kan betrakta radiolänken som en "black box". Jag får således
bara två utfall:

1. cc1101_transmit_frame(...) returnerar ett OK vilket betyder att detta paket är korrekt mottaget av B.
2. cc1101_transmit_frame(...) returnerar ett felmeddelande vilket betyder att paketet inte har bekräftats av B.

Detta anser jag vara helt i sin ordning då felet isåfall har en bra förklaring som t.ex. dåligt radioförhållande.
Jag tycker däremot inte att det är OK att data kastas bort p.g.a. att man inte använder tillgänglig hårdvara på kortet.

[bearing]

Funkar inte
cat /dev/ttyUSB0
eller
cat /dev/ttyUSB0 > loggfil

för att få det som skickas från mikrocontrollern?
Det funkar iaf med med vanlig serieport.

Jag menade inte att det skulle vara en permanent lösning, utan ett sätt att debugga. Eftersom att datan går i flera steg måste du "avlyssna" mellan varje steg för att kunna se var det blir fel. Skicka t.ex. in en text, och jämför sedan loggfilen med texten som skickades in.

[crize]

Jo det fungerar mycket bra i den riktningen (AVR->PC). Men det är i riktningen (PC->AVR) problemet uppstår. Vi bortser från fallet med radiolänken då denna är mer komplicerad och tar istället följande exempel som belyser det jag är ute efter:

1. datorn skickar ett serie kommandon till mikrokontrollern
2. en interrupt rutin i AVR lägger varje mottaget tecken till en buffert.
3. om bufferten innehåller ett giltigt kommando så ska detta kommando köras genom att anropa lämplig funktion.

Antag att kommandon som skickas är följande:

SET LED1
WAIT INPUT2
CLR LED1
.
.
.

under tiden AVR behandlar första kommandot SET_LED1 hinner interrupt rutinen lägga till ytterligare några bytes till bufferten. (ok, i detta fall kanske den faktiskt inte hinner det). WAIT INPUT2 körs igång men tar nu mycket längre tid att köra låt säga 5 minuter. Under tiden som WAIT INPUT2 exekveras hinner det anlända så pass mycket data att bufferten inte kan hantera detta. Därmed hoppas vissa kommandon över.

Lösningen skulle alltså kunna vara att implementera någon form av flödeshantering. Så fort ett kommando känns igen signalerar man till FT232RL att inte skicka mera data. Jag hoppas nu på att FT232 vidarebefordrar detta till PC:n som i sin tur väntar med att skicka mer data till FT232. När exekveringen av kommandot är klart signalerar jag att jag nu är redo att acceptera flera bytes och kommunikationen fortsätter. Det är detta jag vill uppnå d.v.s. att det inte spelar någon roll om datorn skickar ett kommando, flera kommandon eller hur lång tid det tar att utföra ett kommando.

[Swech]

Du bör ju ha 2 buffertar som du växlar mellan
Så fort du tagit emot ett kommando från PCn så växlar du buffertpekare, interruptrutinen
trycker in de nya tecknen i buffert nr 2 och AVR avkodar kommandot "i lugn och ro"
Så växlar du igen vid nästa kommando

Swech

[bearing]

Problemet är väl att minnet i AVR:en är begränsat så att bufferten inte kan vara hur stor som helst. Han använder (som jag förstår) RX-interrupt som fyller AVR-bufferten tills den är full. Men jag kan ju ha fel.

Är det bufferten i AVR:en som är för liten, eller bufferten i FT232?

Har du provat om CTS-signal hjälper?
Databladet för FT232 borde väl beskriva hur den ska användas.