Shop OBEX P1 Docs P2 Docs Learn Events
propeller c — Parallax Forums

propeller c

I am parsing a gps. When the clock hits 59 my screen jumps and sends a line of data below. Any ideas?? Thanks

// print("rmc magvar %s\n\n", _rmcmagvar);
print("day %d month %d year %d\n",day,month,year);

print("JD_adder %d\n\n",JD_adder);
print("A %d\n\n",A);
print("B %d\n\n",B);

// print("_gmathrs %d\n\n", _gmathrs);

// print("decimal_day %f\n\n", decimal_day);
// print("%c",NL);
print("%c",HOME);
pause(499);
388 x 238 - 4K

Comments

  • Hello pilot,

    How did you declared the variables "NL" and "HOME"? Displaying chars may be tricky. Anyway, there is a chance you may be printing a control character (like a TAB or a newline).

    Kind regards, Samuel Lourenço
  • I had to put the "c",HOME like that otherwise it won't work
  • Could you post all of your code? I'm assuming the problem you're referring to is the "1313" line. Maybe your program is trying to send two CRs, but is printing the decimal equivalent instead. It will help if we can see all of your code.
  • I pared it down to the problem. It only occurs when I print the clock data. If I eliminate the clock it does not happen. I have tried several of the print control commands to no avail.

    Thanks
  • I may have cured it with this:

    print("%c",CLREOL);
    print("%c",HOME);

    I set the timing to 1/2 sec as the gps feed is the same and I get a couple of characters that griefly show up and dissappear
    but I think they sould not show up at all.

    If you have a suggestion let me know.

    Thanks
  • Looks like that worked. It appears that I had the %c mixed?? what ever it worked ok for an hour.
  • Dave HeinDave Hein Posts: 6,347
    edited 2016-06-19 21:47
    I believe the problem was caused by the following lines:
     //  print("%d",BKSP);
     //   print("%d",CLREOL);
    
    As long as these are commented out there shouldn't be a problem. However, if you comment them out the control characters BKSP and CLREOL will be converted to an ACSII string representing the decimal values of BKSP and CLREOL. This are defined in simpletools.h as 9 and 11, so with those two lines uncommented you would have seen "911" on the screen. Your original example showed "1313", which could have been caused by having two print("%d",CR) statements. As you determined through experimentation, the "%c" format should be used to send control characters to the screen. Alternatively, you can just used putchar() to send out a single character, such as putchar(CLREOL).

    One comment about sending the newline character, NL. The standard IO routines will actually send both NL and CR characters when attempting to send the NL character. You have to put standard out into an uncooked mode to send out the NL character only. Using the uncooked mode is important when using the CRSRX, CRSRY or CRSRXY control characters followed by a value of 10.
  • Well, that makes perfect sense. Chars are numeric vars like shorts or ints. If you use %d or %i you are printing the equivalent decimal value. When you used %c, you told printf to print the var as a character.

    Kind regards, Samuel Lourenço
  • What is uncooked mode?
  • Uncooked mode allows sending raw bytes without any translation or extra bytes added. You can do this with the following line:
    stdout->_flag &= ~_IOCOOKED;
    
    This zeroes the cooked bit in the standard out struct. Standard I/O is also normally buffered, so it may be desirable to turn off buffering as well. Otherwise, output bytes will sit in a buffer until it fills up, or until a newline is sent.
  • Thanks. Where can I find more info about this and other modes. My C book does not talk about it.
  • pmrobertpmrobert Posts: 673
    edited 2016-12-17 22:26
    http://stackoverflow.com/questions/13104460/confusion-about-raw-vs-cooked-terminal-modes and it's couple of links helped me fully understand the raw-vs-cooked concept. Shamefully, it reminded me that I had already learned it from working with AT&T's Unix decades ago. :-)

    -Mike
Sign In or Register to comment.