sim's Volvo 245 comments

[sim]

That's exactly it! I should have mentioned this before, however
it's a relatively new thing anyway, but you need 100k pull to
grounds on all key output pins, IE, PT2-7 and PA7 in your case,
for the time being. That will tie them to OFF when you're in SM
mode or reset conditions, IMPORTANT for the health of your coils,
rings, rods and head gasket! Sorry for being slow letting you
know about this. Glad you brought it up. If you connect your coil
and injector supplies to relays that are switched with the fuel
pump, then you can get away with not doing it, however I still
recommend it for consistent results. See this video for something
similar... nope, didn't upload it, no idea where it is! Sorry.
I've seen this on Puma and Sean0 has seen it on his TA setup too
and it's understood why it happens.

I figured it would be something like this.

What does PA7 do? I haven't hooked it up to anything yet.

So a 100K Ohm resistor pull down to ground on each of the Port T
output pins will sort this out?

Nothing on PT0 and PT1 though, right?

Remind me to make another diagram of the schematic after getting
this thing running. The pen sketch a few posts ago is already out
of date.


I'm still working on getting a build environment for the
firmware. The .debs on the FreeEMS server are all built for i386,
I run a amd64 kernel and userland here. If I need to be 32 bit, I
can spin off a 32 bit Xen domU for the purpose, I guess.


Also, I will need a output pin for driving my tachometer. It
takes a 12v pulse from the low tension side of the coil at every
spark. I just got around to installing the tach a month or so
ago, so it is certainly not critical, however I have become fond
of it, and expect the extra information will be helpful while
debugging stuff. It will look kind of dumb if it is pinned at
zero RPM all the time.

The old style 240 dash puts the tach front and center, where it
belongs.


Tomorrow, I'm going to try to obtain a couple of suitable MAP
sensors at the Pick-n-Pull yard. I think I can pull a
conditioning circuit out of RavAGE or Cheetah for them. I expect
there will be a trip to the electronics shop between getting the
sensors and installing them.


It feels a bit silly, I've got an embedded processor that is
quite likely more powerful than the 386 I first installed Linux
on all set up to run my engine, yet I'm only using 8 bits of IO
to do so. Wild. There are many things to hook up yet, however.

[Fred]

What does PA7 do? I haven't hooked it up to anything yet.

Via some sort of driver arrangement, it switches the relay that controls your fuel pump, which you've not installed yet, for the EFI that you don't have yet :-)

So a 100K Ohm resistor pull down to ground on each of the Port T
output pins will sort this out?

Yes.

Nothing on PT0 and PT1 though, right?

Right!

I'm still working on getting a build environment for the
firmware. The .debs on the FreeEMS server are all built for i386,
I run a amd64 kernel and userland here. If I need to be 32 bit, I
can spin off a 32 bit Xen domU for the purpose, I guess.

I could be wrong, but the i386 stuff should "just work" on a modern 64 bit Linux, right? In the event that that isn't possible, Dave has a repo with 64 bit debs in it somewhere that we need to work to integrate into the main repo. I might add a note to the tools site about that. If that can't help you, the sources are all public and on Dave's and Sean's github accounts, somewhere. I've not built the tools for a long time, so I can't advise on that. What I do know is that order is critical in the build.

Also, I will need a output pin for driving my tachometer. It
takes a 12v pulse from the low tension side of the coil at every
spark. I just got around to installing the tach a month or so
ago, so it is certainly not critical, however I have become fond
of it, and expect the extra information will be helpful while
debugging stuff. It will look kind of dumb if it is pinned at
zero RPM all the time.

I currently have no good solution for you. We can try a few things and see how they go, though. I was hoping to avoid this problem for a while, but I guess not! :-p What I'm certain about is that there will be other things you want sooner than this... IE, various basics that should already be in the code and aren't.

The old style 240 dash puts the tach front and center, where it
belongs.

Absolutely, I like your style! :-)

I think I can pull a conditioning circuit out of RavAGE or Cheetah for them.

RavAGE, yes, Cheetah, no. Cheetah is just a bunch of ideas right now. Puma may have something for you. Or DFH.

It's just an ADC input conditioning circuit, though, so it's very straight forward and just like the others that you're soon to build (may as well do them all together?)

Have a read of the bosch recommendations, the freescale recommendations and the freescale special note as mentioned in the mpx4250AP datasheet.

It feels a bit silly, I've got an embedded processor that is
quite likely more powerful than the 386 I first installed Linux
on all set up to run my engine, yet I'm only using 8 bits of IO
to do so. Wild.

You could do it with just 4! MAP, CrankRPM, wasted1, wasted2 :-)

Fred.

[jharvey]

I'm still working on getting a build environment for the
firmware. The .debs on the FreeEMS server are all built for i386,
I run a amd64 kernel and userland here. If I need to be 32 bit, I
can spin off a 32 bit Xen domU for the purpose, I guess.

In the event that that isn't possible, Dave has a repo with 64 bit debs in it somewhere that we need to work to integrate into the main repo.

Yeah, Fred's saying good things about Dave's repo. I've also needed to go 64bit. I've found Dave's repo to be the cat's meow. Fred has had some concern about revision numbers or something like that, I felt like Fred was simply being resistant to including 64bit for some reason. I've trashed with Fred that 64bit isn't a bad idea, in my case required for other software. If you need any help, let me know and I'll see what I can offer. You will likely find good support from Dave, look for dandruczyk he's quite good and helpful.

[Fred]

Nope, I'm not in any way anti 64 bit :-) I am in every way fussy about versioning and tracability etc, and although I *absolutely* trust dave's work, there wasn't transparency (to me at least) in the way it was done. I want to get his work integrated into the main repo, but in a way that can be taken forward by anyone in a predictable and repeatable and traceable way. That's all.

Jared, can you dump your sources.list file here for us please?

[sim]

My understanding is that 32 bit binaries will run just fine on an
amd64 system. The problem is that Debian treats i386 and amd64 as
different architectures, and apt refuses to install a .deb
targeted at one, on the other.

If there were source packages, it should be possible to just do
./debian/rules buildpackage or whatever and create a .deb for
your system. That assumes that everything has been packaged
up properly and to the Debian projects specs, this is somewhat
non-trivial to do correctly.

It's been a few years since I've packaged software for Debian,
and I appreciate that it is a chore to do. It sure is great to
have the software packaged though.

If there are 64 bit packages out there, I'll use them, otherwise
I'll either try to build amd64 packages or use a VM to build
firmware, no big deal.

[Fred]

There is a command to tell it to ignore the arch! I forget right now, but wait, I will google....

Code: Select all

sudo dpkg -i --force-architecture nameofpackage.deb

That should do the trick. Jared is going to send me his list and I'll post the deb repo details for the 64 bit stuff that Dave built.

Fred.

[jharvey]

Don't do it, I seem to recall that buggered things for me.

I seem to recall that would allow FreeEMS to build, but caused problems with mtx, and other software. I seem to recall it was a GTK issue, or something like that. I'll see if I can find e-mail, ect about how to install after you've gotten the repo stuff right.

[Fred]

Code: Select all

deb http://freeems.ipdatasys.com natty binary

http://freeems.ipdatasys.com/dists/natt ... ary-amd64/

Nope, whatever you experienced was unrelated to your repo entry as code boxed above. Sim, give that a shot if you prefer. I used it with Abe on his box and it worked fine.

Fred.

[Fred]

btw:

Code: Select all

	Name	Last modified	Size	Description
	Parent Directory	 	 -	 
	jaunty/	21-Mar-2011 11:38	 -	 
	karmic/	21-Mar-2011 11:38	 -	 
	lenny/	21-Mar-2011 11:38	 -	 
	lucid/	21-Mar-2011 11:38	 -	 
	maverick/	21-Mar-2011 11:38	 -	 
	natty/

you have a choice of dists.

[Joseph Davis]

Hi, sim. Hi, everyone.

You have in your hand a Honda firewall mounted MAP sensor. Honda MAP are all the "same" calibration from 88-present, across four different form factors and three plug styles. I suspect some of the 85-87 MAPs are the same, but certain are not - 86-87 Integra, for example, is more akin to a GM 1 bar with 5 volts being at or slightly above atmo.

Anyway, all is not as it seems with those MAP sensors. They are all limited so that they never reach 5v on the signal line. It's been years since I did the measurements, but the firewall mounted jobbers return up to 4.7x which results in 9.25 psi. The later OBD1/OBD2 throttle body mounted sensor (with the same plug) reads 4.8x volts, which is 10.6-10.7 psi - the Hyundaidata site claims 11.3 psi, but this is a number easily reproduced by rounding errors and is not correct. I'm not sure of the last two flavors used on the K-series cars, but I ASSume they are like the OBD1/OBD2 units.