Embedded board with good support out of the box?

Steve B sbattazzo at gmail.com
Fri May 22 17:23:15 UTC 2015


On Fri, May 22, 2015 at 9:28 AM, Mr. Andrei Chichak <groups at chichak.ca>
wrote:

>
> On 2015-May-22, at 8:58 AM, Steve B <sbattazzo at gmail.com> wrote:
>
> > 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.
>
> 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.
>

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.

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.

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.


> 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.
>
> 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.
>

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?

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.

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.
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.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20150522/3e58cdb4/attachment-0002.html>


More information about the users mailing list