JasonC SBB

Interesting input, thanks. I suppose the architecture could be improved while still maintaining its neat ideas.

JasonC SBB

The ECU would already have acceleration info in the RPM trace. And such data would probably have too much noise from outside sources (bumps, etc).

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.

vtjballeng

iTrader: (1)

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.

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).

JasonC SBB

Is it the overall architecture, or the coding of functions?

Braineack

iTrader: (62)

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.

Leafy

iTrader: (1)

How? My understanding of how a computer calculates required injector pulse width involves actually doing out the ideal gas law equation. I know with injector pulse width I can just setup my comp tables correctly and not have to worry about it and have an excel file do the translating between ipw and ve so I can more easily adjust the tune. But I lost my ipw to ve converter spreadsheet so I'll have to make it again.

Reverant

iTrader: (10)

Interesting that the Bosch ECU doesn't handle low-side outputs capable of more than 4 amps; say a PWMed water injection pump.

vtjballeng

iTrader: (1)

The modern method with higher level ECUs these days is to have a dedicated PDM communicating over CAN with detailed current programmability, retry timing, retry failure scenarios etc. A good PDM is, at this point, as advanced or more advanced than some basic ECUs.

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.

richyvrlimited

iTrader: (1)

Tell him to fix my bug then

Reverant

iTrader: (10)

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.

richyvrlimited

iTrader: (1)

Tell him to fix my bug then

JasonC SBB

Nobody here agrees that the most important feature for most enthusiasts are wizards for auto tuning the time consuming stuff like boost control and idle?

Leafy

iTrader: (1)

I would rather have many other more important things first. And I'd rather them not be present at all. The more wizards there are the more accessible tuning is to butting pushers rather than people who actually know what they're doing. It'll limit the amount of people that can tune the system, but it'll also limit the amount of complete **** tunes that a lot tuning shops sell for silly prices to people with more money than sense. And limit the amount of terrible tunes by billy the dsm'er who downloaded this tune from the internet and pushed some buttons and made his afr 8:1 because someone else on the internet said so. Tuning is an art and a science, something that you should easily be able to teach yourself how to do properly and become legitimately good at with practice. It shouldnt just involve pushing buttons that you don't quite understand what they do (unless you're learning and pushing random buttons just to see what they do) in order to "toon" the car.
/rant

Zaphod

Just what I thought - there is simply no reply...

hrk

iTrader: (6)

OBD II port and support for emissions testing.

Jeff_Ciesielski

iTrader: (10)

I think that if they just added a shared peripheral block with basic serial busses, propeller would take off like a rocket.

I've not actually seen McLaren's ECU code (all of my code exists in non-critical sections of the car), but from what I have seen of theirs, it's quite robust, and their electronics are superb.

I can't comment on that as all of the community projects I'm involved in are related to embedded systems. What I will say is that in my experience, if the maintainers are diligent, community driven projects actually tend to produce MUCH better code than commercial solutions. People tend to get in a tight feedback loop in their company, with no external criticism, and commit bullshit. Having 150 people tell you that your code looks like **** on the internet makes you shape up quick if you want it to be included

There are a lot of problems with the MS codebase.

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.

TurboTim

iTrader: (9)

I'll agree 200%. I'm not worried about DSMers or a pile of **** tunes that may come of it...if my life is easier then I like it. I drive around in open loop fueling because settng up the AEM O2 feedback is a PITA. It was easier to drive around with my laptop for a week or so and make sure the zones are right, but if there was a wizard that set up the control variables for me, awesome.

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.

Zaphod

I definitly do, i always wondered how hard it would be for starters to do something like this in a log analyzer like Megalogviewer. I have no clue about software programming, but this surely is no rocket sience...?!

richyvrlimited

iTrader: (1)

I agree totally with you, that's one of the major plusses of MegaSquirt. Phil is working on other wizards, WUE AE etc

triple88a

iTrader: (2)

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.