[TriEmbed] TriEmbed Digest, Vol 36, Issue 4

jonjwolfe at anibit.com jonjwolfe at anibit.com
Wed May 4 13:29:19 CDT 2016


Makes sense now. Setting up GNUARM + Eclipse is actually not that hard. 
It's much easier than it used to be. GNUARM even works with QEMU, so you 
can run and debug your code on an emulated device.

I guess with embed you give up a little flexibility for the sake of ease 
of use and convenience.

You might be able to hack your own feof in there, that's the beauty of 
embedded, you can do naughty things to what little OS you have.


On 2016-05-04 11:31, Alex Davis via TriEmbed wrote:
>> I'm curious what this means as well.
>> 
>> The Nucleo boards use Cortex-M[2,3,4,7] devices for which there is
>> plenty of support for in gcc ARM toolchains, as well as IAR, Keil, 
>> etc..
>> 
>> By "ARM C", do you mean Keil, which is owned by the ARM company? If so
>> that should be supported as well.
> 
> Here's an example from developer.mbed.org:
> https://developer.mbed.org/questions/3895/Compile-for-Nucleo-L053r8/
> 
> Someone's trying compile something that uses the SDFileSystem library.
> They get an error on 'feof' (which is used to know when you reach EOF 
> in
> a file). This is the answer from MBED:
> "I believe the application is for targets which use ARM C library, 
> which
> many nucleo does not support currently. They use uARM which implements
> only subset of C library, therefore some functions are not available.
> There's reference on ARM info pages , what is stripped."
> 
> So, that sucks. Wish they'd listed that somewhere on the MBED site. To
> me, being able to use libraries is a great value, as is the MBED
> paradigm, where so long as I can log on and plug in the board, I can
> write code and test code. If I have to set up a GNU toolchain I'll
> probably never get around to doing anything on it.





More information about the TriEmbed mailing list