Is a propellor practical for this automotive application? (FP!)

pr_sjo

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

Ale

Firstly, if you can cram everything inside a Propeller (not Propellor) it may fit that application: I mean Control is something that can be easily done with the prop, but the limit of RAM and IOs available could lead to compromises. Per software you can do loads of things and interface easily with ADCs or IO expanders or whatever you need. And the propeller HAS timers, loads of them but as no interrupts exist they are done some other way. Get yourself a copy of the Counters application note to see some nice examples, and have a long read at the manual. Later you can decide if the resources will suffice.
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.

Drone

Welcome to the forum...

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

parsko

Pr_sjo,

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

I'm don't think a Prop could do all that. My motorbike needs a fast 32-bit MCU just to control a V-twin engine at up to 12,000 rpm.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

pr_sjo

In all fairness, that's more than likely because that's what is a) available and b) cheap.. Engines were running quite happily on 1mhz HC8's 20 years ago..

Leon said...
I'm don't think a Prop could do all that. My motorbike needs a fast 32-bit MCU just to control a V-twin engine at up to 12,000 rpm.

Leon

DynamoBen

Where you thinking of doing something like this http://bgsoflex.com/megasquirt.html·?

pr_sjo

No, something much better (eventually). I've done work with that product for years and they're not really going anywhere good with it. Mine would end up a commercial product (and the comment above about intellectual property concerns me [noparse]:)[/noparse])..

DynamoBen said...
Where you thinking of doing something like this http://bgsoflex.com/megasquirt.html·?

Mike Green

There have been many many long discussions here about protecting intellectual property and the Propeller. The crux of the matter is that it's much easier than you think for a sophisticated thief to steal your firmware no matter where you have it, whether you have it in some kind of internal flash memory in your controller with or without "protection" flags. For protection against unsophisticated thieves, almost anything that makes life a little more difficult will work including potting part of the circuitry, adding some kind of "key" like a 1-wire sensor which all have unique addresses and burying the "key" in a small routine, perhaps using the built-in pseudo-random operator to transform it. Your actual program is compiled into byte codes and, although it can be decompiled, it's a huge amount of effort to make sense of a compiled program without any labels or variable names.