Follow Us
Categories
Archives
- February 2024
- January 2024
- August 2023
- December 2022
- November 2022
- October 2022
- February 2022
- October 2021
- September 2021
- August 2021
- July 2021
- June 2021
- May 2021
- January 2021
- November 2020
- October 2020
- August 2020
- April 2020
- February 2020
- January 2020
- October 2019
- September 2019
- July 2019
- May 2019
- April 2019
- March 2019
- February 2019
- January 2019
- December 2018
- October 2018
- September 2018
- August 2018
- July 2018
- April 2018
- February 2018
- January 2018
- December 2017
- November 2017
- October 2017
- September 2017
- August 2017
- July 2017
- June 2017
- May 2017
- April 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- April 2016
- January 2016
- December 2015
- November 2015
- October 2015
- September 2015
- August 2015
- July 2015
- June 2015
- May 2015
- January 2015
- December 2014
- November 2014
- October 2014
- September 2014
- August 2014
- July 2014
- June 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- November 2013
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- February 2013
- January 2013
- November 2012
- October 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- December 2011
- November 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
Author Archives: Glennan Carnie
Making things do stuff – Part 4
In the last article we explored the design of a class to encapsulate a physical hardware device. In that article I deliberately ignored how the class would actually interact with the hardware.
In this article we explore the options available to us for accessing hardware and the consequences of those
Posted in ARM, C/C++ Programming, Cortex, General
Tagged Class, GPIO, hardware manipulation, IO, Modern C++. C++11. C++14, STM32, STM32F4 Discovery
Leave a comment
Making things do stuff – Part 3
Previously, we’ve looked at the basics of hardware manipulation in C++ and applied that to a simple GPIO implementation.
In this article we’re going to have a look at encapsulating our code in a class and look at some of the design choices we have to make.
If you’re not familiar with hardware manipulation in C++ I’d highly recommend reading the previous articles in this series before continuing.
Even if you’re familiar with the concepts of hardware manipulation, if you haven’t read the […]
Posted in C/C++ Programming, Cortex, Design Issues
Tagged Class, GPIO, hardware manipulation, IO, Modern C++. C++11. C++14, Object-Oriented Design, OOD, STM32, STM32F4 Discovery
1 Comment
Making things do stuff – Part 2
Last time we looked at the basics of hardware manipulation in C++. This time we’ll apply this to some real hardware and have a look at the code
Posted in C/C++ Programming, Cortex, General
Tagged Cortex-M, GPIO, hardware manipulation, IO, Modern C++, Modern C++. C++11. C++14, STM32, STM32F4 Discovery
4 Comments
Making things do stuff – Part 1
C has long been the language of choice for smaller, microcontroller-based embedded systems; particularly for close-to-the-metal hardware manipulation.
C++ was originally conceived with a bias towards systems programming; performance and efficiency being key design highlights. Traditionally, many of the advancements in compiler technology, optimisation, etc., had centred around generating code for PC-like platforms (Linux, Windows, etc). In the last few years C++ compiler support for microcontroller targets has advanced dramatically, to the point where Modern C++ is a increasingly attractive language […]
Posted in C/C++ Programming, Cortex
Tagged GPIO, hardware manipulation, IO, Modern C++. C++11. C++14
15 Comments
A convenient untruth
Array notation in C is a lie!
Sorry, dear reader*, but I cannot participate in this conspiracy any longer. You have been lied to, manipulated and coerced into thinking arrays are a construct of the C language. I feel it is my solemn duty to blow the whistle on this charade and expose the dirty secrets of C’s so-called arrays.
(* It is statistically possible that more than one person might read this, of
Death and (virtual) destruction*
This time, we’ll have a more detailed look at one of those everybody-knows-that elements of C++ – virtual destructors.
More specifically, I want to reinforce under what circumstances you should make your destructor virtual; and when you don’t need to (despite what your compiler might say)
(*there’s no
Getting your head around auto’s type-deduction rules
Automatic type-deduction is perhaps one of the more divisive features of Modern C++. At its core it’s a straightforward concept: let the compiler deduce the type of an object from its initialiser. Used in the right way this can improve the readability and maintainability of your code.
However, because auto is based on template type-deduction rules there are some subtleties that can catch the unwary programmer.
In this article we’ll have a look at auto in the context of the template type-deduction […]
Posted in C/C++ Programming
Tagged auto, C++, C++0x, C++11, C++1y, l-value, l-value references, r-value, r-value references, reference collapsing, type deduction
3 Comments
Great Expectations
Previously, we’ve looked at the basic concepts of function parameter passing, and we’ve looked at the mechanics of how parameters are passed at the Application Binary Interface (ABI) level.
Far too often we focus on the mechanisms and efficiency of parameter passing, with the goal: if it’s efficient then it’s good; that’s all there is to it. In this article I want to move past simple mechanics and start to explore function parameter design intent – that is, what can I […]
Posted in C/C++ Programming, Design Issues
Tagged C++0x, C++11, C++1y, copy policy, design, functions, Modern C++, move policy, move semantics
2 Comments
The three ‘No’s of sequential consistency
In the previous article we looked at the memory consistency problem that occurs when writing multi-threaded code for modern multi-processor systems.
In this article is we’ll have a look at how we can solve the sequential consistency problem and restore some sanity to our programming
Posted in ARM, C/C++ Programming, Cortex
Tagged atomic, C++, C++11, C++14, multi-threading, race condition, sequential consistency
Leave a comment
Memory consistency made simple(ish)
The C++11 memory consistency model is probably one of the most significant aspects of Modern C++; and yet probably one of the least well-understood. I think the reason is simple: it’s really difficult to understand what the problem actually is.
The memory consistency problem is a concurrency problem. That is, it’s a problem that occurs when we start writing multi-threaded code. More specifically, it’s a parallelism problem – the real subtleties occur when you have two or more processors executing code.
In the first […]
Posted in C/C++ Programming, Design Issues, General
Tagged C++, memory consistency, sequential execution
2 Comments