Skip to main content
Topic: keil 4 arm WTF (Read 28511 times) previous topic - next topic

Re: keil 4 arm WTF

Reply #30
[quote author="SolderSplashLabs"]Yeah no clue how you would get that much info across in 1 page![/quote]
One of the reasons I wanted to check it out was to see exactly how big this "page" was!
[quote author="SolderSplashLabs"]Abstraction helps, means less reading if you want to get started quickly.
PDF chapters are also very useful each peripheral has it's own, that and ctrl-f usually get me the info I need.

A web navigate-able version is a good though[/quote]
Of course in the old days when paper grew on trees, I'd just print the whole thing out - nothing compares to loose paper and a chewed pen for being able to see the big picture!

@bearmos: I think it was more an expanded block diagram of the micro with lots of annotation (down to the level of bits in registers). I would guess that they had a user manual and another datasheet for timing diagrams, electrical characteristics and so on. However all I managed to see of it was what was flashed in front of the camera, I never actually found the sheet itself.

EDIT: Just found it again, EEVBlog #31

Re: keil 4 arm WTF

Reply #31
yes bga .. one other reason I disliked nxp :)

> Most "current" IDEs will no longer be available

yes, I agree 100%, had that issue few times... I rarely / never use libraries I do not have source of, that's why I'm not using MikroC. I like their ide, I like the code quality, I like the tools, I like the ppl making it (know some of them), I like supporting local company (mikroelektronika is from same town I am), but I dislike closed libraries so even if I can have mikroC for free or for some reduced price or pay fully it's not expensive, I won't use it as every freaking library there is closed .. on the other hand if you use libraries you have source of (like with STM32 chips where you have source of all libs) who care if they kill the project in 10 years, you have source of everything so you can compile it on whatever is the actual compiler in 10 years ... if mikroe ever come to their senses and opens their libs I'll just move to their set of tools as I like the way they do things (ok some things I dislike, like case insensitive C compiler :D but what the hell, I can forgive them that :D )

Re: keil 4 arm WTF

Reply #32
gave up on the eclipse plugin for now, it looks interesting but flash and debug won't save settings, I select target, select ST-Link, properties ... blah blah.. and it does not save it, when I try to flash or debug it complains there's no ulink pro

Re: keil 4 arm WTF

Reply #33
[quote author="arhi"]gave up on the eclipse plugin for now, it looks interesting but flash and debug won't save settings, I select target, select ST-Link, properties ... blah blah.. and it does not save it, when I try to flash or debug it complains there's no ulink pro[/quote]
That doesn't sound promising...thanks for the update

[quote author="scsims"]@bearmos: I think it was more an expanded block diagram of the micro with lots of annotation (down to the level of bits in registers). I would guess that they had a user manual and another datasheet for timing diagrams, electrical characteristics and so on. However all I managed to see of it was what was flashed in front of the camera, I never actually found the sheet itself.

EDIT: Just found it again, EEVBlog #31[/quote]

That does look pretty nice, thanks for finding it!  I think a while back I had used an ADuC845 dev board that came with a similar printout.  Although at this point with the number of peripherals packed into MCU's I'm not sure that's possible anymore...one of the reasons I'm grateful for CMSIS is because of how complex/convoluted peripherals have become!

Re: keil 4 arm WTF

Reply #34
[quote author="bearmos"]...one of the reasons I'm grateful for CMSIS is because of how complex/convoluted peripherals have become![/quote]
I can understand the problem with complexity of the peripherals, especially when they interconnect/interact in unexpected ways. However, CMSIS is just as complex and convoluted. My experience with CMSIS:
- provides an extremely basic, and often simplistic, form of interaction
- complicates many simple interactions (2 layer calls for a gpio-pin change)
- causes bloat in your build as it is created an all-or-nothing peripheral joining of functions
- causes bloat due to configure structure concept
- needs to be adjusted for each project and cannot be considered a "library"
- contains many bugs (mostly due to rushed vendor copy-paste publication)
- cannot be used, and is in your way, when using the core/peripherals to the max

Don't get me wrong, I do think that an abstraction layer (often) is a good thing. However, CMSIS is not the answer imo. The problem is that there is no general vendor consensus on which peripherals are available and how they are programmed/interact. Therefore, an abstraction layer gets overly complicated and full of exceptions, whereas the embedded processors are excelling at fast low-level interactions.

Re: keil 4 arm WTF

Reply #35
[quote author="bearmos"][quote author="arhi"]gave up on the eclipse plugin for now, it looks interesting but flash and debug won't save settings, I select target, select ST-Link, properties ... blah blah.. and it does not save it, when I try to flash or debug it complains there's no ulink pro[/quote]
That doesn't sound promising...thanks for the update
[/quote]

I did not use the super old eclipse they mention in manual but what was available for dl ('cause I had no eclipse inside vbox)... so maybe something should be tweaked more ...

The actual plugin seems to solve the problem with IDE completely, you use eclipse for editing and plugin adds uvision menu so you can flash, debug etc etc .. and uses keil for compilation, target data ... problems I found were
 - they say when you import uvision project it should be ready to compile/debug, I found that target was not recognized and spent not small amount of time to figure out how to define a target, after I did I came to problem with it not storing data about programmer/debugger hardware :(
 - apart from import not working properly, the whole "import file system" makes no sense to me, they know how to parse keil project file, why not navigate to project file and let it tell where the rest of the project files are, what the targets are, where the includes are ..
 - I don't get why they want me to create "project/general-project" and not "project/c-project or c++ project, it just makes no sense to me

all in all, it's pretty obvious that plugin that came with 4.7 is not up to date, not up to date with latest eclipse for sure and possible even not up to date with keil itself (since it's not capable to properly import examples from 4.7), I have zero experience with eclipse plugins but that could probably be fixed

on the other hand, starting project from scratch should work ok, apart for the problem with debugger/programmer

Re: keil 4 arm WTF

Reply #36
[quote author="arhi"]
on the other hand, starting project from scratch should work ok, apart for the problem with debugger/programmer[/quote]
This is kind of what I had the impression of last time I looked into it.  Not being able to use the same IDE for coding/debugging and having to keep two separate projects is a non-starter for me, unfortunately - I'm not disciplined enough to keep both an eclipse project (for editing) and a Keil project (for debugging) synced with one another.  On the other hand, I have a ulink-ME, so maybe the Keil plugin will like that better than a more generic JTAG programmer...

[quote author="Bertho"]I can understand the problem with complexity of the peripherals, especially when they interconnect/interact in unexpected ways. However, CMSIS is just as complex and convoluted. My experience with CMSIS:
- provides an extremely basic, and often simplistic, form of interaction
- complicates many simple interactions (2 layer calls for a gpio-pin change)
- causes bloat in your build as it is created an all-or-nothing peripheral joining of functions
- causes bloat due to configure structure concept
- needs to be adjusted for each project and cannot be considered a "library"
- contains many bugs (mostly due to rushed vendor copy-paste publication)
- cannot be used, and is in your way, when using the core/peripherals to the max[/quote]

Believe it or not, I agree with some/most of this:)  I use CMSIS to setup peripherals (usually just initialization), after that I generally create my own macros/inline functions to access whatever specific registers I need.  It is definitely not inexpensive wrt ROM, unfortunately, but since most of it is only used during initialization, runtime (after initialization) shouldn't really be affected.  It should be noted that, my current environment, I am willing to give up some performance for a dramatic decrease in development time (which is why I'm also using some features of C++ to increase code-reuse), so we might have pretty different goals :)

Quote
- causes bloat in your build as it is created an all-or-nothing peripheral joining of functions
What exactly do you mean by this - the linker bringing in all "unused" functions or something else?  I had this issue with the C51 compiler (Keil 8051 compiler) but the MDK-ARM (Keil ARM compiler) linker does an excellent job at removing unused functions.

Quote
- contains many bugs (mostly due to rushed vendor copy-paste publication)
What vendor have you had problems with?  I haven't come across anything with STM32F10x series yet (have only used GPIO, EXTI, TIMER, ADC, DMA, SPI, USB, NVIC, and SysTick so far though)

Quote
- cannot be used, and is in your way, when using the core/peripherals to the max
I actually find myself using more features of peripherals because the lib makes it easier to get them working quickly.  For example, using CMSIS, it's pretty easy to setup DMA to be used with the on-board ADC.

 

Re: keil 4 arm WTF

Reply #37
[quote author="Bertho"]
If you do development between a significant portion of vendors and targets, then you find yourself in a mesmerizing mess of code jungle. Many commercial IDEs have a whole set of targets they support, where they have created the appropriate scripts and interfaces you can pull in from the IDE to become part of your project. But you still need to hack through that code in order to get it to play your way (IMNSHO: a library should not be something you need to fiddle with).[/quote]

I can sympathize w/ the latter.
I worked on an embedded ARM AT91 chip based system using eCos.  Fought buggy drivers and buggy network stacks in that open source OS for the longest time and the project ended up being deep sixed :-P
But we did use the gcc arm cross-compiler on linux to build it.  There was a startup module that was close enough to the AT91 chip we used so it wasn't hugely painful.  But, I'd actually like to know what ARM RTOS doesn't have a crapload of bugs...seems if you go look at forums, there are complaints everywhere :-)

Re: keil 4 arm WTF

Reply #38
[quote author="bearmos"]{snip list}
Believe it or not, I agree with some/most of this:)  I use CMSIS to setup peripherals (usually just initialization), after that I generally create my own macros/inline functions to access whatever specific registers I need.  It is definitely not inexpensive wrt ROM, unfortunately, but since most of it is only used during initialization, runtime (after initialization) shouldn't really be affected.  It should be noted that, my current environment, I am willing to give up some performance for a dramatic decrease in development time (which is why I'm also using some features of C++ to increase code-reuse), so we might have pretty different goals :)[/quote]
The thing is, I often work on flash constraint SoCs. Having only 16/32k and using 10k for CMSIS is a problem. The second thing is that I often use very strict timing constraints, in which calls will interfere too much. Calling a xxx_getIntStatus() function to retrieve one register is completely bogus and prevents the compiler from better optimizing the code.
Fwiw, setting up the peripherals is generally not that complicated. And, I do admit that I sometimes "cheat" by looking at the CMSIS code to see what they did...

[quote author="bearmos"]
Quote
- causes bloat in your build as it is created an all-or-nothing peripheral joining of functions
What exactly do you mean by this - the linker bringing in all "unused" functions or something else?  I had this issue with the C51 compiler (Keil 8051 compiler) but the MDK-ARM (Keil ARM compiler) linker does an excellent job at removing unused functions.[/quote]
The point is that an object file is one unit and generally cannot be separated by the linker (the linker cannot do flow-control testing). There are some exceptions, but they are rare. So, lets say CMSIS has 10 functions in one file, that means they will all be in the object and therefore also in the target. If the Keil linker can separate an object file, then it must have some pretty heavy (global) analysis of the code to determine dead code and dead data sections...

[quote author="bearmos"]
Quote
- contains many bugs (mostly due to rushed vendor copy-paste publication)
What vendor have you had problems with?  I haven't come across anything with STM32F10x series yet (have only used GPIO, EXTI, TIMER, ADC, DMA, SPI, USB, NVIC, and SysTick so far though)[/quote]
NXP has given me a lot of grief.

[quote author="bearmos"]
Quote
- cannot be used, and is in your way, when using the core/peripherals to the max
I actually find myself using more features of peripherals because the lib makes it easier to get them working quickly.  For example, using CMSIS, it's pretty easy to setup DMA to be used with the on-board ADC.[/quote]
I fully agree that it is easy to setup things, but my point is that not all combinations are covered in the CMSIS setup. That would actually mean that CMSIS writers had thought of your problem and solution combination. That is an illusion.
I'm not saying that CMSIS is completely without merit. However, it is an attempt to solve a problem that cannot be solved in a generic way, considering too many vendors with all having an idea of how it should be. The simple things get abstracted correctly (although with bloat), the difficult things get more difficult (and I'm not talking about setting up DMA, but squeezing the SoC).

Re: keil 4 arm WTF

Reply #39
[quote author="Bertho"]The thing is, I often work on flash constraint SoCs. Having only 16/32k and using 10k for CMSIS is a problem. The second thing is that I often use very strict timing constraints, in which calls will interfere too much.[/quote]
Yeah, we're in completely different worlds, which is what I was assuming :)  I have a lot of respect for you SoC guys ;-)  I agree that CMSIS is way out of line for you to be using...For the amount of functionality you need to squeeze into your ROM constraints, there isn't even hope of doing that and use CMSIS!

[quote author="Bertho"]So, lets say CMSIS has 10 functions in one file, that means they will all be in the object and therefore also in the target. If the Keil linker can separate an object file, then it must have some pretty heavy (global) analysis of the code to determine dead code and dead data sections...[/quote]
My experience has been that if I bring in a file and don't use any of it, there is no additional overhead in the compiled binary (which is consistent with what you've said).  Start using one function, more ROM usage, another function added == more ROM usage, etc.  Based on the amount of size the final binary changes by, I'm assuming the linker is going through and removing individual uncalled functions and not bringing in entire files.  If you're curious, here is a link to their docs.

[quote author="Bertho"]If the Keil linker can separate an object file, then it must have some pretty heavy (global) analysis of the code to determine dead code and dead data sections...[/quote]
They were pretty good at doing global analysis with their 8051 compiler (C51) so they could overlay data segments instead of using a traditional stack when making function calls, so I would expect the same sophisticated analysis in their ARM compiler as well.  Then again, maybe what I'm seeing isn't function-level dead code removal after-all...

[quote author="Bertho"]I fully agree that it is easy to setup things, but my point is that not all combinations are covered in the CMSIS setup.[/quote]
Yeah, as you can see from my light usage of peripherals - I'm only at the tip of the iceberg here. . .It wouldn't surprise me at all if I run into this eventually.

[quote author="kenyee"]But, I'd actually like to know what ARM RTOS doesn't have a crapload of bugs...seems if you go look at forums, there are complaints everywhere :-)[/quote]
I certainly can't help here, I haven't used any yet...

Re: keil 4 arm WTF

Reply #40
[quote author="bearmos"]{snip}Yeah, we're in completely different worlds, which is what I was assuming :)  I have a lot of respect for you SoC guys ;-)[/quote]
Yes, different worlds, different requirements ;-) I love it when I can hack something together where there is plenty of everything. It is very refreshing. But, don't do yourself under for not squeezing a chip; getting anything to work is an achievement by itself.

[quote author="bearmos"]My experience has been that if I bring in a file and don't use any of it, there is no additional overhead in the compiled binary (which is consistent with what you've said).  Start using one function, more ROM usage, another function added == more ROM usage, etc.  Based on the amount of size the final binary changes by, I'm assuming the linker is going through and removing individual uncalled functions and not bringing in entire files.  If you're curious, here is a link to their docs.[/quote]
Ah yes, that is what I thought. Although this is a bit off-topic, I'd like to explain anyway. Your link refers to the linker's ability to garbage-collect sections. That is not the same as doing flow-analysis. What is described warns explicitly about the possible side-effects. However, the note at the bottom of that page describes that you need a compiler-option to generate separate sections for functions within one source-file (i.e make ".text.func1", ".text.func2", etc.). This enables the linker to garbage-collect unused section.

That said, the problem with garbage collection is that the linker cannot see indirect (runtime-computed) references. You can generate code that calls/branches to the middle of another function without explicit reference. The linker has no way of detecting this and may remove part of used code (I will not go into the code development and "goto" arguments). The note describes how to prevent removals from happening using attributes. The Keil linker is performing the same actions as the GNU binutils linker. There is also a good remark for (shared) libraries having garbage collection off by default. Using garbage-collection in a library can remove parts of the library because it is not referenced from within the library. The whole point of a library is that the code is accessible from outside, which makes garbage-collection a tenuous operation.

The classical way to ensure least possible bloat when linking is to have each and every (static) library function in a separate file. That way the linker can search the library archive and only take out the objects that are referenced. If you look at, for example, a libc implementation, you will notice a lot of small files with one function only.

[quote author="bearmos"]They were pretty good at doing global analysis with their 8051 compiler (C51) so they could overlay data segments instead of using a traditional stack when making function calls, so I would expect the same sophisticated analysis in their ARM compiler as well.  Then again, maybe what I'm seeing isn't function-level dead code removal after-all...[/quote]
Overlaying is not the same as dead-code/dead-data removal. They are two fundamentally different things. A 8051 has a different memory model and is not easily compared to a 32bit flat address space capable ARM. The problem you address here is one of stack frames and core abilities to the size and addressing. The 8051 is so severely limited that you need to do a lot of work. This is not an issue for ARM.

Re: keil 4 arm WTF

Reply #41
[quote author="Bertho"]Don't get me wrong, I do think that an abstraction layer (often) is a good thing. However, CMSIS is not the answer imo. The problem is that there is no general vendor consensus on which peripherals are available and how they are programmed/interact.[/quote]
CMSIS only concerns itself the processor core and the core peripherals (well, now it's called CMSIS-CORE and there's a CMSIS-DSP library, the CMSIS-RTOS specification and the debug-related bits). It was originally supposed to be a standardised driver interface, but that effort was abandoned after only managing to specify a debug-UART driver, which was then removed after one release. The peripheral libraries are completely up to the chip vendors.

Re: keil 4 arm WTF

Reply #42
GREAT NEWS !!!

dunno exactly when Keil 4.71a came out but a friend today told me that there is "newer then mine 4.70" so I removed 4.70, eclipse and some other stuff from my virtual machine (some configs from old keil's, cleaner registry etc etc) and installed 4.71a, eclipse-cpp-juno-SR2-win32 + plugin from 4.71a ...

1. ide works, the code completion actually works, bunch of issues I had with 4.70, all gone, everything works as expected
2. examples work
3. stmf4discovery examples work
4. stm32discovery examples work
5. new project, click click click blink led - works

ok, ide is still pretty rudimentary compared to eclipse but darn thing at least works and is usable, debugging works like a charm trough st-link v2

then I decided to try out eclipse, didn't create code from scratch but imported example from keil, it worked :D .. there still is no default config (they say when you import project what was last target in keil should work - well it does not but it's few clicks to create target), flash works, debug works - it uses keil to debug but you use eclipse's interface .. it's beautiful :) (yes, the bug with not remembering the selected debug/flash tool is fixed)... so the first eclipse test -> full success

code completion in eclipse don't work attm (spent only 10 minutes so nothing to worry about just yet) but it's probably some settings & includes .. and I have not tried new project from scratch in eclipse but all in all seems that this works ... and even as rudimentary keil ide is one can actually use it (compared to unusable 4.70) .. not sure if I'm going to go with eclipse or keil for the ide .. maybe keil is enough ... will try them up both for a while, there are some things I don't get, looks like even if you create project only in eclipse you still need to have keil project file too (you can create one from eclipse easily) so it should be actually super easy to work on project in keil and in eclipse in the same time :D

anyhow ... looks like 4.71a is really usable, can't wait to see what v5 will bring :)

Re: keil 4 arm WTF

Reply #43
But the main issue, Keil still is at EUR5000?