Shop OBEX P1 Docs P2 Docs Learn Events
SHIFTOUT (not SEROUT) vs DEBUG (typo, sorry!) — Parallax Forums

SHIFTOUT (not SEROUT) vs DEBUG (typo, sorry!)

xanatosxanatos Posts: 1,120
edited 2012-10-26 11:09 in BASIC Stamp
I see that SEROUT SHIFTOUT is spec'd (for the BS2sx) at 42kb/sec, and DEBUG is 9600b/s. I'm not missing anything there, correct? SEROUT SHIFTOUT should, for a given character string, take about 22% of the time (or be ~ 4.3x faster than) the DEBUG statement. Yes? Any hidden timing overhead I'm not taking into account?

Thanks,

Dave

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-10-20 14:04
    Dave,

    With SEROUT you have to specify the baudrate. It's not automatically 42 kBaud. Also, SEROUT to "pin" 16 does not automatically open the debug window the way DEBUG does.

    -Phil
  • xanatosxanatos Posts: 1,120
    edited 2012-10-20 14:40
    I'm sorry - I meant SHIFTOUT, not SEROUT... my error, I was rushing to get out the door for a walk while it's still beautiful out! Yes, I've been using both SEROUT and SHIFTOUT for years, just never had to compare them to DEBUG before. Sorry to be confusing with my careless typing. :-)

    Dave
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2012-10-24 12:17
    DEBUG is design specifically to make use of the programming port on the BASIC Stamp Module to get data to the PC easily (without having to setup parameters for SEROUT), while SHIFTOUT is designed to move data to an SPI (synchronous serial) interface. The two comands really aren't related and on top of that some of the formatting available to DEBUG and SEROUT aren't available to SHIFTOUT. If you have more questions on this, please reply to this thread.
  • xanatosxanatos Posts: 1,120
    edited 2012-10-24 14:11
    Hi Chris,

    Thanks. I must have really just worded my whole question wrong! I was using debug to reflect data derived from a quadrature encoder setup. Using debug, the counter slipped counts if I spun the encoder wheel at much more than one or two revolutions per second. HOWEVER, the debug statement was only to display data at the development phase of the project. The actual data will be displayed on an MC14489 5-digit decoder/driver/multiplexer, which uses SHIFTOUT, so in my development, DEBUG and SHIFTOUT are indeed related :-) I have subsequently determined that the SHIFTOUT statement does allow a significantly faster turning of the wheel than the DEBUG statement allowed, and so my worries about maximum wheel speed have been laid to rest. With SHIFTOUT running now, I can get about 5 revolutions of the wheel per second before I get count slips, and that should be faster than it will ever see in normal use.

    This would have been a lot smoother of a question if I had worded it better to begin with! :-) To those why tried to help, Thank You, and sorry for the poor wording. I think if I had described WHY I was comparing DEBUG and SHIFTOUT to begin with it would have been much better...

    Dave
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2012-10-24 15:36
    No problem. But yes, anytime the BASIC Stamp has to stop and update a display, for example, that will delay reading the encoder. It is definitely a balancing act trying to get everything to update and read in a timely manner on a single-tasking microcontroller. But it can be done. DEBUG, besides being a bit slower has a significant code overhead. Each time you add a DEBUG statement look at the memory map and see the effect. So only use DEBUG when necessary, especially in large programs.

    As a note I have some code that reads an encoder and updates a display as well. It was listed in the Solder Pot Controller Project, however to make up for some timing loss on the encoder I was using a BS2px24 Module.
  • xanatosxanatos Posts: 1,120
    edited 2012-10-24 18:26
    Hi Chris,

    Thanks. And I'm also using the BS2px with the pretty-much single line quadrature reading code that XORs the channels to increment or decrement as necessary. Very slick! This I believe was your line:
    counter = counter - 1 + (2 * (newBits.BIT0 ^ oldBits.BIT1))

    Can't get much more efficient than that! Thanks for putting that out there, it works fantastically well.

    And just to put the DEBUG thing to rest once and for all, I was only using it to check my data in development... I program one task at a time, and often in development DEBUG is perfect to see if I'm getting the right numbers without adding a lot of other code and circuitry for display or other processing of my data. It's a rare program of mine when a DEBUG survives to the final product! :-)

    Thanks again,

    Best,

    Dave
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2012-10-26 11:09
    Dave,

    Thanks for sharing all the details of things. I bet others who read this will benefit from the knowledge and experience. As for the code, I believe I borrowed that 1-line code trick from Jeff Martin, but it was so long ago I don't remember the details. We all learn from someone. ;) Take care!
Sign In or Register to comment.