MCU Choice

[mobyfab]

Hey Fred,

I'm wondering why you picked a 16bit MCU, now that 32bit Mcu are cheaper and much faster.

I'm now comparing a bunch of free and commercial ECUs, most commercials are using 32 for almost a decade. (lots of Renesas, Freescale...)

Honestly, if I were to build my own I'd go with something like a Kinetis or similar cortex M4 with a DSP for knock sensor processing.

[Fred]

I have to say, I hate people bringing up this topic, it's quite irritating, though I know it's going to happen again and again and again.

1) I picked it 5 years ago.
2) It has a clear upgrade path.
3) There is no incentive to take that path right now.
4) A requirement was and is to have a usable dev board around, for running, not dev.
5) It's a dual core mcu with zero latency for interrupts on one core.
6) 32 vs 16 is irrelevant, really. It simplifies mem management, IF the MCU doesn't have an MMU, if it does, it complicates it. It shortens the small amount of 32 bit math calc times.

etc

DIY is a core part of this site (just look at the URL) which rules out SMD stuff for most, and even now, I challenge you to find a high pin count single MCU dev board suitable for dropping into a board and using on a car.

Note, I require that zero-latency dual core functionality. Can you deliver? Not really, no. It's more complex than "this cpu has x mips".

Fred.

[SleepyKeys]

mobyfab,
More importantly than bits, tell me about those MCU's timer sub-systems.

[Fred]

mobyfab,
More importantly than bits, tell me about those MCU's timer sub-systems.

Some of them are quite good, but it's no match for the XGATE. That cheap ST dev board has 16 timers on it, I think. Then again, so does the XEP, so no advantage there, in terms of engine management, which is vastly different from GP applications.

Also, the 32 bit freescale stuff is unacceptable, the etpu stuff is closed design. Anyone using that is crippled without thousands to spend on paying freescale for privileges.

Fred.

[mobyfab]

Well, there's a bunch of reasons for choosing another processor.

I will take a generic Arm CM3 for comparison.

- Cortex M3s were already on the market 5 years ago. It is widely used as of today.
- There's many cheaper 32 bits processor which outperform the S12X on all aspects, including timers (16b/32b), that's the reason of my question.
- Huge choice among the vendors, clear upgrade path as well
- Some vendors are selling dual core MCUs like the LPC4300, but this one is recent.
- More than dual core, you'd need an RTOS such as ChibiOS. (Else, how everyone else is doing?)
- There are a ton of cheap (sub $30) Arm dev board on ebay that could work. Ofc you need to do an extension board, no big deal.
- CM0/3/4 have zero latency interrupts as well.
- DSP and FPU can be had for cheap. (CM4)
- Fully/Officially supported by GCC. Arm even provide their own optimised version of it.
- Code can be easily ported from a vendor to another, and is upward compatible (M0 code runs on M3 and M4)
- Huge code library provided by Arm, the vendors and the community
- No MMU, no troubles
- You are much more likely to get help from other developers that have experience with it.

The S12X is clearly good/fast enough to do the job, but I fear that coding on it must be a pain in the ass: xgate, code is hardly portable because of this and memory management (I hope I'm wrong)
In the end it's not so much about raw performance but ease of development and overall capabilities.

This obviously is ONLY my point of view, you are doing a great job and I owe you big time

[Fred]

5 years ago you couldn't pick up a CM3 on a board with 100 pins of IO in a format ready to plug into a carrier board with io protection/filters/drivers. Nothing came close, really. I did look...

RTOS, absolutely not.

32 bit timers, why? Not really necessary. Wouldn't hurt, though.

Regards cost, it's negligible compared to all of the other components in the device and installation.

Availability is not looking good: http://octopart.com/parts/search?q=LPC4337

There are a ton of cheap (sub $30) Arm dev board on ebay that could work. Ofc you need to do an extension board, no big deal.

The design goal is a single chip solution. Any networking on the card outside of simple peripherals devices on spi/i2c is not acceptable. I've not seen such a beast provided for cheap, or at all.

Good code is portable anyway. No big deal.

As much as I fully support extensive lib use (in a minimal way) in any PC app, I'm not sure external dependencies should be a part of something so critical. I want absolute control of the entire code base. Nothing less will satisfy me.

You might find this disturbing, or even backward, but I am specifically interested in not having people help with the firmware. Only under specific conditions, which are under development right now, will this be happening. When Linux crashes, I curse. When some infinitely merged code attached to your engine takes a dive, you do more than curse. You walk away. Look at all the unhappy customers of MS with blown engines from a few of their bugs.

The S12X is clearly good/fast enough to do the job, but I fear that coding on it must be a pain in the ass

Not really, no. You're wrong about xgate causing non-portable code. In fact, the fact that Sean up and switched from my output stuff to his xg output stuff speaks volumes about how little that impacts portability. The memory management stuff was nailed long ago and is a non-issue, it was only ever an issue in terms of understanding it, anyway.

The trouble is, it's NOT only your point of view. It's every know-it-all and his dog's point of view :-) You raise some solid points, and I'm totally aware of all of them, however none of them matter.

CPU power is not a hold up here. Dave was a hold up here. He's mostly gone, though. Jared was a hold up here. Marcos was a hold up here. All of these people did some great work, and threw spanners in the works in various ways in the process. Hence I only work with committed people now. Whether it's hw, sw, or fw hacks, I don't want fly-by-nighters anymore. They do way more harm than good. Whoa, I got off topic there.

Back to the main points:

1) 5 years ago it was an excellent choice, and the ONLY one that met ALL of my requirements. 5 years on, things have changed.
2) Moving to another platform right now would be a huge backward step, not a small step forward as it appears from a tunnel-vision point of view.

A huge step backward for the FreeEMS project and the general DIYEFI.org movement.

If/when we run into actual limitations we can look at doing a FreeEMS-next-gen on a different platform. Until then, there are engines to run, technology/solutions to develop, market share to steal and community loyalty to build (this is the hardest part of the battle, believe it or not). Anything that gets in the way of that is not welcome.

Excuse me if it sounds defensive, it's not intended, and I don't feel that way. When I see these posts I just sigh and think of this thread: viewtopic.php?f=41&t=1722

Fred.

[SleepyKeys]

In fact, the fact that Sean up and switched from my output stuff to his xg output stuff speaks volumes about how little that impacts portability.

Yeah it's funny, in that it only took a few lines.

[Bangbug]

Excuse me if it sounds defensive, it's not intended, and I don't feel that way. When I see these posts I just sigh and think of this thread: viewtopic.php?f=41&t=1722
Fred.

My god, I read this for some entertainment and some off the charts Fred defensiveness.
I was sorely disappointed.

[mobyfab]

I get the point I guess

I pointed the 32b timers things as a bonus, not a necessity.

After a quick search I just found a cheap (35e) 144pin board, just need to add some circuitry on the carrier board to make it an ecu.

I never said you should move to another platform. I wouldn't.
I totally understand your point of view on not using libraries. If you do not plan to use them, at least they can get you started much faster

I guess this was a good choice a few years back, but since I'm starting "fresh", I don't have the same point of view nor hardware options.

Get well soon.

[Fred]

After a quick search I just found a cheap (35e) 144pin board, just need to add some circuitry on the carrier board to make it an ecu.

That statement is not useful without a matching link ;-)

Further things to ponder:

Availability in high temperature packages.
3.3V vs 5V operation and compatibility with peripherals (this sword can cut both ways, of course)

I never said you should move to another platform. I wouldn't.

Sure, but, if you're not saying that, then what's the point in saying anything? There really isn't one, it's just time wasting. Unfortunately it's hard to see that until you have the benefit of retrospect.

I totally understand your point of view on not using libraries. If you do not plan to use them, at least they can get you started much faster :)

That could be a benefit if there was lib functionality that was useful. The only thing that I can think of off the top of my head that would be useful and in a lib is PID. Even that, though, is so often implemented in less than ideal ways, it seems like writing code against such a lib only to adapt that code to an in-source implementation later is just killing time. FS stuff for SD cards is another, and we will be using "lib" code for that, but in source form, and only after careful review.

I guess this was a good choice a few years back, but since I'm starting "fresh", I don't have the same point of view nor hardware options.

Just to be clear, you posted this thread in the FreeEMS hardware dev section, and I treated it as such. There is no "starting fresh" going on in here. Unless you meant fresh to the project. Likewise, the hardware for FreeEMS is fixed and long since chosen.

If you'd posted it elsewhere, "MCU Choice For New Project" you'd have gotten a vastly different response.

I'm left wondering what your intent was, now. Pray, do tell.

The thing is, you'd be crazy not to use a modern low-cost 32 bit cpu for almost any consumer task. This field of endeavour is a little different, though. You can/could/will/might make any sort of CPU work for this task, but some are going to be better than others, sometimes in subtle ways.

Thanks for the well wishes :-)

Fred.