Shop OBEX P1 Docs P2 Docs Learn Events
Is it worth reviving the PropScope OpenSource Project? — Parallax Forums

Is it worth reviving the PropScope OpenSource Project?

Hi, it's been awhile since I've posted anything. In fact due to technical issues with my old account I had to open another account.

I was involved in OBC's Propscope project way back when and was thinking of the software advances since that project was started. With Xamarin a cross platform project could be developed. I don't know Xamarin but as a software developer I know I could pick it up quickly.

I have all the documentation Parallax and Hanno put out for the project but sadly I don't have any of the pasm code that was posted on OBC's PropellerPowered site. I do believe somebody at least had code for interleave sampling of the ADC in the PropScope. With that site being long since shut down I was wondering if anyone on the forum had copies?

I also wonder with the PropScope being discontinued a long while ago and since most of the interest is now in the Propeller 2, there will be enough interest to make it worth attempting.
«1

Comments

  • I think the problem here is that Hanno never documented the protocol used since it was also part of his commercial ViewPort.

    And Hanno seems to be awol, sadly. I do not have any copies but I tested it at that time and it was quite simple, almost useless, except for getting the basics done.

    I have a PropScope and use it very rarely, It is nice but quite slow. But a P2propScope might be a interesting product, since it would be faster and could work stand alone without a PC connected...

    Enjoy!

    Mike
  • PublisonPublison Posts: 12,366
    edited 2019-02-02 22:49
    Welcome back. I remember the name. I didn't follow the Propscope venture on Jeff's site, and never saved from there. That's not like me, the data horder. Guess it's lost to the ether. :neutral:
  • There is a project on github that works with the propscope: https://github.com/rbehm-ibb/PropScope
    It needs more work to support all the features and also use more cogs to be able to sample at higher rates, but it's got all the code including PASM to talk to the ADC chip. It also includes an application to run on your PC (with full source) that talks the new protocol this project uses instead of Hanno's old one.

    That would be the place to start if you were to revive things. I would certainly like you to! I have 2 PropScopes, and Hanno's software is lacking in many ways, but the hardware is plenty fast and functional for a lot of use cases.
  • jmgjmg Posts: 15,140
    blittled2 wrote: »
    ...
    I also wonder with the PropScope being discontinued a long while ago and since most of the interest is now in the Propeller 2, there will be enough interest to make it worth attempting.

    The links and GUI can be (largely) common to P2 and PropScope, so it is probably quite a good time to revive something that can support either hardware.

    I have been doing some tests on FT232H, to see what bandwidths it can support in the various modes, with a view to faster data paths from P2.

    In Async FIFO mode, PC-> FT232H, I get peak rates of ~15MB/s, sustained averages of ~10MB/s, and if you stipulate 'no gaps' in the data stream, that is ~ 3MB/s
    I'd expect rates in the other direction to be largely similar.

    Sync FIFO can go faster still, but I'm not sure P2 can manage that.

    Even Async mode will need to consume a COG for the link, as the P2 Streamer lacks handshake abilities.
    I also tested Fast Serial modes, PC -> FT232H, and derived these rate equations
      Summary of FT232H Fast Serial PC bulk "U" sending tests : (use CLK out of FT232H to feed FSCLK )
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      FT232H fast Serial Speed equations model as                Calc             CTR             Deviations                                                               BYTES/Sec
      30MHz_30MBaud   => (30.00054M*5/14)*(256*14)/(255*14+15)  = 10711489     1-ans/10.71147M  = -1.855ppm 1-ans/10.71149M = 11.72ppb, ie mostly /14, appx 1:256 is /15   2.14229797 MB/s
      15MHz_15MBaud   => (15.000271M*5/13)*(512*13)/(511*13+14) = 5768468.343  1-ans/5.768466M  = 0.406ppm Mostly /13, appx 1:512 /14                                      1.153693 MB/s
      7.5MHz_7.5MBaud => (7.500135M*5/13)                       =  2884667.307    2.884667M     = looks like 7.5MHz can stream at /13, gapless.                             576.933 kB/s
    

    You can see the char frame time creeps a little with FSCLK MHz, 7.5MHz can manage always 13 Clocks, 15MHz is mostly 13, rarely 14, and 30MHz is mostly 14, rarely 15.
    This needs fewer pins than 245-FIFO mode, but can go quite a bit faster than ASYNC 12MBd limit.
  • If a P2 PropScope were made, I would very much like it to have extra RAM on board or at least the option to install extra RAM. For those very highest sample rates of the signal you can't feed the data out fast enough over serial link, so we'd want some local parallel RAM to dump to, then transfer from that back to the PC after the capture.

    For the existing PropScope it is limited to what it is already, and it can really only do the higher sample rates for a very short sample time that fits in the P1 internal memory. I think it can only reliable send 2Mbps over the serial, so you only get 200k bytes per second. which is only 160k 10 bit samples per second. The hardware setup is capable of 5Msps if using multiple cogs to read the ADC chip, but in that case you only get a very tiny fraction of a second worth of samples before it's filled available memory. It's still useful for capturing short bits of triggered stuff.
  • Yes @"Roy Eltham",

    exactly my thoughts. the serial link to the PC is way to slow, especially if you capture more then 1 channel. But with 64 pins some fast external ram might be possible and still have serial,sd and maybe VGA and PS2 Mouse or Keyboard, maybe even HDMI, USB mouse/Keyboard. Or even both to connect it to older lab equipment.

    the short sampling time made the propscope quite - hmm - restricted when I needed it.

    Enjoy!
  • jmgjmg Posts: 15,140
    Roy Eltham wrote: »
    If a P2 PropScope were made, I would very much like it to have extra RAM on board or at least the option to install extra RAM. For those very highest sample rates of the signal you can't feed the data out fast enough over serial link, so we'd want some local parallel RAM to dump to, then transfer from that back to the PC after the capture.

    Yes, the SO-8 PSRAMs are quite cheap, LY68L6400SLIT is 59c/100 for 64Mb, so you might choose 2 or 3 of those, depending on the ADC chosen. That does ease serial link pressures.
    Chip has some sort of scope mode worked into the next P2 rev, which may allow for many channels of moderate sample rates, or a Selected premium ADC could give more sps, on fewer channels.

  • well with chips scope streamer mode one can fill up the HUB pretty quick, maybe two COGs to save that out fast enough to two external memories.

    interesting

    Mike
  • With something like this: https://www.ftdichip.com/Products/ICs/FT600.html

    Probably wouldn't need any external RAM, just setup a stream of samples going out to that chip in parallel (16bit or 32bit wide fifo). Most basic setup would be a P2, a FT600, and whatever is needed to attach probes properly.
    Of course a more advanced model could include external high end ADC(s), but that's just going to make it cost a lot more.
  • jmgjmg Posts: 15,140
    Roy Eltham wrote: »
    With something like this: https://www.ftdichip.com/Products/ICs/FT600.html

    Probably wouldn't need any external RAM, just setup a stream of samples going out to that chip in parallel (16bit or 32bit wide fifo). Most basic setup would be a P2, a FT600, and whatever is needed to attach probes properly.
    Of course a more advanced model could include external high end ADC(s), but that's just going to make it cost a lot more.

    Yes, the FT6xx series are appealing, but the lack of streamer handshakes may bite here, as those parts really need the TXE_N to be responded to in 1 CLK (66MHz or 100MHz)
  • Roy Eltham wrote: »
    There is a project on github that works with the propscope: https://github.com/rbehm-ibb/PropScope
    It needs more work to support all the features and also use more cogs to be able to sample at higher rates, but it's got all the code including PASM to talk to the ADC chip. It also includes an application to run on your PC (with full source) that talks the new protocol this project uses instead of Hanno's old one.

    That would be the place to start if you were to revive things. I would certainly like you to! I have 2 PropScopes, and Hanno's software is lacking in many ways, but the hardware is plenty fast and functional for a lot of use cases.

    The new software is from me. Currently it only uses one COG to sample data and thus is limited to about 1Msamples/s. I have not yet found the time to extend it. I am using it heavily as it mostly fits my needs. If someone is willing to work on it I can support. he PC software is based on Qt and QCustomPlot to create the waveform display. I am using a new protocol to transfer the data to the PC. This could be extended for higher speed.
    The extension for higher sample rates (using several COGs) are currently something I have no time to implement (and no idea how to do it). Here help would be appreciated.

    Reinhardt
  • yisiguroyisiguro Posts: 52
    edited 2019-03-10 02:06
    Hello,

    Being inspired from PropScope, I am plannnig to make a simple, handy logic analyser based on P8X32A,
    and trying finding method for very fast data acquisition.
    Now I found some ideas:

    - For full system clock rate acquisition ( 100Msps@6.25MHzXTAL ), use 5 cogs runnnig in differed phase, each cog acquire about 200 longword on cogram, and they construct 1000 longword ring buffer ( 10us ). It is required P31 is used for trigger.

    - For half ( or quarter ) system clock rate acquisition ( 50Msps, 25Msps, resp. ), use all 8 ( or 4 ) cogs, directly store into hubram.

    To use P31 as a trigger, you should use P31 in open-drain mannar.
    For example, to realize 100Msps with trigger,
      IF_C MOVE d000, INA WC 'c-flag reflects P31
      IF_C MOVE d001, INA WC
      '...
      IF_C MOVE d198, INA WC
      IF_C MOVE d199, INA WC
      'followed by code for preparing next phase, or, if_nc, for saving acquired data into hub ram
    

    To store data into hubram directly with full hub clock rate,
    use cog counter for generating hubram address, like this:
      MOV FRQx, #0 'stop counter
      MOVI CTRx, %11111_000 'free running counter 
      MOV PHSx, start_address
      SUB PHSx, #3 'compensate target address
      WAITCNT time, #0 NR 'for starting acquisition at appropriate phase
      ' or insert some hub op to synchronize to hub clock
      MOV FRQx, #1 'start counter. note: 1 for 25Msps, 2 for 50Msps
    :loop
      MOV data, INA
      WRLONG data, PHSx 'note: lower 2 bit are ignored
      DJNZ length, #:loop
    ' just 16 system clock cycles
    
    ( these are not tested, sorry )

    To constructing ring buffer, conditional jumps are not usable, so must use something like
      IF_x MOVS :there, #:elesewhere
      'some other instructions here
    :there
      JMP #:somewhere
    

    By the way, Propeller manual datasheet says source operand is fetched at stage-2, and then destination at stage-3 ( section 4.8, page 9 ).
    But through my experiments, it seems these are reversed, i.e. destination operand is fetched at stage-2, and then source at stage-3.

    Excuse me for my english skill. Thanks.
  • jmgjmg Posts: 15,140
    yisiguro wrote: »
    By the way, Propeller manual says source operand is fetched at stage-2, and then destination at stage-3.
    But through my experiments, it seems these are reversed, i.e. destination operand is fetched at stage-2, and then source at stage-3.
    That may come down to terminology/English ?
    A destination is where the answer goes, whilst a source supplies an operand. You cannot hope to place an answer, before you have the operand :)
    ie I would say read/fetch is stage 2 and write/put is in stage 3.


    yisiguro wrote: »
    Being inspired from PropScope, I am plannnig to make a simple, handy logic analyser based on P8X32A,
    and trying finding method for very fast data acquisition.

    Interesting work. Did you look at the new ISSI Serial SRAMs ?
    1M	IS62WVS1288GBLL	x1, x2, x4	2.7~3.6V	45MHz	-40 to 125°C	8-SOIC	Prod	 	Serial SRAM
    2M	IS62WVS2568GBLL	x1, x2, x4	2.7~3.6V	45MHz	-40 to 125°C	8-SOIC	Prod	 	Serial SRAM
    4M	IS62WVS5128GBLL	x1, x2, x4	2.7~3.6V	45MHz	-40 to 125°C	8-SOIC	Prod	 	Serial SRAM
    
    For a longer-storage scope, those could be address-written in armed state, and then start recording on trigger.

    Another approach fro logic analyser is to store change+timestamps.
    That gives a natural compression, and has very good dynamic range, but very top-end edge rate is lower, as you need to store Pinstate+time.
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-03-09 05:23
    yisiguro wrote: »
    Hello,

    Being inspired from PropScope, I am plannnig to make a simple, handy logic analyser based on P8X32A,
    and trying finding method for very fast data acquisition.
    Now I found some ideas:

    - For full system clock rate acquisition ( 100Msps@6.25MHzXTAL ), use 5 cogs runnnig in differed phase, each cog acquire about 200 longword on cogram, and they construct 1000 longword ring buffer ( 10us ). It is required P31 is used for trigger.

    - For half ( or quarter ) system clock rate acquisition ( 50Msps, 25Msps, resp. ), use all 8 ( or 4 ) cogs, directly store into hubram.

    To use P31 as a trigger, you should use P31 in open-drain mannar.
    For example, to realize 100Msps with trigger,
      IF_C MOVE d000, INA WC 'c-flag reflects P31
      IF_C MOVE d001, INA WC
      '...
      IF_C MOVE d198, INA WC
      IF_C MOVE d199, INA WC
      'followed by code for preparing next phase, or, if_nc, for saving acquired data into hub ram
    

    To store data into hubram directly with full hub clock rate,
    use cog counter for generating hubram address, like this:
      MOV FRQx, #0 'stop counter
      MOVI CTRx, %11111_000 'free running counter 
      MOV PHSx, start_address
      SUB PHSx, #3 'compensate target address
      WAITCNT time, #0 NR 'for starting acquisition at appropriate phase
      ' or insert some hub op to synchronize to hub clock
      MOV FRQx, #1 'start counter. note: 1 for 25Msps, 2 for 50Msps
    :loop
      MOV data, INA
      WRLONG data, PHSx 'note: lower 2 bit are ignored
      DJNZ length, #:loop
    ' just 16 system clock cycles
    
    ( these are not tested, sorry )

    To constructing ring buffer, conditional jumps are not usable, so must use something like
      IF_x MOVS :there, #:elesewhere
    :there
      JMP #:somewhere
    

    By the way, Propeller manual says source operand is fetched at stage-2, and then destination at stage-3.
    But through my experiments, it seems these are reversed, i.e. destination operand is fetched at stage-2, and then source at stage-3.

    Excuse me for my english skill. Thanks.

    I did a data logger years ago that exploited 4 cogs to interleave samples.After doing so, I discovered that someone else had also done a similar thing. Just search the forum as it's been done before and code there is probably usable.

    The instruction fetch mechanism has also been discussed. The 6 clock cycles are IIRC
    IdSDeR
        IdSDeR
            IdSDeR
    
    d=instruction decode but I think another letter is used. e=execute. Both of these have no memory access and so are used by the previous and next instruction.
    I=instruction fetch, R=is the result write-back.
  • yisiguroyisiguro Posts: 52
    edited 2019-03-09 15:08
    Thank you guys for your suggestions.
    The instruction fetch mechanism has also been discussed.
    Finally I found it a document about execution timing,
    and a site about PPLA ( Propeller Platform Logic Analyzer ) products w/ downloadable files ( support GUI app "Propalyzer" and firmware ), hosted by wulfden.
    https://forums.parallax.com/discussion/download/123637/machinelanguage.pdf

    See "Sidetrack F: How the instruction pipeline works" (page 23),
    A “standard” instruction takes 6 ticks:
    T=0: Fetch Instruction
    T=1: Decode instruction
    T=2: Fetch „dest“ operand
    T=3: Fetch „source“ operand
    T=4: Perform operation
    T=5: Store result back into “dest”
  • Cluso99Cluso99 Posts: 18,066
    I am fairly sure that manual is incorrect. There were lots of discussions years ago.

    IdSDeR is the sequence that I recall. However, whether S or D is fetched first makes no difference.

    Now, since you are talking about I/O, again IIRC, when you are doing an INA instruction the pin is gated late and directly feeds into the e clock.

    All this can be found by looking at the P1V verilog code published by Parallax.
  • yisiguroyisiguro Posts: 52
    edited 2019-03-17 14:10
    Yes, I know I need a little more things to learn.
    Now, since you are talking about I/O, again IIRC, when you are doing an INA instruction the pin is gated late and directly feeds into the e clock.

    All this can be found by looking at the P1V verilog code published by Parallax.

    I am not good at HDL, but at last I saw what you mean.
    I read Verilog code "cog.v" carefully, and I realize that, fetching read-only pseudo registers such as CNT, PHSx and INA, are delayed for 1 system clock, i.e. in such case, source and destination are simultaneously fetched. That makes sense for me very well.

    Thanks all.
  • Clock LoopClock Loop Posts: 2,069
    edited 2019-03-12 00:48
    If the firmware/software side of this is worked on im sure many of us here can make and provide gerber/pcbartist files for the schematic.

    I am getting into messing with the QT developer side of things also....
    I made a forum thread dedicated to doing raspberrypi/linux compiles of parallax tools and QT on debain.
    --> https://forums.parallax.com/discussion/comment/1455388/#Comment_1455388

    I also have started a propscope pcb replica design, in pcb artist (4pcb.com), which I can finish, make a 4 pcb order on, and then get the gerbers for.

    So I can help with the pcb side of it, and perhaps the QT part.. (not much, yet)

    This would definitely pave a way to then start a P2 scope....
  • I still use the propscope. I take it with me on my weekend job. It would be nice if you guys could clean up the software and maybe add more features. It is good for what it is.
    Not the greatest but sufficiently portable for me. I would be willing to test code anytime as an outsider and try to break it for bugs.
    Martin.
  • Crazy idea! If you design a new propscope how about daisy chaining two to get more use out of it. And maybe in the future the P2. I have a p2 eval board so much power.

  • @"Roy Eltham"
    will this https://github.com/rbehm-ibb/PropScope
    run in windows
    https://github.com/rbehm-ibb/PropScope
    I would like to know prior to downloading.to check it out.

    Thanks

    Martin

    also any others that might work.
    Thanks
  • pilot0315 wrote: »
    @"Roy Eltham"
    will this https://github.com/rbehm-ibb/PropScope
    run in windows
    https://github.com/rbehm-ibb/PropScope
    I would like to know prior to downloading.to check it out.

    Thanks

    Martin

    also any others that might work.
    Thanks

    I have not tested this on Windows, but I expect it to work there too. The code contains nothing OS specific. The OS secifics will be handled by Qt.

    Reinhardt
  • rbehm wrote: »
    pilot0315 wrote: »
    @"Roy Eltham"
    will this https://github.com/rbehm-ibb/PropScope
    run in windows
    https://github.com/rbehm-ibb/PropScope
    I would like to know prior to downloading.to check it out.

    Thanks

    Martin

    also any others that might work.
    Thanks

    I have not tested this on Windows, but I expect it to work there too. The code contains nothing OS specific. The OS secifics will be handled by Qt.

    Reinhardt

    I'm getting errors when I "View Info". "timer.spin" throws errors in the CON section.
  • Roy ElthamRoy Eltham Posts: 2,996
    edited 2019-03-17 20:23
    Can you stop quote replying with my name @'d in there? I keep getting notifications and such.
    I wish they would turn off that feature fix this bug of the forums, it's so abuse-able and annoying.

    Edit: to be clear, what I mean is that I don't want to be notified when someone quotes a message that I have been mentioned in. I do want to be notified when someone mentions me in a message.
    In the above case, I was notified the both rbehm and Publison mentioned me in this thread. Neither of them actually did, they just quoted pilot0315's message in their replies and the system doesn't handle that properly. In my opinion, it's a bug that needs to be fixed.
  • Publison wrote: »
    rbehm wrote: »

    I have not tested this on Windows, but I expect it to work there too. The code contains nothing OS specific. The OS secifics will be handled by Qt.

    Reinhardt

    I'm getting errors when I "View Info". "timer.spin" throws errors in the CON section.

    I have compiled it with bstc without any complains from the compiler.
    What errors do you see?
  • yisiguroyisiguro Posts: 52
    edited 2019-03-21 12:13
    Maybe PropellerTool does not accept enumeration split into lines like this:
    CON
        'timer idx to be used outside
        #0, 
        IPC_TX,     'timer for ipccomm tx response timeout
        IPC_RX,     'timer for ipccomm rx char timeout
        PING,
        NTIMER      'always have this as last
    

    To pass here, commas following after identifiers are to be deleted:
    CON
        'timer idx to be used outside
        #0 
        IPC_TX     'timer for ipccomm tx response timeout
        IPC_RX     'timer for ipccomm rx char timeout
        PING
        NTIMER      'always have this as last
    


    In Timer.spin, identifier "time" has global scope, PropellerTool does not accept it as a parameter name:
    PUB setPeriod(n, time)
        if (n => 0 and n < NTIMER)
            period[n] := time
    

    So, some other name to be used:
    PUB setPeriod(n, p_time)
        if (n => 0 and n < NTIMER)
            period[n] := p_time
    
  • yisiguro wrote: »
    Maybe PropellerTool do not accept enumeration splitted into lines like this:
    CON
        'timer idx to be used outside
        #0, 
        IPC_TX,     'timer for ipccomm tx response timeout
        IPC_RX,     'timer for ipccomm rx char timeout
        PING,
        NTIMER      'always have this as last
    

    To pass here, commas following aftre identifiers are to be deleted:
    CON
        'timer idx to be used outside
        #0 
        IPC_TX     'timer for ipccomm tx response timeout
        IPC_RX     'timer for ipccomm rx char timeout
        PING
        NTIMER      'always have this as last
    


    In Timer.spin, identifier "time" has global scope but PropellerTool do not accept it as a parameter:
    PUB setPeriod(n, time)
        if (n => 0 and n < NTIMER)
            period[n] := time
    

    So, other name to be used some thing like this:
    PUB setPeriod(n, p_time)
        if (n => 0 and n < NTIMER)
            period[n] := p_time
    

    Ok, I only use BST. I don't know about these problems with the PropellerTool. But it seem to be right about the commas in the enumeration. The Prop Manual does it the same way and BSTC alos accepts this.
    The problem with parameters having the name of a global variable has bitten me this week too. Funny that BSTC had no problem here. When I have time I will fix this on github.

  • @"Roy Eltham"
    Agree with you. It should be more specific to the quoter. But I think parallax will not fix. I will ask them.

    All good.
  • rbehm,
    BSTC isn't as strict about things as the official PropTool compiler. It also has features that don't work on PropTool.
    Technically the problems are with BSTC and your code using unofficial things (like the comma's in the enum, or using a local variable with the same name as a global). These are not problems with PropTool.

    The local vs global variable one is something that I would consider a bug in BSTC, because it makes the code confusing to read. Plus, how are you supposed to access the global variable from the function that has a local of the same name?
    Of course, I'm sure BSTC regards it as a feature, but it's a bad one.
  • rbehm wrote: »
    Publison wrote: »
    rbehm wrote: »

    I have not tested this on Windows, but I expect it to work there too. The code contains nothing OS specific. The OS secifics will be handled by Qt.

    Reinhardt

    I'm getting errors when I "View Info". "timer.spin" throws errors in the CON section.

    I have compiled it with bstc without any complains from the compiler.
    What errors do you see?
    Sorry, late to reply. Issues have been addressed above. I was using Propeller Tool and not BSTC.

    640 x 343 - 116K
Sign In or Register to comment.