Raspberry Pi Uart - tijdsverschil tussen RX en TX

Goedemiddag,

Ik zit al enkele dagen te kl*ten (sorry ander woord heb ik er niet voor) met een seriële verbinding tussen Raspberry Pi en een Pic 18F2420. De raspi zend een byte en zodra deze door de pic is ontvangen zend deze een acknowledge byte terug. Deze aknowledge zit direct achter de ontvangen byte (bevestigd via scoop, echter telkens zit ik met timings-fouten.

Nu heb ik een loopback verbinding gemaakt op mijn raspi tussen Rx en Tx en daar mijn scoop ook eens aan gehangen en nu blijkt dat het verschil hiertussen 8 ms is. (Dus de raspi zend zelf een byte en pas na 6 ms is dit weer in zijn ontvangsbuffer van de raspi terug te vinden. Op 4800 bd hoort dit in mijn ogen max +/-2,3 ms te zijn, en zelfs daar twijfel ik over. De pic ontvangt zijn eigen byte wel direct.)

Hierdoor doe ik totaal 10 ms om een byte te verzenden. 5 keer zoveel als de tijd nodig voor een byte en daarom voor mij veel te lang. (Als ik overigens de baudrate verhoog gaat het delay in zelfde orde mee.) Nu vraag ik mij af: is dit normaal voor een raspi/Linux-algemeen (dus een software probleem) of moet ik het in de (mijn)hardware zoeken ? (Raspi stuk?)

(Google is mijn vriend, maar over timing vind ik niet zo heel veel.)

Ik gok dat die tijd ergens in linux je raspberry pi software verbruikt word.

Als dat een probleem is moet je iets anders gebruiken dan linux.
Of je protocol anders in elkaar zetten (100 bytes versturen voordat je framboos de eerste ack gaat bekijken, de framboos heeft geheugen zat)

Als je dingen op de ms precies wil laten gebeuren dan moet je dat door die pic laten doen.

Met een heel Operating System ertussen valt er inderdaad weinig meer van de timing te zeggen...

Kun je niet de ontvangstbuffer uitschakelen en rechtstreeks met de UART communiceren?

Ben weer een stapje verder; het zit inderdaad in Linux zoals jullie al dachten. Als ik de loopback direct naar een input pin verbind, en deze weer een output pin laat aansturen, heb ik hem direct. (Zit al weer in gedachten met een pic welke dan maar voor het ack signaal moet zorgen of een softwarebuffer maken ofzo.... )

Helaas zal ik hier toch wat op moeten verzinnen. Het protocol bestaat nu eenmaal uit enkele bytes welke bevestigd moeten worden dus meer bytes opsparen werkt niet. Ook heb ik de print al gemaakt protocol ontwikkeld e.d.

@Franzki: Hier zat ik zelf ook al aan te denken, maar als ik zoek op internet kom ik alleen maar termio tegen. Heb je enig idee hoe ik dat kan doen ?

Zo'n serieele terugmelding steekt toch niet op wat milliseconden?
Gewoon het communicatieprotocol wat steviger in elkaar timmeren...

Dit is geen Linux-probleem.
Hooguit van een verkeerd geconfigureerd proces of een compleet fout opgezet systeem.

Vraag anders op een forum waar Linux-kennis beschikbaar is, want als je er geen verstand van hebt trek je al gauw foute conclusies.

Ik heb gisteravond nog een website gevonden waaruit blijkt dat dit een eigenschap is van termios. Deze bestaat uit twee buffers. De data komt binnen in de eerste buffer, termios wacht 4 tekentijden af voor meer data en kopieert het daarna naar de tweede alwaar het uitgelezen wordt. Je kan dus altijd pas na 4 tekens uitlezen. Dit is uit te schakelen, maar het was gisteravond te laat om te ontdekken hoe.

Anyway, dit is geen electronica probleem meer dus wat mij betreft is de kous hier af. In elk geval bedankt voor het meedenken.

JA, termios is niet het meest handige stuk interfacing. Om het zachtjes uit te drukken :)

Vaak kom ik op internet een topic met probleem tegen waar ik zelf ook tegenaan loop en vervolgens is er geen oplossing. Dit vind ik zelf altijd heel vervelend dus vandaar nog een kleine update.

In ieder geval: Het is mij gelukt. Verschil tussen Tx en Rx: -100 micro seconde.(De verzonden byte is eerder binnen dan dat de verzender klaar is met verzenden. Dit komt omdat de mini uart de stop-bit negeert.) Dit heb ik behaald door het FIFO geheugen van de Uart direct aan te spreken. Hoe je dat kan doen staat heel mooi uitgelegd op http://www.pieter-jan.com/node/15. Dit gaat echter om de GPIO maar met deze handleiding en de datasheet van de Raspi (welke Pieter-Jan ook levert) kan je dit ombouwen naar de uart. Let wel op: Er zitten twee uarts in de Raspi. De miniuart wordt aangesproken via de alternatieve functie 5 en de echte uart via de alternative functie 0. Dit heeft mij 4 uur gekost om daar achter te komen. Maar toen ik dat eenmaal door had werkte het vrij snel.