Hi,
Before I go into my issues (which being an old hardware fart are many), let me confess that its been more then 10 years since I have had to play in the firmware park. I'm a hardcore hardware guy, but I have been put in the position of needing to write some firmware for one of my projects.
Now here's my problem (or issue).. I can't find any published information regarding the Keil implementation of the included libraries. Keil has lots of information about the compiler, linkers, and the such, but nothing about the libraries. I have been trolling the include files for the last two weeks just to get and idea of whats supported and how its called; now that's not a big deal, except it seems like the hard way of doing things. As Keil is a "professional" product I'm assuming that they have properly document libraries with specific implementation details; where are they?
As an example, fmod() in the Math libs., the definition in the Math.h file is perfect no problems, but why can't I find any information in the Keil documentation about this function? Am I missing something basic, or is Keils documentation of libraries really this poor?
Any help or insights from other users would be greatly appreciated.
Thanks Brian Ingwersen
"that's exactly what vendors don't want to publish"
Well, they won't publish the internal implematation details - but there are going to be implementation-specific details that the user needs to know...
"implementation-specific details that the user needs to know..."
...which are described in the C Standard. I guess you could argue that documenting these things along with the tool documentation would be a nice courtesy and I wouldn't disagree. However, there is always a risk involved with duplicating information: Corrections will likely applied to one of the documents only.
-- Marcus
Hi All;
Thanks for your feedback.
I did find infocentre.arm.com and agree that there is a lot more information there then on the Keil site; and ya I also know ISO is ISO everywhere (even though in practice that's not always true). Looking up the ISO libraries is easy, beside the pile of websites that cover it, I have a library of books and help files that describe the ISO functions in detail.
And I understand that they don't want to publish the code; and to be honest, I don't care about the code; what I really want them to publish is the impact that those functions has on the systems environment. ISO, in this case, is simply a standardized list of functions and not its implementation. That has always been left up to the compiler manufactures simply because its hardware specific (at least at last check).
In debugging an application its really important to know what registers and resources a function touches. Without knowing this level of info it becomes difficult to trouble shoot a system as your blind to whats changed when a call is made (at least without delving into the assembly).
Anyways, this is starting to feel soap box'ish so thanks for the info and opinions. Guess when all is said and done, I really need to quit being lazy and just deal with whats is available or create my own functions. Once again thanks guys.
Brian Ingwersen
> what I really want them to publish is the impact that those > functions has on the systems environment. > [...] > In debugging an application its really important to know what > registers and resources a function touches.
That is covered by another standard :-) On the infocenter, look for the AAPCS (ARM Architecture Procedure Call Standard). Among many other things, it defines the ways in which functions may use processor registers and stack. Somehow I've got the feeling that this doesn't make you any happier...
Any description going into more detail would lock a vendor into never changing that function ever again since every change would break hundreds of applications relying on previous behavior.
> I really need to quit being lazy and just deal with whats is > available or create my own functions.
In most cases the former is probably your best option.
Regards Marcus