DIYEFI.org Forum

So it seems like at least 15 people (including a few on facebook) want to hear my funny accent talk about engine control topics, with a focus on FreeEMS and DIY engine control. This is good. But what do all of you want to hear me rant/rave about and digress away from, etc? Please use this thread to share your ideas for what I might (or might not!) speak about in such a media format! Go! :-)

Fred.

A high level look at how the firmware operates

I recommend breaking the segments into a consistent, formulaic, layout rather than make it one long diatribe. For instance:

1. Pre-recorded intro thanking the listener for joining in with a quick explanation of what they're tuning into along with a mention of the web address(es).
2. Intro to the show's topics.
3. News segment: How the FreeEMS project's going (firmware diary style), anything exciting happening in the DIYEFI community, new products in the engine management scene.
4. This episode's topic 1 (software related, possibly featuring a Q&A of a FreeEMS supporting application developer).
5. Advertisement for underwriters (BrickEMS, CoolEFI, Toxic Industries, Hentai's bodypillows, ...)
6. Product review rant--though not necessarily a specific brand.
7. This episode's topic 2 (hardware related, possibly featuring a Q&A of a FreeEMS or DIYEFI hardware developer).
8. Listener/forum question mailbag
9. Thank earlier guests/companies by name along with those listening. Reminder of how to download shows as podcasts or streams.
10. Pre-recorded closing public service announcement with repeat of web address(es), invitation to join the forum, and encouragement to click on the "donate" link or buy merch (shirts/stickers) to support development.

Suggestions: generic topics that are useful to design (revisioning systems, IDEs, code review, teamwork developed applications/projects, hardware design techniques and applications, prototyping equipment), interviews with people/vendors in the field, "fieldtrip" tours of related places (dyno testing, installation, etc.) in the spirit of "from planning a custom ECU swap through every step of the process."

Or just wing each episode as one long (30-60 minute) narrative and keep it sweet, simple, and fun.

-Jeff

+1 on ToxicGumbo

I think one of the most interesting things that I got from talking with Sean about the reason for needing XGate was some reasons for choosing the Freescale MC9S12XDP512, simple interrupt handling (I think that was it?). He was describing how the processor spends half its time dumping values from registers so as to not have the values overwritten, and how the ADC can only processes a single signal at a time, and is used sequentially--making the "refresh rate" of the signals dramatically slower the more signals being processed. He discussed how you've mitigated that by prioritizing important signals to be checked at a greater frequency. I guess what I'm trying to say is I'd be more interested in hearing about the challenges, and the development that is going against them in future releases--the big picture stuff.

Also, it would be awesome to interview Andy on the Jag, Sean on the XGate, Malcom on EMSStudio, Ben, and many more people that I haven't been around long enough to get to know.

Additionally, I bet you could fill 30 minutes ranting about what is wrong with MegaSquirt, and how you've from the ground up resolved those issues. Explain the focus on simple configurations and stability.

There will be no MS bashing in these, that's for sure, not even a mention. I will probably highlight some strengths and explain why they matter, though.

I'm unsure how you classify interrupt latency as "big picture" :-) The ADC is plenty fast enough, I assure you. Also, there are two of them.

Interviews require co-location to be effective and fun, so that's mostly off the cards. Plus:

1) Andy and Mike are a bit camera shy, though with time and practice they're becoming less shy :-)

2) Ben's done nothing except ask favours in the lounge and cause trouble for 8+ months.

3) Sean's XGATE stuff stays tucked under the bed until such time as his loader is rock solid and 0.2.0 and 0.3.0 of the firmware are completed and released. Until then, it's merely a distraction from a LOT of stuff that REALLY needs a LOT of attention NOW. Lack of it only prevents 12 cylinder engines and engine-owners with no real desire to help, from running/running something. Remember, testers, not users.

Also, while I'm being negative and boring: Jeff, no way is it ever going to be an hour a week any time soon! :-o Expect 30 mins a month for the time being, more or less. If/when I get around to it.

Fred.

Yeah, not what I meant about interrupt latency. I mean
1. Why was the FreeScale processor chosen?
2. What are the major challenges the current version faces, what are the down the road solutions, what are the immediate solutions?
3. Why are FreeEMS users so camera shy?

I just don't grok why everyone cares SO much about the processor. Fuck anyone who does, basically. Maybe in future it'll be a different CPU, who knows? This meets all of our needs for a long time to come. Nothing much else does, and there are reasons for that. :-)

2) OK!

3) LOL, no idea. This project attracts the socially weak by its nature, and I drive them away with mine. Not saying Andy/Mike are socially weak, they may or may not be, but it's certainly true in general.

Fred.

Fred wrote:I just don't grok why everyone cares SO much about the processor. Fuck anyone who does, basically. Maybe in future it'll be a different CPU, who knows? This meets all of our needs for a long time to come. Nothing much else does, and there are reasons for that.

It's "Arduino syndrome". (Not that people want to use Arduino, though some do). You have a system that looks, on the surface, to be fairly simple. You look at the hardware choses and say "Man, why did they use hardware A? I'm really familiar with hardware B and C, and both of them seem like they would do a really good job with that".

Forgetting that the developer is both familiar with A, and has worked with it for a while, and likely has done all the prerequisite research to justify the use of A in the project vs B or C (C wasn't even around at the time the project was conceived). So in their mind, you simply didn't look hard enough, because to them, B and C seem like better fits for what their "idea" of what the system is.

You see a lot of this with the "I could do this, but cheaper and better with an Arduino!"


</offtopic>

Not off topic, excellent insight. It drives me fucking crazy though, as a number of threads on this forum attest to.