avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] ppi speed-tuning ;-)


From: Joerg Wunsch
Subject: Re: [avrdude-dev] ppi speed-tuning ;-)
Date: Thu, 20 Nov 2003 15:08:20 +0100
User-agent: Mutt/1.2.5i

As Jan-Hinnerk Reichert wrote:

> I'm still wondering why ioctl() is so slow. Has anyone any ideas?
> AFAIK, an outb() or inb() takes approx 1us, but calculation shows that 
> on ioctl() that does a single port access takes almost 3us.

Crossing between kernel and userland boundary takes its time.  It's
done by a software interrupt request, which needs quite a bit of
kernel processing.  OTOH, compared to the direct inb/outb instructions
issued by the userland application (e. g. in avrdude on Windows), it's
pretty safe since it crosses the CPU's security rings the standard
way, as opposed to just breaking the rings entirely for the sake of an
application.

> Has anyone got a PCI I/O-Card to check if it is faster there?

Standard parallel ports these days are usually located on a PCI chip
anyway.  However, I don't know whether they still abide by the timing
of the old ISA bus where an IO request was required to take 1.25 µs (8
MHz ISA bus clock).

To get both, security as well as speed, you'd need to write a kernel
driver specific for avrdude yourself.  Dunno about Linux, under
FreeBSD, you'd need to stack it on top of ppbus(4) (which sits itself
on top of the hardware driver ppc(4)), just aside to ppi(4) which we
are currently using.  So the framework is already there, it just needs
someone to implement it. ;-)  You can then save time by passing a
larger block of data from/to the kernel (like using a standard read(2)
or write(2) request), so the K/U boundary needs to be crossed less
frequently, and some of the inner loop is executed inside the kernel
driver.

Something similar could perhaps even be done on Windows...

Needless to say, all these drivers could be written as loadable
modules, so no kernel recompilation needed.  Under Linux, it might
produce more headaches for distributing the RPMs where the modules
fit to the respective kernel version (2.4.x, 2.6.x?), don't know.
Under FreeBSD, we could perhaps get away with either not providing
a binary package at all, or maybe by hacking a package that
contains KLDs for both, FreeBSD 4.x and 5.x.  Under Windows, who
cares for DLL (or VxD?) versioning at all? :-))

I have no idea about a Solaris kernel module...  But I guess it
could be done, too.  This would be beneficial even more, since
there's currently no equivalent to ppi(4)/parport(4) available
on Solaris.
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]