who wants to port to Power Architecture?

[jedediah_frey]

I believe the best approach as it stands now is to use one of the A20 chips eventually Olimex will release this SOM at a reasonably low price.

Looking at the specs on that it doesn't look at all like a good MCU. It looks more like a good general processing computer.

http://www.allwinnertech.com/en/product/A20.html

x264 decoding, HDMI, Android, etc. It seems to lack PWM, external interrupts.

And until a free (or much cheaper than $2,400) compiler is available for the TPU on the Power series (Freescale or STM) then Power really doesn't bring much to the table over ARM.

[abecedarian]

I'll offer up my TRK-MPC5634M kit for this endeavor, but I do expect some sort of reciprocal, such as the user pays for shipping, eventually leading something more which we can discuss later.

Tell me more? I would pay for shipping and I would promise to pass this board to whoever would need it more than I if one pays for shipping

Basically, what I said.
Pay for shipping and one can play with it. If they choose to keep it, we can work out something in trade; either a small cash sum or something else worthwhile, but it would definitely be less than buying one outright from Freescale.

[kb1gtt]

I can sweeten the deal by offering the IO board I made. I blew my TRK board so much of it doesn't work correctly any more. However if you get a good dev board....

The A20 does lack several peripherals. I'm not so worried about things like PWM with a GHz processor, there's plenty of room for that in software. If you have PWM, you have DAC. However ADC would be handy and that's a bit harder to obtain. I would probably look for something like the quickfilter chip for the ADC. http://www.digikey.com/product-detail/en/QF4A512A-LQ-B/686-1002-ND/1284177 After that most everything is digital signals.

[AndreyB]

The A20 does lack several peripherals. I'm not so worried about things like PWM with a GHz processor

Since A* is more a CPU than a MPU ChibiOS has little interest in supporting it Making real time linux is maybe possible - not sure - but that scales me, linux is a bunch of stuff from different eras so I have no idea where we would get support for a linux-based real time thing. QNX or something but again that is a huge unknown. i guess my line of thinking is that ChibiOS works really well for us because of the combination of HAL (Hardware Abstraction Layer) and the amazing support they provide (meaning the guy behind ChibiOS, I have no idea if he ever sleeps or how he find the time). So, it would need to be one of supported architectures

[abecedarian]

I can sweeten the deal by offering the IO board I made. I blew my TRK board so much of it doesn't work correctly any more. However if you get a good dev board....

My dev board works fine, only plugged in once, and I gave up after having issues with GIT and Windows 8.

[AndreyB]

On the other side, before we port anything anywhere we need to have something worth porting. rusEfi still has a long way to go to universal, user-friendly or just useable. I think it is actually harmful to spend too much time thinking about porting at this point. At this point, it seems like we are close to something cool - there are probably ten to 15 guys with these stm32f4discovery boards on this forum. I hope that this would be enough of the critical mass to take off a functional & useful project - but we are not exactly there yet. So, I think that the benefit of having some community on the same stm32f4 page overweight the minor discomfort of the 3v or the lame temperature range.

Implementing the whole thing is a major project so a bit of compromise would increase the changes of getting some result eventually.

[abecedarian]

What's funny is you started this topic about porting to Power and now you're posting against doing that.

[AndreyB]

OMG, I guess this makes me a less then perfect human

[AndreyB]

Got some SPC5643LF2MLQ1 samples from Freescale today...

[kb1gtt]

How hard do we expect it to be, to use the PPC platform under chibios? Is that just a #define thing and your done?

[AndreyB]

If these are the right members of the PPC family (not any would work), it would be close to a #define kind of thing. But that's one day.

[puff]

ppc - powerpc? motorola(ibm) processor used in old macintoshes?

[kb1gtt]

Yup, that is correct. About the PPC thing. Same architecture.

[abecedarian]

Well, my offer still stands for the TRK-MPC5634M eval kit. I don't see me using it for anything any time soon, if ever. So, I'd preferentially choose to sell it than donate it, but I can be persuaded.

[AndreyB]

Would you consider listing it on eBay? If not, I would happily pay $20

I hope that MPC5634M processor is a member of the MPC563xM family, which according to http://en.wikipedia.org/wiki/PowerPC_5000#MPC56xx is same as as SPC563M which according to http://forum.chibios.org/phpbb/viewtopic.php?f=19&t=1639 is supported by ChibiOS. So, my plan would be to start ChibiOS and make rusEfi work on both platforms.

[Nobody]

Would you consider listing it on eBay? If not, I would happily pay $20

I hope that MPC5634M processor is a member of the MPC563xM family, which according to http://en.wikipedia.org/wiki/PowerPC_5000#MPC56xx is same as as SPC563M which according to http://forum.chibios.org/phpbb/viewtopic.php?f=19&t=1639 is supported by ChibiOS. So, my plan would be to start ChibiOS and make rusEfi work on both platforms.

LOL you just don’t get it! According to “kb1gtt” the TPU is GARAGE and everything needs to be rewritten, in spite of millions of applications that say otherwise…

To further quote “kb1gtt” you have “blah” factor, not to be confused with real empirical data. So any attempt to apply something resembling factual data will result in a “blah”… So with a “blah” you get “blah”.

Flat out because of “blah” and some more “blah” followed by more “blah”… Well you get it, because of “blah” it just can’t work.

“Blah”, “blah” and some more “blah”…

Think “kbigtt” made his point, don’t waste your time, it’s predisposed to failure. “Blah” and more “blah”.

Sorry that was bad, but sums it up

[abecedarian]

Would you consider listing it on eBay? If not, I would happily pay $20

I hope that MPC5634M processor is a member of the MPC563xM family, which according to http://en.wikipedia.org/wiki/PowerPC_5000#MPC56xx is same as as SPC563M which according to http://forum.chibios.org/phpbb/viewtopic.php?f=19&t=1639 is supported by ChibiOS. So, my plan would be to start ChibiOS and make rusEfi work on both platforms.

Best I can tell, those are similar platforms. What's going to be important would be the core, e200z3 in the case of the 5634M, and the peripheral set. The different cores support different instructions though they have a substantial common base. Also, the TRK board sports the 33905 system basis chip that, if I remember correctly, handles CAN / LIN communications, power, CPU watchdog and failsafe stuff so that might make ChibiOS a fun handful.

And I'm sorry, but $20 is a bit low. I might consider half-price, i.e. $45, + shipping, or something that approaches that amount in trade. Ebay could be an option but it would have a similar reserve set with additional considerations for export restrictions, per the EULA.

Now, if you would help design the board and port RUSEFI to P8X32A (8 core multi-processor) for 2-4 cylinders, I might be open to more discussion.

As for what NOBODY said... I'm trying to separate the sarcasm from the factuals.

[kb1gtt]

@russian, If you pick it up and start playing with the TRK5634 board, I can offer some insight into chips like the MCZ33905S5EK which includes several features like CAN and watch dog. Getting that chip to work should have been a simple task, but FS has garbage documentation, so it was significantly difficult. Jon and I had that board communicating with it's on-board CAN to a TS on a PC. Basically we created a USB to CAN interface known as CTU originally drafted by essess, this registered as a COM port on a PC, which TS can connect to. The COM messages were sent via CAN to the TRK board, and the CAN messaged were decoded by that MCZ33905S5EK chip and sent to the 5634 as a serial stream which was just like TS was connected locally.

As well I have a KICAD module for one of the 5634 chips, so it shouldn't be very hard to make a brain board that uses that core chip. I'm assuming the ST copy of this chip has the same pin out and such. I understand the ST chip is literally a copy, as many OEM's require multi-sourcing a component to ensure stability in a product's MFG cycle. Apparently FS got ST to be that second source. So they should both be the same.

My cautions about developing with that 5634 chip are as you know about the compiler for the ETPU. The FS provided code doesn't work in the real world very well, it's does not play nice with engines that have a large change in crank angle per rotation like a single cyl. It would work better with an engine with a heavy flywheel or lots of inertia to dampen the short term variations in RPM. Also the FS provided code is only for wheels like a 36-1, and does not support 36-1-2 or any other wheel. So you are very limited in what engines you can use with that FS provided example. The ETPU can be programmed in pure assembly, or you can get the ImageCraft compiler for around $4k.

I also have a functional IO board, err, I may have given that away already. If worst comes to worst and I can't find the assembled IO board, I have a IO board design that I've already assembled and I have done basic testing with it. The only real issue it had was that I would make the ignition driver external, as those DPAK's made more heat than I expected. I would change to that hi/lo driver chip and use an external ignition driver.

[AndreyB]

I simply do not plan to use etpu, just the main chip. By the way, is the etpu a physical external chip, or a cp-processor inside the same package?

[abecedarian]

I simply do not plan to use etpu, just the main chip. By the way, is the etpu a physical external chip, or a cp-processor inside the same package?

eTPU is on the 5634 die.
Here's the schematic for the TRK board.

In my opinion the eTPU is the only compelling reason to use the 5634M. Well that and the butt load of ADC, GPIO and comms.

[Nobody]

As for what NOBODY said... I'm trying to separate the sarcasm from the factuals.

Yes, that was sarcasm laden LOL.

Oddly every TPU function I’ve worked with to date has worked as advertised. Some require more effort/knowledge to configure correctly than others.

To your other point, without using TPU, yes it’s a bit of a waste. Although the 24 channel, 24 bit eMIOS comes with many benefits. ADC with built in knock detection doesn’t hurt much either.

[kb1gtt]

Have you gotten it to work well with a Hall or VR real world sensor on a single cyl engine?

Have you gotten it to work on a V8 with a 36-1-2 wheel? I don't have any thing close to a 36-1 wheel, so I can't play with the stuff unless I get a dedicated engine, or do very significant modification to an engine that currently has other purposes.

I seem to recall that the 5634 only has 2X ADC's, then it's muxed to several pins. ADC muxing creates many interesting issues, which makes it reasonably hard to get fast or accurate readings.

I agree that with out the eTPU, the 5634 is just another slow and expensive micro. The eTPU's are good as they have low latency IRQ capabilities.

[abecedarian]

As for what NOBODY said... I'm trying to separate the sarcasm from the factuals.

Yes, that was sarcasm laden LOL.

Oddly every TPU function I’ve worked with to date has worked as advertised. Some require more effort/knowledge to configure correctly than others.

To your other point, without using TPU, yes it’s a bit of a waste. Although the 24 channel, 24 bit eMIOS comes with many benefits. ADC with built in knock detection doesn’t hurt much either.

The main (my opinion) benefit of eTPU is that once set, you can mostly forget it unless you need to update something with the angle clock or trigger events type of things. Mostly same with eQADC, where you can set a sample sequence and let it run DMA to other variables you want to work with, or as you mentioned decimate and process for knock detect. However, taking the angle clock away from core timers releases the core to do a lot more. There's something to be said about a timer that can service GPIO and account for crankshaft angular acceleration and deceleration, on its own.

[abecedarian]

Have you gotten it to work well with a Hall or VR real world sensor on a single cyl engine?

Have you gotten it to work on a V8 with a 36-1-2 wheel? I don't have any thing close to a 36-1 wheel, so I can't play with the stuff unless I get a dedicated engine, or do very significant modification to an engine that currently has other purposes.

I seem to recall that the 5634 only has 2X ADC's, then it's muxed to several pins. ADC muxing creates many interesting issues, which makes it reasonably hard to get fast or accurate readings.

I agree that with out the eTPU, the 5634 is just another slow and expensive micro. The eTPU's are good as they have low latency IRQ capabilities.

True that the 5634M has 2 ADC modules, but it also sports ~12 bit accuracy at 1MS/s. So sequenced properly, you can get better than 0.05v accuracy given a 0-5v supply, which is better 'accuracy' than an MPX4230 MAP sensor can claim with 1000x longer latency.

[AndreyB]

Giovanni from Chibios has mailed me http://www.st.com/web/catalog/tools/FM116/SC959/SS1675/PF259196
And it looks like Code Worrier (limited to 128K code edition) is the only free compiler Not great.

[Nobody]

With that board you will need a JTAG programmer, if you choose Freescale toolchain then you’ll have to buy P&E JTAG or similar at about $275, if you go with ST toolchain then JTAG will run about $100. They purposely try to lock you in…

Also 128K gets eaten up quickly, I’m at ~310KB, no data tables are hardcoded and still a ways to go. As an example ~18KB is gone just getting fully loaded TPU configured and running (function set dependent).

[kb1gtt]

XMOS comes with more cores, faster IRQ's, and a free compiler, for a lower cost chip. Why not use an XMOS chip instead of this older FS chip. I would bet chibios would port fairly easily to XMOS.

[AndreyB]

I would bet chibios would port fairly easily to XMOS.

That's the part which I really doubt It's not just the scheduling kernel but also the HAL - hardware abstraction layer.

Here is a random list of RTOSes showing that not all of them have HAL/drivers http://stm32discovery.nano-age.co.uk/stm32-resources-and-links/open-source-real-time-operating-systems-for-the-stm32-and-cortex-m3-mpus

[kb1gtt]

Both are the same ARM core, so most of the HAL should work. You would need to change external peripherals things like GPIO pins and perhaps some stuff with timers / ADC's. However the major parts of the core are very much the same I think. As well I understand that different compilers handle IRQ's differently, so you might need to deal with those low level bits as well.

[Nobody]

.