Instructions to change fuel maps on 14CUX Griffith, Chimaera
Discussion
Steve, I don't know who's worse when it comes to asking complicated questions...you or Dave.
The strategy for measuring road speed is absurd and I find it hard to believe that it was originally planned that way. It wouldn't surprise me if the rules were changed for the 14CUX software developers halfway through the game. Maybe the original goal did not involve a road speed limit but was simply to identify the idle mode switch point. This would be easy since the VSS frequency is very low at this point (about 7 Hz) and depends on low RPM and closed throttle.
Another possibility is that an external frequency to voltage converter may have been planned. The signal which now comes directly from the VSS as a square wave would have been an analog representation of road speed. The ADC could then very efficiently measured it. In my opinion, this is the way it should have been done.
One bright spot in all of this is that the ADC has a special comparator mode that gave the developers hope that they could actually measure road speed by using many VSS waveform samples. Unlike the normal 8-bit or 10-bit conversions which take about 100 uSec (a long time when you consider that the MPU can complete an instruction in as little as 2 uSec), a comparator measurement is only 18 uSec. This mode requires that you pre-load a compare register with a threshold value and the ADC result is a single bit which indicates if the measured value is greater or less than the threshold. Perfect for measuring the state of a square wave. This mode allowed the developers to sprinkle these measurements liberally throughout the interrupt code. Each time the measurements go from 1 to 0 a counter is incremented. As the VSS waveform increases in frequency, the counter increments faster.
So why is there still a road speed service routine in the main loop's ADC list? It's main purpose is to check a timer and approximately once per second, the counter is saved as the road speed value (in KPH) and the counter is reset to zero for the next sample interval. This is an important point. If this service routine does not get called, or fails to complete due to the next spark interrupt, the counter, although still incrementing, is never saved as road speed. The road speed value stops changing and the road speed limit is effectively disabled. So, to answer your question, there is really no calculating being done. The comparator subroutine increments the counter and the service routine periodically saves the value. One side effect of this is that the road speed is only updated about once per second as you may have noticed in the RG log files.
Yes, the 8-bit VSS measurement preceding the road speed service is a waste of time. This service routine should have been called separately and should not have been part of the ADC list. It does, however, support my theory that a FVC may have once been planned.
The idea of defeating the road speed limit by changing the high RPM ADC list is OK if you are limited to changing only the data portion of the PROM and not the code itself. You are right in questioning the usefulness of this ADC list. All you need is one call to the RS service each time the interrupt returns and the normal ADC mux lists provide this. Keep in mind that the list is restarted from the beginning each time the interrupt ends and the first item in the list is RS service ($87). So, other than providing an odd way to defeat the RS limit, the high RPM list probably doesn't do anything useful. It may have been a prior attempt to solve the road speed limit functionality which was never removed from the code once they solved the problem by starting all lists with $87. There is simply no apparent need to have done both.
The road speed comparator measurements are still a terrible burden on the processor. R3365 shows one of Lucas' attempts to make these calls more efficient but more can be done. I don't so much care about the RS limit. I just like having accurate road speed in my log files.
The strategy for measuring road speed is absurd and I find it hard to believe that it was originally planned that way. It wouldn't surprise me if the rules were changed for the 14CUX software developers halfway through the game. Maybe the original goal did not involve a road speed limit but was simply to identify the idle mode switch point. This would be easy since the VSS frequency is very low at this point (about 7 Hz) and depends on low RPM and closed throttle.
Another possibility is that an external frequency to voltage converter may have been planned. The signal which now comes directly from the VSS as a square wave would have been an analog representation of road speed. The ADC could then very efficiently measured it. In my opinion, this is the way it should have been done.
One bright spot in all of this is that the ADC has a special comparator mode that gave the developers hope that they could actually measure road speed by using many VSS waveform samples. Unlike the normal 8-bit or 10-bit conversions which take about 100 uSec (a long time when you consider that the MPU can complete an instruction in as little as 2 uSec), a comparator measurement is only 18 uSec. This mode requires that you pre-load a compare register with a threshold value and the ADC result is a single bit which indicates if the measured value is greater or less than the threshold. Perfect for measuring the state of a square wave. This mode allowed the developers to sprinkle these measurements liberally throughout the interrupt code. Each time the measurements go from 1 to 0 a counter is incremented. As the VSS waveform increases in frequency, the counter increments faster.
So why is there still a road speed service routine in the main loop's ADC list? It's main purpose is to check a timer and approximately once per second, the counter is saved as the road speed value (in KPH) and the counter is reset to zero for the next sample interval. This is an important point. If this service routine does not get called, or fails to complete due to the next spark interrupt, the counter, although still incrementing, is never saved as road speed. The road speed value stops changing and the road speed limit is effectively disabled. So, to answer your question, there is really no calculating being done. The comparator subroutine increments the counter and the service routine periodically saves the value. One side effect of this is that the road speed is only updated about once per second as you may have noticed in the RG log files.
Yes, the 8-bit VSS measurement preceding the road speed service is a waste of time. This service routine should have been called separately and should not have been part of the ADC list. It does, however, support my theory that a FVC may have once been planned.
The idea of defeating the road speed limit by changing the high RPM ADC list is OK if you are limited to changing only the data portion of the PROM and not the code itself. You are right in questioning the usefulness of this ADC list. All you need is one call to the RS service each time the interrupt returns and the normal ADC mux lists provide this. Keep in mind that the list is restarted from the beginning each time the interrupt ends and the first item in the list is RS service ($87). So, other than providing an odd way to defeat the RS limit, the high RPM list probably doesn't do anything useful. It may have been a prior attempt to solve the road speed limit functionality which was never removed from the code once they solved the problem by starting all lists with $87. There is simply no apparent need to have done both.
The road speed comparator measurements are still a terrible burden on the processor. R3365 shows one of Lucas' attempts to make these calls more efficient but more can be done. I don't so much care about the RS limit. I just like having accurate road speed in my log files.
Hopefully this won't end up being a confuse-a-dan, but for completeness, is there an id label for the AdcMux table that appears at #C231 in the earlier TVR versions (pre-R3383, I think), such as R2422: #C231 : 8B 86 02 03 84 02 8D 88 02 8B 80 85 81 FA
Where the emphasis is more on fuel temperature not road speed, but the table is called in a high_rpm_patch*. Maybe there were concerns about fuel vaporisation at high engine speeds/temperatures? Looks like the programmers were tackling high rpm issues for some time.
Where the emphasis is more on fuel temperature not road speed, but the table is called in a high_rpm_patch*. Maybe there were concerns about fuel vaporisation at high engine speeds/temperatures? Looks like the programmers were tackling high rpm issues for some time.
- This is renamed CheckForHighSpeed, normalSpeed, etc. in latter tunes as in Dan's mainloop asm file, but there's no hiRpmAdcMux.
Edited by davep on Tuesday 20th May 13:34
Well Dave, I am confused. I never noticed this until you, just now, pointed it out. Code-wise, this IS the same high RPM patch but its purpose seems to be very different. Although the fuel temperature measurement is first in the list, I don't understand why. Fuel temp is a minor fueling input and its secondary purpose (monitoring underhood temperature) is mostly needed for hot restarts. I noticed that the next item in the list is the A/C service. The underhood temp may be an input to A/C compressor control in older tune versions. There is actually an A/C control patch in the fuel interrupt itself which suggests that A/C control may have been as troublesome as road speed.
It seems that, for years, the developers may have simply been adding patches and making changes in response to complaints resulting from either customers or internal testing. Someone at Land Rover may have made the decision that the road speed limit is more important than properly working A/C and the high RPM patch was then re-purposed. It would be great if one of the original people involved came forward and shed some light on this.
It seems that, for years, the developers may have simply been adding patches and making changes in response to complaints resulting from either customers or internal testing. Someone at Land Rover may have made the decision that the road speed limit is more important than properly working A/C and the high RPM patch was then re-purposed. It would be great if one of the original people involved came forward and shed some light on this.
If I road test to compare R2422 (old hiRpmAdcMux table) and R2967 (later hiRpmAdcMux) what are the related parameters or characteristics I should be looking out for in the fuelling and the data logging results? How does the road speed limit manifest itself?
Looking at the R2422 version it effectively calls in an 'extra' trimmed down ADC Mux table pass at high RPM plus an extra fuel temperature service:
Looking at the R2422 version it effectively calls in an 'extra' trimmed down ADC Mux table pass at high RPM plus an extra fuel temperature service:
- C231 : 8B 86 02 03 84 02 8D 88 02 8B 80 85 81 FA
- C231 : 87 86 02 03 84 02 8D 88 02 8B 80 85 81 8E FA FA
Dave, I'm not sure I understand your question. The road speed service routine (which is triggered by $87 in the list) is needed to update the road speed value. The road speed value is then compared with a threshold value at the fueling point in the code and skips fueling on one bank. So if you can successfully log data while this is happening, I think you would see the road speed pass the threshold value but no other changes in the log file. The fueling value for the shut off bank is still being updated but just not applied to the timer since code is taking a different path. The first list that you show has no road speed service so your log file would show the road speed becoming static whenever RPM is greater than 4185. As Steve pointed out to me, there's still a possibility, on some vehicles, that you can hit the road speed limit before reaching 4185 RPM. If that's the case, using this technique to defeat the limit won't work.
danbourassa said:
The strategy for measuring road speed is absurd and I find it hard to believe that it was originally planned that way. It wouldn't surprise me if the rules were changed for the 14CUX software developers halfway through the game. Maybe the original goal did not involve a road speed limit but was simply to identify the idle mode switch point.
Or maybe the Motorola reference design didn't include a road speed limiter, there is no mention of a road speed limiter on the www.bigturbo.co.uk or is that what you would expect for Ferrari, Aston Martin and Cosworth.danbourassa said:
One bright spot in all of this is that the ADC has a special comparator mode that gave the developers hope that they could actually measure road speed by using many VSS waveform samples. Unlike the normal 8-bit or 10-bit conversions which take about 100 uSec (a long time when you consider that the MPU can complete an instruction in as little as 2 uSec), a comparator measurement is only 18 uSec. This mode requires that you pre-load a compare register with a threshold value and the ADC result is a single bit which indicates if the measured value is greater or less than the threshold. Perfect for measuring the state of a square wave. This mode allowed the developers to sprinkle these measurements liberally throughout the interrupt code.
So comparator mode is another parameter passed each time to the Hitachi Analogue to digital chip, not called to turn on and off.danbourassa said:
The comparator subroutine increments the counter and the service routine periodically saves the value.
arrrr ha, I understand, so stopping the service routine wouldn't stop the speed counter but would stop the speed being calculated and saved so you wouldn't see the speed change in the RG log. Wow Dan you certainly have got your head around the code.danbourassa said:
The idea of defeating the road speed limit by changing the high RPM ADC list is OK if you are limited to changing only the data portion of the PROM and not the code itself.
That's me BUT not for long !! thanks to you as I would like to use the later code with the improved idle control without the road speed limiter but keeping the road speed updated in the RG log. Arrr look what I found in the spark interrupt. I'm very tempted to just delete the three lines of code in else statement. I see I can't just use the BUILD_TVR_CODE=1 in the data.asm as it will knock out a whole chunk of code in ignitionInit for preventing closed loop & allows closed loop)
IF BUILD_TVR_CODE
; nothing
ELSE
;-----------------------------------------------
; Road speed limiting code (not in TVR code)
;-----------------------------------------------
ldaa bits_2004 ; test bits_2004.0 (1 = road speed over limit)
bita #$01 ; if set, skips injector refresh for right bank and
bne .LEA71 ; branch down to toggle bank bit
ENDC
Or could I change bne (branch if not equal) to brn (branch never) to stop skipping firing the right/even bank or something like that, Sorry I'm learning assembler on the job. In the flow diagram it skips the odd/left bank so Dan please can you get your act together, only joking.
Dan, if you are planning a NewCode_V1 I bet the first option you'll include is NO_ROAD_SPEED_LIMIT=1 in data file to knock out the speed limiter code and knowing you so well you'll really go to town making the code more efficient.
Dan,
What revision would you suggest I use if I want to start running the later idle control code. I'm thinking of sticking to 3383 as its the last UK revision but does 3526 and 3652 have any further enhancements worth having? I see they are for NAS plus 3652 is a special for NAS cold weather.
Also, can I start experimenting with different prom build options (CRASM pseudo-mnemonics combinations), like the following example below as it may flash the mil lamp at startup. I realise R3383 should have NEW_STYLE_AC_CODE=1, also for the later/better idle control code should I set BUILD_R3360_AND_LATER = 1 instead of BUILD_R3383 = 1? I realise I'll also have to include my 4.3 data and tread carefully with the last few variables in the data.
BUILD_R3365 = 0
BUILD_R3383 = 1
BUILD_R3652 = 0
BUILD_R3360_AND_LATER = 0
BUILD_TVR_CODE = 0
NEW_STYLE_AC_CODE = 0
NEW_STYLE_FAULT_SCAN = 0
NEW_STYLE_FAULT_DELAY = 0
NEW_STYLE_MIL_CODE = 1
Good Night
Steve
Edited by stevesprint on Saturday 24th May 23:36
danbourassa said:
Dave, I'm not sure I understand your question.
Sorry I was a bit vague, but you answered it in your response.I posed the question as it has recently occurred to me that I've never driven a 14CUX EMS car with a tune revision later than R2422.
I've now got to read in detail the post that Steve's just put up.
stevesprint said:
Or maybe the Motorola reference design didn't include a road speed limiter, there is no mention of a road speed limiter on the www.bigturbo.co.uk or is that what you would expect for Ferrari, Aston Martin and Cosworth.
Yes, that's what I would expect. Same as TVR.stevesprint said:
So comparator mode is another parameter passed each time to the Hitachi Analogue to digital chip, not called to turn on and off.
Any improvements we can make to the comparator test would be worth doing since it's called so often. In R3365, they triggered the comparator test before jumping to the subroutine to save a little time. We may not need the extended cycle which would save 9 uSec per call. Also, I don't know why they reloaded the threshold register with the same value every time. This seems unnecessary.stevesprint said:
Or could I change bne (branch if not equal) to brn (branch never) to stop skipping firing the right/even bank or something like that, Sorry I'm leaning assembler on the job. In the flow diagram it skips the odd/left bank so Dan please can you get your act together, only joking.
I had the left/right thing backwards initially. We'll be finding conflicts for years!Changing BNE to BRN has the advantage of changing code the least if you still want to do binary compares, otherwise it's more efficient to just remove those lines and save the extra clock cycles.
stevesprint said:
Dan, if you are planning a NewCode_V1 I bet the first option you'll include is NO_ROAD_SPEED_LIMIT=1 in data file to knock out the speed limiter code and knowing you so well you'll really go to town making the code more efficient.
Yes, the speed limit has to go.The main thing that needs to be made more efficient is the spark interrupt. At high RPM the interrupts become continuous and code functionality starts to break down. This is what led to ad hoc patches like the high RPM ADC table. There is also an A/C compressor control patch in the spark interrupt. It has no business being there. There is also obsolete development code that needs to be removed. Some code in the interrupt tries to control circuitry that is not on the board (see I10 near the PROM).
The single worse time hog is the division loop that calculates RPM from pulse period. It loops 24 times and this one function consumes about 1100 uSec which is about 25% of the total interrupt. This is why they bypassed this calculation at about 1950 RPM. By the way, I am able to reduce the loop to 12 iterations and cut this time almost in half. I'm also looking at using a look-up-table for MAF linearization. This will use more space in the PROM but that's available and free to use. This should save about 140 uSec.
Another thing I'm looking at is RAM utilization. Internal RAM is faster than external (PAL) RAM so it makes sense that often used variables should be in faster memory and seldom used variables should be in slower memory. They seem to have given no regard to this.
stevesprint said:
What revision would you suggest I use if I want to start running the later idle control code. I'm thinking of sticking to 3383 as its the last UK revision but does 3526 and 3652 have any further enhancements worth having? I see they are for NAS plus 3652 is a special for NAS cold weather.
I don't really know yet. One of the advantages of having a single code base with directives (IF/ELSE/ENDC) is that areas having differences can be compared. I just haven't spent a lot of time yet looking at it from that angle.stevesprint said:
Also, can I start experimenting with different prom build options (CRASM pseudo-mnemonics combinations), like the following example below as it may flash the mil lamp at startup. I realise R3383 should have NEW_STYLE_AC_CODE=1, also for the later/better idle control code should I set BUILD_R3360_AND_LATER = 1 instead of BUILD_R3383 = 1? I realise I'll also have to inculde my 4.3 data and tread carefully with the last few variables in the data.
I don't know that the build options are self contained in an "a la carte" sort of way. That initial effort was focused on recreating original code. Most of these options should be safe to try and won't make your engine explode. Hopefully, soon we can agree on a new code base with some safe improvements and build on that.danbourassa said:
The strategy for measuring road speed is absurd and I find it hard to believe that it was originally planned that way. It wouldn't surprise me if the rules were changed for the 14CUX software developers halfway through the game.
Or may be the Motorola reference design code didn't include a road speed limiter and Lucas added the road speed limiter and then TVR removed only a very small part of it.danbourassa said:
The main thing that needs to be made more efficient is the spark interrupt. At high RPM the interrupts become continuous and code functionality starts to break down.
Sounds good for extended RPM tables and hopefully at high RPM we'll see more records in the RoverGauge log.danbourassa said:
There is also an A/C compressor control patch in the spark interrupt. It has no business being there.
and I see it's not ripped out or fixed with the NEW_STYLE_AC_CODE directive.danbourassa said:
Some code in the interrupt tries to control circuitry that is not on the board (see I10 near the PROM).
How do you know these things???? And please don't answer.danbourassa said:
I'm also looking at using a look-up-table for MAF linearization
You would be very popular if you could enhance it to a Manifold Absolute Pressure look up table and do away with the AFM. I know its almost impossible as you would have to add an Air Charge Temperature Sensor input with another look up table.danbourassa said:
Another thing I'm looking at is RAM utilization. Internal RAM is faster than external (PAL) RAM so it makes sense that often used variables should be in faster memory and seldom used variables should be in slower memory. They seem to have given no regard to this.
Its incredible they seem to have given no regard to this, I like to think there must have been a good reason.danbourassa said:
I don't really know yet. One of the advantages of having a single code base with directives (IF/ELSE/ENDC) is that areas having differences can be compared. I just haven't spent a lot of time yet looking at it from that angle.
Its definitely easy to see the revision differences plus when you change the code you don't have to apply the change to 5 separate versions.
danbourassa said:
I don't know that the build options are self contained in an "a la carte" sort of way. That initial effort was focused on recreating original code. Most of these options should be safe to try and won't make your engine explode. Hopefully, soon we can agree on a new code base with some safe improvements and build on that.
Dan"a la carte", Good job I'm Steve Steak and chips as it comes with a beer to wash it down.
As all NAS proms have BUILD_R3360_AND_LATER = 1 and I want use the latest UK tune I'll start by creating a new data file based on R3383 but with my 4.3 full data structure. Once I've proved it runs ok I'll then try removing NEW_STYLE_AC_CODE as it adds an "engine has started A/C down counter" that is counted down in roadSpeed that I don't need, plus there is a tests for very hot coolant above 105 C. I'll then try NEW_STYLE_MIL_CODE and NEW_STYLE_FAULT_SCAN as they appear in one place and look self contained, I won't hold you responsible for any dramas.
I see in StepperMtr2 & idleControl there is lots of code differences for BUILD_R3360_AND_LATER with the comment 'Griff does NOT have this code' I assume that means also not in 3383 as TVR and 3383 are the only tunes without BUILD_R3360_AND_LATER=1.
Steve Sprint
Edited by stevesprint on Sunday 25th May 09:56
stevesprint said:
danbourassa said:
Another thing I'm looking at is RAM utilization. Internal RAM is faster than external (PAL) RAM so it makes sense that often used variables should be in faster memory and seldom used variables should be in slower memory. They seem to have given no regard to this.
Its incredible they seem to have given no regard to this, I like to think there must have been a good reason.Dan will your plans for big code changes,
Edited by davep on Sunday 25th May 22:38
As a university lecturer teaching microprocessor architectures please don't get confused here. The local RAM on the processor is NOT cache memory. Cache memory is where a local copy of code or data is stored locally in fast memory to stop the slowing down of the processor by having it to always access external memory. First commercial chip to have this was the 68020 in 1984 BTW. It requires a lot of support logic and software to do the tag comparisons and validate the results. The Intel Cache mechanisms came out about 10 years after everyone else and to be honest the i86 architecture never really made many inroads into embedded systems. It was the Intel RISC offerings that had some success.
There are problems with caches in embedded systems in that data corruption is a major potential problem. They require a lot of careful control but as the 6801 doesn't have this, no need to worry.
The 6801 in the 14CUX also has a synchronous bus and the external memory runs at the same speed that the processor clock does i.e. 1 MIPs. Access to internal memory is not faster. Look at the instruction timings and they are the same. There is no difference in performance. You could replace 150ns ROM with 5ns static and it will not go any faster!
The reason why there is internal RAM is to go with the internal ROM that was available on some of the parts so that it could run standalone. The internal RAM can be battery backed up very easily which is why some variables are located there and no other reason.
There were also speed variants so if you wanted to run say at 1.25 MHz, you had to have a faster processor and peripherals to match.
There are problems with caches in embedded systems in that data corruption is a major potential problem. They require a lot of careful control but as the 6801 doesn't have this, no need to worry.
The 6801 in the 14CUX also has a synchronous bus and the external memory runs at the same speed that the processor clock does i.e. 1 MIPs. Access to internal memory is not faster. Look at the instruction timings and they are the same. There is no difference in performance. You could replace 150ns ROM with 5ns static and it will not go any faster!
The reason why there is internal RAM is to go with the internal ROM that was available on some of the parts so that it could run standalone. The internal RAM can be battery backed up very easily which is why some variables are located there and no other reason.
There were also speed variants so if you wanted to run say at 1.25 MHz, you had to have a faster processor and peripherals to match.
shpub said:
Access to internal memory is not faster. Look at the instruction timings and they are the same. There is no difference in performance.
You are wrong about this. Internal RAM is accessed by Direct addressing with a 1-byte operand. The upper address byte is assumed to be zero. External memory is accessed by Extended addressing using a two byte operand and an additional clock cycle. Please refer to the datasheet.Maybe I didn't explain fully...
I have the data sheet and user manual as I used to work for Motorola. In fact I managed the Lucas support team and I seem to remember many discussions over where to put variables and the amount of internal RAM. Their requirements were always increasing/changing and they were often after every last drop of performance.
The access speed of the memory is the same as external memory. It is not faster.
You are referring to one of the six addressing modes that "cheats" a little by assuming the top address byte is 0. As a result, it will take one clock less to access as you say. However, this address mode is not available for every instruction which means that the benefit can be of limited use. Logical shifts, multiply, branches, dec, inc and a whole other list of instructions can't use this direct mode and will execute in the same time as external memory. See pages 30 onward in the data sheet. The idea behind it was to speed up access to the control registers initially which are also memory mapped into this area.
As a result, the benefit is often negated because the faster direct mode can't be used. IIRC This is why Lucas put some of the variables into the external memory because the instructions did not support the faster Direct mode and so offered no performance advantage. In addition, having the variables in external memory meant that they could use logic analysers to see data changes which could not be used with variables stored internally.
The point of this is that it does not automatically follow that moving variables into the internal memory will always makes things faster in this case. It will only happen if the instructions that manipulate the data can use this direct mode. If not, there is no advantage.
I have the data sheet and user manual as I used to work for Motorola. In fact I managed the Lucas support team and I seem to remember many discussions over where to put variables and the amount of internal RAM. Their requirements were always increasing/changing and they were often after every last drop of performance.
The access speed of the memory is the same as external memory. It is not faster.
You are referring to one of the six addressing modes that "cheats" a little by assuming the top address byte is 0. As a result, it will take one clock less to access as you say. However, this address mode is not available for every instruction which means that the benefit can be of limited use. Logical shifts, multiply, branches, dec, inc and a whole other list of instructions can't use this direct mode and will execute in the same time as external memory. See pages 30 onward in the data sheet. The idea behind it was to speed up access to the control registers initially which are also memory mapped into this area.
As a result, the benefit is often negated because the faster direct mode can't be used. IIRC This is why Lucas put some of the variables into the external memory because the instructions did not support the faster Direct mode and so offered no performance advantage. In addition, having the variables in external memory meant that they could use logic analysers to see data changes which could not be used with variables stored internally.
The point of this is that it does not automatically follow that moving variables into the internal memory will always makes things faster in this case. It will only happen if the instructions that manipulate the data can use this direct mode. If not, there is no advantage.
danbourassa said:
The first list that you show has no road speed service so your log file would show the road speed becoming static whenever RPM is greater than 4185. As Steve pointed out to me, there's still a possibility, on some vehicles, that you can hit the road speed limit before reaching 4185 RPM. If that's the case, using this technique to defeat the limit won't work.
Following from Dave and Dan's posts regarding the road speed limiter the penny has finally dropped.TVR DID REMOVE THE ROAD SPEED LIMITER FROM ALL PRECAT ECU ABOVE 4185 RPM's by removing it from the data and not the code. This approach isn't ideal as its only effective above 4185 RPM and explains why I use to hit the limiter below 4185rpm with the incorrect speed sensor crown wheel. In addition I previously didn't believe TVR removed the limiter as the TVR R2422 code is identical to Land Rover R2422 code.
The limiter is the 87's in the data rows below, you can also see on the later cars TVR reverted back to the Land Rover data with the limiter and removed the limiter in the code which works at all RPM.
TVR 1992 R2422 : No limiter 8B 86 02 03 84 02 8D 88 02 8B 80 85 81 FA
LR 1991 R2422 : Limited 87 02 87 86 87 02 87 87 87 87 87 87 87 F7
LR 1994 R3383 : Limited 87 02 87 86 87 02 87 87 87 87 87 87 87 F7
TVR 400/450/500 R2967: limited 87 02 87 86 87 02 87 87 87 87 87 87 87 F7
I'm sorry if I previously mislead anyone.
shpub said:
Maybe I didn't explain fully...
I have the data sheet and user manual as I used to work for Motorola. In fact I managed the Lucas support team and I seem to remember many discussions over where to put variables and the amount of internal RAM. Their requirements were always increasing/changing and they were often after every last drop of performance.
And I thought you had reverse engineered the 14CUX to do the ECUmate I have the data sheet and user manual as I used to work for Motorola. In fact I managed the Lucas support team and I seem to remember many discussions over where to put variables and the amount of internal RAM. Their requirements were always increasing/changing and they were often after every last drop of performance.
... anyway were you never interested in offering a chipping service under SH engineering as you understood the bits and bytes?Edited by blitzracing on Monday 26th May 16:25
shpub said:
...In fact I managed the Lucas support team ...
Steve, I think I know why but you've played that one close to your chest, I also know you were a TA at Motorola but support manager for the Lucas 14CUX project, wow!Wandering off topic I know, but I think you've dabbed a dollop of Motorola bias on the situation regarding cache and i86 history. I'm batting for the Intel camp so have a different view on events. On-chip cache and RISC pipelining featured on the 80486 in about 1989; thereafter the i86 family was often cited as market leader in the embedded controller sector in independent marketing literature of the time.
Edited by davep on Monday 26th May 10:53
blitzracing said:
And I thought you had reverse engineered the 14CUX to do the ECUmate ... anyway where you never interested in offering a chipping service under SH engineering as you understood the bits and bytes?
Just because I managed the support team for about 18 months didn't mean that I got to see the design documents, source code or anything like that. I was also pretty well bolted down by non disclosure agreements. Still am actually. The support questions were more about using the processor. Also bear in mind that the ECU has several custom chips in it which we didn't supply and so everything was very much Chinese Walled. ... anyway where you never interested in offering a chipping service under SH engineering as you understood the bits and bytes?I did reverse engineer for the ECUmate but I had an advantage in knowing the chip pretty well which helped guesstimate what they had done. Still had to do a lot of the low-level research using scopes and analysers etc.
I never saw the documentation, source code etc as this was kept extremely under wraps by Lucas. NDAs etc were all over the place. I did know how much work the Lucas guys had to do to test this stuff and how they managed to get the last ounce of performance out of it. What they did in the circumstances of short deadlines and rapidly changing requirements was nothing short of miraculous. I've also seen what happens when they got it wrong...
davep said:
Steve, I think I know why but you've played that one close to your chest, I also know you were a TA at Motorola but support manager for the Lucas 14CUX project, wow!
Wandering off topic I know, but I think you've dabbed a dollop of Motorola bias on the situation regarding cache and i86 history. I'm batting for the Intel camp so have a different view on events. On-chip cache and RISC pipelining featured on the 80486 in about 1989; thereafter the i86 family was often cited as market leader in the embedded controller sector in independent marketing literature of the time.
The Intel vs Motorola stuff was very much Religious wars. Almost all of the cache structures and control techniques were copied from main and mini frames from a couple of decades past and were not original anyway. A lot of the claims at that time were to counter the threat of the RISC machines that were blowing CISC out of the water. If you look in detail at exactly what the hardware was doing and a lot of it was nothing new and simply a bit of marketing. Interesting times though as I left the Apps side to work on processor architectures as it was a more challenging. Wandering off topic I know, but I think you've dabbed a dollop of Motorola bias on the situation regarding cache and i86 history. I'm batting for the Intel camp so have a different view on events. On-chip cache and RISC pipelining featured on the 80486 in about 1989; thereafter the i86 family was often cited as market leader in the embedded controller sector in independent marketing literature of the time.
Edited by davep on Monday 26th May 10:53
Anyway to be honest this is sidetracking this thread.
Dan, quick question; in the RAM variables description within the respective .asm file the following codes are listed:
(F) Fast changing value (fuel map row & col)
(M) Medium changing value (road speed)
(S) Slow changing value (temperatures)
(N) Non-changing value (changes only with map change, fuel map scalar, etc.)
I don't see where these are used in the actual variable definitions, whereas (R), (W), * and x are used. Am I missing something?
(F) Fast changing value (fuel map row & col)
(M) Medium changing value (road speed)
(S) Slow changing value (temperatures)
(N) Non-changing value (changes only with map change, fuel map scalar, etc.)
I don't see where these are used in the actual variable definitions, whereas (R), (W), * and x are used. Am I missing something?
Dave, I'm pleased that you are looking at this code so closely that you would notice this. These are preliminary notes to help me prepare for future code changes. The goal is to have a version of code available that is optimized for the serial port and to use faster internal memory. In version 3 that I'm working on now, I have a directive that moves most of the bit flag variables (bytes that are used as individual bit flags) from external to internal memory and I have measured both a reduction in code size and actual performance gains. You can think of this as the "small model" in old X86 segmented memory programming, where part of the addressing is implied resulting is smaller, faster executables. The reason I chose the bits values to move is that these variables generally are used much more often in the code. The opposite extreme would be a failure delay counter which, ideally, should not get used at all and should be in slower external memory.
Gassing Station | Griffith | Top of Page | What's New | My Stuff