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....
A Speed/RPM based launch limiter
Moderator: Matt
-
- Posts: 112
- Joined: Wed May 03, 2006 5:51 pm
- Location: Id, USA
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
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