next topic »

[Reply #15 on:]

Code:

void Print::pgm_print(PGM_P PROGMEM str) {

      uint8_t c;

      while((c = pgm_read_byte(str)) != '\0') {
            this->write(c);
            ++str;
      }
}

void Print::pgm_println(PGM_P PROGMEM str) {

      this->pgm_print(str);
      println();
}

Is code that I have added to the standard Print library. This gives me two new methods pgm_print and pgm_println that will print strings from progmem instead of sram. Since the hardware serial class inherits from Print it inherits these methods as well. Hence Serial.pgm_print will print progmem strings to the serial interface.

The PSTR macro is a standard macro of AVR LIBC. It defines a progrmem string in place.

An example was already provided:

Code:

     #ifdef TRACK_FOCUS
      Serial.pgm_print(PSTR("next focus: "));
      Serial.println((*screen).focus, DEC);
      Serial.pgm_print(PSTR("current top row: "));
      Serial.println((*screen).top_row, DEC);
      #endif

This does the following: if TRACK_FOCUS is defined the 4 debug lines will be compiled into the code. Instead of       Serial.pgm_print(PSTR("next focus: "));  I could write       Serial.print("next focus: "); However the first statement will put the string into progmem and the second one will put it into sram.

So I do not write debug information into memory. If I would try to do this I would write debug information into eeprom and read it with a programmer later on. Writing debug information into progmem would be theoretically possible but this is something I would rather avoid until I have absolutely no other option.

[Reply #16 on:]

udo: The unit test frameworks will track bugs not detect them. The detection part is done by the unit tests.

a unit test framework will help you write unit tests, no? that is one part of many things that a unit test framework can help you with. in fact, a unit test framework will help you detect bugs more than "track" them. a bug tracking system is complementary to a unit test framework (i.e. use junit for unit testing and as a unit testing framework, use bugzilla/jira to track bugs).  


udo: In my opinion the detection part is the hard work. The tracking and reporting is trivial if you are a one person project. You just call all you unit tests and print the output. Unless you expect hundreds of tests to fail on a regular basis you do not desparately need a fancy framework.

tracking and reporting bugs is non-trivial. have you looked at frameworks and web applications dealing with bug tracking and/or reporting? you're arguing that these items/tools/practices are not relevant to a "one person project", and, in my opinion, that is wrong. i have taken on many contracting positions involving "one person" (just me) in software engineering, and i do use bug tracking software, unit testing framework, version control, etc...

udo: If you want to contribute a unit test framework feel free to do so.

i might need to given your helpful comments and code here.

udo: Just out of curiosity: what are those other industry standards you apply?

in regards to software engineering: unit testing, design patterns (mvc, ioc, fc, etc...) , agile development (xp), version control, continuous integration, etc...

cheers.

[Reply #17 on:]

@jakester
In all the work you've done, the development has been on the same platform that the executable is to be run on, right?

When developing code for the Arduino, the development is done on the PC, and the execution is done on the Arduino.

That is a fundamental change, and one that does not lend itself to unit testing within a test framework. The test framework executes the code on the same platform it is running on. It would be very difficult to fit a unit test framework and bug tracking system on the Arduino, along with the code to be executed.

But, if you're able to pull it off, that would be great. Keep us posted on your progress.

[Reply #18 on:]

Absolutely correct. But given the fact that some people are already in developing AVR emulators in software it would be cool to have a test framework that emulates and tracks everything. Since the processors are small enough even omniscient debugging http://en.wikipedia.org/wiki/Omniscient_Debugger would then be feasible. This would be really extraordinary. However this would be much more work than just some unit test framework

[Reply #19 on:]

pauls, that's not unit testing anymore. i think you're walking into the realm of functional testing then (when you're executing on the runtime platform). are we all talking about the same thing here?

ideally, code should be tested, and best practices suggest at a "unit" level (your coding should produce fine and self-contained units of  logic). theoretically, regardless of programming language, code is unit testable (complicated, as suggested in this thread, by programming habits).

even if you code in java and test using a java unit testing platform, successful testing on a developer machine will not mean necessarily that on a server machine the code will produce the same results (read the specs on jvm in client/server mode). meaning, writing and unit testing code on what is supposed to be the "same platform" in development and deployment do not make bug detection any easier (than if the environments were different).

at any rate guys, thanks for all the help. i think i've got enough to go on and workaround the limitations. you've all been very helpful and kind.

cheers.

[Reply #20 on:]

We are using Arduino boards for data acquisition in a large scientific experiment. Subsequently, we have to support several Arduino boards with different implementations. I wrote python utilities to dynamically load Arduino hex images during unit testing. The code found on the link below supports Windows and OSX via configuration file. To find out where your hex images are placed by the Arduino IDE, hit the shift key before you hit the build (play) button. Hit the shift while hitting upload to find out where your avrdude (command line upload utility) is located on your system / version of Arduino. Alternatively, you can look at the included config files and use your install location (currently on Arduino 0020).

[Reply #21 on:]

That post above was my first post and it wouldn't let me include a link. Here is the link to the python unit testing / loading code.

http://github.com/toddstavish/Python-Arduino-Unit-Testing

[Reply #22 on:]

In my day job, I am a great fan of test-driven development, but one of the things I love about the Arduino is that I can have it do all manner of fancy things in a few dozen lines of code.

I don't need unit testing because its all so delightfully concise and simple.

You need it when your building systems with 100,000 lines of code for a machine with 4GB.

2K and worried about TDD -- I don't think so

[Reply #23 on:]

I don't need unit testing because its all so delightfully concise and simple.

The fun stops when one single line of code produces strange effects sometimes and you have no clue if it's a resource conflict, something in the hardware or your software.

And to top it off, whenever you try to debugging, you end up measuring the effects introduced by your debugging probe and not the problem.

Real men debug with oscilloscopes and chainsaws.

Korman

[Reply #24 on:]

Real men do not debug at all  8-)

[Reply #25 on:]

AlphaBeta, you have a point here.

Chuck Norris doesn't debug - all bugs flee in terror when he turns on the power.

Korman