Why 16BIT? Why Not 32BIT?

From DIY contraptions to sophisticated FreeEMS-specific designs! Plus general hardware development!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Why 16BIT? Why Not 32BIT?

Post by Fred »

davebmw wrote:Would there be any noticeable advantage over 16 bit?
The advantage is in the fact that the 32 bit maths that I do do on the XDP is slow because it is not native. On a 32 bit core it is fast like any other math. Whether that is an issue or not though depends on what you have to get done, how complex it is and how much time you have to do it in. I think the XDP is enough for almost any normalish purpose.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: Why 16BIT? Why Not 32BIT?

Post by jbelanger »

I'd be interested to know where you got the MPC5633 from. Freescale doesn't show where you can get it (from them or a distributor) and it's the same for the evaluation board. I would certainly be interested in seeing what it can do (and no so interested in seeing how expensive it probably is).

Jean
User avatar
Movex
TO220 - Visibile
Posts: 6
Joined: Thu Oct 02, 2008 4:54 pm

Re: Why 16BIT? Why Not 32BIT?

Post by Movex »

Fred wrote:
Movex wrote:
Which 32 bit cores (and boards!) did you have in mind? Regardless of where we are at, I'm keen to learn about them :-)
the new MPC5633M from Freescale is in my opinion a suited device for DIY powertrain:
That's great, but you missed the bit in bold. For this to be fairly successful it needs to be easily accessible to those without the skills and abilities to solder fine pitch gear. Additionally, the proto board of choice needs to be physically suitable for plugging into some main board.

I haven't seen anything with the pin count and modular design that is suitable, but I'm interested to see what is out there.

Having said all that, the site needs a successful project and a modest one at that. Something that works, works well and is fairly basic and cheap. After that is off the ground I expect all sorts of parallel projects to spring up. Till then we need to focus on one thing and someone had to choose it 9 months ago, and it was me, and the XDP was the choice mainly because :

A) It is more than powerful enough to run most anything pretty well
B) MS2 have proved that a lesser variant can work for the intended purpose
C) The TA board is ideal as a modular starting point
D) It's cheap enough and easy to get

Thanks for your input.

Fred.
A cheap evaluation board is existing for this MCU even with a plugable daughtercard for the processor which can be used standalone or on your own board. The pitch (0.50mm)of the MPC5633 is the same as on the S12X in 144 pin package and only a bit denser than the 112 pin LQFP of the S12X (0.65mm).
My concern is not on this particular MCU but more on the future way of DIY in powertrain. Doing Ion sensing or knock detection requires significant power and additional hardware, that's what I'm missing on the latest DIY projects. Modern powertrain MCUs have that hardware for such stuff built in which saves board space and integration time. Look at the Cortex M3 from ST that's also a very suited MCU with great and cheap tool support.

9 months ago this device above has not been existing so I understand your decision in making a kick-off.
davebmw wrote:...
Let's not forget what happened when MS1 went to MS2, we'll need more complex software to iron out all of the interference the new 32 bit CPU picks up due to its higher resolution. this will extend development time and costs.
...
Sorry but the input resolution mainly depends on the ADC/input timers and not the processor architecture. There the MPC has a quite fast ADC but it's much more configurable than the S12 one's that's the difference. The S12 has a fixed configuration which is applied to all channels here you have to sample as fast as your most important signal requires for the other channels the high sample rate is probably be useless. On the MPCs you send commands to the ADC where you can choose a different sample time for every channel even a different for the next cycle. So here you can avoid interference by design/configuration saving RAM and programm space the S12 can't. Same applies to the resolution of the ouputs.

I know the XGate well it has got limitations which makes it hard to do extensive calculations like filter processing as there is no MUL, DIV and MAC instruction. Also there is no free C compiler support for XGate coding in Assembler slows down. Goods compilers like Cosmic and Codewarrior are not cheap.


Attached a picture of my S12XF ecu for a 4cyl. motorcycle project:

Image
davebmw
LQFP144 - On Top Of The Game
Posts: 331
Joined: Sun Jul 13, 2008 2:58 pm
Location: South Wales, UK

Re: Why 16BIT? Why Not 32BIT?

Post by davebmw »

Fred wrote: I think the XDP is enough for almost any normalish purpose.
So we are pretty much OK for what we have to achieve with FreeEMS 1.

But there could be benefits to upping the anti on the next generation with a 32 bit CPU.
Would this mean that the code would become twice as complex?
Would the firmware written for the XDP be portable in any way or is it a different beast altogether?
93'BMW 325is M50B25TU, Rebuilt 06/06, JE10.5:1, polish&port. Scorpion BB, K&N CAI, TEJ21 WBO2, '07 M3 Evo 18" 225F, 255R, EBC Kevlar, Bilstien Sprint, Polyflex. Head rebuild Oct'08, OEM+FSE FPR, MS2v3.0_DJB Custom, Extra 2.0.1
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: Why 16BIT? Why Not 32BIT?

Post by jbelanger »

Movex wrote:A cheap evaluation board is existing for this MCU even with a plugable daughtercard for the processor which can be used standalone or on your own board.
But where can you get it. I can only assume you have some connections with Freescale because it's not available anywhere I can see even though there is information on it on the Freescale site.
User avatar
SleepyKeys
LQFP144 - On Top Of The Game
Posts: 549
Joined: Mon Feb 11, 2008 10:52 pm
Location: Arizona
Contact:

Re: Why 16BIT? Why Not 32BIT?

Post by SleepyKeys »

The only real handy cap like Fred said is 32-bit number crunching, but as a whole the XDP is WELL QUALIFIED for the job. The XDP variant of freeems will kick ass for sure.

As for XGATE, because its only suitable for certain tasks we may be able to get away with the free/special version of CW allowing us to code in C. If the code is too big for the special edition I'll buy CW and port what needs to be ported to xgate. With a nice com protocol there shouldn't be too many things done in xgate and once its done not much needs to be changed. -- correct me if I'm wrong

As for ETPU, the XDP is not the end of the 16-bit line of MCUs. Also I do see 'crude' but effective knock sensing for the XDP-based freeEMS. You don't need advanced hardware to do effective knock sensing or crank angle. Dont get me wrong I do appreciate advanced capabilities. When I found out that the XDP couldnt do v8 sequential I was really bummed and wanted to get an XEP based board instead. But I believe I will get seq V8 injection faster if I get the XDP TA board and help/contrib along with the main efforts and I think the same applies to any other varriant that someone may want to build.

I think we could get alot more done if we all had TA XDP512 cards at this pont. Once we lay down a nice foundation porting it to other HW will be 'easy'.

-sean
You snooze, you lose!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Why 16BIT? Why Not 32BIT?

Post by Fred »

Awesome points all round, no time to comment in detail, but had to quote this :
seank wrote:But I believe I will get seq V8 injection faster if I get the XDP TA board and help/contrib along with the main efforts and I think the same applies to any other varriant that someone may want to build.
Smart man! :-)

There is another factor too :

Statistics.

How many people extensively mod their cars/engines? Small proportion of the population of the planet.
How many people want a cheap standalone? Small proportion of above.
How many people care about how good that cheap standalone is and don't just settle for "good enough"? Small proportion of above.
How many of those people have the skills and desire to DIY it? - I rest my case.

For most even ms1 is more than good enough, they don't care about the details enough, and don't want to diy it in the first place. The remaining people you might find are put off by extra complexity and cost which would come with such a CPU IMO.

Off to work,

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Why 16BIT? Why Not 32BIT?

Post by jharvey »

I agree we should keep our current focus on the TA card and 16 bit, however a different CPU card can be build at some point, perhaps adding additional features, and two optional injection/ignition drives.

I've been pressuring Fred to have a look up table that maps portA_1 to a name. Then use that name in the code. If that is how he did it, porting to a different processor will be much easier as most of the code could be reused as it, simply change the port mapping table, perhaps rewrite some parts that use special functions.

Any how keep focus on the TA card and 16 bit, then upgrade once we have something that works.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Why 16BIT? Why Not 32BIT?

Post by Fred »

It doesn't really work like that mate. There are lots of special function registers etc that need to be used to get any of the timed functionality. You can, and we will do that for general purpose IO stuff, but not for core stuff. Besides, you wouldn't implement it the same way on a different type of chip anyway, the implementation is fairly closely tied to the chip in question. There wouldn't even be much point in moving to a better chip unless you explicitly took advantage of it by structuring the code entirely differently.

EG, if I wrote FreeEMS in java on a PC it would be totally different in almost every way. Just like the existing freeems code won't work on the ms2 chip and no show in hell for the ms1 chip. You take maximal advantage of your hardware, and if you upgrade the hardware there is no point unless you leverage what it can do.

So, some will be portable, but a lot won't by definition.

Regardless of the chip (unless it has a mean multiplexer inside it) you can't just choose a pin for a task, they are connected internally to specific modules so it is how it is. No easy breaks for the hardware guy ;-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Movex
TO220 - Visibile
Posts: 6
Joined: Thu Oct 02, 2008 4:54 pm

Re: Why 16BIT? Why Not 32BIT?

Post by Movex »

seank wrote:The only real handy cap like Fred said is 32-bit number crunching, but as a whole the XDP is WELL QUALIFIED for the job. The XDP variant of freeems will kick ass for sure.

As for XGATE, because its only suitable for certain tasks we may be able to get away with the free/special version of CW allowing us to code in C. If the code is too big for the special edition I'll buy CW and port what needs to be ported to xgate. With a nice com protocol there shouldn't be too many things done in xgate and once its done not much needs to be changed. -- correct me if I'm wrong

...

-sean
Yes, doing comm tasks or bit baning works really fine but that's far below what the Xgate can achive. Implementing angle clock would be nice.
jbelanger wrote:
Movex wrote:A cheap evaluation board is existing for this MCU even with a plugable daughtercard for the processor which can be used standalone or on your own board.
But where can you get it. I can only assume you have some connections with Freescale because it's not available anywhere I can see even though there is information on it on the Freescale site.
I was in contact with local sales office, of course since this is brand new it's difficult to get one at the moment for private use.
By the way a very similar MCU is shown on the ST website, the SPC563M. It plugs into the same evaluation board as the MPC5633M on which is the ST and the Freescale logo sticked.
jharvey wrote:I agree we should keep our current focus on the TA card and 16 bit, however a different CPU card can be build at some point, perhaps adding additional features, and two optional injection/ignition drives.

I've been pressuring Fred to have a look up table that maps portA_1 to a name. Then use that name in the code. If that is how he did it, porting to a different processor will be much easier as most of the code could be reused as it, simply change the port mapping table, perhaps rewrite some parts that use special functions.

Any how keep focus on the TA card and 16 bit, then upgrade once we have something that works.
That's a huge effort as you need a hardware abstraction layer. Doing that for timer as mentioned by Fred is awful.
Post Reply