propeller c

Comments

• samuell Posts: 554

  2016-06-15 14:03

  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
• pilot0315 Posts: 834

  2016-06-18 22:28

  I had to put the "c",HOME like that otherwise it won't work
  
• Dave Hein Posts: 6,347

  2016-06-18 22:40

  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.
• pilot0315 Posts: 834

  2016-06-19 17:56

  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

  zip

  zip

  parsed gps print problem(1).zip

  931K

  parsed gps print problem(1).zip 930.6K
• pilot0315 Posts: 834

  2016-06-19 18:34

  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
• pilot0315 Posts: 834

  2016-06-19 20:15

  Looks like that worked. It appears that I had the %c mixed?? what ever it worked ok for an hour.
• Dave Hein Posts: 6,347

  2016-06-19 21:36 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.
• samuell Posts: 554

  2016-06-22 09:25

  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
• pilot0315 Posts: 834

  2016-12-12 14:27

  What is uncooked mode?
• Dave Hein Posts: 6,347

  2016-12-12 14:53

  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.
• pilot0315 Posts: 834

  2016-12-17 18:49

  Thanks. Where can I find more info about this and other modes. My C book does not talk about it.
• pmrobert Posts: 669

  2016-12-17 22:26 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