[dualdj1]

Hey man you still around? How's the DEC project coming along?

[decipha]

yep i frequent here often, its my first stop in my online loop lol

I have a dec v2 now since i changed processors, i talk about it in the dec section in my sig, ive been spending a good deal of time on it lately just cleaning stuff up, ill probably be putting together 10 or so new alphas with my tax return, just hoping uncle sams as good to me as i was to them

[cgrey8]

What's the new processor?

[decipha]

4x ARM Cortex M3s @ 84mhz 96kb sram each

the old beta used 4x atmel 2560 16mhz ic's, since then i've done a significant amount of recoding to upgrade to the 4x ARMs, now the DEC only supports 12 cylinder engines natively (down from 20 before), what i mean by natively is that 1 DEC can only support up to 12 injectors and 12 ignition coils, now here comes the cool part, i've been working on the code to have two or more DEC's daisy-chained together and thus can support up to 24 injectors and ignition coils in sync for 24 cylinder engines or for 12 cylinder engines with dual injectors and/or coils!!!

I just recently dropped the cluster screen idea due to price and have instead decided to go with a generic 7" lcd touchscreen that can be mounted anywhere

[cgrey8]

Are you going with that many micros to get the I/O pin count you need? Or are you finding you need that many MicroControllers (MCs) to meet timing requirements? Or what? I have to believe that there is an expensive enough MC out there that is powerful enough and with the I/O count to do this. But I could be wrong.

One of the architectures I've wanted to do is a similar setup based on the Spear which is a Microcontroller based on a Cortex A9 AND a Cortex M3 built into the same die. That way, you can run Linux and Java on the full-up A processor making coding and development much more flexible and easy to use. Then the real-time stuff that require critical timing requirements (i.e. injector pulsing, spark timing, etc) can be done by the M3.

The BeagleBone Blacks use a TI AM3359 processor which is a Cortex A8 that tops out at 1GHz. It also has 2 PRU sub-processors to handle the ultra-real time stuff. But you gotta be creative how you do the real time stuff since the PRUs only have about 4kB of code space...that's only about 1000 instructions...so you gotta code those in assembly so you can make the best use of memory.

[decipha]

I need the pins, i think the fastest automotive grade ic is only 128ish mhz (freescale), the faster ics dont do too well with automotive environments, or at least they arent rated for it, over time they have a tendancy to break down, or so ive heard, as far as the time restraints, one IC is perfectly capable of controlling an engine. Im always trying to make the code more efficient, but for reference, currently I have a complete loop occurring about every 5000 microseconds (200 - 210 hz) which is pretty darn fast as compared to say a GUFB ecu which loops about every 36,000 microseconds (from what i gathered from sailorbob, he sent me some logs that you made for him a while back when he was testing some things), which says alot considering i onlu used one IC for that test

I met the programmer and owner of adaptronic a few years back, we had a convo about our ECUs and he used texas instrument IC's at that time, he said if he could do it again he wouldn't have used them, he didnt tell me why though and i didn't ask but he told me to stay clear of them for ecu's, at that time i was just getting involved with the atmel 2560s, so i just kept on

it would be impossible for the dec to run realtime operations on only 4kb, the most important routine that makes everything tick is the cognitive and operation routines, thats not to mention all the other interrupts that would have to be done in realtime as well, just the cognitive routine is well over 1000 instructions and thats just to assign which PID has priority.

If you were to only support a specific ignition and coil setup im sure you could squeeze it on 4kb, my operation routine is where the registers are actuated for the injectors and coils as well as the timing calculated, unlike ford that has a timing interrupt that expires so many microseconds (100 usec??), i calculate the time to the next event then just set an interrupt to expire right before that time, i even have that wait time on a PID feedback so i dont have to burn up clock ticks doing NOPs so the execution occurs at the exact usec intended

My operation routine can control an engine on its own as far as realtime calculations are concerned, pw, dwell, and advance are calculated in the pw and spark subroutines in the primary loop, thats only about 50 instructions

I still dont see how you would be able to run much of any code on the OS based system?? I cant think of any code that can run at less than optimal speeds other than fan control, egr and emissions controls, fault codes and diagnostics.

Everything else that may occur less frequently may still need to be updated rather quickly during a quick throttle change

if it helps any, if i were to cut all the extras out of the DEC (gps, ieee, bluetooth, canbus, abs, car alarm, video, diagnostics, transmission control, manual overrides, blah blah blah and etc...) and just compile it to operate a single engine bare bones style without any cognitives (no adaptive learning other than PID feedback), id guesstimate i could do it in about 12kb of flash

[cgrey8]

If I did this, I would have to break the logic into layers. For instance, I'd have all the high level logic going on in the non-RTOS OS environment which would include determination of spark advance, fuel requirements, shifts, etc. All that can be determined in a 1GHz processor quite easily and fast. And because it has lots of memory, a Java architecture using JIT & HotSwap and hardware pipelining along with hardware-based Floating Point Unit calculator could keep up with those calculations even if they were based on 4 & 5 dimensional arrays. So a lot of what the OS would have to do is "feed" an RT-based processor the info it needs to do its job...lots of memory sharing.

So just to give an example, the OS logic would analyze the RPM & sensor data. Based on RPM, MAF, ECT, Time since Crank, etc, it could calculate what the injector PWs need to be and pass that to the RT-logic to actually make happen on the I/O. It would do this for all the outputs that are time-sensitive. Thus it could calculate the spark advance, EGR%, all the high level logic stuff. It'd be up to the RT-processor(s) to actually implement those decisions. But that's ALL the RT logic would have to do is implement the commanded values, not figure out what they should be.

That works great in theory. What I don't have a feel for is if there'd be any detectable lag between changes in engine load that doesn't get to the high level processor in time for it to change the commanded fuel value before the engine needs it. With a high speed processor that can run 1000s of instructions (more like 10s of 1000s) per engine ignition, I don't see why this couldn't be done.

One of the things I had to learn is faster processor doesn't mean faster performance at an RT level. Granted these new Cortex A8s and A9s are nice. I've got Ubuntu running on a Freescale Cortex A5 and unless I told you or you went exploring for the processor type in Ubuntu, you'd never realize you were on an ARM, not an Intel processor from a UI perspective. So they are FAST. And if you ditch all the UI stuff and run a Cortex Aseries processor with an RTOS, you can get even more brute-force performance out of them. But they still don't "reliably" handle RT tasks as well, yet, for 1 reason. They have an MMU which translates virtualized addresses into real memory addresses. And as such, it takes time loading and unloading that MMU when task switching happens in a combination that requires a swap-out. It takes some 3000 instructions to swap that out...that's regardless whether it's running an RTOS or non-RTOS. What these processors are not well adept at is responding to interrupts. That never made sense to me how these A-series processors could possibly function on a 1GBaseT Ethernet without dropping packets or getting bogged down until I asked the question. In a generic use case, they have peripherals that use DMAs and buffers to ease that burden. So that Ethernet controller that's capable of 1GBaseT isn't interrupting the processor on every frame that comes in. It loads memory with up to 100 frames, giving each one a buffer descriptor, then interrupting the processor to clear the buffer either after a certain amount of time or after a certain threshold of frames have been received. Once the processor has transitioned to processing packets, it can do so VERY fast as well as loading up memory with its responses and passing those to the controller. So even at that level, the hardware is doing what I am wanting to do...break up the real-time logic and the non-real time logic.

Now lets translate this to automotive needs. A V8 taching 8000RPMs has roughly .00375sec/ignition fire. A 1GHz processor would have 3,750,000 cycles/ignition. Even with the Linux overhead, MMU swaps, Java inefficiencies, etc, I can't imagine any calculation that can't be done with that many cycles. My point is that you harness what the Cortex A-series is great at and do the logic that it can do in an environment that is easy to debug, easy to program for, has lots of memory, lots of Open Source support, then you can get a lot more done faster (and with open community help) including making some very complex algorithms and data-sharing with a PC running something like BinaryEditor. Then limit the RT stuff as much as possible to only what absolutely has to be done at those levels, even if it means having multiple Cortex Ms just to get the pin count. If that architecture can be made possible, this seems like something worth at least trying. I'm not saying you'd want to implement this on a 2013 Mustang 5.0L. You'd probably want to develop this on something super-simple like as a GUFx EEC replacement. Get that running well. Then expand into EDIS, trans control, PATS, OBD-II, dash, ABS, etc etc. I'm sure there are people out there that would love to contribute to a project like this if they could work in an architecture that allowed them to isolate their focus to, say, only OBD-II comm parsing, implementing EDIS, or trans control. But purely RTOS or assembly-based architectures are difficult for people to learn and feel comfortable contributing to. In those environments, one-misstep and new code is suddenly breaking behavior of existing code that was working just fine.

Thoughts? More importantly. Is there anybody out there with hardware experience that would be interested in such a project? I've had ideas like this mulling through my head for a LONG time. But I don't have the expertise, at the hardware level, to put something like this together. If I had only myself to rely on, it'd be easier for me to create a J3 device that spoke to an EEC's processor like the QH & TwEECer do just to get the I/O I need to work with an off-the-shelf product like the Beaglebone Black or Raspberry Pi (which has WiFi). Although your idea of completely eliminating the EEC and controlling it completely with your own hardware is much more ideal.

[decipha]

with a gig of processing juice, i would think you should have more than adequate processing power to calculate what you need from a processing standpoint, it would probably depend on how much overhead you think your stripped UI will require?

i guess the real question would be how fast can it execute a correction? From maf or tp reading to calculate pw/spk then spit it out to the IC to actually occur?

transient fuel and spark are where the most critical timing events occur, tip in/shift knock and lean/rich spikes during a high RPM shift requires some pretty swift adjustments, thats where id recommend testing first to see if your hardware design is feasible

throttle response is by far the most critical aspect of any performance ecu, the newer GMs have over half a second of throttle response dead time which makes driving a 2013 GM truck very disatisfying at least for me, others i have spoke to agree as well
I find that just remarkable

[cgrey8]

Transients are where any "complicated" work in the RT would be. What I don't know is if "close enough" is "good enough". For instance, lets say you had an RT processor monitoring the TPS as well as controlling the Injectors & Spark. It did nothing else except monitor TPS and control 8 injectors & a TFI/EDIS. Since it would be the 1st to see a radical change in TPS, it seems you could add some sentiments of initial transient control to it. So if TPS changed by more than some threshold, Spark advance was dropped by say 25-50% and Injector PWs are increased by the same amount. And this would only be done if the main processor didn't update the fueling and spark advance values before it needed to know them. The theory is worst case, you only get 1 cylinder ignition that has to operate on these guessed-at values. The next cylinder should have updated values from the main processor. Is that good enough?

Keep in mind, my flat % adjustment is just an example. It could be more elaborate such that the amount of PW increase or Spark Decrease is configurable and scalable. But my point is how noticeable is it if 1 cylinder fire operates with more spark than it should or with not exactly the right amount of fuel? Also keep in mind, this RT processor also might accept as input, current RPM if it isn't monitoring the PIP to start with. So current RPM could play into it's estimate of a sudden transient change.

Another question. How good are the GUFx era EECs at responding to these same conditions? For instance, how quickly can a GUFx era EEC get spark advance updated on a throttle-snap? What if Injector PW values have already been calculated and given to the HSO in the 8061/5, then the throttle snaps, can the EEC update that output to fire for longer even though a PW is already in progress? Or perhaps is physics on our side for this in that air in the intake can't move fast enough from the TB to the cylinder to matter for 1 cylinder? At low RPMs, I think it could (i.e. off-idle-to-WOT snap). But a 2-3 shift where the engine is going from redline down to ~4000, the RT processor could probably remember a "very recent" WOT PW and reuse that unless/until an update from the main came in.

BTW, I just realized I'm hijacking the thread with all this. Should I split this out to another thread or is it kosher to leave it here since this thread was asking about the dec and was started in the lounge anyway?

[decipha]

should leave it here its all relevant

close enough is good enough, 1 cylinder won't make a huge difference, you might get a tip in knock

the problem with using the end of injection for reference to back calculate the start is that if that injector is already spraying, it may not have enough time to continue the spray before the valve is closed, but like you said i have no idea how that would come into play with cylinder filling since i don't know if the velocity of that cylinders airspeed would increase that fast

i find all the eec-4s are a little laggy on quick throttle changes, i'd guesstimate a few loops at least maybe up to 200msec of delay? just from my observations

you'd probably have to ask sailorbob, mpaton, tvrfan, fraser, bill, svojon, or one of the many other folks that have dabbled with gufb ignition and fuel assembly to know for certain about the transient pw compensation during injection, i've always went out of my way to avoid looking at how henry controlled spark and fuel directly so i could come up with my own calculation not being influenced by his, one of the primary reasons why i even began with the ecu was for the challenge lol

[cgrey8]

For the purposes of open source projects, I don't have a problem with taking some good ideas of how they've done things, and coming up with similar ways.

And for legality issues, I doubt that's a problem since the only way this could be considered legally actionable is if code was copied verbatim or exact (i.e. patented) control strategies were duplicated. Since I seriously doubt there's a mfg out there that would do what I'm thinking, I don't think there's any way what I came up with could be anything but "similar." And of course, open source code is much more difficult to take action against. The legal eagles tried a few years ago to shut down Linux for similarities to certain versions of Unix. They failed. They tried again when alternative Java VM implementers started getting successful. Again, they failed. And the only reason they bothered is because they though there'd be money to be had. Not to mention, any Patents based on stuff as old as GUFx have long since expired.

An open source project like this has no money, no real business strategy built around it. It'd just be contributors and possibly Clint if he had any interest in BE being the front-end. I did assume Moates would be the maker of the hardware since I have no desire to be a manufacturer and supplier. He said he would be willing to do that if he was given design docs and BOMs on how to build it. I just want to have my hands in the code and development. And I have no interest in making this a source of income. Although if others do, that's fine with me.

Another thing I would want to do is not implement fueling based on HEGOs. Even if I reused a stock EEC as my I/O, I would use the HEGO inputs as WB inputs and require anybody using this system to replace the stock HEGOs with WBs that had their controller configured to output 0-2.56v so full-time Closed Loop fuel control could be employed. The only OL conditions would be initial crank and detectable WB sensor failure conditions.

[decipha]

Im not concerned with legal crap either i just wanted the challenge of figuring it out myself

i too talked to craig a while back about making a standalone ecu and he told me pretty much the same thing, it wasnt something he wanted to spend the time on

I have 12 o2 inputs, you can use either wb or narrow