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

Fri Oct 14 14:13:49 UTC 2005

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" <sailors3 at comcast.net>
Date: Fri, 14 Oct 2005 07:02:29 
To:<efi332 at diy-efi.org>
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: <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