ECUFlash - Getting close!

[nelsmar]

Originally Posted by jamesm

They're not fast enough. Trust me. I tried it.

Originally Posted by vgi

interesting, according to this

it's nxp arm7 60 MHz 32 bit microprocessor, which should be fairly fast.

i'm thinking if kill $25 cable i wouldn't be as disappointed as killing $170 cable

Yes they have a fast CPU. And so does your desktop computer. However calculating complex math formulas is a bitch with MS Calculator.

It really comes down to how it was programmed, and a lot of these cables out there such as the ELM327 will take your request, format it, send it, receive it, process it, and give you data back. This all has to be programmed. Sometimes people use inefficient code, sometimes they are processing the data vas just passthrough. Sometime its just such horrible code it runs slow as can be. And sometimes they have them set on a timer to send a request every so many seconds and buffer etc.

Sure the TJA1050 has the abillity to run at 500K connection speed when using ISO15765 connections... but that doesnt mean the cpu was designed to poll efficiently. You don't need a ton of CPU power to poll data and pass through. The common issue with the Chinese cables is that they are constantly made with "hacked up" firmwares with half assed code, or half-attempted reverse engineered code from other cables. Some of them are buggy, some of them arent. Its hit and miss.

There is a series of KLine based cables that will let you poll and I imagine they will let you do the fast poll in romraider (i have never used rom raider so sorry if im off a bit) which lets you poll quickly w/ pass through.

The ELM series sends a PID request and awaits a response, then sends the next one, and the next one... once it gets all its PID's responded to it will start the cycle over.

However using SSM over KLine / 15765 you can send a list of memory points to ask for and tell it to repeat indefinitely. The ECU will respond with the values of these memory spaces as quick as the ECU is either programed to, or to the bus speed. And if you have a poorly optimized code set that is translating the data, you will get a nice bottle neck. However if all of the code is being done in romraider for translation etc and the Kline cables are being 100% pass through (note the mention of pass through multiple times here!) then you can have less bottlenecks holding you back.




Thanks everyone for the links / info, ill read more when i catch up on this project at the office. After that ill try experimenting again. I am curious to see how much I can get out of this little 16mhz atmega 328. But I'll be ordering a higher 40+mhz PIC or ARM cpu as a backup this weekend. I am more concerned with me writing data to my display and SD card than the actual polling rate. As long as the math is done with efficiency in mind you should be able to poll quite a bit using a slower CPU. It sucks I used some CAN code for sending raw 15765 data to test and it kept causing a weird issue with my car and tossing a connection error CEL. I then found out after scanning every last line that the original dev put a small comment block mentioning he had math logic programmed for a 20MHz clock... -.- No wonder I was having issues. *sigh*. Ill probably just write something from scratch so that way I don't waste my time again.

And it was mentioned patching the ECU, does anyone have any info or even posts that even mention something like this that I could read? I saw something on the RR forums about patching for higher speed, but I don't know if it was simply to send read request, or if it was for extended, or just purely for performance.

Thanks for the help guys!

[jamesm]

Originally Posted by nelsmar

Yes they have a fast CPU. And so does your desktop computer. However calculating complex math formulas is a bitch with MS Calculator.

It really comes down to how it was programmed, and a lot of these cables out there such as the ELM327 will take your request, format it, send it, receive it, process it, and give you data back. This all has to be programmed. Sometimes people use inefficient code, sometimes they are processing the data vas just passthrough. Sometime its just such horrible code it runs slow as can be. And sometimes they have them set on a timer to send a request every so many seconds and buffer etc.

Sure the TJA1050 has the abillity to run at 500K connection speed when using ISO15765 connections... but that doesnt mean the cpu was designed to poll efficiently. You don't need a ton of CPU power to poll data and pass through. The common issue with the Chinese cables is that they are constantly made with "hacked up" firmwares with half assed code, or half-attempted reverse engineered code from other cables. Some of them are buggy, some of them arent. Its hit and miss.

There is a series of KLine based cables that will let you poll and I imagine they will let you do the fast poll in romraider (i have never used rom raider so sorry if im off a bit) which lets you poll quickly w/ pass through.

The ELM series sends a PID request and awaits a response, then sends the next one, and the next one... once it gets all its PID's responded to it will start the cycle over.

However using SSM over KLine / 15765 you can send a list of memory points to ask for and tell it to repeat indefinitely. The ECU will respond with the values of these memory spaces as quick as the ECU is either programed to, or to the bus speed. And if you have a poorly optimized code set that is translating the data, you will get a nice bottle neck. However if all of the code is being done in romraider for translation etc and the Kline cables are being 100% pass through (note the mention of pass through multiple times here!) then you can have less bottlenecks holding you back.




Thanks everyone for the links / info, ill read more when i catch up on this project at the office. After that ill try experimenting again. I am curious to see how much I can get out of this little 16mhz atmega 328. But I'll be ordering a higher 40+mhz PIC or ARM cpu as a backup this weekend. I am more concerned with me writing data to my display and SD card than the actual polling rate. As long as the math is done with efficiency in mind you should be able to poll quite a bit using a slower CPU. It sucks I used some CAN code for sending raw 15765 data to test and it kept causing a weird issue with my car and tossing a connection error CEL. I then found out after scanning every last line that the original dev put a small comment block mentioning he had math logic programmed for a 20MHz clock... -.- No wonder I was having issues. *sigh*. Ill probably just write something from scratch so that way I don't waste my time again.

And it was mentioned patching the ECU, does anyone have any info or even posts that even mention something like this that I could read? I saw something on the RR forums about patching for higher speed, but I don't know if it was simply to send read request, or if it was for extended, or just purely for performance.

Thanks for the help guys!

i'm pretty sure the patches open up direct access to the parameters, i.e. straight from ram.

[StormTrooper]

Simple questions from a semi literate user, no programming knowledge.

How is the compatibility of ecuflash and RR with a 64bit OS?

2-3 years ago logging and flashing was a real pita unless you had a copy of xp and laptop segregated from the net for 10 years.

Trying to log with my lc1 only made it impossible.


Thanks,
Matt

[Td-d]

Originally Posted by StormTrooper

Simple questions from a semi literate user, no programming knowledge.

How is the compatibility of ecuflash and RR with a 64bit OS?

As long as you are running 32bit Java, you will be fine.

[Td-d]

Originally Posted by jamesm

i'm pretty sure the patches open up direct access to the parameters, i.e. straight from ram.

Straight from the release notes for the Ecuflash beta that enables the CAN logging:

Support for fast RAM parameters on Subaru CAN vehicles (assuming ROM patch has been made). just use the known RAM parameter ID (0xFFxxxx) and the OP2 will do the rest. reading of multibyte RAM parameters is sped up by the ROM patch which allow reading up to 4 bytes with a specially encoded 3-byte parameter request. due to current Subaru output buffer limitations, only 80 bytes can be returned in a single request, so only 20 4-byte params can be read at a time. i will make some changes to the OP2 firmware in the future to issue multiple requests to overcome this 80-byte of data limit.

[StormTrooper]

Originally Posted by Td-d

As long as you are running 32bit Java, you will be fine.

So no then....

i could never get both to like 32bit java with win7 and have the lc1 log....

[Td-d]

Originally Posted by StormTrooper

So no then....

i could never get both to like 32bit java with win7 and have the lc1 log....

That's odd - I have a netbook running win 7 and I use the MTX (successor to the LC1) - and I never had problems logging.

[StormTrooper]

It's been nearly two years but I remember that while I could get the lc1 to log using whatever software it came with it could not be recognized by RR. When I got that to work semi ok by messing with java and other things ecuflash would stop working......

[Td-d]

There's been quite a lot of work done on RR in the past two years, including plugins - would be worth a try once the next logging enabled beta is out.

[nelsmar]

So I did a little bit of reading on J2534. This protocol is simply a standardization for cables. It says that a specific connector should be used, and each connector should support the different CAN protocols in the specifications. All vehicles must use one of these protocols. All vehicles must have this plug. All cables must use this plug. All cables must have a windows DLL file that will let you use the pre-specified J2534 API functions such as Connect to ISO9141 Can network. Apply voltage, etc.

Basically it just means you can buy 1 cable and it should plug into all 2006(iirc) or newer vehicles and regardless if they use Kline, or whatever based communication method that one cable will let you simply say "connect with xxxx protocol" and it will connect. Previously each manufacture had custom cables and it was a mess for repair shops to have to buy so many cables.

I actually have all the parts to build a J2534 cable that could be used with RR and everything else, but at this time it wasn't what i was aiming for. But im glad I finally read into what that standard was for!

This also explains why the Chinese cables are so hit or miss. They are just trying to get most of the protocol for specifically allowing connection, and packet transfer. However they are still responsible for communicating with the ECU, buffering data, and sending it back. Knowing the Chinese market... they probably don't put so much time into making sure their cable & dll are performance made. I haven't read into performance requirements in what is needed. However I did find some code someone started for making an open source passthrough cable.

As I am working on a hardware logger I don't need to make something that is J2534 compliant. As my software would be sending my "passthrough" messages directly from my hardware, not a PC. The J2534 is just designed to allow you to send data over a network. And as I don't need something to bridge my hardware to the ECU it doesn't fully apply to me.

Thank god. lol I was starting to wonder if I was going to need to code/fabricate yet another layer into my tool.

[nelsmar]

For anyone interested in reading more about J2534 here are some API methods:

http://www.drewtech.com/support/J2534/index.html

And an article explaining some of J2534:
http://www.kvaser.com/zh/about-can/r...ndards/51.html

[nelsmar]

Although now I am interested and half tempted to order an Amtel 32u4 based protoboard and see if I can hack up a quick pass through cable that ecuflash & romraider could use. Ideally I think that processor @ 16mhz would be quick enough for most of the processing...

[nelsmar]

One more thing to add onto these Chinese cables. You want to know why they are sooooo fast? Because ARM has a series of processors that have built in digital can bus. PIC also has a few units with built in CAN bus as well. In fact one of the new Arduino spec's has included one of these ARM processors with it. They included it so they can communicate in "harsh" environments. CAN communications are designed to work in environments where there may be lots of RF interference, voltage changes, and other bits that can mess with communications. This can be apealing for a number of other markets so some ARM manufactures started adding in this technology to their processors.

So you can either

A) do what i did which was get a cheap micro, then get a can bus micro, then get a can bus transceiver (translates the voltage to a digital digital signal).
B) Purchase a micro with a built in can bus controller.

The processors with the built in controllers are really not much more money. And typically are actually cheaper than buying all 3 chips. This also allows you to solder less, use less PCB, and have awesome marketing information to brag about stating you have a high speed processor. We all know that goes with marketing... So the processor is worthless, not needed, and is only there due tot he connivence of the processor.

I actually almost bought one of the ARM based proto boards just because it had a built in CAN controller, and may in fact do that down the road because really they are quite cheap, and make fabrication a lot easier since it removes an entire chip from my build!


I figured I would just in more info since when I was reading and trying to learn I really couldn't find jack SHIT on information on any of this. Its kind of a grey area where no one seem's to share much information. And the fact that the full spec's for J2534 costs money... that isn't helping anyone.

[xjohnx]

Originally Posted by nelsmar

I actually almost bought one of the ARM based proto boards just because it had a built in CAN controller, and may in fact do that down the road because really they are quite cheap, and make fabrication a lot easier since it removes an entire chip from my build!

Pardon my ignorance, but what kind of things could you make with this?