Hi All
I want to play around with the AVRs with Can interface.
To do this a converter from RS232 to Can would be verry interesting.
Unfortunatley I could not find a circuit on the internet.
Any help is apreciated.
Cheers
Rubi
RS232 to Can Adapter
Author
Message
Doing CAN to RS232 hardware wise is fairly straightforward. The software is a little trickier - do you want to send CAN messages or just receive them? Then there is the issue of making sense of the CAN data. If you know exactly what you're looking for makes the code a little easier. A bit of reading and searching should be able to give you some answers.
I think Mr Mic has some OBDII (Car interface thingy) , isn't that Can.
Search his homepage or the Academy
/Bingo
Kartman wrote:
Do you want to send CAN messages or just receive them?
I would like to do both.
About the software side, I can't say anything, before studying the specs.
Bingo600 wrote:
I think Mr Mic has some OBDII (Car interface thingy) , isn't that Can.
Is that can ?
Cheers
Rubi
Here is a great chance for someone to write a short 'white paper' for the freaks describing the current state of OBD... I think there are 3 sets of pins on the connector for Ford, GM, and Chrysler... and 3 different protocols! Ford uses VPW (variable pulse width?) GM uses J1850, Chrysler uses???. There is a feeeware obd program on simtel.com engineering section... search for 'engine analyzer' there. And recently a freak submitted a project to do J1850 on a mega8. This summarizes what I know so far. What I'd like to know: Can you read out miles per gallon on the obd? Or must you compute it from throttle angle, fuel pressure, and vehicle speed? And one other thing: can I read the engine controller rom from the obd to look at the hex dump and try to find the data tables for spark and fuel and whatnot to make myself a performance tuning expert?
Quote:
Is that can ?
No, it's not...
At least not yet. I have only one interface version ready to convert RS232 to SAE J1850 VPW. Next version will be RS232 to ISO9141/14230/KWP2000. CAN is planned for the future. I will try to implement all OBD protocol versions into AT90CAN128.
Quote:
I will try to implement all OBD protocol versions into AT90CAN128.
Do you think you will have enough code space & I/O pins? :) "When the only tool you have is a hammer, everything looks like a nail."
Lee
Now after reading Bob's posting... :D
Actual used protocols or standards for OBD are:
ISO9141/ISO14230/KWP2000 - most European cars
SAE J1850 VPW (yes, variable pulse width) and PWM (fixed pulse width) - most US cars, btw, my Chrysler uses J1850 VPW
ISO 11898/11519 CAN bus - most new vehicles (AFAIK should be OBD protocol standard for all cars from 2008 on)
Quote:
And recently a freak submitted a project to do J1850 on a mega8.
I think, I'm the freak :wink:
Quote:
Can you read out miles per gallon on the obd?
Not directly, but can be calculated if your car has a MAF (Mass Air Flow) sensor. Such project exist, based on AVR.
Quote:
And one other thing: can I read the engine controller rom from the obd to look at the hex dump and try to find the data tables for spark and fuel and whatnot to make myself a performance tuning expert?
Dump yes, but write no. All sensitive areas in ECUs are protected my challenge/respond key handshake. The ECU provides a seed and you must send the correct key to get access.
Quote:
Do you think you will have enough code space & I/O pins?
Of course :wink:
Because on AT90CAN128 I have most interface in hardware implemented.
I need one USART for ISO and one for RS232, then CAN hardware and some IO pins for interrupt driven J1850 VPW/PWM implementation. And the rest for some other features.
Code space is no problem, at least not for ISO and J1850.
Last Edited: Wed. Mar 16, 2005 - 05:23 PM
GM's J1850 is also known as VPW. Ford's PWM is also part of J1850. They are gradually converting to CAN as it is mandated by 2007. The Ford vehicles we work with (diesel pickups) went to CAN in 2003.
Dave Raymond
Take a look at : http://www.can232.com
pschober wrote:
Take a look at : http://www.can232.com
Hi pschober
Yes , that is exactly what I am looking for.
But I would prefer to build one myself, because
90 € for the board is a bit expensive.
Cheers
Rubi
hi mr MIC
avr for obd samples..!
plaese send.
Level: Raving Lunatic
Joined: Tue. Jun 22, 2004
Posts: 3839 View posts
Location: South West Utah, USA
Consider what is involved with a no protocol CAN to RS-232 converter. No protocol just means the raw CAN data is transferred between CAN and RS-232 without any idea or concept of any CAN protocol like device net, CANopen, etc.
Any CAN data frame would have an 11 bit or 29 bit message identifier and up to 8 bytes of data. In addition, the CRC error checking from the CAN protocol is hidden inside the CAN controller hardware. You would need to add your own RS-232 error checking to maintain data integrity and create a RS-232 protocol that allows you to recover the correct message identifier and correct number of data bytes on the other end of the RS-232 link. Since the CAN hardware waits for the entire data frame to finish before passing along the data, you would have to buffer the RS-232 input from the CAN. For example, if you get an 8 byte CAN data frame, than get another two 1 byte CAN data frames, the RS-232 might still be sending the original 8 byte message after the second 1 byte CAN message has been received. If the time it takes the CAN to receive a data frame of some number of bytes is shorter than the time it takes to send the same number of bytes on the RS-232, then you know you are going to accumulate CAN Rx data in a buffer waiting to be sent via RS-232. If the CAN data rate is non-stop (i.e. no extra idle time between CAN data frames), this buffer will just keep growing and growing until it probably overflows and data is lost. A faster RS-232 throughput than the CAN throughput is very desirable.
Do you want to include any RS-232 protocol for requesting and then transferring any CAN errors (i.e. the AVR CANREC and CANTEC error counters) through the RS-232 interface?
It would probably make sense to make any RS-232 data to be sent to the CAN node handshake controlled. As in send out data via RS-232 to the CAN Tx and wait for an affirmative acknowledge that the CAN Tx completed, before accepting any new RS-232 data to be sent by the CAN. Sending an acknowledge back to the RS-232 source would add complexity to the to the RS-232 protocol that sends the CAN Rx data and take additional time on the RS-232 link.
I do not know how the commercial CAN to RS-232 link was implemented, but I suspect it does not do high data rates at 1 mbps maximum CAN baud. If you want high speed CAN it would make more sense to do a USB to CAN converter with something like a high speed SPI interface between the USB and CAN chips. USB has the bandwidth to handle high CAN baud rates which will work if the USB chip is able to make use of enough of this bandwidth to keep up with a high speed CAN.