DIYEFI.org Forum

This thread is intended to be both a discussion and official document/work in progress.

The goal is that a box can be labeled as "FreeEMS Compatible" or similar, perhaps with a special sticker (self printed is fine) and listed on an "Available Hardware" website with features and notes and faults and errata etc. All known designs (free and commercial) shall be listed there, but "FreeEMS Compatible" devices will be listed ahead of all others for obvious reasons.

The goals are :

• Provides the user with a quality experience (connectivity, compatibility, board design and circuit design)
• Fundamental and basic functionality is available (or more. FreeEMS firmware should be able to be configured in a non-crippled way and work minimally at least.)

Last night I was wide awak and did some work on this before I went to sleep. I started compiling a "minimum connections" document just to see what was required for a dead simple single cylinder (or batch/dizzy) setup.

This morning while waiting for a late phone call, I continued and provided recommendations and disucssions of various extra recommended functionality and the pros/cons of including it in a design or not.

This document is mostly divorced of specific pin requirements, but clearly such things will be specified in a final version ready for general release.

I'm going to check it into the docs dir of the firmware now, and later I will integrate it into the odt master document. I can't recall if there is any overlap or not at this stage, there may be.

http://github.com/fredcooke/freeems-van ... ations.txt

Marcos, you have a similar document in your hardware repo, could you please provide a link to it here for us, thanks :-)

Fred.

Whoa! Thats the thread I was waiting for!
In my text file I copied your requirements for a development board (adapt board, with stackable design), and then started to ditch off the thinks I don't consider important.

The file is here
http://github.com/nitrousnrg/FreeEMS_1. ... ifications
where:
// <- not important for a production board
* <-added by me
(?) <-unsure about it.

Please point out the things you consider wrong.

1. Btw, if the board doesn't have any injector or ignition output, It still can be a high end datalogger or solenoid/cam controller.

2. I'm trying to join both:
*clean constant 12v (cpu power supply)
*clean relay switched 12v (adc vreg and sleep input)
to be driven from the same cable (they are clean, and I could switch off the second one with the dirty relay switched 12v)

1) True, but it's no longer an EMS :-) I never want the focus of the firmware to be something other than sensing, injection and ignition. All other functions must come secondarily and/or on accessory cards etc.
2) Sure, but usually that would happen outside the case. You could move it inside, true, but think about relay noise/vspikes and also current draw. If you want to do it internally, that's fine, but I'd expect that it was part of the loom setup, myself.

I'll review your document in detail later!

Fred.

PS, where did you get my "design brief" from? link?

from viewtopic.php?f=9&t=5

Its not a great document, its just a couple of notes I took while I was routing.

Wow, that's OLD, I'd forgotten! That was never supposed to be a document like this thread is for. It was just whatever I could think of at the time that seemed like a good idea. Thanks for the link. I updated it to say 1.6k ;-) I didn't read the rest, though, stuff could be out of date/wrong.

I'd like to revise the Eurocard statement a bit; since 160x100mm is the most common size for stock blank PCB's (at least in Europe), I would suggest keeping it the maximum size but smaller are fine. 160x100 is a large board (for EMS use) anyway.

I'm not disagreeing, and you could build something a LOT smaller if you wanted to and wanted only some features, but if you want something fully featured, then 160x100 is on the small side!

160x100 for thru hole is reasonably small, for SMT it huge. Perhaps two specs would be handy. Seems not every DIY'er is concerned about SMT and is willing to give it a try. I drew my version up such that it can have SMT or thru, so it needed the size to allow the thru components.

OK, bump from the past, the pin use guidelines are now available semi formalised and are a big part of what this thread is about.

I guess looking again there are different aspects to what this document will eventually contain.

Pin use is one of them, and the work that I did yesterday covers a lot of that, however it falls into several categories. I'll list everything that I can think of now:

Pins that you MUST supply certain circuits on. (compulsory core inputs and outputs)
Pins that you MUST use if you supply certain optional circuits. (optional core circuit features)
Pins that you MAY use to supply certain circuits and functions. (general functionality and IO)
Power/ground stuff, wiring and circuits is another full section
Output robustness and options is another section
Input protections is another section
Communications is another section
PCB, case and connector recommendations is another section

I'd like the final document to be compliant with this document if at all possible http://www.ietf.org/rfc/rfc2119.txt as I believe it should be done properly and clear language is a key part of that.

This is exciting progress! :-)

Fred.