Dr. Miro Samek is the creator of the open source QP active object frameworks and the free QM graphical modeling tool. His practical books about UML state machines, active objects (actors), and event-driven frameworks for embedded systems are among the most popular on the market. Miro has also published dozens of technical articles for Embedded Systems Design, Dr. Dobb's Journal, and a column for C/C++ Users Journal. He is also the founder of Quantum Leaps (state-machine.com), an open source company dedicated to bringing quantum leaps of innovation to embedded systems programming by making software and tools that enable widespread adoption of event-driven active object frameworks, hierarchical state machines (UML statecharts), design by contract, rapid prototyping, modeling, and automatic code generation. Miro blogs at embeddedgurus.com/state-space/
Miro Samek's contributions
- Reflections on virtual functions in C
No. If anything, the C implementation of virtual functions might actually increase the RAM footprint. It depends where the virtual tables are allocated. It seems that the method of "copying and overriding" the virtual tables that Dan advocates would require allocating them in RAM. In contrast, the C++ compiler can (and typically does) allocate virtual tables in ROM, as they are known at compile time.
- Asserting failure
Disabling assertions in the production code may still be the beaten path approach, but it seems to me that one of the main purposes of Jack's article is to THINK about it for a minute. The often quoted opinion in this matters comes from C.A.R. Hoare, who considered disabling assertions in the final product like using a lifebelt during practice, but not bothering with it for the real thing. I personally find the comparison of assertions in software to fuses in electric circuits quite compelling. Imagine buying a brand new car and just before driving it on the street for the fist time, replacing all fuses with paperclips. Disabling assertions in production code is just as ridiculous. Of course, the assertion handler must be different and very carefully designed in the production code than during debugging. But for testing, leaving the assertions in is actually simpler, because you "test what you fly and fly what you test".
- A new RTOS trace tool
Software tracing tools aren't new. Some of the greybeards might remember the ScopeTools products originally developed by RTI in the 1990's (StethoScope, TraceScope, ProfileScope, etc.), which were then sold to Wind River Systems in 2005. However, even though the ScopeTools were really powerful and even more sophisticated than the ones Jack describes in this article, they somehow went extinct over the years. I'm not quite sure why, but perhaps because maintaining the tracing instrumentation manually was too big a pain for programmers in the long run. I realize that the tools (e.g., uC/Probe), can monitor any variable in the target, even without instrumenting the target code. But such "automatic" monitoring is necessarily limited to polling the variable at a certain interval. The value of such tracing for debugging the system is limited, because the Murphy's law will make sure that the bug will occur between the polling intervals. So, in the end, tracing the system *reliably* still requires manual instrumenting the application code. Also granted, that an RTOS can be pre-instrumented, but an RTOS "knows" only about tasks, semaphores, and other such low-level mechanisms, but does not know anything specific about the application. This hasn't changed for the past 20 years, from the days of the ScopeTools. I think that we need a game changer in the software architecture for software tracing to really succeed, otherwise we are "doing the same thing over and over again and expect different results", which is a definition of insanity. One development that I see as promising is to go beyond the RTOS to a framework. A framework is an "application skeleton" that can be pre-instrumented, so that it can report many more interesting occurrences than an RTOS. For example, a framework based on state machines can report all activities inside the state machines in the application, such as transitions, entry/exit to states, etc.
- Object-oriented C is simple: Part 2
Frankly, I find the title of this article overpromising and outright misleading. I've been waiting for the second part to see where the author is going with this, but so far the articles have really little to do with object-oriented programming. The author devotes already the second article to a very basic module-scope encapsulation, which is limited to a single instance of some "object". Object oriented programming is about managing an open-ended number of objects (instances of a class). For anybody really interested in object-oriented programming in C, I would highly recommend the recent series of excellent articles by Dan Saks on the subject matter (e.g., http://www.embedded.com/electronics-blogs/programming-pointers/4401463/Initializing-derived-polymorphic-objects). Miro Samek state-machine.com
- Initializing derived polymorphic objects
I think you might be confusing the semantics of "const *" with "* const", and perhaps also with "const * const" The "me" pointer in C corresponds directly to the "this" pointer in C++. In the C++ Standard, the "this" pointer is implicitly declared "* const", a constant pointer, because it cannot be changed. The declaration of "me" merely copies the C++ Standard in this respect. But please note that while the "me" pointer cannot be changed inside a class method, the object it points to can change. If you don't want to allow changing of the object, you can use the "const * const" declaration: void Shape_perimeter(Shape const * const me);
- mbed: A strange IDE
The mbed rapid prototyping platform is an interesting experiment in the embedded development "on the Cloud". The strength of the system comes from the online repository of code and the online community. Indeed, the system is specifically designed for easy sharing of source code among all the participants. However, at the same time the most important component of the system--the mbed library--is kept strictly *closed source* and is available only as a binary. This is by far the biggest problem of mbed as a platform (see the discussion "What happens if mebed.org disappears?" at https://mbed.org/forum/mbed/topic/245). This secrecy around the central library of code stifles innovation and really discourages improvements, which would benefit the whole community. For example, it turned out to be impossible to make the open source lwIP TCP/IP stack really work on mbed (see the discussion "Let's make TCP/IP really work on mbed!" at http://mbed.org/forum/mbed/topic/2073), because the polled Ethernet driver in the standard mbed library turned out to be inadequate. But because the source code was not available (remember, there is no debugger) the work has stalled. So, in the end it is, as always, all about software. Other interesting development platforms somewhat similar to mbed are: Arduino, which also now offers ARM Cortex-M3 board, and the dirt-cheap FRDM-KL25Z: Kinetis L Series Freedom Development Platform (http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-KL25Z). The FRDM-KL25Z board works very similar to the mbed board, in that you can just copy the binary image as a file to the board over USB. But, you develop and build the code locally. FRDM-KL25Z can also be re-programmed to provide the traditional JTAG debugger. Very interesting!