If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Also started making some progress on the extra CAN message today:
New CAN_Send_DME_ARBIDs_karter16() function which replaces the original CAN_Send_DME_ARBIDs() '
And screenshot of the disassembler's C interpretation below to show that I got the machine code right. our new CAN message is decimal 16 in the table.
And here's our new function being called in the 10ms task:
And here's the new entry in the table:
I've decided on ARBID 7D0 as it is higher (lower priority) than any other message in the table, used or not, and is still within the standard 0x000 to 0x7FF CAN ARBID range.
The pointer to 0x0003f900 leads to empty program rom currently. The next step will be to build the new function to send the CAN message.
I'm probably going to do a bad job of explaining this as it has a bunch of components to it, but I've figured out the operating system (by the way the name of the OS is OSKAR) task scheduling system. When I have a high enough level of enthusiasm I'll document this properly in the wiki, but for now here's the quick run-down.
Each processor in the DME receives an external timer interrupt from the programmable interrupt timer 1024 times per second (e.g. approximately every millisecond).
The interrupt is handled here:
So this function fires every 1ms, and in it it does some important high frequency things like update the system timertics variables, sync the values in the dual-ported RAM to local copies of the variables, etc.
Every 2ms it calls sys_process_scheduled_tasks() which checks all scheduled tasks, updates the delay timers on each task and reschedules periodic tasks.
Every time the function runs, and provided there are no other active interrupts, the tasks are actually dispatched via sys_dispatch_tasks which in turn calls sys_task_dispatcher.
Both of these functions are below:
There is also a function to schedule a task in the first place:
And to cancel tasks:
The details of the tasks are stored in a pointer array in the program ROM (0x0003d810 in Master) which in turn points to a table of structs
The array of structs starts at 0x0003d798 (in Master program ROM)
And this is what I've figured out of the structure so far:
It's important to note that sys_process_scheduled_tasks runs every 2ms (every other time the timer interrupt fires) so the period and the initial delay of each task is specified in units of 2ms. e.g. task_10ms has period_2s set to 0x0005:
The task manager can manage up to 32 different tasks and can schedule up to 8 of them at once for execution.
Essentially what it does is monitor for the condition where the car is in 4th gear and has been cruising between 44 and 54 km/h for more than 3 seconds. At that point it enters "noise" mode where the max requestable torque is limited. As soon a different gear is selected or the car drops below 44 km/h or goes about 70 km/h noise mode ends.
It's worth noting that in the 1801 binary the parameters are different (3rd gear instead of 4th, and speed thresholds differ) so this has been tuned specifically for the CSL binary.
So it's super restricted. I have no idea what scenario it's trying to mitigate. If someone wants to give it a go and report back on whether they can detect any difference that would be super cool.
So would that then mean that the reason why that one region of the table is slightly higher in the CSL tune is that the difference in cams allows for a slightly longer intake period which allows for slightly more mixing time?
Either cams or something to do with less restriction in the CSL airbox vs MAF, or both.
karter16
What are ARBID's?
i guess they are ARB ID's but what are they for?
Arbitration ID - used as part of the CAN communication format to deal with situations where multiple messages are flying around the bus at the same time. The message with the lowest ARBID value wins. Part of the plan for introducing another CAN message is to give it a suitably high ARBID so that everything else wins. That way the more critical CAN functions continue on unimpeded and the new message can be transmitted when the bus is free.
Just a few percent higher seems to cause instability. I believe you want the air velocity high enough for effective fuel mixing, so if you open the throttles too much you pass a sad point of no return. They really seem to have pushed it pretty close to the max as far as I could tell when playing with that variable.
So would that then mean that the reason why that one region of the table is slightly higher in the CSL tune is that the difference in cams allows for a slightly longer intake period which allows for slightly more mixing time?
Just a few percent higher seems to cause instability. I believe you want the air velocity high enough for effective fuel mixing, so if you open the throttles too much you pass a sad point of no return. They really seem to have pushed it pretty close to the max as far as I could tell when playing with that variable.
Ah, fair enough. I'll settle for proper part throttle performance every time.
Just a few percent higher seems to cause instability. I believe you want the air velocity high enough for effective fuel mixing, so if you open the throttles too much you pass a sad point of no return. They really seem to have pushed it pretty close to the max as far as I could tell when playing with that variable.
Leave a comment: