On Fri, Mar 16, 2018 at 9:28 AM, Grey, Chris UTC CCS < chris.g...@automatedlogic.com> wrote:
> Anyway, what I'm wanting to do is harness the power of the PRUs to speak > to the onboard processor, a Ford-specific derivative of the 16-bit Intel > 8096, called Intel 8061 (single bank) and 8065 (4-bank capable). They range > from 12MHz to 24MHz clock cycles, where the 8-bit memory-bus runs as 1/3rd > the processor clock. I want to, on the fly, emulate the PROM by sending the > processor opcodes and operands that basically marshal data to/from the > Cortex A8 and the EEC's processor's I/O thus relocating all the engine > management logic to code running in the Cortex A8 and turning the EEC's > processor into a slave co-processor that does nothing more than read the > inputs, write to outputs, and inform of events (i.e. interrupts). The > details of how that can be done, I think I have a good handle on. > I can't really help you (don't own a Ford and have no experience tuning EECs) but this sounds pretty interesting. As I was thinking about it, I had some questions. As far as I understand, the original EEC effectively runs a simple RTOS, and probably can be thougt of as a bunch of coroutines that each serve some engine management function: one might be receiving the crank angle sensor, another would calculate the timing sequence for current external conditions (temperature, RPM, etc), and yet another would activate external devices such as the fuel injector and spark coil, based on this timing. To replace the OEM EEC you'd need to know the details of all the components. After all, if you exceed their design limits, you could damage the engine (e.g. if you consistently pre-ignite and knock the engine to death). You seem to suggest fooling the EEC by giving it synthetic data and instructions; I think you are trying to use the pieces of code in the EEC that are presumably correctly written for the engine by its manufacturer. This is clever: you treat the EEC as a library interfacing to specific low-level engine hardware. Another advantage is that you don't have to replicate the weird analog electronic interfaces to various sensors and actuators, but rather use the ones already present in the EEC. Is my understanding correct so far? How are you going to deal with the following issues: - I believe you still need to disassemble and reverse-engineer enough of the EEC code to identify those individual services, so that you can call them out - the individual services are probably inter-related, and may depend on each other rather than decomposing cleanly---e.g. the spark routine may depend on being called within 1ms of the fuel injector activation. - the OEM EEC code probably contains some integrity checks like watchdogs and inter-coroutine checks, so you will need to fake them out. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgHX55EjZCs8LG4ykgzNvJMKP_GAi9e4xEe8KT8ayPfC1A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
