Im willing to help wherever help is needed I got C compilers, surface mount tools, etc.
USB inferfaces to pic (saves redesigning the wheel) etc

_________________
St205 WRC - Running sweet.

Im willing to help wherever help is needed I got C compilers, surface mount tools, etc.
USB inferfaces to pic (saves redesigning the wheel) etc

_________________
St205 WRC - Running sweet.

you will also (need ) bluetooth in there so that diagnostic codes can be read out onto your android phone...

_________________
St205 WRC - Running sweet.

F* that for a game of soldiers

If you were going to do anything I'd suggest a spare can output. You can layer OBD on that then the user is free to use any Bluetooth dongle of their choice and apps like torque to display it. No point in reinventing the wheel and adding unnecessary hardware

ahh, yes, can. 5 minute job

_________________
St205 WRC - Running sweet.

Can is a lightly skid marked pair of boxers compared to the full on brown trousers and squelchy shoes of bluetooth.

Plus the pics Chris is looking at mostly have can interfaces onboard

Spent a few evenings now researching devices and started on the design proper on CAD. Will post some piccies soon.

Most of the time has been spent researching the processor side of things as I've not yet ventured into pic24/pic32 families so it's all new ground to me.

My prime goals are to avoid surface mount at this stage, as I have been unable to find sockets at a decent price. Rob (Niblettr) has been very helpful to me on another project with surface mount when I was unable to find a company willing to do just 24 boards, but I don't want to have an 'own project' I can't support.

There are some through hole 40 pin dsPIC devices but it doesn't seem a popular format so I would be worried about being future proof.
There are many 28 pin through hole devices in the pic24 /dspic/pic32 families all pin compatible (with care on which pins are used for what) so I have decided to go this route for the main processor and then have a slave 40 pin pic16/18 family device to handle the lower speed I/O's.

I have picked the dsPIC33FJ128GP802 as this is readily available from RS.
I have picked pinouts such that I can also use dsPIC33EP256GP502 (faster & more memory) or PIC32MX250F128B (32 bit but no CAN)
dsPIC family are part of the PIC24 family but with extra instructions available.

The second processor choice is a little limited by the 3V requirement to link to the main processor. PIC16F & PIC18F are not specced below 4V although from experience they do work. I have had to choose the LF version which limits choice from RS/Farnell. I use the PIC18F4525 a lot so would be the obvious choice but it's not available from RS/Farnell as an LF so for the moment I've chosen PIC18LF4523. I may change this at a later stage as they are all pretty much pin compatible.

I have also added an I2C non volatile memory chip in case it's needed for storage of maps or dignostic information. Apparently, you can use the program flash as data storage on PIC24 & PIC32 but I'm playing safe for the sake of a sub £2 8 pin chip.

So, the main processor will connect directly to the following I/O for high speed access:

Map sensor / turbo pressure sensor.
AFM (if required)
Throttle position.
Knock level.
Crank trigger.
Cam trigger 1
Cam trigger 2 (won't be used unless I add limp facility if trigger 1 fails).

4x injector drives.
4x ignition drives.

Can BUS (not on pic32) Tx & Rx.
RS232 Tx & Rx

All other I/O will go onto the aux. processor as it isn't speed critical.

I would have liked to do USB, but none of the 28 pin pics support it so have gone the old fashioned route. USB/RS232 converter leads are readilly available & cheap.
As far as wireless goes (wifi or bluetooth) I don't want any risk of someone nearby able to hack into my ECU and screw up the settings.

Does anyone have any technical info on OBD2 ?
I'm led to believe this can be done via the canbus. It would be useful to be able to handle both.

Feel free to comment if I've missed something.

_________________
If at first you don't suck seed, try drier grain.

For anyone interested:

http://www.cdd.co.uk/stuff/ECU_sch.pdf

_________________
If at first you don't suck seed, try drier grain.

I thought that was going to contain maps and rolling road results
Real world been slowing you down?

Comedian eh ?

Got a nice long list of paying work to get on with at the moment, plus been clearing the decks & getting odd jobs out of the way.

Hoping to have the board layout done by end of Nov. so I can get prototype done by / over Xmas.

_________________
If at first you don't suck seed, try drier grain.

Been looking at pinouts of standard ECU's tonight.

My original concept was to make a PCB which COULD fit in a standard ECU case using standard connectors and look like a standard ECU (knowing the rumours of banning modified cars). Internal links taking care of the few pin changes between models. The extra spare inputs & outputs coming out on unused pins to be wired as required.

As a result of tonights study, this is looking unfeasable as there aren't enough pins unused on all models, especially 205.

One possibility I will explore is to put inputs/outputs on original functions which we do not need to use (egr,aircon etc.) then cut wires in the loom if we need to access the pins for alternative extra functions. (e.g. wideband, coil on plug, etc.) I'm not holding out much hope for this being successful though.

So. -

1. Do I just design a 'generic' ECU with a connector of my own choice then make up adapter looms for various cars. (I would do this for non-toyota anyway)

2. Do I add an extra connector elsewhere on the box for all the extras.

3. Do I live with fewer spare I/O than I was originally planning.

Bearing in mind that 80% of the reason for this project is to provide me with ECU's for my 2 cars plus any friends who want an ECU they can play with the software (megasquirt only more suited to our cars) - Option 2 or 3 sound attractive. But then again, I haven't yet found a source of the denso connectors and plan to house the ECU's in a generic box if they go to market.

What are peoples thoughts ?

_________________
If at first you don't suck seed, try drier grain.

Losing I/O seems daft on a spare pin issue IMHO so option 3 doesn't make sense to me.

If you are trying to design a standard looking ECU box / re-use standard ECU case then an extra connector (as long as costs are sensible for the additional port) makes a lot of sense to me. Stick on teh opposite end of the ECU so hidden during a brief peak and consider it will only be used on cars with serious mods or for tuning purposes (I/O for COP, EGT, Lambretta Sensor, Fuel Pressure etc) all of which will look like a serious mod under the bonnet unless installed to look OEM which I have never seen pulled off on a GT4!

A generic ECU connector also has some merit if you repin the standard loom with new plugs but adds to the hassle and working under dash is a PITA to swap over the connectors.

_________________
JP
GT4DC Treasurer

Grey St185 RC
Silver BMW E46 M3
Multicolour yawn Honda VFR400
Silver Honda Civic Type-R

As for Plugs & pins etc...
http://gt4dc.co.uk/forum/viewtopic.php? ... light=tyco

Have you tried digikey, mouser, onlinecomponents.com or componentscenter.com?

Part nos seem to be in stock again at online components.

_________________
JP
GT4DC Treasurer

Grey St185 RC
Silver BMW E46 M3
Multicolour yawn Honda VFR400
Silver Honda Civic Type-R

Scratch Digi-key - none of that type in my latest book

_________________
JP
GT4DC Treasurer

Grey St185 RC
Silver BMW E46 M3
Multicolour yawn Honda VFR400
Silver Honda Civic Type-R

Thanks JP, I've at least found a manufacturer / part No.

_________________
If at first you don't suck seed, try drier grain.