SpinScope: A Virtual Oscilloscope for the Propeller
Phil Pilgrim (PhiPi)
Posts: 23,514
Attached is an installation zip and documentation for a project that's a work in progress but which has reached a usable node. SpinScope is a virtual oscilloscope for the Propeller that monitors selected Propeller pins and displays their states on a two-channel (with separate trigger channel) oscilloscope in a web browser window:
Future plans include:
Anyway, SpinScope is very easy to use, requiring virtually no additional programming. Here's a quick sample program that was used to create the above image (SpinScope stuff in red):
Enjoy!
-Phil
Addendum: Original download replaced with version 1.1.
Future plans include:
1. Add an "analog" scope capability that samples DUTY mode output on a pin over an interval.
2. Add a terminal screen so that regular terminal I/O can occur concurrently with the scope display.
3. Add a graphical I/O instrument that includes switches, lights, sliders, joysticks, etc. At this point the project will be renamed "SpinLab."
2. Add a terminal screen so that regular terminal I/O can occur concurrently with the scope display.
3. Add a graphical I/O instrument that includes switches, lights, sliders, joysticks, etc. At this point the project will be renamed "SpinLab."
Anyway, SpinScope is very easy to use, requiring virtually no additional programming. Here's a quick sample program that was used to create the above image (SpinScope stuff in red):
CON _CLKMODE = XTAL1 + PLL16X _XINFREQ = 5_000_000 OBJ [color=red]sco : "SpinScope"[/color] 'This line and the sco.start line are all that are required to use SpinScope. PUB start | i [color=red]sco.start[/color] dira[7..0]~~ i~ repeat outa[7..0] := i++
Enjoy!
-Phil
Addendum: Original download replaced with version 1.1.
Comments
That looks really nice.
Have you an unpackaged version of it? exe files are no use around here.
Ooh, sorry. The server program itself is an exe that uses Windows API calls. So an unpackaged version would not help you. That said, however, the server is written in Perl, and I will ultimately release the Perl source code for those who might wish to deploy it on Linux or OS/X.
-Phil
Sounds like an excellent plan. You could just stick it into a github repo.
In the mean time any chance of a zip file of just the bits that get served up to the browser?
Attached is a zip with the HTML generated by the server.
-Phil
Well, not really. It's just that I could not resist making a little Node.js web server to serve up spinscope.html and feed it some trace points.
Tried another simple program to test, (attached)
EDIT: Windows 7
2. Be sure not to have any serial comms objects running that can interfere with comms on P30/31.
3. Make sure you have three additional cogs available for SpinScope.spin to run in.
-Phil
Here's the trace I get from your program on Win7+Firefox:
-Phil
I'm drooling over that image. I really need to take that next step while I've still got my mind wrapped around the JavaScript. The refresh rate will be slower by 8X, however, since the data has to be sent from the Prop as bytes rather than bits. But perhaps I can get by with less horizontal resolution.
-Phil
2. In its current form, SpinScope allows connections from outside the local machine. I should probably not allow that, even though it's kinda cool watching my shop Prop from inside the house.
3. Having more than one user connected at at time can lead to a battle for control, since both have access to SpinScope's settings. SpinScope is strictly a one-user program since it interfaces to a single Prop.
-Phil
Got it working. Here's what I did.
Start SpinScope.exe
Start FireFox localhost:1234
Power On, then Power Off
Stop SpinScope.exe, the restart SpinScope.exe
Now it works every time.
Works in Chrome also.
Pretty snazzy! Thanks for that!
Jim
It did complain about firewall restrictions, but I selected internal/private networks were OK.
Hope Jon gets it working.
A couple questions about the start-up code in the object:
You declare cogno as a byte, yet check for less than 0 -- this should never work, correct? If cognew returns -1, cogno will be truncated to 255.
If cognew for xcrv fails, should you not add a cogstop for cogno before returning false?
-Phil
It's just spinscope beings served up a noisy signal. None of the setting controls are active.
Not from a Propeller though because, well i'm not sure I should admit this but I can't for the life of me find a single Propeller in the house today...
Jim
One thing that stinks about the propscope is that there is no logging. Will this have the ability to record digital signals as a bit of a data analyzer? It'd be great to be able to record some binary signals and later translate them to hex with this.
Only asked because the only way I can view from outside my local network today is via my old Samsung Galaxy S phone where it does not work. Nice to see my setup of multiple layers or routers and nginx proxying is working!
Seems to be SpinScope should be added to the Editor17 Propeller WEB IDE. Then you could program a Prop and see it's operation all in one web app. Of course Editor17 needs a lot of beautifying first.
Yes, I was thinking it would be cool to be able to decode UART, I2C, SPI signalling. Like you can on real scopes now a days.
I have no idea what goes on in Phil's server but an issue at the moment it that is that traces are fetched by the browser as and when it has time to. That means batches of samples can be missed.
I guess that decoding could happen on the server though.
Surely I won't have time to do anything with this idea.
Parallax just ran out of an inexpensive Logic Analyzer from Saleae, that does all that for $149.00 US. Unfortunately, Saleae discontinued that product and came out with a new one that has some analog capabilities at $199.00US. Still not a bad price
Today though the latest Rigol 4 channel scopes can be had for about twice as much money. Decisions, decisions.
Of course what Phil wants to achieve here is a zero cost analyser for us in classes. What better way that have a prop analyse itself?
I guess my next experiment should be to push the trace data via a web socket connection rather than AJAX requests. In theory we should get a much faster update rate.