----- Original Message ----- From: Roman Black To: Sent: Wednesday, December 27, 2000 4:12 AM Subject: [PIC]: PIC data via PC parallel port to screen > > Subject: [PIC]: PIC data via PC parallel port to screen > > Date: Wed, 27 Dec 2000 00:17:47 -0500 > > From: "David Pearson (SKYTRONICS)" > > > > Hi, > > To all the PC programming experts a couple of questions. > > I'm transferring data from a CCD image sensor for display on a PC via the > > parallel port. Works fine, 8 bit gray scale. 400 x 280 pixels. I'm using a > > F877 to transfer data to the PC using the parallel port in Bi-directional > > mode. On the PC end, I'm using Delphi 5 with my own Assembly Portin, > > Portout, Porttest routines. Plotting pixels using the Plotxy functions. > > > > The problem, it's very slow. It takes ~12 seconds to plot a frame on a > > Pentium 120. From what I've read, the maximum toggle rate I can expect on > > the parallel port is 500 nsec to 2 usecs, depending on what you read. Even > > so, I'm seeing times between setting a bit on the parallel port by the F877 > > to the time the PC recognizes the signal of about 15 usecs. Also, the > > plotting routine itself is slow, about 6 seconds to plot the 400 X 280 frame > > when plotting a test grayscale pattern, no port IO, just incrementing the > > plot value. > > > > Does anyone have any ideas on how to speed things up? I need a Windoze > > 95/98 environment using either Delphi or VB. > > Any ideas on how to speed up the data transfer? Faster portIO? Faster > > Plotting in Delphi? > > It seems crazy to me that my $5.00 PIC has to wait for a 120 MHz machine to > > do data transfers. Is the Windoze environment that inefficient? > > > > Any ideas and help is appreciated and may be useful to other group members. > > > 1. "Is windows that inefficient" = YES > 2. "any ideas and help" = May be difficult! :o) > > I use the parallel port for data input all the time, not > having access to ICE and other expensive goodies I do it > the hard way by attaching most of my PIC projects into > the par port and this gives benefits over the ICE anyway > with the ability to chart waveforms and do sophisticated > measurement. > > Firstly, I have only played with Delphi for a short while, > as I don't like Pascal that much. It does seem to me that > Delphi is very much a "idiot language". This almost always > means; easy to make pretty screens but performs like shite. I take offense at this. 32bit Delphi uses the same code generator as Borlands C++ Builder. If correctly written it can be as efficient as C++. > I get data from the par port using Turbo C (dos) and I > program in C-- with smidges of 8086 asm thrown in. You > can get a byte from the par port with something like a > thebyte=inportb(port_id) > which compiles down to a one-word cpu instruction and > on a 486 or pentium is virtually instantaneous. > Now I'm imagining (guessing) that Delphi has to beg > Bill for a chance to peek at the par port, and like most > windows programs will run very low performance. The problem is that Win95, tho' it doesn't _prohibit_ port access, does _virtualize_ it. The trick is probably to write a device driver for the low-level I/O. The app could then call the driver to get a whole bunch of pixels at once. > I don't really have a solution for you, other than to > start programming for a high performance environment > (I am still making dos apps that run fabulously under > Win 95) OR, try finding a windows programming expert > who knows how to beg/force etc windows to give you > better access to the port. > > Having done many years of fast hardware/software > interfacing with dos apps to the real world it never > ceases to amaze me just how PATHETIC windows is at > controlling anything more than a word processor. Although Windows is far from RealTime (by most reasonable definitions thereof), it really isn't too bad on efficiency: most of the raw CPU time is availalble to your code, and properly written graphics operations can be darned fast (take a look at Quake III Arena, for example). Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu