SpinDrive: A pet project of mine

[thebigmacd]

Well the other day I bit the bullet and signed up with SourceForge so I could finally develop my project. I have been brainstorming on scrap pieces of paper for over a year now on how I could use the Parallax Propeller series of chips to run an ECU. Now that I have a website it is starting to come together in my mind.

Have at 'er
http://spindrive.sourceforge.net/index.html

I code all my HTML in a text editor

[EssEss]

this looks super cool!

[Fred]

It sure has been a long time coming, I look forward to hearing your progress!

One comment: Using MIT allows others to use your work in a proprietary fashion. Are you sure that this is what you want? Just a thought, entirely your decision at the end of the day as it's still free software for the rest of us, just the same.

Fred.

[thebigmacd]

It sure has been a long time coming, I look forward to hearing your progress!

One comment: Using MIT allows others to use your work in a proprietary fashion. Are you sure that this is what you want? Just a thought, entirely your decision at the end of the day as it's still free software for the rest of us, just the same.

Fred.

A lot of the basic "SPIN objects" that I will use from the Propeller community are MIT licensed, including all of the objects provided by the manufacturer. It's not a viral license but I think it is only fair to spread the wealth

[jharvey]

Looks interesting, I'll be interested in keeping up on your project.

I'm curious have you drafted some code yet? You have a bunch of nice specs and such that make it nice for people to collaborate. I like that, I can kind of see how the leg bone connects to the hip bone. If it appears you're moving along, I might get interested and help draft a board.

I'm also a fan of the MIT. I choose the open licence to allow open collaboration with out worrying about risks. I'm not very concerned if someone wants to make $ with the ideas it includes. If someone else builds my own work, there's a good chance I'll consider their efforts value add and I'll buy it from them.

[thebigmacd]

Looks interesting, I'll be interested in keeping up on your project.

I'm curious have you drafted some code yet? You have a bunch of nice specs and such that make it nice for people to collaborate. I like that, I can kind of see how the leg bone connects to the hip bone. If it appears you're moving along, I might get interested and help draft a board.

I'm also a fan of the MIT. I choose the open licence to allow open collaboration with out worrying about risks. I'm not very concerned if someone wants to make $ with the ideas it includes. If someone else builds my own work, there's a good chance I'll consider their efforts value add and I'll buy it from them.

Yes actually I have drafted some code, I just forget where I put it. I think it is on my work laptop somewhere I had a single core incrementing 12 separate "cylinder position" counters from 0-719 degrees in 8th-degree increments and outputting a 50% duty cycle on 12 channels, at 12,000+ rpm. The 12 counters were offset by 60 degrees so the 50% DC square waves simulated sequential injection on a V12 engine. I had a second cog displaying the values of the 12 counters on a text terminal, updating at 10 Hz via NTSC output.

There is more coming on the spec tonight, some of which will define the core-core ("Cog-to-Cog" in Propeller-speak) messaging/interfaces. The key feature of the propeller chip is a virtual I/O port called "Port B" that is 32-bits long and acts just like the I/O port (register) called Port A. This port can be read by all cores *simultaneously* so it is a perfect place to write an incrementing "engine position" counter. All other shared memory is accessible every 16 clock cycles by each cog.

[thebigmacd]

I have pretty much settled on my spec format. This quoted section deals with defining what variables the wheel decoder will update. Does this give a clear enough framework for a contributor to understand what this chunk of code should do? The term "Hub RAM" may be unfamiliar, it just means memory that is shared between all cores, as opposed to their local RAM. Port B is a 32-bit "virtual I/O register" that can be accessed simultaneously by all cores.

2.2.2.7) Variables

The Decoder Object shall update a Hub variable called LAST_KNOWN_POSITION. This variable shall be in the form of a 16-bit unsigned integer. Each increment shall represent 1/65536th of two revolutions of the crank shaft (720 deg). The object shall update this variable whenever a valid tooth is decoded successfully, and shall indicate the presence of a new value by setting a 1-bit flag called NEW_KNOWN_POSITION in Hub RAM.

LAST_KNOWN_POSITION has an angular resolution of approximately 0.011 deg.

Code: Select all

LAST_KNOWN_POSITION	Engine Position
0						 0.00 deg
91						1.00 deg
46784					513.98 deg
65535					719.99

The Decoder Object shall update a Hub variable called LAST_TOOTH_ERROR. This variable shall be in the form of a 8-bit unsigned integer. Each discrete value shall represent 1 of 256 predefined tooth error types. The object shall update this variable whenever a tooth is invalid, and shall indicate the presence of a new value by setting a 1-bit flag called NEW_TOOTH_ERROR in Hub RAM.

The Decoder Object shall update a Hub variable called LAST_KNOWN_SPEED. This variable shall be in the form of a 16-bit unsigned integer. Each value shall represent the number of increments of 1/65536th of an engine revolution per 10us. No status flag is required for this variable.

The Decoder Object shall set a 1-bit flag called WHEEL_DATA_PRESENT in Port B when it senses a tooth. The object shall clear the WHEEL_DATA_PRESENT flag when no teeth have been sensed for a defined period of time.

The Decoder Object shall set a 1-bit flag called WHEEL_DATA_GOOD in Port B when it successfully decodes a tooth. The object shall clear the WHEEL_DATA_GOOD flag when a tooth is invalid.

[EssEss]

the flag represents when a 'hard' tooth edge arrives ? or is set whenever a position prediction is made (btwn hard edges) ?
also, the position value will never 'miss' locations ? as in, it's guaranteed to cnt up 0 to 65535 and never skip ?

I'd spec those two things

Is there an overall 'sync/unsync' flag ? or is this the WHEEL_DATA_GOOD flag ?

since this is for a 4-cycle operation only, I didn't see any spec which specifies a cam sync input to know which phase the motor is on. Along with that, I'd spec the decoder behavior to specify what state to expect (as a consumer of the decoder) until the decoder figures out what phase its on (is it simply 'unsynced' until phase info arrives ?)

how will you handle cam decoding ? is it just another 'instance' of a decoder ? this decoder would also have to handle 0-360 only since 0-720 dosen't make sense for a cam decoder. at that point a universal decoder spec might not be possible unless it handles both 0-360 or 0-720.

I have lots more questions. But I don't want to overload you I have a couple of prop devboards and wouldn't mind testing anything as it pops up.

[EssEss]

I was thinking about this more last night .. it looks like a 'deocder' is a seperate concept from a 'position'. as in, a 'position' obj would be composed of one to multiple 'decoders' depending on if you needed to decode a cam input in addition to decoding crank.

is this prj entirely spin or are you going to mix in some pasm too ?

[thebigmacd]

the flag represents when a 'hard' tooth edge arrives ? or is set whenever a position prediction is made (btwn hard edges) ?
also, the position value will never 'miss' locations ? as in, it's guaranteed to cnt up 0 to 65535 and never skip ?

I'd spec those two things

Is there an overall 'sync/unsync' flag ? or is this the WHEEL_DATA_GOOD flag ?

since this is for a 4-cycle operation only, I didn't see any spec which specifies a cam sync input to know which phase the motor is on. Along with that, I'd spec the decoder behavior to specify what state to expect (as a consumer of the decoder) until the decoder figures out what phase its on (is it simply 'unsynced' until phase info arrives ?)

how will you handle cam decoding ? is it just another 'instance' of a decoder ? this decoder would also have to handle 0-360 only since 0-720 dosen't make sense for a cam decoder. at that point a universal decoder spec might not be possible unless it handles both 0-360 or 0-720.

I have lots more questions. But I don't want to overload you I have a couple of prop devboards and wouldn't mind testing anything as it pops up.

The NEW_WHEEL_POSITION flag is set every time a 'hard' tooth arrives, is found to be valid, and its position is written to LAST_KNOWN_POSITION

The LAST_KNOWN_POSITION is nothing more than the position of the last tooth to arrive; if NEW_WHEEL_POSITION is cleared, LAST_KNOW_POSITION has no meaning. By definition it will always skip.

The WHEEL_DATA_GOOD is an overall 'sync' flag.

Actually there is a madness to my method of not specifying whether there is a cam sync input or not: the actual "decoder object" will be completely different code depending on the crank/cam input configuration. I am actually mulling over specifying two extra flags called ENGINE_PHASE_0_TO_359 and ENGINE_PHASE_360_719 that will be used to determine whether the cam sync signal has arrived yet, and dropping the LAST_KNOWN_POSITION variable to only 0-359 degrees. Short of writing a lengthy spec, i'll try to explain in a nutshell: if ENGINE_PHASE_0_TO_359 is set, the injection and ignition logic will fire all channels associated with that phase at their respective angle. Same with ENGINE_PHASE_360_TO_719. The hidden advantage is if the actual phase is unknown, BOTH flags can be set and the associated injection and ignition channels will fire during both phases. Simple logic in the "injection" and "ignition" objects can detect this and drop the fuel pulse width by 50%. If a cam input is never specified, the engine always runs as wasted spark and two fuel pulses per full-cycle per channel. I think 2-cycle operation is not out of the question: just never set ENGINE_PHASE_360_TO_719 and only configure the required ignition and injection channels to fire on the first phase.

Another important aspect to understand is by "object" I don't mean "core" or "Cog". I specified one or two cogs, which are contained and started by the "object", depending on how the programmer wants to tackle a given wheel setup. For example, for Subaru 6/7 only one Cog would be needed to monitor both the cam and crank signals, as they never have the risk of occurring simultaneously. However, for a generic missing tooth crank wheel in conjunction with an arbitrarily-phased cam trigger one may want to dedicate one core for the crank input and one for the cam in case they occur at the same time or within one processing loop. How the two cogs interact with each other in memory to set/clear the required flags and variables is up to the programmer. As long as the proper memory locations are written to with correct information, the remainder of the firmware doesn't care.

Another key aspect: absolutely *no* angle prediction is done by this object. It just "drops new known position and speed information off" to the "simulator object" that I am working on the next section of the spec on my website. LAST_KNOWN_POSITION is definitely not directly referenced to time the fuel injection or ignition. That is the role of CURRENT_POSITION, a globally-accessible integer stored in Port B, and written to by the "simulator object".

Remember, we have 8 cores that we can dedicate to different functions, and slower, less time-critical operations will be done on a second chip

A summary of all the cores I predict on the "Coordinator" chip:

1 Cog: Main Object (bootup operations, watchdog, timeout, etc)
2 Cogs: Comms Object (duplex high-speed serial chip-to-chip)
2 Cogs: Decoder Object (crank and/or cam inputs)
1 Cog: Simulator Object (predicts and increments engine position, sets flags on rollover)
1 Cog: Injection Object (starts injection based on crank angle + flags, ends injection based on time + flags)
1 Cog: Ignition Object (start dwell based on crank angle + flags, fires coils based on crank angle + flags)

Total 8 Cogs

The "Supervisor Chip" will do all of the math and send the resulting pulse widths and angles back on the high-speed comms bus.
8 Cogs I haven't sorted out yet.

Perhaps this image will help: