Shop OBEX P1 Docs P2 Docs Learn Events
Sending state of pin over serial line like an oscilloscope? — Parallax Forums

Sending state of pin over serial line like an oscilloscope?

zepperikzepperik Posts: 16
edited 2018-01-05 22:00 in Propeller 1
I want to debug the signal my input pin is receiving. Its on a vehicle so I figured rather than trying to attach an oscilloscope to it, I'd just send its state via serial line.

The hiccup I'm facing is that there doesn't seem to be any good way to send a bit stream of samples. I resorted to using a stream of bytes for each sample using a line of code like
repeat PST.Char(ina[pin])
But the problem here is that at a baud rate of 115_200, my limit is really only a sample rate of about 14,000hz and after adding other lines of code, I can't get above 8000hz. If you don't add a waitcnt() in that loop, it will call the command too frequently and crash.

So is there any way to send a bit stream of the state of the pin? Basically if I had a sample rate of 1,000hz, I'd need my variable to hold bits with each next bit representing the state of the pin every next millisecond: 0,0,0,0,1,1,1,1 being samples at 1,2,3,4,5,6,7,8 ms.

Comments

  • Maybe SpinScope will help:

    http://forums.parallax.com/discussion/157982/spinscope-a-virtual-oscilloscope-for-the-propeller/p1

    All you need is a PC laptop running a browser and a serial connection. No programming beyond starting the SpinScope object is necessary.

    -Phil
  • zepperikzepperik Posts: 16
    edited 2018-01-08 18:56
    Thanks Phil,

    This looks perfect! I had come across your post before realizing that I was running into a deadend with what I assumed was an easy task.

    Could I confirm a few things: This requires 3 cogs to run? And what is sample rate of this software?

    -Eric
  • jmgjmg Posts: 15,140
    Maybe SpinScope will help:

    http://forums.parallax.com/discussion/157982/spinscope-a-virtual-oscilloscope-for-the-propeller/p1

    All you need is a PC laptop running a browser and a serial connection. No programming beyond starting the SpinScope object is necessary.
    Very nifty - any progress/schedule for the Analog support ? :)

  • I haven't looked at the code in quite a while, so no progress on analog support. Of necessity, the bandwidth would be significantly curtailed by having to send eight bits over the serial port for each pixel instead of one -- unless I can come up with a compression scheme, such as tracking pixel-to-pixel changes with fewer bits.

    -Phil
  • jmgjmg Posts: 15,140
    zepperik wrote: »
    I want to debug the signal my input pin is receiving. Its on a vehicle so I figured rather than trying to attach an oscilloscope to it, I'd just send its state via serial line.
    ...
    So is there any way to send a bit stream of the state of the pin? Basically if I had a sample rate of 1,000hz, I'd need my variable to hold bits with each next bit representing the state of the pin every next millisecond: 0,0,0,0,1,1,1,1 being samples at 1,2,3,4,5,6,7,8 ms.

    There are a couple of ways to manage this.
    Simplest is to set up a UART that merely copies one chosen pin, into the TX slots, at the Tx rate.

    This gives sample points at the baud rate, but does have small pauses over the Start and Stop bits. ( 8 bits of info, in 10 bits of time)
    The simplicity of this design allows quite high baud rates, (< 1us sample gaps) which will compensate somewhat for those pauses.
    In many applications, those jitter points will be fine ?

    More complex, and of lower speed in one COG, is to effectively run a small bit-fifo, to smooth the gaps.
    With 10 baud slots, if you read and buffer the pin every 1.25t, you get 8 samples. This is still unlikely to be perfectly even, as a single core cannot read a pin and output TX edge in the same sysclk.
    A small bit-fifo of a couple of bits depth is all that is needed.
    With an unrolled sample/send loop this might still manage close to 1us sample rate ?

    Next step would be to sample 2 pins, or even 3 or 4 for a multi channel digital scope.
    zepperik wrote: »
    Finally, you mention an "analog" capability for monitoring duty-cycle output pins. How can I try that?
    Analog is going to be more of a compromise.
    A prop ADC needs to sample many times to get readings, and cleanest is binary ratios.
    Running some numbers, looking for a fit.... finds 512 samples (nominally 9 bits) sent as 8 bits gives :

    Using 2 stop bits, so fractional baud differences do not creep buffers & most USB-UARTS have at least a 12MHz virtual baud clock .

    SampleRateR = 80M/512 = 156.250 kHz
    nominal ByteRate = 12M/(11*7) = 155844.155 (6.4166us)
    BaudRate = 1714285 = 583.33ns
    Byte-Error is = appx 0.259%, so tolerable, but bit granularity is trickier.
    P1 has 4 Sysclk granularity in opcodes, so gives 600ns for 48 sysclks, or 550ns for 44 sysclks.
    An unrolled TX can dither 600/550 to average closer to 583.33
    eg possible dither choices could be
    8*(48/80M)+(11-8)*(44/80M) = 6.45e-6 = 0.516%
    7*(48/80M)+(11-7)*(44/80M) = 6.4e-6 = -0.260% ie 7 bits are sent /48 and 4 bits are sent /44 for 1.56250MBd precise
    6*(48/80M)+(11-6)*(44/80M) = 6.35e-6 = -1.049%
    11 or 12 opcodes per bit seems comfortable ?
    That 1.56250MBd precise is 10.971 baud bit times, so most RX bytes have 2 stop bits, whilst ~ 3 in 100 will have 1 stop bit.


    A few UARTS have 24MHz Virtual Baud Clocks (FT2232H,FT232H,CP2102N), so there might be another solution point for those, of
    BytePeriod=11*7/24M = 3.208us (256 ADC sample clocks) - sample rate 312.500 kHz
    9*(24/80M)+(11-9)*(20/80M) 3.2e-6 = -0.260%
    This optional faster candidate, needs 5 or 6 opcodes per bit, more of a challenge....


  • ... Of necessity, the bandwidth would be significantly curtailed by having to send eight bits over the serial port for each pixel instead of one -- unless I can come up with a compression scheme, such as tracking pixel-to-pixel changes with fewer bits.

    -Phil

    Just to confirm, are you saying your code does or does not send one bit per pixel (sample)? I'm seeing a cleanly displayed signal of 100kHz when I test it and, on page 3 of your forum post, another user is claiming to see 3.25MHz. So if the serial line's baud rate is 115,000 bits per second, I don't understand how the 100Khz is possible to sample without taking a sample per bit - and I don't understand how 3.25Mhz is possible at all.
  • jmgjmg Posts: 15,140
    edited 2018-01-08 22:53
    zepperik wrote: »
    Just to confirm, are you saying your code does or does not send one bit per pixel (sample)? I'm seeing a cleanly displayed signal of 100kHz when I test it and, on page 3 of your forum post, another user is claiming to see 3.25MHz. So if the serial line's baud rate is 115,000 bits per second, I don't understand how the 100Khz is possible to sample without taking a sample per bit - and I don't understand how 3.25Mhz is possible at all.

    These posts seem to break down the details

    http://forums.parallax.com/discussion/comment/1301148/#Comment_1301148

    Here is a bit more info on the inner PASM code workings...
    '' This routine saves 17 longs for each channel, LSB first.
    '' The lower 13 bits of the first long are ignored (19 bits used)
    '' The upper 30 bits of the last long are ignored (2 bits used)
    '' This gives a total display of 501 bits for each channel in the 10 division scope screen.
    I am currently working on getting samples working at 1/16 clock rate. I don't expect to be able to do pre-trigger sampling this way tho'.
    Phil: What would be nice is to be able to expand the trace view plus scrolling ability.


    Seems it burst captures just 501 bits (one screen), then sends - the baud rate can be less than the sample rate, as continual sampling-send is not done.


    http://forums.parallax.com/discussion/comment/1301160/#Comment_1301160
    Here is the sampling working at 1/16 of the clock frequency.

    ie this upgrade means short-burst-capture can be higher, 5MHz (200ns samples) at 80MHz sysclk, or 6MHz at 96MHz sysclk.

    zepperik wrote: »
    ... on page 3 of your forum post, another user is claiming to see 3.25MHz. ... and I don't understand how 3.25Mhz is possible at all.
    Re what can be 'seen' - any sampling system reports the logic at timeslots, so it will report something on frequencies even above the sample rate.
    eg if you sample at sysclk/16, but generate sysclk/15, you will get a waveform out. likewise /14,/13,/12,/11,/10,/9,/7,/6,/5,/3 - but /8, /4 from same sysclk, will be stable points at t/16, so give static outputs.
  • zepperik wrote:
    Could I confirm a few things: This requires 3 cogs to run? And what is sample rate of this software?
    Yes, three cogs. Maximum sample rate is 500 kHz (2 usec/pixel)
    Just to confirm, are you saying your code does or does not send one bit per pixel (sample)? I'm seeing a cleanly displayed signal of 100kHz when I test it and, on page 3 of your forum post, another user is claiming to see 3.25MHz. So if the serial line's baud rate is 115,000 bits per second, I don't understand how the 100Khz is possible to sample without taking a sample per bit - and I don't understand how 3.25Mhz is possible at all.
    The code sends one bit per pixel. There are 512 pixels per line for 2 channels, so 1024 bits (128 bytes + protocol bytes) per scan.

    Yeah, forget 3.25 MHz. The user was obviously seeing aliasing on the scope display.

    -Phil


  • jmgjmg Posts: 15,140
    edited 2018-01-08 22:54
    jmg wrote: »
    A few UARTS have 24MHz Virtual Baud Clocks (FT2232H,FT232H,CP2102N), so there might be another solution point for those, of
    BytePeriod=11*7/24M = 3.208us (256 ADC sample clocks) - sample rate 312.500 kHz
    9*(24/80M)+(11-9)*(20/80M) 3.2e-6 = -0.260%
    This optional faster candidate, needs 5 or 6 opcodes per bit, more of a challenge....
    Just checked a CP2102N, with a terminal and frequency counter, to confirm that Requested BAUD rate = 3428571 (8,N,1) is real, for my idea of continual streaming read-send ADC sampling (no burst limits at all).

    Measured frequency, 100k file of 'U' = 1.71481MHz, 1.71392MHz, 1.71426MHz (notice small jitter effects)
    Checking 3428571 (8,N,2) predicts Frequency of 10/11*24M/7/2 = 1.558441 MHz => Measures 1.558326 MHz

    These are less than 0.1% from the requested/expected baud rate, but not precise as the CP2102N is a crystal-less part, so locks a local RC Osc to the 1ms USB frame.
    With a crystal P1 sending, that small jitter is removed/eliminated.

    In digital terms, that sample rate 312.500 kHz per byte, maps to a might be possible bit-sample of 2.5MHz, 8 bits per byte. Half this, of 1.25MHz, is certainly looking easier.


Sign In or Register to comment.