Which Micro controller is best to use Automotive products

Hi,
What would be your operating environment in automotive domain? Are you looking for a AEC-Q100 qualified products? You are posting your question in the TM4C forum. The TM4C products do have some examples interfacing to the Camera and RFID. Please refer to TI Reference designs at www.ti.com/.../refdesignsearchresults.tsp for examples interfacing to Camera and RF using TM4C.

Dinesh,
It is certainly impossible to answer you before you tell us more about your requirements.
Even then, we will try - but if you can, a chat with a FAE would probably be recommended.
Anyway, I could try to help if you disclose:
- What sort of cost constrains are involved?
- How is the powering scenario? Unlimited energy from the vehicle battery? Or an autonomous device?
- Qualifications/approval? AEC-Q100?
- Communication requirements with the "rest of the vehicle"? CAN? None?
- What tasks will this MCU do? What processing is expected?
- Further, what do you want it to do with the camera? When you add image/video to the recipe, the processing requirements go waaaaaay up - to the point that you might need a dedicated MCU just for that, and a low cost, low power part for everything else...
Truly, all you will get here are suggestions, and they will only be assertive if you provide A LOT of information - including block diagrams of your application. Of course, I assume you don't really want to share all that in a public forum, and if that's the case, the FAE will probably serve you better.
Regards
Bruno

Following that "3rd degree/barrage" both poster (likely) & cb1 (for sure) - "head for the hills!"

:)
Torture, here?
At least there's a basic list of questions to be replied - either here or on his own project notes! Can't run away from those inconvenient questions!

From poster's single sentence request - expanded into Auto, Camera & RF ID - might your "expectations" be a "tad" high?

Just to add to your list

Bruno Saraiva said:

- What sort of cost constrains are involved?

Expected quantity, not only is there a price effect but some parts are only available in large quantities.

And not mentioned is temperature. There are two automotive temperature regimes I'm aware of (as in I've run across items qualified to one or the other) under hood/engine and cabin.

Robert

Hi Sir,

My requirement

 1.Driver Activists monitoring using Camera module

 2.GPS,GSM/GPRS and RFiD is no problem to interface with Micro-controller.

    my only problem is interface camera with micro-controller.  i don't know which controller suitable to interface with Camera.

   how to interface camera to TI Controller.any one help me our company start with 3students.

   this is my my Email-ID- dineshece203@gmail.com

Dinesh,

This document will teach you how to use cameras with a Tiva:

http://www.ti.com/lit/pdf/tiduc98 

Again, you may want to consider a simpler MCU (or even a second Tiva) for the rest of your processing, and have a dedicated one for the imaging. Of course, how much processing you will need depends on what your product will do - and I believe you should put up some testing hardware to evaluate.

Regards

Bruno

Dinesh Kumar Shanmugam said:

1.Driver Activists monitoring using Camera module

2.GPS,GSM/GPRS and RFiD is no problem to interface with Micro -     my only problem is interface camera with Micro.      I don't know which controller suitable to interface with Camera.  

That's a far improved description of your requirements - surely "sharpens your thinking" - while greatly assisting your "helpers."

MCUs - by their nature - are amazingly flexible - and may be "coerced" (forced against their (natural) will) into doing many things - some "outside their designer's intent!      Yet - one must ask - how much is (necessarily) "lost" in that (sometimes tortured) process?      And - might a "better, NATURAL way" - exist?

(tightrope walk continues...)

An MCU which was "designed from the start to support the "known" camera interface standard would prove best - is that not so?     That "standard" is the Digital Camera Interface (DCMI). 

It would seem then - that your "MCU Selection" - would benefit greatly from your choosing an MCU,  "naturally equipped with that (DCMI) camera interface." 

Here is presented a "true copy" from the spec sheet of an MCU - perhaps better suited to your "camera" task.       

"The devices embed a camera interface that can connect with camera modules and CMOS sensors through an 8-bit to 14-bit parallel interface, to receive video data. The camera interface can sustain a data transfer rate up to 54 Mbyte/s in 8-bit mode at 54 MHz. It features:

• Programmable polarity for the input pixel clock and synchronization signals
• Parallel data communication can be 8-, 10-, 12- or 14-bit
• Supports 8-bit progressive video monochrome or raw bayer format, YCbCr 4:2:2
progressive video, RGB 565 progressive video or compressed data (like JPEG)
• Supports continuous mode or snapshot (a single frame) mode
• Capability to automatically crop the image"

Note that such is achieved via substantial, dedicated hardware - built right into (that) MCU.      As your "only problem" is that of camera interface - should not such "greatly focused, camera interface & efficient accommodation - "ping your radar?"      Can the "alternatives" - earlier presented - come (even) "close" to the performance & "feature mix" - listed above?

It is said (often) that the "tool best suited for the job" is likely to produce the "best job!"       While "Speeding, Easing, Enhancing" your team's development efforts!

Proper identification of "best practice" - assisted greatly by a "proper component survey" - greatly "eases & enhances" the results of those here.     (selection w/out adequate "awareness" (i.e. Search effort)  - not so much...)