Is a propellor practical for this automotive application? (FP!)
Hi all,
This is my first post here so please excuse me if I step anywhere wrong [noparse]:)[/noparse]
I've been watching Propellor on and off for a while now and i'm contemplating using it for a fairly complicated project. I would like your opinions on if you feel it's a suitable choice or not (any potential pitfalls, or other recommendations appreciated).
I want to create a car ECU (engine control unit). I have lots of experience of these, from OE and aftermarket and understand the control strategies etc. (as well as some unique stuff of my own). My previous idea (not unique, but rarely used unfortunately) was to have a multi-tier processor architecture, eg: a master processor to handle comms/sensors/lookup_tables and then secondary peripheral processors to do the control functions (eg, one processor per two engine cylinders etc.).. I was initially contemplating doing this with AVR's (I use BASCOM, and some assembler) but the multi-core approach of the Propellor interests me (for hopefully obvious reasons).
So I can see valid uses for multiple synchronous cores/cogs here; one for comms, one for reading sensors, one or two for driving the outputs, etc.. I think it'd be really good.. However one thing that is seroiusly putting me off at the moment is the lack of integrated peripherals on these chips (please correct me if i'm wrong), eg no ADC's, no external interrupts (so thus requiring a dedicated COG to do software-interrupts), no timers(!), etc.. Perhaps it's just me not being able to get my head around a 'new' way of doing things (is it new? or infact old?)..
I do like the idea of starting fresh on something new and having all the cores combined rather than 4-8 seperate AVR's does interest me, but i'd like your comments on this project idea [noparse]:)[/noparse]
Thanks
This is my first post here so please excuse me if I step anywhere wrong [noparse]:)[/noparse]
I've been watching Propellor on and off for a while now and i'm contemplating using it for a fairly complicated project. I would like your opinions on if you feel it's a suitable choice or not (any potential pitfalls, or other recommendations appreciated).
I want to create a car ECU (engine control unit). I have lots of experience of these, from OE and aftermarket and understand the control strategies etc. (as well as some unique stuff of my own). My previous idea (not unique, but rarely used unfortunately) was to have a multi-tier processor architecture, eg: a master processor to handle comms/sensors/lookup_tables and then secondary peripheral processors to do the control functions (eg, one processor per two engine cylinders etc.).. I was initially contemplating doing this with AVR's (I use BASCOM, and some assembler) but the multi-core approach of the Propellor interests me (for hopefully obvious reasons).
So I can see valid uses for multiple synchronous cores/cogs here; one for comms, one for reading sensors, one or two for driving the outputs, etc.. I think it'd be really good.. However one thing that is seroiusly putting me off at the moment is the lack of integrated peripherals on these chips (please correct me if i'm wrong), eg no ADC's, no external interrupts (so thus requiring a dedicated COG to do software-interrupts), no timers(!), etc.. Perhaps it's just me not being able to get my head around a 'new' way of doing things (is it new? or infact old?)..
I do like the idea of starting fresh on something new and having all the cores combined rather than 4-8 seperate AVR's does interest me, but i'd like your comments on this project idea [noparse]:)[/noparse]
Thanks
![hop.gif](http://forums.parallax.com/images/smilies/hop.gif)
Comments
For example: I'm using 2 propellers to do some control and measurements, they are interfaced by a 1.8 MBytes/s 4 bit bus, very nice. I did it so because the lack of IOs (32) and RAM per chip. A 64 IO would have solved most of my problems. The advantages ? simplicity, reconfigurability, speed. Is like you have some FPGA... you can do whatever you what... the logic is dynamic
have fun.
For your project propeller sounds like a good candidate to me. Once you work a bit with the propeller, in my opinion you'll welcome not having to deal with interrupts. There are no on-chip A/Ds or D/As but there are powerful timer-counters, two per cog. You can do delta sigma A/D and/or D/A with just a few external components, but results in my opinion won't compare to an on-chip A/D or D/A. There are plenty of freely available I2C and SPI drivers and peripheral examples on the Object Exchange.
Sometime last year I saw a post from someone at Parallax saying the propeller is fine for industrial temperature ranges. Development with the propeller tool is ok, but there's no native simulator, there's no native floating point (but there is a floating point object). Spin runs in Windows only. Spin is pretty slow compared to assembler, but is easy to grasp in my opinion. I would think spin would be fine for the application you're describing. Recently Imagecraft released C for the propeller - affordable. Parallax documentation for the Propeller, Spin, and Assembler is excellent in my opinion.
There is one possible drawback to using the propeller - code is stored in serial EEPROM and there is no way to protect intellectual property. If you are going to mass market your product, this is a risk.
Why don't you just give the propeller a whirl!
Getting Started...
Parallax has made it very easy to do so with their excellent little Propeller Protoboard (P/N 32212, $19.95 USD ea.) The protoboard thoughtfully has 64kB onboard EEPROM, half that is written to when you program the propeller, the other half you can use for whatever you like via freely available I2C driver objects from the Object Exchange.
You will need one Prop Plug USB/Propeller dongle (P/N 32201, $24.05 ea.) to program any number of propellers (one at a time of-course). I feel the Prop Plug is a little pricey - plus I just noticed Parallax is out of stock. Just download the Prop Plug manual, you may be able to roll your own prop plug. The prop plug uses one FTDI FT232RQ USB/serial transceiver. Probably any USB/serial device would work, you just point the propeller tool at the associated virtual COM port number.
Last but certainly not least - consider that in my opinion, support for Propeller users on this forum is superb!
Good Luck - Do let us know how it goes.
Regards, David
Short answer, yes. The Prop should be more than capable of controlling a V10 at 10,000rpm, every cylinder, every revolution. You're not going to have many resources left over, but add a second prop (or wait for the Prop2!!!) and you'll easily be able to do EVERYTHING else you would want to do with a car (blinkers, traction control, etc...). I would go as far as say that it could all be done on one prop, but it would be an impressive feat of logic an engineering, IMHO.
That said, it would have to be done almost completely in assembly.
Also, don't let the lack of integrated peripherals bring you down. It ends up being and advantage. integrated peripherals are limited to what they are. By using external peripherals, you can better choose (tune) to suit your specific application. Plus, if you burn out an ADC, you won't have to replace the whole ucontroller, just the ADC.
This is one of my many projects (I'm staring with my dirtbike first). I have done much thinking (and calculating) regarding this, and determined that the Prop is perfectly suited for it, and more than capable.
You have already thought about this a bunch, start allocating resources and determine for yourself if it will work. Let us know what you find!
-Parsko
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle