thanks for the hint. if spent a bit of time and turned the in/out opcodes to ppi ioctls. actually i was very surprised about the results since you said the overhead wouldn't be that big.
uploading a 256 kbyte file i got the following results: using ppi: 17.120 seconds using in/out opcodes: 8.001 seconds so i think i'll rather stick to my old inline assembly code even if it can't be considered nice programming style, but the ppi overhead isn't something i can cope with in my app. cheers. alex John Baldwin schrieb am 2009-07-23: > On Wednesday 22 July 2009 3:31:54 pm Alexander Best wrote: > > the ppi manual states that using ioctl with /dev/ppi is extremely > > slow. i need > > the parallel port to be really fast. i need to communicate with a > > device that > > uses asynchronous transfer at a rate of ~ 2 mhz. so i need the full > > ISA bus > > speed to be able to push/pull data to/from the parallel port > > without any > > delays. timing is really critical. if there's a lot of work to do > > for the > > scheduler and the io calls get queued too long the transfer will > > fail. > The overhead of ppi is probably in the noise on a modern CPU. I > think you > should be fine with just using ppi(4). > > actually i meant: how can i check the available parallel ports from > > within my > > app? is there a syscall i can use or something like that? > You can look for ppcX devices perhaps. The easiest way might be to > enable > ppi and look for /dev/ppiX devices in /dev. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
