GPIO - what do users want?

[jsmcortina]

I read that the GPIO is soon to be released.

Just wondering what people were planning on doing with it?

Obviously I want to help keep MS2/Extra in line with GPIO development.

There are a few main modes of using the GPIO.

1. standalone / almost standalone box that runs its own code and is autonomous.
The trans controller is a good example of this.

2. input/output extender totally controlled by the MS2 master.
There doesn't really seem to be any code to do this at the moment.

3. A bit of both. Semi-autonomous with programming language to process MS2 and GPIO status information and control outputs accordingly.
This is where the existing GPIO code is targetted. However there is not yet a stragihtforward way to create the programming langauge and the interface with Megatune is incomplete.

MS2/Extra status (Dec 07)
-needs updating to latest CAN code from MS2 2.88, appears to have changed in last few releases.
-would have worked with the trans controller code, but MS2 recently changed the block used for outpc, so won't work now
-reading ADCs is possible from GPIO
-as with base MS2, there is no existing INI file to support the programming language and the CAN pass-through is not yet fully working.

James

[Asteris]

I/O extender for me. It would be nice to have A/C clutch control, EGT controlled turbo pressure, traction control and perhaps even immobilizer function.

[6040solder]

would the simplest from a code creation point of view be a cut down version of the existing ms2extra code with no fuel or ignition control and more generally available pin choice for the existing functions?

the ms2 is (as we all well know) IO limited so it makes sense to move the existing functionality off to another ms2 chip or gpio board (ms2 chip on error board is far more compact than a full gpio).

If you could just take the existing code and say
"you are slave"
"your id is X"
"master id is Y"
and use it as is that would please a lot of people right off the bat.
boost control makes sense to get pushed out first as if thats done gear dependent boost control would be easier with the fuel/ign table data out of ram and page space.

in any case i think there should be a compiler flag for the hardware target

micro || ms2 || gpio || xyz

as that leaves it more flexible for hardware choice.

i think io flexibility (designed in to keep distributors happy) has been lacking somewhat. until the other day i didnt realise the gp out code was limited by MT. there must be a way to keep a list of available pins of each type and check them off as they are assigned. or is that in the wait for mtx basket?

exciting times :-)

[6040solder]

I/O extender for me...traction control...

i second those :-)

[jsmcortina]

Too much flexibility can often lead to "option overload" for even moderately experienced users. It wasn't simply comments from distributors that motivated us to keep i/o combinations reduced compared to MS1, it is also documentation. If there are four different ways of wiring something, it makes it a lot more difficult to document in a way that is clear and guides the new user.

For many users I feel that a "ready-to-roll" software solution is what they are after, but right away we run into the problem of more code than available pins.

Also with the CAN pass-through (I add a description of this to my document) not appearing to be complete the remote processing options are more difficult.

Extended "general purpose pins" to cover all GPIO pins and the ability to divert some MS2/Extra base functions onto GPIO pins with the majority of the processing remaining on the MS2 is a possibility. Doing it that way uses existing fully functional comms, but still requires many hours of coding.

James

[hassmaschine]

is it possible to use the CAN bus to control another MS2 CPU for more ignition and fuel outputs? basically, if I wanted to run true COP and sequential injection on a 6 cylinder, using more than one MS board.

[racingmini_mtl]

I don't know if that makes sense since I haven't looked at the GPIO code at all yet but what if each of the MS2/Extra I/O features had a "virtual" pin (in addition to the real ones already there). You would reserve a memory location for each of these.

So if an output is using the virtual pin, you would just write the computed value (on, off, or duty cycle for PWM) in the assigned location and the GPIO would read this from a CAN message and act accordingly (the PWM frequency would be set on the GPIO side). For inputs using virtual pins, the MS2/Extra code would get the actual value from a CAN message to the GPIO and use the value (on, off, ADC count) in its computations.

Of course, that implies some coding on both the MS2/Extra side and the GPIO side. I don't know how much work would be needed on the GPIO side but I don't think it would be that big of a deal on the MS2/Extra side. I may be wrong but from James' documentation, it seems pretty straightforward and it would already solve some of the issues that have been raised with the current features.

Jean

[md95]

Auto trans control
Full COP 4 spark outputs, per cylinder adjustable timing
Full sequencial, 4 injector outputs, per cylinder fuel tuning
A/C button input for idle up
ABS control with speed sensor inputs
4 EGT inputs

Thats all i can think of..individual cylinder fuel and ignition control would be awesome.. For a 4 cylinder, have 4 fuel maps, and 4 spark maps. Make them all identical to start, then adjust if need be. Dont even know if this is possible with memory space though.

[MegaScott]

is it possible to use the CAN bus to control another MS2 CPU for more ignition and fuel outputs? basically, if I wanted to run true COP and sequential injection on a 6 cylinder, using more than one MS board.

You are basically describing the Sequencer board....see - http://www.megamanual.com/seq/

[6040solder]

thats something i've been thinking about too.

running sequencer code or similar on a ms2 card with board mods. discreet components are more diy :-)

[hassmaschine]

is it possible to use the CAN bus to control another MS2 CPU for more ignition and fuel outputs? basically, if I wanted to run true COP and sequential injection on a 6 cylinder, using more than one MS board.

You are basically describing the Sequencer board....see - http://www.megamanual.com/seq/

yeah, it looks really nice, but it will cost close to $600. Another MS2 board would cost several hundred less.

[jsmcortina]

I don't know if that makes sense since I haven't looked at the GPIO code at all yet but what if each of the MS2/Extra I/O features had a "virtual" pin (in addition to the real ones already there). You would reserve a memory location for each of these.

So if an output is using the virtual pin, you would just write the computed value (on, off, or duty cycle for PWM) in the assigned location and the GPIO would read this from a CAN message and act accordingly (the PWM frequency would be set on the GPIO side). For inputs using virtual pins, the MS2/Extra code would get the actual value from a CAN message to the GPIO and use the value (on, off, ADC count) in its computations.

Great minds think alike.

What Jean wrote here is very much what I had been thinking of for the i/o extender. I've already coded some of it a LONG time ago - notice that realtime baro has long had an option for GPIO ADCs. These now work in the CVS code.

The output side is not started.

James

[Keithg]

One thing that has been mentioned is to offload some of the non engine timing related outputs first. Fuel Pump, Coolant and air temp. These are long time constant variables and can deal with the time constant of CAN. On the other hand, it still does not free up any PWM outputs and that only amounts to 3 pins. If boost control and idle is added to this we get 5.

Personally, I do not want to have to build and house another MS unit. I did not find it too difficult with the input/output permutations in MS1, but I do understand the need/desire to simplify things. The idea of virtual outputs in an MS2 and the ability to pass the pertinent data to a daughter board would be very interesting. I am not a programmer and do not know how tough that would be. I do think it would be very interesting to have a small micro on a daughter card to get 4 (or more) real PWM outputs, though. What comes to mind is Boost control, Idle control, ELCD, Variable cam/intake manifold. How about an AVS based output expander board? each pin with a v5n07 output mosfet or even IRLU110s. Is this too far out there? I'd be willing to do the legwork to layout and order the boards.

I would think a special code version of the MS2/E but set for a GPIO board would be a better MS2/E unit than the V3/MS2 chip used currently. If Stepper is needed, then make it on a daughter card. If more current is needed for an output than the v5n07s can handle, then make the rest of the circuit on a daughter card. Doesn't the GPIO allow access to all the PWM outputs? and the 2 for th LoZ injector flyback could be re-purposed in this setting? If this were the case, I may spring for a GPIO for my daily driver and flash it with MS2/E. Am I missing something?

KeithG

[Jon k]

Gear indication possible? So we can do gear based rev limit or gear based boost control?

[Keithg]

Thinking some more.... If we were to use an ATmega8, (23 I/O and 3 PWM) for example, as an 'output only' expansion board which only takes info passed to it over CAN (it has onboard serial comms), we could use the other 3-5 pins on the MS2 as inputs for the main MS2 processor.

This does not help with transmission control, etc., but does address the lack of outputs on the MS2. Basically, if there were pseudo output channels in MS2, these would be piped over CAN to the AVR. It would be merely a receiver and processor of data, not an input module. We would send info to the AVR and it would be programmed to run stuff like fans, lights, idle solenoids, ELCD solenoids, etc... I think this would help some of us. Am I talkin' crazy talk?

edit: This probably belongs with the CAN discussion. I am just so jazzed about this and posted in the wrong place....

KeithG

[jsmcortina]

For speed of development - stick with the HCS12C family of parts. The CAN code is there and works and a cut down version of MS2<something> can be used on it quickly. The trans software I've done could be a start, throw away the trans code and you have an MS2 compatible shell with Al's working CAN code.

If you jump processors you have to learn how to implement all of the CAN protocol from nothing.

James

[johnc32779]

Some fuel for the fire -- for what it's worth.

http://www.futurlec.com/CANNode.shtml

http://www.futurlec.com/ET-ARM_Stamp.shtml

[Keithg]

So, in summary, I still like the thought of a GPIO board as a main MS2 controller. To get more outputs and inputs, James suggests getting another MS2. What I do not see is how they will all be packaged as a unit to be driven and drive. The concept of a 600.00+ sequencer device or such is still pretty inexpensive in the big picture, but is getting close to a quantum jump from MS1.

The biggest issue we all seem to have with the MS2 is lack of I/O and specifically true PWM output. There are other chips in the family of the MS2 with more I/O pins and more PWM. Have these been looked at? If the CAN protocol was ported to an AVR or PIC, would the concept I outlined be possible or even desirable?

KeithG

[jsmcortina]

Keith,
good points.
I too see packing as a problem for "end-user" types. For the hardcore DIY-er it is no problem, but a proliferation of different methods for achieving a similar goal could lead to more confusion amongst newcomers and hurt rather than help the Megasquirt brand.

I perceive many on here who want to know "how do I wire it up." Presenting them with a multitude of different options, different devices and alternate pinouts leads to a muddle of documentation and the lack of clarity is a real impediment. We've seen that with MS1/Extra plenty of times. e.g. "Q: which pin do I use" "A: you choose" "Q: but which one?" etc.

The sequencer for sure helps with this as it is going to be a clear device with known goals and defined outputs. It still doesn't have a ton of I/O though, but does have some spare I/O.

James

[6040solder]

but is getting close to a quantum jump from MS1.

yes, it is.

The biggest issue we all seem to have with the MS2 is lack of I/O and specifically true PWM output.

yes, agreed.

There are other chips in the family of the MS2 with more I/O pins and more PWM. Have these been looked at?

apparently they don't really exist or at least not in sufficient quantity for consideration. ie hard or impossible to actually get. it would be nice to confirm that with motorola though.

If the CAN protocol was ported to an AVR or PIC, would the concept I outlined be possible or even desirable?

if it was cheap, compact, and very flexible i think yes. the gpio is somewhat specific in its capabilities hardware wise.

i was envisaging the gpio would have something like 3 of these on one board with a processor in amongst it :



trying to simplify such a system could be pretty limiting. its not a simple task to run an engine from scratch. the intent was always for people to learn about what they are doing. if someone buys a ready made XYZ instead of understanding what they actually want and need to achieve and how its done they are going to be asking a lot more questions than if they had to design their personal system from a parts bin of options.

the sequencer is almost out of the grass roots category which is what its really been about the whole time. doing it better diy and for much less. for the kid that can barely afford his car in the first place sinking 600US into a single component on that car is a pretty big call. I know no single component on my car cost more than about 400US the turbo and the engine coming in 1st equal there. you can say "then just use a ms1/v2.2", but in modern times it doesnt cut it with big injectors on a small engine. it would be nice if a diyer still had the option of building it up from scratch how they want it whilst the "pull out the wallet and pay" crowd can get a sequencer ready to roll. rather than one or the other.

if each option had a unique pin assigned as a default that could help with what you mention, but as soon as you have more functions than pins it becomes impossible to avoid such questions.

flexible,compact,cheap are the keywords for any diy io extender i think.

its tough because you are damned if you do and if you don't with design choices like that. i hope i didnt muddle things further.