Using VScode as editor

Some other folks have commented on VScode. I want to comment on C++14. I know this question is about a year old, but just in case a future reader needs some breadcrumbs...

When you say "use c++14" that is somewhat ambiguous. If you are referring to using basic / convenience features, like digit separators, binary literals, generic lambdas, 'auto' variables, or std::make_unique, then you are going to be fine with simply selecting the right compiler and rebuilding.

On the other hand, if you intend to use the threading (<thread> <mutex> <future> ...)  or time (<chrono>) libraries, then that is going to be a bit more work. The main challenge is that Keil can't predict what RTOS you will use: ThreadX, RTX, FreeRTOS, mbedOS, or any of a hundred others. And of course each OS has a slightly nuanced way of handling their primitive constructs. In spite of that, (thankfully!!), Keil has done most of the heavy lifting, by providing libraries with easy C-style callbacks for the places where these C++ libraries hook into the OS.

Contrast this with IAR, which doesn't provide anything at all, for example IAR's <thread> is a single error statement saying "#error "IAR Systems does not support thread". Yay IAR. 

Keil on the other hand, has a full <thread> implementation, up to the point of where a seam exists between the stdlib and the RTOS. And that is what you will have to fill in.

(As a small aside, GCC or specifically arm-eabi-none is in a similar camp as Keil -- see the '<bits/gthr-default.h>' file for the gcc porting layer - you would need to create and fill in a gthr file for your OS of choice).

Back to Keil, for a launch point, see www.keil.com/.../armclang_lib_wip1493208196925.htm.

For C++14, the basic steps are:

- TARGET TAB: pick compiler v6

- COMPILER TAB: enable RTTI, select the C++14 dialect, and add some defines: -fexceptions -D_ARM_LIBCPP_EXTERNAL_THREADS

- LINKER TAB: similarly, add some misc controls: --stdlib=threaded_libc++

Once you do this, you can use the C++ features creating a thread or initializing a mutex, and the linker will look for the ARMCLANG library callbacks. 

So for instance, the function:

int __ARM_TPL_thread_create ( __ARM_TPL_thread_t* __t, void* ( *__f ) ( void* ), void* __arg )

you would implement per your desired OS. An example native call would be FreeRTOS's xTaskCreate. Or if you are using CMSIS compliance then osThreadCreate. 

As you can probably guess, this effort of filling in Keil's hooks should not be underestimated. The stdlib definition has a lot of nuances, you will have to think about the ability to join threads, to how to handle threads that terminate before the next statement in the caller context, and so forth. I have done this for both IAR (see above, basically start from scratch) and for Keil (implementing the hooks).  IAR took 1-2 weeks. Keil took a 1-2 days. But the result is very rewarding -- after this, you are able to exercise just about any feature in C++14 you'd like.

If you make it far enough to have implemented the stdlib backend, then I would assume you are versed enough in OS design to be aware of initialization challenges, namely, starting the kernel. Unlike say, a Windows C++ executable, where main() is already spooled in the context of a thread (windows process), a bare metal executable needs main to start that OS itself. There are some tricks you can play regarding automatic OS launching but those tricks in my assessment tend to add minimal value. (For an similar non-OS-domain example, see how google-test discovers test suites and invokes them without an explicit registration by using static initializers). While witty and slick, these techniques for kernel management are only marginally superior to just accepting a limitation that main() will itself be an OS launch context, not a thread.

Some other folks have commented on VScode. I want to comment on C++14. I know this question is about a year old, but just in case a future reader needs some breadcrumbs...

When you say "use c++14" that is somewhat ambiguous. If you are referring to using basic / convenience features, like digit separators, binary literals, generic lambdas, 'auto' variables, or std::make_unique, then you are going to be fine with simply selecting the right compiler and rebuilding.

On the other hand, if you intend to use the threading (<thread> <mutex> <future> ...)  or time (<chrono>) libraries, then that is going to be a bit more work. The main challenge is that Keil can't predict what RTOS you will use: ThreadX, RTX, FreeRTOS, mbedOS, or any of a hundred others. And of course each OS has a slightly nuanced way of handling their primitive constructs. In spite of that, (thankfully!!), Keil has done most of the heavy lifting, by providing libraries with easy C-style callbacks for the places where these C++ libraries hook into the OS.

Contrast this with IAR, which doesn't provide anything at all, for example IAR's <thread> is a single error statement saying "#error "IAR Systems does not support thread". Yay IAR. 

Keil on the other hand, has a full <thread> implementation, up to the point of where a seam exists between the stdlib and the RTOS. And that is what you will have to fill in.

(As a small aside, GCC or specifically arm-eabi-none is in a similar camp as Keil -- see the '<bits/gthr-default.h>' file for the gcc porting layer - you would need to create and fill in a gthr file for your OS of choice).

Back to Keil, for a launch point, see www.keil.com/.../armclang_lib_wip1493208196925.htm.

For C++14, the basic steps are:

- TARGET TAB: pick compiler v6

- COMPILER TAB: enable RTTI, select the C++14 dialect, and add some defines: -fexceptions -D_ARM_LIBCPP_EXTERNAL_THREADS

- LINKER TAB: similarly, add some misc controls: --stdlib=threaded_libc++

Once you do this, you can use the C++ features creating a thread or initializing a mutex, and the linker will look for the ARMCLANG library callbacks. 

So for instance, the function:

int __ARM_TPL_thread_create ( __ARM_TPL_thread_t* __t, void* ( *__f ) ( void* ), void* __arg )

you would implement per your desired OS. An example native call would be FreeRTOS's xTaskCreate. Or if you are using CMSIS compliance then osThreadCreate. 

As you can probably guess, this effort of filling in Keil's hooks should not be underestimated. The stdlib definition has a lot of nuances, you will have to think about the ability to join threads, to how to handle threads that terminate before the next statement in the caller context, and so forth. I have done this for both IAR (see above, basically start from scratch) and for Keil (implementing the hooks).  IAR took 1-2 weeks. Keil took a 1-2 days. But the result is very rewarding -- after this, you are able to exercise just about any feature in C++14 you'd like.

If you make it far enough to have implemented the stdlib backend, then I would assume you are versed enough in OS design to be aware of initialization challenges, namely, starting the kernel. Unlike say, a Windows C++ executable, where main() is already spooled in the context of a thread (windows process), a bare metal executable needs main to start that OS itself. There are some tricks you can play regarding automatic OS launching but those tricks in my assessment tend to add minimal value. (For an similar non-OS-domain example, see how google-test discovers test suites and invokes them without an explicit registration by using static initializers). While witty and slick, these techniques for kernel management are only marginally superior to just accepting a limitation that main() will itself be an OS launch context, not a thread.