Automotive MCUs

I'm currently looking to specify two MCUs for an automotive application. The first will be driving an small OLED and the second will be driving solenoids (and some other duties). Both connected via CAN. Normally I would use an ARM based MCU (familiarity and tools) but apart from a single TI CM3, 99% are not automotive qualified / have the temperature range.

After lots of searching Freescale seems to be the dominant provider and an S9S12G128 / MPC5602P combination seems to fit the requirements. The tool cost for Freescale seem to be pretty high, although ?special ' versions of CodeWarrier seem to be listed as "Free" not sure what that means? Free with dev kits? That may mean that I use two of the same despite extra costs incurred.

Microchip also provide dsPIC33 which seem competitive but they don't seem to have some of the robustness features; ECC memory for one. Also I've read that the FLASH write cycles can be very low although I didn't notice it on a previous project.

The product won't be large volumes (x100 at most) Does anyone have any experience with Freescale products when compared to Microchip for automotive applications? Freescale MCUs, apart from some of the S12's don't seem to be available from suppliers (digikey, mouser?etc). Also the performance of the S12 may be a small concern, especially when compared to the dsPICs.

Any general advice would be appreciated.

--------------------------------------- Posted through

formatting link

Reply to
treborlecs
Loading thread data ...

This is in passenger compartment, right? Why would you put an OLED display under the hood? If so, you don't need high temp. grade for this.

This can be lower performance.

You only need ECC for dynamic ram. How much memory do you need under the hood?

Not a problem unless you are changing the FLASH in run time.

Reply to
edward.ming.lee

If this is intended for OEM product, then you don't have much freedom in choosing MCUs or tools. First, look what is approved or would be acceptable with your customer.

Vladimir Vassilevsky DSP and Mixed Signal Designs

formatting link

Reply to
Vladimir Vassilevsky

Have a look at the Fujitsu MB96Fxxx family. These are automotive style MPUs and come with a free compiler. I have been using these and their predecessor (MB90Fxxx) for more than 10 years now.

formatting link

--
Reinhardt Behm 
rb@rbehm.de
Reply to
Reinhardt Behm

Details of CodeWarrior versions are pretty clear on the Freescale website:

Look for the "CodeWarrior Development Suite comparison" link.

Basically, the free version has restrictions on the size of the code you can work with - but I've found the limits more than high enough for real-world projects.

CodeWarrior is quite good, now that they have dropped their own IDE and moved over to Eclipse. In an incredibly thoughtless decision, they decided to drop the Linux versions after 10.3, which has annoyed a lot of people. (Don't these guys know that a lot of modern embedded and automotive development is done on Linux and for Linux?). It is also extraordinarily daft policy that C++ is only available on the "professional" version (at $5000 for a full license).

The library is a bit weird, and the wizard-generated startup and interrupt code is sometimes truly awful, but that's not uncommon in toolchains. The compiler does a solid job.

We've never had trouble getting Freescale parts, though we usually use a real distributor.

Reply to
David Brown

A single device can't serve both purposes (perhaps because of location requirements of each)?

Presumably, you are hard pressed on temperature at the *high* end and not the low? What risk do you run if the devices are "borderline" in terms of *specified* performance?

Usually, the kits are limited in terms of the complexity of the "programs" you can write. Either in terms of size of binary created, number of source files, etc. If you are trying to do this on a hobbyist's budget, there are often ways to coax a "limited" tool to meet your needs -- though often at some bit of inconvenience on your part (e.g., cut the application in half and link the two halves through a jump table, etc.)

Are you *sure* you need ECC memory? What are you protecting against? General memory failures? Or, *specific* "precious" data? In the latter case, you can implement your own ECC algorithms and access those parameters through a mechanism that you create.

You are probably not going to be able to use FLASH like RAM. Instead, you want to be using it for configuration information and things that don't change often. E.g., storing the frequencies of radio station presets (which don't change often -- and probably can't PHYSICALLY be changed often!)

If you need to store something in FLASH that changes often, you might have to keep a "live copy" that you update as often as you want and arrange for that to get stashed in FLASH "just before powering off" or even "periodically" -- as long as that ends up less than your high frequency update rate.

Only you can decide if a particular device will meet your requirements (capabilities, etc.). Ask yourself what it is about the dsPICs that sets them apart/above the other choices. Then, see if there is a way to *not* need that capability -- thereby reducing the dsPICs advantage and making other options more usable.

If you are looking for small volumes, a big part of your design decision will be *getting* the parts. The "perfect" part is useless if it's not obtainable (for you).

Reply to
Don Y

SiLabs have CAN Automotive spec devices.

These should do the Solenoid instance, and depending on how small the 'small OLED' is, may even have a part for that too. Come up to 128KF and 8KR

formatting link

Infineon XMC1xx series can spec to 105'C, but is not full automotive.

Reply to
j.m.granville

Freescale have automotive qualified ARM parts with CAN which may be worth looking at.

Normally the 'special' codewarrior is subject to a maximum code size,

32kB or 64kB depending on the part IIRC.

You can also use GCC if you like.

We use a range of freescale parts, and they are all available from Digikey. Although for some parts, you may have an MOQ if you want a particular package and temperature rating.

Regarding performance, Some of the S12 variants have an XGATE co-processor (E.g mc9s12xep100).

Andy

Reply to
Andy Sinclair

I believe that you can use the supplied gcc to compile code bigger than than the code size limit, but you can't debug it with the "special" edition of CodeWarrior. The same applies to using C++ - gcc supports it, but not the "special edition" debugger.

Reply to
David Brown

According to the spec, dsPIC33 can run up to 120C at full speed and 150C at half speed. We pick them for wide temp range of -40 to 150C for an outdoor product, but perhaps not as hot as under the hood.

DsPIC33 has 24 bits accumulator and single cycle multipler. It should be handy for apps such as audio/voice codec, with the build-in D2A.

Reply to
edward.ming.lee

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.