DFH - Defacto FreeEMS Hardware in KICAD

[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.

[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.

[jharvey]

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.

[Fred]

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.

[jharvey]

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.

[Fred]

Because, once again, it would create a support nightmare. This isn't changing. I'm sorry if you don't like it.

[Fred]

Your Pin assignment .ods file notes all AN's are swap able.

The ods does not state that the pins are swappable, it states that the pins could be swappable.

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.