From PaulHelmuth at SprintMail.com Thu Jun 2 23:46:54 2005 From: PaulHelmuth at SprintMail.com (Paul Helmuth) Date: Thu, 2 Jun 2005 23:46:54 -0500 Subject: [Efi332] (from a Newbe) Just want to know... Message-ID: <008101c567f7$696cfae0$6b7ba8c0@p2450> ...if there is any current activity on the original EFI332 project, or of course, an updated version of the project. I have been working on developing an ECU based on the Motorola/Freescale MPC555 for some time. I am working with the Phytec development board, the GCC tool chain, a Macraigor Wiggler, and a Flash Programmer from Macraigor. I am working with a 60-2 crank trigger wheel from Electromotive (with one of there sensors). I am using the TPU micro code from the EFI332 FTP archive that is set up for a 60-2 input train. I have quite a bit of stuff working, though not a complete system yet. I will be testing the ignition triggering this month, then work on adding the fuel injection. I have a pretty nice lap-top monitor/tuner application that communicates with the MPC555 through one of it's on-chip serial ports. In the past, I have had some questions about the TPU microcode, but I have the major functions (PMMX, PSP12, LPWM2) working just fine now. Just wanted to see if there were some other nuts like me, that I could share being nuts with. -Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050602/4d1ce192/attachment.html From doug at udel.edu Fri Jun 3 04:40:56 2005 From: doug at udel.edu (Doug Brunner) Date: Fri, 03 Jun 2005 05:40:56 -0400 Subject: [Efi332] (from a Newbe) Just want to know... In-Reply-To: <008101c567f7$696cfae0$6b7ba8c0@p2450> References: <008101c567f7$696cfae0$6b7ba8c0@p2450> Message-ID: <42A025A8.7060003@udel.edu> I'm also working on a new Phytec-555 based computer, for the University of Delaware's Formula SAE car. I had a system based on the old EFI332 4-layer board working, but it suffered a series of glitches after sitting for a few months that I was unable to fix, or even trace down. We decided to go with a new system that could avoid the shortcomings of the original 332 board (large, high component count, glitch-prone). I'm presently designing the carrier board that will hold input buffers, signal conditioning, injector drivers, and open-collector outputs to connect to the ignition box. I expect a lot of my code to carry over, and the remainder is mostly configuration, which should be simple (no need to interface with external ADC's, etc., like on the 332 board). I developed a serial-port-based tuner program of my own that can be configured for multiple arrangements and sizes of tables (e.g. you can change table resolution without any programming changes), which I'll be updating to support floating-point data types. You can take a look at my codebase on the DIY-EFI ftp site, in /incoming; the code for the 332 is efi332-code-udsae-2005.tar.gz and the tuner program is zut-1.0.tar.gz. --Doug Brunner Paul Helmuth wrote: > ...if there is any current activity on the original EFI332 project, or > of course, an updated version of the project. > > I have been working on developing an ECU based on the > Motorola/Freescale MPC555 for some time. I am working with the Phytec > development board, the GCC tool chain, a Macraigor Wiggler, and a > Flash Programmer from Macraigor. > > I am working with a 60-2 crank trigger wheel from Electromotive (with > one of there sensors). I am using the TPU micro code from the EFI332 > FTP archive that is set up for a 60-2 input train. > > I have quite a bit of stuff working, though not a complete system yet. > I will be testing the ignition triggering this month, then work on > adding the fuel injection. > > I have a pretty nice lap-top monitor/tuner application that > communicates with the MPC555 through one of it's on-chip serial ports. > > In the past, I have had some questions about the TPU microcode, but I > have the major functions (PMMX, PSP12, LPWM2) working just fine now. > > Just wanted to see if there were some other nuts like me, that I could > share being nuts with. > > -Paul. > >------------------------------------------------------------------------ > >_______________________________________________ >Efi332 mailing list >Efi332 at diy-efi.org >http://lists.diy-efi.org/mailman/listinfo/efi332 > > From BowTieVette at aol.com Fri Jun 3 21:21:19 2005 From: BowTieVette at aol.com (BowTieVette at aol.com) Date: Fri, 3 Jun 2005 22:21:19 EDT Subject: [Efi332] (from a Newbe) Just want to know... Message-ID: <1f6.b1b8293.2fd26a1f@aol.com> Hi Paul, There is not too much traffic on the old efi332 list these days. We lost most of the subscribers when the diy server took a dump a while back and many folks never came back. I still have a working system in my car, and it still works great. I know that Doug's target is an FSAE car, what is your target? Make it three nuts on the use of the Phytec. I have a carrier board designed and built, with software bringing up the rear. There are a couple of photos of the board at James MPC555 site here: _http://www.ee.ualberta.ca/~jasmith/mpc555/_ (http://www.ee.ualberta.ca/~jasmith/mpc555/) look at bullet number 8 near the top amongst a note about the mc33394 power supply. Its chockablock full of drivers and IO capability with all TPU lines going to drivers of one sort or another. There are at least a couple of other lurkers also working with the 555/565 on this list. I'm using a port of my 332 code with a pile of enhancements. I use a Labview based console program for serial comm, datalogging, replays etc. Most of my old stuff, although now quite dated is on the sourceforge efi332 site including a few notes on the 58XX TPU functions. I should be replacing the venerable 332 in my car sometime this summer. Jeff more notes below.. In a message dated 6/3/2005 5:41:37 AM Eastern Standard Time, doug at udel.edu writes: I'm also working on a new Phytec-555 based computer, for the University of Delaware's Formula SAE car. I had a system based on the old EFI332 4-layer board working, but it suffered a series of glitches after sitting for a few months that I was unable to fix, or even trace down. We decided to go with a new system that could avoid the shortcomings of the original 332 board (large, high component count, glitch-prone). Doug, ... Thats too bad about your 332 board, I have had great luck with my units, they are solid performers. I'm puzzled by your high component count comment. It seems to me that despite the greater integration of the 555, you will need far more "components" to take advantage of the IO on the 555. Those pullups/downs and switches really add up. I'm presently designing the carrier board that will hold input buffers, signal conditioning, injector drivers, and open-collector outputs to connect to the ignition box. I expect a lot of my code to carry over, and the remainder is mostly configuration, which should be simple (no need to interface with external ADC's, etc., like on the 332 board). I developed a serial-port-based tuner program of my own that can be configured for multiple arrangements and sizes of tables (e.g. you can change table resolution without any programming changes), which I'll be updating to support floating-point data types. Hee, I just use large by huge tables right off the bat.. You can take a look at my codebase on the DIY-EFI ftp site, in /incoming; the code for the 332 is efi332-code-udsae-2005.tar.gz and the tuner program is zut-1.0.tar.gz. --Doug Brunner Paul Helmuth wrote: > ...if there is any current activity on the original EFI332 project, or > of course, an updated version of the project. > > I have been working on developing an ECU based on the > Motorola/Freescale MPC555 for some time. I am working with the Phytec > development board, the GCC tool chain, a Macraigor Wiggler, and a > Flash Programmer from Macraigor. > > I am working with a 60-2 crank trigger wheel from Electromotive (with > one of there sensors). I am using the TPU micro code from the EFI332 > FTP archive that is set up for a 60-2 input train. Same here although with slightly modified microcode. > > I have quite a bit of stuff working, though not a complete system yet. > I will be testing the ignition triggering this month, then work on > adding the fuel injection. > > I have a pretty nice lap-top monitor/tuner application that > communicates with the MPC555 through one of it's on-chip serial ports. > > In the past, I have had some questions about the TPU microcode, but I > have the major functions (PMMX, PSP12, LPWM2) working just fine now. > > Just wanted to see if there were some other nuts like me, that I could > share being nuts with. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050603/505907c0/attachment.html From Anders.Franzen at mbox2.swipnet.se Mon Jun 6 05:22:00 2005 From: Anders.Franzen at mbox2.swipnet.se (Anders Franzen) Date: Mon, 6 Jun 2005 12:22:00 +0200 Subject: [Efi332] efi332 Message-ID: <001401c56a81$93b1b6b0$6401a8c0@eemea.ericsson.se> Is this project and list dead??? I would very much like to buy the necceary pcb's (4 layer main and the rest). Or do I have to use the 2 layer design and have the pcb's done myself?? I have looked a bit at megasquirt, where it seems to be a bit more action. but since I am a techno freak I actually wanted to base an EFI on the MPC555 but that one I think is to expensive as a EFI platform, so then I decided to go with the efi332. Best regads /Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050606/a064c061/attachment.html From Steve.Ravet at arm.com Mon Jun 6 22:05:53 2005 From: Steve.Ravet at arm.com (Steve Ravet) Date: Mon, 6 Jun 2005 22:05:53 -0500 Subject: [Efi332] efi332 Message-ID: ________________________________ From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Anders Franzen Sent: Monday, June 06, 2005 5:22 AM To: efi332 at diy-efi.org Subject: [Efi332] efi332 Is this project and list dead??? Think coma, not dead. With the right stimulation it could come back to life. There are a handful of people (3?) who have taken efi332 all the way to running a car, and a lot more who have stalled out somewhere -- it's a steep learning curve. I would very much like to buy the necceary pcb's (4 layer main and the rest). Or do I have to use the 2 layer design and have the pcb's done myself?? You would be much better off getting a 4 layer board from someone on the list, or maybe Bruce has some left? If there aren't any, I have a 2 layer kit that I'm willing to deal on. That's 2 boards, one mostly populated, plus a bunch of parts. --steve From PaulHelmuth at SprintMail.com Sat Jun 11 00:27:45 2005 From: PaulHelmuth at SprintMail.com (Paul Helmuth) Date: Sat, 11 Jun 2005 00:27:45 -0500 Subject: [Efi332] H/W - S/W Question about triggering MSD type ignition box Message-ID: <015601c56e46$4c80c240$6b7ba8c0@p2450> All (all three of you), I have be swapping some email with Jeff to get some idea of where each of us were in the development process. Development that is, of projects similar to the original EFI-332 project, but based on the MPC555 chip (and in particular on the Phytec SBC - though I am not utilizing any resources that aren't directly on the MPC555). Per my exchanges with Jeff, I'm posting this query to the list. I am pretty close to doing some "ignition trigger only" testing, but would like to check a few things with some of you that have more experience than I. 1) I have set up individual TPU channels with the PSP12 function to generate the timing pulse for each of the cylinders. I have set them up in the Angle-time mode. This seems most appropriate since the external trigger isn't controlling the "dwell", just providing a timing signal. I'm reasonably confident of this, but if I'm wrong, please set me straight. 2) In order to provide the timing signal to the external ignition box (in my case a Crane Fireball system), I need to ground one of the wires going in to the control box. Since I have one TPU pin for each cylinder and I want to use the high signal from each of them to "energize" the base of a transistor (in order to "switch on" a connection to ground) - do I need to "isolate" the individual TPU pin outputs (like running them through an OR gate, or putting diodes in between each pin and the transistor base) or can they all be directly connected to the transistor base? My first concern is any potential damage to the TPU channel pins. Secondly, I wonder if having all of them common would effectively "pull down" the high signal that each of them will be generating in sequence.?.? Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050611/791572e2/attachment.html From bowtievette at aol.com Sat Jun 11 06:44:52 2005 From: bowtievette at aol.com (bowtievette at aol.com) Date: Sat, 11 Jun 2005 07:44:52 -0400 Subject: [Efi332] H/W - S/W Question about triggering MSD type ignition box In-Reply-To: <015601c56e46$4c80c240$6b7ba8c0@p2450> References: <015601c56e46$4c80c240$6b7ba8c0@p2450> Message-ID: <8C73C921D67A4A4-458-AA1F@MBLK-M33.sysops.aol.com> Hi Paul, Lemme make sure I understand your configuration. It appears that you want to use one TPU channel per cylinder and effectively join or "or" all these signals together into a single transistor switch which will in turn trigger a single Crane Ignition amplifier and then on to a distributor. To answer your question directly, you will need to provide some form of isolation between the TPU pins to get it to work, and to avoid drawing too much current from the channel that happens to be driving high while all the others are low. Diode "steering" should work but an OR gate IC with however many channels you need would work best. I use the OR gate method on one configuration of my xfi box (I need a new name since FAST stole this one already) for an application that requires a closely spaced complex pattern of triggers. That said, I'm unclear why you would want the complication of 8 TPU lines (for an 8 cylinder) when they are essentially driving a single channel output. Perhaps this is just for an interim test configuration and you intend to go to multiple coils down the road. But if you plan to run your target this way you could just use a single TPU channel and drive all 8 signals with it as is done with the efi332 software. The PSP function is set up to interrupt on the falling edge of the current cylinder's trigger signal and the ISR then re-assigns the trigger angle for the next cylinder in the firing order. You still have individual control over each cylinder's timing (if required) and avoid the addition of the OR gates and such. Works like a damn to rpms well past 10000 rpm at least. -----Original Message----- From: Paul Helmuth To: efi332 at diy-efi.org Sent: Sat, 11 Jun 2005 00:27:45 -0500 Subject: [Efi332] H/W - S/W Question about triggering MSD type ignition box All (all three of you), I have be swapping some email with Jeff to get some idea of where each of us were in the development process. Development that is, of projects similar to the original EFI-332 project, but based on the MPC555 chip (and in particular on the Phytec SBC - though I am not utilizing any resources that aren't directly on the MPC555). Per my exchanges with Jeff, I'm posting this query to the list. I am pretty close to doing some "ignition trigger only" testing, but would like to check a few things with some of you that have more experience than I. 1) I have set up individual TPU channels with the PSP12 function to generate the timing pulse for each of the cylinders. I have set them up in the Angle-time mode. This seems most appropriate since the external trigger isn't controlling the "dwell", just providing a timing signal. I'm reasonably confident of this, but if I'm wrong, please set me straight. 2) In order to provide the timing signal to the external ignition box (in my case a Crane Fireball system), I need to ground one of the wires going in to the control box. Since I have one TPU pin for each cylinder and I want to use the high signal from each of them to "energize" the base of a transistor (in order to "switch on" a connection to ground) - do I need to "isolate" the individual TPU pin outputs (like running them through an OR gate, or putting diodes in between each pin and the transistor base) or can they all be directly connected to the transistor base? My first concern is any potential damage to the TPU channel pins. Secondly, I wonder if having all of them common would effectively "pull down" the high signal that each of them will be generating in sequence.?.? Thanks, Paul _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050611/8e5bec1a/attachment.html From PaulHelmuth at SprintMail.com Sat Jun 11 12:16:03 2005 From: PaulHelmuth at SprintMail.com (Paul Helmuth) Date: Sat, 11 Jun 2005 12:16:03 -0500 Subject: [Efi332] H/W - S/W Question about triggering MSD type ignition box References: <015601c56e46$4c80c240$6b7ba8c0@p2450> <8C73C921D67A4A4-458-AA1F@MBLK-M33.sysops.aol.com> Message-ID: <016901c56ea9$3f9f4ca0$6b7ba8c0@p2450> Jeff, Thanks very much for your response. Yes - you understand my configuration correctly. I haven't looked at the EFI332 software (at least not very much), so I hadn't considered using a single TPU channel to output all of the ignition signals. My "bigger picture" thought is from the perspective of driving individual coils. However, my first application is a 1980 MGB (w/1800B 4cyl), hence the single trigger point for the ignition. It sounds like using a single channel would make the most sense (at least for my initial testing). Thanks for the tip. -Paul ----- Original Message ----- From: bowtievette at aol.com To: efi332 at diy-efi.org Sent: Saturday, June 11, 2005 6:44 AM Subject: Re: [Efi332] H/W - S/W Question about triggering MSD type ignition box Hi Paul, Lemme make sure I understand your configuration. It appears that you want to use one TPU channel per cylinder and effectively join or "or" all these signals together into a single transistor switch which will in turn trigger a single Crane Ignition amplifier and then on to a distributor. To answer your question directly, you will need to provide some form of isolation between the TPU pins to get it to work, and to avoid drawing too much current from the channel that happens to be driving high while all the others are low. Diode "steering" should work but an OR gate IC with however many channels you need would work best. I use the OR gate method on one configuration of my xfi box (I need a new name since FAST stole this one already) for an application that requires a closely spaced complex pattern of triggers. That said, I'm unclear why you would want the complication of 8 TPU lines (for an 8 cylinder) when they are essentially driving a single channel output. Perhaps this is just for an interim test configuration and you intend to go to multiple coils down the road. But if you plan to run your target this way you could just use a single TPU channel and drive all 8 signals with it as is done with the efi332 software. The PSP function is set up to interrupt on the falling edge of the current cylinder's trigger signal and the ISR then re-assigns the trigger angle for the next cylinder in the firing order. You still have individual control over each cylinder's timing (if required) and avoid the addition of the OR gates and such. Works like a damn to rpms well past 10000 rpm at least. -----Original Message----- From: Paul Helmuth To: efi332 at diy-efi.org Sent: Sat, 11 Jun 2005 00:27:45 -0500 Subject: [Efi332] H/W - S/W Question about triggering MSD type ignition box All (all three of you), I have be swapping some email with Jeff to get some idea of where each of us were in the development process. Development that is, of projects similar to the original EFI-332 project, but based on the MPC555 chip (and in particular on the Phytec SBC - though I am not utilizing any resources that aren't directly on the MPC555). Per my exchanges with Jeff, I'm posting this query to the list. I am pretty close to doing some "ignition trigger only" testing, but would like to check a few things with some of you that have more experience than I. 1) I have set up individual TPU channels with the PSP12 function to generate the timing pulse for each of the cylinders. I have set them up in the Angle-time mode. This seems most appropriate since the external trigger isn't controlling the "dwell", just providing a timing signal. I'm reasonably confident of this, but if I'm wrong, please set me straight. 2) In order to provide the timing signal to the external ignition box (in my case a Crane Fireball system), I need to ground one of the wires going in to the control box. Since I have one TPU pin for each cylinder and I want to use the high signal from each of them to "energize" the base of a transistor (in order to "switch on" a connection to ground) - do I need to "isolate" the individual TPU pin outputs (like running them through an OR gate, or putting diodes in between each pin and the transistor base) or can they all be directly connected to the transistor base? My first concern is any potential damage to the TPU channel pins. Secondly, I wonder if having all of them common would effectively "pull down" the high signal that each of them will be generating in sequence.?.? Thanks, Paul _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 ------------------------------------------------------------------------------ _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050611/93d05bb5/attachment.html From PaulHelmuth at SprintMail.com Sat Jun 11 22:12:40 2005 From: PaulHelmuth at SprintMail.com (Paul Helmuth) Date: Sat, 11 Jun 2005 22:12:40 -0500 Subject: [Efi332] Question regarding PMMX Message-ID: <017c01c56efc$983fd020$6b7ba8c0@p2450> All, Are there any particular "procedural requirements" for sending a CAM Synch request (HSRR = 1) to the PMMX function? (like disabling all linked channels, etc.) The reason that I ask is because I am testing my CAM Synch logic, and when I set the associated HSRR bits to b01, everything on the TPU stops. The only requirement that I can find in the documentation that I have is that the CAM Synch request should be made when PMMX is in the synchronized state (which it is at the point that I am making the request). Any ideas? -Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050611/fee591e6/attachment.html From PaulHelmuth at SprintMail.com Sun Jun 12 01:49:12 2005 From: PaulHelmuth at SprintMail.com (Paul Helmuth) Date: Sun, 12 Jun 2005 01:49:12 -0500 Subject: [Efi332] Question regarding PMMX References: <017c01c56efc$983fd020$6b7ba8c0@p2450> Message-ID: <018f01c56f1a$d79ed270$6b7ba8c0@p2450> I found the problem. While the documentation that I have for the PMMX function indicates a HSRR value of b01 for a CAM Sync request, the micro-code for the PMMX function (doc and code from the FTP archive) actually recognizes b10 as a CAM sync request. This little tid bit should be helpful to anyone writing their own source. Also, it would be a good idea to add a note reflecting this change in the TPU function doc (though I don't know who would do that). -Paul ----- Original Message ----- From: Paul Helmuth To: efi332 at diy-efi.org Sent: Saturday, June 11, 2005 10:12 PM Subject: [Efi332] Question regarding PMMX All, Are there any particular "procedural requirements" for sending a CAM Synch request (HSRR = 1) to the PMMX function? (like disabling all linked channels, etc.) The reason that I ask is because I am testing my CAM Synch logic, and when I set the associated HSRR bits to b01, everything on the TPU stops. The only requirement that I can find in the documentation that I have is that the CAM Synch request should be made when PMMX is in the synchronized state (which it is at the point that I am making the request). Any ideas? -Paul ------------------------------------------------------------------------------ _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050612/4b5843b8/attachment.html From BowTieVette at aol.com Sun Jun 12 07:36:06 2005 From: BowTieVette at aol.com (BowTieVette at aol.com) Date: Sun, 12 Jun 2005 08:36:06 EDT Subject: [Efi332] Question regarding PMMX Message-ID: <199.4109db3a.2fdd8636@aol.com> Paul, There is nothing on this issue (I don't use the cam synch feature) but there are some other errata and notes on the 58XX functions here that you may want to be aware of: _http://efi332.sourceforge.net/TPU.htm_ (http://efi332.sourceforge.net/TPU.htm) perhaps your notes should go here.. jc In a message dated 6/12/2005 2:49:40 AM Eastern Standard Time, PaulHelmuth at SprintMail.com writes: I found the problem. While the documentation that I have for the PMMX function indicates a HSRR value of b01 for a CAM Sync request, the micro-code for the PMMX function (doc and code from the FTP archive) actually recognizes b10 as a CAM sync request. This little tid bit should be helpful to anyone writing their own source. Also, it would be a good idea to add a note reflecting this change in the TPU function doc (though I don't know who would do that). -Paul ----- Original Message ----- From: _Paul Helmuth_ (mailto:PaulHelmuth at SprintMail.com) To: _efi332 at diy-efi.org_ (mailto:efi332 at diy-efi.org) Sent: Saturday, June 11, 2005 10:12 PM Subject: [Efi332] Question regarding PMMX All, Are there any particular "procedural requirements" for sending a CAM Synch request (HSRR = 1) to the PMMX function? (like disabling all linked channels, etc.) The reason that I ask is because I am testing my CAM Synch logic, and when I set the associated HSRR bits to b01, everything on the TPU stops. The only requirement that I can find in the documentation that I have is that the CAM Synch request should be made when PMMX is in the synchronized state (which it is at the point that I am making the request). Any ideas? -Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050612/0dd4025d/attachment.html From PaulHelmuth at SprintMail.com Sun Jun 12 21:50:08 2005 From: PaulHelmuth at SprintMail.com (Paul Helmuth) Date: Sun, 12 Jun 2005 21:50:08 -0500 Subject: [Efi332] Question regarding PMMX References: <199.4109db3a.2fdd8636@aol.com> Message-ID: <001401c56fc2$9c49d4b0$6b7ba8c0@p2450> Jeff, Thanks for the additional info. Very useful, especially the part about re-syncing. It seems that those TPU notes describe a different emulation mask from the one that I found in the archive. The code that I am working with was under ftp://ftp.diy-efi.org/pub/efi332/tpu/. The code under this directory must have been an earlier snapshot as it doesn't contain the SM, ITC, and RWTPIN referenced in the TPU Notes, and it does contain PSP3 (along with LPWM2, and PTA). At least that is what it looks like if you reference the "main8.asc" (TPUMASM build file). Do you know if there is a set of code archived that matches the description in the TPU Notes page (are you using something close to this)? I looked through the "pub" stuff and didn't find it. I don't seem to have access to "incoming" and don't see it in "uploads". Thanks again, -Paul ----- Original Message ----- From: BowTieVette at aol.com To: efi332 at diy-efi.org Sent: Sunday, June 12, 2005 7:36 AM Subject: Re: [Efi332] Question regarding PMMX Paul, There is nothing on this issue (I don't use the cam synch feature) but there are some other errata and notes on the 58XX functions here that you may want to be aware of: http://efi332.sourceforge.net/TPU.htm perhaps your notes should go here.. jc In a message dated 6/12/2005 2:49:40 AM Eastern Standard Time, PaulHelmuth at SprintMail.com writes: I found the problem. While the documentation that I have for the PMMX function indicates a HSRR value of b01 for a CAM Sync request, the micro-code for the PMMX function (doc and code from the FTP archive) actually recognizes b10 as a CAM sync request. This little tid bit should be helpful to anyone writing their own source. Also, it would be a good idea to add a note reflecting this change in the TPU function doc (though I don't know who would do that). -Paul ----- Original Message ----- From: Paul Helmuth To: efi332 at diy-efi.org Sent: Saturday, June 11, 2005 10:12 PM Subject: [Efi332] Question regarding PMMX All, Are there any particular "procedural requirements" for sending a CAM Synch request (HSRR = 1) to the PMMX function? (like disabling all linked channels, etc.) The reason that I ask is because I am testing my CAM Synch logic, and when I set the associated HSRR bits to b01, everything on the TPU stops. The only requirement that I can find in the documentation that I have is that the CAM Synch request should be made when PMMX is in the synchronized state (which it is at the point that I am making the request). Any ideas? -Paul ------------------------------------------------------------------------------ _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050612/27a4fb85/attachment.html From bowtievette at aol.com Mon Jun 13 07:57:43 2005 From: bowtievette at aol.com (bowtievette at aol.com) Date: Mon, 13 Jun 2005 08:57:43 -0400 Subject: [Efi332] Question regarding PMMX In-Reply-To: <001401c56fc2$9c49d4b0$6b7ba8c0@p2450> References: <199.4109db3a.2fdd8636@aol.com> <001401c56fc2$9c49d4b0$6b7ba8c0@p2450> Message-ID: <8C73E2E9FD3213C-85C-F761@mblk-r32.sysops.aol.com> Paul, You may want to scrub through the SourceForge code as there are a number of lessons learned embedded in there. And yes, the microcode in CVS on SourceForge is modified from what you have. Since I needed those other functions as well (SM for stepper motor IAC, rwtpin for discrete pin IO, and ITC for a cam counter), another list member and I packaged up a new combination of functions. When you compile the "stock" 58XX tpu functions with these into a custom mask, you will find that it won't fit the 332's emulation RAM. Something had to go so the crank window function psp12d was removed and pmmx8 and psp3 doctored to get them to work without psp12d. Other than that, its the same microcode. The 555 has more emulation ram available so even if you need these extra functions, they should fit. Jeff -----Original Message----- From: Paul Helmuth To: efi332 at diy-efi.org Sent: Sun, 12 Jun 2005 21:50:08 -0500 Subject: Re: [Efi332] Question regarding PMMX Jeff, Thanks for the additional info. Very useful, especially the part about re-syncing. It seems that those TPU notes describe a different emulation mask from the one that I found in the archive. The code that I am working with was under ftp://ftp.diy-efi.org/pub/efi332/tpu/. The code under this directory must have been an earlier snapshot as it doesn't contain the SM, ITC, and RWTPIN referenced in the TPU Notes, and it does contain PSP3 (along with LPWM2, and PTA). At least that is what it looks like if you reference the "main8.asc" (TPUMASM build file). Do you know if there is a set of code archived that matches the description in the TPU Notes page (are you using something close to this)? I looked through the "pub" stuff and didn't find it. I don't seem to have access to "incoming" and don't see it in "uploads". Thanks again, -Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050613/11da25a5/attachment.html From PaulHelmuth at SprintMail.com Tue Jun 14 00:47:37 2005 From: PaulHelmuth at SprintMail.com (Paul Helmuth) Date: Tue, 14 Jun 2005 00:47:37 -0500 Subject: [Efi332] Question regarding PMMX References: <199.4109db3a.2fdd8636@aol.com><001401c56fc2$9c49d4b0$6b7ba8c0@p2450> <8C73E2E9FD3213C-85C-F761@mblk-r32.sysops.aol.com> Message-ID: <003b01c570a4$926ad6f0$6b7ba8c0@p2450> Jeff, Thanks. I'll hunt through SourceForge and see what I can find. -Paul ----- Original Message ----- From: bowtievette at aol.com To: efi332 at diy-efi.org Sent: Monday, June 13, 2005 7:57 AM Subject: Re: [Efi332] Question regarding PMMX Paul, You may want to scrub through the SourceForge code as there are a number of lessons learned embedded in there. And yes, the microcode in CVS on SourceForge is modified from what you have. Since I needed those other functions as well (SM for stepper motor IAC, rwtpin for discrete pin IO, and ITC for a cam counter), another list member and I packaged up a new combination of functions. When you compile the "stock" 58XX tpu functions with these into a custom mask, you will find that it won't fit the 332's emulation RAM. Something had to go so the crank window function psp12d was removed and pmmx8 and psp3 doctored to get them to work without psp12d. Other than that, its the same microcode. The 555 has more emulation ram available so even if you need these extra functions, they should fit. Jeff -----Original Message----- From: Paul Helmuth To: efi332 at diy-efi.org Sent: Sun, 12 Jun 2005 21:50:08 -0500 Subject: Re: [Efi332] Question regarding PMMX Jeff, Thanks for the additional info. Very useful, especially the part about re-syncing. It seems that those TPU notes describe a different emulation mask from the one that I found in the archive. The code that I am working with was under ftp://ftp.diy-efi.org/pub/efi332/tpu/. The code under this directory must have been an earlier snapshot as it doesn't contain the SM, ITC, and RWTPIN referenced in the TPU Notes, and it does contain PSP3 (along with LPWM2, and PTA). At least that is what it looks like if you reference the "main8.asc" (TPUMASM build file). Do you know if there is a set of code archived that matches the description in the TPU Notes page (are you using something close to this)? I looked through the "pub" stuff and didn't find it. I don't seem to have access to "incoming" and don't see it in "uploads". Thanks again, -Paul ------------------------------------------------------------------------------ _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050614/c220f981/attachment.html From bowtievette at aol.com Tue Jun 14 12:54:52 2005 From: bowtievette at aol.com (bowtievette at aol.com) Date: Tue, 14 Jun 2005 13:54:52 -0400 Subject: [Efi332] XFI555 GNU C Questions In-Reply-To: <6CFFB0592543734E9A09610C738B4E0404EDD6@cvit2k3.CVITLAN.local> References: <6CFFB0592543734E9A09610C738B4E0404EDD6@cvit2k3.CVITLAN.local> Message-ID: <8C73F214CC8290E-A18-17D5F@mblk-r41.sysops.aol.com> Paul, What was the nature of your problems with the 58XX mask set? FWIW, Peter was using the same microcode that I have been working with. In any event, there are only two sets of 58XX code that I have seen. One is the original 58XX code that came to this list years ago, and the other is slightly modified from that to have a slightly smaller RAM footprint. Were you able to get the Motorola mask set to work with the 60-2 crank wheel pattern? If so, I'd be curious to evaluate that setup against the 58XX. >David, > >This isn?t in response (at least not directly) to your question/post regarding >the GNU tool chain. However, I may be able to help you with some things. I >have been working (by myself) on an MPC555 based engine management system for >some time now. Of course, the going is a bit slow when you are doing everything >yourself. Anyway, I am also using the GNU tool chain and a Phytec 555 >development board ? so I may be able to answer a lot of questions (but not >necessarily, as I am learning this as I go). I would be very interested to >learn if there is any "current" archive or copy of the TPU code that was/is >being used. I was unable to get a related emulation mask (one that Pieter >Siebold used in the AEMS555 project) to work. However, I have had some luck >using a standard automotive mask available form Motorola (TPUMSKAB). That >being said, from what I have seen the mask developed for the EFI332 project >would be ideally suited (as I am using a 60 minus 2 crank wheel and many >features are nicely accommodated ? as far as I can tell). > >Is there any active copy of this mask that folks are working on? > >Paul A. Helmuth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050614/8ff926a4/attachment.html From sailors3 at comcast.net Wed Jun 15 00:38:27 2005 From: sailors3 at comcast.net (sailors3 at comcast.net) Date: Wed, 15 Jun 2005 05:38:27 +0000 Subject: [Efi332] XFI555 GNU C Questions Message-ID: <061520050538.22413.42AFBED0000D2F440000578D2200734748CC9C9D0104070E9C@comcast.net> Hi Paul, I have not gotten far enough on the project yet to have learned anything about the mask sets. So..., Jeff is your best bet for insight in that area. I will be learning about that soon though, I believe. It is exciting that you are doing the same thing I am (GNU/Phytec555)! We need to stay in contact and share info, for sure! I'm not even that far from you in Iowa, maybe we can meet somewhere when we are driving our efi cars to view each other's project. I am putting this efi on my LS1 engine, which has a built in crank sensor. I would prefer to use that, but as Jeff pointed out, it is a very different approach to position sensing and represents a separate project all by itself. In the meantime, I suppose I will figure out how to mount a 60-2 wheel also (which might be a project all by itself). I will need to figure out the cam sensor too, it might just be one pulse per revolution. looking forward to working with you more! regards, dave -------------- Original message -------------- David, This isn?t in response (at least not directly) to your question/post regarding the GNU tool chain. However, I may be able to help you with some things. I have been working (by myself) on an MPC555 based engine management system for some time now. Of course, the going is a bit slow when you are doing everything yourself. Anyway, I am also using the GNU tool chain and a Phytec 555 development board ? so I may be able to answer a lot of questions (but not necessarily, as I am learning this as I go). I would be very interested to learn if there is any ?current? archive or copy of the TPU code that was/is being used. I was unable to get a related emulation mask (one that Pieter Siebold used in the AEMS555 project) to work. However, I have had some luck using a standard automotive mask available form Motorola (TPUMSKAB). That being said, from what I have seen the mask developed for the EFI332 project would be ideally suited (as I am using a 60 minus 2 crank wheel and many features are nicely accommodated ? as far as I can tell). Is there any active copy of this mask that folks are working on? Paul A. Helmuth Software Development Cardiovascular Imaging Technologies 4320 Wornall Road Suite 55 Kansas City, MO 64111-5966 (816)531-2842 ext.#109 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050615/9e0d553d/attachment.html -------------- next part -------------- An embedded message was scrubbed... From: "Paul Helmuth" Subject: [Efi332] XFI555 GNU C Questions Date: Tue, 14 Jun 2005 17:29:18 +0000 Size: 694 Url: http://lists.diy-efi.org/pipermail/efi332/attachments/20050615/9e0d553d/attachment.mht From PaulHelmuth at SprintMail.com Wed Jun 29 16:37:06 2005 From: PaulHelmuth at SprintMail.com (Paul Helmuth) Date: Wed, 29 Jun 2005 16:37:06 -0500 Subject: [Efi332] HW Question (for JC) Message-ID: <00ee01c57cf2$b272b940$6b7ba8c0@p2450> Jeff, I managed to source a couple of National LM2940T (9volt output) regulators. I am hoping to use this part to power my Phytec development board from the car's 12v battery. The "Typical Application" section of the data sheet shows only two external components. One is a .47 microfarad capacitor on V-in to ground. An asterisk note indicates that this is required if the regulator is located far from the "power supply filter". Which seems to imply that there should be some filtering in place between the battery and the regulator (though there is no diagram of what such a filter should look like). The second external component is a 22 microfarad (minimum) capacitor on V-out to ground. The interesting note on the output capacitor is that the equivalent series resistance is critical. Reading the performance characteristics table relating to the output capacitor ESR, I see that I need to use a capacitor with an ESR between .1 and 1 ohm. I have never seen ESR given for capacitors. Can you give me any pointers as to how I can determine and arrive at an acceptable ESR for the output capacitor(s)? Thanks, -Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050629/a198cd1a/attachment.html From bowtievette at aol.com Wed Jun 29 20:44:57 2005 From: bowtievette at aol.com (bowtievette at aol.com) Date: Wed, 29 Jun 2005 21:44:57 -0400 Subject: [Efi332] HW Question (for JC) In-Reply-To: <00ee01c57cf2$b272b940$6b7ba8c0@p2450> References: <00ee01c57cf2$b272b940$6b7ba8c0@p2450> Message-ID: <8C74B2C7469CC18-CA0-7F5A@FWM-R26.sysops.aol.com> Hi Paul, I would include the 47uF on the input side. I don't think you will have any problems with it running from the car's battery/alternator. On the output side, you're right, ESR values are typically not quoted in catalogs other than to say low ESR, so you usually have to dig up the datasheet(s) to get the tables for it. If you do a search for low ESR capacitor at digikey it will narrow the search to caps that advertise low ESR. Pick a 22 uF one from the selection table presented and follow it to the datasheet. For this application, aluminum electrolytics are common, and occasionally tantalums. Some folks recommend against using tantalums in power supplies since they have a tendency to blow up under rapid transient conditions. With the electrolytics, you may have to watch the temperature variation since the ESR varies quite a bit. -----Original Message----- From: Paul Helmuth To: efi332 at diy-efi.org Sent: Wed, 29 Jun 2005 16:37:06 -0500 Subject: [Efi332] HW Question (for JC) Jeff, I managed to source a couple of National LM2940T (9volt output) regulators. I am hoping to use this part to power my Phytec development board from the car's 12v battery. The "Typical Application" section of the data sheet shows only two external components. One is a .47 microfarad capacitor on V-in to ground. An asterisk note indicates that this is required if the regulator is located far from the "power supply filter". Which seems to imply that there should be some filtering in place between the battery and the regulator (though there is no diagram of what such a filter should look like). The second external component is a 22 microfarad (minimum) capacitor on V-out to ground. The interesting note on the output capacitor is that the equivalent series resistance is critical. Reading the performance characteristics table relating to the output capacitor ESR, I see that I need to use a capacitor with an ESR between .1 and 1 ohm. I have never seen ESR given for capacitors. Can you give me any pointers as to how I can determine and arrive at an acceptable ESR for the output capacitor(s)? Thanks, -Paul _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050629/e811bea1/attachment.html