Author Topic: What uC to use in Automotive application  (Read 22748 times)

0 Members and 1 Guest are viewing this topic.

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27833
  • Country: nl
    • NCT Developments
Re: What uC to use in Automotive application
« Reply #25 on: June 14, 2012, 10:54:04 pm »
Let me give you a rundown, first, this is a working environment so get REALLY high power irons (stay away from metcal and weller)
Pace/Ersa/JBC is good, Hakko also if you aren't doing lead free. You need two nearly identical ones with different tips
At least Ersa and JBC have irons where you can change tips quickly. I prefer Ersa though because the tips take up solder very easely.

You could have your boss bleed for equipment but don't rule out Rigol et al. I consider a 4 channel scope a bare minimum and I'd get one with a big screen with at least 640x480 resolution. Digital channels will be very usefull. When it comes to a multimeter: consider a benchtop multimeter. They never run out of batteries. And don't look at anything with less then 4.5 digits.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: What uC to use in Automotive application
« Reply #26 on: June 28, 2012, 01:28:10 pm »
Ok, so you're working for "AC S.A." am I right? :)

I also work in automotive electronic engineering field, but utility/heavy vehicle safety systems (ABS and stuff) rather than fuel systems for passenger cars.

First of all, don't use dsPIC30F, they suck and are full of bugs. Rather go for dsPIC33 family. Faster and better.

Second: you want your ECU to be as robust as possible and you need to overengineer everything to be safe against stuff like: ESD, power interruption, disconnection of battery, failure of voltage regulator, transient spikes when cold cranking etc. I guess best reference for start would be ISO16750 standards.

EMC: your design has to be EMC compliant. This means that virtually any stuff like switching regulator is pain i the as* to design and layout is extremly constrained.

All of your parts should have automotive qualification, and since LPG ECU is typically mounted in engine compartment it needs to fulfill AEC-Q100/101/200 (depends on component type) with Grade 1 or 0.

If you really want a rock-solid MCU try Infineon. They are quite dedidated to automotive industry and have some very interesting components.
« Last Edit: June 28, 2012, 01:30:07 pm by poorchava »
I love the smell of FR4 in the morning!
 

Offline 0xdeadbeef

  • Super Contributor
  • ***
  • Posts: 1580
  • Country: de
Re: What uC to use in Automotive application
« Reply #27 on: June 28, 2012, 05:02:46 pm »
Typical CPUs in the automotive environment nowadays are FreeScale (from the Oak family in the past to the Esys family nowadays) and Infineon CPUs (TriCore). These CPUs have a lot of peripherals, specifically dedicated IO like MIOS on the Esys and GPTA on the TriCore plus peripheral coprocessors (eTPU for Esys and PCP for TriCore) . Some specific optimizations in the peripherals allow extrapolation of angular signals from crankshaft without much software intervention or main CPU load.
Trying is the first step towards failure - Homer J. Simpson
 

Offline Hypernova

  • Supporter
  • ****
  • Posts: 655
  • Country: tw
Re: What uC to use in Automotive application
« Reply #28 on: June 29, 2012, 03:30:52 am »
First of all, don't use dsPIC30F, they suck and are full of bugs. Rather go for dsPIC33 family. Faster and better.

-1 for the 30F from me too, used them at work (2010 and 4011) and they are a total horror show. Check out the errata for them and you can see that the interrupt controller in the core is seriously fucked up. They also drink power like a fish with 150mA at idle.
 

Offline digsys

  • Supporter
  • ****
  • Posts: 2209
  • Country: au
    • DIGSYS
Re: What uC to use in Automotive application
« Reply #29 on: June 29, 2012, 04:03:53 am »
If you are used to the 8052, this is what I use. An awesome 8bit, lots of MIPS and incredible analogue subsystems.
www.silabs.com/products/mcu/automotive/Pages/default.aspx
This series is specifically for vehicles. The rest of their range of parts is awesome as well, expecially isolators.
As for irons, I beg to differ with FE. We got boxes of dead Wellers. Once they started farming out manufacture,
they turned to poopoo. I have several JBCs now, and love them. Especially the High Power version. HD
Incredible range of tips as well, and it seems like they last for ever.
Hello <tap> <tap> .. is this thing on?
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: What uC to use in Automotive application
« Reply #30 on: June 29, 2012, 07:39:34 am »
I used dsPIC30F5013 for one project and like 50% of software work was trying to figure out why something doesn't work, despite the fact that it should according to datasheet and to finally find solution in silicon errata.

Rant #1: idiotic PLL design. You need 7.5Mhz crystal to get full specified speed. Wait... 7.5M? Right, you can't get one, they simply do not exist on the market at any reasonable price. Of course you could attach 15M crystal, but silicon bug makes PLL malfunction above 10MHz.

Rant #2: read-modify-write problems @ 30 MIPS... Fail. And don't tell me that it can't be better because PIC32MX can toggle pin at >60MHz reliably.

I didn't finish that project, turned to dsPIC33 - they are far better engineered the way i see it. They have some peculiarities, but I like using them and they are well equipped for most tasks.

Anyway: anything automotive electronics -> go for Infineon first. No, they don't pay me to say that :) - I just have good experience with them in terms of cooperation.
I love the smell of FR4 in the morning!
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 10210
  • Country: nz
Re: What uC to use in Automotive application
« Reply #31 on: June 29, 2012, 08:27:10 am »
I used dsPIC30F5013 for one project and like 50% of software work was trying to figure out why something doesn't work, despite the fact that it should according to datasheet and to finally find solution in silicon errata.

Yeah, that's one thing i've noticed too. PICs do seem to have an unusually large number of silicon bugs.
Why they don't fix them i'm not sure.

I could understand if its some obscure bug that only occurs in 0.1% of applications but some of the bugs are quite annoying and pretty common.
It's got to the point where it's absolutely essential to read all the errata before starting to program anything.

I guess there's a reason why they're often the cheapest
« Last Edit: June 29, 2012, 08:32:08 am by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27833
  • Country: nl
    • NCT Developments
Re: What uC to use in Automotive application
« Reply #32 on: June 29, 2012, 10:09:25 am »
If you are used to the 8052, this is what I use. An awesome 8bit, lots of MIPS and incredible analogue subsystems.
Amazing how a message can get delayed by more than 20 years! But to get you up to speed (literally): go for ARM.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline digsys

  • Supporter
  • ****
  • Posts: 2209
  • Country: au
    • DIGSYS
Re: What uC to use in Automotive application
« Reply #33 on: June 29, 2012, 12:02:09 pm »
Quote
Amazing how a message can get delayed by more than 20 years! But to get you up to speed (literally): go for ARM.
Mate, you don't know me nor what I do, and I don't quote your (or others) comments and bag what YOU do. Pls keep it civil.
If you have an opinion / suggestion, just make it, that's what we're here for. OPs will make their own decisions.

Hello <tap> <tap> .. is this thing on?
 

Offline darrylp

  • Regular Contributor
  • *
  • Posts: 127
  • Country: gb
Re: What uC to use in Automotive application
« Reply #34 on: June 29, 2012, 12:11:43 pm »
Most coders these days are lazy, real lazy. A real world 8bit 1mips processor can handle 6 cylinder ignition + injection to better than 1/100 degree crank rotation even at 9000 rpm.

The rule is optimise!  don't waste CPU cycles on calculating static data each loop iteration if its not needed. Large memory and fast cpus are not good to efficient designs IMO.
 

Offline T4P

  • Super Contributor
  • ***
  • Posts: 3697
  • Country: sg
    • T4P
Re: What uC to use in Automotive application
« Reply #35 on: June 29, 2012, 12:59:02 pm »
You'd wish that's the case, many uC's used in today's world calculate more than just the engine,
it's actually cheaper using a more powerful STM32F4 rather then 2 DSPIC33F's anyway
 

Offline notsob

  • Frequent Contributor
  • **
  • Posts: 705
  • Country: au
Re: What uC to use in Automotive application
« Reply #36 on: June 29, 2012, 01:03:40 pm »
RTFM - especially read the manufacturers errata,

THAT'S what it is there for
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27833
  • Country: nl
    • NCT Developments
Re: What uC to use in Automotive application
« Reply #37 on: June 29, 2012, 01:13:58 pm »
Most coders these days are lazy, real lazy. A real world 8bit 1mips processor can handle 6 cylinder ignition + injection to better than 1/100 degree crank rotation even at 9000 rpm.

The rule is optimise!  don't waste CPU cycles on calculating static data each loop iteration if its not needed. Large memory and fast cpus are not good to efficient designs IMO.
Optimizing costs time and thus makes development more expensive and increases time to market.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline NiHaoMike

  • Super Contributor
  • ***
  • Posts: 9201
  • Country: us
  • "Don't turn it on - Take it apart!"
    • Facebook Page
Re: What uC to use in Automotive application
« Reply #38 on: June 30, 2012, 04:50:15 am »
A FPGA seems like a better choice if you want to have fine control over the engine. I remember reading that the first generation Japanese market Prius used FPGAs for parts of the hybrid system control, then they went to ASICs once they realized they're going to have a big demand.

The nicest part of a FPGA is that by its very nature it works in parallel, so making a change to something like the knock detector isn't going to throw off timing in a critical part like the ignition or fuel injection.
Cryptocurrency has taught me to love math and at the same time be baffled by it.

Cryptocurrency lesson 0: Altcoins and Bitcoin are not the same thing.
 

Offline JoannaK

  • Frequent Contributor
  • **
  • Posts: 336
  • Country: fi
    • Diytao making blog
Re: What uC to use in Automotive application
« Reply #39 on: June 30, 2012, 03:44:34 pm »
If it's automotive and safety critical.. I'd say go for Freescale. They have been doing those transport (not just automotive) chips for quite a long time and know what kind of controlls you'll need.

I know the 32 bit PPC cores aren't as media sexy as these Arm:s, but still they are quite amazng chips.
 

Offline Baliszoft

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: hu
Re: What uC to use in Automotive application
« Reply #40 on: June 30, 2012, 09:18:59 pm »
I have used the dspic30f family for automotive applications without problems. It has got lots of silicon bugs for sure, thouhg all of them are documented and one can find a workaround for the particualr problem. I chose the 30f because it can work on 5v, and it is a lot more favourable voltage than 3.3v (sensors wise). It is not an automotive uC however, i coulndt find any reasons why not to use it. It is not fast either, though still faster than some old automotive controllers (f.eg siemens/infineon c166/c167). Using it with a faster crystal than 5mhz (pll-d) is already out of spec for the extended temperature range. No doubt, there are lots of better and specialized micros out there for this purpose.
« Last Edit: June 30, 2012, 09:21:58 pm by Baliszoft »
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: What uC to use in Automotive application
« Reply #41 on: July 03, 2012, 08:55:15 am »
IIRC engine management systems are one level below in "criticality" than what I work on (braking systems). But nevertheless you want extremly bug-free silicon and software. You wouldn't want your company's customer to come and say something like: "ok, total engine rapair is $10k, and you have caused it. We have fitted 1k of engines with your ECU. Have a nice day" :).

Plus diesel engines these days are far more complicated than petrol engines and are pushing material limits much further (eg. variable-geometry turbo, high compression ratios, extreme fuel rail pressures, stratified multistage injection etc).

ARM is consumer/high volume stuff. I'm not saying it's bad. Just not designed specifically for automotive. I have disassembled and examined numerous different control units from quite a few brands and never saw single ARM MCU. As JoannaK wrote: mostly Infineon, Freescale, in older designs Toshiba, TI or garden variety 8051. Never saw an FPGA, one time there was XC9500 CLPD (we figured it was used for routing signals in different ECU variants). Some unusual stuff happens like Atmel Automotive AVR, Renesas (formerly NEC), Raytheon (probably custom anyway - that's what Raytheon does).
I love the smell of FR4 in the morning!
 

Offline T4P

  • Super Contributor
  • ***
  • Posts: 3697
  • Country: sg
    • T4P
Re: What uC to use in Automotive application
« Reply #42 on: July 03, 2012, 10:17:26 am »
Because ARM mcu's are brand new and nobody dares to test it
It's got brunt in areas they completely don't
 

Offline Baliszoft

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: hu
Re: What uC to use in Automotive application
« Reply #43 on: July 03, 2012, 10:52:08 pm »
you want extremly bug-free silicon and software
There is no such thing :-).
Dspics are sill considered to be plain risc processors (maybe they did not want to license the arm architecture?)
« Last Edit: July 04, 2012, 06:49:14 pm by Baliszoft »
 

Offline Hypernova

  • Supporter
  • ****
  • Posts: 655
  • Country: tw
Re: What uC to use in Automotive application
« Reply #44 on: July 05, 2012, 03:59:52 am »
you want extremly bug-free silicon and software
There is no such thing :-).
Dspics are sill considered to be plain risc processors (maybe they did not want to license the arm architecture?)

There's really no equivalent for the ARM in the 16bit class, the more proper comparison is with the PIC32 line which is MIPS based. Another example is Renesas which wiped up their own RX core and Atmel's AVR32.
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8393
Re: What uC to use in Automotive application
« Reply #45 on: July 05, 2012, 07:18:01 am »
you want extremly bug-free silicon and software
There is no such thing :-).
8051 comes close, simply by being old enough that established software and hardware have had all the bugs ironed out.

Renesas also has its SH series, probably more popular in Japan, here's one in an ECU:
http://en.wikipedia.org/wiki/File:Denso-SH2.jpg
 

Offline RundstedtTopic starter

  • Contributor
  • Posts: 21
  • Country: pl
Re: What uC to use in Automotive application
« Reply #46 on: July 06, 2012, 07:38:02 am »
First, thanks for all replies. After nearly 2 weeks my boss finally explained me what I really have to do, I have to make an ECU for monofuel car (for diesel-cng/lpg conversion). So it is "a bit" more that i was expected.

Ok, so you're working for "AC S.A." am I right? :)
Nope, I work in Mi?sk Mazowiecki.

First of all, don't use dsPIC30F, they suck and are full of bugs. Rather go for dsPIC33 family. Faster and better.

I was thinking about dsPIC33 but i couldn't find dsPIC33 for 5V. And that was important for me. For example I would have to put a lot of voltage dividers for most analog sensors.

Although all Yours warnings about silicon bugs in dsPic30 won't go unnoticed, and I will read silicon errata a few times. For now I will go with dsPIC30F6012A.

If it's automotive and safety critical.. I'd say go for Freescale. They have been doing those transport (not just automotive) chips for quite a long time and know what kind of controlls you'll need.

Freescale and STM16 was one of my first choices, unfortunately they are much harder to get, much smaller online community and my company hired me with knowledge that I programmed only 8051 and atmegas in my life, with no commercial experience. 



 

Offline T4P

  • Super Contributor
  • ***
  • Posts: 3697
  • Country: sg
    • T4P
Re: What uC to use in Automotive application
« Reply #47 on: July 06, 2012, 08:31:34 am »
Never heard of STM16 before, ST does have some automotive MCU's
 

Offline RundstedtTopic starter

  • Contributor
  • Posts: 21
  • Country: pl
Re: What uC to use in Automotive application
« Reply #48 on: July 07, 2012, 10:16:32 am »
Never heard of STM16 before, ST does have some automotive MCU's
Sorry, thought shortcut. What I meant was 16bit mcu from STMicroelectronics like st10 or sth
 

Offline DuaneJack

  • Newbie
  • Posts: 1
Re: What uC to use in Automotive application
« Reply #49 on: July 07, 2012, 02:15:05 pm »
Hello, I just joined the forum after reading this thread.  I am a certified Master Technician and I am at the other end of the spectrum from all you EE's out here.  I would like to offer a few suggestions to your design along with a little tip on your R & D.  You may find lots of info out here on the web and get lots of assistance from folks like all the Gents on this Thread but please dont forget the little guy at the other end who has to repair your design after it has been implemented.  Or is that important, how many techs in the field repair Control Units (CU's) ie: (ECU, ECM, PCM, TCM, BCM, etc), almost zero.  There are a few shops that specialize in certain models and they have a mock up board to diagnose and perform component replacement throughout the entire unit but again, these are mostly specialists to only a couple of CU's.  Even though I dont do component replacement, I sure would like to know how to diagnose the CU and understand the Theory of Operation, what pins are inputs, outputs and how do they interact.  Which pins are high and low under normal circumstances and what is the logic supposed to be when a certain switch is turned on.  You would not believe how many folks dont know why they get 12 volts on their voltmeter on the ground side of a ground side controlled circuit.

Some of the guys talked about over engineering, YES, choosing a chipset that is way too much for the job at hand, I promise, you will want to upgrade your project at some point and it will be sooner than you think, as soon as you complete your project, the boss will want you to add another option to the CU.  Be prepared to add a daughter board to the CU as opposed to a complete redesign of your PCB, even better, a completely seperate add on CU (slave).  Todays vehicles have upwards of 20+ CU's around the vehicle.  One of the reasons was to keep replacement cost down for the consumer in case a specific system had a major malfunction that requires replacement of the smaller CU as opposed to a single PCM that monitors and controls the entire vehicle.  Another reason was to speed up and simplify diagnosis for the field tech.  I am sure you know all about CAN systems of today.  We dont have Logic Analyzers and most dont have oscilloscope above 100MHz.

How will you allow your CU to be diagnosed in the field or in a repair facility, will you allow for the field tech to reflash the programming via a dedicated reprogrammer or via the Web via what type of interface.  Will the CU be diagnosed via software on a PC (laptop) that you design or via the OBDII or CAN standards.  Emission Standards, this is also where your Map will come into play.  Someone mentioned something about sensor inputs, speed of reaction to these inputs and Emissions.  Car computers are really slow so dont worry too much about lightning speed reaction times if you are not CAN Complient otherwise I think you will only need something like 9800 baud rate, I may be too slow on that but its slow for sure, but this is not for normal operations of most systems, only the CAN BUSS talking and monitoring systems and components.  I highly recommend to build it test points where a graphing multimeter or oscilloscope can tag certain lines without fear of shorting something out in a compact area of the PCB.  Not all field techs can afford nice equipment so how user friendly do you want to make your product, how much documentation do you want to put out to the field.

I noticed a few mechanical suggestions.  A four channel scope is nice as you will need to tag four different areas of a system, not necessarily all 4 cylinders, creating ignition and injection is a series procedure and that one series line can be tagged to get all four cylinders one after the other.  Triggering off of one cylinder (usually cyl #1) will give you your reference point for firing order such as 1, 3, 4, 2 while triggering from #1, just count the pulses series until you see your problem, if its on #1, change your reference trigger point.  I know you are not designing the engine but you could ask for some simple additions to their design which consists of a simple stamp in the sheet metal or a paint mark across two mating components.

If you use the flywheel to monitor RPM based on a magnetic pickup or Hall Effect sensor, there are many models that allow the flywheel to be reinstalled in any old manner after completion of maintenance since all the mounting bolt holes are equally spaced, alignment marks or paint marks will help immensely.  Components that can only be installed one way such as the front harmonic balancer pulley or crankshaft & camshaft timing gears are not bullet proof.  Even the steel alignment pins or keys and keyways wear out.  Doing a quick visual inspection of the timing belt or chain will not show the issue at hand as the belt and gear are still in time but with a sheared alignment pin, the camshaft itself is out of time.  This is also a major issue with harmonic balancer pulleys that have rubber dividers between inner and outer rings, the timing marks align on the outer ring but the inner ring attached to the crankshaft is out of time.  So be aware of where you place your reluctor for a magnetic pick up if you use this type of system.  You should publish the waveform and corollation of all your timing signals.

Heat and cold was hit on but dirt and dust and liquids were not addressed.  Mainly in high dust areas there can be a lot of dust intrusion into the case of your CU as you need to allow for heat ventilation of some magnitude.  Adding on a nice user replaceable air filter would be nice.  Air Conditioning systems use them to filter out dust and pollen but sometimes they install them in the damndest places, why.  Mounting location of the unit was hit on but putting it under the hood, well, it offers ease of access but its pretty hot and dusty in there.  Being in an area of extreme temperature changes promotes high condensation rates and a corrosive environment.  Can other fluids be accidentally spilled on it while servicing the brake fluid, oils, or if the radiator decides to let loose, where is all the antifreeze going and if it has not been properly maintained, its corrosive also.  Consumers love consumer products like Coke and they love to spill it everywhere if mounted in the cabin, enough said about that.  Back to ease of access and length of wire harness and orientation of the CU if mounted up under the dash or down in a kick panel, NOT under the seat, people love to leave their windows down in a rain storm.  The field tech would love to be able to pull this thing out and back probe it or attach a breakout box without the need to pull so hard as to pull a few pins out in the process.  An EE subject I have seen on many PCB's, if you use electrolytic caps, seal the base with the proper type of glue to prevent the electrolytic from running down the board and eating up part of the PCB traces along with other components.  Mitsubishi is famous for this.  On another subject I have seen fuel wick up the wire from a fuel injector into the CU and flood it out and destroy it, beware.

Fuel injectors come in all resistance ranges but maybe your design will be model specific, but again, thinking in the future, you will want to make a simple component change to allow for a multitude of applications, this also goes for ignition coils if you go petrol.

Voltage ranges, in the 12 volts systems, you will want to allow from 9 to 18+ volts for weak charging to non regulating dynamo scenarios.  I cannot speak for the 24 volt systems.

Maps, this CU is fully reprogrammable and many manufactures today allow for their own mistakes when they design a Map and they also allow for normal wear and tear which will also require a reflash months or years down the road as opposed to a refit of a new expensive preprogrammed CU.  You can program multiple Maps designed for multiple applications of your powertrain system, even with only one engine in mind and maybe even only one chassis in mind, along with automatic or manual gear selection, there are always a multitude of driving scenarios such as mostly city, highway, mountainous, granny mode or young punk race mode, work vehicle hauling lots of people or a lot of heavy equipment.  Some of these modes could be selected via a user input switch similar to power, normal, towing modes.

Now for my original purpose of joining this thread, get a field tech in with you on the R & D so that when you make your presentation to the Board and they ask for a demonstration of your project, you can also show them how easy it is for a technician in the field to diagnose this CU, its easy of access along with its safety and security of its mounting point and the purpose of its orientation.  The need for selectable Maps and the forward looking need of reflashing for a multitude of reasons, a few of which you will name.

I am all over the place on this post so let me recheck and ask a couple more questions.  CAN, helps to diagnose issues thoughout the vehicle.  Most techs dont understand CAN and I dont even want to get into, scan the system, see what CAN Data says to do, then do it.  I always back up scandata via a scope, I just dont trust scanners but they do help to narrow down a system issue to a smaller area of concern.  Without a complete understanding of what make the vehicle tick, it does not always come down to experience.  I mentioned adding in test points but not only on the PCB.  Allow a wire to come out of the main harness to allow an Amp Clamp to be attached for some non intrusive testing, ie: ignition coils, injectors, checking base timing can all be done via an Amp Clamp.  Build in some test connections so wires dont need to be probed or backprobing a connector is quite popular also but should not be required, there are some real brutes out here who dont care what kind of a hack job they do, they will just cut up a harness to try to find a short and then rewire two red wires back together just because they are red not caring that there are two sets of red wires in the bundle, then they give up and the next tech has to find that issue as well.

Sorry for the rants, I am out'a'here..............
Duane in Japan
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf