<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 21, 2015 at 9:45 PM, 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-21, at 17:39, Steve B <<a href="mailto:sbattazzo@gmail.com">sbattazzo@gmail.com</a>> wrote:<br>
> I need CAN bus, a couple of UARTs (one of which may need interrupts), some sort of ADC (whether it is the built in one or external), file logging, and some GPIO. No need for Ethernet unless it really proves useful in uploading software remotely or spitting out diagnostic data faster than a UART can handle.<br>
<br>
<br>
</span>The ST STM32F407 dev boards do CAN, have 3 UARTS, 16(?) channels of 12 bit ADC, 2 DACs, handle SD cards or USB OTG, lots of GPIO, ether, and run at 168MHz with hardware floating point. Its an ARM Cortex M4.<br>
<br>
It’s about an order of magnitude down from a BBB and Apples to Orangutans to an Intel anything.<br>
<br>
ST’s STM32F4 Discovery board is really cheap, has a lot of stuff to get you started, but has a lot of crap tossed in that get in the way (like a microphone and audio DAC).<br>
<br>
Your question smacks of someone entering embedded systems from the top (Intel really isn’t a player down here where 1MB of code space is pretty big). I’d suggest going slow and get accustomed to not having niceties like off-the-shelf graphics, and rich code libraries.<br>
<span class="HOEnZb"><font color="#888888"><br>
Andrei<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a></div></div></blockquote></div><br></div><div class="gmail_extra">Thanks! I am aware that I'm sort of coming in from the "wrong way" but the Beaglebone Black was picked before I had any say in the project because it was like "let's throw 1GHz at it, that should be enough to do anything." Keeping the Beaglebone in there would be great at this point since the hardware is already designed around that, but if the software we need really isn't there, then I think we're justified to replace it with something else in a future revision.<br><br></div><div class="gmail_extra">I'm personally fairly experienced with either embedded Linux applications or bare metal applications on really crude microcontrollers, but a bit new to the RTOS game. I've been trying to dabble in RTEMS for quite some time but it ends up falling by the wayside until I get to a place where I really need it.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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></div><div class="gmail_extra">I think at the very least I will grab a couple of those discovery kits and rig up a dummy loop application and get CAN bus running and see how that goes, but I was hoping that there might be a good drop-in replacement with similar horsepower to what we already have. I'm not hurting too much for physical size or power budget, so I thought a small x86 board might be good if it already has the drivers we need and can be brought up with minimal effort.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers!<br><br></div><div class="gmail_extra">Steve<br></div></div>