View Single Post
  #187  
Old 08-22-2007, 12:59 AM
Nomake Wan's Avatar
Nomake Wan Nomake Wan is offline
Retired
 
Join Date: Jan 2007
Location: Orange, CA
Posts: 1,031
Send a message via AIM to Nomake Wan Send a message via MSN to Nomake Wan Send a message via Yahoo to Nomake Wan Send a message via Skype™ to Nomake Wan
Now sadly I don't know enough about the hardware we're dealing with to be 100% sure about my translation of the final paragraph. But HOLY CRAP GUYS, YOU HAVE TO READ IT!!! IT'S AMAZING!!!!! Maybe this will solve the problems with the feedback coming in so slowly!!


Quote:
Originally Posted by Kashima-san
I analyzed the communication processing routine, but I couldn't find something like "read command" or "write command" in it. Most likely, the [functional? while-running?] engine data is directly read from the program's work area.

It appears that there's a default binary-mode communication format, but that an ASCII format also exists. In ASCII mode, the baud rate is CLOCK / 832 (4808.9 bps), whereas in Binary mode it's CLOCK / 2048 (1953.6 bps). Furthermore, The CPU clock speed is 8.0020 MHz. Now, while ASCII mode is 8 Bit Data, 1 Stop Bit, and No Parity, Binary mode is 8 Bit Data, 1 Stop Bit, and Even Parity.

In the Legacy and Impreza's case, it takes 1024 microseconds for one cycle of an interrupt processing call once it has a call from the communication processing routine. I am switching from the default binary mode to the ASCII mode for changing the values of data in the memory addresses containing the work area. When switching to ASCII mode the baud rate changes, but when it comes time to switch back to binary mode the baud rate does not return to normal. If I switch once and immediately go back to binary mode, then I can effectively increase the baud rate of binary mode. This being so, then even in Binary mode the UART's baud rate setting should be able to be manipulated directly all the way up to something like 9600 bps. The end of the command is identified from the head of the received data, so when the "regulation amount" data is received the command "raises an event."
EDIT: I thought about that some. It makes sense. Also, it should be noted that the TCU does NOT have an ASCII interpretation mode. How do I know? Look at the command that Kashima-san gives for "STOP" in ASCII mode. On the ECU, that works even when receiving binary data (I've just typed "12" into the comm tool and it stopped the stream). On the TCU, sending it only "12" has NO effect at all. You have to type "12000000" for it to stop. So I guess the ECU is the only computer in the car with an alternate mode... which means it's probably the only one we can mess around with the baud rate on.

EDIT2: A friend of mine offered to take a look at what I've got and try to figure something out with me. He's pretty good with electronics, so we might be able to find something out.

Last edited by Nomake Wan; 08-22-2007 at 01:50 AM.
Reply With Quote