Looking for a standard battery of test applications

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Something with HD44780 would be good as this must figure in a LOT of embedded solutions and it'd be interesting to see this familiar code written in the C++ way. Obviously UART to PC is a very often implemented solution to. So maybe something with LCD+buttons that presents a nested menu system that can equally be driven over UART (if I understand C++ correctly the idea of using common core code with two different interfaces is one of the areas where it shines?). I'm personally interested in FAT on SD though maybe it wouldn't be fair to suggest that someone applies C++ to Chan's FatFs code as that would probably be a major undertaking. (Also the 16K micro could be a limit - though I guess there's the Petit version)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Something with HD44780 would be good as this must figure in a LOT of embedded solutions and it'd be interesting to see this familiar code written in the C++ way.

I was already thinking that the watt meter application could fairly nicely integrate the LCD and buttons. It would, perhaps, be interesting to look at interface changes with different LCD controllers.

One stumbling block in general with I/O the 'C++ way' is that there needs to be a streams hierarchy in place. That is true with UART communications, LCD and, yes, file systems. There are, therefore, two major things that would have to be completed for a reasonable test of a FatFs implementation: the filesystem itself and the file streams. As I haven't actually looked at the implementation I can't say how long a translation would take, but I would assume it could be appreciable; the design process is often crucial for successful 'objectified' code.

I also would be fully willing to make the reference controller a 644, or 1284 if I can get my hands on it so that there are no real memory constraints. After all, the real test is the actual size of the programs, where they are bloated ( or not ). Decisions as to whether or not the code size differences are critical would depend very much on who you ask. The numbers should speak for themselves.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."