<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 22, 2015 at 9:28 AM, Mr. Andrei Chichak <span dir="ltr"><<a href="mailto:groups@chichak.ca" target="_blank">groups@chichak.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 2015-May-22, at 8:58 AM, Steve B <<a href="mailto:sbattazzo@gmail.com">sbattazzo@gmail.com</a>> wrote:<br>
<br>
> 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>
<br>
</span>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><div> </div><div>Agreed, I don't know what the actual ratio would be but I assume it to be actually worse than 1:1 given the differences in instruction sets. So, if we assume some margin worse than that and make a wild guess that I can cut the bloat in half, then I'm still possibly on the fringe with 200MHz. But it's hard to say at the moment how much that OS or virtual memory overhead would account for.<br><br>There is also the "minor" detail that we're running a boat load of double precision operations where the BBB only actually has single precision hardware, so there is a possibility that we can cut the whole thing down by a factor of 10 by switching to singles, or maybe even fixed point. This is why Cortex M is on my radar but I want to be cautious about it. <br><br>If the level of effort to use a Zynq or keep the Beaglebone Black is actually not much more than the STM32, then I don't really have a great reason to switch down. I currently have a large margin on battery life and size/weight, and component cost isn't really a factor between $10 for an STM or a few hundred for a Zynq board.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>On my current project we are using a J1939 (large vehicle data) stack on top of CAN on a STM32F407. I used ST’s program called CubeMX to generate the initialization code for the various subunits (including the horrible task of firing up all of the various fine grained clocks) and their abstraction library code (with reasonable examples) and bringing up the CAN bus was about a day.<br>
<br>
More complex tasks like getting a 1KHz timer to trigger the ADCs to convert 14 channels, then generate a DMA event, took a little more setup time, but no CPU time.<br></blockquote><div><br></div><div>Thanks, good to know. I basically just need to have data going in and out on CAN bus and UART plus my number crunching task on a 100Hz mark, so I think I should be able to manage without too much trouble. Is there some kind of file system support ready to go so I can log all of my data as well?<br><br></div><div>I have a Zynq in front of me and a couple of STM32F4s on the way, so I will at the very least try to get those up and running with everything but the number crunching, while I keep studying the trade-offs.<br><br></div><div>If you have any other tips and tricks on the STM32 I might be interested, but I guess that I can browse the list archives and see what things have cropped up for starters.<br></div><div>I know Chris is pretty well versed on the Zynq and I've already gotten a few pointers from him but haven't managed to process all of that yet.<br></div><div><br></div><div>Steve<br></div><div> <br></div></div></div></div>