what pic should i use?

[skimask]

Hello!

I'm developing a kind of onboard's car computer and i need to continually measure 3 analog signals (fuel, oxygen sensor, temp.) and one freq. signal (speed sensor). I would like to show all data in an 20x4 LCD. In your opinion, what pic should i use? Is 16f676 a good choice? Any other?

Thanks in advance.

Sylvio

Use the ELM327 from www.elmelectronics.com. It's a PIC18F2550.

[sirvo]

skimask.. i have read stuffs about elm327 but i am not sure about using it.
i know that elm can interface the iso9141 obdII protocol, but, does it send all the info. that I need? For example.. i would like to read the fuel sensor, so, do i need just to send a command and it answers to me the value?

Thanks !

Sylvio

editing... i will read the datasheet.. thanks again

[skimask]

skimask.. i have read stuffs about elm327 but i am not sure about using it.
i know that elm can interface the iso9141 obdII protocol, but, does it send all the info. that I need? For example.. i would like to read the fuel sensor, so, do i need just to send a command and it answers to me the value?

Thanks !

Sylvio

editing... i will read the datasheet.. thanks again

It's all in the datasheet...all the values you could ever want, and a load of those you could never use.

[sirvo]

Hello skimask

I've just read the datasheet. The problem is to decode all the data. Do you know how to do that?

Thanks.

Sylvio

[skimask]

Hello skimask

I've just read the datasheet. The problem is to decode all the data. Do you know how to do that?

Thanks.

Sylvio

Decode what? The ELM327 does it all for you, spits out temperature, voltage, o2 sensor readings, etc. You have to do the research OBD-II and figure out what input values give you which output values. There's literally hundreds of them and I don't have the time to explain them here.

[sirvo]

Decode what? The ELM327 does it all for you, spits out temperature, voltage, o2 sensor readings, etc. You have to do the research OBD-II and figure out what input values give you which output values. There's literally hundreds of them and I don't have the time to explain them here.

Hi. when I said "decode", i mean just what you said about what input values should i send to receive what i want. I have read a lot about obdII codes and i got nothing about iso 9141 protocol and what received "bytes" mean..

thanks skimask for helping...

Sylvio

[skimask]

Hi. when I said "decode", i mean just what you said about what input values should i send to receive what i want. I have read a lot about obdII codes and i got nothing about iso 9141 protocol and what received "bytes" mean..

thanks skimask for helping...

Sylvio

ISO9141 is only an 'electrical' specification, as is J1850 and CAN, at least as far as the ELM327 is concerned (I know they are actually much more than that, but it doesn't matter at the moment). For example, when you send (in ASCII) '01 05' with a CR/LF at the end to the ELM327, the ELM327 (assuming it has already set itself up with the correct protocol) will send back a few bytes in ASCII, an example reply is '41 05 7B' (7B is an example in this case, could be anything). 41 signifies the same mode you asked for but with $40 added to it, 05 is the PID number, and 7B is the data value, all in byte wide HEX-ASCII. According to the OBDII standard, mode 01-PID 05 retrieves engine coolant temp. To get the actual coolant temp, convert 7B to decimal, 123 and (again, according to the OBDII standard) subtract 40, result = 83. Just like the ELM327 datasheet says.

So, it doesn't matter to the end user if the ELM327 is connected to an ISO9141 vehicle, a J1850-PWM, J1850-VPW, or one of the various C.A.N. mode vehicles, the inputs and the outputs are relatively the same (CAN is a little bit different but only in the byte formatting as explained in the datasheet).

If, what you are asking, is how the signals in an ISO9141 vehicle (or any OBDII compliant vehicle) are formatted in respect to timing, voltage levels, etc? Again, I don't have the time to explain it. It's quite complicated for all of those protocol's and this is one of those cases where I'd rather spend the $40USD for the interface chip instead of writing my own code.

If, however, all you want to do is read the O2 sensors (which you'll most likely need a small amplifier for since an O2 sensor only outputs at most a volt maybe a bit more, and as you may or may not know is not steady but is used by the computer as an overall 'average' of a sort), the average duty cycle of the fuel injectors (which won't do you any good without knowing what the pressure differential between the fuel rail and the intake manifold is to get any kind of accurate flow rate, then you'll have to figure out what kind of lag time there is between the injector open signal and the injector actually opening and the same thing for closing and then coorelate that with system voltage), and temperature (whether it's air temperature or coolant temperature, doesn't matter, it's very iffy at best since the resistance curves from these thermistors isn't linear at all and is very steep and would most likely take quite awhile to plot a table with useful data points to interpolate useful temperature values), (phew), then yes, a PIC16F676 will do in a minimalist system (no buttons, no nothing etc). Otherwise, I'd go with a PIC18F2520, or one of the other 28 pin 18F models.

[malc-c]

Ahh... but where's the fun in using a pre-programmed PIC. And Sylvio wouldn't lean much about PBP etc

Sylvio, I've just used a 16F676 in one project that the guys here helped me out with, and I'm sure they would all do the same if you chose to go down this route. The only limitation of using the 16F676 is the pin count. 6 of the 12 I/O pins available will be required for a normal 16X2 LCD in 4 bit mode, and without details on the 20 x 4 LCD you are intending to use, you may find it needs more, which would thus limit the number of pins left for your A/D inputs.