Pokud někdo hledá námět, měl bych nápad.
Říkal jsem si, až budu mít čas, že zkusím připojit k počítači přes paralelní nebo sériový port nějaký vnější bastl a zkusím s ním něco (programovat to budu v BASICu, pro mne stačí a z jiných jazyků jsem jakžtakž uměl akorát stroják a assembler 8080). Například přiložím teplotní čidlo k výměníku na ledničce a budu sledovat jak často se lednička zapíná a vypíná. Ale nejdřív wokna zakázala přímý přístup k portům a teď už ani ty porty na počítačích nejsou. Tak co kdyby někdo vymyslel něco co by přes USB dělalo ty dřív klasické porty a nějaký driver co by umožnil programu v BASICu s těmi porty komunikovat tak jako v době MS DOSu blahé paměti? Existují sice různá ..duina, ale proč si komplikovat život, když už jeden počítač mám?
Tak předně, to, že si Widle hlídají přístup na porty, je správně. OS nemá přímo k hardware nic pustit. V DOSu to nevadilo, tam prakticky nebyl multitasking, ale pokud je multitasking a spustil bys dva programy, co lezou na port, tak je průšvih na světě. Proto smí k železu jenom ovladač a obávám se, že ten ve Widlích nenapíšeš ani náhodou. Je jednodušší naprogramovat jednočip, než cokoliv ve widlích.
Basic je opravdu taky out. Holt jak říkal klasik, "kdo chvíli stál, už stojí opodál"...
Marně přemýšlím, jak jsem to ksakru udělal, že jsem komunikoval ve Windows přes USB se zařízením, a nepsal jsem ani jediný ovladač. A v jiné zakázce, co chtěl zákazníkem zase přes COM porty - a opět jsem nepsal žádný ovladač. Obé funguje ve všech verzích Windows včetně posledního Windows 10. Ale už vím, jak jsem to dokázal - nevěděl jsem od vás, že to nejde!
W 95 a jeho potomci (98, 98 SE, ME) dovolovaly dva přístupy k portům.
První přes standardní ovladač (v případě COMu fiktivní soubor, u LPT tato možnost nebyla) přes API. To je správně a trvá dodneška. Kdyby používal tohle, tak mu to v pohodě chodí i na W10.
Druhá byla přímo přístupem na registry SuperIO. Jádro tam mělo sice ochranu pomocí privilegií a vyskočila výjimka, ale ta byla ošetřena tak, že aplikaci dala práva k přístupu na HW. Prý kvůli kompatibilitě s DOSem. A bastlíř mohl šmrdlat pinama na LPT, jak s mu zalíbilo.
V NT a potomcích (2k, XP, Vista, 7, 8, 8.1, 10) druhá možnost zcela správně chybí. Takže tam si člověk z LPT v ECP logický analyzátor tak jednoduše neudělá...
Z toho, že dřív to šlo a teď ne, odvozuju, že Yarda používal tu druhou možnost. Hacknutí železa bez ovladače a mimo kontrolu jádra. Ve své době na to, jak si hrát s HW z BASICu, TurboPascalu,... vyšlo dokonce i několik knížek. A patrně ve všech varování, že to na NT nebude fungovat.
Takže pro paralelní port existují a dodnes jsou rezervovány soubory LPT1, ...
Věci ve Windows se dělají velice jednoduše - včetně toho hw a portů. Jen je třeba se přizpůsobit filozofii Windows.
Když budete jednat s mužem tak, jak se jedná se ženami - dříve či později dostanete přes ústa. Když budete jednat se ženou tak, jak se jedná s muži - budete mít zase problém. Jediné správné řešení je jednat s každým po jeho způsobu.
Když děláte věci pro jednočip, máte to dělat způsobem pro jednočip přirozeným. Když budete dělat věci na Windows, máte to dělat způsobem pro Windows přirozeným. Když to tak dělat nebudete, vznikají nesmysly typu tvrzení, že jednočip se programuje snadněji, než Windows.
To samé platí v programovacích jazycích. Když programujete v C, piště to pro C. Když v C++, pište to v C++. Když v Basicu, pište to jako v Basicu.
Na druhé straně PC je čím dál nevhodnější stroj pro jakoukoli vážnou záležitost a hw řízení. Vůbec ne pro problémy s porty, ale spíše proto, že výrobci a participanti vedou PC směrem, že je to stroj na fecebook spíše než na stroj mající reagovat skrze I/O s okolím. Nikdy nevíte, co vám s PC udělají špiónské technologie určené pro ztráty kontroly nad vaším počítačem: jako je UEFI, ATM, a další.
Jenomže soubor LPT1 komunikuje standardně (v režimu SPP) tak, že zapisuje data a používá nějaký handshake. Většina věcí používala SPP (byla to jistota, ne všude bylo ECP) a čtení dat pomocí PISO apod. Tam LPT moc nepomůže.
Filozofie Windows je taková, že "použij, co je, nebo trp s driver SDK a Cčkem". Vlastní ovladač doma neslepí (DriverSDK nepodporuje Basic) a ovladače jsou dělaný tak, že jsou tam přibalený i části GUI (konfigurační dialog, notifikace,...), takže default - a v případě LPT nepoužitelný. To je prostě realita a proto kde můžu, mám Linux.
Ohledně jazyků nesouhlasím. Jazyk svazuje a nedává moc možností. Zrovna píšu grafiku na jednočipu. Učecnicový příklad pro OOP, ale projekt je v C. Takže prostě píšu objektově v ANSI C. A trochu jsem to pomocí maker rozšířil o Pascal ( Assigned(), sety, stringy s danou délkou,...), o výjimky (protože v multithreadu setjmp.h nefunguje) a o něco málo z jiných jazyků (foreach, ...). No problem. A i McConnel doporučuje umět hodně jazyků, navrhnout řešení v tom nejlepším a přepsat do toho, ve kterým je projekt.
PC už je dávno jenom ovládací terminál. Nemá ani periferie, Windows nejsou real time (u Linuxu je třeba přebuildovat jádro s jiným schedulerem), HW nemá certifikace. V reálu všechno řídí nějaký jednočip a do PC jenom ládují data po LAN, WiFi nebo USB.
"Říkal jsem si, až budu mít čas, že zkusím připojit k počítači přes paralelní nebo sériový port"
To není problém. Sériový port je ve Windows obyčejný soubor. První sériový port je soubor "COM1", druhý sériový port je soubor "COM2". Stačí použít tento název souboru a Windows pracuje přímo se sériovými porty. A když už budete mít otevřen sériový port jako soubor, můžete použít kromě čtení a zápisu také speciální funkce Windows API, jako je SetCommMask (výběr události po sériovém portu, na který chcete čekat), WaitForCommEvent (čekání na událost ze sériového portu) a dále standardní nástroje pro synchronizaci jako WaitForSingleObject (např. čekání až přijde bajt ze sériového portu).
"Například přiložím teplotní čidlo k výměníku na ledničce a budu sledovat jak často se lednička zapíná a vypíná."
To je lépe sledovat rovnou proud z 230 V sítě do ledničky. Při vypnutí má např. 1 W (proud kolem 4 mA) a při zapnutí třeba 50-100 W. Teplotní jevy mají vždy značnou setrvačnost - začínají se zpožděním (než se ohřeje/ochladí) a vypínají se zpožděním (než se opět vrátí termodynamická rovnováha).
"Tak co kdyby někdo vymyslel něco co by přes USB dělalo ty dřív klasické porty a nějaký driver co by umožnil programu v BASICu s těmi porty komunikovat tak jako v době MS DOSu blahé paměti?"
To samozřejmě dávno existuje. Proto si můžete koupit na trhu bambiliardu různých převodníků USB/RS232, které emulují sériový port na USB portu. Stojí pár šupů. Z hlediska Windows s tím můžete pracovat jako se sériovým portem, viz otevření souboru COM1, COM2, atd. A práci se souborem umí i ten Basic.
Miloslav Ponkrác