kent@swrinde.nde.swri.edu (Kent D. Polk) (09/26/90)
In article <4564@crash.cts.com> seanc@pro-party.cts.com (Sean Cunningham) writes: >Well, I haven't found it yet, but sofar, I and my partner have been able to >have FIFTY-FOUR concurrent tasking running at once. This was on an A2500/30 >with 4MB 32bit FastRAM/1MB 16bit ChipRAM. > >These were chosen because they all require constant onscreen refreshing, and >don't sit idle in the background like a WP or other application. Also, since >the Amiga doesn't presently support memory protection, the fourty-nine copies >of clock were a real test as well...EXEC handled things flawlessly. Oh, and >the DPaint anim ran smoothly as well (surprising, but nice!). And we still >have about 1.5MB to play with. > >I'd like to see a similar test tried on other platforms... How about a different test on the same platform :^) I hesitated mentioning this, but was gently nudged, so ... the following data acquisition system was put together with the assistance of Pete Goodeve & David Navas - PPIPC. bkgnd: I have developed a number of data acquisition systems in the past, with a host of lab-oriented ones for each tiny different project. I was getting tired of practically rewriting them every time. So, I eventually came out with my version of a 'data pipeline' data acq. system. Actually I call it a 'conveyor belt' since events are handled as objects and have particular types of messages associated with them which contain instructions and information on what is in the event & how to handle the event. For each 'belt', there is a manager who is in charge of starting up & shutting down the tasks (work stations) which operate on the data, as well as handling a semaphore-controlled linked list of those work stations. The list contains info such as the succ/pred message ports. It is controlled by a semaphore so the manager can insert or delete a work station at any time - even when data & messages are traveling along the belt. PPIPC was the big help here - safe messages & a versatile message structure. Each belt also has a 'Sampler' station - which is in charge is creating the event data, putting it on the belt & assigning a message to that event. Everything is modular, so that there is a generic Sampler which handles pretty much any type of event data I have come across. For each physical device that I can get data from, there is a device-dependent module with a standard set of interface calls which the Sampler uses to drive the device - typically I hook up to GPIB scopes, but I have file samplers (for when you want to see it again :^) and several others for hardware we put together here. The Sampler module handles all 'belt' oriented stuff, which makes writing 'device drivers' pretty easy. Each station beyond the Sampler has a similar arrangement, but is a 'Filter' station. The Filter module handles all belt interactions & expects a standard set of functions from each particular filter module. Makes it REAL easy to write other filter stations. The result is that I can use most of previously written software, while keeping new stuff simple and very easy to write. Moving on... I recently wrote a Sampler station to pull in waveform info from some handmade hardware waveform/event processors. I pull in the data in a interrupt service routine which is almost two pages of 'C' code. Hardly even optimized - I just got it running for now. The thing which completely amazed me was that this little A2500/30 can respond to my interrupts in an average of about 25 usec., and execute those ~two pages of 'C' in under 100 usecs at a 20msec/event duty cycle. "What's so great about that" you say? Well, this is while the above- mentioned belt system is pulling in multiple channels of waveform data over GPIB, sending data down two belts through multiple filter stations, plotting the waveforms & writing the event data to disk at about 35k/second. Oh yeah, I can even continue editing, a little word-processing (gotta do those reports), and even read the News (rlogin) while all this is going on (can't believe I got it this stable :^). Tried compiling, but Manx kinda hogs the machine. Xoper typically reports ~65 tasks and processes active, including ~25 CLI processes while all this is going on. Out of my 4 Meg of fast ram, I have about .5 Meg left. I'm impressed... Sorry to take up the bandwidth, but just thought a few people might want to know what a nice low-end data acquisition machine the Amiga can be, and how incredibly easy it is to program. After all, I'm definitely no hotshot programmer, so must be the machine & it's environment. Thanks C= for a beautiful machine. (Now, how about fixing SCSIdirect on my 2090a? :^) Kent Polk: Southwest Research Institute (512) 522-2882 Internet : kent@swrinde.nde.swri.edu UUCP : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent