mad4x4
|
| posted on 22/3/12 at 08:54 AM |
|
|
quote:
Originally posted by MikeRJ
quote:
Originally posted by coyoteboy
Again the 'duino is a crippled processor.
It's hardly crippled, it kicks the arse of many 8 bit microcontrollers.
quote:
Originally posted by coyoteboy
Cracking for learning and can do some neat stuff, but I'm not sure it's fast enough in it's standard form to operate as an ignition
controller - you really need microsecond reliable control or you scrap your £1000 engine for a saving of £100.
I'm certain it would be fast enough - it's faster than the equivalent 18F PIC's in most situations (don't forget most
instructions complete in 1 clock cycle compared to 4 on the PIC).
The main problem with the standard Arduino (Atmega168/328 based) for this application is that it has only one 16 bit timer with compare/capture which
isn't ideal, but probably workable. The Arduino Mega uses the Atmega1280/2560 which is a newer and better version of the micro used in VEMS and
the short lived MS AVR project. In VEMS this micro runs at the exact same clock rate as it does in the Arduino (16MHz) so you could implement a full
engine controller on that.
quote:
Originally posted by coyoteboy
And learning C and programming a PIC isn't much different to arduino, maybe an extra nights learning and a few tutorials.
The Arduino is already programmed in C and/or C++, it just has a few subtle differences, like splitting up main() into an initialisation function and
an endless loop function. It's trivial to revert back to full ANSI C however, it uses the same compiler underneath (GCC). Unless you are going
straight to the 24F or 33F PIC's there's no significant advantages over the 8 bit Atmel parts, in the same way that if you are familiar
with the 8bit PIC's there's probably not much incentive to move to the Atmel parts.
Personally I'm quite enamoured with the modern ARM Cortex devices - for the price of an 18F PIC you get a 72MHz 32 bit powerhouse, and debugging
on them is a dream compared to the old 8 bitters. Even better the Cortex core is used by numerous vendors, so if you want to move to another part
it's really only the peripheral differences you have to worry about.
quote:
Originally posted by coyoteboy
From my own position (diddle with embedded stuff all the time) making a GUI for a windows based system is remarkably hard. Not sure if I'm just
retarded in that respect, but I can code most stuff but I struggle with GUI concepts 
Me too. I can make functional GUI's, but I struggle to make them pretty as I just don't have that artistic flair.
Agree
another advantage is that the AVR support floating poitn maths where when I looked at PIC's some years ago you had to go round the houses and
do allsorts of wierd crap to get it to do floating point.
Arduino is a PIC that is user friendly.
Scot's do it better in Kilts.
MK INDY's Don't Self Centre Regardless of MK Setting !
|
|
|
|
|
coyoteboy
|
| posted on 22/3/12 at 10:54 AM |
|
|
My point was not that the processor was useless (or the line of processors), more that in it's form (as an arduino) it's limited and
mainly useful as a learning tool. As I said, it can do plenty, but there's better options (i.e. different products and not used in the arduino
platform) if you're going to start a project like this. Have you guys played with Freescale products? They've got some rather tasty items
out at the moment.
[Edited on 22/3/12 by coyoteboy]
|
|
|
MikeRJ
|
| posted on 22/3/12 at 12:27 PM |
|
|
quote:
Originally posted by coyoteboy
My point was not that the processor was useless (or the line of processors), more that in it's form (as an arduino) it's limited and
mainly useful as a learning tool.
I see what you mean, though I wouldn't say they are limited only as a learning tool. I've used Arduinos (using standard C rather than the
"processing" language) for prototyping simply because they are very inexpensive, and the "shield" concept works pretty well to
create a robust prototype compared to a breadboard etc. You can now get Arduino clones using PIC and STM32 ARM Coretx micro's (and probably
others) so there is a reasonable choice of target device. I would agree the form factor is ultimately rather limiting however.
|
|
|
dhutch
|
| posted on 22/3/12 at 01:03 PM |
|
|
I was far to slow, and its now sold, but one has just gone up sale for £70 on wscc.
http://forum.wscc.co.uk/forum/index.php?/topic/93473-megajolt/page__fromsearch__1
Daniel
|
|
|
Slimy38
|
| posted on 22/3/12 at 01:45 PM |
|
|
I was trying to work out whether these prototype boards are actually fast enough. I see that there are references to clock cycles et al, but from what
I know about processors clock cycles do not 100% relate to activity. Even from my early processor experiences (Z80!), you had to use a handful of
clock cycles to handle a single assembler command, it must be even more to do the equivalent of a C command?
Looking at it from the other direction, how often would these devices have to sample the inputs with which to calculate whether the injectors are open
or shut, and when to light the sparkplugs? I'm guessing it is down to the millisecond interval, if not quicker?
Using some (pretty rough) maths, a car at 7000 rpm and being capable of responding to a resolution of 1 degree on the crankshaft, the device would
have to respond 42 times per millisecond? (7000*360/60/1000)
Am I talking nonsense?
|
|
|
coyoteboy
|
| posted on 22/3/12 at 02:01 PM |
|
|
You're not wrong, and you must also add in the fact that most engine management systems work to decimals on the ignition timing these days.
Plus, on top of all that, you want to knock sense which may involve some on-processor sampling and filtering. But none of that's outside the
scope of a decent micro with a reasonable clock rate and good coding. The MS2 has more than enough timing capability and it's fairly old
hardware these days. Slower processes like boost control, fueling calcs etc, are not run every n uS, they're run far less frequently and almost
as a background process, with the *timing* of fuel and ignition taking the primary interrupt driven role for good accuracy.
MS1 runs an engine fairly well, even a highly strung fast engine, and it's only re-calculates ignition timing once per revolution, but
it's accurate to ~1 degree based off that one calculation. Rapid transients see timing errors but theyr'e relatively small.
[Edited on 22/3/12 by coyoteboy]
|
|
|
Slimy38
|
| posted on 22/3/12 at 02:42 PM |
|
|
quote:
Originally posted by coyoteboy
with the *timing* of fuel and ignition taking the primary interrupt driven role for good accuracy.
That interrupt driven role, is that some sort of trigger wheel on the crank?
|
|
|
coyoteboy
|
| posted on 22/3/12 at 03:44 PM |
|
|
Yeah, working from the MS code IIRC the teeth on the crank wheel are decoded by triggering an int and syncing when the between-tooth time is longer
than 1.5x the last few times (assumes it's the missing tooth), then it calculates the nearest tooth to the desired ign angle and when it reaches
it it uses timer-int to get the last few degrees accurate. MS1 uses the timer from one specific tooth per rotation, MS2 counts the teeth up to just
before so as to get better accuracy on the timer (i.e. engine may be speeding up notably between tooth 1 and tooth 10 so timing error may be large if
it's based on tooth 1+time)
|
|
|
MikeRJ
|
| posted on 22/3/12 at 07:43 PM |
|
|
If you have sufficient timers with compare/capture, then the CPU speed requirements are significantly reduced, to the point you can run an engine in
steady state with negligible CPU overhead.
The original megasquirt has a pretty awful software architecture where a very large interrupt service routine is run every 0.1ms to test whether to
start or stop injectors etc. and even with it's relatively slow micro (much slower than an AVR @ 16MHz) it managed to do this ok.
|
|
|
coyoteboy
|
| posted on 22/3/12 at 11:47 PM |
|
|
Have you checked out the MPC5676R for the opposite end of the spectrum to the MS1...
"The MPC5676R offers significant performance and enhanced powertrain functionality, such as eTPU2, on-chip knock control and the peripherals
needed to meet extreme regulatory and environmental needs.
Features
Dual Power Architecture® 200z7 (32 bit) cores 2 x 180MHz
SPE1.1 / SIMD module for DSP and floating point operations
Core: Operating Frequency Max - Max (MHz) 184
Internal Flash (kByte) 6000
Total DMA Channels 128
Serial Interface - Type CAN, SPI, SCI
Timers - Number of Timers 3
Timers - Size (bit) 24
A/D Converter - Bits (bit) 12
A/D Converter - Channels 64
Shame the dev board and a processor is £700 and it's BGA 
|
|
|
