[decipha]

I just swapped a quarterhorse at the moates estate last week, craig handed me a qh with the replaceable battery holder

no more worrying about a dead battery on it, that and with the correct resistor its a non issue

[Cougar281]

What I've been told is at this point, there are only a few prototypes in existence, and that there pretty much certainly won't be anything on it until 2016. When in 2016, no idea.

[decipha]

the problem with the qh2 is that the sram isn't cheap, how many reasonable would shell out $500 for the qh2 when the quarterhorse for half the price does the exact same thing?

[ollopa]

the problem with the qh2 is that the sram isn't cheap, how many reasonable would shell out $500 for the qh2 when the quarterhorse for half the price does the exact same thing?

I think you meant MRAM. QH1 is backed by SRAM and all SRAM is volatile. I wonder why QH couldn't just use flash memory like EEC-Tuner and TwEECer, though.

[cgrey8]

I think you meant MRAM. QH1 is backed by SRAM and all SRAM is volatile. I wonder why QH couldn't just use flash memory like EEC-Tuner and TwEECer, though.

It could. But dealing with flash is more complicated where MRAM is a drop-in replacement for SRAM (from a logic/programming perspective).

Flash, on the other hand, requires that the writing processor:

• Put the memory in "write" mode
• Flash (i.e. erase) the sectors to be updated
• Write the new data
• Return the part to "read" mode

During this period, the other parts of the flash are not accessible. So performing a write while the EEC is also reading from the flash can't be done. This is why the TwEECer reverts to the stock tune when it is being written to. For most setups with aftermarket MAF and injectors, this means the engine can't be run since the stock tune isn't capable of running the engine...at least not run it well.

On the other hand, the QH can run the engine with no problems while a new tune is being written from the PC which was a significant selling point for the QH over the TwEECer. On the single-bank EECs, it accomplished this by maintaining 2 copies of your tune in memory. While writing to one, the QH is serving up the other tune. Then the PC writes the other tune, and the QH serves up the tune just written. With this, the EEC is never served a tune that's in the process of being replaced.

The QH has 2 SRAM chips although I don't believe that's related to its ability to write and read tunes simultaneously. It might have made programming the processor and CPLD-logic a little simpler, but even with a single SRAM chip, I believe this would've been possible. However it is not as common to have multiple flash parts on the same bus. So simply plopping down 2 flash parts probably wasn't an option or not an easy one to make work.

Now if the QH was something being developed today, my guess is a combination of DRAM and eMMC would likely be used. Altera makes an FPGA with a hardened ARM Cortex A9 processor so you could run a full-up Linux distro and glean all the benefits thereof including having Ethernet or Bluetooth wireless ability which would be far more convenient and reliable than USB. But that's not an insignificant development effort.

[ollopa]

The way I would have done it is to have an SRAM backed by the KAM power rail for working memory and flash for long-term storage. Whenever power is lost and restored, the contents of flash would be loaded to SRAM so you'd never be stuck with a dead car.

You could use DRAM in self-refresh mode when the car is is off, but I think the SRAM still has lower power consumption and 4Mbit 12ns SRAM can be had for less than $5, so it seems a reasonable choice.

An FPGA with a hard CPU core would be interesting, but you'd want to do it in such a way that you don't have to wait for Linux to boot before you can start your car. If it's only real function is an Ethernet and BT stack, it might be a little overkill to go with A9/Linux over a Cortex M4 and RTOS.

If only there were time to build all these ideas... :)

[cgrey8]

The way I would have done it is to have an SRAM backed by the KAM power rail for working memory and flash for long-term storage. Whenever power is lost and restored, the contents of flash would be loaded to SRAM so you'd never be stuck with a dead car.

Yep. That would work too...but just wasn't what was done. I don't know how much built-in flash the processor has. But my guess is it isn't that much.

...You could use DRAM in self-refresh mode when the car is is off, but I think the SRAM still has lower power consumption and 4Mbit 12ns SRAM can be had for less than $5, so it seems a reasonable choice...

I think the SRAM is 55ns...or at least I think that's what Craig said it was back when I talked to him. But don't quote me on that. If you really want to know, check the PN and do some googling.

...An FPGA with a hard CPU core would be interesting, but you'd want to do it in such a way that you don't have to wait for Linux to boot before you can start your car...

Yeah 1st-time boot would take some time. But once booted, I believe it had the ability to be put in low-power sleep mode which could be held-up by the KAM power. Then woken back up to full speed with KOEOn.

...If it's only real function is an Ethernet and BT stack, it might be a little overkill to go with A9/Linux over a Cortex M4 and RTOS....

Probably a lot overkill. But I've had in my head for a number of years that I could abandon the whole idea of serving a stock tune and instead write the entire logic in something like C++ or maybe Java. Then use the FPGA to simply feed the EEC's processor opcodes to fetch its sensor data and receive data to write to its outputs. You could use the interrupts as sentinels to do timing and be aware of events. But when you are in control of memory (inc stack), you don't ever actually have to adhere to programming standards. You could ignore the concept of a stack so there's no stack to blow. Unless an ISR return actually unsets registers to allow other ISRs to be triggered, you wouldn't have to ever return from anything. You just have to make sure the PC never rolls over and goes to an address below 0x2000 (outside of your device's control). Otherwise just keep feeding the processor whatever you need it to do, pet its watchdog from time to time, and record when ISR's call their respective memory locations. The set of opcodes you'd ever need to feed the processor would be a vast subset of what's seen in a BIN. The work would be having the Linux processor keep enough stuff pipelined for the EEC processor to do to keep it busy. Obviously there's a WHOLE lot more to making that work. But I think it's possible to be done...basically turning the EEC processor into a coprocessor. And do all the control logic in an easier-to-read/easier-to-maintain language that can be updated and interfaced via a PC in a far more modern way. With devices like BeagleBones, it's becoming possible. The TI AM3358 processor it has 2 8-bit PRUs (Programable Realtime Unit) which could probably do what the TwEECer & QH CPLD is doing. So it's not completely outside the realm for something like this to get developed in the open source community as long as there was a hardware mfg that was willing to design the hardware aspect of it. I'm a firmware developer, so I could handle the Linux and programming aspects. What I couldn't do easily is make hardware. I'd be reliant on off-the-shelf parts like the BBB or Raspberry Pi which really aren't ideal for an automotive environment.

Oh yeah, and then there's writing a software frontend for this beast. Whether that be an HTML/JS interface served from a webserver in the device or an installed software like BinaryEditor would have to be also figured out.

[ollopa]

That's a pretty unusual concept :) I could see that working but if you're going to go to that extreme then you're probably better-off just playing with a MS instead. Of course I never really cared for their CPU choices and their code is a rather nasty mix of ASM and uninspiring C.

I still think you'd be better off starting with the MS hardware and replacing the CPU with something that wouldn't require hand-optimized ASM for the ISRs to meet timing than investing all that energy into a BBB EEC-orchestrator... Still an interesting idea!

[Shaker666]

My Gawd, the MS source makes me cringe; it's very poorly engineered from a software POV, hard to maintain. No way I'd choose one over an EEC setup, especially given the cost differential.