4-bit Seriell överföring?

[4kTRB]

Du har alltså en state-mashine som ger ASYNKRON data ut, 4 databit.
I en SYNKRON kommer det båda data och klocka.

Nåväl, den är ju enkel att expandera till 8 bit...

Bitströmen ut är vad jag ser synkron med klockan.
En mottagare får synkronisera med startbiten skulle jag tro.

[Nerre]

Du menar om G ändras?

Nej, jag menar om D0-D3 ändras mitt under pågående överföring.

[Icecap]

Normalt använder man ett 8 bit shiftregister, parallell in, seriell ut till detta, då riskerar man inte att data ändras under tiden sändning sker.

Asynkron/synkron avgörs inte av hur data skickas men om de följs av en klocka eller inte.

[4kTRB]

Du menar om G ändras?

Nej, jag menar om D0-D3 ändras mitt under pågående överföring.

Ok ja detta är en enklare grej mer som övning.
Kanske kan duga i en tillämpning för Trygghetslarm?

[Castor]

Jobbar du åt Tunstall? Där finns förbättringspotential.

[Nerre]

Normalt använder man ett 8 bit shiftregister, parallell in, seriell ut till detta, då riskerar man inte att data ändras under tiden sändning sker.

Hur löser man start- och stoppbitar om man bara har ett 8-bitars skiftregister? Är det inte enklare att köra ett 10-bitars så att man även kan få med start- och stoppbit utan att behöva hantera dem med extra logik?

[Castor]

Ett sätt är att sätta startbitsnivå, vänta 1 bittid shifta från registret samtidigt som man på sista platsen shiftar in en stoppbit som då blir bit 10. Med 14 eller 16 pins kapslar finns kanske inte plats för 10 bitars parallell-laddning och man måste ju ända hålla reda på antal shiftade bitar på något sätt.

[4kTRB]

Lär mig lite nytt hela tiden när jag håller på med det här.
Modifierade ASM-diagrammet och drog in på en grind men lade å andra sidan till en vippa för Ready.
Själva kontrollogiken-boxen blev densamma.
Men är inte säker på om det blir bättre då T-utgångarna är klockade. Hur som helst går det lösa på fler sätt.

ASM_Serial_A.png

ASM_Serial_B.jpg

LogiSim_ASM_Serial_002.png

[4kTRB]

LCD verkar kunna gå att styra med 4 bitars mod. Fast hur det ska utföras vet jag inte, det måste ju till R/W, Enable osv.

[Nerre]

Ett sätt är att sätta startbitsnivå, vänta 1 bittid shifta från registret samtidigt som man på sista platsen shiftar in en stoppbit som då blir bit 10. Med 14 eller 16 pins kapslar finns kanske inte plats för 10 bitars parallell-laddning och man måste ju ända hålla reda på antal shiftade bitar på något sätt.

Det är väl därför man istället oftast använder en färdig UART.

[bit96]

Start- och stopp-bit behöver nödvändigtvis inte vara med i själva shift-registret.

Vid normal asynkron överföring ligger linjen i 'viloläge' när inget sänds, vilket motsvarar en stoppbits värde, t.ex. '1'.
Vid sändningsstart dras linjen till '0' en bitlängd d.v.s. en startbit.
Direkt därefter kommer önskat antal databitar.
Och direkt därefter kommer en (eller två) stoppbit/ar, '1', som kan vara 'oändligt' lång/a, man drar alltså linjen till viloläge igen.

Men kommer nästa tecken direkt så måste stopp-biten/bitarna i alla fall vara en/två bitlängd/er lång/a.
Så i alla fall stopp-bit/ar måste ändå hanteras utanför shift-registret då den alltså motsvarar 'viloläge', som måste vara 'oändligt' stabilt, annars 'lurar' man igång mottagaren.
Mottagaren synkas alltså igång på startbiten och förväntas därefter hålla timingen rätt tills stoppp-biten anländer (normalt inom ca 10-12 bitlängds-tider)

Sen kan man lägg in paritet-bit om man vill, men det kan i detta fall, överföringsmässigt, ses som utökning av antal databitar.

[Nerre]

Nej, visst behöver de inte, men som jag skrev är det enklare att få med dem genom att köra ett 10-bitars register än att hantera med extern logik.

Den nuvarande lösningen använder ju ett 8-bitars för att få med start- och stoppbit.