maximale frequentie parallele poort

zet in je programma "aan" en "uit" zonder delay en bekijk met een osciloscoop wat de frequentie is.

Ik meen te herineren dat je computer pas de parallele poort hoog of laag maakt op het moment dat "hij daar zin in heeft."

Volgensmij was dit te corrigeren door een driver te installeren. Maar correct me if i'm wrong.

In ECP/EPP mode is 5...6 mbps maximum haalbaar...

Je kunt wel een driver installeren, maar Windows zal nooit volledig realtime worden. Daarvoor zul je een echt realtime os moeten installeren, zoals realtime linux.

(Heb voor een schoolproject met een printerpoort een composite signaal gemaakt. Werkte prima op tv, wel alleen zwart/wit)

je zou eens het idee van Jan Bot kunnen uitvoeren.

maar hoe ga je naar de poort schrijven?
heb je een driver die lowlevel inhaakt of heb je een "printer" geinstaleerd?

@RoelA: je kan altijd nog gaan threaden op forground met RT prioriteit

Realtime zal het misschien niet halen maar het zal zeker een stuk sneller gaan dan dat je normaal zal halen asl je gewoon in je "main thread" blijft.

met een RT krijg je ook voorrang op de meeste windows processen let wel op dat je GUI geen update meer krijgt want daar is geen tijd voor.

Enige goede manier is de parallelpoort gebruiken voor de communicatie naar een externe MCU, en die de timing laten regelen...

ik gebruik een driver dll en ik schrijf het progje met vb2008. we gaan hem gebruiken om een stappen motor aan te sturen. als hij 1000 pulsen per sec kan maken is het al zat dat zal hij dus wel moeten halen. het gaat er vooral om dat hij geen stappen over slaat. en ik dacht dat dat bij hogere frequenties mischien zou kunnen gebeuren.

ik denk dat ik het idee van Jan Bot ga proberen.

Robbert

In de cnc hobby wereld wordt veel gebruik gemaakt van MAch3 als cnc software deze stuurt zijn signalen naar buiten via de parallele poort. De frequentie van de signalen kan tot 100kHz ingesteld worden en dit zou de parallele poort dus ook aan moeten kunnen.

oke bedankt iedereen :d

Robbert

De poort op zich kan wel een flinke frequentie aan, maar bij Mach3 wordt daarvoor een kernel-level driver gebruikt.

Als je vanuit een user-space programma gaat sturen, zoals waarschijnlijk het geval is als je in VB programmeert, kom je waarschijnlijk in de knoop met het multitasking systeem van windows; je programma wordt steeds op een willekeurige plaats onderbroken voor ~10ms, dus in die tijd blijven de uitgangen staan. Je kunt dus maximaal 50Hz continue halen, en als je PC even druk is met iets anders, gaat zelfs dit nog fout.

vanuit user space kan je nog een behoorlijke snelheid halen als je niet continu zend maar in bursts ik weeet niet wat het idee van robbert is.

maar als je thread in realtime gaat dat boven alle processen is dus de kans dat je communicatieburst onderbroken wordt erg klein.

ik geloof niet dat het voor de TS haalbaar is om een KMD(.SYS) te schrijven.

er is echter op de msdn wel info over te vinden.

realtime, zoals het begrip in de embedded systems wereld gebruikt wordt, bestaat niet in windows, en al helemaal niet in user space.

Hoe hoog je de prioriteit ook zet, je programma zal wel degelijk tig keer per seconde onderbroken worden, waardoor de uitgangen bevroren worden. Alleen korte bursts zenden zal ook niet lukken, omdat je geen waarschuwing krijgt voordat je timeslice afgelopen is.

ik had ook niet over realtime zoals in embedded omgevingen.

je kan wel bursts zenden als je weet hoe lang je timeslice is.

er moet op een of andere manier wel na te gaan zijn hoe lang dat kan zijn.

Hallo.

Ik gebruik vaak Profilab voor test doeleinde daar kom ik tot 1Khz, in vb haal je inderdaad niet veel meer dan 50Hz.

Maar misschien is daar nog een foefje voor?

Gr Lambiek.

* timmie zal eens de scoop aan een parpoort hangen terwijl hij een continues loop loopt in een RT thread die nix anders doen dan de pin togglen

/edit
ik zal eerst kijken wat ik zie als ik dat ding op highest zet(hoger kan je/mag je niet programeren in VB)

[Bericht gewijzigd door timmie op zondag 2 november 2008 20:44:24 (30%)]

Als ik me niet vergis, hebben de standaard timers in VB e.d. ook maar een resolutie van 10ms, in ieder geval in VB 6. Hoe het zit binnen de .NET omgeving weet ik niet.

Andere mogelijkheden zijn het gebruik van de hoge resolutie timers d.m.v. de Windows API, of het gebruik van een kernel driver, maar dat is niet bepaald een eenvoudig klusje.

Het feit blijft dat Windows niet voor dergelijke zaken ontworpen is, en er nooit echt geschikt voor zal zijn. Er zijn wel mogelijkheden om dit soort dingen voor elkaar te krijgen, door middel van real-time kernels zoals Intime, maar dan draait Windows als een soort idle-task, en dat is een zware ingreep op het systeem. Als je niets anders met die PC doet, kan dat wel een mogelijkheid zijn, maar de kosten van de ontwikkel- en runtime licenties van dergelijke kernels zijn meestal ver buiten het bereik van hobbyisten.

Waarom moet zo'n vraag nu weer ontaarden in een discussie over real-time dingen?

Het antwoord op de vraag is: Rond de 1M keer per seconde (Het ding is van oudsher een ISA apparaat, en daar krijg je niet makkelijk meer dan 1M dingen heen per seconde). Als iemand ECP en EPP laat vallen, dan heeft hij het over de DMA mode, waarbij het standaard paralallele printer protocol gebruikt wordt om hele bytes te sturen. Dan gaat het dus niet over het sturen van individuele pennen.

(En dan nu het real-time aspect....) Let op: je programma kan op ieder willekeurig moment door het besturingssysteem ineens effe stilgezet worden. Als je bijvoorbeeld een stappenmotor aanstuurt zul je er voor moeten zorgen dat het blijft werken als je ineens niet meer draait. Een "soft-start" inbouwen heeft dus geen zin. Hij moet plots van max naar nul en weer naar max kunnen.

Dat deze discussie op een real-time verhaal uitkomt, lijkt me vrij logisch, aangezien de TS een pulstrein uit zijn parallelle poort wil hebben, waar je, als je een hoge snelheid wilt halen, een real-time systeem voor moet hebben.

Uitleggen waarom het onder windows, zonder ingewikkeld kunst- en vliegwerk, niet zomaar gaat, lijkt me voor de TS ook wel handig.

Met een DMA mode kun je, met een paar eenvoudige trucjes, zulke dingen wel mogelijk maken; als je ervoor zorgt dat het strobe signaal (het "ik heb de data gelezen, geef het volgende byte maar" signaal) met een bepaalde vertraging terug komt, kun je een pulstrein met een min of meer vaste snelheid naar buiten laten komen, als je een tabel met de juiste waarden aanbiedt. Op die manier verplaats je het kunst- en vliegwerk van de software naar de hardware.