From smale at ncinternet.net Sat Oct 1 10:52:05 2005 From: smale at ncinternet.net (C SMALE) Date: Sat, 01 Oct 2005 08:52:05 -0700 Subject: [Efi332] password Message-ID: <433EB0A5.6020504@ncinternet.net> defiant From sailors3 at comcast.net Mon Oct 10 08:23:34 2005 From: sailors3 at comcast.net (David Eicher) Date: Mon, 10 Oct 2005 06:23:34 -0700 Subject: [Efi332] Requirements Design Document for EFI Message-ID: Hello, Has anyone written a requirements and/or design document for EFI or engine management that they would care to share? Thanks, Dave From friction at iinet.net.au Wed Oct 12 03:47:24 2005 From: friction at iinet.net.au (Bryan Hope) Date: Wed, 12 Oct 2005 16:47:24 +0800 Subject: [Efi332] (no subject) Message-ID: <000901c5cf09$925c3960$c0b63bcb@oemcomputer> From sailors3 at comcast.net Wed Oct 12 08:22:58 2005 From: sailors3 at comcast.net (David Eicher) Date: Wed, 12 Oct 2005 06:22:58 -0700 Subject: [Efi332] Queued Serial IO on the MPC555... In-Reply-To: <10af01c5b6f7$000c9890$6b7ba8c0@p2450> Message-ID: Hi Paul, Any progress on the queued serial I/O? Getting that working on the MPC555 is my next task (with interrupts). Maybe we can compare notes as we go along on it here and help each other. For a starting point I want to see what the Quickstart package says about it, and build on that foundation (use that interface to the hardware for both access to the QSCI and for interrupt handling). Is that your approach? More later when I get something built and try to run it. thanks, dave _____ From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Paul Helmuth Sent: Sunday, September 11, 2005 9:34 AM To: efi332 at diy-efi.org Subject: [Efi332] Queued Serial IO on the MPC555... All, My "ignition only" testing has gone flawlessly. I had some initial issues with my sensor mount not being rigid enough (engine vibration would cause the crank trigger signal to get mangled such that PMMX would lose synch), but an additional bracket (from the tip of the sensor mount back to the block) has that under control. I have a lot of stuff to do to add the fuel injection side, but one critical piece of the puzzle will be to implement queued serial I/O. Right now I am just the simple "direct/immediate" I/O routines (you see these everywhere in various sample code for the 555 - I think Axiom may have been the original author?). I have seen a few comments from the group that indicate there are some problems getting the queued serial I/O to work (at least reliably, consistently, predictably). That's a little disconcerting, but I'd like to see if I get it sorted out. I have taken a look at Jeff Clark's source from the 332 project, but I was wondering if any of you may have some work in progress on the 555 platform that I could use as a starting point? Needless to say, I would make my results available to the group. It would also be great to collect a "bug list" - that is, to understand any existing problems that you guys have seen. I have heard there are problems, but I don't recall seeing any specifics. Hope all is going at least as well for your projects. -Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20051012/f1470153/attachment.html From PaulHelmuth at SprintMail.com Thu Oct 13 13:44:25 2005 From: PaulHelmuth at SprintMail.com (Paul Helmuth) Date: Thu, 13 Oct 2005 13:44:25 -0500 Subject: [Efi332] Queued Serial IO on the MPC555... References: <200510120925.1epGBDaH3Nl34m1@mx-casero.atl.sa.earthlink.net> Message-ID: <002901c5d026$230cc020$6b7ba8c0@p2450> Dave, I started out reviewing the code that Jeff Clark had implemented in the original 332 project (which was essentially the code from a Motorola Application Note). After that, I found the original application note in the Freescale archives and reviewed it. Finally, I decided that it would be best to simply go through the 555 documentation (Section-14 Queued Serial Multi-channel Module) and implement from that. For myself, I am only interested in the serial communications interfaces (DSCI: SCI1 and SCI2). As I am not planning on doing any hardware interfaces with the QSPI. I assume the SCI stuff is what most guys on this list will be interested in - for communication with remote tuning and monitoring applications. After having read the documentation, I think it should be relatively simple to enable interrupts and add an interrupt service routine to read incoming data in to a buffer - and conversely send outbound data from a queue/buffer. I think initially I would do this without taking advantage of the built in Queue capabilities in the QSMCM. As this would be a nice small step to take that would limit the number of potential sources for trouble (always a bonus in development). This would also be roughly equivalent to the interrupt/queued support in the original 332 project. Once everything was working well using the interrupts, then I would add the internal queue support. I doubt that many of us will "need" that to free up CPU cycles, but as a technology guy you have to use it if its there. So, those are my thoughts. If I had some more time (or fewer things to do) I would already have this plan implemented (at least partially), but I should be spending a few cycles on it within the next week or so. So I may have a working version of Phase-I pretty soon. How does this approach sound to you? -Paul ----- Original Message ----- From: David Eicher To: efi332 at diy-efi.org Sent: Wednesday, October 12, 2005 8:22 AM Subject: RE: [Efi332] Queued Serial IO on the MPC555... Hi Paul, Any progress on the queued serial I/O? Getting that working on the MPC555 is my next task (with interrupts). Maybe we can compare notes as we go along on it here and help each other. For a starting point I want to see what the Quickstart package says about it, and build on that foundation (use that interface to the hardware for both access to the QSCI and for interrupt handling). Is that your approach? More later when I get something built and try to run it. thanks, dave ------------------------------------------------------------------------------ From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Paul Helmuth Sent: Sunday, September 11, 2005 9:34 AM To: efi332 at diy-efi.org Subject: [Efi332] Queued Serial IO on the MPC555... All, My "ignition only" testing has gone flawlessly. I had some initial issues with my sensor mount not being rigid enough (engine vibration would cause the crank trigger signal to get mangled such that PMMX would lose synch), but an additional bracket (from the tip of the sensor mount back to the block) has that under control. I have a lot of stuff to do to add the fuel injection side, but one critical piece of the puzzle will be to implement queued serial I/O. Right now I am just the simple "direct/immediate" I/O routines (you see these everywhere in various sample code for the 555 - I think Axiom may have been the original author?). I have seen a few comments from the group that indicate there are some problems getting the queued serial I/O to work (at least reliably, consistently, predictably). That's a little disconcerting, but I'd like to see if I get it sorted out. I have taken a look at Jeff Clark's source from the 332 project, but I was wondering if any of you may have some work in progress on the 555 platform that I could use as a starting point? Needless to say, I would make my results available to the group. It would also be great to collect a "bug list" - that is, to understand any existing problems that you guys have seen. I have heard there are problems, but I don't recall seeing any specifics. Hope all is going at least as well for your projects. -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/20051013/258707af/attachment.html From bowtievette at aol.com Thu Oct 13 14:21:15 2005 From: bowtievette at aol.com (bowtievette at aol.com) Date: Thu, 13 Oct 2005 15:21:15 -0400 Subject: [Efi332] Queued Serial IO on the MPC555... In-Reply-To: <002901c5d026$230cc020$6b7ba8c0@p2450> References: <200510120925.1epGBDaH3Nl34m1@mx-casero.atl.sa.earthlink.net> <002901c5d026$230cc020$6b7ba8c0@p2450> Message-ID: <8C79E426A30E9C4-164C-31F0B@MBLK-M02.sysops.aol.com> Paul, Dave, The 332 implementation of the 'regular' SCI is easily ported to the 555. In fact, all the registers are the same with slightly different names, and even the bit assignments in the status register are the same so its a very easy port and a good first step. Depending on how much data you want to flow, this may be an ok solution, or more effort may be in order. To understand why, consider this. Every stack frame save and restore consumes about 150 usec on the 555 assuming no corner cutting i.e you save everything including all the floating point registers. On the regular SCI, every byte in and out triggers an interrupt. If you use all the processor bandwidth to handle these, that means it can handle about 6666 bytes/second. My current efi332 setup sends about 1500 bytes per second, or 150 bytes per frame at 10 Hz. Even with that throughput, serial comm handling consumes almost a quarter of the processor. Obviously, you'd like to go the other way, i.e. pump out more data and/or at higher rates and use less processor to do it. The 68332 is doing fine with this level of overhead, so you're probably wondering why is the 555 so much less efficient; doesn't it run at more than twice the speed (nominally 40 MHz, vs 16 MHz)? The trouble is with the floating point stuff. The 555 has many 64 bit floating point registers that need to be saved and restored. One can get by with less overhead by refraining from doing floating point operations, but thats a major attraction of the chip in the first place. You could simplify the stack frame for this interrupt only and gain some speed but if you are involving an OS, maintaining a consistent stack frame is desirable. The real improvement potential is to use the queueing feature which can cut interrupt traffic by a factor of 8. I think Mot put this in to bolster up the SCI in terms of throughput without going to the expense of a dedicated serial comm controller. I wish they had just put the SCC in. The queued SCI appears to be simple enough from the manual, but is difficult to get working. I have made a superficial attempt but was unsuccessful. In reading the MPC500 list, it appears many others have spent significant effort and not got it working. Unfortunately Mot support is lacking in this area, and direct posts on the subject have gotten no response. I'm sure the module works, but there are some secrets to be understood there. Maybe we can get it working between us. >Dave, > >I started out reviewing the code that Jeff Clark had implemented in the original 332 project (which was essentially the code from a Motorola Application Note). After that, I found the original application note in the Freescale archives and reviewed it. > >Finally, I decided that it would be best to simply go through the 555 documentation (Section-14 Queued Serial Multi-channel Module) and implement from that. > >For myself, I am only interested in the serial communications interfaces (DSCI: SCI1 and SCI2). As I am not planning on doing any hardware interfaces with the QSPI. I assume the SCI stuff is what most guys on this list will be interested in - for communication with remote tuning and monitoring applications. > >After having read the documentation, I think it should be relatively simple to enable interrupts and add an interrupt service routine to read incoming data in to a buffer - and conversely send outbound data from a queue/buffer. > >I think initially I would do this without taking advantage of the built in Queue capabilities in the QSMCM. As this would be a nice small step to take that would limit the number of potential sources for trouble (always a bonus in development). This would also be roughly equivalent to the interrupt/queued support in the original 332 project. > >Once everything was working well using the interrupts, then I would add the internal queue support. I doubt that many of us will "need" that to free up CPU cycles, but as a technology guy you have to use it if its there. > >So, those are my thoughts. If I had some more time (or fewer things to do) I would already have this plan implemented (at least partially), but I should be spending a few cycles on it within the next week or so. So I may have a working version of Phase-I pretty soon. > >How does this approach sound to you? > >-Paul >>----- Original Message ----- >>From: David Eicher >>To: efi332 at diy-efi.org >>Sent: Wednesday, October 12, 2005 8:22 AM >>Subject: RE: [Efi332] Queued Serial IO on the MPC555... >> >> >>Hi Paul, >> >>Any progress on the queued serial I/O? >> >>Getting that working on the MPC555 is my next task (with interrupts). Maybe we can compare notes as we go along on it here and help each other. >> >>For a starting point I want to see what the Quickstart package says about it, and build on that foundation (use that interface to the hardware for both access to the QSCI and for interrupt handling). Is that your approach? >> >>More later when I get something built and try to run it. >> >>thanks, >> >>dave >> >> >> >> >>>-------------------------------------------------------------------------------- >>>From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Paul Helmuth >>>Sent: Sunday, September 11, 2005 9:34 AM >>>To: efi332 at diy-efi.org >>>Subject: [Efi332] Queued Serial IO on the MPC555... >>> >>> >>>All, >>> >>>My "ignition only" testing has gone flawlessly. I had some initial issues with my sensor mount not being rigid enough (engine vibration would cause the crank trigger signal to get mangled such that PMMX would lose synch), but an additional bracket (from the tip of the sensor mount back to the block) has that under control. >>> >>>I have a lot of stuff to do to add the fuel injection side, but one critical piece of the puzzle will be to implement queued serial I/O. Right now I am just the simple "direct/immediate" I/O routines (you see these everywhere in various sample code for the 555 - I think Axiom may have been the original author?). >>> >>>I have seen a few comments from the group that indicate there are some problems getting the queued serial I/O to work (at least reliably, consistently, predictably). That's a little disconcerting, but I'd like to see if I get it sorted out. >>> >>>I have taken a look at Jeff Clark's source from the 332 project, but I was wondering if any of you may have some work in progress on the 555 platform that I could use as a starting point? >>> >>>Needless to say, I would make my results available to the group. >>> >>>It would also be great to collect a "bug list" - that is, to understand any existing problems that you guys have seen. I have heard there are problems, but I don't recall seeing any specifics. >>> >>>Hope all is going at least as well for your projects. >>> >>>-Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20051013/a9a7a43f/attachment.html From r_d_gullickson at yahoo.com.au Thu Oct 13 17:45:33 2005 From: r_d_gullickson at yahoo.com.au (Rodney Gullickson) Date: Fri, 14 Oct 2005 08:45:33 +1000 (EST) Subject: [Efi332] Queued Serial IO on the MPC555... In-Reply-To: <8C79E426A30E9C4-164C-31F0B@MBLK-M02.sysops.aol.com> Message-ID: <20051013224533.66151.qmail@web90210.mail.scd.yahoo.com> Hi all, I have just recently joined the mailing list - found it via the MegaSquirt page. I am interested in this project from 2 fronts - 1. I have a Lucas efi system on a Landrover that is misbehaving and I would like to replace it, tune it and learn more about efi and engine tuning, and 2. At my current place of employment (I am an embedded software engineer), we use both a MPC860 and a MPC509 and use heaps of features on these. The 509 is no longer produced though, so an upgrade will be needed soon....! Maybe the 555 will be only a minor upgrade. Anyway, I understand that we use the queued serial, although it may be in a basic form. I will attempt to have a bit of a dig and see what is in there, how relevant it is to the 555 and how it is being used. The code is within a commerical codebase, however the mechanism of setting up the chip will be useful. On another front, what hardware is everyone using? Is there a kit or PCB available, or have people just been building their own? Regards, Rodney --- bowtievette at aol.com wrote: > Paul, Dave, > The 332 implementation of the 'regular' SCI is > easily ported to the 555. In fact, all the registers > are the same with slightly different names, and even > the bit assignments in the status register are the > same so its a very easy port and a good first step. > Depending on how much data you want to flow, this > may be an ok solution, or more effort may be in > order. > > To understand why, consider this. Every stack frame > save and restore consumes about 150 usec on the 555 > assuming no corner cutting i.e you save everything > including all the floating point registers. On the > regular SCI, every byte in and out triggers an > interrupt. If you use all the processor bandwidth to > handle these, that means it can handle about 6666 > bytes/second. > > My current efi332 setup sends about 1500 bytes per > second, or 150 bytes per frame at 10 Hz. Even with > that throughput, serial comm handling consumes > almost a quarter of the processor. Obviously, you'd > like to go the other way, i.e. pump out more data > and/or at higher rates and use less processor to do > it. > > The 68332 is doing fine with this level of overhead, > so you're probably wondering why is the 555 so much > less efficient; doesn't it run at more than twice > the speed (nominally 40 MHz, vs 16 MHz)? The trouble > is with the floating point stuff. The 555 has many > 64 bit floating point registers that need to be > saved and restored. One can get by with less > overhead by refraining from doing floating point > operations, but thats a major attraction of the chip > in the first place. You could simplify the stack > frame for this interrupt only and gain some speed > but if you are involving an OS, maintaining a > consistent stack frame is desirable. The real > improvement potential is to use the queueing feature > which can cut interrupt traffic by a factor of 8. I > think Mot put this in to bolster up the SCI in terms > of throughput without going to the expense of a > dedicated serial comm controller. I wish they had > just put the SCC in. > > The queued SCI appears to be simple enough from the > manual, but is difficult to get working. I have made > a superficial attempt but was unsuccessful. In > reading the MPC500 list, it appears many others have > spent significant effort and not got it working. > Unfortunately Mot support is lacking in this area, > and direct posts on the subject have gotten no > response. I'm sure the module works, but there are > some secrets to be understood there. Maybe we can > get it working between us. > > > > > > >Dave, > > > >I started out reviewing the code that Jeff Clark > had implemented in the original 332 project (which > was essentially the code from a Motorola Application > Note). After that, I found the original application > note in the Freescale archives and reviewed it. > > > >Finally, I decided that it would be best to simply > go through the 555 documentation (Section-14 Queued > Serial Multi-channel Module) and implement from > that. > > > >For myself, I am only interested in the serial > communications interfaces (DSCI: SCI1 and SCI2). As > I am not planning on doing any hardware interfaces > with the QSPI. I assume the SCI stuff is what most > guys on this list will be interested in - for > communication with remote tuning and monitoring > applications. > > > >After having read the documentation, I think it > should be relatively simple to enable interrupts and > add an interrupt service routine to read incoming > data in to a buffer - and conversely send outbound > data from a queue/buffer. > > > >I think initially I would do this without taking > advantage of the built in Queue capabilities in the > QSMCM. As this would be a nice small step to take > that would limit the number of potential sources for > trouble (always a bonus in development). This would > also be roughly equivalent to the interrupt/queued > support in the original 332 project. > > > >Once everything was working well using the > interrupts, then I would add the internal queue > support. I doubt that many of us will "need" that to > free up CPU cycles, but as a technology guy you have > to use it if its there. > > > >So, those are my thoughts. If I had some more time > (or fewer things to do) I would already have this > plan implemented (at least partially), but I should > be spending a few cycles on it within the next week > or so. So I may have a working version of Phase-I > pretty soon. > > > >How does this approach sound to you? > > > >-Paul > >>----- Original Message ----- > >>From: David Eicher > >>To: efi332 at diy-efi.org > >>Sent: Wednesday, October 12, 2005 8:22 AM > >>Subject: RE: [Efi332] Queued Serial IO on the > MPC555... > >> > >> > >>Hi Paul, > >> > >>Any progress on the queued serial I/O? > >> > >>Getting that working on the MPC555 is my next task > (with interrupts). Maybe we can compare notes as we > go along on it here and help each other. > >> > >>For a starting point I want to see what the > Quickstart package says about it, and build on that > foundation (use that interface to the hardware for > both access to the QSCI and for interrupt handling). > Is that your approach? > >> > >>More later when I get something built and try to > run it. > >> > >>thanks, > >> > >>dave > >> > >> > >> > >> > >>>-------------------------------------------------------------------------------- > >>>From: efi332-bounces at diy-efi.org > [mailto:efi332-bounces at diy-efi.org] On Behalf Of > Paul Helmuth > >>>Sent: Sunday, September 11, 2005 9:34 AM > >>>To: efi332 at diy-efi.org > >>>Subject: [Efi332] Queued Serial IO on the > MPC555... > >>> > >>> > >>>All, > >>> > >>>My "ignition only" testing has gone flawlessly. I > had some initial issues with my sensor mount not > being rigid enough (engine vibration would cause the > crank trigger signal to get mangled such that PMMX > would lose synch), but an additional bracket (from > the tip of the sensor mount back to the block) has > that under control. > >>> > >>>I have a lot of stuff to do to add the fuel > injection side, but one critical piece of the puzzle > will be to implement queued serial I/O. Right now I > am just the simple "direct/immediate" I/O routines > (you see these everywhere in various sample code for > the 555 - I think Axiom may have been the original > author?). > >>> > >>>I have seen a few comments from the group that > indicate there are some problems getting the queued > serial I/O to work (at least reliably, consistently, > predictably). That's a little disconcerting, but I'd > like to see if I get it sorted out. > >>> > >>>I have taken a look at Jeff Clark's source from > the 332 project, but I was wondering if any of you > may have some work in progress on the 555 platform > that I could use as a starting point? > >>> > >>>Needless to say, I would make my results > available to the group. > >>> > >>>It would also be great to collect a "bug list" - > that is, to understand any existing problems that > you guys have seen. I have heard there are problems, > but I don't recall seeing any specifics. > >>> > >>>Hope all is going at least as well for your > projects. > >>> > >>>-Paul > > _______________________________________________ > Efi332 mailing list > Efi332 at diy-efi.org > http://lists.diy-efi.org/mailman/listinfo/efi332 > ____________________________________________________ Do you Yahoo!? The New Yahoo! Movies: Check out the Latest Trailers, Premiere Photos and full Actor Database. http://au.movies.yahoo.com From bowtievette at aol.com Thu Oct 13 20:09:07 2005 From: bowtievette at aol.com (bowtievette at aol.com) Date: Thu, 13 Oct 2005 21:09:07 -0400 Subject: [Efi332] Queued Serial IO on the MPC555... In-Reply-To: <20051013224533.66151.qmail@web90210.mail.scd.yahoo.com> Message-ID: <8C79E7302C30AD7-15C4-14F2@mblk-d43.sysops.aol.com> Hi Rodney, Welcome to the list. I've been looking to see if the qsci is used on other freescale chips to no avail so far. I'm not sure about the 509, but I think the 860 is considerably more well endowed than the 555 in the serial comm department with 4 SCC's. In terms of hardware, there are a few efi332 systems still kicking but most of the traffic on this list lately (what little there has been) has been about the 555. There are a few folks working separate solutions with different hardware, although everyone seems to be using the Phycore module. I have a pretty complete custom hardware solution using a carrier board built around the PhyCore module and I think Paul is working directly with the Phytec development board. Jeff -----Original Message----- From: Rodney Gullickson To: efi332 at diy-efi.org Sent: Fri, 14 Oct 2005 08:45:33 +1000 (EST) Subject: Re: [Efi332] Queued Serial IO on the MPC555... Hi all, I have just recently joined the mailing list - found it via the MegaSquirt page. I am interested in this project from 2 fronts - 1. I have a Lucas efi system on a Landrover that is misbehaving and I would like to replace it, tune it and learn more about efi and engine tuning, and 2. At my current place of employment (I am an embedded software engineer), we use both a MPC860 and a MPC509 and use heaps of features on these. The 509 is no longer produced though, so an upgrade will be needed soon....! Maybe the 555 will be only a minor upgrade. Anyway, I understand that we use the queued serial, although it may be in a basic form. I will attempt to have a bit of a dig and see what is in there, how relevant it is to the 555 and how it is being used. The code is within a commerical codebase, however the mechanism of setting up the chip will be useful. On another front, what hardware is everyone using? Is there a kit or PCB available, or have people just been building their own? Regards, Rodney --- bowtievette at aol.com wrote: > Paul, Dave, > The 332 implementation of the 'regular' SCI is > easily ported to the 555. In fact, all the registers > are the same with slightly different names, and even > the bit assignments in the status register are the > same so its a very easy port and a good first step. > Depending on how much data you want to flow, this > may be an ok solution, or more effort may be in > order. > > To understand why, consider this. Every stack frame > save and restore consumes about 150 usec on the 555 > assuming no corner cutting i.e you save everything > including all the floating point registers. On the > regular SCI, every byte in and out triggers an > interrupt. If you use all the processor bandwidth to > handle these, that means it can handle about 6666 > bytes/second. > > My current efi332 setup sends about 1500 bytes per > second, or 150 bytes per frame at 10 Hz. Even with > that throughput, serial comm handling consumes > almost a quarter of the processor. Obviously, you'd > like to go the other way, i.e. pump out more data > and/or at higher rates and use less processor to do > it. > > The 68332 is doing fine with this level of overhead, > so you're probably wondering why is the 555 so much > less efficient; doesn't it run at more than twice > the speed (nominally 40 MHz, vs 16 MHz)? The trouble > is with the floating point stuff. The 555 has many > 64 bit floating point registers that need to be > saved and restored. One can get by with less > overhead by refraining from doing floating point > operations, but thats a major attraction of the chip > in the first place. You could simplify the stack > frame for this interrupt only and gain some speed > but if you are involving an OS, maintaining a > consistent stack frame is desirable. The real > improvement potential is to use the queueing feature > which can cut interrupt traffic by a factor of 8. I > think Mot put this in to bolster up the SCI in terms > of throughput without going to the expense of a > dedicated serial comm controller. I wish they had > just put the SCC in. > > The queued SCI appears to be simple enough from the > manual, but is difficult to get working. I have made > a superficial attempt but was unsuccessful. In > reading the MPC500 list, it appears many others have > spent significant effort and not got it working. > Unfortunately Mot support is lacking in this area, > and direct posts on the subject have gotten no > response. I'm sure the module works, but there are > some secrets to be understood there. Maybe we can > get it working between us. > > > > > > >Dave, > > > >I started out reviewing the code that Jeff Clark > had implemented in the original 332 project (which > was essentially the code from a Motorola Application > Note). After that, I found the original application > note in the Freescale archives and reviewed it. > > > >Finally, I decided that it would be best to simply > go through the 555 documentation (Section-14 Queued > Serial Multi-channel Module) and implement from > that. > > > >For myself, I am only interested in the serial > communications interfaces (DSCI: SCI1 and SCI2). As > I am not planning on doing any hardware interfaces > with the QSPI. I assume the SCI stuff is what most > guys on this list will be interested in - for > communication with remote tuning and monitoring > applications. > > > >After having read the documentation, I think it > should be relatively simple to enable interrupts and > add an interrupt service routine to read incoming > data in to a buffer - and conversely send outbound > data from a queue/buffer. > > > >I think initially I would do this without taking > advantage of the built in Queue capabilities in the > QSMCM. As this would be a nice small step to take > that would limit the number of potential sources for > trouble (always a bonus in development). This would > also be roughly equivalent to the interrupt/queued > support in the original 332 project. > > > >Once everything was working well using the > interrupts, then I would add the internal queue > support. I doubt that many of us will "need" that to > free up CPU cycles, but as a technology guy you have > to use it if its there. > > > >So, those are my thoughts. If I had some more time > (or fewer things to do) I would already have this > plan implemented (at least partially), but I should > be spending a few cycles on it within the next week > or so. So I may have a working version of Phase-I > pretty soon. > > > >How does this approach sound to you? > > > >-Paul > >>----- Original Message ----- > >>From: David Eicher > >>To: efi332 at diy-efi.org > >>Sent: Wednesday, October 12, 2005 8:22 AM > >>Subject: RE: [Efi332] Queued Serial IO on the > MPC555... > >> > >> > >>Hi Paul, > >> > >>Any progress on the queued serial I/O? > >> > >>Getting that working on the MPC555 is my next task > (with interrupts). Maybe we can compare notes as we > go along on it here and help each other. > >> > >>For a starting point I want to see what the > Quickstart package says about it, and build on that > foundation (use that interface to the hardware for > both access to the QSCI and for interrupt handling). > Is that your approach? > >> > >>More later when I get something built and try to > run it. > >> > >>thanks, > >> > >>dave > >> > >> > >> > >> > >>>-------------------------------------------------------------------------------- > >>>From: efi332-bounces at diy-efi.org > [mailto:efi332-bounces at diy-efi.org] On Behalf Of > Paul Helmuth > >>>Sent: Sunday, September 11, 2005 9:34 AM > >>>To: efi332 at diy-efi.org > >>>Subject: [Efi332] Queued Serial IO on the > MPC555... > >>> > >>> > >>>All, > >>> > >>>My "ignition only" testing has gone flawlessly. I > had some initial issues with my sensor mount not > being rigid enough (engine vibration would cause the > crank trigger signal to get mangled such that PMMX > would lose synch), but an additional bracket (from > the tip of the sensor mount back to the block) has > that under control. > >>> > >>>I have a lot of stuff to do to add the fuel > injection side, but one critical piece of the puzzle > will be to implement queued serial I/O. Right now I > am just the simple "direct/immediate" I/O routines > (you see these everywhere in various sample code for > the 555 - I think Axiom may have been the original > author?). > >>> > >>>I have seen a few comments from the group that > indicate there are some problems getting the queued > serial I/O to work (at least reliably, consistently, > predictably). That's a little disconcerting, but I'd > like to see if I get it sorted out. > >>> > >>>I have taken a look at Jeff Clark's source from > the 332 project, but I was wondering if any of you > may have some work in progress on the 555 platform > that I could use as a starting point? > >>> > >>>Needless to say, I would make my results > available to the group. > >>> > >>>It would also be great to collect a "bug list" - > that is, to understand any existing problems that > you guys have seen. I have heard there are problems, > but I don't recall seeing any specifics. > >>> > >>>Hope all is going at least as well for your > projects. > >>> > >>>-Paul > > _______________________________________________ > Efi332 mailing list > Efi332 at diy-efi.org > http://lists.diy-efi.org/mailman/listinfo/efi332 > ____________________________________________________ Do you Yahoo!? The New Yahoo! Movies: Check out the Latest Trailers, Premiere Photos and full Actor Database. http://au.movies.yahoo.com _______________________________________________ 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/20051013/d1262f51/attachment.html From sailors3 at comcast.net Thu Oct 13 21:25:51 2005 From: sailors3 at comcast.net (David Eicher) Date: Thu, 13 Oct 2005 19:25:51 -0700 Subject: [Efi332] Queued Serial IO on the MPC555... In-Reply-To: <8C79E426A30E9C4-164C-31F0B@MBLK-M02.sysops.aol.com> Message-ID: Hi Paul, Yep, that sounds like a good approach. Crawl, then walk, then run.., so to speak. Appreciate your willingness to share your experience with this, I'll do the same. I'll let you know when I have some kind of results. Thanks, Dave _____ From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of bowtievette at aol.com Sent: Thursday, October 13, 2005 11:21 AM To: efi332 at diy-efi.org Subject: Re: [Efi332] Queued Serial IO on the MPC555... Paul, Dave, The 332 implementation of the 'regular' SCI is easily ported to the 555. In fact, all the registers are the same with slightly different names, and even the bit assignments in the status register are the same so its a very easy port and a good first step. Depending on how much data you want to flow, this may be an ok solution, or more effort may be in order. To understand why, consider this. Every stack frame save and restore consumes about 150 usec on the 555 assuming no corner cutting i.e you save everything including all the floating point registers. On the regular SCI, every byte in and out triggers an interrupt. If you use all the processor bandwidth to handle these, that means it can handle about 6666 bytes/second. My current efi332 setup sends about 1500 bytes per second, or 150 bytes per frame at 10 Hz. Even with that throughput, serial comm handling consumes almost a quarter of the processor. Obviously, you'd like to go the other way, i.e. pump out more data and/or at higher rates and use less processor to do it. The 68332 is doing fine with this level of overhead, so you're probably wondering why is the 555 so much less efficient; doesn't it run at more than twice the speed (nominally 40 MHz, vs 16 MHz)? The trouble is with the floating point stuff. The 555 has many 64 bit floating point registers that need to be saved and restored. One can get by with less overhead by refraining from doing floating point operations, but thats a major attraction of the chip in the first place. You could simplify the stack frame for this interrupt only and gain some speed but if you are involving an OS, maintaining a consistent stack frame is desirable. The real improvement potential is to use the queueing feature which can cut interrupt traffic by a factor of 8. I think Mot put this in to bolster up the SCI in terms of throughput without going to the expense of a dedicated serial comm controller. I wish they had just put the SCC in. The queued SCI appears to be simple enough from the manual, but is difficult to get working. I have made a superficial attempt but was unsuccessful. In reading the MPC500 list, it appears many others have spent significant effort and not got it working. Unfortunately Mot support is lacking in this area, and direct posts on the subject have gotten no response. I'm sure the module works, but there are some secrets to be understood there. Maybe we can get it working between us. >Dave, > >I started out reviewing the code that Jeff Clark had implemented in the original 332 project (which was essentially the code from a Motorola Application Note). After that, I found the original application note in the Freescale archives and reviewed it. > >Finally, I decided that it would be best to simply go through the 555 documentation (Section-14 Queued Serial Multi-channel Module) and implement from that. > >For myself, I am only interested in the serial communications interfaces (DSCI: SCI1 and SCI2). As I am not planning on doing any hardware interfaces with the QSPI. I assume the SCI stuff is what most guys on this list will be interested in - for communication with remote tuning and monitoring applications. > >After having read the documentation, I think it should be relatively simple to enable interrupts and add an interrupt service routine to read incoming data in to a buffer - and conversely send outbound data from a queue/buffer. > >I think initially I would do this without taking advantage of the built in Queue capabilities in the QSMCM. As this would be a nice small step to take that would limit the number of potential sources for trouble (always a bonus in development). This would also be roughly equivalent to the interrupt/queued support in the original 332 project. > >Once everything was working well using the interrupts, then I would add the internal queue support. I doubt that many of us will "need" that to free up CPU cycles, but as a technology guy you have to use it if its there. > >So, those are my thoughts. If I had some more time (or fewer things to do) I would already have this plan implemented (at least partially), but I should be spending a few cycles on it within the next week or so. So I may have a working version of Phase-I pretty soon. > >How does this approach sound to you? > >-Paul >>----- Original Message ----- >>From: David Eicher >>To: efi332 at diy-efi.org >>Sent: Wednesday, October 12, 2005 8:22 AM >>Subject: RE: [Efi332] Queued Serial IO on the MPC555... >> >> >>Hi Paul, >> >>Any progress on the queued serial I/O? >> >>Getting that working on the MPC555 is my next task (with interrupts). Maybe we can compare notes as we go along on it here and help each other. >> >>For a starting point I want to see what the Quickstart package says about it, and build on that foundation (use that interface to the hardware for both access to the QSCI and for interrupt handling). Is that your approach? >> >>More later when I get something built and try to run it. >> >>thanks, >> >>dave >> >> >> >> >>>------------------------------------------------------------------------- ------- >>>From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Paul Helmuth >>>Sent: Sunday, September 11, 2005 9:34 AM >>>To: efi332 at diy-efi.org >>>Subject: [Efi332] Queued Serial IO on the MPC555... >>> >>> >>>All, >>> >>>My "ignition only" testing has gone flawlessly. I had some initial issues with my sensor mount not being rigid enough (engine vibration would cause the crank trigger signal to get mangled such that PMMX would lose synch), but an additional bracket (from the tip of the sensor mount back to the block) has that under control. >>> >>>I have a lot of stuff to do to add the fuel injection side, but one critical piece of the puzzle will be to implement queued serial I/O. Right now I am just the simple "direct/immediate" I/O routines (you see these everywhere in various sample code for the 555 - I think Axiom may have been the original author?). >>> >>>I have seen a few comments from the group that indicate there are some problems getting the queued serial I/O to work (at least reliably, consistently, predictably). That's a little disconcerting, but I'd like to see if I get it sorted out. >>> >>>I have taken a look at Jeff Clark's source from the 332 project, but I was wondering if any of you may have some work in progress on the 555 platform that I could use as a starting point? >>> >>>Needless to say, I would make my results available to the group. >>> >>>It would also be great to collect a "bug list" - that is, to understand any existing problems that you guys have seen. I have heard there are problems, but I don't recall seeing any specifics. >>> >>>Hope all is going at least as well for your projects. >>> >>>-Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20051013/9f617de6/attachment.html From sailors3 at comcast.net Fri Oct 14 09:02:29 2005 From: sailors3 at comcast.net (David Eicher) Date: Fri, 14 Oct 2005 07:02:29 -0700 Subject: [Efi332] Queued Serial IO on the MPC555... Message-ID: Jeff, I was searching for examples of interrupt driven QSCI, found this. http://groups.yahoo.com/group/MPC500/message/3130?viscount=100 Zero response, right? It appears the Freescale guys have not figured out how to use it. Regards, Dave _____ From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of David Eicher Sent: Thursday, October 13, 2005 6:26 PM To: efi332 at diy-efi.org Subject: RE: [Efi332] Queued Serial IO on the MPC555... Hi Paul, Yep, that sounds like a good approach. Crawl, then walk, then run.., so to speak. Appreciate your willingness to share your experience with this, I'll do the same. I'll let you know when I have some kind of results. Thanks, Dave _____ From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of bowtievette at aol.com Sent: Thursday, October 13, 2005 11:21 AM To: efi332 at diy-efi.org Subject: Re: [Efi332] Queued Serial IO on the MPC555... Paul, Dave, The 332 implementation of the 'regular' SCI is easily ported to the 555. In fact, all the registers are the same with slightly different names, and even the bit assignments in the status register are the same so its a very easy port and a good first step. Depending on how much data you want to flow, this may be an ok solution, or more effort may be in order. To understand why, consider this. Every stack frame save and restore consumes about 150 usec on the 555 assuming no corner cutting i.e you save everything including all the floating point registers. On the regular SCI, every byte in and out triggers an interrupt. If you use all the processor bandwidth to handle these, that means it can handle about 6666 bytes/second. My current efi332 setup sends about 1500 bytes per second, or 150 bytes per frame at 10 Hz. Even with that throughput, serial comm handling consumes almost a quarter of the processor. Obviously, you'd like to go the other way, i.e. pump out more data and/or at higher rates and use less processor to do it. The 68332 is doing fine with this level of overhead, so you're probably wondering why is the 555 so much less efficient; doesn't it run at more than twice the speed (nominally 40 MHz, vs 16 MHz)? The trouble is with the floating point stuff. The 555 has many 64 bit floating point registers that need to be saved and restored. One can get by with less overhead by refraining from doing floating point operations, but thats a major attraction of the chip in the first place. You could simplify the stack frame for this interrupt only and gain some speed but if you are involving an OS, maintaining a consistent stack frame is desirable. The real improvement potential is to use the queueing feature which can cut interrupt traffic by a factor of 8. I think Mot put this in to bolster up the SCI in terms of throughput without going to the expense of a dedicated serial comm controller. I wish they had just put the SCC in. The queued SCI appears to be simple enough from the manual, but is difficult to get working. I have made a superficial attempt but was unsuccessful. In reading the MPC500 list, it appears many others have spent significant effort and not got it working. Unfortunately Mot support is lacking in this area, and direct posts on the subject have gotten no response. I'm sure the module works, but there are some secrets to be understood there. Maybe we can get it working between us. >Dave, > >I started out reviewing the code that Jeff Clark had implemented in the original 332 project (which was essentially the code from a Motorola Application Note). After that, I found the original application note in the Freescale archives and reviewed it. > >Finally, I decided that it would be best to simply go through the 555 documentation (Section-14 Queued Serial Multi-channel Module) and implement from that. > >For myself, I am only interested in the serial communications interfaces (DSCI: SCI1 and SCI2). As I am not planning on doing any hardware interfaces with the QSPI. I assume the SCI stuff is what most guys on this list will be interested in - for communication with remote tuning and monitoring applications. > >After having read the documentation, I think it should be relatively simple to enable interrupts and add an interrupt service routine to read incoming data in to a buffer - and conversely send outbound data from a queue/buffer. > >I think initially I would do this without taking advantage of the built in Queue capabilities in the QSMCM. As this would be a nice small step to take that would limit the number of potential sources for trouble (always a bonus in development). This would also be roughly equivalent to the interrupt/queued support in the original 332 project. > >Once everything was working well using the interrupts, then I would add the internal queue support. I doubt that many of us will "need" that to free up CPU cycles, but as a technology guy you have to use it if its there. > >So, those are my thoughts. If I had some more time (or fewer things to do) I would already have this plan implemented (at least partially), but I should be spending a few cycles on it within the next week or so. So I may have a working version of Phase-I pretty soon. > >How does this approach sound to you? > >-Paul >>----- Original Message ----- >>From: David Eicher >>To: efi332 at diy-efi.org >>Sent: Wednesday, October 12, 2005 8:22 AM >>Subject: RE: [Efi332] Queued Serial IO on the MPC555... >> >> >>Hi Paul, >> >>Any progress on the queued serial I/O? >> >>Getting that working on the MPC555 is my next task (with interrupts). Maybe we can compare notes as we go along on it here and help each other. >> >>For a starting point I want to see what the Quickstart package says about it, and build on that foundation (use that interface to the hardware for both access to the QSCI and for interrupt handling). Is that your approach? >> >>More later when I get something built and try to run it. >> >>thanks, >> >>dave >> >> >> >> >>>------------------------------------------------------------------------- ------- >>>From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Paul Helmuth >>>Sent: Sunday, September 11, 2005 9:34 AM >>>To: efi332 at diy-efi.org >>>Subject: [Efi332] Queued Serial IO on the MPC555... >>> >>> >>>All, >>> >>>My "ignition only" testing has gone flawlessly. I had some initial issues with my sensor mount not being rigid enough (engine vibration would cause the crank trigger signal to get mangled such that PMMX would lose synch), but an additional bracket (from the tip of the sensor mount back to the block) has that under control. >>> >>>I have a lot of stuff to do to add the fuel injection side, but one critical piece of the puzzle will be to implement queued serial I/O. Right now I am just the simple "direct/immediate" I/O routines (you see these everywhere in various sample code for the 555 - I think Axiom may have been the original author?). >>> >>>I have seen a few comments from the group that indicate there are some problems getting the queued serial I/O to work (at least reliably, consistently, predictably). That's a little disconcerting, but I'd like to see if I get it sorted out. >>> >>>I have taken a look at Jeff Clark's source from the 332 project, but I was wondering if any of you may have some work in progress on the 555 platform that I could use as a starting point? >>> >>>Needless to say, I would make my results available to the group. >>> >>>It would also be great to collect a "bug list" - that is, to understand any existing problems that you guys have seen. I have heard there are problems, but I don't recall seeing any specifics. >>> >>>Hope all is going at least as well for your projects. >>> >>>-Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20051014/670c7ca6/attachment.html From bowtievette at aol.com Fri Oct 14 09:13:49 2005 From: bowtievette at aol.com (Jeff Clarke) Date: Fri, 14 Oct 2005 14:13:49 +0000 GMT Subject: [Efi332] Queued Serial IO on the MPC555... In-Reply-To: <200510141003.161434fba9c193@rly-ya05.mx.aol.com> References: <200510141003.161434fba9c193@rly-ya05.mx.aol.com> Message-ID: <14134496.1129299260595.JavaMail.teamon@bda072-cell00.bisx.prod.on.blackberry> Correct, no response. I can't ask the question any more directly than that. There are some tips and code snippets in the archives but not much. Sent wirelessly via my BlackBerry. -----Original Message----- From: "David Eicher" Date: Fri, 14 Oct 2005 07:02:29 To: Subject: RE: [Efi332] Queued Serial IO on the MPC555... Jeff, ? I was searching for examples of interrupt driven QSCI, found this. ? http://groups.yahoo.com/group/MPC500/message/3130?viscount=100: ? Zero response, right? It appears the Freescale guys have not figured out how to use it. ? Regards, ? Dave ? ? ---------------- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of David Eicher Sent: Thursday, October 13, 2005 6:26 PM To: efi332 at diy-efi.org Subject: RE: [Efi332] Queued Serial IO on the MPC555... ? Hi Paul, ? Yep, that sounds like a good approach. Crawl, then walk, then run?., so to speak. Appreciate your willingness to share your experience with this, I?ll do the same. I?ll let you know when I have some kind of results. ? Thanks, ? Dave ? ? ---------------- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of bowtievette at aol.com Sent: Thursday, October 13, 2005 11:21 AM To: efi332 at diy-efi.org Subject: Re: [Efi332] Queued Serial IO on the MPC555... ? Paul, Dave, The 332 implementation of the 'regular' SCI is easily ported to the 555. In fact,?all the registers are the same?with slightly different names, and?even the bit assignments in the status register are the same so its a very easy port and a good first step. Depending on how much data?you want to flow, this may?be an?ok solution, or more effort may be in order. ? To understand why,? consider this. Every stack frame save and restore consumes about 150 usec on the 555 assuming no corner cutting i.e you save everything including all the floating point registers.? On the regular SCI, every byte in and out triggers an interrupt. If you use all the processor bandwidth to handle?these, that means?it can handle about 6666 bytes/second. ? My current efi332 setup?sends about 1500 bytes per second, or 150 bytes per frame at 10 Hz.?Even?with that throughput,?serial comm handling?consumes almost a quarter of the processor.??Obviously, you'd like to go the other way, i.e. pump out more data and/or at higher rates?and use less processor to do it. ? The 68332 is doing fine with this level of overhead, so you're probably?wondering why is the 555 so much less efficient; doesn't it run at more than twice the speed (nominally 40 MHz, vs 16 MHz)??The trouble is with the floating point stuff. The 555 has?many 64 bit floating point registers that need to be saved and restored. One can get by with less overhead by refraining from doing floating point operations, but thats a major attraction of the chip in the first place. You could simplify the stack frame for this interrupt only and gain some speed but?if you are involving an OS, maintaining a consistent stack frame is desirable.?The real improvement potential is to use the queueing feature which can?cut interrupt traffic by a factor of 8.?I think Mot put this in to bolster up the SCI in terms of throughput without going to the expense of a dedicated serial comm controller. I wish they had just put the SCC in. ? The queued SCI appears to be simple enough from the manual, but is difficult to get working. I have made a superficial attempt but was unsuccessful. In reading the MPC500 list, it appears many others have spent significant effort and not got it working.? Unfortunately Mot support is lacking in this area, and direct posts on the subject?have gotten?no response. I'm sure the module works, but there are some secrets to be understood there. Maybe we can get it working between us. ? ? ? ? >Dave, > >I started out reviewing the code that Jeff Clark had implemented in the original 332 project (which was essentially the code from a Motorola Application Note). After that, I found the original application note in the Freescale archives and reviewed it. > >Finally, I decided that it would be best to simply go through the 555 documentation (Section-14 Queued Serial Multi-channel Module) and implement from that. > >For myself, I am only interested in the serial communications interfaces (DSCI: SCI1 and SCI2). As I am not planning on doing any hardware interfaces with the QSPI. I assume the SCI stuff is what most guys on this list will be interested in - for communication with remote tuning and monitoring applications. > >After having read the documentation, I think it should be relatively simple to enable interrupts and add an interrupt service routine to read incoming data in to a buffer - and conversely send outbound data from a queue/buffer. > >I think initially I would do this without taking advantage of the built in Queue capabilities in the QSMCM. As this would be a nice small step to take that would limit the number of potential sources for trouble (always a bonus in development). This would also be roughly equivalent to the interrupt/queued support in the original 332 project. > >Once everything was working well using the interrupts, then I would add the internal queue support. I doubt that many of us will "need" that to free up CPU cycles, but as a technology guy you have to use it if its there. > >So, those are my thoughts. If I had some more time (or fewer things to do) I would already have this plan implemented (at least partially), but I should be spending a few cycles on it within the next week or so. So I may have a working version of Phase-I pretty soon. > >How does this approach sound to you? > >-Paul >>----- Original Message ----- >>From: David Eicher >>To: efi332 at diy-efi.org >>Sent: Wednesday, October 12, 2005 8:22 AM >>Subject: RE: [Efi332] Queued Serial IO on the MPC555... >> >> >>Hi Paul, >> >>Any progress on the queued serial I/O? >> >>Getting that working on the MPC555 is my next task (with interrupts). Maybe we can compare notes as we go along on it here and help each other. >> >>For a starting point I want to see what the Quickstart package says about it, and build on that foundation (use that interface to the hardware for both access to the QSCI and for interrupt handling). Is that your approach? >> >>More later when I get something built and try to run it. >> >>thanks, >> >>dave >> >> >> >> >>>-------------------------------------------------------------------------------- >>>From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Paul Helmuth >>>Sent: Sunday, September 11, 2005 9:34 AM >>>To: efi332 at diy-efi.org >>>Subject: [Efi332] Queued Serial IO on the MPC555... >>> >>> >>>All, >>> >>>My "ignition only" testing has gone flawlessly. I had some initial issues with my sensor mount not being rigid enough (engine vibration would cause the crank trigger signal to get mangled such that PMMX would lose synch), but an additional bracket (from the tip of the sensor mount back to the block) has that under control. >>> >>>I have a lot of stuff to do to add the fuel injection side, but one critical piece of the puzzle will be to implement queued serial I/O. Right now I am just the simple "direct/immediate" I/O routines (you see these everywhere in various sample code for the 555 - I think Axiom may have been the original author?). >>> >>>I have seen a few comments from the group that indicate there are some problems getting the queued serial I/O to work (at least reliably, consistently, predictably). That's a little disconcerting, but I'd like to see if I get it sorted out. >>> >>>I have taken a look at Jeff Clark's source from the 332 project, but I was wondering if any of you may have some work in progress on the 555 platform that I could use as a starting point? >>> >>>Needless to say, I would make my results available to the group. >>> >>>It would also be great to collect a "bug list" - that is, to understand any existing problems that you guys have seen. I have heard there are problems, but I don't recall seeing any specifics. >>> >>>Hope all is going at least as well for your projects. >>> >>>-Paul _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 From andreic at chichak.ca Wed Oct 19 14:58:01 2005 From: andreic at chichak.ca (Andrei Chichak) Date: Wed, 19 Oct 2005 13:58:01 -0600 Subject: [Efi332] Requirements Design Document for EFI In-Reply-To: <20051010132415.QCP26509.priv-edtnes82.telusplanet.net@spla t.ca> Message-ID: <5.2.1.1.0.20051019133657.01bdd370@pop.telus.net> At 07:23 AM 10/10/2005, you wrote: >Hello, > >Has anyone written a requirements and/or design document for EFI or engine >management that they would care to share? I've been meaning to send a message about this for a while now. I was hoping that someone else would chime in since I think I have either discussed this with either you or Jeff off-list. My position is coming from finishing off a project where I used the '332, the TPU, the SPI ADCs, serial switches and an RTOS. It was for a piece of medical equipment, but a lot of it is applicable to this project. I worked with an MPC562 board for a while, but I have to look at where I want to spend my money and time. I can see using the '332 again in more projects. I have some Axiom CMM332 boards, which make a great off the shelf compute core for these projects, working compilers, debugging modules, and a lot of experience in the gotchas of the '332. For me, the cost of switching to PPC is more that I can justify at this point. But, you know, this doesn't change the requirements, the algorithms, the structure, or what is needed to get a system going. I learned, through making lots of mistakes, that the first thing that you need to write is a FLASH based error logger. This calls out having the FLASH writers and serial comm interpreter in place. I have been playing around with simpler interfaces for ignition coil driving, and PWM idle motors. None of this stuff is specific to PPC or '332 or Megasquirt or what have you. SO, yes I have the start of a requirements/design doc that I would be glad to share. Is anybody interested? Andrei From BowTieVette at aol.com Wed Oct 19 17:23:49 2005 From: BowTieVette at aol.com (BowTieVette at aol.com) Date: Wed, 19 Oct 2005 18:23:49 EDT Subject: [Efi332] Requirements Design Document for EFI Message-ID: In a message dated 10/19/2005 4:02:33 PM Eastern Standard Time, andreic at chichak.ca writes: >Hello, > >Has anyone written a requirements and/or design document for EFI or engine >management that they would care to share? I've been meaning to send a message about this for a while now. I was hoping that someone else would chime in since I think I have either discussed this with either you or Jeff off-list. Yup, that was me. I haven't done any further work on your document since then. My position is coming from finishing off a project where I used the '332, the TPU, the SPI ADCs, serial switches and an RTOS. It was for a piece of medical equipment, but a lot of it is applicable to this project. I worked with an MPC562 board for a while, but I have to look at where I want to spend my money and time. I can see using the '332 again in more projects. I have some Axiom CMM332 boards, which make a great off the shelf compute core for these projects, working compilers, debugging modules, and a lot of experience in the gotchas of the '332. For me, the cost of switching to PPC is more that I can justify at this point. But, you know, this doesn't change the requirements, the algorithms, the structure, or what is needed to get a system going. Yes, the performance requirements should tell you whether the 332 is sufficient for your needs or not. That notwithstanding, if there are cost constraints, you need to factor those constraints into your requirements development so as to not to guarantee yourself a deficient system from the start. The 332 can make a fine system for lots of folks... we've had this discussion before. Lots of things to consider though, size, capability, through hole or SMT, integrated drivers or not, etc. Some of these can drive the 332 cost to as high as a ppc design. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20051019/66a2105d/attachment.html From sailors3 at comcast.net Wed Oct 19 19:52:03 2005 From: sailors3 at comcast.net (David Eicher) Date: Wed, 19 Oct 2005 17:52:03 -0700 Subject: [Efi332] Requirements Design Document for EFI In-Reply-To: <5.2.1.1.0.20051019133657.01bdd370@pop.telus.net> Message-ID: Hi Andrei, Thanks for the response. Yep, I'd be interested in seeing a requirements/design doc on engine management if you're willing to share. Thanks, Dave -----Original Message----- From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Andrei Chichak Sent: Wednesday, October 19, 2005 11:58 AM To: efi332 at diy-efi.org Subject: Re: [Efi332] Requirements Design Document for EFI At 07:23 AM 10/10/2005, you wrote: >Hello, > >Has anyone written a requirements and/or design document for EFI or engine >management that they would care to share? I've been meaning to send a message about this for a while now. I was hoping that someone else would chime in since I think I have either discussed this with either you or Jeff off-list. My position is coming from finishing off a project where I used the '332, the TPU, the SPI ADCs, serial switches and an RTOS. It was for a piece of medical equipment, but a lot of it is applicable to this project. I worked with an MPC562 board for a while, but I have to look at where I want to spend my money and time. I can see using the '332 again in more projects. I have some Axiom CMM332 boards, which make a great off the shelf compute core for these projects, working compilers, debugging modules, and a lot of experience in the gotchas of the '332. For me, the cost of switching to PPC is more that I can justify at this point. But, you know, this doesn't change the requirements, the algorithms, the structure, or what is needed to get a system going. I learned, through making lots of mistakes, that the first thing that you need to write is a FLASH based error logger. This calls out having the FLASH writers and serial comm interpreter in place. I have been playing around with simpler interfaces for ignition coil driving, and PWM idle motors. None of this stuff is specific to PPC or '332 or Megasquirt or what have you. SO, yes I have the start of a requirements/design doc that I would be glad to share. Is anybody interested? Andrei _______________________________________________ Efi332 mailing list Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332