HOMEBREW EMULATOR

[buddrow]

Ok so I have looked at a few options for a homebrewed emulator, more for fun than economic issues. Does anyone have any info on how they did it, etc? Ive looked at a few online "projects" and it's pretty straight forward but was wondering if anyone here has done it successfully. Any insight is greatly appreciated.

Thanks,

Buddrow

[Six_Shooter]

If you've found successful emulator projects I'd be interested in seeing those. All I was able to find a couple years ago was basic ideas, partial schematics and end to journeys.

[buddrow]

As of late all I can find are parallel port devices, which isn't a huge issue but a little too old school lol. I am researching what I can find and will share what I have after I get it sorted through and indexed. If you would like to collaborate on this project that would be great. I have considered a pseudo-emulator/bin switcher device but a little hokey to me. I had looked into an arduino based unit but they don't carry enough memory on board to be effective even for a 4k bin. Will likely be pic based or arduino with external ram chip or???

[jdarg]

An Arduino mega has 8K of SRAM and would work, but I don't think its quite fast enough to decode the clock/address lines and gate the data, although I haven't tried it so who knows, maybe it is.

When newer Arduino's w/ faster IO speeds come out it will be possible to emulate w/ an Arduino. The existing emulation products probably use FPGAs.

I'm working on an open source OBD1 project based on an Arduino, bluetooth module for ALDL stream logging, and 2mbit SST flash eeprom. Frankly I think full emulation is overrated since you can write a 4K flash image in a couple of seconds anyways. Yeah the engine will stumble for a split sec and might throw a PROM code unless you disable that MALF code in the BIN, but for most purposes it works just fine.

http://www.gearhead-efi.com/Fuel-Inj...ftware-project

[buddrow]

Im lookong at emulating up to 64k bins so ram size is a concern as well as processor speed. Emulation is more a time saver for me since most of my tuning is while flying solo so any increase in speed is a plus and i like gadgets so...;) I know the pic mc's can handle the overhead so its probably the route i will go.

[RobertISaar]

i've looked into this as a design exercise before and to expand my electronic knowledge a bit....

what i came up with as the best combination of compromises(IMO) was to use a full-size(so 64KB) dual-port RAM chip and some other microcontroller between it and a PC, send full BINs over USB and have the microcontroller write the new BIN into the RAM chip and it's ready to update at any time with no issues. obviously, the dual-port RAM would need to be of the NV type to keep all of the data after key-off, but that is easy enough to do without grabbing 64KB NVRAM modules.

i got far enough to know it's possible..... and then i realized i can't do any of the software on the PC side and archived my work for the future.

[buddrow]

i've looked into this as a design exercise before and to expand my electronic knowledge a bit....

what i came up with as the best combination of compromises(IMO) was to use a full-size(so 64KB) dual-port RAM chip and some other microcontroller between it and a PC, send full BINs over USB and have the microcontroller write the new BIN into the RAM chip and it's ready to update at any time with no issues. obviously, the dual-port RAM would need to be of the NV type to keep all of the data after key-off, but that is easy enough to do without grabbing 64KB NVRAM modules.

i got far enough to know it's possible..... and then i realized i can't do any of the software on the PC side and archived my work for the future.

Robert, I would be very interested in seeing what you have. would you consider sharing your hardware? Myself or another savvy programmer here could write the software side.

Buddrow

[RobertISaar]

i'll have to search for my info in the morning... pretty sure i had everything except for the software figured out.

[buddrow]

Awesome! Dont think im rushing you though. If youre like me time is a precious commodity in short supply. I do appreciate your input and hard work. Makes my task easier obviously lol.

Bddrow

[RobertISaar]

i think some of my info got misplaced or deleted.... some of it still exists, but a lot is gone.

anyways, i took a quick look around and couldn't easily find any 64K X 8-bit dual-port SRAMs, plenty of 32 and 128 though. connection to ECM is pretty simple, just match up address and data lines. the microcontroller side.... that will obviously depend on the micro. i think i was looking at a high pincount ATMEL unit and was going to toggle the data and address lines directly.

[buddrow]

Been looking at some netduino stuff that use a ST chip. Looks like it has enough onboard sram so it might be an easier solution. Still reading and researching.

http://netduino.com/netduinoplus2/specs.htm

[jdarg]

Im lookong at emulating up to 64k bins so ram size is a concern as well as processor speed. Emulation is more a time saver for me since most of my tuning is while flying solo so any increase in speed is a plus and i like gadgets so...;) I know the pic mc's can handle the overhead so its probably the route i will go.

Some more thoughts...

You don't need 64K on the ucontroller for this. 8K is overkill. You are going to be hooked to some other device (Windows PC, etc.) to actually tune, right? If so, the ucontroller only has to act as a pass through between the host and SRAM. The host software can take care of initializing SRAM, etc. and from there you are really only tweaking a byte at a time. The microcontroller is just passing bytes from serial to the SRAM. It needs no more than a few bytes storage to do this. If you think about it it needs only store 3 bytes - 2 bytes for the desired address and 1 for the data.

Now if you want to emulate without a host connected, things get a lot more interesting and complex.

64Kx8 dual port SRAM's have a high pin density. This makes them pretty complex for DIY because you can't get them in a DIP package.

i have an idea on how this could be done with an Atmel microcontroller and single-port SRAM but I'd need to actually put together a PoC before I would say it would work. The problem is the dual data/address bus management would need to be done through glue circuitry vs. within the SRAM.

[buddrow]

Some more thoughts...

You don't need 64K on the ucontroller for this. 8K is overkill. You are going to be hooked to some other device (Windows PC, etc.) to actually tune, right? If so, the ucontroller only has to act as a pass through between the host and SRAM. The host software can take care of initializing SRAM, etc. and from there you are really only tweaking a byte at a time. The microcontroller is just passing bytes from serial to the SRAM. It needs no more than a few bytes storage to do this. If you think about it it needs only store 3 bytes - 2 bytes for the desired address and 1 for the data.

Now if you want to emulate without a host connected, things get a lot more interesting and complex.

You must be reading my mind lol. I had a similar thought last night. Basically gonna be a pass-thru. I have a. arduino mega on the way for testing and future use on other projects. Thanks for the input.

Buddrow

[RobertISaar]

The problem is the dual data/address bus management would need to be done through glue circuitry vs. within the SRAM.

this is why i started looking at dual-port..... the circuit complexity goes sky-high compared to the relatively straight-forward connections that the dual-port route offers.

that and i was looking for seamless changes, i couldn't come up with a method that would allow for the processor to continue on without any hiccups/halting the processor while using a single RAM module.

[buddrow]

I'm looking at software switching of the address which may require a few hw pieces but i dunno yet. when me mega board gets here I'll be able to test theory and see what reality presents. :)