gbulmer
Moderator
I've been looking through the Maple code. I can't find the startup code. This is the code that executes before main() is called, and hence before setup() and loop().
Where is it?
I would normally expect some code which copies from flash to initialise the area of RAM occupied by the initialised variables, but I can't find that.
I would hope it is in there somewhere because the executable program couldn't be installed using the USART or JTAG/SWD otherwise.
Is it in the bootloader?
siy
Member
There are two parts of initialization code - libc runtime initialization (where variables copied from flash to RAM, in particular) and hardware initialization. The libc initialization is obviously part of libc (i.e. part of toolchain libraries). Hardware initialization can be found in boards.cpp in libmaple. Hope this helps.
gbulmer
Moderator
I should have been clearer.
I am looking for the source "code which copies from flash to initialise the area of RAM occupied by the initialised variables".
I think I have found most of it.
I believe the source code which initialises the program variables (data and bss segment) is in start_c.c called by start.S.
I looked in the linker include 'common.inc' where it identified __cs3_start_c.
The object code for __cs3_start_c appears in the two libraries libcs3_stm32_med_density.a and libcs3_stm32_high_density.a
(Side Note: The way linkers used to work (maybe smarter now, so this may be wrong), the startup code had to be separate from libc.a so that the user's program could be linked with the startup code, and the user's code could *ALL* be "linked" before extracting anything from the libraries. Otherwise the user's program couldn't override/replace library functions, which, at least, would make it hard to write and test new versions of library functions. I haven't looked hard at linkers for more than 15 years (that's what Java, and VM based languages do to you:-), so this might be wrong, but, it did lead me to the code I was looking for :-)
The source files, start.S and start_c.c, are in the libmaple git repository at libmaple/support/ld/libcs3_stm32_src
start_c.c is Copyright CodeSourcery, which maybe why it isn't in the Maple IDE download.
BUT, I can't find the file cs3.h
Any ideas?
siy
Member
I guess this is what you're looking for:
Sourcery_G++_Lite/arm-none-eabi/include/cs3.h
i.e. it's a part of the toolchain, as I've mentioned above :)
P.S. I've also switched to Java many years ago and often it requires some efforts to restore old knowledge and get used to (rather inconvenient after Java) C/C++ "standard" approaches and tools (makefiles often perceived as something from stone age after maven)...
gbulmer
Moderator
Rod - my copy of libmaple/support/ld/libcs3_stm32_src doesn't contain cs3.h, does yours?
I downloaded libmaple git repository today to check.
I assume siy's Sourcery_G++ path is likely correct, but I haven't checked yet.
siy - I am downloading the source TAR for "Sourcery G++ Lite 2011.03-41 for ARM GNU/Linux" I guess that is the thing to start with
I don't have much problem restoring old knowledge about "standard" C/C++ approaches and tools. I've continued using gcc, make, bison, flex, shell scripts, find, grep, ar, nm, strings etc. as well as Java, DTrace, Ruby, Erlang, Python etc. Having all of that at my fingertips is one of the reasons I use Mac OS X.
The problem is some of the old technologies have moved on, and alternatives added, so techniques which work for me aren't always the way some people, who don't have those historical skills, do things. Its all adds to my learning experiences :-)
siy
Member
The cs3.h is a part of standard binary distribution which, I guess, you should have installed already.
P.S. The restoring knowledge is not a problem, but, as you have mentioned, some things moved on since I've used them last time, so my old knowledge does not always fit, so efforts necessary to adjustments. Unix tools are not problem for me too just because I had installed Windows on my PC only for about 6 months during last 20 years. From the other hand, I had feeling that this area of software development evolves together with remaining industry, but found that this is not the case. Of course there are some notable differences, but most things looked almost identical 10-15 years ago. Nothing comparable to changes, for example, in Java for last 10 years. Of course I know, that, in fact there are significant changes in "big" C++ software development, but this is not the case for embedded software, where C seems still dominates and C++ is used as "C with classes" at best. Moreover, even some pure C code looks...hmm... well, ugly, as if authors don't know meaning of words "abstraction layer" and how they related to libraries. Most notable example, probably, is STM32Fxx standard peripheral library.
As always, above is just my thoughts and they can be wrong...
gbulmer
Moderator
siy
The cs3.h is a part of standard binary distribution which, I guess, you should have installed already.
AFAIK CodeSourcery/Mentor do not provide a standard binary distribution of Sourcery_G++_Lite for Mac OS X. Is there a place to retrieve one? I just install Maple, and it comes with a minimal gcc & binutils.
Are you saying the STM32Fxx standard peripheral library is ugly, or provides a good abstraction layer?
I have only looked at a few parts of the STM32F peripheral library.
I think it is pretty ugly.
While the functions appear to provide a stable API across STM32F devices, there isn't much of an abstraction.
For example the GPIO functions take structs which appear to change depending on which STM32Fx device is used. So the family leaks out into the user code. Hence, IMHO, it provides very little abstraction.
I dislike naming conventions which suffix type names with "TypeDef", or "Struct". The sort of modern IDE hardcore engineers use will tell you the definition of a name anyway. My era was initial capital for types/classes or "_t".
I like things that have sensible, working defaults, which require minimal code to get right.
But, I think it might be practical to put a thin 'veneer' over those libraries to make them more approachable.
siy
Member
Ah sorry, I've missed that you're using Mac OS X. I don't know where to download binary distribution for it.
I was trying to say that STM32Fxx standard peripheral library is ugly and does not serve as abstraction layer.
(I often have problems expressing my thoughts so they are clear to other peoples. This happens even when I'm using one of my native languages. English makes things worse :) )
P.S. Downloading 135Mb source archive for one 6Kb file is overkill, IMHO. Copies of this file are present in numerous places through Internet, for example here http://code.google.com/p/plex-svn/source/browse/trunk/h103/cs3.h?r=407
You must log in to post.
