DIY_EFI Digest Tuesday, 12 December 1995 Volume 00 : Number 001 In this issue: Re: C for embedded controllers [admin] digest mode Re: EST Re: EST Re: EST thanx Re: EST Re: EST Re: thanx See the end of the digest for information on subscribing to the DIY_EFI or DIY_EFI-Digest mailing lists. ---------------------------------------------------------------------- From: Bruce Bowling Date: Mon, 11 Dec 1995 12:08:08 EST Subject: Re: C for embedded controllers ~ ~ >Virtual functions appear to be an additional layer ~ >to debug through, since addresses are determined at runtime and ~ >can change depending on the inheritance of an object. ~ ~ ~ As to the "additional layer", it's largely invisible during debugging. ~ If I step a machine instruction at a time across a call to a virtual function, ~ watching the current high-level source line, the debugger makes a brief detour ~ to the last line in the file (I assume this indicates a point in the code ~ for which the compiler indicated no valid source line), then goes to the ~ first line of the virtual function. It's effortless. ~ ~ ~ If I may be so bold, I see this belief as a relic from K & R. I feel ~ that the weak typing of (non-ANSI) C is nice for the ((new || old) && ~ (sloppy || lazy)) programmer who wants to pass an argument when it's too ~ bothersome to figure out how to properly typecast it. I have never been ~ prevented by C++ from doing anything I wanted to do. Explicitness makes ~ for fewer misunderstandings over time. ~ I guess I got "bad blood" from using C++, mainly because of the requirements of the project. My bad experience came from using C++ on a non-embedded project, one that should not have been (in my mind) so difficult, but caused endless grief until I realized what was going on... The "project" was an electron accelerator simulation which consisted of several processes (running on a HP workstation under HPUX) which communicated using shared-memory. The idea was to create the objects (which were several thousand 2-dimensional matrices with associated virtual functions - each matrix+functions a separate object) in shared memory and let each concurrent process use the functions. However, it turns out that the first process who created the shared-memory objects initialized the virtual function pointers to its "space" of execution and the other processes who accessed the virtual functions were trying to access an address outside of its scope. This caused me loads of pain on a project which was already behind because of my learning curve with C++. HPUX does not have thread capabilities (the OS version I was using), and other communication methods like pipes, sockets, etc, were inefficient with the size of the data (over 70 meg). The solution to the problem was to make the objects in shared-memory a sub-class to new objects which contained the virtual functions (taking them out of the shared- memory classes) and pointers to the object in shared-memory. This worked, but I lost the benefits of encapsulation of data/functions in one single object. Each processes has to set up the pointers to shared-memory themselves, and data accesses are via. the pointers to shared memory which killed performance slightly. The program also had to worry about shared-memory/object alignment to prevent access errors. I guess the point here is that I had to know what the compiler/OS was doing with the code, and find a work-around, so the whole notion of just writing code and letting the compiler worry about the details can lead to trouble. Hence the "lazy" or "inexperienced" reference I stated before. This is a unique problem, which probably would not show up on an embedded system where one has access to the entire scope of memory. However, the experience has reinforced in my mind that one should use the proper tools for the job. I was required to use C++ on this project to make the simulation more "high-tech"/"state-of-the-art"/etc...... - - Bruce - -- - ----------------------------------------------------- <<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - ----------------------------------------------------- Bruce A. Bowling Staff Scientist - Instrumentation and Controls The Continuous Electron Beam Accelerator Facility 12000 Jefferson Ave - Newport News, VA 23602 (804) 249-7240 bowling@xxx.gov http://devserve.cebaf.gov/~bowling - ----------------------------------------------------- <<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - ----------------------------------------------------- ------------------------------ From: John S Gwynne Date: Mon, 11 Dec 1995 12:02:41 -0500 Subject: [admin] digest mode - -------- Digest mode is now available. To subscribe: a) unsubscribe to the regular mail list Send in the body of email to majorodomo@xxx.edu: unsubscribe i.e., "unsubscribe diy_efi" b) subscribe to the digest version of the list Send in the body of email to majorodomo@xxx.edu: subscribe -digest i.e., "subscribe diy_efi-digest" John S Gwynne Gwynne.1@xxx.edu _______________________________________________________________________________ T h e O h i o - S t a t e U n i v e r s i t y ElectroScience Laboratory, 1320 Kinnear Road, Columbus, Ohio 43212, USA Telephone: (614) 292-7981 * Fax: (614) 292-7297 - ------------------------------------------------------------------------------- ------------------------------ From: Steve Knickerbocker 512-356-3000 X6759 Date: Mon, 11 Dec 1995 12:26:00 -0600 (CST) Subject: Re: EST - --Boundary (ID UxJ6DWxGkEYSwE3PgHgQjw) Content-type: TEXT/PLAIN; CHARSET=US-ASCII - --Boundary (ID UxJ6DWxGkEYSwE3PgHgQjw) Content-type: MESSAGE/RFC822 Date: Mon, 11 Dec 1995 07:21:00 CST From: "Steve Knickerbocker"@xxx.Org Subject: Re: EST MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Posting-date: Mon, 11 Dec 1995 00:00:00 CST A1-type: DOCUMENT At 08:40 PM 12/8/95 -0500, you wrote: >One problem with this setup, when the fifth magnetic pickup is triggered, is >it at TDC compression/power or is it TDC exhaust/intake. This is where you >need a magnetic pickup on the cam. > >See ya, > > >Mike No cam pickup is needed for dual coils or batch fired injectors, only one coil per cylinder, or sequential injector systems. - -j- I've come to this conclusion this past weekend. What I need to know is the formula for convering mS to degrees at a given RPM. Steve - --Boundary (ID UxJ6DWxGkEYSwE3PgHgQjw)-- ------------------------------ From: walter@xxx.com (thomas walter x5955) Date: Mon, 11 Dec 95 13:52:05 CST Subject: Re: EST > What I need to know is the > formula for convering mS to degrees at a given RPM. > > Steve uh... converting? RPM/60 = RPS ( Rev per SECOND ) RPS/360 = degrees per SECOND /* note 60*360 = 21600 */ so RPM/21,600 * 1000 (ms per second) = degrees per mS RPM/21.6 restated at: to obtain degrees per milliSecond divide RPM by 21.6 quick check: at 8,000 RPM = 370ms/Degree (sounds about right. ;-) Tom "This puppy redlines at 140Hz" Walter ------------------------------ From: atsakiri@xxx.com Date: Mon, 11 Dec 95 15:57:29 -0500 Subject: Re: EST > > What I need to know is the > > formula for convering mS to degrees at a given RPM. > > > > Steve > > uh... converting? > > RPM/60 = RPS ( Rev per SECOND ) > > RPS/360 = degrees per SECOND > > /* note 60*360 = 21600 */ > > so RPM/21,600 * 1000 (ms per second) = degrees per mS > > RPM/21.6 > > > restated at: > > to obtain degrees per milliSecond divide RPM by 21.6 > > quick check: > at 8,000 RPM = 370ms/Degree (sounds about right. ;-) > > > Tom "This puppy redlines at 140Hz" Walter I think the RPS/360 = deg/second above should be RPS*360 = deg/second. I get: N rev min s 360 deg ----- * ---- * ------- * ------- = N*360/(60*1000) deg/ms min 60 s 1000 ms rev = N * 0.006 deg/ms (where N is in rev/min) Anthony Tsakiris - --------------------------------------------------------------------------- The opinions expressed are my own and not necessarily those of my employer. ------------------------------ From: Steve Knickerbocker 512-356-3000 X6759 Date: Mon, 11 Dec 1995 15:22:00 -0600 (CST) Subject: thanx Tom, Thanks for showing me the light. I'm afraid to even try and figure out what 140 hz equates to. I'm in a non math kinda day. Steve ------------------------------ From: Bruce Bowling Date: Mon, 11 Dec 1995 17:11:12 EST Subject: Re: EST ~ > so RPM/21,600 * 1000 (ms per second) = degrees per mS ~ > ~ > RPM/21.6 ~ > My web page which computes piston velocity also computes the time in milliseconds per crankshaft degree: http://devserve.cebaf.gov/~bowling/auto.html But dividing by 21.6 is probably *much* faster....... - - Bruce - -- - ----------------------------------------------------- <<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - ----------------------------------------------------- Bruce A. Bowling Staff Scientist - Instrumentation and Controls The Continuous Electron Beam Accelerator Facility 12000 Jefferson Ave - Newport News, VA 23602 (804) 249-7240 bowling@xxx.gov http://devserve.cebaf.gov/~bowling - ----------------------------------------------------- <<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - ----------------------------------------------------- ------------------------------ From: walter@xxx.com (thomas walter x5955) Date: Mon, 11 Dec 95 16:21:15 CST Subject: Re: EST Egg on my face.... not only did I MIX UP my math on that, I also did not answer it as Steve requested. Sorry about that... ;-) > formula for convering mS to degrees at a given RPM Rev Minute s 360 degrees 6 degrees ------ * ------ * --------- * ------------ = ----------- Minute 60 s 1000 ms rev 1000 ms degrees per millisecond = RPM * 0.006 so at 8000 RPM, that is 48.0 degrees per millisecond. 600 RPM, that is 3.6 degrees per millisecond. [Thanks to John and Anothony for spotting such a mistake... I am much better at hiding them in obscure C calls. Then I wouldn't have a chance of getting it past John. ;-)] I'll stick to doing math in radians. ;-) Cheers, Tom "140Hz is just another way of saying 8,400 rpm" Walter > quick check: > at 8,000 RPM = 370ms/Degree (sounds about right. ;-) OPPS, no it doesn't!!!!! ;-( > Old Model T at idle, perhaps? > > Tom "This puppy redlines at 140Hz" Walter ------------------------------ From: dzorde@xxx.au Date: Tue, 12 Dec 95 08:59:10 Subject: Re: thanx Guys, guys, guys According to my knowledge of basic physics and common knowledge 140 Hz is 8400 RPM or 50.4 deg/mS Dan Zorde ______________________________ Reply Separator _________________________________ Subject: thanx Author: diy_efi@xxx.edu at INTERNET Date: 12/12/95 7:15 AM Tom, Thanks for showing me the light. I'm afraid to even try and figure out what 140 hz equates to. I'm in a non math kinda day. Steve ------------------------------ End of DIY_EFI Digest V0 #1 *************************** To subscribe to DIY_EFI-Digest, send the command: subscribe diy_efi-digest in the body of a message to "Majordomo@xxx. A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace "diy_efi-digest" in the command above with "diy_efi".