Frekvensavvikelse på klocka vid synkron överföring

[LHelge]

Är det någon som har erfarenhet av att köra synkron seriell kommunikation utan extern klockkristall. I teorin borde det ju fungera kanon, men hur är det i praktiken?.

Mer specifikt är det i det här fallet ett antal STM32F3xx som skall vara I2C-slavar. Hade varit bra om det gick att använda 8 MHz HSI för att spara lite yta på kortet.

[Nerre]

I2C har ju en separat tåt för klocka, då ska väl inte klockfrekvensen spela nån roll alls?

Jag tycker begreppen synkron och asynkron vid datakommunikation är lite för diffusa, även en asynkron serieöverföring är ju beroende av en hyfsat bra klocka, skillnaden är att vid asynkron kommunikation så synkar man per tecken medans man vid synkron datakommunikation synkar per datapaket.

Så som jag förstått synkron datakommunikation (d.v.s. utan en särskilt tåt för klocka) så använder man ju särskilda start/stopp-sekvenser som används för att synka in mottagarens klocka med sändarens (ungefär som PLL-syntes). Så den absoluta klockfrekvensen behöver då inte vara särskilt exakt, det enda viktiga är att den inte varierar för mycket under sändningen av ett paket.

[sodjan]

Den stora vinsten med det som traditionellt kallas "synkron" överföring
är att man utnyttjar tillgängliga "bitar" effektivare. Det finns inga start-
och stoppbitar för varje överförd byte. En byte tar 8 bitar "på linjen"
istället för 10 (med en start- och en stoppbit).

[LHelge]

Kan hända att det är jag som har dålig koll, hur som helst var jag otydlig. Det jag menar med synkron överföring är att man har en separat tråd för klocka, t ex I2C, SPI och liknande. Medan asynkron synkroniserar på flanker på en startbit (t ex RS-232) eller på varje flank (t ex CAN) men har ingen separat tråd för klocka.

I teorin borde ju en frontend för I2C latcha värdet på datatråden vid en stigande/fallande flank på klocktråden som klockas av den som är master på bussen. Då spelar det väldigt liten roll om systemklockan driver iväg på en av slavnoderna. Det jag undrar är om det faktiskt fungerar så även i praktiken på en hyffsat modern microkontroller. Vad vet jag, det kanske är så stor skillnad mellan processorns klockfrekvens (72 MHz) och datatakten på I2C (400 kHz) så det inte spelar någon roll om I2C-modulens datalatch klockas både med systemklocka och I2C-klocka.

[sodjan]

Ja, begreppen asynkron/synkron är inte helt tydliga och de har
nog även glidit i betydelse över åren.

Jag tänker mest på protokoll som IBM SNA/SDLC. Men visst
I2C och SPI kallas också för synkrona protokoll...

[TomasL]

När det gäller SPI och I2C så är det mastern som driver klockan, så det spelar ingen roll om den vandrar i frekvens.

[Nerre]

En byte tar 8 bitar "på linjen" istället för 10 (med en start- och en stoppbit).

Man har lite overhead med synkron överföring också (man har ju start-, stopp och inklämda synk-paket), men den är inte lika stor. Så att det är 8 bitar per byte är avrundat, det ligger antagligen runt 8,05 bitar per byte eller nåt sånt (om man inte köra jättestora paket).

Både ethernet och USB är väl synkrona protokoll?

[LHelge]

När det gäller SPI och I2C så är det mastern som driver klockan, så det spelar ingen roll om den vandrar i frekvens.

I teorin är det så, och det var jag fullt medveten om redan innan, min fundering var om det också stämmer i praktiken. Någon som prövat?

Ytterligare något som talar för att det skulle fungera är att många enheter verkar ha stöd för något som kallas clock stretching där man medvetet låter klockan driva hos en I2C slav som tvingar SCL-ledaren låg tills den klarat av beräkningar, mätningar eller vad det nu är den håller på med.

...Både ethernet och USB är väl synkrona protokoll?

Inte enligt mitt sätt att se på det, men jag kan ha fel.

[TomasL]

När det gäller USB så vet jag inte, men ethernet är klockan inbäddad i paketen.

[lillahuset]

Med I2C och SPI kan du dribbla med klockan i stort sett som du vill bara du tar hänsyn till tsu och th.

Ethernet och USB är synkrona protokoll. Man utvinner en klocka ur dataströmmen. Jag vet inte exakt hur det går till men antar att det är något liknande manchesterkodning.
https://en.wikipedia.org/wiki/Manchester_code

Edit: Och där hade jag fel när det gäller USB. Så kan det gå när man tar något för givet.

[Nerre]

Nja, en ethernet-frame inleds med 56 bitar preamble, som används för att synka klockan. Det är samma teknisk som används i t.ex. SDLC.

Och även USB verkar använda sig av synk-ord (fast det är bara en byte där).