I used to write FreeBSD kernel code, and now I do a little of everything, including linux driver work at my day job.Xtatic wrote: tell me about it. I write/maintain linux drivers for living
inline also doesn't seem to work with this port of gcc. I inlined a few of the functions for controlling the ignition outputs, and the asm looked the same before and after I did it. Even if inline did work though, it does cause us to use more space like you say. Kernel coding is a bit different from this kind of coding though, as even with kernel coding, you don't have to be incredibly careful about the speed unless you're writing an interrupt handler. Most of the time the CPUs you are writing for in the linux kernel are WAY faster than the processor on the ms2.btw, i fully understand the overhead of multiple function calls. Is there a reason why you guys don't use them with "inline" specifier? You get the benefit of modularity in the source, and the speed of completely inline code (no overhead as the compiler just concatenates them together automatically). But i guess you guys also worry about how much space the binary occupies too, so i guess it's GOTO and ASM time. (we all really need some updated hardware)
I don't mind working on the slower hardware. It's fun to actually have to care how fast the code executes. We've been able to be a little less careful about execution speed in the main-loop than we were with ms1, and gain a LOT more accuracy in comparison, so I still think we have some life left in this chip. We do need a faster chip to do some of the more complicated stuff that we're interested in.
The code isn't really all that complicated to tell the truth. I'm going to clean up some of the style for it sometime before 2.0 is released, but code-flow and all that is not that difficult to understand in this code.I'd be glad to help with this kind of diagram/description, but unfortunatelly i don't have the same understanding of the code as you two do, and won't have for a while (if ever).
Alex
I mean it's mainly:
1) start at the top of the main loop, and go to the bottom.
2) look at each ISR and see what each one does.
3) then the hardest part: see how the IC ISR and RTC ISR interact with variables that are set in the main loop.
For number 3, the main things to consider are that the spark scheduler is in the main loop, and the ISR just reads the calculated values from there, and uses them to set the ignition outputs. The fuel calcs are also in the main loop, and used in the IC ISR to set the fuel pulse-width.
There are also some other things, like the boost control and idle speed control algorithms are in the main loop, but the RTC takes the % calculated in the main loop, and turns it the appropriate output on and off to get the desired PWM behavior.
But really, if you just go through the main loop, you'll get a good idea of how it all works, then it's just a matter of figuring out where specific main-loop calculated variables are used in the interrupts. It's pretty obvious which ones are used outside the main loop, as I've tried to surround those in a DISABLE_INTERRUPTS...ENABLE_INTERRUPTS block.
Anyway, hope that helps.
Ken