As a result of the currently running thread on the technical, costs ( or not ) of C++, and an ongoing personal fascination with just what is possible at compile time, I am looking at building a series of applications in C and C++ to solve a number of different problems. I would, however, like any pointers others might have on specific applications that might be representative of projects that would not be considered 'toy' applications, but are still of sufficient simplicity to be understandable.
As I am currently working on a prototype board to go to fab ( hobby application ), I could make minor changes so that it could act as a hardware platform for those tests. As such, here is what I have in mind. The board will be based on an AtMega164(pa) processor running at some USART friendly frequency, probably 18.432 MHz to remove clock speed as an obstacle to the comparison; this would be the processor ( and code ) under examination. A second processor would be included for the sole purpose of monitoring the primary processor. This monitor would be able to sample drive voltage and current of the primary and would have an interrupt line connected to the primary, setup for timing of the main loop execution ( via asm start(), end() functions that would be consistent across the C and C++ code ). This monitor processor would send information back to a computer to log the status of the main code to be combined with compilation information.
The current applications I have in mind should have no trouble fitting in the memory so that simply 'writing the program as seems appropriate' should be a reasonable approach. Also, though, I think that multiple optimization options should be tested as I have seen large differences in even -O2 and -Os when compiling C++; also, different command line flags can change the final application size appreciably so that should be standardized as well.
The first goal, it seems, should be to come up with a basic set of applications. I believe that they should be representative of the types of applications that an AVR might typically be a suitable choice for ( certifications not withstanding ). I currently have a few ideas,
1. A traffic corner with walk/stop indicators, walk request buttons, and car sensors. The primary advantage of this idea may, perhaps, also be its greatest downfall. Because it so visual it almost requires interaction and it would be difficult ( if not impossible ) to do testing of the system without quite a bit of external support equipment. Either way, it represents a large, but reasonable, FSM. As such, something like it should be include in the set of applications.
2. A watt meter combines input ( analog ), mild computation, and output ( digital - LCD ). As a fairly balanced application it should act as a reasonable reference for C vs. C++ when there are no overwhelming specialized constraints.
3. A spectrum analyzer for an electric guitar ( or signal of similar range ). This would, of course, test the computational overhead of different implementations. Moreover, it will stress the memory ( SRAM mostly ) constraints of the system and, therefore, give a window at memory specific constraints.
As I see it, none of the above applications require dynamic memory allocation so if that is a comparison that ought to be made, I will need some suggestions as far as suitable applications is concerned. I would also like suggestions regarding testing practice. I believe that it would be useful to generate statistics on lines of code, flash required, sram required ( perhaps including heap ), etc. Also useful would be processor current ( need to design so that necessary output currents don't obscure the signal ), maximum, minimum and average. Then run these steps over a long enough period to get rid of any random noise.
I have a project with something a of time limit that will need to be finished before any major work is expended toward this idea, so there is time for further discussion and questions - especially questions. If anything seems silly or weak, I'd love to hear it as my hope is that this could lead to some more concrete data than, 'in my experience X or y SEEMS to imply Z ( or maybe G ).'
Martin Jay McKee