Letting go of the "MegaSquirt mindset" (firmware)

Official FreeEMS vanilla firmware development, the heart and soul of the system!
Post Reply
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Letting go of the "MegaSquirt mindset" (firmware)

Post by Fred »

There have been quite a few instances of people thinking in the "ms way". While this isn't a bad way to think, I think it limits us a bit. I've been proven to do this myself, and consequently I've been making a conscious effort to think outside the box and really consider what is missing and what is there.

Firstly, ms1 and ms2 do a great job in almost any circumstances. Where they are lacking is in IO. COP + Sequential + lots of accessories and data logging.

Another area that I don't like is the complexity of configuration. This exists because of the attitude present that says "we must support all cars ever made", and "we must do it in a single bin file".

I think it is important to let go of "how it is done" and try to see "how it could be done". Already we have made some good progress towards a better code structure for high performance operation. This came about by ignoring "how it is done".

So then, what we want to do is fill hole in market that exists in performance/functionality/price relationship, and provide a platform that allows people to help themselves (Thanks Russianblue).

The best ways to achieve this as quickly as possible are to A work on things that all users require first and foremost, and B to keep decoder styles separate from the rest of the implementation as much as possible C not put excess effort into creating something that MS already does very well.

I think it's important to stay focussed on doing the basics really well first.

http://www.diyefi.org/forum/viewtopic.php?f=8&t=27

Thanks,

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Russianblue
TO220 - Visibile
Posts: 4
Joined: Thu Apr 03, 2008 4:53 am

Re: Letting go of the "MegaSquirt mindset" (firmware)

Post by Russianblue »

Wow. I'm flattered! I'd never touched a MS until about 2 months ago! First off, you'll have to continue to forgive my ignorance, as I speak from the perspecitve of a corporate finance professional and self-taught IT/Domain/Exchange admin...but the code side of things remains foreign to me. That said, I know a damn good bit about computers, build my own PC's (water cooled and overclocked of course), and have a weekend network support business that generates 5 figures a year in revenue. Anyway, one thing i was thinking with regard to the "all things to all people" issue....

....I seem to recall having visited a website at some point in order to download a certain software package and where the download process was very different than your typical Spybot download or similar. I went through an extensive list of options regarding my own setup and preferences, and was asked to hit a 'SUBMIT' button or something. At that point, a message appeared asking me to wait for 'up to 5 minutes' for my download to be prepared. After 30 seconds or so, i downloaded the install normally. Now, when i installed the program, it was tailored according to the same options I'd designated in the questionnaire, no more, no less.

If i am not mistaken, what occured there on the back end was the compilation of a fully customized exe containing exactly what I needed, preconfigured for my use. I could be completely wrong or off-base with this, but I was thinking that a similar delivery portal for this new software could be employed in the same completely modular way.

for example, the list of options to fill out could be something like
1. What kind of car?
2. stock or modded?
3. Ignition type? Check one: EDIS, basic trigger, toothed wheel, etc
4. Wideband Type? Check one: AEM, LC-1, etc.
5. What size injectors? enter size in lbs: ___
6. How many?
7. Low or High Z?

You'd choose all of your options and then wait for your custom compiled firmware to be delivered with the main portions pre-configured.

I think the beauty of something like this would be that individual modules could be submitted for approval by just about anyone and 'added to the list of options'. As new code came in the door, it would be noted with its source, and its stage of development. So if i wanted to run the Release software for everything but say, my idle control valve, for which i wanted to try out a new experimental option/module, I could just run the compiler and download away. It would certianly address a number of the "confusing interface" options talked about here by minimizing the myriad choices within the configuration software itself. Less room for error, a la carte selection, simple if so desired, and full blown experimental...all available in the same place, via the same procedure.

Well, you've said it yourself....we are in the brainstorming phase. This may well be a pipe dream so don't waste your time answering if that's the case, but this WOULD be pretty cool!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Letting go of the "MegaSquirt mindset" (firmware)

Post by Fred »

No worries mate. You illustrated something I had been sort of aiming at the whole time. Accessibility of the code to everyone. If I do a good job, that should be a real possibility, just add in your chunk, recompile and try it.

As for the web-compile thing, that is a pretty cool idea, but I can see that it would take a LOT of work. Additionally, one of the reasons that I want to separate them out is to place personal responsibility for a particular code type on the developer that supports it. I feel that it is not prefessional to release a variant of the code having only personally tested say Denso mode. If I release Denso based code as a sort of master release and then BOB merges in his neon decoder and tests it on his car and then releases that you may have more confidence that It has been better tested prior you using it.

Hence I think such a web-compile setup could only work well with a finished and comprehensively tested code base.

Also, probably the only things that will differ between variants are :

Wheel decoders
Ignition and injection algorithms (which DEFINITELY need special testing) for the likes of rotaries and siamese engines.

Thank you very much for sharing your idea!

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: Letting go of the "MegaSquirt mindset" (firmware)

Post by AbeFM »

Fred,
I don't think he was really saying the website would have to do it (though it could), but any way the code could be modular. You could have a routine (java or something machine independent please!) that gathers together modules. I could see separately compiled bits so you don't even have to replace all your code at once.

The issue with all this is it makes things stuck, get abandoned, etc. While it's good to allow other code to override the basic, there needs to be a basic code that's all tested and works together. And if someone writes a module, it really should work with the standard code.

Let's pretend somehow miata specific code is generated. Then the next version of the firmware comes out, and the denso wheels work with it, but now the miatas don't. It's way too easy for so much stuff to get left behind per release that there will inevitably be code variants going in a million directions. Ultimately this won't work as well.

A central authority/master copy can be limiting, and a really good interface spec that's maintained will get around almost all these issues, but having a million little separate hacks means it'll never really work for anyone.
Russianblue wrote: I think the beauty of something like this would be that individual modules could be submitted for approval by just about anyone and 'added to the list of options'. As new code came in the door, it would be noted with its source, and its stage of development. So if i wanted to run the Release software for everything but say, my idle control valve, for which i wanted to try out a new experimental option/module, I could just run the compiler and download away. It would certianly address a number of the "confusing interface" options talked about here by minimizing the myriad choices within the configuration software itself. Less room for error, a la carte selection, simple if so desired, and full blown experimental...all available in the same place, via the same procedure.
I like the idea of making modules you can put in. I'm having hell with the PID controllers in MS-II, for instance. I would like to see the base code there (unless we're just plain out of space) and override code available. Sure, it could be chosen at compile time, but then something more straightforward for compiling builds would be an awesome tool. It's a bit down the road, sure, but being able to check a few boxes or name a few paths to files would make sharing and tweaking much easier, and lead to widely distributed stable versions much faster.


Oh, and for the love of god make everything be import/exportable. Nothing's worse than trying to remember the AFR or THEM tables you had.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Letting go of the "MegaSquirt mindset" (firmware)

Post by Fred »

I'm just not sure that it's achievable in this environment with so little overhead. i.e. you have a main loop with some structure that has X routines in one part and Y in another and you need to call them and you need to test to ensure that the cpu load is balanced between different time slices, and then you have std variables and bob has the bare min, and your module requires one more than bobs, but bob thinks ... etc etc.

As for import/export, of course, if it's adjustable, you should be able to save it. Period. Not just some stuff.

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: Letting go of the "MegaSquirt mindset" (firmware)

Post by AbeFM »

With everything important being interrupt based anyway, it shouldn't really matter if one routine takes longer than another....?
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Letting go of the "MegaSquirt mindset" (firmware)

Post by Fred »

You've forgotten our minimise latency schema where by certain things are done every other loop, and the balance on the opposite ones. This is to make sure the fuel calcs are done as often as possible. We want a super fast main loop at the expense of other things for that reason, load balancing between different portions of that loop will be quite important to make that happen. making that happen is important for throttle response at higher revs IMO.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: Letting go of the "MegaSquirt mindset" (firmware)

Post by AbeFM »

That makes a OS leap to mind. Running the loop a few times to get an idea for how long it takes, and record in the header how long it takes. Then you might as well put in how often it needs to run (0.2 hz, 20 hz, 1khz) and your scheduler can do it all.

Good thing there won't be any overhead in all that.
Faststang
TO220 - Visibile
Posts: 4
Joined: Thu Dec 22, 2011 6:52 pm

Re: Letting go of the "MegaSquirt mindset" (firmware)

Post by Faststang »

First thing Fred, excellent work! It's nice to see this, I use to play with MS but it's nice to see a truly open source project. I am really interested in learning how the code works and to be able to implement my own work but I am somewhat of a newb in terms of assembly at the moment. However I am an EE, with background in Mechanical Eng that has done quite extensively Controls engineering where PLC and robotic programming have become second nature to me.

That being said, I have a suggestion.
It would be nice to compile a list of routines and have them just start working, I have done this in the past in regards to PLC code which worked great. So good, I had new employees programming with 1 day of training and finished the job 1 year ahead of schedule and latency was almost non existent. The key was to have routines enable / disable themselves when they were not required (jump back to something more important). This was done by comparing previous set value with existing, if existing doesn't change X amount, skip to next routine. For example, if throttle position or MAP voltage etc didn't change X amount jump to something more important like fueling or whatever we deem is more important.

The header file was typically just that, it directed traffic only to subroutines, the more important ones ran first before heading into the next routine, doing above compare, and jumping or scanning again next routine as outlined in the header. The "X" amount could always be adjusted depending on the "importance" of the routine 1 being high priority and 9 being the least. I typically made those values part of the comparison code. Very high importance routines would eliminate the comparison all together with a 0.

Also, all subroutines had an enable or disable flag. These flags were enabled simply by turning on the appropriate input. That input would tell the program robot 1 exists and would turn on the appropriate routine. For example, if we had a MAP sensor the fact an input was there, present on dedicated I/O, could enable the routine for MAP sensors, but would also need to be added to the code. Of course you always ran into "false triggers" which is why I also used a "learn" input that was either enabled or disabled. This "learn" button also polled for other devices of specific I/O. Robots, presses, stampers, welders, etc. You could do the same on dedicated ignition and injector channels, read impedance to enable a channel, etc. You could even monitor for trigger wheels and have the program count for the missing tooth.

Your choice of processors makes this ideal since you have a high amount of I/O present. There is no way you are going to approach 80 I/O for an internal combustion engine meaning this could actually be a viable solution. In any case, it's just food for thought. Might all be moot, but thought I might put it out there to think about.
Post Reply