Viewport v1.2: Free 80Mhz Scope- inside your own program!
Hanno
Posts: 1,130
Viewport v1.2, the tool that let’s you into the Propeller, is ready for free download at: mydancebot.com
Viewport uses a 2Mbaud connection between a graphical Windows-based application and a cog running alongside your program to let you monitor and change variables in your running spin program.
New features include:
Requirements:
A big thanks to our beta testers: Ingolf, George, and especially Harley. Here’s what Harley has to say about Viewport:
"Before Viewport, I had trouble programming and debugging the Propellers for a Z80 emulator design- it was difficult for me to see what was happening inside- there is only so much a blinking LED can tell you. Now, I can see AND edit variables in my program and also watch what's happening on the 32 IO lines at high speed with NO wires!"
Enjoy!
Hanno
[url=http://myDancebot.com: Home of the affordable balancing robot]myDancebot.com: Home of the affordable balancing robot[/url]
Post Edited (Hanno) : 9/4/2007 8:13:41 PM GMT
Viewport uses a 2Mbaud connection between a graphical Windows-based application and a cog running alongside your program to let you monitor and change variables in your running spin program.
New features include:
- A QuickSample object that lets you view all 32 I/O bits at up to 80Mhz- while your program is running. A one-line change to your existing program let’s you see a graph of what’s happening to each bit- with triggers, timescales from 50ns/div to 5s/div and memory limited only by our pc.
- Applets are pre-built Propeller programs that display data within Viewport and take input from Windows controls like scrollbars, textboxes and checkboxes. Viewport shows you available applets (with description and link to the spin file) and then lets you load to the propeller ram/eeprom. We’ve includes applets to let you interact with LEDs, motors, ping and compass sensors.
- Check out the website for a video tutorial, help documentation, application notes, and more.
Requirements:
- Parallax Propeller driven by a 5mhz crystal
- A Parallax PropPlug to provide a 2Mbps USB connection between PC and Propeller
- 500Mhz PC with 100MB RAM running Windows XP natively
- 1MB hard drive space
- .NET Framework
A big thanks to our beta testers: Ingolf, George, and especially Harley. Here’s what Harley has to say about Viewport:
"Before Viewport, I had trouble programming and debugging the Propellers for a Z80 emulator design- it was difficult for me to see what was happening inside- there is only so much a blinking LED can tell you. Now, I can see AND edit variables in my program and also watch what's happening on the 32 IO lines at high speed with NO wires!"
Enjoy!
Hanno
[url=http://myDancebot.com: Home of the affordable balancing robot]myDancebot.com: Home of the affordable balancing robot[/url]
Post Edited (Hanno) : 9/4/2007 8:13:41 PM GMT
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I'm new to the propeller!
And for allowing me to help you while learning about how useful ViewPort can be.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Any chance of releasing the source? It'd be nice to tinker with the interface a little.
" The Propeller"
Need I say more ?
Rob7
Graham
kompliment, dein ViewPort sieht sehr gut aus.
Ein tolles Propeller Tool.
Super Video Tutorial.
viele Gr
This is smoking hot software, a logic analyser built into the code.
Well done Hanno.
This is going to make prop stuff even more fun and much easier to debug.
Paul, Chip, this is so good can you please add it to a future version of the tool?
Gavin
This is one great tool. Even at this relatively early release time.
It is working for my needs in LSA mode quite well. Much better than hooking up scope probes, or many logic analyzer probes, to be able to view what's happening just on the I/O pins.
And for the 20 MHz capture rate it only uses two cogs.
It also allows one to view the values of variables INSIDE the chip!!!
Here's one/another satisfied 'customer'.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Hanno
Any word on when the DanceBot kits will be released?
Any chance of seeing Viewport work remotely?
Amazing stuff!!!
Rich
Paul
rjo- For the next release- v1.4, we're working on a "wireless" mode. This would allow you to disconnect the USB plug, take measurements with the Propeller, and then reconnect the USB connection to download the data. The Propeller uses very little power when idle, so this would allow you to run the Propeller from a 9V battery and take measurements over multiple days... We intend to measure temperature, color, and possibly ph of our beer while it's fermenting. The possibilities are endless!
The dancebot is coming along- we're striving for very high design goals while making it affordable enough to use for all sorts of hobby applications. No firm dates yet- but if you're interested in helping beta-test a bot please let us know!
At 80 MSPS, the propagation delay between cogs causes a slight distortion in the sample rate, but probably not enough to worry too much about.
Any chance you could make this work with Windows Vista x64?· I had it working a little, but it crashes when trying to change settings...
For 20 MSPS, could the LSA and Conduit be combined so as to only use one cog?· (I think you need 2 now, right?)
Ray
Glad you like it!
Are you able to characterize the distortion? The cogs run interleaved- first cog 1, 2 ,3 then 4- just like a four cylinder engine. The cogs take measurements when the clock pulse reaches them- if the clock pulse reaches some cogs faster than others, then those cogs would take measurements slightly earlier than they should.
Anybody from Parallax- any way of minimizing this distortion by choosing specific cogs?
Theoretically it might be possible to combine the 20mhz and conduit to run in 1 cog. However, the conduit is doing FULL duplex serial communication at 2mbps- so sending data from the pc to the propeller would be much more involved - you would have to resend an attention byte until acknowledged by the propeller. We're already doing some of this- but this would make an already complex system even more complex.
At the moment we're working on other features that we believe provide more value:
- a wireless mode (letting you disconnect the propplug, take measurements for days, then reconnect to get the data)
- advanced triggers (edge, pattern modes for all channels- frame, analog values, and even virtual channels)
- and taking analog measurements up to 40msps at 8 bit resolution.
Speaking of "providing value"- we don't see any value in Windows Vista and won't migrate our shop. If someone wants to help us by providing debugging information (turn on the "trace log" in edit/preferences, then look for the file: "c:/viewport.log") we'll fix those bugs.
If we are looking at feature requests, a one-shot trigger mode would be handy. I was trying to capture some very fast data trains, but they kept scrolling off the screen and I could find no way to slide the window across to let me see them, even though I saw them scroll past. A one shot trigger mode would allow me to capture a single frame and view it at my leisure.
Of course, if it's there and I've missed it, or there is a way to scroll back the history window (won't here anyway) then I'd love to be pointed in the right direction.
Nice bit of software though.. It'll come in handy.
I've looked at the "QuickSample_12" assembly code, but don't see how it can aquire at 20 MSPS...
The chip is running at 80 MHz, but it takes (at least) 4 clock cycles to execute an instruction. So, it's running at 20 MIPS.
So, to aquire at 20 MSPS, every instruction must be a MOV from INA.
I would think the only way to do this would be to have many MOV instructions in a row. But, I don't see that in your code (unless the code itself is generating these instructions somehow).
Hanno, can you clue me in?
Hanno's program achieves higher aquisition rates by using multiple cogs and interleaving the clock cycle each cog samples the INA bus.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 8/30/2007 9:41:55 PM GMT
hast du schon was von Steve V... aus NZ geh
The manual says there is a 1 to 1.5 ns delay from the first cog to the last for I/O signals. So, with 4 cogs there is ~3/4 of a ns or so offset. This is not a totaly insignificant fraction of 12.5 ns period. Are you saying this 1 to 1.5 ns delay only when used as an output, not input?
As I understand it, Hanno achieves 20 MSPS with 1 cog and uses 4 cogs to get 80 MSPS. But, I don't see how his code can do this...
If each cog waits for the counter to reach a certain value, but each is offset by 1 clock cycle then each will be synchronous to a different clock cycle so data is grabed by the following cog order 1,2,3,4,1,2,3,4,1,...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Thanks for the info on the propagation delay. Looks like Viewport should be able to measure up to 80mhz with no significant artifacts. And yes, QuickSample interleaves the measurements.
I like to give the analogy that it runs like a 4 Cylinder/4 Stroke engine. Each Cylinder fires Once every 4 Strokes. But, if you interleave 4 of them, then you get a "fire" on every stroke!
Rayman
My assembly code dynamically generates the code to take the measurements- that's why you don't see 400 MOV instructions in a row. For the single-cog version, the dynamic code is regenerated for every set of measurements- as the code runs completely in it's own cog and destroys its code as it stores the measurements. To support all the different sampling frequencies, the code actually implements 5 different cases:
*4 Cog Mode:
- at 80Mhz each cog takes 1 sample every 4 clock cycles- for a total of 1600 samples. They're interleaved, so a sample is taken every clock cycle.
- at 40Mhz cogs 1 and 2 run interleaved to take the first 800 samples- so a sample is taken every 2 clock cycles- then cogs 3/4 take the last 800 samples
- at frequencies <=20Mhz, the cogs run interleaved, but don't run dynamically generated code anymore- a simple wait loop is sufficient. Again, this yields 1600 samples.
*1 Cog Mode:
- at 20Mhz, the dynamic code takes 1 measurement every 4 clock cycles- taking 400 samples
- below 5Mhz, a wait loop takes the measurement whenever needed
Franz- No, I haven't heard from Steve...
BradC- Yes, we've had requests for "single-shot" mode- and are working on it now. The "time scrollbar" currently lets you scroll through the non-frame channels. These channels (which represent variables in your program) are updated at 2Mbps- giving you high time resolution- up to 200ksps if monitoring a single byte variable. For example, we take minutes worth of data and can then inspect the data at any timescale- from seconds/div to usec/div for ANY of that data! A PC based scope is very powerful!
For inspiration on what to do with Viewport, take a look at some of the case studies now on the applications page:mydancebot.com/products/viewport/applications.php
Ingolf is taking 8bit ANALOG measurements at up to 40MSamples/Second! Support for analog measurements will be released in the next version!
Post Edited (Hanno) : 8/31/2007 3:57:43 AM GMT
There has been some German text here. Das is fein, kein Problem f
Thanks for clearing that up! I knew that's the only way it could work, but had trouble following the code... The interleaving for 80 MSPS with 4 cogs using the system clock was easy to see. But, I didn't see many MOV instructions. I guess dynamically generating the code is the only way to go to have flexibility in aquisition rate with a small footprint...
I wonder if it would be possible to use multiple cogs, not to increase sample rate, but to multiply the acqusition depth. 400 samples is good, but 800 or 1200 would be better. Some of the first digital scopes had 50 points/ division with 10 horizontal divisions. They typically had 512 points. I think the system clock could also be used to coordinate cogs in this way too, right?
I noticed the way you used two variables to indicate when aquisition was started and stopped to coordinate between the LSA and the conduit. Did you think about using the built-in "locks" instead? It seems that this is what they were made for...
Yes, assembly code which dynamically generates its own code is not easy to follow.
If you're using the 4 cog mode 1600 samples will be taken at whatever sampling rate you desire- look at my previous post again... If you're using 1 cog only 400 samples will be taken. Each cog has 512 LONGS of fast memory available, this is shared between the measurement data (406 long), and the assembly code and variables.
Yes, I thought about using "locks"- however, I'm also using the "synchronization" markers to tell Viewport- running on the PC, that the frame was complete. While complex, the current method assures that variable data is updated at a constant rate and that Viewport only draws complete frames.
Another cool feature of the single cog acquisition mode is the "interruptible 0 latency" trigger. From Viewport you can change the trigger/timescale even while a trigger is waiting for a signal. The 0 latency feature (only for the single cog mode) means you're measurements are accurate to 1 clock cycle- 12.5ns!
I try to install this 80 MHz scope on my laptop and got stuck on some comunication problem.
I'm using USB <-->rs232 dongle from Paralax and have no problem w/ loading spin code to propeller.
However, once I have started Vieport I see this error message:
Looking for a Viewport Object to connect to:
Trying COM5...Opened, but no Viewport Object found
Looking for Propeller:
Trying COM5...Found Propeller v 1 on COM5
Propeller found on COM5 but could not communicate with a Viewport Object.
Please load a Propeller Program that uses a Viewport Object.
You can load Viewport Applets using the Load Button
I have uploaded the following code to ·EPROM
pub run|pin,switch vp.start(31, 30,@pin,String("No Data-just switch the LED on/off with the Switch:1s/div:DSO:pin=16,switch!")) 'starts Viewport- textbox for pin, checkbox for switchand I see it is running because LED is blinking @ 4Hz. Although it always stops blinking for ~1 second after I press 'Connect' button in Viewport. But a secnd later it blinks again.
Any hint what I should check?
Jan
Are you sure your clock is configured correctly? Your program should start with:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
This configures the Propeller to run from an external crystal (you should be using a 5Mhz crystal) and uses the pll multiplier to set a 80Mhz clock. If the timing is wrong, the Propeller won't be able to communicate with the Viewport program.
The Viewport program looks for a running Viewport object on a propeller using 2 passes. In the first pass, it checks for incoming serial data on all available com ports. If it detects a valid signal, it processes the configuration and becomes "connected". If it doesn't, it tries to find a Propeller- by sending the reset signal and a special code to which the propeller replies with a version number.
I believe what's happening is that your program runs fine, but at the wrong clock rate. This causes Viewport to not understand the Propeller, reset it, and then find just the valid Propeller on the correct port. This "reset" causes the 1 second delay in blinking.
I used just your demo, first from the top, and did not touch your clock lines, this is full code.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 _1s=80_000_000 OBJ vp : "ViewportConduit_12" 'transfers data to/from PC pub run|pin,switch vp.start(31, 30,@pin,String("No Data-just switch the LED on/off with the Switch:1s/div:DSO:pin=16,switch!")) 'starts Viewport- textbox for pin, checkbox for switchI'm using propeller stick - would it make·a difference?
I'm really stuck
Jan