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

Fri Oct 14 02:25:51 UTC 2005

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 