A Speed/RPM based launch limiter

Nistune topics related specifically to the 6303 cpu

Moderator: Matt

Post Reply
GZ@hybridka
 

Posts: 112
Joined: Wed May 03, 2006 5:51 pm
Location: Id, USA

A Speed/RPM based launch limiter

Post by GZ@hybridka »

I couldnt fit it in the title, but the topic of this post would be more appropriately, "a speed/rpm based launch limiter without re-writing a bunch of the original rev/speed limit routine".

Speed oriented launch limiter is a nifty little feature that I always wanted to add to my ecus, but there was always a problem. The original rev/speed limit routines are written very closely to each other and are very hard to patch. In the ka24e ecu, the limiter works by looping at the routine a count of 3 times out of 4, instead of continuing, for each program cycle that the threshold (rpm or speed) is met.

Wanting to include a whole new algorithm with a new speed limit and a new rev limiter, I was in a pinch. So what is the solution? 16bits (or should I say 2 consectutive 8 bit chunks) of free ram :) . This may be a bit hard to come by in some ecus depending on how much the code has been modified, but is required for this mod.

So, instead of writing my launch routine near the original limiters, I simply use a routine elsewhere, in some free space, to choose which rev limiter to load from rom to to my free ram location, this is dictated by current speed. The original rev limiter routine is then changed so that it compares current RPM to the ram location rather than the original rom location.

I have this algorithm tested working on the bench, kind of like they do it on hondas.

something like this........

IF Speed < Launch_speed_set THEN
rev_limit = RAM (rom location 1)

IF Speed > Launch_speed_set THEN
rev_limit = RAM (rom location 2)

The only potential problem with this is that if a variable is not loaded into the ram location before the REV limiter routine, on the first program cycle, a rev limiter of zero will be experienced. This isnt really a big problem, either way, not exactly necessary.

Just something for those to ponder....
Matt
Site Admin
 

Posts: 8961
Joined: Sun Jan 29, 2006 1:45 am
Location: Adelaide, Australia
Contact:

Post by Matt »

you could always patch the RESET routine to put the initial RAM value in

writing an autopatcher which does all types of ecus gets difficult. especially the KA24E which has different RAM locations to most other 6303 based ecus

also free ram seems to be a rarity on some ecus. i have been using the RAM tracer along with disassembly trying to find free space. on the MELPS ecus I use the consult buffers for temp storage when consult isn't using them

like yourself i jsr/jmp from where the original routine lived to the new routine and then return back afterwards. there is never enough space to patch over existing code with new code
Post Reply