New Library Compatible with CMSIS - Comments

16-32micros · ‎2009-05-18

Posted on May 18, 2009 at 16:58

tkindler · ‎2011-05-17

Posted on May 17, 2011 at 13:06

STOne-32,

I think it's really nice that the startup-code is also included now. The only thing missing is a matching linker script for gcc based toolchains.

Right now, I'm using the codesourcery toolchain with lanchon's project files - but his linker scripts and startup code seem overly complicated.

It would be nice to have something more official included in the firmware library.

kilian2 · ‎2011-05-17

Posted on May 17, 2011 at 13:06

Hi STOne-32

We already integrated to new library as we made a major upgrade anyway. It looks great up to now, the only part we are missing is the full support for the 'SysTick' as it was defined in ''stm32f10x_systick.h'' before. Is there a good reason that only a minimal set is provide by ''misc.h''?

Thanks and kind regards

Kilian

16-32micros · ‎2011-05-17

Posted on May 17, 2011 at 13:06

Hi Friends,

Thanks for your comments, This is more than encouraging for us ! and confirms that the New Library 100% CMSIS compatible is working Out-of-the-box which we are trying to put a lot of efforts into ...

Back to your questions,

1) For the Support of codesourcery, this is coming as well in a later stage once we integrate our New Libraries with our Third Parties default packages.

2) Regarding Systick, This part is now moved to the ''CMSIS Core'' Block and will be maintained by ARM at www.onarm.com and we will be always inline the same versions from now-on.

Thanks again and Please post us your comments to take into account as usual !

Cheers,

ST1.

cole · ‎2011-05-17

Posted on May 17, 2011 at 13:06

Has anyone successfully migrated from FWLib to the new StdPeriphLib with Rowley Crossworks?

Thanks,

-Chris

raptorhal · ‎2011-05-17

Posted on May 17, 2011 at 13:06

Request adding a sample project for the Anglia IDEAList IDE.

raptorhal · ‎2011-05-17

Posted on May 17, 2011 at 13:06

I spotted one technical glitch with the library - rcc.c lists RCC_APB1Periph_USART4 and RCC_APB1Periph_USART5 as valid function call parameters in the function comments. rcc.h defines them as RCC_APB1Periph_UART4 and RCC_APB1Periph_UART5.

In fixing this, I recommend checking documentation for similar mislabelling of UART4 & 5.

jzarnow · ‎2011-05-17

Posted on May 17, 2011 at 13:06

Sorry to say that, but new documentation in chm format is totally useless here.

WinXP HE SP3 with all updates + IE8 - doesn't open any position from left list in right panel (only informs ''Navigation to Web Site(? - me) was rejected'' !).

Why you guys change what worked perfect till now (Manual in pdf's) into such crap MS-based solution ?!

Regards

Jacek

[ This message was edited by: jzarnow on 15-04-2009 22:28 ]

richardneveau9 · ‎2011-05-17

Posted on May 17, 2011 at 13:06

Had problems with .chm file also so I used 7-zip

to 'unzip' the chm file (into html) and it

seems to work.

jzarnow · ‎2011-05-17

Posted on May 17, 2011 at 13:06

Thank you, Richard - it really worked 🙂

But - have you checked size of expanded folder?

It totals over 77 MBytes in over 2000 files !!!!

Four times larger than whole new 3.0 Library itself...

tberk1 · ‎2011-05-17

Posted on May 17, 2011 at 13:06

Quote:

On 12-03-2009 at 21:47, Anonymous wrote:

Would it be possible to move/fix the definition of the HSE frequency. I'm using RIDE and it means if I want to use the built in library I have to recompile it for every project that has a different crystal.

Don't suppose there is a workaround for the v2 library atm?

I second this.

This has driven me crazy a number of times for forgetting to add library *.c files which are dependent on HSE define (i.e. USART) to the project. When working on multiple projects w/ diff crystal freqs its an issue.

Todd