Having fun now!

photomankc

So I have been struggling with the fact that using printf in a C++ project for anything other than static text basically precludes using LMM at all because of code size. Any '%d' or what-have-you results in a huge jump in code size. I don't like burning a test run to FLASH or EEPROM with XMM to try to debug something over and over. So I was trying to come up with an idea. I know the Arduino's Serial.Print() is not nearly as flexable as printf() but it also doesn't have the code size price tag either so I started looking at it and then it dawned on me. I have an I2C LCD that i never did much with laying on the bench. I also have a nice I2C class I just got done fighting with. Maybe I can port over the String class and the Print class from the Arduino environment and make something simlar to Serial.Print() for the LCD. Just getting a few lines of text, some HEX numbers, and decimal values would cover 90% of my needs for debug output and later on the Robot might look mighty slick with a nice LCD status dispay.

Took about a night to build up my I2C_LcdDisplay class using I2C. Now I have some debug output in a footprint that is less than half of that when printf() is used in a c++ project.

Feel like I'm starting to get back in the swing of this. I really love that you guys have brought C++ over to the Propeller I. It may have it's limitations but I'm having a really good time here and soon may have a decent little library to build my Robot on top of. I plan to press on with this and polish up the LCD/Print/and I2C class. I think Print could be wrapped around puts()/putf() fairly easily and that would also seem to shed a LOT of weight and provide a lighter weight debug serial output that C++ can't seem to get with simple_printf right now. Not sure how much interest there would be in that.

jazzed

Been busy I see. Glad you're putting the I2C code to good use.

There are also some examples like the SPIN TV_Text in the propgcc/demos/TV folder:
http://code.google.com/p/propgcc/source/browse/#hg%2Fdemos%2FTV%2FTvText_demo
TvText.c has the str(), dec(), hex(), and bin() functions in it.

Regarding size, I've been testing code today that make great improvements in code size. Can't promise when it will be ready, but things look pretty good so far. We're also thinking of making Ted's Tiny Library a regular option.

I'm definitely interested in seeing your code. I have an old project that has an I2C interface between two propellers where the second one has a VGA and other peripherals connected. There is already I2C secondary code available for propeller for decoding commands. So much to do, so little time ....

Nice picture BTW.

photomankc

Thanks. The iPod camera is a handy thing sometimes, if not the nicest quality. I think the PropGCC I2C implementation as a driver looks really nice from what I see in the library. My effort in building my own was to make the entire bus transaction from START to STOP atomic. I need to manage several devices that use repeated start and I can't have another cog driver that might also be using the I2C bus come stomping in after a partial operation from another cog or thread has just completed. My I2C builds the entire transaction and thus everyone else waiting for idle knows that they can go on and do their transaction once the bus goes idle. I also support clock stretching because I do a lot of my sensors as I2C peripherals on other MCs and some will stretch the clock if they are not ready yet.

I'll pop the code out here once I'm done. The Arduino stuff I borrowed (String/Print) is LGPL though, not MIT, so I don't know how that might complicate things if anyone borrowed from these objects.

The most daunting code is ahead though. Will likely be looking at a multi-threaded main application for the behavior-based control of the robot. It's much easier to do this if the behavior arbitration code is running in another thread of execution.... although... I never really thought of pthreads as "easy".

photomankc

Alright, after fighting the compiler for a few hours because they picked uint8_t in place of char which generated a mountain of puke over types I have implemented this to mimic the Arduinos print() and println() syntax. The LCD + support classes and libraries weigh in at about 16K. That's down from 18K after I cleaned up a lot of redundant code in the I2C class. I also trimmed the String class to no float or doubles and eliminated some of the fluff, I think still more could go.

So at present this handles just the Newhaven Serial / I2C / SPI LCD set to operate on I2C. Integer values of arbitary base are supported to include binary. The LCD will line wrap over the top if you keep doing println() and that's the best I can do without creating a shadow ram space to hold all the text so I can shift it up to scroll rather than wrap. You can clear individual lines as well as clear single or multi-line windows of space. So to continually update 3 variable fields without retransmitting the static text you do thus:

i = 0;
    lcd.Cls();    // Just print the static text once.
    lcd.println("Dec Var: ");
    lcd.println("Hex Var: ");
    lcd.println("Oct Var: ");
    while(1)
    {
    	lcd.ClearWindow(0,9,3,19);   // Clears (0,9) to (3,19)    (row, col).  Sets cursor to begining of that window.
    	lcd.print(i, DEC);
    	lcd.SetCursorPos(1,9);
    	lcd.print(i,HEX);
    	lcd.SetCursorPos(2,9);
	lcd.print(i, OCT);
	i--;
	usleep(250000);
    }

This seems to work pretty well, stays small and will do nicely for updating basic readout fields.



4 lcd.println() produce this:



The next print() wraps over the top.



Clearing a window from (1,0) to (3,13)



Displaying continously updated variables in the in a window from (0,9) to (3,19)