Svenska ElektronikForumet

För mig uppstår liknande problem eftersom jag struntat i hårdvaruhandskakning. Men jag har ett terminalprogram i min PC där jag kan ange tid i millisekunder mellan varje tecken som ska skickas. Så jag kan skicka en hel fil och anpassa hastigheten så att processorn hänger med. Det vore väl en enkel lösning för dig?

Swech: Med två buffertar som jag växlar mellan kan jag förmodligen få det hela att fungera bättre än vad det gör idag, men dock inte så pass bra att jag "aldrig" missar något data.

bearing: Du har helt rätt. Minnet är starkt begränsat och detta gäller ju faktiskt både AVR och FT232. Det jag hoppas på är att man med hjälp av flödeskontrollsignalerna kan replikera tillbaka i kedjan och därmed få FT232 drivrutinen på PC-sidan att börja buffra data istället. På detta sätt skulle man då få en FIFO vars storlek egentligen endast begränsas av PC:ns hårdvara t.ex. tillgängligt RAM-minne. Databladet beskriver inte flödeskontrollsignalerna i klartext och därför misstänker jag att de fungerar enligt någon standard för hur dessa signaler ska fungera. CTS signalen är något jag tror kan vara lösningen, har dock inte testat detta ännu, men kommer givetvis skriva det här när jag har testat. Jag drog tyvärr inte ut dessa pinnar på kretskortet så jag kan därför inte testa detta innan jag beställt eller tillverkat ett nytt kort.

jesse: Som jag tidigare har nämnt vill jag inte begränsa mig till något speciellt terminalprogram.

Jag förstår fortfarande inte hur två buffertar skulle lösa problemet. Bufferten måste så klart vara en ringbuffert. Om den är en ringbuffert ser jag inte fördelen med två buffertar.

Först får man sätta kraven lite rimligt och anpassa.
Du bör/måste ha ett tecken som avslutar ett kommando t.ex. CR
Har du även ett tecken för att indikera början av ett kommando blir det ännu bättre t.ex. $ @ !

Ett kommando bör inte vara oändligt långt.

SET LED1
WAIT INPUT2
CLR LED1

Bör lämpligtvis vara
SL1
Wi2
CL1

Finns ingen anledning att skicka SET LED1... om man inte skall skicka kommando manuellt....
Kör man en maximal meddelande längd på 16 tecken och med 2 buffertar så går det åt 32+ säg 8 till då...

Fördelen med 2 buffertar jämfört med ringbuffert är att det är lättare att hålla reda på längden på kommandot
och att dubbelbuffern aldrig kan skriva över ett redan infångat meddelande. Ringbufferten kan ju om sluttecknet missas
fortsätta fylla på in i föregående kommando...

Bufferten tillåts inte att fyllas på längre än max 16.
Hittas inget CR så är det ett skräpkommando... ett kommando är säkerligen förlorat
Hittas ett starttecken så nollställ och börja om direkt... ett kommando är säkerligen förlorat


Swech

Varför skulle handskakningen med CTS (Clear to Send) inte fungera genom alla lager (radiolänk, FT232 osv...)? Om grejerna fungerar och stödjer CTS så bör det inte uppstå något fel. Det är väl värt att testa i alla fall.

Givetvis vidarbefodras inte CTS signalen direkt genom alla länkar, utan varje länk signalerar ju när dess egen buffert blir full. När AVR-en vill ha en paus så sätt CTS låg. Då lagrar radiolänken data i sin buffert till s den blir full, då slutar den att sända och sätter CTS låg på andra sidan. Där får FT232 signalen (om man programmerat en ingång att vara CTS pinne). Efter ett tag blir dess buffert full, och då signalerar den en virtuell CTS signal på den virtuella USB serieporten vilket vidarebefordras till det lager som hanterar serieportar viken då stoppar sin sändning. Då börjar serieportsbufferten (som antagligen hanteras av det bibliotek som hör till just det OS'et eller programspråket, t.ex en DLL eller Javax.comm eller nåt annat) att fyllas tills dess angivna maxgräns uppnåtts. Då stoppas programmet som sänder data, alternativt uppstår ett felmeddelande, beroende på konfigurering (antar jag). Enklare radiolänkar har ju varken buffert eller handskakning - då funkar det inte. I så fall måste du i programvaran skicka data i mindre paket med checksumma och efter varje paket skicka ett "ok" innan programmet antingen försöker sända om datan eller fortsätter med nästa paket.