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

0 Members and 1 Guest are viewing this topic.

Offline RundstedtTopic starter

  • Contributor
  • Posts: 21
  • Country: pl
What uC to use in Automotive application
« on: June 12, 2012, 11:24:16 am »
Hello!
Recently I started my first engineering job and now I stand before difficult (and quite big) decision to make, my objective now is to design and program an ECU for a petrol car (controlling throttle, injectors and ignition). And I have to choose uC family that will run all that. I will program it in C. I'm currently familiar with 8052 and (a  bit less) with avr (8bit).

So can you good people from eevblog forum help me with your advice? And then advice me on good ISP programmer/debugger, and some starter board for educational purposes.

Currently I was thinking about dsPIC family although STM8 or even atmega (models for mobile purposes) came to mind.

Should I focus my search on DSP or uC will do the job?

Since it is my first post here, I'd like to apologise for my bad english.
« Last Edit: June 12, 2012, 11:44:50 am by Rundstedt »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27665
  • Country: nl
    • NCT Developments
Re: What uC to use in Automotive application
« Reply #1 on: June 12, 2012, 12:38:59 pm »
I'd go for an ARM based controller. Look for automotive specified parts and make sure you get a copy of the latest MISRA book.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 10181
  • Country: nz
Re: What uC to use in Automotive application
« Reply #2 on: June 12, 2012, 12:44:26 pm »
Automotive stuff is a little different to regular electronics.  It's supposed to last the life of the car, which could be 20 years. Unlike consumer electronics which is at most 5 years. You're supposed to design everything to be able to handle double the intended voltage without pushing any component past its rated specs.

You're supposed to have TVS diodes (or other protection) on all external I/O and a main large 24V TVS on the supply input.
As an example, an external 12v on/off signal to a 5v micro input might go something like this.

(might be able to combine the TVS and zener, you can get tiny SO package input protection chips)

Components rated for the full temperature range are a good idea as well.
And watch for grounding issues between high current outputs and low current sensor inputs.

As said above, look for components where the datasheet says "automotive use"
« Last Edit: June 12, 2012, 01:24:17 pm by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline RundstedtTopic starter

  • Contributor
  • Posts: 21
  • Country: pl
Re: What uC to use in Automotive application
« Reply #3 on: June 12, 2012, 01:37:08 pm »
Thank you for replies!

Of course I look only parts qualified for automotive design but still there is so much of it (most uC families have their automotive counterparts).

@nctnico, I think ARM is a bit of overkill, dsPIC30 is way to much for this current design (it was used in some other company products).

Currently I'm leaning towards PIC family cause they have 8bit and 16 bit MCUs and so many different uC in their offer.

And what ICSP for development? PICkit3? Maybe something else?

What Development/Prototype board for educational purposes for it? I found TDGL003, it looks nice, it has CAN controller so would be perfect for learning.

@Psi yes I know that this design should be tough, but thanks for the TIP about TVS diodes

 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27665
  • Country: nl
    • NCT Developments
Re: What uC to use in Automotive application
« Reply #4 on: June 12, 2012, 02:54:56 pm »
There is no such thing as overkill! There is no cost advantage of using a slower controller.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8545
  • Country: us
    • SiliconValleyGarage
Re: What uC to use in Automotive application
« Reply #5 on: June 12, 2012, 03:14:07 pm »
automotive grade Cortex-M3 processors are cheaper than pic's ... and they have way much more horsepower and peripherals.
Like Nctnico said : there is no cost benefit of messing around with an underpowered controller.

And i agree : start by reading MISRA and get a development tool that supports MISRA ( IAR and Keil both do you enable the MISRA option and the compiler will refuse to generate code for anything that is non-compliant. you can even toggle individual MISRA rules on and off. )

btw : MISRA : Motor Industry Software Reliability Association. It is a set of unbreakable rules ( and some guidelines ) to be followed when developing code for automitve and mission critical systems using the C language.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline T4P

  • Super Contributor
  • ***
  • Posts: 3697
  • Country: sg
    • T4P
Re: What uC to use in Automotive application
« Reply #6 on: June 12, 2012, 05:42:44 pm »
Calling the 'Cortex-M3' Overkill is like calling a ferrari that is a ferrari but much cheaper and oddly cheaper then a toyota too fast for racing

Cortex-M3's start from 1-2$ at one off quantities ( And they contain a big amount of RAM compared to PIC32 whether you need or not ! )
« Last Edit: June 12, 2012, 05:52:44 pm by DaveXRQ »
 

Offline Baliszoft

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: hu
Re: What uC to use in Automotive application
« Reply #7 on: June 12, 2012, 06:43:09 pm »
As the other members suggest, go for automotive graded parts (not just the uC). Very important thing is to use adequate protection on power to low voltage circuits (reverse battery protection, protection against tansients, against load dump). You may however use a lot simpler protection on the io lines. A 10nf cap to gnd at the connector (spark gaps often used in older devices), 2k pulldown/pullup resistor and a high value resistor before uC (min 33k to several hundred k ohms) is a common practice (for digital input and freq counting). Modern uCs already have got clamping diodes inside, you just have to make sure that you do not exceed the maximum clamping current. Regarding to AD channels is a different story, as the maximum required impedance for the AD to work correctly may be low for protection. To overcome this problem optional op amps (with the current limiting resistors) can be used.

I have succesfully used the extended temperature version of the dsPic family for such an application (they are cheap and easily obtainable, though they are not the most powerful ones, you can find faster alternatives).

I also suggest you to take a look at different manufacurers site (f.eg freescale, st, bosch semiconductor), because there are a lot of nice and handy asics available in the topic. These may be expensive or not really available in lower quantities, however.
« Last Edit: June 12, 2012, 08:47:32 pm by Baliszoft »
 

Offline snoopy

  • Frequent Contributor
  • **
  • Posts: 768
  • Country: au
    • Analog Precision
Re: What uC to use in Automotive application
« Reply #8 on: June 13, 2012, 03:22:51 am »
Hello!
Recently I started my first engineering job and now I stand before difficult (and quite big) decision to make, my objective now is to design and program an ECU for a petrol car (controlling throttle, injectors and ignition). And I have to choose uC family that will run all that. I will program it in C. I'm currently familiar with 8052 and (a  bit less) with avr (8bit).

So can you good people from eevblog forum help me with your advice? And then advice me on good ISP programmer/debugger, and some starter board for educational purposes.

Currently I was thinking about dsPIC family although STM8 or even atmega (models for mobile purposes) came to mind.

Should I focus my search on DSP or uC will do the job?

Since it is my first post here, I'd like to apologise for my bad english.

When it comes to auto manufacturers you will find that that cost is what determines what parts are used. Every last cent is important to an auto maker. They really are cheap skates although you wouldn't believe it when you have to fix your own car and buy parts from them !!
 

Offline RundstedtTopic starter

  • Contributor
  • Posts: 21
  • Country: pl
Re: What uC to use in Automotive application
« Reply #9 on: June 13, 2012, 07:51:17 am »
When it comes to auto manufacturers you will find that that cost is what determines what parts are used. Every last cent is important to an auto maker. They really are cheap skates although you wouldn't believe it when you have to fix your own car and buy parts from them !!
Well I don't directly work for auto manufacturer, I work for a company that produce LPG and CNG installations. As a start they want me to create ECU for diesel engine. I looked on a demo product by some company from usa (LPG ecu) and they used huge freescale MCU along with Ethernet controller, 4 layer pcb with parts on both sides, and another SoC (that even wasn't graded for automotive design). It was huge, and can't even imagine how much it cost to manufacture.

Calling the 'Cortex-M3' Overkill is like calling a ferrari that is a ferrari but much cheaper and oddly cheaper then a toyota too fast for racing

Cortex-M3's start from 1-2$ at one off quantities ( And they contain a big amount of RAM compared to PIC32 whether you need or not ! )

On digikey I checked Cortex M3 core, and -40C to 125C and it found me 10 products and cheapest one was almost 11$, can you show me maybe  where I can buy Cortex-M3 for automotive for 1-2$

I have succesfully used the extended temperature version of the dsPic family for such an application (they are cheap and easily obtainable, though they are not the most powerful ones, you can find faster alternatives).
Well power is not that big concern to me, cars 20 years ago had 8052 in them, if not for lack of peripherals that kind of power is ok.
I also suggest you to take a look at different manufacurers site (f.eg freescale, st, bosch semiconductor), because there are a lot of nice and handy asics available in the topic. These may be expensive or not really available in lower quantities, however.
Yes, that is quite a problem. For a start I will need low quantity to prototype (this diesel ecu won't be put to production anyway, it is a project for me to learn from and test me in new job)
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8380
Re: What uC to use in Automotive application
« Reply #10 on: June 13, 2012, 08:14:29 am »
I've seen quite a few Motorola (now Freescale) 68xx / 9S12 in ECUs. Earlier ones more commonly used MCS51/52, and there's one that used an 1802 (can't remember exactly). If you're familiar with the 8052 then I'd say that's a good choice. In applications like this, processing power is not the main constraint --- reliability is. A many decades old architecture that's tried and tested is better from this standpoint than the latest superpowerful MCUs.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27665
  • Country: nl
    • NCT Developments
Re: What uC to use in Automotive application
« Reply #11 on: June 13, 2012, 08:45:37 am »
I've seen quite a few Motorola (now Freescale) 68xx / 9S12 in ECUs. Earlier ones more commonly used MCS51/52, and there's one that used an 1802 (can't remember exactly). If you're familiar with the 8052 then I'd say that's a good choice. In applications like this, processing power is not the main constraint --- reliability is. A many decades old architecture that's tried and tested is better from this standpoint than the latest superpowerful MCUs.
That is like saying sending a letter is more reliable than an e-mail. Its totally wrong. In the old days an ECU didn't do a lot. Nowadays you need the best timing resolution you can get to inject fuel at exactly the right moment (especially for diesel) to meet environmental regulations. More speed is always better.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Baliszoft

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: hu
Re: What uC to use in Automotive application
« Reply #12 on: June 13, 2012, 11:41:14 am »
I have succesfully used the extended temperature version of the dsPic family for such an application (they are cheap and easily obtainable, though they are not the most powerful ones, you can find faster alternatives).
Well power is not that big concern to me, cars 20 years ago had 8052 in them, if not for lack of peripherals that kind of power is ok.

When i started my (similar) project 3 years ago, i also thought the same :).

More speed is always better.

This is very very true. I suggest you to get the fastest one you can, even if you think you do not need it at all :). The timing (turning on injectors, turning off injectors, charginig ignition coils, discharging ignition coils) eats up at least the 60%-70% processing power of the processor, and you did not even do anything else. The extended temperature version of dspic30fs can be good up to max 20MIPS only (less than the industrial one), which is not a breathtaking performance at all, especially if you are going for C. I was using assembly, so i could do everything i wanted (six cylinders, with a nice resolution of timing), but i could not do that in C for sure at 20MIPS. The RISC architecure also favours asm instead (in my opinion). If i were just going for a 4 cyl diesel (4 injection only), the 20MIPS dspic30f could do a timing resolution of min. ~3 uS even in C (i did 12 channels (6inj+6ign), with 5uS resolution in asm). If you are happy with that, then it may be an alternative. The biggest dspic30f has got enough peripherials and memory to accomplish all this. I know, because i have already done that (and using the ECU at the moment).
 

Offline Baliszoft

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: hu
Re: What uC to use in Automotive application
« Reply #13 on: June 13, 2012, 11:49:48 am »
And what ICSP for development? PICkit3? Maybe something else?

Definitely pickit2 for dspic30f.
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 10181
  • Country: nz
Re: What uC to use in Automotive application
« Reply #14 on: June 13, 2012, 11:55:22 am »
You might at some point want to calculate a real time automotive map using a complex function.
Having an ARM chip that can do floating point without taking a significant speed hit is very useful.

While you can do floating point on a 8bit chip it really limits how responsive you can make the system.
« Last Edit: June 13, 2012, 11:57:50 am by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline Baliszoft

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: hu
Re: What uC to use in Automotive application
« Reply #15 on: June 13, 2012, 12:03:46 pm »
You might at some point want to calculate a real time automotive map using a complex function.
Having an ARM chip that can do floating point without taking a significant speed hit is very useful.

While you can do floating point on a 8bit chip it really limits how responsive you can make the system.

Yes, you are right. Lot of fractional multiplications, divisions, etc are needed to calculate (lots of) parameters, the dspic cannot do floating point at all, i have no idea how effective the compiler handles these calculations.
 

Offline RundstedtTopic starter

  • Contributor
  • Posts: 21
  • Country: pl
Re: What uC to use in Automotive application
« Reply #16 on: June 13, 2012, 12:11:11 pm »
And what ICSP for development? PICkit3? Maybe something else?

Definitely pickit2 for dspic30f.
Oh, not PICkit3? I've read that PICkit2 is no longer developed by microchip so it may not support some chips.

I was planning for a first buy TDGL003 (to learn basic programming of pic, it also has CAN bus so I can learn how to use it), and PICkit3 (with development board). But if you say I should rather buy PICkit2 maybe I should.

Well, truth to be told when I started planning whole project (2 days ago) I thought I would use dsPIC30F5015 (it was used on other ECU made for us by outside company), but then my co-workers suggested me that maybe I would use something smaller cause there is no need for that much processing speed. But now you begin to change my mind.
 

Offline T4P

  • Super Contributor
  • ***
  • Posts: 3697
  • Country: sg
    • T4P
Re: What uC to use in Automotive application
« Reply #17 on: June 13, 2012, 12:25:36 pm »
Floating points are undisputedly really useful for timing, something like the STM32F4 has been really excellent for me
There's a reason PICkit2 is suggested for the old parts, it's because it's got something else the pickit3 doesn't and ... ah well
At the same time look at the STM32F4-Discovery (Costs less, much less) and the STM32F4 parts, they aren't much more expensive (Pretty cheap actually) then the dspic30f and if this isn't an one off ST will provide a shitload of dev equipment if you would use their parts

« Last Edit: June 13, 2012, 12:30:50 pm by DaveXRQ »
 

Offline Baliszoft

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: hu
Re: What uC to use in Automotive application
« Reply #18 on: June 13, 2012, 12:46:53 pm »
There was a thread here why the pickit2 was better than the pickit3. Pickit3 will work of course perfectly, however there are some things in which pickit2 was better. If it is not available anymore, that is a pity. I used both, as i got two 30fs on my board :). As for the micro choice, i went for the dspic30f6014 doing the timing and "calculating physics" and also i got a 30f3011 doing some high speed signal processing evaluating the signals of knock sensors (which is of course not needed for diesel), and it is only to please my experimental pleasure, as this task could have been solved with an asic for $5 :).

Here it is (it is a bosch motronic me7.5 pin compatible ecu):
 

Offline RundstedtTopic starter

  • Contributor
  • Posts: 21
  • Country: pl
Re: What uC to use in Automotive application
« Reply #19 on: June 13, 2012, 01:00:17 pm »
i got a 30f3011 doing some high speed signal processing evaluating the signals of knock sensors (which is of course not needed for diesel)

Well that is main reason why as my first project was chosen ECU for non Commonrail diesel, simply cause it is easier, no throttle control, no lambda sensor, only fuel injection, no knock sensors.
 

Offline caroper

  • Regular Contributor
  • *
  • Posts: 193
  • Country: za
    • Take your PIC
Re: What uC to use in Automotive application
« Reply #20 on: June 13, 2012, 03:02:24 pm »
You haven't given any indication of budget but I get the impression that your employer is taking this seriously.
With that in mind I would suggest you go for the ICD3 rather than the PICKit, it is faster and offers far more debug capability. I have several have both models of PICKit and like them both in their respective rolls but when it comes down to trying to finding an I/O problem, Timing issue or Memory leak the ICD3 is the tool to have at hand.


It may be overkill for a hobbyist but still reasonably priced for a company that appreciates having the correct tools for the job.


Cheers
Chris








Offline RundstedtTopic starter

  • Contributor
  • Posts: 21
  • Country: pl
Re: What uC to use in Automotive application
« Reply #21 on: June 14, 2012, 09:06:37 am »
You haven't given any indication of budget but I get the impression that your employer is taking this seriously.
With that in mind I would suggest you go for the ICD3 rather than the PICKit, it is faster and offers far more debug capability. I have several have both models of PICKit and like them both in their respective rolls but when it comes down to trying to finding an I/O problem, Timing issue or Memory leak the ICD3 is the tool to have at hand.


It may be overkill for a hobbyist but still reasonably priced for a company that appreciates having the correct tools for the job.


Cheers
Chris
Unfortunately I already placed order for PICKit 3, but I'm sure that  if after 3 months they decide that they like what work I'm doing they will buy ICD3.

Today my boss was talking something about setting a place for me with some soldering tools, multimeters probably an oscilloscope, so I need to watch Dave video on setting a basic electronic workshop once more.
 

Offline T4P

  • Super Contributor
  • ***
  • Posts: 3697
  • Country: sg
    • T4P
Re: What uC to use in Automotive application
« Reply #22 on: June 14, 2012, 09:53:27 am »
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

I'll let you decide what multimeter is good for you or what, if so consider a Agilent U1272A or the U1252A

Just a rough one.
 

Offline senso

  • Frequent Contributor
  • **
  • Posts: 951
  • Country: pt
    • My AVR tutorials
Re: What uC to use in Automotive application
« Reply #23 on: June 14, 2012, 03:08:09 pm »
That a look in the MegaSquirt ignition/injection management unit, its sort of open source, so you can acess all the code and the schematics.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8545
  • Country: us
    • SiliconValleyGarage
Re: What uC to use in Automotive application
« Reply #24 on: June 14, 2012, 04:55:47 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

I'll let you decide what multimeter is good for you or what, if so consider a Agilent U1272A or the U1252A

Just a rough one.
i would focus on getting a good SCOPE first... if you are doing an ECU you will need to look at signals first and foremost...
since cars have more than 2 cylinders... 4 channel scope ! preferrably an MSO style system so you can watch an spi or i2c or some other digital pattern or debug signals while looking at analog signals simultaneously. get something with a bit of oomph (memory and sampling speed. the mso3000x comes in mind , or go for a 7000 series. laaaarge display )

I would not muck around with handheld multimeters either. They tip over , are always in the way on your working area . Get a bench meter.
Agilent has entry level bench meter ( 4-1/2 (escort design) and 5-1/2 like the 34405 (real agilent design))

And a good power supply. E36xx series or E34xx series.

As for soldering irons.. JBC ( ihad one for 8 years, it was ok , but the tips were easily damaged and the clamping system was crap. when i could afford a weller i switched and never looked back...)
Hakko and Ersa ... don't like those. they just don't feel right.

Get a metcal, one basestation with two irons on it. and different tips.
For precise work get the weller microiron
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27665
  • 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: 10181
  • 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: 27665
  • 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: 704
  • 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: 27665
  • 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: 9184
  • 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: 8380
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
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27665
  • Country: nl
    • NCT Developments
Re: What uC to use in Automotive application
« Reply #50 on: July 07, 2012, 03:09:17 pm »
In many cases the diagnostic error code of a car tells absolutely nothing about the real problem!

A few weeks I ago my car wouldn't start. The diagnostics said that the fuel injection timing valve needed to be replaced. In reality the timing belt was broken. If the ECU had more horsepower it could be made smart enough to see the injection pump wasn't rotating but the camshaft was so it could say something about the timing belt. That would have been a meaningfull error.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline yyrkoon

  • Newbie
  • Posts: 6
Re: What uC to use in Automotive application
« Reply #51 on: August 23, 2012, 03:55:09 am »
ARM is consumer/high volume stuff. I'm not saying it's bad. Just not designed specifically for automotive.

http://www.ti.com/lsds/ti/arm/hercules_arm_cortex_r_safety_microcontrollers/overview.page

No hands on or personal experience with it. But they are being touted as safety MCU's. Have some experience with the Stellaris Cortex M3 line. Which is buggy. Though the more I look at the C2000 line, the more I like. A piccolo seems like it could handle the job easily. Would it last though ? No idea.
 

Offline NiHaoMike

  • Super Contributor
  • ***
  • Posts: 9184
  • Country: us
  • "Don't turn it on - Take it apart!"
    • Facebook Page
Re: What uC to use in Automotive application
« Reply #52 on: August 24, 2012, 02:48:14 am »
In many cases the diagnostic error code of a car tells absolutely nothing about the real problem!

A few weeks I ago my car wouldn't start. The diagnostics said that the fuel injection timing valve needed to be replaced. In reality the timing belt was broken. If the ECU had more horsepower it could be made smart enough to see the injection pump wasn't rotating but the camshaft was so it could say something about the timing belt. That would have been a meaningfull error.
Wouldn't a broken timing belt prevent the camshaft from turning?
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 poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: What uC to use in Automotive application
« Reply #53 on: August 24, 2012, 06:21:39 am »
Timing belts most of the times function well and then suddenly they tear break causing massive damage to valves and pistons, because everything loses synchronisation and pistons hit valves when they are open. Some engines are engineered in such way that this is not possible (eg. GM\Opel\Vauxhall\Holden C20NE).

But such failures that the belt doesn't break completly, but rather stretch are also found. it causes marginal timing change, but i guess if it was en extreme case it could affect vehicle performance.

Timing belt can also get damaged if one pulley or another breaks and belt can touch some static surface (eg waterpump or engine block). It becomes thinner and thinner and in the end will break prematurely.

such things happen, but a tech with 3 month of experience probably won't know that and will only rely on what diagnostic interface says.
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 #54 on: August 24, 2012, 12:11:52 pm »
Always trust your eyes! Not your diagnostics ...
 

Offline SeanB

  • Super Contributor
  • ***
  • Posts: 16362
  • Country: za
Re: What uC to use in Automotive application
« Reply #55 on: August 24, 2012, 03:41:54 pm »
Mine said Idle adaptation was outside normal range. Solution? Change the fuel filter, as it was restricted.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 27665
  • Country: nl
    • NCT Developments
Re: What uC to use in Automotive application
« Reply #56 on: August 26, 2012, 09:36:18 pm »
In many cases the diagnostic error code of a car tells absolutely nothing about the real problem!

A few weeks I ago my car wouldn't start. The diagnostics said that the fuel injection timing valve needed to be replaced. In reality the timing belt was broken. If the ECU had more horsepower it could be made smart enough to see the injection pump wasn't rotating but the camshaft was so it could say something about the timing belt. That would have been a meaningfull error.
Wouldn't a broken timing belt prevent the camshaft from turning?
Yes (ofcourse  ;) ). But my engine has a rotation sensor on the injection pump (which is also driven by the timing belt) and the crankshaft. The engine even runs fine if only one of these two sensors is working. It would have been a small effort to check whether the sensors are connected and point into the direction of the timing belt and not a very expensive part (€ 400) which almost never goes bad. Anyway, the engine in my car has been engineered to sacrifice the rocker in case the timing belt breaks. Replacing the belt and a rocker fixed it without having to remove the cylinder head.
« Last Edit: August 26, 2012, 09:37:51 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf