OpenSource ECM Project
06-23-2010, 11:27 AM
#1
Member
Thread Starter
Join Date: Jun 2010
Posts: 32
OpenSource ECM Project
Hi. I am interested in the idea of developing a substitute ECM for the Maxima. A side-project would be a Maxima-simulator device: plug an ECM into the simulator and it thinks it's driving down the road, not sitting on your desk. Could be used to test questionable ECMs...
I'm primarily focused on a32 4th gen Maxima, but the project could expand. The 4th gen seems a good place to start because of issues of cost, complexity, and availability (I own 2 and would consider trying to grab another at auction as my testing guinea pig).
I'm not interested in simple performance tweaks/tricks, which seem to consist mostly of hacking tables that reside in known memory locations, although that's a great starting point. Instead, I want to learn everything about the car's control software, and prove this knowledge by building a substitute ECM.
Architecture-wise, I am thinking:32-bit processor with tons of memory and I/O capacity, running Linux. All Open-Source software (probably all written in C). This would be a testing/learning/simulating rig; stock Linux takes too long to boot up to use in a real car. But it would yield the understanding needed for the next step, which is a standalone system running a lightweight RTOS or no OS at all, that could actually be used as a substitute ECM.
This is a fairly large project and it would be a part-time hobby effort. Right now I am scoping that effort. This would move along more quickly if I could reverse-engineer the stock ECM as much as possible. To do this I need as much "inside" information about the ECM hardware and software as I can find. I have only found a little bit so far.
I don't even know if this is legal. If you have any information, tips, or recommendations (books, sites, downloads, etc.), please advise. Also, If you know of any similar efforts underway, please let me know about them. And if you would be interested in working on this, let me know.
No scrap of info is too small.
Thanks.
I'm primarily focused on a32 4th gen Maxima, but the project could expand. The 4th gen seems a good place to start because of issues of cost, complexity, and availability (I own 2 and would consider trying to grab another at auction as my testing guinea pig).
I'm not interested in simple performance tweaks/tricks, which seem to consist mostly of hacking tables that reside in known memory locations, although that's a great starting point. Instead, I want to learn everything about the car's control software, and prove this knowledge by building a substitute ECM.
Architecture-wise, I am thinking:32-bit processor with tons of memory and I/O capacity, running Linux. All Open-Source software (probably all written in C). This would be a testing/learning/simulating rig; stock Linux takes too long to boot up to use in a real car. But it would yield the understanding needed for the next step, which is a standalone system running a lightweight RTOS or no OS at all, that could actually be used as a substitute ECM.
This is a fairly large project and it would be a part-time hobby effort. Right now I am scoping that effort. This would move along more quickly if I could reverse-engineer the stock ECM as much as possible. To do this I need as much "inside" information about the ECM hardware and software as I can find. I have only found a little bit so far.
I don't even know if this is legal. If you have any information, tips, or recommendations (books, sites, downloads, etc.), please advise. Also, If you know of any similar efforts underway, please let me know about them. And if you would be interested in working on this, let me know.
No scrap of info is too small.
Thanks.
06-23-2010, 11:42 AM
#3
Look at the FSM diagram of the ecu pin out to see how it controls everything. It is quite complicated.
It might be easier just to get a standalone, or work with the people to get the daughter boards working with out ecu's. (ie, nistune or bikiboards)
It might be easier just to get a standalone, or work with the people to get the daughter boards working with out ecu's. (ie, nistune or bikiboards)
06-23-2010, 12:50 PM
#4
![[s3]'s Avatar](data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 50 50'><circle class='avatar-circle-default' fill='%23986ec4' cx='25px' cy='25px' r='20px'></circle><text class='avatar-text-default' x='49%' y='53%' fill='white' text-anchor='middle' alignment-baseline='middle'>[</text></svg>)
Hi. I am interested in the idea of developing a substitute ECM for the Maxima. A side-project would be a Maxima-simulator device: plug an ECM into the simulator and it thinks it's driving down the road, not sitting on your desk. Could be used to test questionable ECMs...
I'm primarily focused on a32 4th gen Maxima, but the project could expand. The 4th gen seems a good place to start because of issues of cost, complexity, and availability (I own 2 and would consider trying to grab another at auction as my testing guinea pig).
I'm not interested in simple performance tweaks/tricks, which seem to consist mostly of hacking tables that reside in known memory locations, although that's a great starting point. Instead, I want to learn everything about the car's control software, and prove this knowledge by building a substitute ECM.
Architecture-wise, I am thinking:32-bit processor with tons of memory and I/O capacity, running Linux. All Open-Source software (probably all written in C). This would be a testing/learning/simulating rig; stock Linux takes too long to boot up to use in a real car. But it would yield the understanding needed for the next step, which is a standalone system running a lightweight RTOS or no OS at all, that could actually be used as a substitute ECM.
This is a fairly large project and it would be a part-time hobby effort. Right now I am scoping that effort. This would move along more quickly if I could reverse-engineer the stock ECM as much as possible. To do this I need as much "inside" information about the ECM hardware and software as I can find. I have only found a little bit so far.
I don't even know if this is legal. If you have any information, tips, or recommendations (books, sites, downloads, etc.), please advise. Also, If you know of any similar efforts underway, please let me know about them. And if you would be interested in working on this, let me know.
No scrap of info is too small.
Thanks.
I'm primarily focused on a32 4th gen Maxima, but the project could expand. The 4th gen seems a good place to start because of issues of cost, complexity, and availability (I own 2 and would consider trying to grab another at auction as my testing guinea pig).
I'm not interested in simple performance tweaks/tricks, which seem to consist mostly of hacking tables that reside in known memory locations, although that's a great starting point. Instead, I want to learn everything about the car's control software, and prove this knowledge by building a substitute ECM.
Architecture-wise, I am thinking:32-bit processor with tons of memory and I/O capacity, running Linux. All Open-Source software (probably all written in C). This would be a testing/learning/simulating rig; stock Linux takes too long to boot up to use in a real car. But it would yield the understanding needed for the next step, which is a standalone system running a lightweight RTOS or no OS at all, that could actually be used as a substitute ECM.
This is a fairly large project and it would be a part-time hobby effort. Right now I am scoping that effort. This would move along more quickly if I could reverse-engineer the stock ECM as much as possible. To do this I need as much "inside" information about the ECM hardware and software as I can find. I have only found a little bit so far.
I don't even know if this is legal. If you have any information, tips, or recommendations (books, sites, downloads, etc.), please advise. Also, If you know of any similar efforts underway, please let me know about them. And if you would be interested in working on this, let me know.
No scrap of info is too small.
Thanks.
But good luck re-inventing the wheel.
06-23-2010, 01:05 PM
#5
And what would make this not legal - he is not planning on using any of the proprietary software from the ECU, nor does he plan to use the hardware of the ECU.
I see nothing illegal about this venture.
I however see some complications in the process - but can offer some 'advice on this'
You will need RTL (Real Time Linux) - you'll need at least a 2GB/s transfer rate board (hmm lets think about that - Dell Mini 10 would do the trick) AND you would need to create a 'harness' to USB adaptor - the other option is a desktop with an old serial port (24 pin Printer type) (course that would not be on any of the newer 'fast enough' boards.)
If you get such a beast built - I'd be interested in doing testing for you with my 99 Maxima.
I see nothing illegal about this venture.
I however see some complications in the process - but can offer some 'advice on this'
You will need RTL (Real Time Linux) - you'll need at least a 2GB/s transfer rate board (hmm lets think about that - Dell Mini 10 would do the trick) AND you would need to create a 'harness' to USB adaptor - the other option is a desktop with an old serial port (24 pin Printer type) (course that would not be on any of the newer 'fast enough' boards.)
If you get such a beast built - I'd be interested in doing testing for you with my 99 Maxima.
06-23-2010, 02:08 PM
#6
And what would make this not legal - he is not planning on using any of the proprietary software from the ECU, nor does he plan to use the hardware of the ECU.
I see nothing illegal about this venture.
I however see some complications in the process - but can offer some 'advice on this'
You will need RTL (Real Time Linux) - you'll need at least a 2GB/s transfer rate board (hmm lets think about that - Dell Mini 10 would do the trick) AND you would need to create a 'harness' to USB adaptor - the other option is a desktop with an old serial port (24 pin Printer type) (course that would not be on any of the newer 'fast enough' boards.)
If you get such a beast built - I'd be interested in doing testing for you with my 99 Maxima.
I see nothing illegal about this venture.
I however see some complications in the process - but can offer some 'advice on this'
You will need RTL (Real Time Linux) - you'll need at least a 2GB/s transfer rate board (hmm lets think about that - Dell Mini 10 would do the trick) AND you would need to create a 'harness' to USB adaptor - the other option is a desktop with an old serial port (24 pin Printer type) (course that would not be on any of the newer 'fast enough' boards.)
If you get such a beast built - I'd be interested in doing testing for you with my 99 Maxima.
"This would move along more quickly if I could reverse-engineer the stock ECM as much as possible."
Unfortunately without reverse engineering the stock ECM, he wouldn't know where to start. Unless he is a genius and can write code out of nowhere and program a substitute ECM to interface fully with the car.
It's like almost trying to write a PS3 Emulator.
Good luck.
06-23-2010, 02:16 PM
#7
A custom tuned ecu cheaper and more widely available than the ts/jet ecus or emanage would be huge on this forum and considering some of the backgrounds a lot of us come from I know that the potential is here. Let's just face it, probably at least a third of ourselves consider ourselves computer junkies.
This could be largely irrelevant but on avic411.com in the f series hacks section a member known as eegeek started a project to use our f series head units (wince) as tuning and diagnkostic tools... The project took off for a while and some versions of the software were released but he did not want to have to make interface changes for every type of vehicle and the like... Im suere This had been abandoned by now I'm sure but his sources and what not are still around, also he seemed very knowledgeable about the inner workings of tuning and software hardware interface. The original thread is something like obd-ii scanner interface?
Ninja edit: make sure to make contact with eegeek, he's a very knowledgeable member of the forum and I don't just mean knowledgeable in windows ce programming, he's also a tuner professionally.
Back on topic, this would be a fantastic thing to have for these vehicles and could allow for much improvement over our pricey run of the mill tuning systems..
If I can help in any way of course I will.
This could be largely irrelevant but on avic411.com in the f series hacks section a member known as eegeek started a project to use our f series head units (wince) as tuning and diagnkostic tools... The project took off for a while and some versions of the software were released but he did not want to have to make interface changes for every type of vehicle and the like... Im suere This had been abandoned by now I'm sure but his sources and what not are still around, also he seemed very knowledgeable about the inner workings of tuning and software hardware interface. The original thread is something like obd-ii scanner interface?
Ninja edit: make sure to make contact with eegeek, he's a very knowledgeable member of the forum and I don't just mean knowledgeable in windows ce programming, he's also a tuner professionally.
Back on topic, this would be a fantastic thing to have for these vehicles and could allow for much improvement over our pricey run of the mill tuning systems..
If I can help in any way of course I will.
Last edited by FallenOne; 06-24-2010 at 07:24 PM.
06-23-2010, 02:23 PM
#8
Guess you missed this part
"This would move along more quickly if I could reverse-engineer the stock ECM as much as possible."
Unfortunately without reverse engineering the stock ECM, he wouldn't know where to start. Unless he is a genius and can write code out of nowhere and program a substitute ECM to interface fully with the car.
It's like almost trying to write a PS3 Emulator.
Good luck.
"This would move along more quickly if I could reverse-engineer the stock ECM as much as possible."
Unfortunately without reverse engineering the stock ECM, he wouldn't know where to start. Unless he is a genius and can write code out of nowhere and program a substitute ECM to interface fully with the car.
It's like almost trying to write a PS3 Emulator.
Good luck.
Obvioussly he will have to do his Own tinkering but low and behold I doubt jwt and ts just called up Nissan and said hey there send me over all the needed information to hack your ecus.
I just want you to stop being a buzz kill, if you feel like responding do it via PM I do not wish to be responsible for getting this thread locked.
Like I said let's see what others think and what can be done.
06-23-2010, 02:33 PM
#9
Just sit back and watch, theres no reason to try to destroy a project before it begins because you want to be right, and prove how smart you are.
Obvioussly he will have to do his Own tinkering but low and behold I doubt jwt and ts just called up Nissan and said hey there send me over all the needed information to hack your ecus.
I just want you to stop being a buzz kill, if you feel like responding do it via PM I do not wish to be responsible for getting this thread locked.
Like I said let's see what others think and what can be done.
Obvioussly he will have to do his Own tinkering but low and behold I doubt jwt and ts just called up Nissan and said hey there send me over all the needed information to hack your ecus.
I just want you to stop being a buzz kill, if you feel like responding do it via PM I do not wish to be responsible for getting this thread locked.
Like I said let's see what others think and what can be done.
06-23-2010, 02:46 PM
#10
Ever looked into romraider? Here's what a lot of subus have been playing with.
http://www.clubwrx.net/forums/tuning...r-tactrix.html
http://www.clubwrx.net/forums/tuning...r-tactrix.html
06-23-2010, 04:45 PM
#11
Just sit back and watch, theres no reason to try to destroy a project before it begins because you want to be right, and prove how smart you are.
Obvioussly he will have to do his Own tinkering but low and behold I doubt jwt and ts just called up Nissan and said hey there send me over all the needed information to hack your ecus.
I just want you to stop being a buzz kill, if you feel like responding do it via PM I do not wish to be responsible for getting this thread locked.
Like I said let's see what others think and what can be done.
Obvioussly he will have to do his Own tinkering but low and behold I doubt jwt and ts just called up Nissan and said hey there send me over all the needed information to hack your ecus.
I just want you to stop being a buzz kill, if you feel like responding do it via PM I do not wish to be responsible for getting this thread locked.
Like I said let's see what others think and what can be done.
06-23-2010, 06:08 PM
#12
legal ? well its your car you can do what you want to it. if your trying to resell intellectual property then yes its illegal. If you build a cpu from the ground up without using any of nissans patents then im sure its fine....
06-23-2010, 09:05 PM
#13
http://forums.maxima.org/4th-generat...addresses.html
Id say start reading.. I forgot someone already attempted some of this.
Id say start reading.. I forgot someone already attempted some of this.
06-23-2010, 11:56 PM
#14
http://forums.maxima.org/4th-generat...addresses.html
Id say start reading.. I forgot someone already attempted some of this.
Id say start reading.. I forgot someone already attempted some of this.
06-24-2010, 12:20 AM
#16
06-24-2010, 08:36 AM
#17
No, I'm pretty sure it works with out ecu's. Whether he shipped it or not is another story. But these boards do work with the Jap/Aus version of our ECU so I do believe they will work with ours.
06-24-2010, 10:35 AM
#18
Member
Thread Starter
Join Date: Jun 2010
Posts: 32
All: This post will contain no useful progress. But, thank you for the responses - exactly what I was hoping for. My posts may be infrequent as it will take me some time to chase down the info you've provided and digest it.
Please see response to S3 below regarding intent to be legal.
The project is large. It must probably proceed in stages, the holy grail being achieved only after development of necessary test fixtures/software/etc is done. Also, there are several different areas:
- Mechanical (connectors - where to purchase?, etc)
- Hardware (processor selection, speed, IO, memory. Gauge the capability of Nissan's h/w)
- Software monitoring (initial) and control (later)
- Software communication (Consult & OBDII)
- Development and testability tools, fixtures, etc.
Delacruz: All help is welcome if this gets off the ground.
Kevlo: Thank you for the helpful starting points.
S3: Of course I am a genius, I can't figure out why nobody else in my life seems to realize this... Regarding reinventing the wheel, if I waited to do something 100% original I'd die a very bored man. It bothers me that the ECM is so expensive and opaque, and since I plan to be driving my two 99 Maximas 10+ years from now (not at the same time, that's another project), I'd like to try to get more control over the process.
S3/4DSC: Regarding reverse engineering, this means many things. I am DEFINITELY NOT talking about disassembling, copying, and redistributing Nissan's IP. I am talking about a black-box emulation using characterization techniques, using clean-room development techniques, maybe bending things to my advantage with whatever "inside" information I can start with (basic things like processor, clock speed, other hardware, etc. used on Nissan's ECM).
SaithLinux: Exactly, RTL. Very useful IO suggestions! I think the USB/harness is top contender, don't know if USB with off the shelf serial adaptors would provide adequate/quicker solution.
FallenOne: Thanks for the support. Will check out the WRX and F-Series OS stuff in more detail.
Cruz/EsQ/Nismo: Thanks.
Please see response to S3 below regarding intent to be legal.
The project is large. It must probably proceed in stages, the holy grail being achieved only after development of necessary test fixtures/software/etc is done. Also, there are several different areas:
- Mechanical (connectors - where to purchase?, etc)
- Hardware (processor selection, speed, IO, memory. Gauge the capability of Nissan's h/w)
- Software monitoring (initial) and control (later)
- Software communication (Consult & OBDII)
- Development and testability tools, fixtures, etc.
Delacruz: All help is welcome if this gets off the ground.
Kevlo: Thank you for the helpful starting points.
S3: Of course I am a genius, I can't figure out why nobody else in my life seems to realize this... Regarding reinventing the wheel, if I waited to do something 100% original I'd die a very bored man. It bothers me that the ECM is so expensive and opaque, and since I plan to be driving my two 99 Maximas 10+ years from now (not at the same time, that's another project), I'd like to try to get more control over the process.
S3/4DSC: Regarding reverse engineering, this means many things. I am DEFINITELY NOT talking about disassembling, copying, and redistributing Nissan's IP. I am talking about a black-box emulation using characterization techniques, using clean-room development techniques, maybe bending things to my advantage with whatever "inside" information I can start with (basic things like processor, clock speed, other hardware, etc. used on Nissan's ECM).
SaithLinux: Exactly, RTL. Very useful IO suggestions! I think the USB/harness is top contender, don't know if USB with off the shelf serial adaptors would provide adequate/quicker solution.
FallenOne: Thanks for the support. Will check out the WRX and F-Series OS stuff in more detail.
Cruz/EsQ/Nismo: Thanks.
06-24-2010, 10:43 AM
#19
All: This post will contain no useful progress. But, thank you for the responses - exactly what I was hoping for. My posts may be infrequent as it will take me some time to chase down the info you've provided and digest it.
Please see response to S3 below regarding intent to be legal.
The project is large. It must probably proceed in stages, the holy grail being achieved only after development of necessary test fixtures/software/etc is done. Also, there are several different areas:
- Mechanical (connectors - where to purchase?, etc)
- Hardware (processor selection, speed, IO, memory. Gauge the capability of Nissan's h/w)
- Software monitoring (initial) and control (later)
- Software communication (Consult & OBDII)
- Development and testability tools, fixtures, etc.
Delacruz: All help is welcome if this gets off the ground.
Kevlo: Thank you for the helpful starting points.
S3: Of course I am a genius, I can't figure out why nobody else in my life seems to realize this... Regarding reinventing the wheel, if I waited to do something 100% original I'd die a very bored man. It bothers me that the ECM is so expensive and opaque, and since I plan to be driving my two 99 Maximas 10+ years from now (not at the same time, that's another project), I'd like to try to get more control over the process.
S3/4DSC: Regarding reverse engineering, this means many things. I am DEFINITELY NOT talking about disassembling, copying, and redistributing Nissan's IP. I am talking about a black-box emulation using characterization techniques, using clean-room development techniques, maybe bending things to my advantage with whatever "inside" information I can start with (basic things like processor, clock speed, other hardware, etc. used on Nissan's ECM).
SaithLinux: Exactly, RTL. Very useful IO suggestions! I think the USB/harness is top contender, don't know if USB with off the shelf serial adaptors would provide adequate/quicker solution.
FallenOne: Thanks for the support. Will check out the WRX and F-Series OS stuff in more detail.
Cruz/EsQ/Nismo: Thanks.
Please see response to S3 below regarding intent to be legal.
The project is large. It must probably proceed in stages, the holy grail being achieved only after development of necessary test fixtures/software/etc is done. Also, there are several different areas:
- Mechanical (connectors - where to purchase?, etc)
- Hardware (processor selection, speed, IO, memory. Gauge the capability of Nissan's h/w)
- Software monitoring (initial) and control (later)
- Software communication (Consult & OBDII)
- Development and testability tools, fixtures, etc.
Delacruz: All help is welcome if this gets off the ground.
Kevlo: Thank you for the helpful starting points.
S3: Of course I am a genius, I can't figure out why nobody else in my life seems to realize this... Regarding reinventing the wheel, if I waited to do something 100% original I'd die a very bored man. It bothers me that the ECM is so expensive and opaque, and since I plan to be driving my two 99 Maximas 10+ years from now (not at the same time, that's another project), I'd like to try to get more control over the process.
S3/4DSC: Regarding reverse engineering, this means many things. I am DEFINITELY NOT talking about disassembling, copying, and redistributing Nissan's IP. I am talking about a black-box emulation using characterization techniques, using clean-room development techniques, maybe bending things to my advantage with whatever "inside" information I can start with (basic things like processor, clock speed, other hardware, etc. used on Nissan's ECM).
SaithLinux: Exactly, RTL. Very useful IO suggestions! I think the USB/harness is top contender, don't know if USB with off the shelf serial adaptors would provide adequate/quicker solution.
FallenOne: Thanks for the support. Will check out the WRX and F-Series OS stuff in more detail.
Cruz/EsQ/Nismo: Thanks.
Maybe you can do what all them Nissan engineers failed to do LOL
Last edited by [s3]; 06-24-2010 at 10:45 AM.
06-24-2010, 10:52 AM
#20
Senior Member
Join Date: Dec 2009
Posts: 469
Reverse-engineering isn't illegal. It's how AMD, VIA, and the others were able to make Intel-compatible chips for the last several decades, and it's how Intel can make x64-compatible chips today. If you open up the source code and copy out code, you aren't reverse-engineering anything, you're just copying. Reverse-engineering means creating an identical interface using your own methods; e.g. Intel publishes a set of commands that programmers can use to make software, and using these commands, AMD makes a chip that outputs the same as would an Intel chip.
OP knows this but I thought I'd clarify because I like to hear mysef talk.
OP knows this but I thought I'd clarify because I like to hear mysef talk.
06-24-2010, 11:49 AM
#22
06-25-2010, 06:54 AM
#24
There is a decent amount of electronics inside the Nissan ECU that you could probably reuse. If I were you, I would develop a list of requirements first so you know exactly what it is you will have to do. You have to control/sense
6 injectors - output - digital
6 coils - output - digital
IACV - output - stepper moptor
IACV valve 1 - output - digital
IACV valve 2 - output - digital
EVAP purge control volume valve - output - stepper motor
crank sensor (pos) - input - digital
crank sensor (ref) - input - digital
cam sensor - phase - digital
MAF - input - analog
KS - input - analog
Fuel temp sensor - input - analog
Intake air temperature sensor - input - analog
EGR temp sensor - input - analog
Engine Coolant Temperature Sensor - input - analog
EVAP control system pressure sensor - input - analog
Absolute pressure sensor - input - analog
TPS - input - analog
Right front O2 sensor - input - analog
Left front O2 sensor - input - analog
rear O2 sensor - input - analog
EVAP Canister Vent valve - output - digital
Map/Baro switch solinoid valve - output - digital
Vacuum cut valve bypass valve - output - digital
EVAP canister purge control solenoid valve - output - digital
EGRC solenoid valve - output - digital
Power steering pressure switch - input - digital
Tachometer - output - digital
Vehicle speed sensor - input - analog
Fuel pump relay - output - digital
Neutral position switch - input - digital
That's a lot going on at once. There are a lot of 12 volt circuit you have to interface with also, which is why reusing the electronics in the stock ECU might be beneficial. I would think that a 32 bit embedded solution, like an ARM, would be the way to go. You can get those up to a couple hundred megahertz, and if you run an RTOS that should be enough. How much experience do you have with C and embedded systems?
6 injectors - output - digital
6 coils - output - digital
IACV - output - stepper moptor
IACV valve 1 - output - digital
IACV valve 2 - output - digital
EVAP purge control volume valve - output - stepper motor
crank sensor (pos) - input - digital
crank sensor (ref) - input - digital
cam sensor - phase - digital
MAF - input - analog
KS - input - analog
Fuel temp sensor - input - analog
Intake air temperature sensor - input - analog
EGR temp sensor - input - analog
Engine Coolant Temperature Sensor - input - analog
EVAP control system pressure sensor - input - analog
Absolute pressure sensor - input - analog
TPS - input - analog
Right front O2 sensor - input - analog
Left front O2 sensor - input - analog
rear O2 sensor - input - analog
EVAP Canister Vent valve - output - digital
Map/Baro switch solinoid valve - output - digital
Vacuum cut valve bypass valve - output - digital
EVAP canister purge control solenoid valve - output - digital
EGRC solenoid valve - output - digital
Power steering pressure switch - input - digital
Tachometer - output - digital
Vehicle speed sensor - input - analog
Fuel pump relay - output - digital
Neutral position switch - input - digital
That's a lot going on at once. There are a lot of 12 volt circuit you have to interface with also, which is why reusing the electronics in the stock ECU might be beneficial. I would think that a 32 bit embedded solution, like an ARM, would be the way to go. You can get those up to a couple hundred megahertz, and if you run an RTOS that should be enough. How much experience do you have with C and embedded systems?
06-25-2010, 08:41 AM
#25
There is a decent amount of electronics inside the Nissan ECU that you could probably reuse. If I were you, I would develop a list of requirements first so you know exactly what it is you will have to do. You have to control/sense
6 injectors - output - digital
6 coils - output - digital
IACV - output - stepper moptor
IACV valve 1 - output - digital
IACV valve 2 - output - digital
EVAP purge control volume valve - output - stepper motor
crank sensor (pos) - input - digital
crank sensor (ref) - input - digital
cam sensor - phase - digital
MAF - input - analog
KS - input - analog
Fuel temp sensor - input - analog
Intake air temperature sensor - input - analog
EGR temp sensor - input - analog
Engine Coolant Temperature Sensor - input - analog
EVAP control system pressure sensor - input - analog
Absolute pressure sensor - input - analog
TPS - input - analog
Right front O2 sensor - input - analog
Left front O2 sensor - input - analog
rear O2 sensor - input - analog
EVAP Canister Vent valve - output - digital
Map/Baro switch solinoid valve - output - digital
Vacuum cut valve bypass valve - output - digital
EVAP canister purge control solenoid valve - output - digital
EGRC solenoid valve - output - digital
Power steering pressure switch - input - digital
Tachometer - output - digital
Vehicle speed sensor - input - analog
Fuel pump relay - output - digital
Neutral position switch - input - digital
That's a lot going on at once. There are a lot of 12 volt circuit you have to interface with also, which is why reusing the electronics in the stock ECU might be beneficial. I would think that a 32 bit embedded solution, like an ARM, would be the way to go. You can get those up to a couple hundred megahertz, and if you run an RTOS that should be enough. How much experience do you have with C and embedded systems?
6 injectors - output - digital
6 coils - output - digital
IACV - output - stepper moptor
IACV valve 1 - output - digital
IACV valve 2 - output - digital
EVAP purge control volume valve - output - stepper motor
crank sensor (pos) - input - digital
crank sensor (ref) - input - digital
cam sensor - phase - digital
MAF - input - analog
KS - input - analog
Fuel temp sensor - input - analog
Intake air temperature sensor - input - analog
EGR temp sensor - input - analog
Engine Coolant Temperature Sensor - input - analog
EVAP control system pressure sensor - input - analog
Absolute pressure sensor - input - analog
TPS - input - analog
Right front O2 sensor - input - analog
Left front O2 sensor - input - analog
rear O2 sensor - input - analog
EVAP Canister Vent valve - output - digital
Map/Baro switch solinoid valve - output - digital
Vacuum cut valve bypass valve - output - digital
EVAP canister purge control solenoid valve - output - digital
EGRC solenoid valve - output - digital
Power steering pressure switch - input - digital
Tachometer - output - digital
Vehicle speed sensor - input - analog
Fuel pump relay - output - digital
Neutral position switch - input - digital
That's a lot going on at once. There are a lot of 12 volt circuit you have to interface with also, which is why reusing the electronics in the stock ECU might be beneficial. I would think that a 32 bit embedded solution, like an ARM, would be the way to go. You can get those up to a couple hundred megahertz, and if you run an RTOS that should be enough. How much experience do you have with C and embedded systems?
"S3:Of course I am a genius"
Why reuse any of the electronics in the stock ECU when he's attempting to rebuild it from scratch?
Expect to see a prototype in about 2 months.
06-25-2010, 10:24 AM
#26
ok so i dont know how much itll be worth to you, but id say your best bet for harware would probably be the Pico ITX. you have usb as well as com ports for all your digital and analog needs! for your hdd, you could use the onboard sata with an internal ssd chip. not a 2.5" hdd size but is a much smaller version
PICO mainboard...
PCIE to sata adapter
PCIE SSD 16gb Super Talent
and this i just thought was cool, maybe you could incorperate it into the unit and use it for diagnotics or even tuning...
small lcd screen
other options, prebuilt, small, everything included...
axiomtek ebox530
AMOS 3000
PICO mainboard...
PCIE to sata adapter
PCIE SSD 16gb Super Talent
and this i just thought was cool, maybe you could incorperate it into the unit and use it for diagnotics or even tuning...
small lcd screen
other options, prebuilt, small, everything included...
axiomtek ebox530
AMOS 3000
06-25-2010, 12:08 PM
#27
Too pricy and too much bs involved. One thing I've yet to hear is the base os he plans to use?
Oh and everyone seems to think this is a humungeous project but in all actuality.. Half the information is already available via the Fsm.
Oh and everyone seems to think this is a humungeous project but in all actuality.. Half the information is already available via the Fsm.
06-25-2010, 12:11 PM
#28
ok so i dont know how much itll be worth to you, but id say your best bet for harware would probably be the Pico ITX. you have usb as well as com ports for all your digital and analog needs! for your hdd, you could use the onboard sata with an internal ssd chip. not a 2.5" hdd size but is a much smaller version
PICO mainboard...
PCIE to sata adapter
PCIE SSD 16gb Super Talent
and this i just thought was cool, maybe you could incorperate it into the unit and use it for diagnotics or even tuning...
small lcd screen
other options, prebuilt, small, everything included...
axiomtek ebox530
AMOS 3000
PICO mainboard...
PCIE to sata adapter
PCIE SSD 16gb Super Talent
and this i just thought was cool, maybe you could incorperate it into the unit and use it for diagnotics or even tuning...
small lcd screen
other options, prebuilt, small, everything included...
axiomtek ebox530
AMOS 3000
Those are a good option - especially the newer ones that have the faster GHz speeds.
06-25-2010, 12:53 PM
#29
Can’t you just get a microcontroller with board and write it all with opcode? There are some good boards out there with 32 bit Motorola chips in them. This is a popular way of doing this; in fact Mega Squirt uses a Motorola chip and opcode.
With this setup you could just reveres engineer the mega squirt opcode and be done in a weekend, or get a mega squirt and be done in a day.
With this setup you could just reveres engineer the mega squirt opcode and be done in a weekend, or get a mega squirt and be done in a day.
06-25-2010, 02:29 PM
#31
Junior Member
Join Date: May 2007
Posts: 49
First things first, does anybody know anything about the MCU (model and data sheet) and the other support hardware in the ECU? Can the MCU be dumped and the code disassembled? What about the D/A and A/D interface hardware? Anybody got a lead as to where this stuff can bought? I doubt Digikey carries it.
If we can't get answers to these questions then this project is a pipe dream.
If we can't get answers to these questions then this project is a pipe dream.
06-25-2010, 03:46 PM
#32
Very cool idea, I see a couple doubters at the beginning of the thread and all I have to say is that.... a long long time ago, someone said lets go to the moon! And I'm sure back then everyone was like "yeah, maybe I will grow wings and fly too" but the point is, just about nothing is impossible with enough people working together and a strong enough dedication.
Looking forward to future results! Good luck!
Looking forward to future results! Good luck!
06-25-2010, 09:28 PM
#33
Very cool idea, I see a couple doubters at the beginning of the thread and all I have to say is that.... a long long time ago, someone said lets go to the moon! And I'm sure back then everyone was like "yeah, maybe I will grow wings and fly too" but the point is, just about nothing is impossible with enough people working together and a strong enough dedication.
Looking forward to future results! Good luck!
Looking forward to future results! Good luck!
06-25-2010, 09:31 PM
#34
Do those ITX boards have GPIO? I kinda thought they just had busses (PCIE, AGP, USB). And why are we talking in the GHz range. That is way overkill. Usually in a case like this, most people would use an embedded system for the actual ECU and a laptop to tune it. You can use USB to connect the two, but USB is going to get you no where when you need to read the TPS signal. A microcontroller is what you need to interface to the car's electronics, and to make the decisions. You really don't need to have an OS in the sense of windows or linux. A program written in c, or something else that will allow you to compile machine code for your given architecture, would do the trick. Possibly with threading, but not necessarily, it would probable just slow it down and over complicate it.
The AVR32 B series has chips with multiple PWM (for the injectors) and 10 or so A/D inputs, plus GPIO for the digital stuff. Atmel is a great choice because it too is inherently open source. Atmel has some ARM chips as well, but those seem like overkill with their video decoders and Ethernet. You aren't really going to need DMA for this project either.
The AVR32 B series has chips with multiple PWM (for the injectors) and 10 or so A/D inputs, plus GPIO for the digital stuff. Atmel is a great choice because it too is inherently open source. Atmel has some ARM chips as well, but those seem like overkill with their video decoders and Ethernet. You aren't really going to need DMA for this project either.
06-25-2010, 09:32 PM
#35
Very cool idea, I see a couple doubters at the beginning of the thread and all I have to say is that.... a long long time ago, someone said lets go to the moon! And I'm sure back then everyone was like "yeah, maybe I will grow wings and fly too" but the point is, just about nothing is impossible with enough people working together and a strong enough dedication.
Looking forward to future results! Good luck!
Looking forward to future results! Good luck!
good luck, can't wait to see progress!
06-26-2010, 09:38 AM
#38
I thought of that thread too. It was so exciting, what happened?
http://forums.maxima.org/4th-generat...addresses.html
Id say start reading.. I forgot someone already attempted some of this.
Id say start reading.. I forgot someone already attempted some of this.
06-26-2010, 10:23 AM
#39
Do those ITX boards have GPIO? I kinda thought they just had busses (PCIE, AGP, USB). And why are we talking in the GHz range. That is way overkill. Usually in a case like this, most people would use an embedded system for the actual ECU and a laptop to tune it. You can use USB to connect the two, but USB is going to get you no where when you need to read the TPS signal. A microcontroller is what you need to interface to the car's electronics, and to make the decisions. You really don't need to have an OS in the sense of windows or linux. A program written in c, or something else that will allow you to compile machine code for your given architecture, would do the trick. Possibly with threading, but not necessarily, it would probable just slow it down and over complicate it.
The AVR32 B series has chips with multiple PWM (for the injectors) and 10 or so A/D inputs, plus GPIO for the digital stuff. Atmel is a great choice because it too is inherently open source. Atmel has some ARM chips as well, but those seem like overkill with their video decoders and Ethernet. You aren't really going to need DMA for this project either.
The AVR32 B series has chips with multiple PWM (for the injectors) and 10 or so A/D inputs, plus GPIO for the digital stuff. Atmel is a great choice because it too is inherently open source. Atmel has some ARM chips as well, but those seem like overkill with their video decoders and Ethernet. You aren't really going to need DMA for this project either.
the proc is PLENTY fast enough. granted i dont know the specs on an ecu but considering the crunching that those little ITX's are capable of id say it can handle it. optimized software and just simple code proccessing should be to easy for it.
my main though with using something like the ITX is to have a GUI you could use with an external monitor... this could replace the ECU with a stock type tune and then you could also have an interactive interface like EU to tune and datalog... you can compare the minimum specs for EU software and see itll do fine
also, i cant compare these to an embeded microcontroller because i know diddly about them... plus im guessing it would be pretty expensive to develope one for this... either way though. LOTS OF FUNCTIONS IS THE KEY!!!
