Your dream ECU
#41
Propellers are neat and all, but they're quite unsuitable for anything serious. I know they now have GCC support and they look great on paper, but you have to bit-bang everything. Weak. You end up defeating the coolness of the hub + processing spokes architecture by burning up entire cores to interface with external ICs. By the time you've covered SPI, CAN, I2C, and USART, you're half occupied. Also, even though the hub memory window shifts predictably, I'd be hesitant to rely on a hard real time system that could potentially miss out on it's memory access.
#42
Theoretically Adaptronic did the right approach, dithering say, +/- 2* of timing, and looking for the resulting change in acceleration that is synchronous with the timing change.
#43
Did somebody say McLaren?
My dream ECU is simple: MS2 featureset, with a proper power supply, on a single board, with real connectors, a better communication protocol and a codebase that isn't a huge, flaming pile of ****. I'm sorry guys, I know it works, but MS has some of the _worst_ code I've ever seen. It's so bad, we show it to developers here as an example of how to get fired.
Seriously.
My dream ECU is simple: MS2 featureset, with a proper power supply, on a single board, with real connectors, a better communication protocol and a codebase that isn't a huge, flaming pile of ****. I'm sorry guys, I know it works, but MS has some of the _worst_ code I've ever seen. It's so bad, we show it to developers here as an example of how to get fired.
Seriously.
I think most code projects started by a community / non-pro have "the_worst_code" issue. I can think of a number of web projects like bulletin boards, ecommerce packages etc that suffer from poor initial structure, poor initial code and then the project just gets worse as other non-pros pour their semi-functional tidbits into the poorly organized package. Whenever you look at it you wish it was just re-started with good practices from scratch, then you figure out how long that would take and just move on.
I also don't like the multi-board setups that add insertion loss, capacitance, vibration issues, etc etc etc. Would be nice to have a very capable single board MS solution with no licensing requirements... oh wait, here is a close version except still some licensing something or other issues and relatively expensive for a low cost board MS3-Pro Module - An EMS on a circuit board, for building your own systems. The majority of the cost built into ECUs is for support as a general rule in industry (that may not be the case for MS builders here).
#45
Boost Czar
iTrader: (62)
Join Date: May 2005
Location: Chantilly, VA
Posts: 79,493
Total Cats: 4,080
Even Ken complains of the code, and he writes the msextra stuff. But that's mostly the B&G code he has to work around.
it runs my car well with more features than I can use, so whatever. and when somethign doesnt work, I just text/IM/email him and bother him enough and he fixes it.
it runs my car well with more features than I can use, so whatever. and when somethign doesnt work, I just text/IM/email him and bother him enough and he fixes it.
#46
Elite Member
Thread Starter
iTrader: (1)
Join Date: Jun 2012
Location: NH
Posts: 9,479
Total Cats: 104
That's not an issue with the ECU, that's an issue with the tuning software. Whether it's VE based or injW based, the tuning software will send the same tables to the ECU. Put another way, one can re-write the tuning software to present VE based tuning to you, then translate it into whatever the ECU needs.
#48
MoTeC > About Power Distribution > Overview
They really haven't made it down to the consumer level yet but likely will. Isis power is trying to push them in the aftermarket at the low end as an example but I have no idea how well that is going for them. There has actually been a lot more advancement in the last 5 years in power distribution than in ECUs imo.
#49
Elite Member
iTrader: (1)
Join Date: Jun 2006
Location: Warrington/Birmingham
Posts: 2,642
Total Cats: 42
Even Ken complains of the code, and he writes the msextra stuff. But that's mostly the B&G code he has to work around.
it runs my car well with more features than I can use, so whatever. and when somethign doesnt work, I just text/IM/email him and bother him enough and he fixes it.
it runs my car well with more features than I can use, so whatever. and when somethign doesnt work, I just text/IM/email him and bother him enough and he fixes it.
#50
Elite Member
iTrader: (10)
Join Date: Jun 2006
Location: Athens, Greece
Posts: 5,977
Total Cats: 356
I agree, however the problem with CAN is that its not suitable for time critical applications. For example, if you want to activate a high-current device at a specific crank angle, you can't. Or to put more scientifically, you can try, but you are not guaranteed to apply it in the correct time frame.
#51
Elite Member
iTrader: (1)
Join Date: Jun 2006
Location: Warrington/Birmingham
Posts: 2,642
Total Cats: 42
Even Ken complains of the code, and he writes the msextra stuff. But that's mostly the B&G code he has to work around.
it runs my car well with more features than I can use, so whatever. and when somethign doesnt work, I just text/IM/email him and bother him enough and he fixes it.
it runs my car well with more features than I can use, so whatever. and when somethign doesnt work, I just text/IM/email him and bother him enough and he fixes it.
#53
Elite Member
Thread Starter
iTrader: (1)
Join Date: Jun 2012
Location: NH
Posts: 9,479
Total Cats: 104
/rant
#56
Most of the McLaren stuff I have seen is built for a specific series so it is neutered by the regs, though I'm sure there are fully capable ones I haven't yet run into. The Bosch stuff is where I see the craziest setups but that is just from my experience. Audi has some insane logging / electronics pacakge for their LeMans prototype cars as an example.
I think most code projects started by a community / non-pro have "the_worst_code" issue. I can think of a number of web projects like bulletin boards, ecommerce packages etc that suffer from poor initial structure, poor initial code and then the project just gets worse as other non-pros pour their semi-functional tidbits into the poorly organized package. Whenever you look at it you wish it was just re-started with good practices from scratch, then you figure out how long that would take and just move on.
1) I shouldn't have to dig through 1300 lines of global variables and memory map structures to get to the definition of main() in a file called ms2_extra_main.c. The code is laid out in such a way that finding anything just defies reason. If you have bulk data that needs to be accounted for, put it in its own file, don't muddy up application code (this is one of the few times I think globally accessible variables/data are ok)
2) WHY THE **** ARE THERE SO MANY GLOBAL VARIABLES. Global variables (in general) are bad practice. Of course, occasionally this is unavoidable, but in almost every case you should have variables with local scope and be stored in the functions that they are going to be used in. If they need to be persistent, make them static. If the _absolutely_ need to be global, at least keep them in their relevant file. Global variables are just asking for concurrency issues to spring up.
3) Your main loop shouldn't be 2000 lines long. Y U NO FUNCTION!?! Functions should be short, sweet, and to the point (also: appropriately named). I should be able to look at any given function and understand (roughly) what is going on. Looking at MS2s main loop feels like reading a short novel. If you are concerned about branch time being an issue, __attribute__((always_inline)) is your friend (though this will, of course, increase size)
4) There is no layering. Good embedded software is layered (in fact, all good software is layered).
My preferred layout for embedded software is thus:
HAL (hardware access layer) -> Hardware Device Drivers -> Software Device Drivers -> Application code (which can also talk directly to device drivers depending on what we're talking about).
You layer software in order to modularize functionality and to allow ease of debugging and flexibility for future growth.
The MS code violates this pretty much everywhere.
5) They overuse GOTO statements. There are a few cases where they are useful (see linux kernel for examples), but for the most part (especially the way MS uses them) they are unnecessary IMO. Why not just have a conditional jump to a function?
6) They use assembly in completely unnecessary places. I get why you might use it in a timing critical interrupt, but there is some stuff that just doesn't require it.
There are a few others, but these are the bigguns as far as I am concerned. I'd also do some sort of encoding of the serial communications, but that's just me.
Edit: I'd like to point out, that I _DO_ appreciate the hard work that the developers have put in, and it DOES work. I don't mean this to be accusatory or anything.
Last edited by Jeff_Ciesielski; 03-14-2013 at 03:01 PM.
#57
Elite Member
iTrader: (9)
Join Date: Jun 2006
Location: Chesterfield, NJ
Posts: 6,893
Total Cats: 399
I know theoretically how to tune a PID (or PI in the case of the AEM?) control, but if a good wizard can do it faster and more accurately, then that would be awesome. With as often as I change setups (or in the case of a 'tuner', with as often as they tune different cars) and therefore have to redo the feedback maps, I would love a wizard.
#60
Autotune.. everything and automatically input everything. AFR, idle at all engine temps, smart air temp afr (changes teh afr multiplier at different air temps automatically), spark if possible. Basically load up the basic map and drive and have it automatically adjust everything on the fly.