Fuel Economy, Hypermiling, EcoModding News and Forum - EcoModder.com - View Single Post

ishiyakazuo · 08-18-2008, 10:37 AM

Hi, thanks for responding.
The issue is that if you throw it on a scope, it definitely won't be exactly 10400 baud because your calculations are just approximations.
To guarantee a consistent baud rate on a CPU running at such a slow speed, you need to use the hardware baud rate generator.
I've done plenty of protocol projects (such as monitoring an I2C bus I wasn't talking on) and I couldn't keep up when it was written mostly in ASM, on a 50MHz ARM7, and the I2C bus was only talking at 5-10kHz (about the same time as this one). iso_read_byte() definitely will have some issues in keeping up.
The bottom line is, even to talk to an ELM, you're going to need a consistent baud rate, and you will need to listen and talk simultaneously (the reason RS232 has Rx and Tx). You can't implement these things in software -- it's just not possible.
For debug, you're going to need to rely on the 2x16 LCD to print out some info at this point, I think. The data will be limited, but you don't really have much choice as far as interfacing goes. The other choice for debug is to make a debug bus (maybe hook up another CPU to get another serial port, and make the two CPUs talk?)
Your calculation just doesn't seem to take into account the fact that a message can come to you at any time -- on serial busses there's framing on bytes as well as bits, and that doesn't look like that will be adhered to with all these function calls being made. Using the hardware RS232 fixes this.

Read again the page you linked to early on: prj.perquin.com says that you have to send 0x33 at 5 baud, then send the payload c1 33 f1 81 66 at 10400 baud to get a response. (You should be waiting for response 83 f1 01 c1 e9 8f ae). Waiting for a response that wasn't asked for may be a big problem you're facing as well

For CAN, you might want to check out the AT90CAN series Atmel CPUs. It seems like it may be fairly software compatible with a good portion of the Arduino's ATMega. But in order to get the project done quick, yeah, use the ELM327. (My car is ISO, so I'm interested in getting the ISO stuff working, personally.

)

08-18-2008, 10:37 AM	#126 (permalink)
ishiyakazuo Test Tool Engr. Join Date: Aug 2008 Location: Elgin, IL, USA Posts: 47 Red Rocket - '02 Honda Civic LX Sedan 90 day: 33.57 mpg (US) Bronze Bucket - '98 Toyota Corolla VE 90 day: 34.97 mpg (US) Silver Bullet - '06 Hyundai Sonata GL 90 day: 31.58 mpg (US) Thanks: 0 Thanked 0 Times in 0 Posts	Hi, thanks for responding. The issue is that if you throw it on a scope, it definitely won't be exactly 10400 baud because your calculations are just approximations. To guarantee a consistent baud rate on a CPU running at such a slow speed, you need to use the hardware baud rate generator. I've done plenty of protocol projects (such as monitoring an I2C bus I wasn't talking on) and I couldn't keep up when it was written mostly in ASM, on a 50MHz ARM7, and the I2C bus was only talking at 5-10kHz (about the same time as this one). iso_read_byte() definitely will have some issues in keeping up. The bottom line is, even to talk to an ELM, you're going to need a consistent baud rate, and you will need to listen and talk simultaneously (the reason RS232 has Rx and Tx). You can't implement these things in software -- it's just not possible. For debug, you're going to need to rely on the 2x16 LCD to print out some info at this point, I think. The data will be limited, but you don't really have much choice as far as interfacing goes. The other choice for debug is to make a debug bus (maybe hook up another CPU to get another serial port, and make the two CPUs talk?) Your calculation just doesn't seem to take into account the fact that a message can come to you at any time -- on serial busses there's framing on bytes as well as bits, and that doesn't look like that will be adhered to with all these function calls being made. Using the hardware RS232 fixes this. Read again the page you linked to early on: prj.perquin.com says that you have to send 0x33 at 5 baud, then send the payload c1 33 f1 81 66 at 10400 baud to get a response. (You should be waiting for response 83 f1 01 c1 e9 8f ae). Waiting for a response that wasn't asked for may be a big problem you're facing as well For CAN, you might want to check out the AT90CAN series Atmel CPUs. It seems like it may be fairly software compatible with a good portion of the Arduino's ATMega. But in order to get the project done quick, yeah, use the ELM327. (My car is ISO, so I'm interested in getting the ISO stuff working, personally. )