DFH - Defacto FreeEMS Hardware in KICAD

Jared's unmaintained and never-used TA based "Defacto FreeEMS Hardware" design.
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by jharvey »

Per your IRC comments, and http://issues.freeems.org/view.php?id=190, I don't follow what you mean. For example.
- IAT,CHT,TPS,EGO,BRV,MAT MUST be implemented on ALL hardware designs.
- TPS is optional to connect, but highly recommended for all installs
So is TPS optional, or required? More importantly, what pin/port is it? What S12X AN is IAT? What S12X AN is CHT? What S12X AN is TPS? What S12X AN is MAP?
ADC pins can stay as-is pin wise
Again, what pin/port. Your Pin assignment .ods file notes all AN's are swap able. However I notice issue 190 is newer than the .ods. What should I use for a pin assignment, as the ods appears to be out dated.

Also why have you chosen that ADC stuff will be hardwired to specific ports/pins? I understand the requirement for PT to be your ignition and injection channels, until XGate stuff is better. But I don't understand why AN1 has to be AN1 and not AN2. They all use the same MUX, so the signal delays should be the same. Perhaps the issue is sourced from the crappy sample and hold, and it's tendency cross talk signals to adjacent input signals. However if that were the case, then you would have put the unused AN's between the other signals, to prevent this kind of leakage. So I don't follow why it has to stay wired this way.
User avatar
Fred
Moderator
Posts: 15409
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by Fred »

As stated in issue 190, TPS MUST be provided on all hardware designs, but is optional to connect. IE, the circuit needs to be there, the sensor in the vehicle does not.

The ods does not state that the pins are swappable, it states that the pins could be swappable. The assignment in the ODS stands, with the exceptions noted in issue 190. The pin out document is a pin description document for the CPU as a raw device too. Information there describes the CPU as a device, with the exception of the column of assignments and the column of notes. The notes are just that, notes, reminders that the hardware works a certain way and requires certain uses.

It has to stay wired this way because there is existing hardware out there, (40 units or more) with this configuration, and because one firmware build needs to work OOTB on all hardware setups without custom ADC mapping files needing uploading. Additionally, the core ADC channels are all on one module, which does not share the mux with the other module. In fact, the configuration is separate. Thus the other module can be disabled (as it is by default) and the device can still work.

The whole point of the 190 and associated docs is compatibility. For a DIY project, compatibility is absolutely essential, and maintaining it a very high priority.

As it stands, your configuration will result in no data in the device. That's not going to change till someone connects a Ravage up, and they are required for the spare inputs that he has.

At the end of the day, it's a support load thing and simplicity thing. I'd be very surprised if you couldn't lay it out to work as is.

I hope that it's now clear :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by jharvey »

Fred wrote: I'd be very surprised if you couldn't lay it out to work as is.
I can very likely route it this way, but it's going to increase the noise floor, as this layout wasn't the same as PUMA's general layout. I didn't know the second ADC was disabled. I'm not sure it's a good thing to force all future layout's to be the same as PUMA, especially with the TA card. I'm tempted to require this use a modified firmware, however DFH was going to be the PUMA, before PUMA existed. I guess it's a chicken and the egg situation. So it's a bit of a bugger.

As pins for many things will move around from layout to layout, I'd like to suggest a kind of compiler config file that allows one to easily determine what's mapped to what in the firmware. Kind of like an INI file that notes something like AN0 = IAT, PT2 = INJ3, ect. My injectors don't follow your pin out as well.
User avatar
Fred
Moderator
Posts: 15409
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by Fred »

jharvey wrote:I'm tempted to require this use a modified firmware
I don't like your chances of getting any sort of user base with that. You would lag the upstream all the time, constantly have to maintain your fork. Lots of work for little gain.
however DFH was going to be the PUMA, before PUMA existed. I guess it's a chicken and the egg situation. So it's a bit of a bugger.
My bench rig existed before that (and still exists!), and that was the point at which it was nailed down. WAY before Puma and WAY before DFH too.
As pins for many things will move around from layout to layout
Not on compliant layouts they won't, no. Only the sort of optional stuff that you have to configure anyway will move around.
I'd like to suggest a kind of compiler config file that allows one to easily determine what's mapped to what in the firmware. Kind of like an INI file that notes something like AN0 = IAT, PT2 = INJ3, ect.
Nope, absolutely not, the VAST majority of users will take a binary s19 from the release site and install it in some hardware and connect it to their vehicle and expect to get some level of functionality OOTB. Such things are OK for quick dirty hacks, but not for production level environments with multiple hardware solutions. No way. Route correctly or get left behind maintaining your own firmware. I wouldn't put myself in those shoes if I were you.
My injectors don't follow your pin out as well.
Then they will not work.

Hardware follows firmware. Remember that.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by jharvey »

Fred wrote:
As pins for many things will move around from layout to layout
Not on compliant layouts they won't, no. Only the sort of optional stuff that you have to configure anyway will move around.
Why not make them software configurable? Such that one links them via MTX or uses some PC software to specify that AN? is IAT, ect. The default build wouldn't connect them at all. That would be a flexible option.
User avatar
Fred
Moderator
Posts: 15409
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by Fred »

Because, once again, it would create a support nightmare. This isn't changing. I'm sorry if you don't like it.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15409
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: DFH - Defacto FreeEMS Hardware in KICAD

Post by Fred »

jharvey wrote:Your Pin assignment .ods file notes all AN's are swap able.
Fred wrote:The ods does not state that the pins are swappable, it states that the pins could be swappable.
ods wrote:All these yellow ones are swap able to suit board layout needs at the designers whim.
Jared, I owe you an apology. The wording in the ods is VERY misleading. I guess that's why it caught both Marcos and you. This doesn't change the facts, but I'm sorry for saying that it didn't say it when it was THAT unclear! :-(

IIRC the intent was to allow spare ones that weren't core to be swapped. I believe the yellow stuff existed before the pins were assigned too.

Sorry!

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply