Status, help offered?

[hamster]

http://serverfault.com/questions/32270/ ... m-defining Maybe help?

[hamster]

As for pin behaviors, you are referring to the pin states at poweron? I still need to actually look at the pins and what you are doing with them, but I'm sure that will make more sense once I get the board and can put some code on it.

I was planning on going EFI on the bike last winter, but I was too lazy and it didn't happen. I got a 'base' MS-II working to the point where the stim board could be used to generate RPM and be read with software as I recall, so I have a good place to start from. I'll hack up that board more in line of being a real ECU and work on a breadboarded adapter to the Adapt board to get the pins routed and help resolve these boot up states, and from there I can work up a real adapter.

Should be exciting, I'm looking forward to putting some of this EFI gear I bought to work.

Also, I have a complete 36-1 tooth wheel, VR pickup, and Ford EDIS V8 controller/coil pack, which were intended for my previous MS project of putting EFI on my old Mustang. I dug up some injectors, and a spare manifold to CNC for the injectors, but then I didn't get around to doing the CAM and getting that going. (it's nice to have a CNC at work that I can use anytime).

So, I don't have any trouble with getting together a test bed for anything.

[Fred]

Yeah, pin state during reset, and after reset with the bootloader running. At the least, we need to know what is happening so we can buffer the hardware with an enable pin of some sort, to make pins with different reset behaviours consistent. I don't care too much about say an idle pwm pin or such, but I definitely care about injector, ignition and fuel pump pins. And possibly other things too.

There is a whole thread on this subject, or two, but the worst issue that I noticed was the A and B ports (8 pins each, and intended for bit banged fuel or ign as they have the least special functionality) behave differently, one is benign and does nothing, the other flashes at reset and could cause a spark to fly at an inopportune time! A reset during running under boost at a bad time could mean a severely damaged engine, for example. Plus there is the coil burning up during boot load issue that MS has, we don't want that either. But that is another story and involves hardware inversion of ignition outputs rather than software configuration. OK, time to stop typing, I'm rambling...

Fred.

[hamster]

OK, I copy. I have a 16 channel logic analyzer I can throw at it... actually, I have an ancient PC based 50 channel one if the machine with the working ISA slot still... works. Hehe.

I knew about the MS coil-burny-outy thing, seems like that should have been obvious, but...

Also, I have a schematic that may or may not be useful already drawn up of a) a RPM signal conditioner that will work on anything with a Kettering style ignition system and b) a simple Atmel AVR based RPM calculator that can also do spark cut on any non-CDI ignition system (it's cute, it just prevents the points/FETs from opening for a short period). Tested on my bike to work as a simple rev limiter, although without fuel control can lead to afterfiring.

Oh, yeah... almost forgot. I have an Innovate wideband O2 on the bike, the basic one. Instead of buying the RPM measuring module for $125, I reverse engineered the serial protocol for one and implemented it in an Atmel AVR, so if anyone is interested in how to fake a device in the Innovate serial chain, I have that code that I need to publish. The protocol is pretty simple, just some silly bit shifting that has to happen to make it work.

[davecramer]

I'm also interested in helping out. I have lots of embedded software experience as well as agile and open source experience. Point me at a problem... I will be buying hardware ASAP. What is recommended ? jimstim, MS2 ? and the hardware hc12

Dave

[jharvey]

Hello davecramer and welcome along.

If you haven't already found it, I'd say first look at the wiki found via freeems.org. The bare min setup for hardware as shown in Fred's proto is a TA card, some MOSFET's and a couple other small parts for the RPM pickup. The Jim stim probably helps, but I seem to recall some folks also made use of a sound card for simulation purposes.

[davecramer]

I read somewhere on the forum that someone here was developing a simulator ? Is that true, what state is it in ?

this is something I'd like to start with if it isn't being worked on.

Dave

[jharvey]

I recall a some talk about using a sound card for a simulator, but I think that fell by the way side. The Jim stim has lots of existing field testing and has some very mature firmware. Using it helps keep the focus on new dev instead of re-inventing the wheel.

[davecramer]

Well, one thing is that the jimstim is not open source. It appears we are re-inventing the wheel with free-ems, so why not the simulator ?

What does jimstim do, or more correctly what would a good engine simulator do ?

Dave

[Fred]

Point you at a problem? Hmmmm, let me think about that!

The JimStim isn't open source, but the author isn't an arsehole, he's my favourite forum member! As Jared said, it's a tool, and lets us focus on what we're doing. I guess there is no harm in creating an open source stim of some sort, though, as future FreeEMS users will also need to bench test their devices before installation or while debugging various things.

The simulator you read about was being devved by an ex forum member called Alex. He never got anywhere with it, or the EMS he thought he would build to prove how wrong I was doing this.

Fred.