Hanno said...
Hi Clock Loop,
Since the Propeller has 8 cogs, it's easy to simplify your program so it runs entirely on one chip- this will make it easier for other people to replicate what you're seeing- it's really quite interesting!
Of course looking at the 5MHz signal on pin 19 is pure garbage at this slow rate...
I ran your program on my "DemoBoard" no problem see screenshots at proper time settings of 200ns for the 5MHz signal and 100us for the 10us pulses every 500us.
Clear as mud?
I though I was onto squashing a bug, but it sounds like your telling me that the prop samples data at the rate you set on the DIV dial.
I know about sample rates(Nyquist) and the like, my question is does the prop sample the data at the rate you set on the DIV dial?
Or does the prop sample all its pins at its highest rate, and then send the data to be downscaled on the PC?
So If I set my quicksample object to 4 cogs and 1600 samples,
is it sampling at the rate set by those four cogs or does viewport tell the prop at what rate to sample?
Perhaps this is nothing more than a lack of understanding on how the prop samples data in the quick sample object when using 4 cogs and 1600 samples.
I tried to look at the quicksample object but the pasm code is not commented so I have no idea whats going on, my pasm reading isn't good.
P.S. I am now a DEV owner. [noparse]:)[/noparse]
Playing catch up now.
Post Edited (Clock Loop) : 2/18/2010 4:46:29 AM GMT
Hi Clock Loop,
Thanks for the purchase!
Yes, the sampling rate changes as the timescale is changed. When using 1 cog, the maximum sampling rate is 20Msps. With 4 you can sample at up to 80Msps- all with the standard 80MHz clockrate. The sampling rate is determined by the timescale and the size of your screen- each sample will be represented by 1 pixel. If you over-clock your Propeller you can go even faster- ViewPort will automatically adjust the timing information based on the clock constants.
Looks like this is resolved- in summary, make sure to measure signals at the proper rate! I typically start at a much faster rate and then decrease until the signal is sized for my needs.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Hanno said...
Hi Clock Loop,
Thanks for the purchase!
Yes, the sampling rate changes as the timescale is changed. When using 1 cog, the maximum sampling rate is 20Msps. With 4 you can sample at up to 80Msps- all with the standard 80MHz clockrate. The sampling rate is determined by the timescale and the size of your screen- each sample will be represented by 1 pixel.
Hanno
So if one were to sample at a high rate 80Msps on the prop like the quicksample object, one would fill up data space very fast, faster than the 2mbps connection that we have available?
So the answer is to sample for a shorter amount of time and then stop sampling to let the data finish getting sent over the usb connection? Thats why a continuous sample lasting 100ms at a rate of 200ns cannot be done?
So when I am in 1ms DIV mode, and the prop is only taking a sample every .5ms what is it doing with all that extra time?
So then its really just a matter of sampling at the highest rate all the time, and doing proper reduction of that data in the same cog.
Using the simple rule i mentioned earlier the 010=01 101=10 reduction the fast rate pulses can still be plotted when the DIV mode is on 1ms.
The positions of the fast rate pulses won't be exact, but they will still show up on all scales, and those lines that have high rate pulses (like a 3mhz clock) will look like barcodes, instead of a clock that has timing close to your DIV setting.
If I knew enough about pasm I would write it into my copy of quicksample.
Perhaps you could give it a try if you have time? Or anyone else that understands what I am getting at.
I am sorry for thinking that a limitation of the prop and the code it uses was the fault of your viewport software.
I do have something odd to report. When I do or don't use any trigger at all, and move the DIV to anything above 50ms nothing happens. Blank screen.
Post Edited (Clock Loop) : 2/18/2010 8:05:58 AM GMT
Hi Clock Loop,
ViewPort supports two ways of measuring: "sampling" and "streaming".
When you're just using vp.share to share memory, the variable values will be transmitted continuously to the pc into a buffer. Think of it like a black-box-recorder. If you want to go back to a measurement in the past just scroll back. Then, you can zoom in. This is what I initially built to debug my DanceBot- when it fell over, I could go back to the initial event that started the crash, and look at millisecond resolution to an event that happened 10 seconds ago. If you're sharing 1 variable at 2Mbps you get a sampling rate of ~50ksps!
I built "QuickSample" to support faster measurements. In this case, as you rightly pointed out, the sampling can be much faster than even the 2Mbps connection can support. At a peak rate of 80Msps*32bits/sample: 2.56Gigabits are generated/second! So, for this mode the sample rate is chosen to match the desired time/div of the scope.
At 1ms/div it's actually taking ~50 samples/division- so it's sampling every ~20usec. It's "waiting" the rest of the time- consuming little power but lots of memory!
QuickSample is already very tricky and complex- it's capable of taking a sample EVERY clock cycle- when each instruction takes FOUR clock cycles....
When you set the timescale to 100ms/div in sampling mode- guess how long it'll take to take a complete sample? ViewPort takes samples to fill ~20 divisions- so 20*100msec= 2seconds... Give it some time...
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Thank You Clock Loop and Hanno for a most informative post. It answers questions that I had that could not be found in the manual and I have been too busy to ask.
VERY nice descriptions and screen shots of the problems Clock Loop.
Several people have encountered this problem of artifacts showing up when sampling a high speed signal too slowly. What can be done about it? Clock Loop mentions a "reduction" approach- may not be feasible at full speed, but at slower speeds should be doable... Any other ideas?
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Hanno said...
Several people have encountered this problem of artifacts showing up when sampling a high speed signal too slowly. What can be done about it? Clock Loop mentions a "reduction" approach- may not be feasible at full speed, but at slower speeds should be doable... Any other ideas?
Hanno
I hope I explained the reduction method properly.
Basically you sample all pins at highest rate possible, IN ANY DIV MODE, IN THE COG(hub ram too slow)
Then you read your DIV setting. And depending on it, you will REMOVE every X sample to match the DIV setting, BUT when removing samples, if you encounter a single sample that has two samples around it in the opposite state of the target sample(010 or 101), you have just encountered a sample only 1 bit long. When doing reduction by just removing samples, that single pulse, 1 bit long will be erased. But if you check to see if its a LONE PULSE, then you can at least keep it.
I can draw an example up on some graphing paper to show exactly what I am talking about and what will result from a pulse reduction in the case of clocks or single high speed pulses.
So basically when sampling at the highest rate, you will be removing most of the samples, not recording them to cog ram, which ones you remove depend on the div setting. But if you encounter a pulse a single bit long you will need to propagate that pulse to the nearest bit spot closest to the ram space for your DIV mode.
So if your sampling at highest rate... take these 16 samples..
0101100101001101
If your div mode was set to 1 step lower than the highest sample rate your cog, you would discard every other sample.
Normally you would just discard every other sample with no worries. But this would eliminate pulses if they were lone pulses depending on their location.
Remove every 2nd sample
00100010
If you notice, in the first 16bit sample, there was a LONE 1 and was removed in the reduction, but if you follow this rule...
For each bit removed, compare it with the two bits that surround it.
If BOTH bits that surround your removed sample are opposite state of your removed sample,
you need to invert the state of ONE of those surrounding bits.
Heres what results from the 16bit sample being reduced following that simple rule.
01 01 10 01 01 00 11 01<---this last bit has no 3rd bit so I just mirror the bit before it to be able to still follow the 3 bit compare rule.
=
10111011
If you look at the original sequence 01 01 10 01 01 00 11 01 you will see LONE Bits (in bold) (only our targeted removal bits)
Here is where those lone bits ended up. 10111011
It just so happens that my targeted bits never had a 0 surrounded by a 1's, but the same rule would apply.
The only reason I care about seeing high speed blips of lines on my LSA when in slower speeds is because I found that this is an invaluable tool to test many logic lines for proper progression through time.
When in 1ms mode for example, I only care that my 1us pulse shows, and shows up APPROXIMATELY where its supposed to be.
This would allow a 1us pulse that happens every 1ms to show up. Then when you zoom the div mode, that same pulse won't move(on timeline) or get bigger/smaller it will just look the same, unill your div mode gets closer to its actual size.
Example, when I had to diagnose a malfunctioning PCI card, with a 20 pin agilent lsa,
I just used an identical PCI card and connected 20 or so different logic points and identified the "progression" of steps that each logic line took, i.e. CS line operation, resets, clocks, and other various logic signals that don't start all at the same time.
I was able to identify which chip was bad by knowing very little about the architecture, or signals, or program.
Viewport with the propeller beats the agilent device hands down due to the cost and sheer number of logic lines available on the prop/viewport. (if we can fix this high speed pulse issue) (but most signals being diagnosed are not 80mhz)
I know that the resolution of the high speed signals will be unreliable (and exact positioning), but the APPROXIMATE position of that high speed pulse is what I care about.
So If I wanted to see the 20th CS pulse in my program above, because right after it another line is suppose to start talking... I would be able to see that by just setting the dial to a longer DIV.
I hear you about the limitations of the prop on this, so then only do this rule when running in a sample speed that the asm can keep up with. Who really needs that on small DIV modes anyway. This is just so small pulses still show up on large div modes.
But this method would require the sample loop to run at its fastest sample rate, and then do "on the fly", in the cog reduction of samples.
But the reduction method I suggest will screw up high speed bits (as far as their position)when this basic method is run through more than once on the same sample.(this would be done to do more than a 1/2 reduction)
Unless you can keep track of which way you moved the single pulse bit. (left or right) (possible i think)
If you can then when you move that same bit again(this would happen during many repeat 1/2 reductions(in the cog)) that bit will jump left and right AROUND its original position.(original position being impossible to attain) But you would only need to keep track of that direction for one iteration behind, then during reduction you can look back and if that same bit was the result of a reduction, you can see which way that bit originally moved, left or right. (the bit that you inverted last iteration)
This would cause the high speed bit to dance around its original position.
I can see how the sample loop could not run at HIGHEST RATE, but gosh, it would cover 95% of the spectrum?
hover1 said...
Thank You Clock Loop and Hanno for a most informative post. It answers questions that I had that could not be found in the manual and I have been too busy to ask.
VERY nice descriptions and screen shots of the problems Clock Loop.
Jim
THANKS, I am just trying to make the world a better place, 1 bit at a time.
Hanno said...
When you set the timescale to 100ms/div in sampling mode- guess how long it'll take to take a complete sample? ViewPort takes samples to fill ~20 divisions- so 20*100msec= 2seconds... Give it some time...
For me, nothing worked above 20ms/div before 2 days ago. I figured it was a bug, so I deleted the viewport directory, reinstalled, and 50ms/div now works randomly, but nothing above it works at all.
I realized that the reason nothing above 20ms/div works is due to the quicksample object and the # of cogs/samples you set.
Just now I realized that 50ms/div mode worked for me only when I had my quicksample object set to a single cog.
When I use 4 cogs and 1600 samples with the quicksample object, 50ms/div and up are dead.
When I use 1 cog and 400 samples, I can't get 50ms/div to work.
When I use 1 cog and 1600 samples, I can get 50ms/div to work and 100ms/div works randomly, but nothing above 100ms/div.
Whats the maximum amount of samples you can use? I figured 1600?
I noticed you can push STOP up above to stop the communication connection. The LSA will continue to function and even the DIV mode will.
IS THIS DATA FAKE / RELIABLE? I am guessing IT IS FAKE.
Somehow this shouldn't be allowed, or at least make a note about it.
The reason I am making these observations is that most LSA's are not usually limited in processor ram, so they store all bits with no reduction and then do reduction only to show data to user, this being possible because of ram space.
The prop, cogs are ram limited. So we must pick what data to keep according to our div mode.
That means if you want to keep high bit info, you need to reduce it in the live cog?
I am beginning to see the need for my whiteboard again.
Hey Hanno I know this is heavy reading, so don't stress it if you don't get to all my stuff immediately.
With all that you have given me, already accomplished, is amazing, yes I paid for it, but I would just like to say thanks,
WOW, the wide range of possibilities you have shown with this software is amazing, it really shows whats possible with this amazing chip.
Thank you and don't stop ever!
Is it possible to allow the font of the code editor to be able to set the size like the propeller tool?
I love to read my code in font 6. [noparse];)[/noparse]
If you close viewport when its maximized on your secondary display, it will open up on the primary display. But if you size the window to almost match the second display, then close it, viewport will open on the second display.
Post Edited (Clock Loop) : 2/19/2010 1:30:03 PM GMT
Hey hanno, I am trying to edit using the designer mode and am having difficulty just adding a switch. I chose terminal mode, and then went "file" "new". It asks me for a name, I choose "box" (this is the name my prop code calls when its loaded.)
My issue is, when I try to modify the terminal xml file using the designer mode, I run into major errors.
I cannot seem to force the parent object on things like the switch.
When I try to modify the terminal object, and actually just delete the terminal, and use the text output, it messes up when I try to start to add swiches. Its hard to make the parent object the viewport box. When I can manage to do that, sometimes when I drag the switch over to the box, it asks me if I would like to change the parent, and i say yes, then it works. But more often than not, it doesn't even ask me.
I find that if I modify any tab, they all start to act funny in some way.
What am i doing wrong? What is the best way to modify the xml file? (other than in designer mode)
Perhaps a bit of a lesson on how to do some "designer mode" manipulation, and possible "avoid doing this".
I find that if I mess up an xml file it permanently messes up and I must delete it and start from my last position that I didn't notice anything getting wack.
I find that sometimes the RED selection bar, and the GREEN size boxes just dissappear when I heavily manipulate the terminal tab.
Hi Clock Loop,
Shoot, I missed a long post from you- the one from 2-18. Let me digest that one- I'll reply to that tomorrow, it's late here.
Ok, designer stuff...
I've found that the graphical drag/drop/resize works best to make things look nice, but organizing UI hierarchies is easier in text mode.
What I do is drag all the widgets I want onto the new view inside ViewPort. I leave ViewPort open, and use a text editor to copy/paste the xml into the right structure- it's pretty easy to read. For example, a switch looks like this: <switch var="autoscale" color="ff0... I save in my editor, and in ViewPort I toggle tabs so it refreshes the view from the file. I know it's not perfect.. I think the biggest problem right now is with containers and arranging thing into/out of them... Resizing, moving items works well- I use a combination of keyboard and mouse. The first drop-down under "properties" also let's you select an item by name/type- that's pretty useful.
Views shouldn't affect each other- what do you mean "act funny"?
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
I've found that the graphical drag/drop/resize works best to make things look nice, but organizing UI hierarchies is easier in text mode.
Resizing, moving items works well- I use a combination of keyboard and mouse.
Views shouldn't affect each other- what do you mean "act funny"?
Hanno
If you load these various tabs into viewport, the ones that say good, are my attempts to create a good tab. I would mark it bad once it became corrupt and not load in viewport properly, then I would revert back to my copy that was still good, and try to repeat the thing I was trying before, sometimes it will do what I want, and I can save the tab, reload it, and it works. Other times i save the tab, and reload it and it show up blank.
I am just doing things like moving windows around, adding buttons, trying to change the parent objects, etc.
I have noticed after trying to track this down, that if I enter designer mode, and only change 1 thing. Then save, and get out of designer mode, then change tabs, then back to your tab. This lets you check your change for problems. So far when I make only 1 change at a time then save, and verify each change, it seems to work properly. (except for making widgets change their parents, and also when I change a widget(its var value) it gets copied. I now have two of the same widget, one with a value I put into var, and another the same as the default.
So I keep mine, and delete the default. Save, then get out of designer mode, then change tabs, then back to my tab, and the default widget that I deleted is back there. I delete it again, save, change tabs, and its there again. If I delete it and then save it, sometimes when I change tabs, it disappears.
Post Edited (Clock Loop) : 3/3/2010 12:13:43 AM GMT
Hi CL,
Thanks for posting the xml files. I was able to open them in the debugger and immediately found the problem with all 3 "broken" files. Fixing will take a bit more time, but I do have a workaround for you:
The "cursors" widget is specified like this in the xml:
<code>
<cursors color="ff000000" color2="ff000000" font="Arial_8" location="0,-20" size="504,747" points="0,0 115.7472,0 196.3569,0 301.7695,0 415.4498,0 0,0 1,3" labels=",Show,A,B,Diff,Vert,Horz," />
</code>
The last 2 "points" values must be 1,3- in your "broken" files, they were scaled to other values: here's an example:
<code>
<cursors color="ff000000" color2="ff000000" font="Arial_8" location="0,-20" size="504,747" points="0,0 115.7472,0 196.3569,0 301.7695,0 415.4498,0 0,0 2.066915,2.989933" labels=",Show,A,B,Diff,Vert,Horz," />
</code>
I'm working on a real fix- might take a bit longer because I'm in the middle of integrating a professional code editing object.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
I figured out why this hasn't come up before....
I take the "integer" of those values. So, if you just change the size of the "cursor" widget by small amounts each time and save the file, the integer portion won't be affected. You changed the size too much all in one go. Funny thing [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Hi CL,
I'm giving some "love" to the designer part of ViewPort- it's working really well now- I'll share it asap. Yup there are lots of XML editors out there- I still prefer Notepad+++ for easy copy/paste. I came up with a simple fix to the "parent finder" problem- you can right-click on an object and assign it a parent! Much more intuitive.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here), 12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
Comments
I though I was onto squashing a bug, but it sounds like your telling me that the prop samples data at the rate you set on the DIV dial.
I know about sample rates(Nyquist) and the like, my question is does the prop sample the data at the rate you set on the DIV dial?
Or does the prop sample all its pins at its highest rate, and then send the data to be downscaled on the PC?
So If I set my quicksample object to 4 cogs and 1600 samples,
is it sampling at the rate set by those four cogs or does viewport tell the prop at what rate to sample?
Perhaps this is nothing more than a lack of understanding on how the prop samples data in the quick sample object when using 4 cogs and 1600 samples.
I tried to look at the quicksample object but the pasm code is not commented so I have no idea whats going on, my pasm reading isn't good.
P.S. I am now a DEV owner. [noparse]:)[/noparse]
Playing catch up now.
Post Edited (Clock Loop) : 2/18/2010 4:46:29 AM GMT
Thanks for the purchase!
Yes, the sampling rate changes as the timescale is changed. When using 1 cog, the maximum sampling rate is 20Msps. With 4 you can sample at up to 80Msps- all with the standard 80MHz clockrate. The sampling rate is determined by the timescale and the size of your screen- each sample will be represented by 1 pixel. If you over-clock your Propeller you can go even faster- ViewPort will automatically adjust the timing information based on the clock constants.
Looks like this is resolved- in summary, make sure to measure signals at the proper rate! I typically start at a much faster rate and then decrease until the signal is sized for my needs.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
So if one were to sample at a high rate 80Msps on the prop like the quicksample object, one would fill up data space very fast, faster than the 2mbps connection that we have available?
So the answer is to sample for a shorter amount of time and then stop sampling to let the data finish getting sent over the usb connection? Thats why a continuous sample lasting 100ms at a rate of 200ns cannot be done?
So when I am in 1ms DIV mode, and the prop is only taking a sample every .5ms what is it doing with all that extra time?
So then its really just a matter of sampling at the highest rate all the time, and doing proper reduction of that data in the same cog.
Using the simple rule i mentioned earlier the 010=01 101=10 reduction the fast rate pulses can still be plotted when the DIV mode is on 1ms.
The positions of the fast rate pulses won't be exact, but they will still show up on all scales, and those lines that have high rate pulses (like a 3mhz clock) will look like barcodes, instead of a clock that has timing close to your DIV setting.
If I knew enough about pasm I would write it into my copy of quicksample.
Perhaps you could give it a try if you have time? Or anyone else that understands what I am getting at.
I am sorry for thinking that a limitation of the prop and the code it uses was the fault of your viewport software.
I do have something odd to report. When I do or don't use any trigger at all, and move the DIV to anything above 50ms nothing happens. Blank screen.
Post Edited (Clock Loop) : 2/18/2010 8:05:58 AM GMT
ViewPort supports two ways of measuring: "sampling" and "streaming".
When you're just using vp.share to share memory, the variable values will be transmitted continuously to the pc into a buffer. Think of it like a black-box-recorder. If you want to go back to a measurement in the past just scroll back. Then, you can zoom in. This is what I initially built to debug my DanceBot- when it fell over, I could go back to the initial event that started the crash, and look at millisecond resolution to an event that happened 10 seconds ago. If you're sharing 1 variable at 2Mbps you get a sampling rate of ~50ksps!
I built "QuickSample" to support faster measurements. In this case, as you rightly pointed out, the sampling can be much faster than even the 2Mbps connection can support. At a peak rate of 80Msps*32bits/sample: 2.56Gigabits are generated/second! So, for this mode the sample rate is chosen to match the desired time/div of the scope.
At 1ms/div it's actually taking ~50 samples/division- so it's sampling every ~20usec. It's "waiting" the rest of the time- consuming little power but lots of memory!
QuickSample is already very tricky and complex- it's capable of taking a sample EVERY clock cycle- when each instruction takes FOUR clock cycles....
When you set the timescale to 100ms/div in sampling mode- guess how long it'll take to take a complete sample? ViewPort takes samples to fill ~20 divisions- so 20*100msec= 2seconds... Give it some time...
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
VERY nice descriptions and screen shots of the problems Clock Loop.
Jim
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
I hope I explained the reduction method properly.
Basically you sample all pins at highest rate possible, IN ANY DIV MODE, IN THE COG(hub ram too slow)
Then you read your DIV setting. And depending on it, you will REMOVE every X sample to match the DIV setting, BUT when removing samples, if you encounter a single sample that has two samples around it in the opposite state of the target sample(010 or 101), you have just encountered a sample only 1 bit long. When doing reduction by just removing samples, that single pulse, 1 bit long will be erased. But if you check to see if its a LONE PULSE, then you can at least keep it.
I can draw an example up on some graphing paper to show exactly what I am talking about and what will result from a pulse reduction in the case of clocks or single high speed pulses.
So basically when sampling at the highest rate, you will be removing most of the samples, not recording them to cog ram, which ones you remove depend on the div setting. But if you encounter a pulse a single bit long you will need to propagate that pulse to the nearest bit spot closest to the ram space for your DIV mode.
So if your sampling at highest rate... take these 16 samples..
0101100101001101
If your div mode was set to 1 step lower than the highest sample rate your cog, you would discard every other sample.
Normally you would just discard every other sample with no worries. But this would eliminate pulses if they were lone pulses depending on their location.
Remove every 2nd sample
00100010
If you notice, in the first 16bit sample, there was a LONE 1 and was removed in the reduction, but if you follow this rule...
For each bit removed, compare it with the two bits that surround it.
If BOTH bits that surround your removed sample are opposite state of your removed sample,
you need to invert the state of ONE of those surrounding bits.
Heres what results from the 16bit sample being reduced following that simple rule.
01 01 10 01 01 00 11 01<---this last bit has no 3rd bit so I just mirror the bit before it to be able to still follow the 3 bit compare rule.
=
10111011
If you look at the original sequence 01 01 10 01 01 00 11 01 you will see LONE Bits (in bold) (only our targeted removal bits)
Here is where those lone bits ended up.
1011 1011
It just so happens that my targeted bits never had a 0 surrounded by a 1's, but the same rule would apply.
The only reason I care about seeing high speed blips of lines on my LSA when in slower speeds is because I found that this is an invaluable tool to test many logic lines for proper progression through time.
When in 1ms mode for example, I only care that my 1us pulse shows, and shows up APPROXIMATELY where its supposed to be.
This would allow a 1us pulse that happens every 1ms to show up. Then when you zoom the div mode, that same pulse won't move(on timeline) or get bigger/smaller it will just look the same, unill your div mode gets closer to its actual size.
Example, when I had to diagnose a malfunctioning PCI card, with a 20 pin agilent lsa,
I just used an identical PCI card and connected 20 or so different logic points and identified the "progression" of steps that each logic line took, i.e. CS line operation, resets, clocks, and other various logic signals that don't start all at the same time.
I was able to identify which chip was bad by knowing very little about the architecture, or signals, or program.
Viewport with the propeller beats the agilent device hands down due to the cost and sheer number of logic lines available on the prop/viewport. (if we can fix this high speed pulse issue) (but most signals being diagnosed are not 80mhz)
I know that the resolution of the high speed signals will be unreliable (and exact positioning), but the APPROXIMATE position of that high speed pulse is what I care about.
So If I wanted to see the 20th CS pulse in my program above, because right after it another line is suppose to start talking... I would be able to see that by just setting the dial to a longer DIV.
I hear you about the limitations of the prop on this, so then only do this rule when running in a sample speed that the asm can keep up with. Who really needs that on small DIV modes anyway. This is just so small pulses still show up on large div modes.
But this method would require the sample loop to run at its fastest sample rate, and then do "on the fly", in the cog reduction of samples.
But the reduction method I suggest will screw up high speed bits (as far as their position)when this basic method is run through more than once on the same sample.(this would be done to do more than a 1/2 reduction)
Unless you can keep track of which way you moved the single pulse bit. (left or right) (possible i think)
If you can then when you move that same bit again(this would happen during many repeat 1/2 reductions(in the cog)) that bit will jump left and right AROUND its original position.(original position being impossible to attain) But you would only need to keep track of that direction for one iteration behind, then during reduction you can look back and if that same bit was the result of a reduction, you can see which way that bit originally moved, left or right. (the bit that you inverted last iteration)
This would cause the high speed bit to dance around its original position.
I can see how the sample loop could not run at HIGHEST RATE, but gosh, it would cover 95% of the spectrum?
THANKS, I am just trying to make the world a better place, 1 bit at a time.
For me, nothing worked above 20ms/div before 2 days ago. I figured it was a bug, so I deleted the viewport directory, reinstalled, and 50ms/div now works randomly, but nothing above it works at all.
I realized that the reason nothing above 20ms/div works is due to the quicksample object and the # of cogs/samples you set.
Just now I realized that 50ms/div mode worked for me only when I had my quicksample object set to a single cog.
When I use 4 cogs and 1600 samples with the quicksample object, 50ms/div and up are dead.
When I use 1 cog and 400 samples, I can't get 50ms/div to work.
When I use 1 cog and 1600 samples, I can get 50ms/div to work and 100ms/div works randomly, but nothing above 100ms/div.
Whats the maximum amount of samples you can use? I figured 1600?
I noticed you can push STOP up above to stop the communication connection. The LSA will continue to function and even the DIV mode will.
IS THIS DATA FAKE / RELIABLE? I am guessing IT IS FAKE.
Somehow this shouldn't be allowed, or at least make a note about it.
The reason I am making these observations is that most LSA's are not usually limited in processor ram, so they store all bits with no reduction and then do reduction only to show data to user, this being possible because of ram space.
The prop, cogs are ram limited. So we must pick what data to keep according to our div mode.
That means if you want to keep high bit info, you need to reduce it in the live cog?
I am beginning to see the need for my whiteboard again.
Hey Hanno I know this is heavy reading, so don't stress it if you don't get to all my stuff immediately.
With all that you have given me, already accomplished, is amazing, yes I paid for it, but I would just like to say thanks,
WOW, the wide range of possibilities you have shown with this software is amazing, it really shows whats possible with this amazing chip.
Thank you and don't stop ever!
Is it possible to allow the font of the code editor to be able to set the size like the propeller tool?
I love to read my code in font 6. [noparse];)[/noparse]
If you close viewport when its maximized on your secondary display, it will open up on the primary display. But if you size the window to almost match the second display, then close it, viewport will open on the second display.
Post Edited (Clock Loop) : 2/19/2010 1:30:03 PM GMT
My issue is, when I try to modify the terminal xml file using the designer mode, I run into major errors.
I cannot seem to force the parent object on things like the switch.
When I try to modify the terminal object, and actually just delete the terminal, and use the text output, it messes up when I try to start to add swiches. Its hard to make the parent object the viewport box. When I can manage to do that, sometimes when I drag the switch over to the box, it asks me if I would like to change the parent, and i say yes, then it works. But more often than not, it doesn't even ask me.
I find that if I modify any tab, they all start to act funny in some way.
What am i doing wrong? What is the best way to modify the xml file? (other than in designer mode)
Perhaps a bit of a lesson on how to do some "designer mode" manipulation, and possible "avoid doing this".
I find that if I mess up an xml file it permanently messes up and I must delete it and start from my last position that I didn't notice anything getting wack.
I find that sometimes the RED selection bar, and the GREEN size boxes just dissappear when I heavily manipulate the terminal tab.
Is there a better way to do this?
Shoot, I missed a long post from you- the one from 2-18. Let me digest that one- I'll reply to that tomorrow, it's late here.
Ok, designer stuff...
I've found that the graphical drag/drop/resize works best to make things look nice, but organizing UI hierarchies is easier in text mode.
What I do is drag all the widgets I want onto the new view inside ViewPort. I leave ViewPort open, and use a text editor to copy/paste the xml into the right structure- it's pretty easy to read. For example, a switch looks like this: <switch var="autoscale" color="ff0... I save in my editor, and in ViewPort I toggle tabs so it refreshes the view from the file. I know it's not perfect.. I think the biggest problem right now is with containers and arranging thing into/out of them... Resizing, moving items works well- I use a combination of keyboard and mouse. The first drop-down under "properties" also let's you select an item by name/type- that's pretty useful.
Views shouldn't affect each other- what do you mean "act funny"?
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
If you load these various tabs into viewport, the ones that say good, are my attempts to create a good tab. I would mark it bad once it became corrupt and not load in viewport properly, then I would revert back to my copy that was still good, and try to repeat the thing I was trying before, sometimes it will do what I want, and I can save the tab, reload it, and it works. Other times i save the tab, and reload it and it show up blank.
I am just doing things like moving windows around, adding buttons, trying to change the parent objects, etc.
I have noticed after trying to track this down, that if I enter designer mode, and only change 1 thing. Then save, and get out of designer mode, then change tabs, then back to your tab. This lets you check your change for problems. So far when I make only 1 change at a time then save, and verify each change, it seems to work properly. (except for making widgets change their parents, and also when I change a widget(its var value) it gets copied. I now have two of the same widget, one with a value I put into var, and another the same as the default.
So I keep mine, and delete the default. Save, then get out of designer mode, then change tabs, then back to my tab, and the default widget that I deleted is back there. I delete it again, save, change tabs, and its there again. If I delete it and then save it, sometimes when I change tabs, it disappears.
Post Edited (Clock Loop) : 3/3/2010 12:13:43 AM GMT
Thanks for posting the xml files. I was able to open them in the debugger and immediately found the problem with all 3 "broken" files. Fixing will take a bit more time, but I do have a workaround for you:
The "cursors" widget is specified like this in the xml:
<code>
<cursors color="ff000000" color2="ff000000" font="Arial_8" location="0,-20" size="504,747" points="0,0 115.7472,0 196.3569,0 301.7695,0 415.4498,0 0,0 1,3" labels=",Show,A,B,Diff,Vert,Horz," />
</code>
The last 2 "points" values must be 1,3- in your "broken" files, they were scaled to other values: here's an example:
<code>
<cursors color="ff000000" color2="ff000000" font="Arial_8" location="0,-20" size="504,747" points="0,0 115.7472,0 196.3569,0 301.7695,0 415.4498,0 0,0 2.066915,2.989933" labels=",Show,A,B,Diff,Vert,Horz," />
</code>
I'm working on a real fix- might take a bit longer because I'm in the middle of integrating a professional code editing object.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
I take the "integer" of those values. So, if you just change the size of the "cursor" widget by small amounts each time and save the file, the integer portion won't be affected. You changed the size too much all in one go. Funny thing [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
My method of making a single step and saving, then testing that change seems to work best in manipulating them.
I tried to look at the xml file and was getting no where fast with notepad.
What do you think of this tool?
I really like how it organizes the data, this is something I can deal with and really work with.
FREE
WARE(November 4, 2004)
XML marker.
http://symbolclick.com/
I'm giving some "love" to the designer part of ViewPort- it's working really well now- I'll share it asap. Yup there are lots of XML editors out there- I still prefer Notepad+++ for easy copy/paste. I came up with a simple fix to the "parent finder" problem- you can right-click on an object and assign it a parent! Much more intuitive.
Hanno
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer