Howdy all. New member here, I'm Quillgear.
I hesitated to post this question in the general forum, but I'm not sure where else it should go. If this post is in the wrong place, please let me know.
I perused the site for several hours before posting, and I got the impression that most active development and test going on, is on the Puma boards right now.
I would like to ask what is the status of the DFH (is it still called that?) hardware and the vanilla (is it still called that?) firmware.
I have several FreeEMS projects in mind, but the first one I'm thinking about is a dynamometer mule engine. Among other things, the dynamometer setup with this engine would be used as an EFI test bench. As a test setup, it needs to be flexible and the DFH board stack architecture would fit in nicely with that.
I have a stock 1.8L Miata engine sitting unused in a parts car, so it seems as good a starting point as any.
Is there a way that I could participate usefully in the DFH stack development?
Where should I go to get hooked up with the latest DFH status, and find out what development hardware and software I need to participate? What is on the current to-do list for the DFH and the vanilla firmware?
Regards,
Quillgear
DFH status?
Re: DFH status?
Hi!
FreeEMS-Vanilla (the only branch of the firmware at this time, and hopefully for ever) is in fine form and running/ran multiple engines right now/recently. This is the core of the project, the idea is for there to be many specialised hardware designs all of which run a common robust firmware.
DFH stopped dev a while back after I found an issue with PORTA pins behaviour during reset (won't affect most users, but needs sorting out before proceeding).
Neither Puma nor DFH are compatible OOTB (out of the box) with the firmware as it stands right now. The reason is that currently we only support 6 output channels, and those are the ones on PORTT. DFH has them wired to injectors and Puma has them wired to 4 ignition channels and 2 spares. Reality is that you can jumper the CPU source pin around to whatever output circuits you have pretty easily. That is what I did on my Puma.
All of the needed software is free and open source. To participate physically (even on the bench) you need a running XDP512 cpu with the correct SM code loaded to it. The simplest easiest and most reliable way to do that is by purchasing a TA card with the correct headers to use on a car later. Once you have that, it needs a power supply upgrade, and then limited bench testing can be performed, with nothing else. Pretty soon I'll have a bench test module in the firmware for full bench testing, that'll be cool. From there, its inputs, and outputs and engines :-)
You're not alone in your interest in DFH, there are a few more who want to pursue something simpler than the Puma too.
Hopefully jharvey spots this and fills in the rest with regards DFH.
Welcome to the site! :-)
Fred.
FreeEMS-Vanilla (the only branch of the firmware at this time, and hopefully for ever) is in fine form and running/ran multiple engines right now/recently. This is the core of the project, the idea is for there to be many specialised hardware designs all of which run a common robust firmware.
DFH stopped dev a while back after I found an issue with PORTA pins behaviour during reset (won't affect most users, but needs sorting out before proceeding).
Neither Puma nor DFH are compatible OOTB (out of the box) with the firmware as it stands right now. The reason is that currently we only support 6 output channels, and those are the ones on PORTT. DFH has them wired to injectors and Puma has them wired to 4 ignition channels and 2 spares. Reality is that you can jumper the CPU source pin around to whatever output circuits you have pretty easily. That is what I did on my Puma.
All of the needed software is free and open source. To participate physically (even on the bench) you need a running XDP512 cpu with the correct SM code loaded to it. The simplest easiest and most reliable way to do that is by purchasing a TA card with the correct headers to use on a car later. Once you have that, it needs a power supply upgrade, and then limited bench testing can be performed, with nothing else. Pretty soon I'll have a bench test module in the firmware for full bench testing, that'll be cool. From there, its inputs, and outputs and engines :-)
You're not alone in your interest in DFH, there are a few more who want to pursue something simpler than the Puma too.
Hopefully jharvey spots this and fills in the rest with regards DFH.
Welcome to the site! :-)
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!
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!
Re: DFH status?
Welcome along.
I stopped working on it, as I was waiting for Fred to tell me what pin would have what sub circuit. I honestly haven't looked at this for some time. I have been combining my efforts with Marcos, however I'm currently waiting for Marcos so I can do a bit more work here. If your interested feel free to do a detailed analysis, and don't hold back, but also don't simply tell me that something sucks. I like hearing, this sucks because resistor blah would over heat and explode in a desert environment, ect. Feel free to smack it around, it can only make it stronger.
There have been a couple people that have pinged me about DFH, however Marcos got my attention by doing his own spin, and pushing to make a proto.
I stopped working on it, as I was waiting for Fred to tell me what pin would have what sub circuit. I honestly haven't looked at this for some time. I have been combining my efforts with Marcos, however I'm currently waiting for Marcos so I can do a bit more work here. If your interested feel free to do a detailed analysis, and don't hold back, but also don't simply tell me that something sucks. I like hearing, this sucks because resistor blah would over heat and explode in a desert environment, ect. Feel free to smack it around, it can only make it stronger.
There have been a couple people that have pinged me about DFH, however Marcos got my attention by doing his own spin, and pushing to make a proto.
Re: DFH status?
Thanks for the quick replies, being a newbie I didn't expect that.
Fred wrote:
Are PORTA pins used for injectors at all? Aren't all 6 output channels on PORTT? Or is this different for Puma and DFH? (dunno why it would be...)
In another post a little while back, somebody (probably also Fred) wrote:
JHarvey wrote:
I have a feeling there is a bunch of documentation out there on the wikis or such, that I haven't found yet...
Regards,
Quillgear
Fred wrote:
Forgive me for not being up to speed here; I'm having trouble finding all the schematics and such, so this is probably a dumb question, BUT:DFH stopped dev a while back after I found an issue with PORTA pins behaviour during reset
Are PORTA pins used for injectors at all? Aren't all 6 output channels on PORTT? Or is this different for Puma and DFH? (dunno why it would be...)
In another post a little while back, somebody (probably also Fred) wrote:
Was this describing the same PORTA reset problem? Or was this in connection with HighZ PORTA pins during bootloader operation?On puma we need a solution for that on one pin, the fuel pump, and any PORTA GPIO pins that are brought out too.
I don't have the hw yet... But, now that I know what to get, I will be getting it soon! Point me to the right thread to study up on the PORTA reset problem? Maybe I could try to investigate it.Someone needs to investigate this, still, and there are now lots of people with hw that can give it a shot.
JHarvey wrote:
Um, sorry I'm feeling a bit dense here, but... analysis of what? You mean of the TA card? Or is there already an input or output card schematic floating around?If your interested feel free to do a detailed analysis, and don't hold back, but also don't simply tell me that something sucks.
I have a feeling there is a bunch of documentation out there on the wikis or such, that I haven't found yet...
Regards,
Quillgear
Re: DFH status?
We strive to exceed explications here, unlike other projects that feel the bare min is OKquillgear wrote:Thanks for the quick replies, being a newbie I didn't expect that.
I think you'll find many of use fairly tolerant here. We seem to understand that we haven't spent the time to put this data in one good location, so we know it's a bit of hit or miss about what you might learn on the initial readings. A good-ish place to get a basic idea of at least DFH is on the wiki.quillgear wrote:Forgive me for not being up to speed here; I'm having trouble finding all the schematics and such, so this is probably a dumb question, BUT:
http://wiki.freeems.org/doku.php
There are many things that come and go in the forum chatter, the wiki typically will contain the items that made it through the forum debates and such. As always, its best to read as much as possible before asking questions, but most won't really start to object unless you ask a question a couple times or something like that.
Hmm, looks like I just found a broken link on the DFH wiki. The git link should be fixed shortly.
Right now, that's kind of up in the air. I schematically connected IGN to port T and INJ to port B, however that was just to make the DRC shut up. The PCB layout doesn't have either actually routed to an actual pin. I'd say what ever we decide with PUMA should match as much as possible in DFH.quillgear wrote:Are PORTA pins used for injectors at all? Aren't all 6 output channels on PORTT? Or is this different for Puma and DFH? (dunno why it would be...)
I don't fully follow the issues with portA. All I know is that Fred said to stop, until he specified what pins to use.
Analysis of anything really. This board hasn't been built yet, and it's common that a first spin has problems, similar to what we saw with PUMA. Any time someone looks over the design, and notes things like, this trace is bad because of X/Y/Z, it makes the proto spin that much less problematic. So by all means, feel free to calculate the trace widths for a specific current draw, ect. Any kind of sanity check would be great. If you see something that seems a bit different then what you expect, pipe up and inquire. There may or may not be a reason for oddities.quillgear wrote:Um, sorry I'm feeling a bit dense here, but... analysis of what? You mean of the TA card? Or is there already an input or output card schematic floating around?If your interested feel free to do a detailed analysis, and don't hold back, but also don't simply tell me that something sucks.
Re: DFH status?
Ah Ha !! Thanks. I went back to Git Hub and was able to find all the hardware files. Now it becomes more clear what y'all are doing.jharvey wrote:Hmm, looks like I just found a broken link on the DFH wiki. The git link should be fixed shortly.quillgear wrote:Forgive me for not being up to speed, having trouble finding all the schematics, this is probably a dumb question
All this was done in Eagle, right?
Fair enough, now that I found all the hardware files on GitHub I will be studying it and trying to understand it in detail. Will get back to you in a week or two with questions.jharvey wrote:Analysis of anything really. <snip> Any kind of sanity check would be great. If you see something that seems a bit different then what you expect, pipe up and inquire.quillgear wrote:You mean of the TA card?If your interested feel free to do a detailed analysis, and don't hold back, but also don't simply tell me that something sucks.
Thank you sir!
Quillgear
Re: DFH status?
Negative, it's done in KICAD.quillgear wrote:All this was done in Eagle, right?
I look forward to your input, enjoy.
Re: DFH status?
hi all i'm also new here. how do i find hardware files on GitHub?
Re: DFH status?
ok i think i found it
Re: DFH status?
Hi! I was talking about the reset problem. All the pins, a, b, t, etc with anything important on them (preferably all used pins) require some sort of attention for both bootloader and reset, the PORTA pins require extra attention. During reset PORTA appears to go high, briefly, the rest go high z and float, which is also bad, if you have a coil or injector attached and powered at the time, which you usually do...quillgear wrote:Was this describing the same PORTA reset problem? Or was this in connection with HighZ PORTA pins during bootloader operation?Fred wrote:On puma we need a solution for that on one pin, the fuel pump, and any PORTA GPIO pins that are brought out too.
There is a specific thread about it, some of the state control pins may be to blame for it, or perhaps it's just always going to happen.
Thread on this: viewtopic.php?f=9&t=510
Comments: viewtopic.php?f=9&t=511
If you can help, great, I've not had time, however I may spend some time with a friend on this in 1.5 weeks, if it's not done first.
Regards,
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!
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!