Fred's firmware development diary comments thread

[sry_not4sale]

Hi Fred,

What comms changes are you making?

Aaron

[Fred]

Working on making all packets cause a reply. Also looking for spurious error packet cause. Also removing cruft from comms as I go. Nothing you care about :-) Yet.

Fred.

[jharvey]

From http://freeems.sourceforge.net/doxygen/ ... so_8c.html Perhaps the general comments should read something like this.

--- General overview ---
- This Module reads Nippon Denso 24/2 sensors. Commonly found on Toyota engines.
- This file contains two interrupt service routines for handling engine position and RPM signals.
- This file requires XYZ set in XYZ file (some how setup ISR table to use this code not another module)
- The first ISR is triggered by each rising edge of pin X the signal should consist of 24 evenly spaced teeth.
- The second ISR is triggered by each rising edge of pin X and should be from the two adjacent teeth.
- This ISR sets a couple global variables, and if certain conditions are satisfied schedules a couple events.

--- Feature scope ---
- This signal style provides enough information for wasted spark ignition and semi sequential fuel injection.
- Supported engines include:
4A-GE
7A-FE
3S-GE
1UZ-FE
Mazda F2T

from a bit lower in the page in the primary ISR

Primary RPM ISR

Summary of intended engine position capture scheme (out of date as at 3/1/09)

--- Triggers that call this ISR ---
- Rising edge of PIN X triggers this ISR

--- Tasks of this ISR ---
- Discards edges that have arrived too soon (lose sync here?)
- Check to ensure we haven't lost sync (pulse arrives too late)
- Compare time stamps of successive edges and calculate RPM and position

--- Outputs of this ISR ---
- Stores RPM and position to global variables (list actual vars here)
- Check events that can be scheduled (spark, fuel, ect)
- Schedule events that fall after this tooth and before the next tooth.
- If at position X then grab a unified set of ADC readings one time in a consistent crank location to eliminate engine cycle dependent noise, and set flag stating that New pulse, advance, etc should be calculated.

I think the secondary ISR should read something like this.

Secondary RPM ISR

--- Triggers that call this ISR ---
- Rising edge of PIN X triggers this ISR

--- Tasks of this ISR ---
- Discards edges that have arrived too soon (lose sync here?)
- Check to ensure we haven't lost sync (pulse arrives too late)
- Compare time stamps of successive edges and calculate RPM and position (calc TDC?)

--- Outputs of this ISR ---
- Stores RPM and position data to global variables (store TDC?) (list actual vars here)

[jharvey]

Also from here

http://freeems.sourceforge.net/doxygen/ ... oders.html

Should there be a file called Tach-Duty.c? Some chuck of code that wiggles a pin's bit, producing a duty cycled tach signal, that could route to an LED and function as a timing gun? It would be mostly for diag, and prototyping purposes. It's probably best to use a normal timing gun to account for slight delays in the ignition circuit, however a tach signal might be handy for a fairly normal tach gauge, and if the tach signal also happens to work as a basic timing gun, it's just an extra feature you can use if you want.

I'm thinking that a nice baby step or stake in the ground, would be to parallel the timing signals from the existing motor (perhaps the jimstim), and have it simply tell you when it's at TDC. Even better if I knew the expected output of the engine position ISR's, I might be able to write Tach-Duty.c making a basic tach signal. That may be in my realm of abilities, but might also be to much to bite off, so feel free to do it with out me.

[Fred]

As for the first post, sure, it could be improved somewhat. I'm working on a total gutting of that file though so may be best to wait till that is complete.

As for tach... I have code that (wastefully) generates a tach signal, but you are thinking of a tach signal a little wrongly.

A tach signal is only required to be of the correct frequency... it is not required to be timed to the engine at all. My tach signal is simply proportional to RPM such that you can tune a tacho or run a tacho with an engine with a diff number of cyls.

Fred.

[jharvey]

Bump, see above comments on Feb 28th about additional code comments.

Perhaps I wasn't excessively clear in conveying my thoughts, perhaps it was just bad timing. Either way the comments you have are great, but didn't really tell me how the hip bone was intended to connect to the leg bone.

[Fred]

Yeah, I had forgotten about that. Timing was and still is bad for that particular file though :

As for the first post, sure, it could be improved somewhat. I'm working on a total gutting of that file though so may be best to wait till that is complete.

That example isn't bad actually, content and formatting wise. Have you considered taking a swing at improving some of the existing ones yourself on other files? If you feel like it you could do that and email them to me (or just push to github) and I could take, tweak and return or something?

I don't see it as high priority right now, but if you are bored :-)

I'll try to keep this sort of thing in mind in future. Probably I'll write some docs as I get back into it because I'll be needing them myself :-)

Fred.

[jharvey]

Right now, I have no idea how the timing signals are brought into the firmware. For example, If I wanted to make a tach signal, I don't know how the RPM circuit will relay data to a my tach signal. Toggling a pin is easy, figuring out how other software will tell me the RPM is my key problem now.

[sry_not4sale]

Re: http://www.diyefi.org/forum/viewtopic.php?p=8068#p8068

http://www.youtube.com/watch?v=VZ2HcRl4wSk !!!!!


I am still set to start coding again on Monday

[Fred]

Good man!

We'll get there in the end! One way or another!

Fred.