SpinScope for P2 in browser?
Rayman
Posts: 14,640
in Propeller 2
Phil's SpinScope for P1 is pretty neat:
https://forums.parallax.com/discussion/157982/
I think that when he wrote that one could not access serial ports with web browser, but now you can.
Seems it should be possible now to do something like SpinScope in a browser.
Anybody done something like this already?
I see the PropTool debug window can also plot data, but don't think it can look like a scope and have the usual scope controls, or can it?
Comments
I'd prefer something that worked as a sigrok interface. It'd be a lot more powerful and a lot less work to implement.
Sigrok does look like something worth doing. Didn't somebody already talk about doing this?
I searched up a Pico code that looks easy to port:
https://github.com/pico-coder/sigrok-pico
The upshot of Sigrok is the library of protocol analyzers.
Didn't see an easy way to use Sigrok to do what I want... Would have to dig deep into some source code of other devices to figure out the syntax and don't really want to do that. Also, I got a ~$10 gizmo off Amazon that works with Sigrok, giving a perhaps easier way to look at P2 pin outputs without using the P2 serial port.
Did finally figure out how to get the Web Serial API working to talk to P2 over serial interface in a browser.
The main trick that was learned the hard way is that connecting reboots the P2.
So, the P2 code needs to be written to flash before trying.
There is P2 code for testing and link to a browser based serial terminal example here:
https://www.rayslogic.com/Propeller2/WebScope/WebSerialTest.htm
Sounds like good progress
I wonder whether DTR inversion bit is in the correct state? (I vaguely remember something in FTPROG)
Or perhaps it toggles DTR more than once
I've been sitting on a very rough implementation of the SUMP protocol-based logic analyzer that is supported by Sigrok and other LA software. The core issue I haven't push hard to release is I find Sigtok to be very unstable for Windows when using serial ports (not tested with Linux). However, I also have been using other SUMP-compatible clients like the OpenBench LogicSniffer Java Client with pretty good success, just the implementation on my side and theirs is both buggy which makes configuration error prone. Though it's been nice for the P2 to be its own logic analyzer when troubleshooting code. I'll probably finesse the code a bit over the next few days (just got back into town) and get a thread going regarding it.
If anyone is planning to implement a browser based scope please consider this: No matter how high your data transfer rate is the resulting update rate and response time will always be slower than a real time solution rendering directly to a screen. And even most digital scopes are much slower than a real analogue scope deflecting the beam of a cathode ray tube directly.
You may be thinking the eye can't see more than 30fps anyway but it makes a huge difference. For example if your timebase is 1µs/cm your full screen has a range of 10µs. If you only display 30fps with a single trigger event each this means that that you are blind for the rest of 1s - 30*10µs = 999.7ms, or in other words 99.97% of the available information is discarded.
I still like my old HP digital scope from the 90s. It has no limited buffer memory for the samples before and after the trigger. Instead it records all the samples all the time until the next frame is displayed on the screen. It just shifts them along the time axis based on the trigger events. So every sample generates a pixel. And if a square wave has jitter you don't see the edges before and after the trigger edge jumping forth and back from time to time but instead a nice noisy pixel cloud around this edges. And you can tell from the shape and density of the pixel fog if it's random noise or has some repeating pattern.
You can also count the number of times per frame a pixel is overwritten with a new sample. The more samples the brighter the pixel is displayed. This is called "digital phosphor".