hur snabbt kan en parallellport läsa in data?

Det går alldeles för fort för parallelkortet

- den klarar på sin höjd 200 Kbyte i sekunden.

du måste ha annan typ av HW, med kanske DMA mot moderkortet

/TE

Du klarar helt enkelt inte detta utan att endera bygga ett helt specialanpassat kort direkt för t ex PCI-bussen i datorn, eller genom att med någon extern specialbyggd hårdvara omvandla till något som kan läsas in genom något av nätverkskort, videocapture eller SCSI-interface och sedan ordna upp det hela i datorn med specialskrivet program.

Att konstruera ett eget PCI-kort med dessa krav och skriva tillhörande drivrutin för något modernt operativsystem är ingen helt trivial sak i dagens läge och det låter som om det kan bli riktigt dyrt.

Ett alternativ kan kanske alltså vara att bygga någon extern pryl som kan omvandla till t ex ethernet. Jag har sett en del byggen där man använt enchipsdatorer för att läsa in data i hög hastighet och sedan skickat vidare via någon av Intels eller Realteks enchips ethernetadaptrar över ethernetnätverkskabel till nätverkskort i datorn som egentligen ska ha informationen. Om det finns någorlunda färdiga sådan hårdvara att köpa vet jag inte alls däremot, men det bör iaf bli någorlunda humant pris på en sådan lösning.

Jag blev råd detta med PCI-kort tidigare men misstänkte att det skulle bli mycket jobb.

Denna lösning är absolut något jag ska kolla närmare på

Ett tack till både Dig Olof och till Torbjörn

mvh Harald

För länge sedan, på 486-tiden, skrev jag en point-to-point driver för Linux som nyttjade parallellporten för att överföra information. Lite som PLIP men som ett labbexperiment. Hastigheterna jag kom upp i då utan att gå över på avancerade protokoll var ca 130 kbyte/s på de enklare parallellportarna och upåt 150-170 kbyte/s på de mer avancerade.

Jag tror inte man kan förvänta sig några grova hastigheter utöver detta, inte ens om man är slugare än jag var 1995 eller så.

Det slog mig att det fins många microkontrollers med USB interface som kanske passar för denna typ av applikation.

- dock, det måste vara USB2.0 om du skall får den bandbredd du behöver.

du drar nog en 35 - 50 Mbit för 3-Mbyte i sekunden då det är så mycket overhead mm. pga omfrågningar mm. i USB

Kruxet här är att skriva en applikation på PC-sidan som pratar USB som du vill, och att enheten som plockar upp informationen presenterar sig i rätt klass (video?) för att få dom realtidsegenskaper som krävs.

- i princip vill du ha komunikations-chipseten och tillhörande mjukvara i var ända som används i USB-baserade videokapturekort...

- du kommer att behöva en bunt minne för buffring på microcontrollern då datatransporten över USB är tämligen ryckigt.

Personligen gillar jag inte alls USB, då det rent tekniskt transmissionsmässigt är ett slafsverk i stil med IDE-bussen i dummheter - detssutom är 'host' i PC tämligen komplicerad att hantera.

mao. det gäller att hitta _bra_ appnötter och kit där allt sådant är så färdiggjort som det bara går.

- både på kontrollersidan och i PC-sidan.

Du träffar mitt i prick eller hur man nu säger, det verkar vara ett stort krux och man får en ryckig överföring. Mycket jobb med osäker prestanda. Jag vill försöka undvika detta med Cypress Hotlink, får se vad jag kommer fram till... Problemet blir till sist att få in datat i datorn. Ska oxå titta lite på Olofs förslag.

Firewire är nog det optimala alternativet ( om inte det ända rätta) men det verkar vara ännu mera jobb med det än med USB. Utvecklingskorten är svindyra och då måste man ofta köpa "stacken" ovanpå detta. Jag har försökt sätta mig in i det bara för att förstå att det skulle ta alltför lång tid för mig. Det är helt enkelt lite överkurs...

mvh Harald

Du kommer aldrig runt detta med ryckigheten då USB är ett paketorienterat nät - du behöver säkert 10 ggr nyttjad banbredd i marginal för att vara någotsånär säker på alltid tillgång...

- om 'host' sköter sig i sin ända övh.

Dessutom var det tidigare vanligt med korrupta packet med massa slumpmässiga omfrågningar, mycket beroende på den urursla transmissionsöverföringsfilosofin HW-mässigt.

Kretskopplat nät som firewire så är det helt anna sak, då har du en 'garanterad' bandbredd - iofs kanske i 'sektorer' med viss stadigt intervall, men ändå!

Val av transporttopologi kan vara helt avgörande för hur bra och kanske tom. om möjlighet alls att lyckas med i sitt nära realtidsprojekt.

Själv tycker jag det är synd att så fort man lyckas få till lite 'speed' i HW för överföring, så lassar man på så mycket API i både HW och mjukvara så att kommunikationsgränssnittet lider av svår slagsida

- elefantisis helt enkelt, mjukvarufolket formligen dränker en i olika API:e så att man kommer så långt ifrån HW-level som möjligt i någon slag godhjärtad dumhet/ondska (och medföljande dålig prestanda då informationen skall ta sig igenom en bunt layers innan det når 'trådarna' ut - det kanske passar mjukvarufolk utan prestandakrav, men det passar inte folk som jag och förmodligen du, som vill ha full kontroll på HW, så nära 'trådarna' som möjligt för att klämma ut maximal prestanda!! Framförallt så begriper jag inte varför man i USB har bestämda 'master' och 'slave'-roller och inte kan byta plats med varandra.

Jag menar att RS232:s styrka var, är och förblir att man kunde byta både 'kön' och 'roll' - 'kön' fysisk med omkopplingar, och roll beroende vad mjukvaran i resp. ända betraktar sig som.

Hela den här biten är omöjliggjord i USB som den ser ut idag. Arkitekturmässigt så är den ytterst trång kostym och knakar och spricker i sömmarna betänkligt redan vid först provningen mot verkligheten som när man sätter sig - samt saknar ovesäntligheter vänsterarm och högerben...