<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 22, 2015 at 9:48 AM, Karel Gardas <span dir="ltr"><<a href="mailto:karel.gardas@centrum.cz" target="_blank">karel.gardas@centrum.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/22/15 06:28 PM, Mr. Andrei Chichak wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 2015-May-22, at 8:58 AM, Steve B <<a href="mailto:sbattazzo@gmail.com" target="_blank">sbattazzo@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The STM32F4 is on my list, but because our main number-crunching routine already takes 25% of our time step duty cycle on the AM3358 at 1GHz, it seems risky. If we pretend MIPS/MHz and FLOPS/MHz were a 1:1 map from the A8 to the M4, then we are guaranteed to violate timing. On the flip side, this number crunching part is not in any way optimized with embedded operation in mind, so there are at least a couple things I can think of  we could do that may allow us to squeeze it in to a Cortex M device.<br>
</blockquote>
<br>
I think 1:1 would be optimistic, but you also don’t have to deal with a heavy OS or things like demand paged virtual memory.<br>
</blockquote>
<br></span>
AM3358 is Cortex-A8 IIRC which means in-order dual-issue CPU. On the other hand IIRC M4 is single issue in-order CPU so it's definitely not 1:1. Also wikipedia lists M4 as 1.25 DMIPS/MHz and A8 as 2.0 DMIPS/MHz. To get to A8 performance level, you would need brand new M7 which provides 2.14 DMIPS/MHz[1].<br>
<br>
Karel<br>
<br>
[1]: <a href="http://en.wikipedia.org/wiki/List_of_ARM_microarchitectures" target="_blank">http://en.wikipedia.org/wiki/List_of_ARM_microarchitectures</a><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br></div></div></blockquote><div><br></div><div>Thanks, good call! The M7 was also on my mind (supposed to be better floating point performance than the M4 as well?), but it's still only in engineering sample stage I think. The only vendor I know of that has a board out for it is Emcraft systems, but it's not yet using "production" silicon.<br><br></div><div>The STM32F7 is supposed to be binary compatible with the F4 so hopefully it wouldn't be too hard to get RTEMS going on that.<br><br></div><div>For now I think it's simplest to just try to trim the fat (double->single, etc) and run on the same platform we currently have, and see how big of an execution time gain can be had from just that, and then I'll have a better idea of whether or not the M4 or M7 is feasible.<br><br><br></div><div><br></div></div><br></div></div>