nAst1: Progress and Concepts Thread

[robertisaar]

could be tomorrow... i mean, the stuff that needs added in isn't that complex, won't take long to test.

[robertisaar]

wow, i'm easily distracted.... actual code to do the MAP PE threshold only took ~10 minutes to deal with, but there was a good 2 hours of time from start to end that i can't reallt account for....

anyway, know what pin we determined would work well for the reverse solenoid? i can't remember. this could be used for a lot of things actually, i may add in a bunch of mini-patches to allow for different types of values to be compared against. so if someone wanted to run the 3500/3900 VVT function at two discrete settings based on RPM, they could just set the RPM switch point and choose normally on or normally off and they'll be good to go. or always having a fan active below a specific MPH... or a throttle level below which a wastegate is fully open or closed....

lot of possibilities.

anyways, trying to get the AE while PE issue done today too, just working on the t56 solenoid/multi-purpose output.

[caffeine]

Shift solenoid B/low coolant light on 90- ECMs. I think anyway.

Also would it be simple to add a TPS threshold to the 1-2step limiters so that I'm not constantly hitting it in daily driving? (Need to get some revs going to engage 1st with the 3.23 gears). Also could be good for doing burnouts at the track without needing a switch to disable the limiter. I.E. not going full throttle until clutch is engaged.

[robertisaar]

sounds like the right circuit.... very few to no vehicles using the PCM driven low coolant light.

TPS threshold sounds like a good idea... only for step 1, or step 2 as well? step 2 is really only intended for WOT w/pedal in anyway, so i'm not sure if it would be of any use. i guess if you were to run above the step 2 cut threshold, drop throttle and then clutch for the shift, it could happen(and not necessarily be wanted) without a TPS threshold on it.

[caffeine]

TPS threshold for step 1 and 2, since I could hit step 2 rev matching for a downshift.

[robertisaar]

ah, yeah that would do it too...

guess i'll add that in the to-do list for 1.08 as well...

thinking out loud: logic would go something like this:

TPS threshold for step 1 check
if pass, do RPM threshold check for step 1, else go check step 3
if too high, go do cut

do TPS threshold for step 2 check
if pass, do RPM threshold check for step 2, else go check step 3
if too high, go do cut

step 3 RPM check
...
...



this way, step 3 will ALWAYS be referenced against if not cutting already due to 1/2.

[caffeine]

That logic, of course also checking clutch pedal status for step 1 and 2 .

[robertisaar]

oh, durr....

at least the hard part is already done, modifying the patch to have a couple more items to check is cake.

of course, if i knew C/C++ and could use it to compile directly to 6811 assembly, that would almost be the exact string i would need to punch in.... but high level languages = me no comprende.

[caffeine]

Unfortunately, higher level languages usually have the trade off of a bunch of unused code taking up space.

[caffeine]

Then again, a standard C library probably wouldn't have too much use in this application. Most if any of the functions used would be mathematically related Im assuming.

[robertisaar]

a lot of it looks that way.

supposedly, GM did the main loop and a lot of the minor loops in C with certain sections of code done by hand...

some of the overflow and underflow checking is a dead giveaway.

[caffeine]

Interesting..... Makes you wonder how difficult it would be to modify a minimalist open-source C compiler... Of course then the program would have to be translated into C. How different are the assembly instructions used here from, say, x86 instructions?

If this were available in C code I'd be interested in doing some of my own programming.

[robertisaar]

i would have no idea.... any other language/instruction set i try to get into, it makes my head spin trying to correlate new instructions to ones i know in 6811.

as an example:

C38C:
JMP L96D8    ;go do my code

96D8:
LDAA L0054   ;grab MAP A/D(1BAR real or emulated)
CMPA L9708   ;compare to MAP above which always PE
BHI L96E5    ;branch if high enough to enter PE
LDX L8B24    ;otherwise, start return to normal code
JMP LC38F    ;and return
96E5:

LDAB L0042   ;load bits
PSHB         ;temp store
ANDB $DF     ;clear PE bit(since it's not cleared anywhere else)
STAB L0042   ;save byte
PULB         ;grab real previous PE status
JMP LC3DB    ;go back to normal code, PE enabled from high MAP

i can understand this easily... only 2 accumulators to deal with(both 8-bit, but can be used as a single 16-bit), two 16 bit index registers that don't get used too often, a stack pointer, a program counter, status register... and not much else.

[caffeine]

Seems kinda similar... It's been a while but IIRC x86 has 4 16-bit registers, which can double as 32-bit registers with different instructions. Some of the hardware stuff would have to be written in inline assembly, but most C compilers I know of have a way of inserting direct assembly code.

[robertisaar]

i...... uh, i wouldn't know.

getting beyond my knowledge/experience. i don't think i would want to punch out assembly for anything more complex than the 6811, too many things to keep track of. just trying to follow CPU32 in a motorola 68332 gives me a headache.