rusefi.com

Looks like I'm getting a new Arm kit courtesy of stellarisiti.com: http://forum.stellarisiti.com/topic/1805-giveaway-winners-hercules-launchxl-tms57004/#entry5637
I'll be looking at porting rusefi over to it. Anyone interested, it is here and $20 USD; processor information here.

Not quite up to the STM as far as memory and a few other things, like lack of FPU (and if you need FPU you have other issues ), but is definitely a competitive price, and is specifically a 'real-time' processor.

Looks like no ChibiOS support, so that would mean a different RTOS... While on the one hand it would be great, on the other hand that's a lot of change.

Change is good.

abecedarian wrote:Change is good.

What I meant by that is maybe, instead of process driven 'thinking', event-driven is more appropriate?

Events being things like, you have only a few events 'really' happening with EFI:
- key is on and engine is cranking;
- engine is running;
- trigger wheel tooth detected;
- throttle position changes.

Everything else depends on just a few events and though an RTOS might seem like a logical solution, is it necessary?

Nothing about an engine is time-dependent; everything revolves (pun intended) around crankshaft position... is what I mean.
It's all event driven, not time driven, and a co-op multi-tasking RTOS like ChibiOS is all about sharing time and responding to events "in time".

Think (not quite this simple, but humor me):
- tooth detected / TPS change detected;
- - read and update CLT, IAT and MAP sensors;
- - need to fire injector; yes / no?
- - - fire injector if needed
- - need to fire spark plug; yes / no?
- - - fire spark plug if needed

Obviously, more goes on in the background but save for the variability in 'timing' it's all event driven and relates to the crankshaft position, ultimately, when the engine is running.

Actually rusEfi is event driven, pretty much the way you describe it

I need to do a better job documenting the source code, maybe more main page content http://rusefi.com/docs/html/

russian wrote:Actually rusEfi is event driven, pretty much the way you describe it

I need to do a better job documenting the source code, maybe more main page content http://rusefi.com/docs/html/

Maybe I need to pay more attention?

abecedarian wrote:Maybe I need to pay more attention?

http://rusefi.com/docs/html/files.html

The main file has a misleading name main_loop.c - it is misleading because in reality it is main_event_handler, the file is something I would need to change soon.

I can see porting this will be fun.
... likely a complete re-write, actually.

I might even be inclined to buy one for Jared so he can help work out the I/F board.

I have asked a question of there are any ChibiOS plans for this chip - http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=1626

russian wrote:I have asked a question of there are any ChibiOS plans for this chip - http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=1626

TI does have their own RTOS for this. Maybe I'll look at that.

Question is how sweet their HAL is if there is one. The miracle of ChibiOS is that it has a very sweet HAL.

russian wrote:Question is how sweet their HAL is if there is one. The miracle of ChibiOS is that it has a very sweet HAL.

Don't know... maybe http://processors.wiki.ti.com/index.php/TI-RTOS
http://processors.wiki.ti.com/index.php/Category:SYSBIOS


... apparently not TMS570 ready yet.

Hercules' N2HET has an 'angle generator'...
Page 594:
http://www.ti.com/lit/ug/spnu517a/spnu517a.pdf

@, if you are capable of writing code we need you to join the stm32 club - we will port when we have something to port. Now we need to get the whole thing into the air at least on one platform. stm32f4 is not that bad

When I get closer to having my project going, I'll see where things lay.

abecedarian wrote:When I get closer to having my project going, I'll see where things lay.

To clarify:
I don't want to buy / change boards based on someone's whim.
So when there's an I/O board I feel comfortable using, I'll consider.

abecedarian wrote:So when there's an I/O board I feel comfortable using, I'll consider.

I hear you

Not sure what I'm looking at, but it looks like 40 pins or so of I/O.

I have 100 pins ranging from 5 to 3v3 power and grounds, to analog inputs, to digital I/O, amongst which timers and PWM are interspersed.

abecedarian wrote:I have 100 pins ranging from 5 to 3v3 power and grounds, to analog inputs, to digital I/O, amongst which timers and PWM are interspersed.

How many engines did you start with these amazing 100 pins already?

You are looking at a possible future shield for stm32f4discovery - I/O board

nevermind.

It seems you have 100 pins just like me... except you're using up more for GND, VDD, 5V and 3V than I am.

Fortunately, you have USB OTG, it seems.
So, I'll take my JTAG and leave.

Look, no reason to puff chests. Different designs, different capabilities.


But if you really want to ask how many engines have I run... I just received the board 1/14/2014;
... how long did it take, and how many people helped you, before you ran stand-alone?

I'd at least ask for as many man-hours before any comparison be made.

Since I started the topic, thought I should at least give some info about where it's gone.
Set up to sample 8 analog sensors, as it sets- may be able to sample 2-4 more:
- 5v0 out from the regulator, a.k.a. reference voltage;
- throttle position sensor signal;
- manifold absolute pressure signal;
- coolant temperature signal;
- manifold intake air temperature (IAT) signal;
- O2 sensor (should be able to handle either narrow (0-1v out) or wideband (0-5v out);
- two additional "undefined purpose" sensors.

To do: 5v0 rail(s) to the sensors requiring such: TPS, MAP, CLT and IAT... (no sensors grounding to the chassis with this. ).
Probably need some filtering on the analog, but all in time. Digital / GPIO not defined yet.

And sorry, no protection on the analog inputs, yet. All in time.

Is that a shield for the Launchpad or an all-contained board? Cool stuff both ways

russian wrote:Is that a shield for the Launchpad or an all-contained board? Cool stuff both ways

Meant for this.

russian wrote:Is that a shield for the Launchpad or an all-contained board? Cool stuff both ways

Meant for (image is a hyperlink, BTW):


The buttons are meant for the user to simulate faults, with firmware running that detects the faults and can report said fault(s) to a monitoring PC or via LED's on board.
I don't see much use for them in an EFI system, so the LP will mount beneath the board rendered a few posts up.

Sorry for the 'redundant' replies. I was 'intoxicated' and ... well, you know how that goes.

In essence, it's a board that attaches to the LaunchPad from above.
The harness connector mounts beneath the board to minimize height, or "thickness" of the 'system'.
3v3 and 5v0 supplies, both automotive rated to +60v inrush and 2A output... most likely far more than needed.

To do: 12v input isolation, filtering and such; figure out crank position signaling, most likely MAX9926; output controls- fuel pump, injector and ignition triggers and such.

Might do a 'daughter' card to handle injector control....

Yeah, I know I pimped the TMS570 / Hercules board but this should work with TM4C123GXL and MSP430F5529 LaunchPads. Also, the below should be capable with P8X32A (Propeller) MCU's.

abecedarian wrote:Anyone interested, it is here and $20 USD; processor information here

Just got myself one.