nitrousnrg wrote:
5v/1.6k = 3.125mA
5v/1k = 5mA
Is there any noticeable difference? I'm fine with 1.6k.
3.125 * 8 = 25mA = max current per port rating! That is why, and yes, 1.6k worth of resistor between outputs and other devices is part of compliance because without it you can't reasonably guantee that the CPU won't lock up (this happens if you overload the port) and hold the pins in any random unknown state potentially causing burned coils, flooded engines, worn out rings, hydrauliced rods/hgs, etc. I can't find the reference for you to prove it, but you can trust me that that is the case. The main thing is, that if a power transistor or mosfet cant be driven properly directly from the CPU through such a resistor, then with a slightly lower value resistor it will still be marginal, and therefore it should be driven through a buffer of some sort. Make good sense? Tear me apart if not.
Being 100% compatible is hard, at least for now, mostly because of the pinout.
My ignition outputs are right, probably. I expect that ignition will be always in port T, as well as RPM inputs.
Injector outputs are in port B, a port that doesn't seem to be useful except for bit banging. (No SPI,I²C, ADC,etc)
Stepper and auxiliary outputs are in PORT A, which is the same thing as port B (both A and B are available for data addressing, and we don't care about it).
There is actually a pin out document, which is slightly out of date, but pretty much right, available. In it it states that port t has inputs and fuel outputs, but that is changing to be inputs and ignition as you have it. As for port A and B, be careful! These two registers are back to back, and it makes sense to use 16bit writes across them, SO, which one you have routed for fuel WILL probably matter. The code isn't written yet, though. And the pin state during reset is not determined either, yet. Hence my warnings about not being able to make a design yet. It might be a waste of PCB. I'm not going to compromise the design just because someone already built a board. If you want your ADCs on different ports than I have them, then we need to discuss the POSSIBLE semantics of that too, and develop some code to handle it. I'm still not convinced about that, though. I also can't believe that it's that hard to route them as I have them. It is true that all the accessory ADC inputs should be configurable, but having the core ones that way seems superfluous and prone to misconnection. One of the guiding principals is to not have things configurable that don't need to be. Such as the individual firmware per decoder setup, etc.
I think you're rushing ahead! Somewhere earlier in this thread we discussed that finalisation of your board wouldn't be possible for several months, at least, and dependent on someone bench testing those reset power states, and then the forum members reaching a reasonable resolution on the pin buffers and pin outs etc.
If you have a proposal list for the ADC connections, maybe its a good time to try to modify my board. I have freed some space in it.
Something like:
CH1 = MAP¿
CH2 = Baro
CH3 = CLT, etc etc
is that information available somewhere?
YES!!! :-) RTFM ;-) That was one of the first documents I drew up as I knew it would be required by pretty much anyone doing anything with the device (users, sw devs, fw devs, hw devs).
So, if a board works out of the box with a vanilla software (which is easy to check, its mostly pinout), and the community can check it is reliable, we have a FreeEMS compliant board. Cool. I thought it was harder than that.
It is a little more complex, the grounds and powers MUST be properly seperated. I wont compromise on some basic minimum standards, I don't want MegaSquirt quality devices floating around with my firmware, and having a standard, that enough devices meet and are approved up to the standard of, will prevent that to some extent. If we make a big enough deal out of it, people won't want non compliant devices, it should be more or less that simple.
I vote for a "freeems capable" sticker :P
Great idea! :-) Perhaps "FreeEMS HW-1.0 Compliant" or something like that. Then we can roll out with 1.1 and 2.0 and have 2.0 be something entirely different, etc. Good idea, worth discussing.
Fred.
