Is it worth reviving the PropScope OpenSource Project?

blittled2 · 2019-02-02 21:55

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.

msrobots · 2019-02-02 22:31

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

Publison · 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.

Roy Eltham · 2019-02-02 22:51

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.

jmg · 2019-02-02 23:22

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.

Roy Eltham · 2019-02-03 00:58

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.

msrobots · 2019-02-03 01:33

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!

jmg · 2019-02-03 01:35

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.

msrobots · 2019-02-03 02:15

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

Roy Eltham · 2019-02-03 03:39

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.

jmg · 2019-02-03 04:00

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)

rbehm · 2019-02-10 02:55

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

yisiguro · 2019-03-08 14:19

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.

jmg · 2019-03-08 19:23

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.

Cluso99 · 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.

yisiguro · 2019-03-09 12: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”

Cluso99 · 2019-03-09 13:53

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.

yisiguro · 2019-03-10 03:12

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 Loop · 2019-03-12 00:47

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....

pilot0315 · 2019-03-17 02:55

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.

pilot0315 · 2019-03-17 02:57

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.

pilot0315 · 2019-03-17 03:07

@"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

rbehm · 2019-03-17 13:16

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

Publison · 2019-03-17 14:15

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 Eltham · 2019-03-17 18:19

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.

rbehm · 2019-03-18 02:01

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?

yisiguro · 2019-03-21 03:31

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

rbehm · 2019-03-21 04:54

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.

pilot0315 · 2019-03-21 05:23

@"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.

Roy Eltham · 2019-03-21 09:51

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.

Publison · 2019-03-21 14:44

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.

Is it worth reviving the PropScope OpenSource Project?

Comments