zumindest bei mir läuft der noch nicht (noch nicht alle teile da)Alfagta hat geschrieben:wie siehts nun aus mit dem Adapter für die MS2 V3.0?
Hat es schon jemand am laufen?
mir ist auch nicht bekannt das noch jemand platinen hat herstellen lassen
FreeEMS - Open Source Motorsteuergerät
Re: FreeEMS - Open Source Motorsteuergerät
mir ist auch nicht bekannt das noch jemand platinen hat herstellen lassen
Re: FreeEMS - Open Source Motorsteuergerät
Hi Fred. What kind of Software is used to program (tune) FreeEMS at the moment? Megatunix? If the Hardware would be there (like the adapter board mentioned above) would it be possible for a programming N00B (like me) to get anything running at all?Fearless hat geschrieben:He hasn't posted in the FreeEMS vehicles section, so I assume he hasn't run anything. I doubt he'd run anything without at least a little bit of help, anyway. It's intentionally difficult right now, and will stay that way for at least 6 months or so.
Re: FreeEMS - Open Source Motorsteuergerät
Sure it's possible, but you must work closely with me to do it. Or you WILL hit snags and have problems and end up with a bad experience. This is intentional. I want to be involved in each and every start up until things are n00b-proof.
Fred Cooke, creator of FreeEMS - The open source engine management system! Number of installs! (with graph)
Also the founder of DIYEFI.org - The Do It Yourself Engine Control Community! Forum available here!
Also the founder of DIYEFI.org - The Do It Yourself Engine Control Community! Forum available here!
Re: FreeEMS - Open Source Motorsteuergerät
Hi Fred,
I really respect you passion for what you do and I like your approach.
And the attitude to request to be involved in all new start ups is not bad either as it helps you to learn from any user who is willing to cooperate and get his FreeEMS running in his ride.
What concerns me a bit is the flexibility in port use you are telling us about which avoids making a specific hardware. On one hand I understand that you need this sort of flexibility for improving you functional performance. On the other hand I did not yet see the clear strategy how I should start if I want to ge a FreeEMS running.
I'm an electical engineer working in automotive business (which means nearly no leasure time
) and therefore I know about circuit design. Maybe I did not get into the FreeEMS stuff deeply enough to understand your approach of getting a hardare fitting to a specific vehicle.
In general I love to use OEM ECU housings and connectors to make it a plug & play solution (of course only from hardware point if view).
Can you give some hints to make your approach for the hardware clearer?
Maybe Tooly or other members here can share what they understood?
Thank you!
Regards,
Carsten
I really respect you passion for what you do and I like your approach.
And the attitude to request to be involved in all new start ups is not bad either as it helps you to learn from any user who is willing to cooperate and get his FreeEMS running in his ride.
What concerns me a bit is the flexibility in port use you are telling us about which avoids making a specific hardware. On one hand I understand that you need this sort of flexibility for improving you functional performance. On the other hand I did not yet see the clear strategy how I should start if I want to ge a FreeEMS running.
I'm an electical engineer working in automotive business (which means nearly no leasure time
) and therefore I know about circuit design. Maybe I did not get into the FreeEMS stuff deeply enough to understand your approach of getting a hardare fitting to a specific vehicle.In general I love to use OEM ECU housings and connectors to make it a plug & play solution (of course only from hardware point if view).
Can you give some hints to make your approach for the hardware clearer?
Maybe Tooly or other members here can share what they understood?
Thank you!
Regards,
Carsten
Re: FreeEMS - Open Source Motorsteuergerät
Hello Carsten,
There are a few reasons that pins are not nailed down forever-forever.
The outputs subject is as follows:
8 timers, currently 2 for inputs, 6 for outputs.
In future, 8 for inputs (maybe configurable outputs too), 36 NORMAL pins powered by the XGATE coprocessor.
It's not the future, yet
It's quite likely that we can keep using the same 6 pins even once the software is upgraded, but not guaranteed. I'm in absolutely NO rush to add that software for a few reasons:
It will attract more "users" which are a drain and annoying and largely useless. "users" is not the same as testers/hackers, who can mostly take care of themselves and are a help, not a hurdle.
Other pin selection subjects are potential reserved pins for "always" functions and potential concurrency issues between XGATE and S12 in terms of accessing the same registers at the same time. IE, we may need to clearly split the 36 outputs onto ports not at all used by XGATE, or provide a mechanism for inter-CPU communication about pin state, or both.
It's a development system, no users, only testers. I'm not shy about that, nor am I shy about what it can do. It'd be a HUGE mistake to have "ordinary" users involved at this point. They'd simply end up frustrated and disappointed and hating the system, which is bad long term. The limitations are not hardware, nor are they people, there are certain things that I personally need to take care of, and my time is limited. The more users, the less time I have. It's starting to be the case that others know about the system, and can help. This is also bad, though, as there is still a proportion of stuff that's just me. The more it grows, the faster it grows, and I'm critically aware of that, and the fact that it could implode if it grows too fast without being ready for it. Much like a small business growing will go nuts and die off if it grows too fast without being prepared. Basically what I'm focused on is that preparation, making the system as "normal" person friendly as possible, which it's VERY MUCH NOT right now.
I hope that clears it up.
If you want to hack up your own stuff, at your own risk, follow the jaguar schematics and consider T2-7 to be your outputs, put ignition first 2,3,4 of them, and fuel second, 4,3,2 of them. You can do 5/1 but 5 cylinder/10 cylinders are rare. You can do 6 of just ign or just fuel, but that's not too useful. You can do 6 of both, and provide ability to jumper them around between say PORT B and PORT T, which future proofs it (partially), and allows it to be configurable between say 4/2, 3/3, 2/4 in the short term.
If your spoken English is good, I'd be very happy to have a chat with you on skype one of these days very soon, ditto anyone else who wants to ask questions on a dynamic way and get quick answers. PM me if you want
Fred.
There are a few reasons that pins are not nailed down forever-forever.
The outputs subject is as follows:
8 timers, currently 2 for inputs, 6 for outputs.
In future, 8 for inputs (maybe configurable outputs too), 36 NORMAL pins powered by the XGATE coprocessor.
It's not the future, yet
It's quite likely that we can keep using the same 6 pins even once the software is upgraded, but not guaranteed. I'm in absolutely NO rush to add that software for a few reasons:
It will attract more "users" which are a drain and annoying and largely useless. "users" is not the same as testers/hackers, who can mostly take care of themselves and are a help, not a hurdle.
Other pin selection subjects are potential reserved pins for "always" functions and potential concurrency issues between XGATE and S12 in terms of accessing the same registers at the same time. IE, we may need to clearly split the 36 outputs onto ports not at all used by XGATE, or provide a mechanism for inter-CPU communication about pin state, or both.
It's a development system, no users, only testers. I'm not shy about that, nor am I shy about what it can do. It'd be a HUGE mistake to have "ordinary" users involved at this point. They'd simply end up frustrated and disappointed and hating the system, which is bad long term. The limitations are not hardware, nor are they people, there are certain things that I personally need to take care of, and my time is limited. The more users, the less time I have. It's starting to be the case that others know about the system, and can help. This is also bad, though, as there is still a proportion of stuff that's just me. The more it grows, the faster it grows, and I'm critically aware of that, and the fact that it could implode if it grows too fast without being ready for it. Much like a small business growing will go nuts and die off if it grows too fast without being prepared. Basically what I'm focused on is that preparation, making the system as "normal" person friendly as possible, which it's VERY MUCH NOT right now.
I hope that clears it up.
If you want to hack up your own stuff, at your own risk, follow the jaguar schematics and consider T2-7 to be your outputs, put ignition first 2,3,4 of them, and fuel second, 4,3,2 of them. You can do 5/1 but 5 cylinder/10 cylinders are rare. You can do 6 of just ign or just fuel, but that's not too useful. You can do 6 of both, and provide ability to jumper them around between say PORT B and PORT T, which future proofs it (partially), and allows it to be configurable between say 4/2, 3/3, 2/4 in the short term.
If your spoken English is good, I'd be very happy to have a chat with you on skype one of these days very soon, ditto anyone else who wants to ask questions on a dynamic way and get quick answers. PM me if you want
Fred.
Fred Cooke, creator of FreeEMS - The open source engine management system! Number of installs! (with graph)
Also the founder of DIYEFI.org - The Do It Yourself Engine Control Community! Forum available here!
Also the founder of DIYEFI.org - The Do It Yourself Engine Control Community! Forum available here!