uARM and ARM proposed changes

[sg-]

https://developer.mbed.org/forum/mbed/topic/25940/

The next proposal I'd like to make is that there become a clear distinction about which targets use uARM and which use ARM (microlib versus standard library). My suggestion is that any MCU with 64k or less flash use uARM (microlib) and any MCU with more than 64k use ARM (standard library). Feedback??

http://www.keil.com/support/man/docs/armlib/armlib_chr1358938937854.htm

[0xc0170]

My suggestion is that any MCU with 64k or less flash use uARM (microlib) and any MCU with more than 64k use ARM (standard library). Feedback??

Sounds good to me.

Adding more ppl, cc @Sissors @bcostm @screamerbg @bridadan

[bridadan]

That makes sense to me as well. How has this worked in the past? Was it up to the platform vendor?

[0xc0170]

How has this worked in the past? Was it up to the platform vendor?

Yes, I would say there was some confusion for default_toolchain option.

[star297]

There are several considerations when using micolib and may not suit all applications.
I understand that OS will have an impact on code size, but that would depend on which targets will be affected.
Could I suggest a drop down selectable option on the Mbed WEB IDE perhaps next to the 'compile' button.
Most of the 'small' Flash devices do have both TOOLCHAIN_ARM_STD and TOOLCHAIN_ARM_MICRO already in the Mbed library's, so why not make these available if possible.

This will then give the user a choice particularly if their STD code would fit.

Could you talk to the WEB guys to see if they can implement this?

But then it would be nice at some point to have some information on V3.0 and if there are to be any changes or additions to the WEB IDE functionality, perhaps this could be feature added at that time?

[sg-]

@star297 Thanks for the feedback!

Most of the 'small' Flash devices do have both TOOLCHAIN_ARM_STD and TOOLCHAIN_ARM_MICRO already in the Mbed library's, so why not make these available if possible.

This is the problem. You can hardly do anything meaningful using TOOLCHAIN_ARM_STD with a device of less than 64k Flash and 8k RAM when using standard library features that are impacted by microlib versus the standard library.

What I'm trying to do is minimize the amount of releases that get made and tested with little or no practical use.

Is there a case you know of where using the TOOLCHAIN_ARM_STD instead of TOOLCHAIN_ARM_MICRO for a device with 64k or less flash would be a ideal?? Better worded is there something that you know would have a negative effect using the TOOLCHAIN_ARM_MICRO library?

Keep the feedback coming!!

[Sissors]

What are the actual advantages of ARM compared to uARM? I know some functions aren't implemented in uARM, but the number is fairly limitted I think? (At least the functions you would realistically care about).

Quick check with online compiler (LPC1768 vs LPC11u24 vs LPC812) gives for blinky + a printf 17kB flash, 10kB flash and 4.7kB flash. (The 812 seems to be an outlier, any idea why it is so much less?). Similar numbers for for example the KL series. So the difference in flash is about 7kB. Then 64kB seems like a good limit to me.

[star297]

Is there a case you know of where using the TOOLCHAIN_ARM_STD instead of TOOLCHAIN_ARM_MICRO for a device with 64k or less flash would be a ideal?? Better worded is there something that you know would have a negative effect using the TOOLCHAIN_ARM_MICRO library?

The Keil compiler developers would be able to answer this to a better depth.
Maybe draw on their knowledge and experiences just to be sure.
Not just about output size, is it something to do with speed and stability?
But I can't say I have experienced or even noticed any detrimental effect on the targets I have used that implements Microlib.
I would side with you on simplicity that works and easier to debug verses over complication that has issues and a nightmare to debug and maintain.
The only reservation I would have is the future implementation of asynchronous and RTOS techniques with OS that will eat flash like its going out of fashion. Perhaps this will not be used on sub 64k flash devices.

[ciarmcom]

ARM Internal Ref: IOTMORF-218