Stari programatorji za LPT port na novih strojih - kako ?

[KlagenFurtelj]

Rad bi usposobil stari Xeltek programator ( ki sicer dela) na dokaj moderni Linux mašini, ki jasno nima LPT porta.
Ta uproablja tako DOS kot WIn programje, jaz sem za poenostavitev problema izbral DOS in se ga namenil pognativ DOSEMU okolju.

Zato sem ga probal LPT dodati v obliki PCIe/M.2 kartice ( 2x COM+ 1*LPT).

Stvar je zaznana a po zajebancijah z DOSEMU sem skoraj obupal.

Rešitev: instaliral fork - DOSEMU2.

Ta dela.
Po začetnem navdušenju in odzivu programatorja, sem opazil, da pa sedaj določeni alogritmi za določen čiperaj ne delajo ( recimo i2C in SPI serijski EEPROMI tipa 24C64 in 93C54).

Domnevam da zato, ker so bolj časovno občutljivi.

Te I/O kartice namreč visijo na PCIe portu, kar pomeni, da je za vsak flip bita na emuliranem 8255 čipu treba poslati PCIe podatkovni paket, kar domenvam ne traja vedno enako dolgo.

KAko tozadevne probleme rešujete sami ?
S kakim predpotopnim PCjem ?
Pa laufa Linux na taki mašini v meri, da se da ta PC povezati v mrežo ?

Kaj je najnovejša generacija, ki ima na plati izveden LPT in je ta na CPU povezan brez vmesnega pretakanja preko SPI porta (kot so razni SuperIO čipi) ?
Ali pa mogoče problem ni v tem ampak nekje drugje ?

Aja, še to, opaazil sem,d a po novem ta I/O kartica ni mapirana na starih I/O portih, kot je to bilo prej v času 3/486tk, ampak samo na spominskih lokacijah - na "moderen" način.
Ne spomnim se, kako sem prišel mimo tega - je to v splošnem odvisno od Linux kernela ali od kartice ?

[VolkD]

Programatorji, ki bazirajo na LPT portih zanesljivo delajo do 386 računalnikih, delajo tudi na nekaterih 486 računalnikih, a se vedno najde tudi kakšen tak 486, ki ti v najbolj kritičnem trenutki zagreni življenje. Na pentuim računalnikih je podobno, le da se da vedno naleteti na takega, ki dela, a večino njih ne dela.
Pod dela/ne dela mislim na povsem vse funkcije programatorjev, tudi tiste časovno kritične.
Igranje z čipi kot so FT245 (ftdi) in podobni, daje precej nezanesljive rezulztate. Če so hitrosti programiranja nizke, se včasih celo izide praviloma pa to ni rešitev.

Ostane pač dejstvo, da so skupaj s starimi računalniki zastareli tudi programatorji. Rešitev je običajno nabava novega sodobnega, ki praviloma deluje na USB. Manj običajna rešitev pa je samogradnja. Glede na tvoje napredno razmišljanje, slednjo rešitev pričakujem prav od tebe ( verjetno bo natečaj za samogradnje).

[KlagenFurtelj]

Ostane pač dejstvo, da so skupaj s starimi računalniki zastareli tudi programatorji. Rešitev je običajno nabava novega sodobnega, ki praviloma deluje na USB. Manj običajna rešitev pa je samogradnja. Glede na tvoje napredno razmišljanje, slednjo rešitev pričakujem prav od tebe ( verjetno bo natečaj za samogradnje).

Sem imel veliko idej na to temo, a na žalost so moje ideje in usta pogosto prehitevala delo rok.
No, ko sem RES rabil kaj sprogramirat, sem scumpral tudi "programator" za dani čip.

A z univerzalnim programatorjem so problemi:

Novi modeli, tudi tisti poceni, imajo možnost analognega krmiljenja vsakega pina posebej. Tsti dražji ( Conitec GALEP-5, BAtronix, Dataman ipd) iajo custom čip, ki ima DA/pretvornike, driverje, stikala, A/D pretvornike ipd. Cenejši, kot je Xgecu T4(/56/76 imajo pa goro mosfetov in level shifterje. Prvo je praktično nemogoče v DIY, drugo je zelo nerodno

Daleč največ dela ni s hardverjem, ampak s softverjem - točneje z neskončnim dodajnjem novih algoritmov, preverbo obsotječih, ukvarjanjem s "posebnostmi" posameznih serij ipd ipd

Masa algoritmov je tajnih. Tako imajo mnogi programatorji recimo podporo za GAL čipovje, a samo nekateri tudi podporo za PALCE (= Lattice/AMD verzija funkcionalno istega GAL-a, ki pa ima svojo programirno proceduro.

V bistvu je zadnji v listi tudi razlog zakaj se zaj* z danim Xeltekom - je poceni ime v "požegnanem" segmentu proizvajalcev, ki ima podporo za mnoge "tajne" algoritme.

Je pa na spletu odprtokodni projekt krmiljenje za slavni ultrapoceni serijo, ki jo je Xgecu ugrabil (Kitajci, jasno ) in nadgradil v T48/T56/T76 in nekaj algoritmi.
Če kdo zgrunta vse skrivnosti tega, je mogoče brezveze delati na svojem programatorju.
Tista škatlica je zmogljiva in poceni.

Če postane programje odprtokodno in enostavno posodobljivo, je delavski razred zmagal...

[VolkD]

Sem imel veliko idej na to temo, a na žalost so moje ideje in usta pogosto prehitevala delo rok.

Že opaženo.

Če postane programje odprtokodno in enostavno posodobljivo, je delavski razred zmagal...

No nisem imel v mislih programator, ampak bolj elegantno rešitev. USB to PRINTER port vmesnik, ki bo deloval pravilno. Pravzaprav je zadeva trivialna. Vsi problemi, ki nastanejo v sodobnih računalnikih z vsemi raznoraznimi printer porti, so povezani z nedefiniranimi časi, vse pa izhaja s tega, da se s procesorjem ne da več direktno krmiliti printer portov. Rešitev je torej v tem, da odstreaniš ta problem. Potem imaš generalno na razpolago vse stare cenovno ugodne programatorje.

[KlagenFurtelj]

No nisem imel v mislih programator, ampak bolj elegantno rešitev. USB to PRINTER port vmesnik, ki bo deloval pravilno. Pravzaprav je zadeva trivialna. Vsi problemi, ki nastanejo v sodobnih računalnikih z vsemi raznoraznimi printer porti, so povezani z nedefiniranimi časi, vse pa izhaja s tega, da se s procesorjem ne da več direktno krmiliti printer portov. Rešitev je torej v tem, da odstreaniš ta problem. Potem imaš generalno na razpolago vse stare cenovno ugodne programatorje.

Ne vidim, kako bi to lahko delalo.
USB host kontroler ima svoj "vozni red" oddaje paketov, ki ga ne moreš 100% nadzorovati, sploh pa ne s tako ločljivostjo.
Tega ne mroeš, tudi če bi ti OS dovolil direktno dostop do HW.
Potem je tu problem nedetrminizma OS-a, ki šmudla procese med jedri, jih prekinja ipd.

Če bi to hotel bi moral imeti:
* poseben driver za moj "USB_LPT" port.
* na strani vmesnika pravzaprav MCU, ki bi od hosta sprejemal ukaze v smislu "postavi te pine XYZ na kombinacijo ABC v času ZXCVBN mikrosekunde".
In seveda moral bi imeti predelan QEMUs haklci, ki bi čakali,d a se kaka instrukcija dotakne enega od namiljenih LPT portov in jo prevesti v zaporedje ukazov USB-LPT pretvorniku in te poslati po USB portu.

A tu se zaplete pri sekvencah "postavi-pine ABC v času X nato pa poskeniraj pine v času Y".
Ta čas je na LPTju lahko samo nekaj mikrosekund. IIRC USB ne more garantirati tako hitrega odziva. Sploh pa ne v poljubnih "piši-beri" sekvencah.

To bi bilo lažje izvesti s FPGA-jem na PCIe portu namesto skozi USB.
S tem,d a bi količina dela presegla vsak razumen benefit.

No, USB4 lahko deluje v PCIe načinu, a najbrž nisi tega mislil, domnevam...

[VolkD]

Hint: Kaj pa če narediš na USB koncu en buffer in imaš potem svoj procesor za programiranje.

Seveda rešitev ni 100%, a z dovolj rama, dovolj dobra, da prežveči vse, kar se rabi.

[KlagenFurtelj]

Hint: Kaj pa če narediš na USB koncu en buffer in imaš potem svoj procesor za programiranje.

Seveda rešitev ni 100%, a z dovolj rama, dovolj dobra, da prežveči vse, kar se rabi.

Potem je vseeno če stari programator šutiraš v kanto.

JAz nimam v osnovi problemov s tem, a pred tem bi rad poskeniral kako stvar programira čipe, za katere algoritem ni javen.

V bistvu sem imel nekaj takega v mislih, a s FPGAjem.
A to bi rad naredil tako, da FPGA/SoC znam parcialno rekonfigurirati, po možnosti med delom.
In po možnosti tako, da se FPGA rekonfigurira sam.
Za to pa bom moral še "malo" špinače pojest.

[VolkD]

JAz nimam v osnovi problemov s tem, a pred tem bi rad poskeniral kako stvar programira čipe, za katere algoritem ni javen.

Ufff,.. dosti dela. Vprašanje je, če to res rabiš. Oziroma še bolje, koliko in/ali kolikokrat rabiš. Mogoče je bolje, da si za te redke primere sposodiš programator-

V bistvu sem imel nekaj takega v mislih, a s FPGAjem.
A to bi rad naredil tako, da FPGA/SoC znam parcialno rekonfigurirati, po možnosti med delom.
In po možnosti tako, da se FPGA rekonfigurira sam.
Za to pa bom moral še "malo" špinače pojest.

Niti ni tako hudo, kot se zdi. S FPGA-jem bo šlo seveda bolj hitro in ne bo potreben hud procesor. Ampak za rekonfiguracijo bo en mikrokontroler zraven, zagotovo precej bolj ugodna zasnova.

[KlagenFurtelj]

Niti ni tako hudo, kot se zdi. S FPGA-jem bo šlo seveda bolj hitro in ne bo potreben hud procesor. Ampak za rekonfiguracijo bo en mikrokontroler zraven, zagotovo precej bolj ugodna zasnova.

To počnejo drugi.
Ne maram "meee tooo" pristopa.
Še ena ovca v čredu.
Koneckoncev celat tista Xgecu Txx serija je ena od mnogih v tem stilu.
Zakaj bi delal svojo verzijo nečesa, kar je čisto OK narejeno ?

Stvar ima STM32 kontroler + Xilinx FPGA čip.
Koneckoncev jo lahko kupi kdorkoli za manj, kot bo ga stal material in jo pač preprogramira po želji.
Mislim, da je na voljo celo shematika.

Če v kaj sam investiram čas, bi rad videl nekaj novega.
Tudi čese izkaže kot s*anje - vsak novi preboj nosi rizik.

[VolkD]

Če v kaj sam investiram čas, bi rad videl nekaj novega.
Tudi čese izkaže kot s*anje - vsak novi preboj nosi rizik.

Sem imel veliko idej na to temo, a na žalost so moje ideje in usta pogosto prehitevala delo rok.

Čas je, da se lotiš!