Hello,

I'm just starting to use mbed, with Bert van Dam's "ARM Microcontrollers" book as a guide.

My knowledge of C is a bit shaky, but as I understand it, with the mbed compiler, there are various C functions which have been created specifically for programming the mbed microcontroller e.g. DigitalOut, DigitalIn, AnalogIn, etc. My question is: if I was to move to another compiler in the future such as LPCXpresso or uVision, would I come across the same functions or would they have their own unique functions?

Thanks...

Hi Chris,

The C compiler itself is a standards compliant C/C++ compiler; we actually use armcc. That is the program that turns the C language code in to machine instructions that can run on the processor.

It is also common for compilers to provide an implementation of the Standard C Library. This gives you useful platform-independant functions like printf/fopen (stdio.h), sin/cos (math.h), malloc/exit (stdlib.h). So this is pretty standardised across compiler toolchains.

The mbed libraries are an additional set of classes and functions that provide simple high-level abstractions for microcontroller specific peripherals; DigitalIn, SPI, AnalogOut etc (mbed.h). These are unique to mbed, and are not currently supported by other tool chains. As you identify, other toolchains may well provide their own functions to achieve similar things, and most MCU vendors provide "Peripheral Driver" code examples on their websites too.

Unlike the Standard C Library, there isn't really a dominant standard for microcontroller peripherals. Much of this is down to the differences between microcontroller peripherals and the different potential trade-offs between device specific flexibility and simplicity/uniformity. With mbed, we made a library that went strongly down the simplicity/uniformity route, so hopefully it is easy to pick up and use for the common case.

Hope that is helpful, and good luck!

Simon

Hi Simon,

Thanks for the fast response, which is clear to me now. I do have a further question on the subject of libraries, though:

I also have Dev-C++ installation on my hard drive, for the purpose of learning C in general (not mbed). Most code starts with the line

1. include <stdio.h> or similar

which I understand to be a directive to include the stdio library. If I open stdio.h itself (located at c:\dev-cpp\include in my case) I can see a lot of function declarations (prototypes?), assembler directives, etc., etc., but nothing that looks like actual code. So are the definitions in stdio.h actually referring to something else located somewhere else, or am I misunderstanding this completely? Is the code embedded in the compiler and hence hidden from the user? I've checked a couple of reference books but can't find a straight answer to this question.

Thanks again...

Hi Chris,

Yes, that is fairly normal; the standard C library is usually pre-compiled, and "linked" with your program when you compile it. Because all these functions are well defined and common, yet the implementation is usually specific to a particular compiler, they are usually considered part of the whole compiler toolchain package.

A useful reference of the C functions is:

• http://www.cplusplus.com/reference/

Simon

Hi Simon,

Thanks - very useful. I think I was worrying about things I don't need to worry about.

Best regards,

Chris.

I was wondering if there is also a support for the iostream libraries in C++ (see http://www.cplusplus.com/reference/iostream/) When I enter something like

#include <fstream>

main()
{
  ofstream ofs; 
  ofs.open("/local/test.txt"); 

the code compiles without errors, but this

#include <sstream>

...
 ostringstream oss; 

will cause errors, not at the include line, but when I use the ostringstream command. In conclusion, there seems to be partial support for iostream libs, but not completely.

Are there plans to support string handling as well? Would this be a possible contribution from the community?

Best regards,

Thomas

During my quest of finding a suitable XML parser I experimented with the iostream library quite a lot, IIRC I even added a string stream. The main problems were that I hit a compiler and/or library problem (which should be fixed by now) and that it eats memory like hell. Not only takes it flash, but especially RAM. It easily eats 10k or so, which together with TCP/IP leaves not so much room for doing real work.

Hi

Perhaps time to look at the compiler manual?

http://infocenter.arm.com/help/topic/com.arm.doc.dui0491c/DUI0491C_arm_compiler_reference.pdf

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/Babfcgfc.html

wvd_vegt

Hi!

Thank you for the information! You're right, the memory consumption is probably too big for this on a µC, I forgot this.

But it's great fun and so easy to program this microcontroller.

Have fun and a nice weekend! Thomas

Hi,

I note Simon's reference to http://www.cplusplus.com/reference/ but is there an actual mbed compiler reference document? Of course there are the handbook pages but for more general C++ questions that are specific to mbed it would be good to have something to go to for answers.

Thanks, Peter

Yes, check the ARM Compiler Toolchain reference (I'm not sure which version is currently used on mbed.org, but 5.0 should be close).