Shop OBEX P1 Docs P2 Docs Learn Events
Least intrusive debugging... — Parallax Forums

Least intrusive debugging...

groggorygroggory Posts: 205
edited 2011-02-11 10:24 in Propeller 1
For all the programs that my friend and I have written so far we have always used the Full Duplex Serial Driver as a debug port during dev. However, during some time sensitive things enabling our debug lines of code really slowed things down. Would moving to a video driver (Composite or VGA) instead of serial be a faster and less intrusive way to do debugging? It seems like it might being that the propeller has hardware video hardware in each cog.

Any thoughts?

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2011-02-10 16:04
    It takes about 1ms per character to send debug text to a PC. The normal FullDuplexSerial object has a 16 byte output buffer and that can fill up pretty fast. You can

    1) Keep your debug strings very short

    2) Increase the size of the output buffer and/or increase the Baud

    3) Switch to using a TV or VGA display for the debugging. Normally the display buffer can get fairly large and the TV needs at least 3 I/O pins or VGA needs typically 8 I/O pins. There is a 1-pin TV driver in the Object Exchange and there is a TV driver used in Sphinx that keeps its display buffer in the cog's memory. It still takes some time to handle the display of debugging information, particularly when the display screen is rolled up.
  • Bobb FwedBobb Fwed Posts: 1,119
    edited 2011-02-10 16:23
    I thought I saw someone announce a zero-footprint debugging object at one point (but maybe that was zero-memory -- not sure how that would happen -- I thought they were referring to the "intrusiveness" of the debugging).
  • jazzedjazzed Posts: 11,803
    edited 2011-02-10 17:09
    Using a TV/VGA monitor will be faster than a serial port but you lose the "record" of all transactions.
    A TV driver like Bagger's Half-Height TV Text objects will give you more display area for debug info.
    A scrolling window in half the display would not be too hard to make ... just look at the way new-line works.
  • Cluso99Cluso99 Posts: 18,069
    edited 2011-02-11 01:46
    I posted a 1pin TV debug driver in Obex that takes very little hub footprint for this purpose.

    My zero footprint debugger is also in the obex. It uses the shadow ram in cog to step through the program, but it slows the cog quite dramatically. It is a little complex to use, but can also trace spin and even switch the pasm debugging on for the spin interpreter.
  • Beau SchwabeBeau Schwabe Posts: 6,568
    edited 2011-02-11 10:05
    You could run the Serial "debug' in it's own cog and just pass the variables you want to see?
  • HollyMinkowskiHollyMinkowski Posts: 1,398
    edited 2011-02-11 10:24
    If you have an extra prop you could create a debug/analyzer tool with it.
    Output the debug data to a monitor, also sometimes outputting audio
    alerts is useful...especially if while working on the circuit under test you
    are unable to easily watch a monitor. You need not limit the audio alerts
    to simple beeps as the prop is capable of playing good quality audio clips.
    You can log the debug data in the eeprom or an sd if there is a lot of it.
    You can create a fast routine in a cog and send the external prop debugger
    a simple stream of debug data on a single pin. You can also use your
    prop tool to monitor all sorts of data from the project under test. The prop
    really shines as a custom analyzer....it is truly awesome waht you can do with
    it. :-)
Sign In or Register to comment.