[Efi332] Queued Serial IO on the MPC555...

Fri Oct 14 01:09:07 UTC 2005

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 <r_d_gullickson at yahoo.com.au>
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 