OldComp.cz

S CPU i8080@2MHz je při 115 kilobitech/sec skutečná přenosová rychlost 6-7 kilobajtů/sec, ale je to sníženo i tím, že během přenosu testuji i klávesnici kvůli možnosti přerušení přenosu stiskem tlačítka STOP nebo jeho ekvivalentem. Bez toho bych se dostal cca na 9kB/s. Když zapnu turbo CPU 4MHz, a je jedno na jakém procesoru, dostal jsem se tuším na 11kB/s i s tím průběžným testováním klávesnice.

Navíc kvůli občasným "únikům" bajtů na straně vysílače, kdy nestačí včas zareagovat na DTR, testuji nejprve, zda je UŹ další bajt v přijímacím registru UARTu DSM-1 ještě před povolením vysílání a až když zjistím, že není, pak proběhne fáze DTR ON - čekání na příjem - DTR OFF - načtení bajtu. S každou takovou kudrlinkou se ta přijímací smyčka prodlužuje ale realita si řekla, co tam musím testovat.

Takže už na frekvenci CPU 4MHz to smysl má, těch 115kb/s. A určitě by další urychlení přenosu přinesl i přechod na 230kb/s, jakkoliv limitně se další přínos blíží nule, o tom není pochyb. Pak by to mělo smysl zase až s dalším zvýšením taktu CPU, kdy na kartě JPR-1V se dá jet do 10MHz a s kartou JPR-1X do 8MHz.

Vše výše uvedené platí pro použitou, celkem univerzální přenosovou rutinu s průběžným dekódováním IntelHEX formátu. Troufám si odhadnout, že čistý binární přenos s optimalizovaným přijímacím algoritmem by i stařičký i8080@2MHz ocenil na přenosové rychlosti 500kb/s, tedy že by tam ještě byl viditelný nějaký ten přínos oproti 230kb/s.

Dnešní pokusy s komunikační rychlostí HD3-6402R-9 odhalily to, co je naznačeno v některých verzích katalogových listů tohoto obvodu. Ač má R-ková verze garantovanou frekvenci hodin "pouze" 2MHz (komunikační rychlost 125kBaud), má tento obvod značnou rezervu pro případ kolísání napájecího napětí a rozptyl pracovních teplot. Pokud se však držím na 25°C a +5V±5%, obvody, koupené jako použité, jedou bezpečně na 230kBaud. S obvody 6402R-9 značené Intersil a deklarovanými jako nové jsem se dostal na 460kBaud. To vše s přijímači SN75189 od Texas Instrument. Ty by měly jet údajně do 1MBitu. Abych se dostal na zmíněných 460kBaud, musel jsem ještě na desce DSM-1V vyměnit oscilátor pro generování přenosových rychlostí. Místo 3,6864MHz jsem dal 14,7456MHz, což je garantované maximum pro použité děličky 74HC40103. A taky jsem musel pustit CPU na desce JPR-1X na 8MHz, protože mám pomalý obslužný program a při 2MHz mi utíkaly bajty mimo handshake.

A to vše je překonáno faktem, že z UtSource jsou už na cestě 4x rychlejší verze UARTů (HD3-6402B-9), které by nominálně měly jet do 500kBaud. Tak na jejich skutečnou rychlost jsem tedy opravdu zvědavý...

Obvody HD3-6402B-9 (tam je důležité to písmeno B v označení) se mi podařilo v SAPI na desce DSM-1V rozchodit až na 921600 Baud. ALE:

Na procesorové desce JPR-1V s CPU Z80 to chce frekvenci určitě větší než 5MHz, na té to nejede. Na 10MHz to už jede na tom megabitu spolehlivě. Výpočtově není důvod k tak velké požadované frekvenci CPU ale je to tak. Při těchto limitních komunikačních rychlostech, které jsou limitní i pro samotný USB/UART převodník, už asi ten handshaking začíná mít své mouchy.

Na procesorové desce JPR-1X s CPU 8085 se mi ten megabit nerozjel vůbec, dokonce ani s 8MHz taktem.

Pořád ovšem platí, že jsem to zkoušel na celkem univerzální přijímací softwarové proceduře s průběžným překladem dat z formátu IntelHex, protože bez toho by to stejně nemělo smysl. Surová bajtová rychlost s okamžitým ukládáním dat do buferu by to měla vyřešit a posunout komunikační rychlost směrem k vyšším hodnotám. Ale to si mohu později zkoušet v nějakých sólo programech, v MikroBIOSu pro to není místo.


S rychlostí 460800 Baud už je to mnohem lepší, JPR-1V to po optimalizaci software zvládá spolehlivě s procesorem Z80/4MHz. JPR-1X s procesorem 8085/4MHz to sice nedává, ale tam jsem ještě neoptimalizoval ten komunikační program. Předpoklad je, že to pojede taky.


Z výše uvedeného vyplývá, že i když ten megabit JE technicky řešitelný, z praktických důvodů s ním nebudu pro další vývoj počítat. Stejně by to na kanálu A vyžadovalo úpravu v podobě vypuštění děličky pro generování přenosových rychlostí. Alespoň tedy není důvod vyrábět modifikaci desky DSM-1V nativně pro 1MBit. Spíše se zaměřím na to, aby MikroBIOS (nově MikroMON pro odlišení od předchozích verzí) zvládal těch 460800 Baud. I tak to bude výzva.


Aktuální stav je takový, že desku DSM-1V rev. 1.1 jsem osadil a jede. Po malých změnách vůči rev. 1.0 se tam zřejmě nedostaly nové chyby a tak zbývá už jen proměřit takové ty formální věci jako prodlužovače impulsů RESET a podobně. Potisk desky DSM-1V i dokumentace uvádí i v revizi 1.1 jako maximální komunikační frekvenci 115200 Baudů pro oscilátor 3,6864MHz. To je z toho důvodu, že by v té desce měly jet téměř všechny klony 6402 mimo vyložených šrotů. Použití těch rychlých UARTů 0,5MBit ve spojení se čtyřnásobnou frekvencí oscilátoru (14,7456MHz) sice umožní chod desky až do zmíněného 0,5MBitu, ovšem s ohledem na osmibitové děličky komunikačních rychlostí se minimální komunikační rychlost zvedne na 1200 Baudů. Ve schématu chybí 3. list, protože je téměř identický s listem č. 2.

DSM-1V má jednu záludnost co mi kazí plány na náhradu dvou DSM-1 za jednu DSM-1V. A to že na prodloužení signálu místo MKO je použit signál /MR. Čistě portové desky mám v rozšiřující jednotce JPN-1, s úpravou tak aby byla adresovaná jako porty tj. místo DPB-1 mám DPR-1. Chápu Liborovu nechuť k analogovému smetí (ty MKO taky nemusím) ale v daném případě radši to analogové smetí a ponechat desku čistě portovou. Osobně to s tím použití /MR se mi nelíbí ….

_________________
Ne všichni jsme měli z češtiny za jedna, aneb jsem dyslektik a dysgrafik.

http://www.sapi.cz/

Samozřejmě, že prodloužení signálů je možné řešit jinak. Ale takovou desku už jednu máme - originální DSM-1. Kdybych chtěl mít takovou desku v systému, tak ji prostě okopíruji jedna ku jedné. Ale já nechci. Pro mne je větší prioritou technická a estetická čistota než chod na portových sběrnicích. U ZDR-1V to šlo bez kompromisu, tak proč ne. Tady to bez kompromisů nešlo.

Vše začíná u toho, jak pomalý sběrnicový interface mají ty UARTy 6402 i v té nejrychlejší podobě. Hlavně požadované přesahy dat za zápisovým pulsem a délka nulovacího impulsu. I když ty přesahy dat jsou, pravda, vynuceny koncepcí jedné společné datové sběrnice. Ale mít na desce čtyři datové sběrnice pro dva UARTy mi přišlo šílené. Použití MKO jsem vyloučil, takže zbyly jen klopné obvody a volba byla jen v tom, kterými signály je řídit. Ne že bych nezkoušel něco jiného než zmíněný signál /MR. U rev. 1.0 jsem to zkoušel se signálem STSTB, který je rovněž pravidelný a synchronní s chodem CPU. Bohužel je tam jedna záludnost, který vyplývá z nešťastného časování 8228 viz dále (prostě se někdy nemusí ukončit SELECT desky, když program poběží na nevhodných adresách).

Čekací stavy jsou jeden velký problém, protože musíme počítat s CPU i8080. Když i8080 zapisuje do paměti či portu, tak se standardním a dominantním řadičem 8228 přichází signál zápisu velice pozdě. Proto například AND-1Z generuje požadavek WAIT už od platné adresy a ne od signálů MR/MW, a to i za cenu falešných a zbytečných WAIT stavů. A on si málokdo asi bude pořizovat i8080 s řadičem 8238 místo 8228. Na to se nejde spolehnout. Ale ano, zvažoval jsem i čekací stavy a zvolil jsem to co jsem nakonec zvolil. I za tu cenu, že potřebuji signál MR.

Budu-li dělat nějakou další desku tohoto typu, budu myslet na to, že by měla jet v portové sběrnici. Pokud to jen trochu půjde a nebude to na úkor jiných vlastností, určitě se o to pokusím.

EDIT: Mimochodem, při 1MBitu byla reálná přenosová rychlost cca 31,5kByte/sec, pokud se lze spolehnout na údaj, který zobrazuje SW terminál Tera Term.

Kdybys měl zájem si to otestovat, tak 8238 bych měl...

_________________
na co myslím, když jsem na fóru: Je děsivé vidět jak kompletně vymyšlené pohádky bez opory v realitě dovedou tolik lákat majitele nadřazených mozků, vidících za opony moci a pod závoje intrik.

Díky za nabídku. Ale asi není důvod zkoušet něco, co stejně nikdo druhý neudělá. A ty vyvinuté karty už taky nikdo nezmění.

Zrovna zkouším přinutit i8080A/i8085 na 2MHz aby obsluhoval UART na 460 kBaud. A asi jsem našel cestu. Je poněkud kostrbatá ale zdá se, že to půjde. Takt zmíněných CPU víceméně lineárně omezuje shora bajtovou přenosovou rychlost. Prozatím jsem dosáhl těchto výkonů:

na 2MHz je to cca 8kByte/sec (od 115200 Baudů nahoru se to už nemění!)
na 4MHz je to cca 16kByte/sec
na 8MHz je to cca 32kByte/sec

Důležité je, že jsem asi našel ten problém. Zcela očekávaně to byl okamžik, kdy jsem povolil příjem a čekal na příjem bajtu. Když jsem nechal signál DTR jen pár taktů déle, došlo k přijetí dalšího znaku UARTem a přepisu toho předposledního. Teď ještě vrátit zpět všechny ostatní věci kolem a neztratit moc na rychlosti. Až budu mít dost sesbíraných údajů o poměru takt CPU versus maximální smysluplná komunikační rychlost, hodil bych to do nějaké přehledné tabulky.

Víkendové bádání nad přenosovými rychlostmi UARTu ve vztahu k rychlosti CPU jsem uzavřel zjištěním, že 115,2kBaud představuje všeobecný kompromis mezi rychlostí dostupných UARTů, reakční dobou obslužného SW na straně i8080/i8085/Z80 a v neposlední řadě i schopností těch kabelových převodníků. Takže tuto rychlost považuji za jmenovitou. Než se přijde na něco jiného

Samozřejmě platí, co již bylo řečeno dříve, že maximální dostupná komunikační rychlost jde až 1MBaud podle nastavení generátoru komunikační rychlosti na kartě DSM-1V a rychlosti CPU na kartě JPR-1x v kombinaci s efektivitou ovládacího SW.

A ještě jedno důležité upozornění pro ty, co by chtěli použít některé části zapojení DSM-1V či osadit DSM-1V zmíněným oscilátorem 14,7456MHz.

Děličky pro generování taktovací frekvence pro obvody UART na desce DSM-1V jsou synchronní, proto produkují velice úzké impulsy na výstupu a nikoliv signál se střídou 1:1. Proto použití oscilátoru 14,7456MHz a nastavení dělicího poměru 1:4 NENÍ obrazně řečeno totéž jako použití oscilátoru 3,6864MHz a nastavení dělicího poměru 1:1. Prostě platí, že pro všechny UARTy 6402, které jedou pouze do 115,2kBaud (rychlostní kategorie "2MHz") MUSÍ být použit oscilátor 3,6864MHz nebo pomalejší. Takže pokud si někdo není jistý následky, je dobré osadit DSM-1V tak, jak je navržena.

Někdy člověk při úklidu projektu ze stolu zjistí, že ještě není konec. Stejně tak i u DSM-1V.

EC1045.01 a Martin8bity mě ještě nakopli k nějakým praktickým změnám. Takže i když rev. 1.1 už slouží v mé sestavě, tak v záloze vzniká rev. 1.2, která možná bude později uvolněna. Z funkčních věcí je ve hře náhrada digitálních prodlužovačů impulsů, tak aby mohla karta fungovat na specifické sběrnici IOB-1 bez signálů A15:A8 (jejich absence nám nevadí) ale i bez signálů /MW a /MR (a zrovna tento karta DSM-1V rev. 1.1 potřebuje). Pak mi ještě Martin doporučil SN74LVC1G80DBVR na pozici asynchronní děličky dvěma ve funkci symetrizátoru hodin pro UART. Je to elegantní a velice lákavé a po posledních pokusech s programovým vybavením je to horký kandidát na doplnění na desku.

K tomu programovému vybavení. Nakonec jsem pro účely přenosu víceméně ohraničeného souvislého bloku (=přenos souboru) zvolil taktiku, kdy na začátku přenosu povolím DTR nebo RTS a v letmém režimu stihne i8080 na 2MHz odchytávat data bez signalizace handshakeovými signály. IntelHex formát stihne i8080 dekódovat na již zmíněných 115kBaudech a binární soubory stihne ta samá i8080 přijímat na 230kBaudech. Tady už se bavíme o finální verzi BIOSu, nikoliv o dílčích pokusech. A protože nikdo ničím nebrzdí jmenovitou bitovou přenosovou rychlost, tak ta bajtová přenosová rychlost je přesně desetinová, bez ohledu na takt CPU, protože na jeden bajt se přenáší START bit, 8 datových bitů a jeden STOP bit. A protože osazení těch děliček SN74LVC1G80DBVR sníží maximální dostupnou rychlost UARTu právě na 230kBaud, tak se asi na tuto společnou metu posune i technický limit budoucí verze DSM-1V rev. 1.2.

EDIT: Někde jsem minule chybně uvedl fakt, že rozptyl nastavení komunikačních rychlostí může být 1200Baud až 230kBaud. Skutečnost je ovšem taková, že při zvýšení maximální komunikační rychlosti na 230kBaud nám ta minimální dostupná rychlost poskočí až na 1800Baud, takže z dostupných voleb vypadne "tradiční" hodnota 1200Baud... Ale to už se začínáme točit kolem drobného dolaďování finální specifikace.