It is currently Fri Aug 17, 2018 5:08 pm



Post new topic Reply to topic  [ 39 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Where and When do we Restart?
PostPosted: Sun Mar 02, 2014 2:02 pm 
Offline

Joined: Wed May 15, 2013 10:12 pm
Posts: 10
O5E is a huge project and more than a few good and capable fellows have bent their picks chipping away at it including its visionary founder Mark E. Lately, it has burned out Sean S. and Mark but there still is a tiny spark from the original idea that the MPC 5xxx series of processors have immense promise for the homebuilder EFI nut.

Back a few years ago, O5E--before it had that name--came to a similar point and I chimed in with some rather simple minded EFI software using the MPC5554--always noting that I am a "hobbyist" programmer. It didn't have an OS, it had a terribly simple "tuner interface" (I even hate to use the term it was so primitive) and it used smallish tables, didn't use the FLASH and used fixed point arithmetic. It was to use my extant PLX sensor and display hardware. It had to trim the fat from the FS eTPU software a bit and it fit in the RAM of the 5554. And---it seemed to work. From that bare beginning, Jon and then Sean picked up the ball and advanced it way beyond its humble beginnings. But, here we are.

Mark is selling me his hardware and I will port my software to it and replace the DELCO MEFI in my '68 OHC-6 SPRINT. It may not be pretty. It may not be a saleable, shining, new ECU but, with any luck at all, it might even run!

Of course, there are some near term obstacles. I am in the midst of moving, selling homes, building new shops, etc., ad nauseam. Nothing is going to happen fast or soon. But in my lonely, empty hours, I have a chance to blather on and I will continue this forum with a few words from time to time to outline my plans, specs and progress such as they may be. I shall share my work openly and without caveat except "use at your own risk" as befits the excellent precursor work of Mark and many others.

Comments and critical analysis will always be welcome.

Paul S


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Mon Mar 03, 2014 10:48 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:52 am
Posts: 304
Location: Over here, doing 'over here' things.
I wish you luck, of the good type. ;)

Am anxiously awaiting reading more about this.

_________________
/me goes off to the corner feeling like Jerry Springer with a mullet.

My O5E candidate: 1982 Honda CX500TC motorcycle.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Mon Mar 03, 2014 10:55 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
Paul S wrote:
Mark is selling me his hardware


Yes!...if by selling you mean giving. I want to help in any way I can so the stuff is yours if you can use it.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Mon Jul 07, 2014 9:29 pm 
Offline
User avatar

Joined: Thu May 30, 2013 1:11 am
Posts: 54
Paul,

I wish you the very best of luck! I'm still pushing forward (SLOWLY!) on my motorcycle ECU project as well. I'm planning on using the 5634 (now way in heck am I willing to design a board for a 400+ pin PBGA!) as the TRK board I have is a great development platform. From what I have laid out right now, I have plenty of pins and functionality for everything I need, no point in fighting with BGAs.

The ONLY advise I am able to give is to keep it simple, but not too simple. o5e, along with others (such as EFI332) all died. In my OPINION, one thing a lot of the dead ones had in common was huge feature creep. When I saw things like 24 fuel channels, 12 injector channels, anti-lock brake channels, drive by wire, etc, etc, I really didn't expect it to make to to the finish line. I hoped, but I didn't expect...

As for my own efforts, I'm spending a bit of time getting to understand the basics of the whole Codewarrior development environment and understanding the programming model of the MPC processors. There is DEFINITELY a pretty steep learning curve compared to the AVRs that I normally use. But it is coming together and starting to make more and more sense. If nothing else, I can now blink some LEDs with the eTPU channels... ;)


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Tue Jul 08, 2014 2:23 am 
Offline
User avatar

Joined: Tue Jul 08, 2014 1:42 am
Posts: 5
Is o5e (the topic of this whole forum) dead?

This seems to be what the previous post says?


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Wed Jul 09, 2014 10:45 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
clcorbin wrote:

The ONLY advise I am able to give is to keep it simple, but not too simple.
....
As for my own efforts,......


You're speaking Paul's language with KISS :)

the problem is the second piece....."my own efforts"

Every single person that in anyway touched o5e (and I'm quite sure EFI332 also), myself included, was working on the project to support personal goals of some sort, which is fine and normal for a hobby, BUT it makes it impossible to set specs and truly share the work.

At that point it becomes more a collection of personal projects and an ECU is a BIG project that very few individuals can complete on their own, I certainly can't.....and the effort founders.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Wed Jul 09, 2014 10:47 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
GreenAsJade wrote:
Is o5e (the topic of this whole forum) dead?

This seems to be what the previous post says?


Very close......there just is no agreement on anything or anyone willing to step up and actually DO anything so nothing happens it seems


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Sun Jul 13, 2014 2:40 pm 
Offline
User avatar

Joined: Thu May 30, 2013 1:11 am
Posts: 54
Mark,

Here is my take on things: megasquirt succeeded because they started VERY simple (perhaps too simple, but hey, it DID succeed!). Once they had the fuel only version running and mostly debugged, they added on fairly simple ignition. Once that was working, they moved on to more features. The single biggest limitation of MS has always been the hardware it was designed around. They gave up on EFI332 mainly because there wasn't decent tools available to support that thing unless you have a BUTT LOAD of money. That has changed quite a bit in the last several years.

I'm kind of stuck in the middle here. My original goal was to implement a MS system on my bike. I hit problems in that it really couldn't support the throttle body I needed to use (GSRX-600K model) at the hardware level. Plus, the "box" was WAY too big for were I needed to put it. The next step was to design custom hardware that would fit and would have the dual stepper controllers I needed. But I wasn't counting on how far away from open source MS had become over the years, so that hit a Huge snag as well.

In the third round, I came across o5e. At the time I found it, you were just starting to take a look at the 5634 processor instead of the bigger, more powerful BGA parts. That caught my eye. Here was an automotive MCU that HAD the TPU channels I wanted and it was in a package I could solder myself. In addition, the tools to support this thing were getting more and more capable all the time. Heck, the current 10.6V SE supports up to 512K flash size... FS was also in the process of rewriting the eTPU functions to improve and simplify them. To make it even better, indepth reading of the o5e website showed a lot of people were putting a lot of effort into designing GOOD hardware. Just the discussions on input filtering and protection was very interesting... And DEFINITELY a huge leap over what MS was doing.

Of course, for assorted reasons, o5e has ground to a halt. Damn.

So I'm not at my third choice: go it alone. That sucks! To do this, I have no choice but to embrace the KISS principle at all levels. The board I am designing supports the features I NEED and no more. I'm also not going to use an OS if I don't absolutely have to. Of course, from my point of view, that was always the advantage of the eTPU is how it off loads so much from the main MCU, so WHY did we need an OS to run an engine? Perhaps I will find out.

One item that I will have to implement is table loading. I suspect the initial version will be VERY simple and just support loading tables and possible pulling log data so I can process it off line to make changes to the tables. Tuner Studio or other interfaces would be GREAT, but they can wait until my bike is actually running (however poor it may be running!). Once the bike is running, THEN I can start to worry about adding features, IF I find they are necessary.

Wish me luck! Because you, more than most, know what I am up against!


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Sun Jul 13, 2014 8:12 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
clcorbin wrote:
Mark,

Here is my take on things: megasquirt succeeded because they started VERY simple (perhaps too simple, but hey, it DID succeed!).

.....

Of course, for assorted reasons, o5e has ground to a halt. Damn.

So I'm not at my third choice: go it alone.


I parsed a bit to make my take a bit clearer.

EFI332 failed because it required a team of people working togeter. MS succeed because it did not. It really is that simple.

o5e is basically complete and ready to live test. It does every single thing you say you want plus some.....so why on earth would you not simply hook it up and use it? Answer.....you didn't write it and you really want to try doing it yourself is all I can think.

05e has been fully ready to run engine for 2+ years now. Everything is bench tested, the sync function has been tested on a running engine doing every cranking mode I could think up and works fine. it's ready to go but I can't find anyone willing to try it. Everyone has an excuse...it doesn't do this or that so I add more code.....and still no one is willing to test it.

The code is modular so if all you want is fuel, just use fuel and select "disable" for everything else. Its that simle, use what you want, don't use what you don't want.

Is your bike ready? if so I'll send you part for a frankenECU. You actually test it and the stuff is yours.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Wed Jul 30, 2014 9:06 pm 
Offline
User avatar

Joined: Thu May 30, 2013 1:11 am
Posts: 54
hardware wise, the bike is ready. I'm not in school anymore, so I'm not riding it everyday. Questions on the frankenECU:

    Can it drive two dual H-bridges? (two stepper motors must be controlled)
    Can it drive staged injectors? (see note below)

The 36-1 wheel has been made and tested long ago, as has the VR sensor test circuit (based on MAX9924 chip and right out of the o5e schematics). I have the crank VR sensor, the throttle body (off a 2008 Suzuki GSXR-600). I also have the pump and wiring harness off the same bike. I would have to build the header tank for the pump (I have the aluminum already).

If the FrankenECU runs, I have NO idea were it would be mounted, but I'm sure I could come up with something to test it. Heck, I'm going to have to come up with a temporary mount for the battery as it currently lives were the header tank must go.

I have to have one dual h-bridge, even for testing as the idle air control is a stepper motor. The other one is for the secondary throttle/high idle control which could be bypassed for testing.

The same goes for the staged injectors. This bike probably uses enough fuel at idle (it is an old 1100 after all) that I could get away with just using the high speed injectors, especially for testing. The idle quality MAY suffer a bit (MAYBE), but it should run well enough for testing. This thing has a 8500 rpm red line, not a 15,000 rpm red line...

I believe the FrankenECU uses the TRK board, which I already have. If you want to move forward, let's do it. I was thinking that the code was being rewritten and that hit a road block and come to a stop. But if we have some code that should be able to run, let's try it.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Wed Jul 30, 2014 10:20 pm 
Offline
User avatar

Joined: Thu May 30, 2013 1:11 am
Posts: 54
I forgot to add that I also have a wideband O2 (LC-1) ready to go but I DO need to find the "right" threaded VR sensor for the camshaft. The Yamaha crank VR sensor I have works perfectly at picking up the cam nose with over 1mm clearance at 120 rpm, I can't think of a good way to mount that sensor to the valve cover! A threaded one would be very easy to adapt.

Clint


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Fri Aug 01, 2014 9:12 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
clcorbin wrote:
I forgot to add that I also have a wideband O2 (LC-1) ready to go but I DO need to find the "right" threaded VR sensor for the camshaft. The Yamaha crank VR sensor I have works perfectly at picking up the cam nose with over 1mm clearance at 120 rpm, I can't think of a good way to mount that sensor to the valve cover! A threaded one would be very easy to adapt.

Clint


I have a couple hall sensors from DIY autotune that are threaded. They are no good for crank because they aern't accurate enough but should be fine for cam.

Or could I help you with an adapter of some kind?


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Fri Aug 01, 2014 9:18 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
clcorbin wrote:
hardware wise, the bike is ready. I'm not in school anymore, so I'm not riding it everyday. Questions on the frankenECU:

    Can it drive two dual H-bridges? (two stepper motors must be controlled)
    Can it drive staged injectors? (see note below)

The 36-1 wheel has been made and tested long ago, as has the VR sensor test circuit (based on MAX9924 chip and right out of the o5e schematics). I have the crank VR sensor, the throttle body (off a 2008 Suzuki GSXR-600). I also have the pump and wiring harness off the same bike. I would have to build the header tank for the pump (I have the aluminum already).

If the FrankenECU runs, I have NO idea were it would be mounted, but I'm sure I could come up with something to test it. Heck, I'm going to have to come up with a temporary mount for the battery as it currently lives were the header tank must go.

I have to have one dual h-bridge, even for testing as the idle air control is a stepper motor. The other one is for the secondary throttle/high idle control which could be bypassed for testing.

The same goes for the staged injectors. This bike probably uses enough fuel at idle (it is an old 1100 after all) that I could get away with just using the high speed injectors, especially for testing. The idle quality MAY suffer a bit (MAYBE), but it should run well enough for testing. This thing has a 8500 rpm red line, not a 15,000 rpm red line...

I believe the FrankenECU uses the TRK board, which I already have. If you want to move forward, let's do it. I was thinking that the code was being rewritten and that hit a road block and come to a stop. But if we have some code that should be able to run, let's try it.


OK.

now you see why getting optional outs is so important...everyone including you needs them ;)

stepper idle contol is harder than IAC...but doable. It will need to be coded though.

staged injection is in the setup menus but again the actual control needs to be coded...not hard but needs to be done.

If we can get you running without idle control and staged injection that would be best ....KISS ;)

....but they are not hard to add once you're running. PM me and we'll figure out what HW you need and what I have and can send.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Sat Aug 02, 2014 5:36 pm 
Offline
User avatar

Joined: Thu May 30, 2013 1:11 am
Posts: 54
mk e wrote:
clcorbin wrote:
I forgot to add that I also have a wideband O2 (LC-1) ready to go but I DO need to find the "right" threaded VR sensor for the camshaft. The Yamaha crank VR sensor I have works perfectly at picking up the cam nose with over 1mm clearance at 120 rpm, I can't think of a good way to mount that sensor to the valve cover! A threaded one would be very easy to adapt.

Clint


I have a couple hall sensors from DIY autotune that are threaded. They are no good for crank because they aern't accurate enough but should be fine for cam.

Or could I help you with an adapter of some kind?


Does anyone have an idea of how small a VR sensor I can run on the cam? What I have found is that the small diameter ones that I would LOVE to run are only rated at 30 to 60V at 1000ips were the larger (and more normal sized for a cam or crank sensor) units are up in the 150V+ output under the same conditions. Given that syncing would be the most critical time and the output would be MUCH less, I'm not sure if the small ones will work. But they SURE would be easier to mount!

Mark,

As for the mounts, I still have access the machine shop at the university, so I SHOULD be able to make what I need. Right now, I'm trying to track down a "spare" valve cover for my bike (given how many of them are not longer running, you would think come of the gents on the XS11 page would have one laying around collecting dust...) so I have something to test with. I already have a spare non runnable head and a good testing cam, so I just need that valve cover so I can take the proper measurements and build up a test rig for the sensor.

Push comes to shove on the threaded sensor, I might change gears and try to track down a reasonable "normal" motorcycle cam cover and fabricate a mount for it that can be welded to the valve cover. For some reason, I don't want to mess with the head! One upside of a "real" cam VR sensor is that it will be a LOT easier to seal with an o-ring.

Clint


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Sat Aug 02, 2014 6:25 pm 
Offline
User avatar

Joined: Thu May 30, 2013 1:11 am
Posts: 54
mk e wrote:
OK.
now you see why getting optional outs is so important...everyone including you needs them ;)

Actually, I was planning on writing it directly into my fork of the code branch! I don't consider that an "optional" part of the code!

mk e wrote:
stepper idle control is harder than IAC...but doable. It will need to be coded though.

I should be able to handle that. I want to build a prototype board with the DRV8825 stepper driver on it, so that would be trivial to wire into the FrankenECU. I hope! It also looks like the stepper motor eTPU code can handle an external driver, but I'm not sure on how it handles the direction change (does the main code have to flip the direction output, or does the eTPU code handle that? Not clear in the docs I've read) Fairly trivial to handle one way or the other.

mk e wrote:
staged injection is in the setup menus but again the actual control needs to be coded...not hard but needs to be done.

The main trick with staged injection is the hysteresis so you aren't constantly switching between single/dual injectors if you happen to be at that point in the curve. Other wise, it is just a "run on first stage until xx% duty cycle, then hold stage 1 at yy% and calculate fuel required from second stage injectors". And no, I'm not sure what "xx%" or "yy%" should be. I'm thinking along the lines of xx%=70% and yy% = 50%. There is also the strategy of do you want to always run the second stage injectors at a certain, very low duty cycle all the time (when above the critical idle level) to keep the fuel in the fresh (in case ALL you did was idle around town... ??) and primed. That second part can DEFINITELY be removed as part of KISS. Of course, I might have this completely messed up in my head and it is actually MUCH more complex. But I don't think so.

mk e wrote:
If we can get you running without idle control and staged injection that would be best ....KISS ;)

If I manually open the secondary throttle plates, I SHOULD be able to adjust the high idle set screw to control the low speed idle, at least roughly. Hopefully! And if I wired the two secondary throttle stepper coils hot, that would keep them from moving on me as well. The factory opens the secondary throttle all the way (to force the primary plates open a bit) at start, then closes the normal idle control valve (stepper) and then fine tunes the idle from there. At some point, it switches to a "normal" idle based on temperature, engine speed, etc.

mk e wrote:
....but they are not hard to add once you're running. PM me and we'll figure out what HW you need and what I have and can send.

I'll send you a PM this weekend.

Clint


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Mon Aug 04, 2014 11:48 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
clcorbin wrote:
mk e wrote:
OK.
now you see why getting optional outs is so important...everyone including you needs them ;)

Actually, I was planning on writing it directly into my fork of the code branch! I don't consider that an "optional" part of the code!


The problem is NOBODY considers ANYTHING they need optional....but nothing but spark and fuel run an engine ;)

But I understand and simplifying what I planned as the "optional" stuff will make it easier. I've trying very hard not to make the features general enough to give most people an easy way to do what they need.....and it's nearly there, I just need to pick back up and get it done.


Yes to the rest....but you probably don't want to use the etpu stepper function.. The etpu runs even is the processor is locked so control of the throttle should never be in the etpu IMO.

The better option is to just use a simple standalone stepper driver card. This makes it easy to have the processor control the idle and also makes the control code for stepper or IAC the same I think. Another good way to do idle is using ignition timing....and again I think the same control code code be used.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Sun Aug 10, 2014 12:04 pm 
Offline
User avatar

Joined: Thu May 30, 2013 1:11 am
Posts: 54
mk e wrote:
The problem is NOBODY considers ANYTHING they need optional....but nothing but spark and fuel run an engine ;)


And air.....!

mk e wrote:
Yes to the rest....but you probably don't want to use the etpu stepper function.. The etpu runs even is the processor is locked so control of the throttle should never be in the etpu IMO.


The throttle is still controlled by my wrist. Only the secondary throttle valve (used to implement a constant vacuum type response on VERY wide dynamic range engines) will be under the PCM control.

Case 1: The PCM opens them wide open and leaves them there. - Throttle response suffers a bit at low rpm. Ne effect at high rpm or the ability to control the engine speed. Fail safe.

Case 2: The PCM closes the secondary throttle and leaves them there. - Engine power is greatly reduced. I could still drive the bike, just slowly using the primary throttle to regulate the air that could get past the secondary throttle plates in the closed position (they do NOT fit tight like the primary plates!). Fail moderately safe. Worst case: I pull over, unplug the stepper motor and then use my fingers to push the plates open through the airbox. Then drive home like Case 1.

Case 3: The PCM goes ape-shit crazy and keeps randomly changing the secondary throttle plate position. Damn hard to drive! Pull over, unplug, push open, go home. Fail moderately safe.

mk e wrote:
The better option is to just use a simple standalone stepper driver card. This makes it easy to have the processor control the idle and also makes the control code for stepper or IAC the same I think. Another good way to do idle is using ignition timing....and again I think the same control code code be used.


The board I am designing uses standalone stepper drivers (one for IAC and one for secondary throttle). The eTPU will ONLY be used to generate the step pulse pattern to each driver. The MCU will only have to determine were to move them and then the eTPU will take care of generating the correct pulse sequence (single pulse train, not 4 to 6 outputs like direct control)


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Mon Aug 11, 2014 4:01 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
clcorbin wrote:
mk e wrote:
The problem is NOBODY considers ANYTHING they need optional....but nothing but spark and fuel run an engine ;)


And air.....!


Yes and air...but the ECU doesn't supply that part :)



mk e wrote:
The better option is to just use a simple standalone stepper driver card. This makes it easy to have the processor control the idle and also makes the control code for stepper or IAC the same I think. Another good way to do idle is using ignition timing....and again I think the same control code code be used.


clcorbin wrote:
The board I am designing uses standalone stepper drivers (one for IAC and one for secondary throttle). The eTPU will ONLY be used to generate the step pulse pattern to each driver. The MCU will only have to determine were to move them and then the eTPU will take care of generating the correct pulse sequence (single pulse train, not 4 to 6 outputs like direct control)


If all you need is a pulsed output.....just have the OS generate it. very simple loop with OS wait at each step. There is no easy way to get the eTPU to output say 4 pulses, but the CPU can do that very easily.

for an IAC valve where the freq is constant and you vary duty cycle to control air, the eTPU makes sense, but for a pulse output to move a stepper the number of pulses, the CPU is WAY easier...I think.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Tue Aug 12, 2014 2:57 pm 
Offline
User avatar

Joined: Thu May 30, 2013 1:11 am
Posts: 54
mk e wrote:
If all you need is a pulsed output.....just have the OS generate it. very simple loop with OS wait at each step. There is no easy way to get the eTPU to output say 4 pulses, but the CPU can do that very easily.

for an IAC valve where the freq is constant and you vary duty cycle to control air, the eTPU makes sense, but for a pulse output to move a stepper the number of pulses, the CPU is WAY easier...I think.


Have you read the documentation on the stepper motor eTPU functions? That is EXACTLY what it is designed for. There is a HELL of a lot more to moving a stepper motor than just generating a pulse train. The biggest issues is acceleration and deceleration of the mechanical system (yes, even just the throttle plates and gear drive has significant inertia). Without proper acceleration profiles, you will miss multiple steps and then have no idea were the system is versus were you wanted it (remember, that throttle position sensor is NOT an encoder! It is position in the grosses sense only). That is all built in the SM eTPU code.

Having a high performance MCU generating a stepper pulse and waiting for the next one is just crazy when you have hardware on that same MCU DESIGNED to do just that sort of job.

As an example, let's assume we have a 200 step/rev motor in 1/8 microstepping and we have a 5:1 gear reduction to the throttle plates. If fully closed is position 0 (home), then fully open would be position 2000. (200*8*5 * 1/4 turn):

With an eTPU:

MCU -> eTPU "hey, move from were ever you are to position 2000"
MCU -> Does what ever it needs to do while the eTPU takes care of the stepper motor
eTPU -> MCU "hey, we are at position 2000 like you asked!"
Done.

Without eTPU:

MCU -> Figure out were we are
MCU -> Figure out what velocity we are currently at
MCU -> Figure out correct acceleration to move it in the correct direction
MCU-> Apply step
MCU-> Wait first wait time
MCU-> Apply step
MCU-> Wait second wait time
...repeat until at constant velocity in the correct direction...
MCU-> Calculate when to start deceleration
...repeat step/wait until deceleration time is reached
MCU-> Wait first decleration time
MCU-> Apply step
MCU-> Apply second decleration time
MCU-> Apply step
...etc...etc...etc...
MCU-> Apply final step to position 2000

The whole point having the eTPU is to take all these little time consuming (but simple) tasks away from the MCU core so the core can focus on more important (and probably much less simple) things. Not saying the MCU can't do it, but the eTPU can do it better while freeing up a LOT of MCU cycles.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Tue Aug 12, 2014 6:25 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
clcorbin wrote:

Have you read the documentation on the stepper motor eTPU functions? That is EXACTLY what it is designed for.


Several years back we'd come to a plan to use an external stepper controller like this:

http://www.pololu.com/product/1182

but that doesn't mean it was a good plan.....Let me look at it again.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Thu Aug 14, 2014 1:58 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
mk e wrote:
clcorbin wrote:

Have you read the documentation on the stepper motor eTPU functions? That is EXACTLY what it is designed for.


Several years back we'd come to a plan to use an external stepper controller like this:

http://www.pololu.com/product/1182

but that doesn't mean it was a good plan.....Let me look at it again.


Ok, I've got my brain fixed. I was thinking of the PWM function that can't count pulses, the stepper function does exactly what you say.

Way, way back there was a discussion that ONLY primary engine functions would be in the eTPU (so crank position, fuel, spark) and that is the way everything was planned and laid out.

With the optional out stuff it became apparent it would be easiest to break the rule and put a PWM function and Freq Measure (for wheel speeds) in the eTPU but the plan was still to do steppers using an external controller due to the perception that it would eat up eTPU capacity and since most people don't need it, eat up pins and add cost.

For a frankenECU, none of that much matters beyond it's code most people don't need, but you're right that it certainly can be done nicely using the eTPU.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Tue Aug 19, 2014 9:18 pm 
Offline
User avatar

Joined: Thu May 30, 2013 1:11 am
Posts: 54
You can still use that Pololu breakout board. The only thing that changes is a single eTPU channel is producing the step stream instead of the MCU and a GPIO.

I'm designed in a Ti DRV8825 driver into my board (well, two of them actually). It is basically functionally identical, but it is rated at 2.5A vs. 1A (the throttle should pull 1.7A) and can do 1/32 stepping if needed. Otherwise, same function.

When I first started looking at the SM eTPU code, I was orginally looking at running it direct, but that took FOUR eTPU lines PER stepper AND I would still have to have output drivers. You do get better integration running the eTPU directly (it directly handles direction as well as step). But between eight output drivers and using up 1/4 of the eTPU channels, I decided an external driver would be better.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Fri Aug 22, 2014 9:19 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
That all sounds right Clint.

The routine that calculates Idle controller position should be in % I think....that lets it easily be converted to a stepper position for any stepper motor or to a duty cycle to run any IAC valve.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Fri Aug 22, 2014 11:36 am 
Offline
User avatar

Joined: Thu May 30, 2013 1:11 am
Posts: 54
That sounds like the configuration would be different (eMIOS PWM versus eTPU channel) and then you would need a scaling factor for the stepper so you would know exactly how "far" open is from closed.

But pretty straight forward either way.


Top
 Profile  
 
 Post subject: Re: Where and When do we Restart?
PostPosted: Fri Aug 22, 2014 1:34 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
clcorbin wrote:
That sounds like the configuration would be different (eMIOS PWM versus eTPU channel) and then you would need a scaling factor for the stepper so you would know exactly how "far" open is from closed.

But pretty straight forward either way.


Yes, but that's why I've been on about planning ahead.

The control routine outputs a % valve position. You'll need to have an input for the # steps in the stepper and the DC the IAC works at either way so I'd take full advantage. and make the routine generic.


Then another routine takes that piece of info and runs the actual valve....or just an if satatement would do, or we just burn 2 etpu channels , maybe 2 with a common pin, and output a both a DC and stepper position to the eptu (the etpu has a nice PWM too) and it's done. Simple works for most all applications....execpt mine that will use ignition timing for idle control most likely.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 39 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Theme designed by stylerbb.net © 2008
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
All times are UTC - 5 hours [ DST ]