Here comes a very special wish - please do not call me crazy:
Working with many C modules, I prefer to define protected/"dangerous" variables static to one module. Quite often I would like to have a variable global only in a restricted number of modules - typically only in one module and then further the the communication modules (e. g. "comm1.c", "comm2.c").
To achieve this, it would be terrifically nice, if I could create the following code with a special pragma modifier (I made the examples with two modules "comm1.c" and "comm2.c", to keep the examples more general - but in fact I would be perfectly happy, if this would work with restriction to one further module "comm.c"):
#pragma RestrictedGlobal "comm1.c" #pragma RestrictedGlobal "comm2.c" int iRestricted;
(alternatively also like this (but then it would not work in other C compilers):
#pragma allowAccess "comm1.c" #pragma allowAccess "comm2.c" static int iRestricted;
)
In "comm1.c", "comm2.c" then the extern command
extern int iRestricted;
should be allowed - but it any other module it should fail (best would be, if the command itself would be allowed, but if the access to iRestricted would fail in any other module - then it is possible to include the extern declaration in some header file without the danger of failure)
I know that this is not possible in any other C compiler, but I think pragma is not standardized, so C compiler producers can add their own - just I think better use the first of the above alternatives, as then the code will also work in other C compilers not recognizing this pragma.
... I know that this might be quite an effort, as it concerns the very interior of the compiling/linking tables ... so just a polite question ... .
I just looked through the product page, and to my surprise it really seems to support C++ completely. ... .
Just e. g. for my demo board MCBSTM32F400 I did not find any C++ code - also I never saw any uController project in C++ up to now - this is completely new to me. Therefore I really would be interested if somebody has used C++ already for uController development, and what the experiences are (I would like to start "from the scratch" - too much respect concerning the pitfalls of uController programming).
... sorry ... last message should say "I would NOT like to start from the scratch ...".
STL with lots of dynamic memory etc may not be a good choice.
And it may be a good idea to stay away from streams etc also, to keep down on size of linked libraries.
But C++ instead of C really doesn't matter much to a microcontroller as general as the ARM. You can write your programs as C programs with objects. Or C programs with namespaces. Or C programs with references. Or C programs with exceptions.
Good or bad experiences aren't really caused by the language, but how the user decides to use the language.
The main requirement for the processor is that it should have a full set of instructions for work through pointers, allowing good mapping of the "this" pointer that is a very important part of object-oriented C++ code.
So you would recommend to keep the assemply and C startup code from the basic example, and then start with the classes only in the main function and above?
I agree with you, that I anyway would not dare to include too much dynamic memory handling into the controller software.
So then I would mainly use the C++ classes in a sort of quasi-static approach (possibly even with most member functions static ...).
Just for now I think this is a bit too much for me, I have to think about it some time.
Anyway it would be nice, if Keil could present some simple C++ demo, maybe based on Blinky, to show the advantages and possible pitfalls of C++ concerning controller programming.
Classes are for C++ - not assembler.
So you will obviously not play around with any classes in the startup file.
You don't need static member methods. But you should think twice about how you allocate your objects. If they are global objects. Or created on the stack. Or from a special memory pool. Or from standard heap. Or if you are going to use something else.
What you have to realize is that the operator "new" isn't the only way to get object variables in C++.
That's what I meant with my statement "I would presumably use C++ in a sort of quasi-static approach".
If I skip new, then usually I would define all my classes global. And in this case of course it will not make much sense to use constructor / destructor functions. So the main advantage of using C++ then will restrict to the variable protection scheme of C++, which of course is very advanced.
... perhaps in some future I will try some small steps with some simple global C++ classes without constructor / destructor ...
an example using STL is located in:
C:\Keil\ARM\Examples\C++\Example1
another simple example using operator overloading and friend functions can be found in:
C:\Keil\ARM\Examples\C++\Example2
You must live a very sheltered life!
There have been C++ compilers for microcontrollers for very many years - even for the 8051!!
I would suggest that you seek out a training provider to help you lay some proper, good foundations...
eg, some are mentioned here:
http://www.keil.com/events/links.asp blog.antronics.co.uk/.../ (although it's talking about 'C', the providers mentioned also do C++).
Dan Saks writes a lot about C++ in embedded systems: http://www.dansaks.com/
Thank you for the link to the two ARM C++ examples. Really interesting.
But the point that they present only 2 very basic examples with C++ in a folder which contains hundred's of C examples does not really support the importance of C++ in microcontroller programming :).
I think the most important thing is (concening my programming method), that I do not use dynamic memory handling in uC programming. And the power of C++ mainly comes up, if you start with dynamic memory handling.
In Windows programming nearly anything is dynamic memory - there I never would dare to write larger software without C++.
But I think without dynamic memory, C++ looses much of its glamour.
Constructors/destructors aren't bound to the use of "new" and "delete".
They apply just as well to global objects, or objects created on the stack.
You want to make classes complete - and that would include the use of constructors/destructors. Of course, some classes don't define anything that need destruction in which case you can get by with an empty default destructor.
But just as global C variables are always zeroed, you want all C++ objects (however they are created) to have a known state of all member attributes. Unless you think it's fun to debug programs having uninitialized variables taking random values depending on what was in memory before.
And the power of C++ mainly comes up, if you start with dynamic memory handling.
No this is not the case at all !
You are wrong if you think dynamic memory is what it takes to get huge advantages from C++.
C++ don't have more need for dynamic memory than C has. If you receive data in a C program, you need somewhere to store it. Switching to C++, you still need somewhere to store it. It doesn't matter if a variable is a C++ object, or an int or an array of char.
The main power of C++ is in encapsulation, and creating tight (but extendable) modules combining data and methods. And encapsulation don't have anything to do with how objects are instantiated.
What we do know, right now, is that you want to rewrite the C language because you aren't happy with it.
And that you haven't spent any real time with C++ and don't know the real strengths with the language.
So - time that you start investing some time really learning the language. And thinking about _why_ things looks like they do.
Consider how classes can have friends. Consider the implications of "using" namespaces. Or the advantages of type-safe linking. Or the ability to use { and } to encapsulate a block of code marked as "C". The difference in complexity compared to your #pragmas are huge.
Sorry, but that's not right - in Windows I am C++ expert and fan.
I am far from rewriting C language. I just wanted to add a helpful programming aid to the linker.
One further point:
If I use a global class in Keil ARM C++, and if this class has a constructor - is there some way to tell the compiler when the constructor should be called? (I mean e. g. somewhere in the assembly-startup function, in the c-startup function, or at the start of the main function?)
But if your #pragma only handles the next variable declaration, you could need a huge number of #pragma - and each one can be wrong.
Think about C++ which can use { and } to group information into a namespace or class. Or have private:, public:, protected: to have lots of things into a specific access category.
If you think dynamic allocation of objects is a requirement to get the full power of C++, then you may have used C++, but you have not considered the full richness of the language compared to C.
Think about a circular buffer with enquque(), dequeue(), is_empty(), is_full(), have_data(). Duplicated multiple times for multiple serial ports. And having the constructor receive a pointer to a char buffer and a buffer size. So you can instantiate - statically - multiple ring buffers of different size, for UART0 receive, UART0 transmit, UART1 receive, UART1 transmit, ..., SPI0 receive, SPI0 transmit, ... Zero dynamic memory involved. Unless you decide that you have one big block of buffer memory, and a configuration table to decide how many bytes of the pool for UART0 receive, UART0 transmit, ...
Or let's say that you have a class with a state machine supporting different sets of blinks - slow, fast, dual-blink, ... And a virtual method for driving an output. So you have one instance driving LED-1, one for LED-2, one for REL-1, one for REL-2, ... And the code runs through all these objects (accessed as an array of pointers) and call an update() method - automagically getting all your blinks etc. No dynamic memory involved. With C, you would have to send a pointer to a struct containing configuration and current tick counters, and a function pointer for what output to drive.
Dynamic memory is for solving problems where you don't know how many of something you need. But with limited RAM, you can't just allocate more objects. So there must be limits. And limits means that the problem could have been solved statically. Or that you know that you either need x objects of type 1, or y objects of type 2 - but not at the same time. C or C++ doesn't matter. You still have to write the software based on the existing hw - and select the used hw based on needs. But operator new is not what "makes" C++. The main purpose of it is to allow many programs to share a big processor and have each individual program claim no more than what is needed. With smaller microcontrollers, there are only one program running. So no memory to save for another program. So rules for how to share the available RAM can be decided at design time - without hurting the capabilities of the programming language.
A global class? A class is a data type. As expert C++ programmer, I would have expected you to talk about a global object - i.e. an instantiation of a class.
Well - the startup code have to make sure that the constructor is called before the code enters main(). Just as the startup code have to make sure that the interval variables in the C library gets initial values after the startup code have mapped RAM but before you reach main().
If you want the constructor to be called after you enter main(), then you should create the object as an auto object on the stack. That allows main() to contain code that makes decisions before the constructor is called. So you could decide what parameters to send to the constructor.