I installed Viewport and played for a day when I had the time so I could get a bit familiar. But when I really needed to take it for a debugging spin, it had already expired. So I don't know much about its real life capabilities.
I think rather than a timed evaluation period, a usage evaluation period would be more practical for busy people.
I'd love to experiment with it more than once to get a feel for its capabilities. Finding play time more than once a month can be difficult! So I wonder if it would work for me, but I'm not willing to pay the price to find out that it doesn't.
Virtual machines are great for evaluating demoware that leaves breadcrumbs behind on your system. Snapshot, Install, Play, Roll back snapshot, Lather, Rinse, Repeat.
The best part is if you decide that the software is really not your cup of tea, it never actually polluted your system with anything.
Software that puts Smile all over your system (dll's, registry entries, .ini files, hidden garbage) and does not remove 100% of it when you uninstall is one of the huge reasons Windows turns into a pile of goo over a year or two..
Virtualbox is free and fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I do my best to keep all my customers happy- currently all 76 threads on my forums have ended successfully...
I'll investigate "usage" based trials- although I would prefer to spend time working on new features...
Back to the original question-
Yes, as long as your timing constants are set correctly, ViewPort will work and use the right timescale for showing your signals. I use it up to 106MHz. The PropScope runs at 100MHz. Sapieha has run up to ~120MHz...
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
Thanks for taking notice of this posting and for your total support.
Absolutely total congratulations on resolving all 76 threads on your
forums, which is a great accomplishment and shows your dedication
to this product.
I have no problems to run ViewPort with any frequency.
I RUN it with both 100MHz and frequencies upp to 120MHz without problems.
Stable in all communication speeds.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Thanks. This knowledge is very helpful.
BTW, congratulations on your successful experiments
in running the Propeller chip at enhanced frequencies.
This has helped many of us squeeze out more power
from an already powerful Propeller chip.
One quick question. Some of the program tutorials have schematics written in the info area of the spin file.
But I can't decrypt what is going on. I have attached an image.
Also in that image....
(that clock setting of _clkmode = xtal1 + pll16x with _clkfreq= 80_000_000 )
pll16x mode??
Post Edited (Clock Loop) : 2/18/2010 4:18:24 AM GMT
Clock Loop said...
One quick question. Some of the program tutorials have schematics written in the info area of the spin file.
But I can't decrypt what is going on. I have attached an image.
Also in that image....
(that clock setting of _clkmode = xtal1 + pll16x with _clkfreq= 80_000_000 )
pll16x mode??
Means my prop is running at 1.28 ghz hehehe.
As for the encoding issue, it looks like the file is UTF-8 encoded. The Propeller Tool expects either plain ASCII or UCS2 encoded characters.
_clkfreq = _xinfreq * PLL
You can specify either one but not both. I prefer _xinfreq.
Kuroneko is right, looks like there are UTF-8 characters in that file. This file "12_Measure Capacitance" shows ok within ViewPort, but not in the Propeller Tool. I'll have a closer look tomorrow- thanks for the heads up.
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
As for the encoding issue, it looks like the file is UTF-8 encoded. The Propeller Tool expects either plain ASCII or UCS2 encoded characters.
_clkfreq
_xinfreq
You can specify either one but not both.
I prefer _xinfreq.
OOOOPS. I was mixing _clkfreq with _xinfreq...
heh details.. details..
in the prop manuall...
The application can specify either _CLKFREQ or _XINFREQ in the CON block; they are mutually
exclusive and the non-specified one is automatically calculated and set as a result of
specifying the other.
Back to the skeematic. I still don't see what its trying to show..
so I ran CHARMAP and loaded up the PARALLAX font, and looked at the very bottom.
I then copied some of the schematic symbols and put them into the propeller tool.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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...
Kuroneko is right, looks like there are UTF-8 characters in that file. This file "12_Measure Capacitance" shows ok within ViewPort, but not in the Propeller Tool. I'll have a closer look tomorrow- thanks for the heads up.
You need to force saving as UTF-16 for the Propeller Tool to cope with Unicode. Easiest way would be to load the files in an editor that understands both and lets you force saving as UTF-16.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I think rather than a timed evaluation period, a usage evaluation period would be more practical for busy people.
Most people like me leave their computer running for about a week without shutting down. Viewport could run for this entire time. Besides, this would require more calculating just for trial protection. There is a bug in Viewport that allows you to bypass the trial, that I reported to Hanno, but I don't think it's fixed yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Computers are microcontrolled.
Hi Clock Loop,
The $29 version of ViewPort does not include an integrated code editor or visual spin code debugger. The other's do. You can upgrade your license key here: hannoware.com/viewport/upgrade.php Cost is the same as if you had bought everything together in the first place.
The "code" view let's you view your code- but most importantly it let's you debug your code just like "visual studio"- letting you click on a line to set a breakpoint, step over lines of code, and watch what your program is doing: profiler, memory map, pin status. You can also "animate" your program with the interpreter. Or hover over a variable in your code to see it's value and then change it...
I'm very happy with the debugging functionality, but have recently spent a decent amount of money on a full-blown professional code editor- I'm integrating that into ViewPort now. That'll bring high-end editing features to SPIN, PASM and C...
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
@Clock Loop
I am using Ver 4.2.7 Beta.
On the left side of the Viewport welcome screen, there is a "View Code" button. This will bring up the Propeller Tool and open whatever tutorial program is highlited.
Next to the "Welcome" tab on the top is a tab called "code". This will open the code in Viewport. The formatting is a little better in this view.
Jim
PS I'm not sure what the "Info" button does. I thought it was there to provide othe info like schematics, but I may be thinking of 12Blocks. UPDATE: I just saw Hanno posted while I was composing.
Clock Loop said...
How do you view code IN viewport?
Also does the INFO button do anything?
I keep pressing it.. somewhere something is turning on and off.
Hackers schmakers.. I have been around the shareware / freeware / paidware / trialware / crippleware / nagware / weregoingtotrytoprotectourcodefrombeingcrackedtothepointthatitmessesupthepersonscomputerandouroriginalcode-ware.
People pay for programs that either work(and have most things they need)
or they pay for programs that are buggy but have support or affordable sources available. (one mans bug is anothers triumph)
Hanno said...
Hi Clock Loop,
I'm very happy with the debugging functionality, but have recently spent a decent amount of money on a full-blown professional code editor- I'm integrating that into ViewPort now. That'll bring high-end editing features to SPIN, PASM and C...
Hanno
I like your pricing method, I was able to get started early, even tho I had planned to purchase the dev.
I noticed the bugs I ran into when I first started, turned me off to viewport. Then I noticed that the low speed and low buffer for the student copy I tried out first was so bad it almost looked like I was dealing with a bug.
Viewport has a few bugs in it(mentioned below), but I couldn't tell if the way it looked was due to speed/buffer or a bug. I found most of the things I thought were bugs were due to the slow speed and the low buffer.
When I upgraded to the high speed/buffer, I noticed it started to show me results I was looking for, but now my connection was constantly breaking. I investigated it, and found the *mentioned below* speed limitations depending on your electronic LAYOUT.
In electrical noisy conditions 1mbps mode seems to work best.
Speeds below that seem to trigger bugs in viewport its self. (but i can't be sure if its speed based or license based)
I did find bugs in LSA mode and will discuss them in detail below.
Does the developer kit just let you do viewport interface and plugin designing?
I would like to be able to create exe files from my custom viewport configurations(if I had the dev kit)
The point being, one could create a "shell" that you run a single viewport tab in that does nothing else but what that tab was designed to do. Perhaps yet another addon to be considered. Field deployable interfaces.
I have noticed an issue with LSA mode and this code.
I have my prop looking at a 3 mhz clock(I/O-19), a CS(I/O-20) line that is around 400hz, and a few other lines that have some 20mhz pulses.
When I run the code below, I set my trigger on the CS line to be a falling edge in viewports the lsa bit mode, and it shows the attached image named BAD I noticed the correct capture shows up once in a while if I just let it run, but its every 30 seconds or so. Right when I SET the trigger on falling edge, it quickly flashes the correct bitstream (see good image) but then it quickly switches to the BAD image.
I can record the entire process to repeat the bug using a desktop recorder if you need.
I have also attached an image that says, error1, in this image you can see that the data is showing up(again, it just flickers and then goes to the bad blank image), but now the data its self is showing up on the incorrect lines, you can see the TX now on line 22, not 30, like in the good image. I am still in bit mode triggering on the CS line falling edge. I have no idea why it all shifted up, thats how bugs are. One causes another. You can see in the error1 image that my CS line also shifted up to line12 (was on 20), and my clock is on line 11(was on 19).
Below, it says it detected the trigger, so it must be a viewport graphic/data alignment/refresh issue.
One thing to mention is that I do use dual displays. But the same thing happens on either display.
I can run the same test on a vista machine with a single display, if needed.
Is that status message the last message? What is the memory count?
Perhaps the message should erase its self after the expired lot of time is up?
Its hard to know if the reason your not seeing anything properly is due to viewport bug or due to lockup on prop.
For instance, if I just reset the prop while its bursting data out to viewport,
viewport will act like nothing happened to the prop, and it just sits there looking for the trigger, not even knowing the prop just died.
My usb device was never disconnected, so it shows the connection still at 2000kbps.
The VAL stops updating too, but the viewport program knows nothing.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
vp : "Conduit" 'transfers data to/from PC
qs : "QuickSample" 'samples INA continuously in 4 cog to 80mhz
pub demo|frame[noparse][[/noparse]1600],ctr
vp.register(qs.sampleINA(@frame,4)) 'sample INA with 4 cog up to 80Mhz
vp.config(string("var:io,ctr(min=0,max=15)"))
'share memory with ViewPort, io,ctr. Ctr's range is 0-15.
vp.config(string("lsa:view=io,timescale=1ms"))
'View io with a timescale of 1ms with the lsa graph
vp.config(string("start:lsa"))
'Start in lsa mode
vp.share(@ctr,@ctr)
'Share ctr
Perhaps I should start posting in your forums now.
A bit of a note for other users or potential users of viewport.
I had trouble with viewport and running it in any highspeed mode with my prop on a breadboard,
the only way i am able to get it to work in 2mbps mode(and sometimes 1mbps mode) is to use a prop-plug that is directly connected to the prop with very little in between. See my breadboard setup image: breadboard
I HAVE noticed that if you use a 10k pull down resistor on high speed serial communication, it helps the stability. I have noticed that I was able to increase my prop to prop baud from 115200 to 300000 using the simple fullduplexserial object and 10k pull down's on both rx.
I have also noticed this stability when using FTDI prototype devices such as the one shown in my image: breadboard. you can see the DUALPORT ftdi device to the left, and the propplug to the right.
Breadboarded like this, the dual port FTDI device can do 1mbps with no issues with connection to viewport.
But if you use the propplug very close to the prop like I have done, you can get 2mbps.
My power supply is an isolated 5v supply with a ldo3.3v regulator. I do not have a ground loop because my 3.3v supply is isolated, something that many people overlook.
If I didn't have an isolated supply, i would use my usb's 5v supply with a ldo3.3v regulator to power my prop and circuit,
usb is limited tho, so use caution.
Post Edited (Clock Loop) : 2/18/2010 4:23:27 AM GMT
Hi Clock Loop,
Thanks for the long post. I'm glad you like my pricing method. I work on my Propeller projects (PropScope, ViewPort, 12Blocks) full-time and it's great to see people valuing my work. I highly prefer to work on improving the product rather chasing the elusive goal of becoming hacker-proof.
As I mentioned above, I'm proud that to date I've helped everyone who has contacted me to be successful with ViewPort- looks like now is your turn.
I added the ability to select baud-rates to cover special situations like yours. On most machines people are able to get a good 2Mbps connection to their ProtoBoard/DemoBoard- where electrical interference is minimized with very short, grounded connections between the Propeller and the FTDI chip. The default rate of
1Mbps connection should work on all PC's and is better suited for breadboarded projects. People with wireless, or even less stable breadboarded projects use the 115kbps setting. The speed setting shouldn't cause any bugs- the update rate should just decrease.
I notice in your screenshots that you switched from the default 1mbps to 2mbps- can you try setting it back to 1mbps? ViewPort does do some error checking on the received signal, but is unable to detect some types of electrical noise. This could explain why your bit traces shift (as shown in "error1") as well as the short signals (in "bad").
You talk about a status/error message: "Is that status message the last message? What is the memory count?Perhaps the message should erase its self after the expired lot of time is up?" I didn't see this in your screenshots... Could be ViewPort trying its best to tell you about a corrupted transmission?
Maybe someone with more experience in high-speed analog transmission can guide us on the proper way to terminate rs232 signals? Again, I haven't seen any such problems on ProtoBoard/DemoBoard...
Hanno
ps: The current development tools let you create "add-ons" and "plug-ins". Add-ons are full programs that interface with ViewPort via DDE. Plug-ins are DLL's that are run within ViewPort. Good idea on "field deployable interfaces".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
As I mentioned above, I'm proud that to date I've helped everyone who has contacted me to be successful with ViewPort- looks like now is your turn.
I am going to support you also, because I think you are absolutely on the right track with this program.
I am a big user of the logic tools, and this one is mission critical for me right now.
I see this program could potentially help me heavily, but I can't get this first thing to work, which is just trying to use the prop to look at logic signals that a datasheet cannot be found for. So I can figure out the communication scheme of this particular device.
It has a 3mhz clock, a CS, and 3 other data lines. It seems the only trigger mode I have major issues with is the trigger on fall. (in both bit mode and pattern mode)
Rise trigger works, so does trigger "high" or "low" in the pattern mode.
I noticed if I look at the signal on CS and choose trigger on rise, depending on the division mode I have set, my CS pulse will disappear, or show up in wrong timing spots. And other div/sec modes make the repetitive cs pulse not show as repeating, or not show up at all. And other modes move the cs pulse to different spots on the time scale, spots that don't match up with the previous time scale. For instance when I choose trigger high on cs line in 1ms mode, the pulse shows up around 10msec. But then if I choose 500us mode, the CS pulse shows up around 5msec AND 10msec, but nothing after that. Then if I go farther to 200us mode, the CS pulse shows up around 14.8msec, the 5 and 10msec pulses are now missing. If I try 2ms mode the CS pulse at 10msec is missing, and shows up no where. But it says its triggered on signal through all this.
See image attachments.
So depending on the DIV/SEC that I choose, that will determine if the pulses that are being detected (triggered) are going to show up graphically or not. (again the CS pulse IS triggering, but will show the pulse at different times depending on the DIV/SEC mode I choose.
I have used a few lsa's and found that the correct response when you choose a different div/sec mode is for you to see the same pulse that your triggering on in the same spot, but more or less detail about the duration of that pulse. The pulse should not be jumping from 10ms, to 5ms, then to 14ms depending on my div setting. Nor should it be show a single pulse, and then 2 pulses, and then none when i change the div setting.
I can start using a screen recording tool so you can see this, in real time if you think it would help.
this is just too much stuff to try to type and hope that my issue is being conveyed.
I am missing pulses because that CS line has a consistent repeat rate, but viewport will not show this. It will usually only show the first pulse and not the subsequent ones after it.
I suspected that my CS pulse was not consistent and repeating, so I tried to use 10ms or 20ms or 50ms and those don't show any pulse at all on my cs line, but the "triggered on signal" is showing and the display is updating. (i can tell by the serial data and the jitter on my 3mhz clock that I am triggering)
So it can't be a weak signal.
Hanno said...
I notice in your screenshots that you switched from the default 1mbps to 2mbps- can you try setting it back to 1mbps?
I tried 1megbaud on an xp machine with dual displays, and a vista machine with a single display, and found that I cannot trigger properly on fall. I tried 115200 baud mode and saw that the same thing happens, it triggers on the fall, but then quickly disappears, but this time it took longer to disappear in the 115200 baud mode. Once it disappeard in 115200 baud mode it dosen't show back up again.
The speed of the trigger on fall and the display being blanked out shortly after is dependent on baud speed.
Note that other trigger modes do not do this at all. So its likely not an issue with the baud. Higher baud rates would cause program loops to increase which would explain why the lower baud took longer to manifest the blank bug.
Ya know so far ALL of my issues have been with the LSA and particularly with the graphing of the logic data, and the time/div scale. Oddities show up even when just changing the div/sec dial also. I'd like to blame it on my system, but when moving to a vista system that is entirely offline, same results show up.
Hanno said...
I didn't see this in your screenshots... Could be ViewPort trying its best to tell you about a corrupted transmission?
I was just staying that it would be nice to have a count since last trigger so one could see if they are triggering at a specific timing rate. Right next to Waiting for trigger, put a number that shows how much time has elapsed since last trigger. This will help people see if they are missing triggers or if the data being displayed is incorrect, or if they are in fact not triggering, they will notice by the count.
Attached images are:
-good cs pulse at 5ms in 100us mode.jpg (all of the DIV modes should show this)
-good 5ms And 10ms CS pulse in 500us Mode.jpg (all of the DIV modes should show this)
-good CS pulse at 10ms in 1ms Mode but Missing the 5ms pulse.jpg
-Missing5msCSpulse.jpg -200us mode
-Missing10msCSpulse.jpg -200us mode
5 and 10ms CS pulses missing in 200us Mode
The only pulse found was at 14.8ms in 200us Mode
The trigger on fall screen blanking issue does not change in any situation of the DIV mode, its always the same.
But the pulse missing and the pulse position misalignment are issues that change depending on the DIV mode.
I still see pulses missing and pulse position issues with higher div modes also, the 5ms mode shows no pulse at 5ms or 10ms.
No mode shows pulses every 5 ms like they all should.
Just to make sure its not my signal, I will take another prop,
and generate the same signals as my cs line and do the same thing to verify my issue is not signal.
Post Edited (Clock Loop) : 2/18/2010 4:27:30 AM GMT
Below is a program that will generate two signals.
A 5mhz clock(P19), and a Pulse(P20) with a low time of 500us and the high time is toggled as fast as spin can toggle a pin on and off.
Attached are 5 images all at different DIV modes as labeled.
The images show exactly what is wrong when you read the spin program I attached.
The spin program attached continually generates two signals, one 5mhz and the other a pwm described above.
Note how in the images that show multiple pulses, pulses are totally missing, and the pulses that are missing depends on your DIV setting.
I understand a 10 us pulse cannot be shown in detail on a very high DIV setting, but its very important to show every pulse,
even if it looks like a mess, a.k.a the PIN will look like a barcode because the pulses are smashed together.
I have 2 props running, one runs the clock program, and the other runs the LSA.
P20 on clock prop goes to P20 on LSA
P19 on clock prop goes to P19 on LSA
This is the code on the LSA prop.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
vp : "Conduit" 'transfers data to/from PC
qs : "QuickSample" 'samples INA continuously in 4 cog to 80mhz
pub demo|frame[noparse][[/noparse]1600],ctr
vp.register(qs.sampleINA(@frame,4)) 'sample INA with 4 cog up to 80Mhz
vp.config(string("var:io,ctr(min=0,max=15)"))
'share memory with ViewPort, io,ctr. Ctr's range is 0-15.
vp.config(string("lsa:view=io,timescale=1ms"))
'View io with a timescale of 1ms with the lsa graph
vp.config(string("start:lsa"))
'Start in lsa mode
vp.share(@ctr,@ctr)
'Share ctr
This is the program that is running on the clock prop.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
ClockPin = 19
CS = 20
DiagRX = 31
DiagTX = 30
ClockRate = 5_000_000 '5MHz
OBJ
ClockGen : "Synth"
VAR
long cogon, cog, pile[noparse][[/noparse]1000]
PUB start
stop
cogon[noparse][[/noparse]0] := (cog[noparse][[/noparse]0] := cognew(ClockOut, @pile[noparse][[/noparse]0]) > 0) ' 2 cogs
PUB Clockout
dira[noparse][[/noparse]CS]~~
ClockGen.Synth("A",ClockPin, ClockRate) 'Synth({Counter"A" or Counter"B"},Pin, Freq)
Repeat
!outa[noparse][[/noparse]CS]
'Assuming that a 80 MHz core clock is being used, 800,000 cycles is about 10 ms (1/100th second) of time.
'waitcnt(800 + cnt) 'Wait for 10us -100 khz
'waitcnt(8_000 + cnt) 'Wait for 100 us -10 khz
'waitcnt(80_000 + cnt) 'Wait for 1ms -1000 hz
'waitcnt(800_000 + cnt) 'Wait for 10 ms -100 hz
'waitcnt(8_000_000 + cnt) 'Wait for 100 ms -10hz human reaction speed
'waitcnt(80_000_000 + cnt) 'Wait for 1000 ms -1hz
!outa[noparse][[/noparse]CS]
'waitcnt(800 + cnt) 'Wait for 10us -100 khz
'waitcnt(8_000 + cnt) 'Wait for 100 us -10 khz
'waitcnt(40_000 + cnt) 'Wait for 500us
waitcnt(38_636 + cnt) 'Wait for 500us ***adjusted for spin loop***
'waitcnt(80_000 + cnt) 'Wait for 1ms -1000 hz
'waitcnt(800_000 + cnt) 'Wait for 10 ms -100 hz
'waitcnt(8_000_000 + cnt) 'Wait for 100 ms -10hz human reaction speed
'waitcnt(80_000_000 + cnt) 'Wait for 1000 ms -1hz
PUB stop
'' Unload timer object - frees a cog
if cogon[noparse][[/noparse]0]~ ' if object running, mark stopped
cogstop(cog[noparse][[/noparse]0])
Post Edited (Clock Loop) : 2/17/2010 4:08:43 PM GMT
I think both these bugs have to do with how when you look at a clock up close, you can see each high to low.
But when you lower the DIV, eventually that same Pin starts to get smaller, then as you still lower the DIV, that same pin looks entirely different, and almost like a data signal. This is done due to the fact that a computer display has a limited amount of pixels per inch.
Does this happen due to data averaging?
And are the triggers that can be set, reading data that has ALREADY been averaged?
From the looks of all issues I am having, falling trigger and then blanking of the screen, and the CS pulses missing,
It tells me that your looking for the trigger after the data has been averaged, or modified in some way.
But in the case of a CS pulse that has a very short pulse between long periods of nothing, that averaging would do exactly what I am seeing.
It would cause pulses to go missing, and triggers to not work correctly, All depending on the DIV mode used!!!!
I discovered this situation when I was using pattern trigger mode.
You can repeat it by using the same programs above and then going to pattern mode.
1.
-Set Your DIV to 100us
-Set P19 to trigger LOW
-Set P20 to trigger HIGH
See 1.jpg
Notice how everything seems fine.
Trigger working fine.
2.
-Set your DIV to 200us
Notice the flickering. This is the blanking of my screen I was noticing before with my trigger on fall.
The trigger seems to be set to trigger off reduced/averaged screen data, not original data?
Here i suspect its because of the reduction of the pins that switch too fast to be displayed.
If your program looks for triggers BEFORE this reduction of data for the display, the triggering / blanking issue might go away.
But the missing pulses on CS would still exist due to that reduction I suspect.
Another way to squeeze all the data on screen is needed.
Data reduction to fit on screen can be done with a simple rule.
Determine which bit you want to remove, then compare the two bits that surround it.
If the bit you want to remove is in the opposite state of BOTH bits that surround it,
then you need to invert ONE of the bits that surrounds it.
Then you remove the original bit you wanted to remove.
So in these two situations.
101 = 10
and
010 = 01
All other situations, just remove the bit you don't want.
I have no idea if I am on to something here...
Post Edited (Clock Loop) : 2/17/2010 7:59:04 PM GMT
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!
Here is the combined program- basically it:
- uses 1 cog for ViewPort's conduit to share memory with the PC
- uses 1 cog for ViewPort's quicksample object to sample the IO pins at variable frequencies (more about this later)
- uses 1 cog to synthesize a 5MHz square wave signal on pin 19, with a spin loop repeatedly waiting 500uSec and then toggling pin 20 twice in succession
Ok, time for introductions- here is my friend "Nyquist".
Nyquist tells me that in order to accurately measure a signal, I have to sample it at least twice as fast as it is changing: [noparse][[/noparse]url]http://en.wikipedia.org/wiki/Sampling_rate[noparse][[/noparse]/ur]
For example, if I want to sample a 1KHz wave taking a sample every second will do me no good. If I get unlucky, I'll get the same value every measurement- and I would then wrongly report that there was no signal. Sampling that 1KHz signal at 2Ksamples/sec will give me 2 samples/cycle- barely enough to tell that there is a signal. So, moral of the story- you need to sample a signal at the correct rate!
You have two signals- let's start with 5MHz wave on pin 19. A 5MHz signal has a cycle time of 200 nanoseconds! That's quite fast! My buddy Nyquist tells me to sample at least at 10Msamples/sec! When you set the timescale to 100usec or even 200usec, you're almost 3 magnitudes too slow! Try turning the dial to at least 500nsec/div. That will show you 5usec of data- enough for 25 cycles. Turn it even faster to 50nsec/div to see that the signal does indeed take 200nsec (4 divisions) for one cycle.
You're other signal is even harder. You have a long time between transitions (500us), and then a short time for the actual pulse ~10usec. The QuickSample algorithm looks for your trigger, then has to wait for a short time before it can start sampling. In this case, sampling at 50usec/div gives us a good reading. The first pulse that triggered the sampling is not visible, but scrolling to the right reveals the second pulse from 500us to 510usec- and another from 1000 to 1010usec. When we reduce the sampling rate by going to slower than 100us/div the 10us pulse may not even show! 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?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Here's the program I used on my stock DemoBoard with ViewPort v4.27
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
ClockPin = 19
CS = 20
DiagRX = 31
DiagTX = 30
ClockRate = 5_000_000 '5MHz
OBJ
vp : "Conduit" 'transfers data to/from PC
qs : "QuickSample" 'samples INA continuously in 4 cog to 80mhz
ClockGen : "Synth"
VAR
long cogon, cog, pile[noparse][[/noparse]1000]
pub demo|frame[noparse][[/noparse]1600],ctr
vp.register(qs.sampleINA(@frame,4)) 'sample INA with 4 cog up to 80Mhz
vp.config(string("var:io,ctr(min=0,max=15)"))
'share memory with ViewPort, io,ctr. Ctr's range is 0-15.
vp.config(string("lsa:view=io,timescale=1ms"))
'View io with a timescale of 1ms with the lsa graph
vp.config(string("start:lsa"))
'Start in lsa mode
vp.share(@ctr,@ctr)
'Share ctr
start
repeat
PUB start
stop
cogon[noparse][[/noparse]0] := (cog[noparse][[/noparse]0] := cognew(ClockOut, @pile[noparse][[/noparse]0]) > 0) ' 2 cogs
PUB Clockout
dira[noparse][[/noparse]CS]~~
ClockGen.Synth("A",ClockPin, ClockRate) 'Synth({Counter"A" or Counter"B"},Pin, Freq)
Repeat
!outa[noparse][[/noparse]CS]
'Assuming that a 80 MHz core clock is being used, 800,000 cycles is about 10 ms (1/100th second) of time.
'waitcnt(800 + cnt) 'Wait for 10us -100 khz
'waitcnt(8_000 + cnt) 'Wait for 100 us -10 khz
'waitcnt(80_000 + cnt) 'Wait for 1ms -1000 hz
'waitcnt(800_000 + cnt) 'Wait for 10 ms -100 hz
'waitcnt(8_000_000 + cnt) 'Wait for 100 ms -10hz human reaction speed
'waitcnt(80_000_000 + cnt) 'Wait for 1000 ms -1hz
!outa[noparse][[/noparse]CS]
'waitcnt(800 + cnt) 'Wait for 10us -100 khz
'waitcnt(8_000 + cnt) 'Wait for 100 us -10 khz
'waitcnt(40_000 + cnt) 'Wait for 500us
waitcnt(38_636 + cnt) 'Wait for 500us ***adjusted for spin loop***
'waitcnt(80_000 + cnt) 'Wait for 1ms -1000 hz
'waitcnt(800_000 + cnt) 'Wait for 10 ms -100 hz
'waitcnt(8_000_000 + cnt) 'Wait for 100 ms -10hz human reaction speed
'waitcnt(80_000_000 + cnt) 'Wait for 1000 ms -1hz
PUB stop
'' Unload timer object - frees a cog
if cogon[noparse][[/noparse]0]~ ' if object running, mark stopped
cogstop(cog[noparse][[/noparse]0])
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Humanoido
Posts: 5,770
Comments
Here is a forum post that talks about what you want.
forums.hannoware.com/viewtopic.php?f=4&t=137&sid=9413ae2cb1e1474f4f66ebd142ddf0e0
I installed Viewport and played for a day when I had the time so I could get a bit familiar. But when I really needed to take it for a debugging spin, it had already expired. So I don't know much about its real life capabilities.
I think rather than a timed evaluation period, a usage evaluation period would be more practical for busy people.
I'd love to experiment with it more than once to get a feel for its capabilities. Finding play time more than once a month can be difficult! So I wonder if it would work for me, but I'm not willing to pay the price to find out that it doesn't.
..steve
The best part is if you decide that the software is really not your cup of tea, it never actually polluted your system with anything.
Software that puts Smile all over your system (dll's, registry entries, .ini files, hidden garbage) and does not remove 100% of it when you uninstall is one of the huge reasons Windows turns into a pile of goo over a year or two..
Virtualbox is free and fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
They should switch to a "number of times the program runs" or something on the trial, instead of days.
Post Edited (Clock Loop) : 2/18/2010 4:17:23 AM GMT
I'm terribly sorry that I overlooked your post.
Thankfully, the bug was fixed in 4.27- please update to the latest here: hannoware.com/viewport/updates.php
I do my best to keep all my customers happy- currently all 76 threads on my forums have ended successfully...
I'll investigate "usage" based trials- although I would prefer to spend time working on new features...
Back to the original question-
Yes, as long as your timing constants are set correctly, ViewPort will work and use the right timescale for showing your signals. I use it up to 106MHz. The PropScope runs at 100MHz. Sapieha has run up to ~120MHz...
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
Thanks for taking notice of this posting and for your total support.
Absolutely total congratulations on resolving all 76 threads on your
forums, which is a great accomplishment and shows your dedication
to this product.
humanoido
I have no problems to run ViewPort with any frequency.
I RUN it with both 100MHz and frequencies upp to 120MHz without problems.
Stable in all communication speeds.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Thanks. This knowledge is very helpful.
BTW, congratulations on your successful experiments
in running the Propeller chip at enhanced frequencies.
This has helped many of us squeeze out more power
from an already powerful Propeller chip.
humanoido
Thanks, I am up and running now!
One quick question. Some of the program tutorials have schematics written in the info area of the spin file.
But I can't decrypt what is going on. I have attached an image.
Also in that image....
(that clock setting of _clkmode = xtal1 + pll16x with _clkfreq= 80_000_000 )
pll16x mode??
Post Edited (Clock Loop) : 2/18/2010 4:18:24 AM GMT
You can specify either one but not both. I prefer _xinfreq.
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
OOOOPS. I was mixing _clkfreq with _xinfreq...
heh details.. details..
in the prop manuall...
Back to the skeematic. I still don't see what its trying to show..
so I ran CHARMAP and loaded up the PARALLAX font, and looked at the very bottom.
I then copied some of the schematic symbols and put them into the propeller tool.
Propeller Charge Pin ───┬──┬────┐ 10K Resistor  │ │ 10M Resistor │  │ Unknown Capacitor │ │  Propeller Gnd Pin10K ───┘ │ │ Propeller Gnd Pin10M ──────┘  Ground▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
You need to force saving as UTF-16 for the Propeller Tool to cope with Unicode. Easiest way would be to load the files in an editor that understands both and lets you force saving as UTF-16.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Also does the INFO button do anything?
I keep pressing it.. somewhere something is turning on and off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Computers are microcontrolled.
Robots are microcontrolled.
I am microcontrolled.
SX Spinning light display·
http://designedbymemicros.blogspot.com/
The $29 version of ViewPort does not include an integrated code editor or visual spin code debugger. The other's do. You can upgrade your license key here: hannoware.com/viewport/upgrade.php Cost is the same as if you had bought everything together in the first place.
The "code" view let's you view your code- but most importantly it let's you debug your code just like "visual studio"- letting you click on a line to set a breakpoint, step over lines of code, and watch what your program is doing: profiler, memory map, pin status. You can also "animate" your program with the interpreter. Or hover over a variable in your code to see it's value and then change it...
I'm very happy with the debugging functionality, but have recently spent a decent amount of money on a full-blown professional code editor- I'm integrating that into ViewPort now. That'll bring high-end editing features to SPIN, PASM and C...
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 am using Ver 4.2.7 Beta.
On the left side of the Viewport welcome screen, there is a "View Code" button. This will bring up the Propeller Tool and open whatever tutorial program is highlited.
Next to the "Welcome" tab on the top is a tab called "code". This will open the code in Viewport. The formatting is a little better in this view.
Jim
PS I'm not sure what the "Info" button does. I thought it was there to provide othe info like schematics, but I may be thinking of 12Blocks.
UPDATE: I just saw Hanno posted while I was composing. Post Edited (hover1) : 2/15/2010 9:28:44 PM GMT
People pay for programs that either work(and have most things they need)
or they pay for programs that are buggy but have support or affordable sources available. (one mans bug is anothers triumph)
I like your pricing method, I was able to get started early, even tho I had planned to purchase the dev.
I noticed the bugs I ran into when I first started, turned me off to viewport. Then I noticed that the low speed and low buffer for the student copy I tried out first was so bad it almost looked like I was dealing with a bug.
Viewport has a few bugs in it(mentioned below), but I couldn't tell if the way it looked was due to speed/buffer or a bug. I found most of the things I thought were bugs were due to the slow speed and the low buffer.
When I upgraded to the high speed/buffer, I noticed it started to show me results I was looking for, but now my connection was constantly breaking. I investigated it, and found the *mentioned below* speed limitations depending on your electronic LAYOUT.
In electrical noisy conditions 1mbps mode seems to work best.
Speeds below that seem to trigger bugs in viewport its self. (but i can't be sure if its speed based or license based)
I did find bugs in LSA mode and will discuss them in detail below.
Does the developer kit just let you do viewport interface and plugin designing?
I would like to be able to create exe files from my custom viewport configurations(if I had the dev kit)
The point being, one could create a "shell" that you run a single viewport tab in that does nothing else but what that tab was designed to do. Perhaps yet another addon to be considered. Field deployable interfaces.
I have noticed an issue with LSA mode and this code.
I have my prop looking at a 3 mhz clock(I/O-19), a CS(I/O-20) line that is around 400hz, and a few other lines that have some 20mhz pulses.
When I run the code below, I set my trigger on the CS line to be a falling edge in viewports the lsa bit mode, and it shows the attached image named BAD I noticed the correct capture shows up once in a while if I just let it run, but its every 30 seconds or so. Right when I SET the trigger on falling edge, it quickly flashes the correct bitstream (see good image) but then it quickly switches to the BAD image.
I can record the entire process to repeat the bug using a desktop recorder if you need.
I have also attached an image that says, error1, in this image you can see that the data is showing up(again, it just flickers and then goes to the bad blank image), but now the data its self is showing up on the incorrect lines, you can see the TX now on line 22, not 30, like in the good image. I am still in bit mode triggering on the CS line falling edge. I have no idea why it all shifted up, thats how bugs are. One causes another. You can see in the error1 image that my CS line also shifted up to line12 (was on 20), and my clock is on line 11(was on 19).
Below, it says it detected the trigger, so it must be a viewport graphic/data alignment/refresh issue.
One thing to mention is that I do use dual displays. But the same thing happens on either display.
I can run the same test on a vista machine with a single display, if needed.
Is that status message the last message? What is the memory count?
Perhaps the message should erase its self after the expired lot of time is up?
Its hard to know if the reason your not seeing anything properly is due to viewport bug or due to lockup on prop.
For instance, if I just reset the prop while its bursting data out to viewport,
viewport will act like nothing happened to the prop, and it just sits there looking for the trigger, not even knowing the prop just died.
My usb device was never disconnected, so it shows the connection still at 2000kbps.
The VAL stops updating too, but the viewport program knows nothing.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ vp : "Conduit" 'transfers data to/from PC qs : "QuickSample" 'samples INA continuously in 4 cog to 80mhz pub demo|frame[noparse][[/noparse]1600],ctr vp.register(qs.sampleINA(@frame,4)) 'sample INA with 4 cog up to 80Mhz vp.config(string("var:io,ctr(min=0,max=15)")) 'share memory with ViewPort, io,ctr. Ctr's range is 0-15. vp.config(string("lsa:view=io,timescale=1ms")) 'View io with a timescale of 1ms with the lsa graph vp.config(string("start:lsa")) 'Start in lsa mode vp.share(@ctr,@ctr) 'Share ctrPerhaps I should start posting in your forums now.
A bit of a note for other users or potential users of viewport.
I had trouble with viewport and running it in any highspeed mode with my prop on a breadboard,
the only way i am able to get it to work in 2mbps mode(and sometimes 1mbps mode) is to use a prop-plug that is directly connected to the prop with very little in between. See my breadboard setup image: breadboard
I HAVE noticed that if you use a 10k pull down resistor on high speed serial communication, it helps the stability. I have noticed that I was able to increase my prop to prop baud from 115200 to 300000 using the simple fullduplexserial object and 10k pull down's on both rx.
I have also noticed this stability when using FTDI prototype devices such as the one shown in my image: breadboard. you can see the DUALPORT ftdi device to the left, and the propplug to the right.
Breadboarded like this, the dual port FTDI device can do 1mbps with no issues with connection to viewport.
But if you use the propplug very close to the prop like I have done, you can get 2mbps.
My power supply is an isolated 5v supply with a ldo3.3v regulator. I do not have a ground loop because my 3.3v supply is isolated, something that many people overlook.
If I didn't have an isolated supply, i would use my usb's 5v supply with a ldo3.3v regulator to power my prop and circuit,
usb is limited tho, so use caution.
Post Edited (Clock Loop) : 2/18/2010 4:23:27 AM GMT
Thanks for the long post. I'm glad you like my pricing method. I work on my Propeller projects (PropScope, ViewPort, 12Blocks) full-time and it's great to see people valuing my work. I highly prefer to work on improving the product rather chasing the elusive goal of becoming hacker-proof.
As I mentioned above, I'm proud that to date I've helped everyone who has contacted me to be successful with ViewPort- looks like now is your turn.
I added the ability to select baud-rates to cover special situations like yours. On most machines people are able to get a good 2Mbps connection to their ProtoBoard/DemoBoard- where electrical interference is minimized with very short, grounded connections between the Propeller and the FTDI chip. The default rate of
1Mbps connection should work on all PC's and is better suited for breadboarded projects. People with wireless, or even less stable breadboarded projects use the 115kbps setting. The speed setting shouldn't cause any bugs- the update rate should just decrease.
I notice in your screenshots that you switched from the default 1mbps to 2mbps- can you try setting it back to 1mbps? ViewPort does do some error checking on the received signal, but is unable to detect some types of electrical noise. This could explain why your bit traces shift (as shown in "error1") as well as the short signals (in "bad").
You talk about a status/error message: "Is that status message the last message? What is the memory count?Perhaps the message should erase its self after the expired lot of time is up?" I didn't see this in your screenshots... Could be ViewPort trying its best to tell you about a corrupted transmission?
Maybe someone with more experience in high-speed analog transmission can guide us on the proper way to terminate rs232 signals? Again, I haven't seen any such problems on ProtoBoard/DemoBoard...
Hanno
ps: The current development tools let you create "add-ons" and "plug-ins". Add-ons are full programs that interface with ViewPort via DDE. Plug-ins are DLL's that are run within ViewPort. Good idea on "field deployable interfaces".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 am going to support you also, because I think you are absolutely on the right track with this program.
I am a big user of the logic tools, and this one is mission critical for me right now.
I see this program could potentially help me heavily, but I can't get this first thing to work, which is just trying to use the prop to look at logic signals that a datasheet cannot be found for. So I can figure out the communication scheme of this particular device.
It has a 3mhz clock, a CS, and 3 other data lines. It seems the only trigger mode I have major issues with is the trigger on fall. (in both bit mode and pattern mode)
Rise trigger works, so does trigger "high" or "low" in the pattern mode.
I noticed if I look at the signal on CS and choose trigger on rise, depending on the division mode I have set, my CS pulse will disappear, or show up in wrong timing spots. And other div/sec modes make the repetitive cs pulse not show as repeating, or not show up at all. And other modes move the cs pulse to different spots on the time scale, spots that don't match up with the previous time scale. For instance when I choose trigger high on cs line in 1ms mode, the pulse shows up around 10msec. But then if I choose 500us mode, the CS pulse shows up around 5msec AND 10msec, but nothing after that. Then if I go farther to 200us mode, the CS pulse shows up around 14.8msec, the 5 and 10msec pulses are now missing. If I try 2ms mode the CS pulse at 10msec is missing, and shows up no where. But it says its triggered on signal through all this.
See image attachments.
So depending on the DIV/SEC that I choose, that will determine if the pulses that are being detected (triggered) are going to show up graphically or not. (again the CS pulse IS triggering, but will show the pulse at different times depending on the DIV/SEC mode I choose.
I have used a few lsa's and found that the correct response when you choose a different div/sec mode is for you to see the same pulse that your triggering on in the same spot, but more or less detail about the duration of that pulse. The pulse should not be jumping from 10ms, to 5ms, then to 14ms depending on my div setting. Nor should it be show a single pulse, and then 2 pulses, and then none when i change the div setting.
I can start using a screen recording tool so you can see this, in real time if you think it would help.
this is just too much stuff to try to type and hope that my issue is being conveyed.
I am missing pulses because that CS line has a consistent repeat rate, but viewport will not show this. It will usually only show the first pulse and not the subsequent ones after it.
I suspected that my CS pulse was not consistent and repeating, so I tried to use 10ms or 20ms or 50ms and those don't show any pulse at all on my cs line, but the "triggered on signal" is showing and the display is updating. (i can tell by the serial data and the jitter on my 3mhz clock that I am triggering)
So it can't be a weak signal.
I tried 1megbaud on an xp machine with dual displays, and a vista machine with a single display, and found that I cannot trigger properly on fall. I tried 115200 baud mode and saw that the same thing happens, it triggers on the fall, but then quickly disappears, but this time it took longer to disappear in the 115200 baud mode. Once it disappeard in 115200 baud mode it dosen't show back up again.
The speed of the trigger on fall and the display being blanked out shortly after is dependent on baud speed.
Note that other trigger modes do not do this at all. So its likely not an issue with the baud. Higher baud rates would cause program loops to increase which would explain why the lower baud took longer to manifest the blank bug.
Ya know so far ALL of my issues have been with the LSA and particularly with the graphing of the logic data, and the time/div scale. Oddities show up even when just changing the div/sec dial also. I'd like to blame it on my system, but when moving to a vista system that is entirely offline, same results show up.
I was just staying that it would be nice to have a count since last trigger so one could see if they are triggering at a specific timing rate. Right next to Waiting for trigger, put a number that shows how much time has elapsed since last trigger. This will help people see if they are missing triggers or if the data being displayed is incorrect, or if they are in fact not triggering, they will notice by the count.
Attached images are:
-good cs pulse at 5ms in 100us mode.jpg (all of the DIV modes should show this)
-good 5ms And 10ms CS pulse in 500us Mode.jpg (all of the DIV modes should show this)
-good CS pulse at 10ms in 1ms Mode but Missing the 5ms pulse.jpg
-Missing5msCSpulse.jpg -200us mode
-Missing10msCSpulse.jpg -200us mode
5 and 10ms CS pulses missing in 200us Mode
The only pulse found was at 14.8ms in 200us Mode
The trigger on fall screen blanking issue does not change in any situation of the DIV mode, its always the same.
But the pulse missing and the pulse position misalignment are issues that change depending on the DIV mode.
I still see pulses missing and pulse position issues with higher div modes also, the 5ms mode shows no pulse at 5ms or 10ms.
No mode shows pulses every 5 ms like they all should.
Just to make sure its not my signal, I will take another prop,
and generate the same signals as my cs line and do the same thing to verify my issue is not signal.
Post Edited (Clock Loop) : 2/18/2010 4:27:30 AM GMT
A 5mhz clock(P19), and a Pulse(P20) with a low time of 500us and the high time is toggled as fast as spin can toggle a pin on and off.
Attached are 5 images all at different DIV modes as labeled.
The images show exactly what is wrong when you read the spin program I attached.
The spin program attached continually generates two signals, one 5mhz and the other a pwm described above.
Note how in the images that show multiple pulses, pulses are totally missing, and the pulses that are missing depends on your DIV setting.
I understand a 10 us pulse cannot be shown in detail on a very high DIV setting, but its very important to show every pulse,
even if it looks like a mess, a.k.a the PIN will look like a barcode because the pulses are smashed together.
I have 2 props running, one runs the clock program, and the other runs the LSA.
P20 on clock prop goes to P20 on LSA
P19 on clock prop goes to P19 on LSA
This is the code on the LSA prop.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ vp : "Conduit" 'transfers data to/from PC qs : "QuickSample" 'samples INA continuously in 4 cog to 80mhz pub demo|frame[noparse][[/noparse]1600],ctr vp.register(qs.sampleINA(@frame,4)) 'sample INA with 4 cog up to 80Mhz vp.config(string("var:io,ctr(min=0,max=15)")) 'share memory with ViewPort, io,ctr. Ctr's range is 0-15. vp.config(string("lsa:view=io,timescale=1ms")) 'View io with a timescale of 1ms with the lsa graph vp.config(string("start:lsa")) 'Start in lsa mode vp.share(@ctr,@ctr) 'Share ctrThis is the program that is running on the clock prop.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 ClockPin = 19 CS = 20 DiagRX = 31 DiagTX = 30 ClockRate = 5_000_000 '5MHz OBJ ClockGen : "Synth" VAR long cogon, cog, pile[noparse][[/noparse]1000] PUB start stop cogon[noparse][[/noparse]0] := (cog[noparse][[/noparse]0] := cognew(ClockOut, @pile[noparse][[/noparse]0]) > 0) ' 2 cogs PUB Clockout dira[noparse][[/noparse]CS]~~ ClockGen.Synth("A",ClockPin, ClockRate) 'Synth({Counter"A" or Counter"B"},Pin, Freq) Repeat !outa[noparse][[/noparse]CS] 'Assuming that a 80 MHz core clock is being used, 800,000 cycles is about 10 ms (1/100th second) of time. 'waitcnt(800 + cnt) 'Wait for 10us -100 khz 'waitcnt(8_000 + cnt) 'Wait for 100 us -10 khz 'waitcnt(80_000 + cnt) 'Wait for 1ms -1000 hz 'waitcnt(800_000 + cnt) 'Wait for 10 ms -100 hz 'waitcnt(8_000_000 + cnt) 'Wait for 100 ms -10hz human reaction speed 'waitcnt(80_000_000 + cnt) 'Wait for 1000 ms -1hz !outa[noparse][[/noparse]CS] 'waitcnt(800 + cnt) 'Wait for 10us -100 khz 'waitcnt(8_000 + cnt) 'Wait for 100 us -10 khz 'waitcnt(40_000 + cnt) 'Wait for 500us waitcnt(38_636 + cnt) 'Wait for 500us ***adjusted for spin loop*** 'waitcnt(80_000 + cnt) 'Wait for 1ms -1000 hz 'waitcnt(800_000 + cnt) 'Wait for 10 ms -100 hz 'waitcnt(8_000_000 + cnt) 'Wait for 100 ms -10hz human reaction speed 'waitcnt(80_000_000 + cnt) 'Wait for 1000 ms -1hz PUB stop '' Unload timer object - frees a cog if cogon[noparse][[/noparse]0]~ ' if object running, mark stopped cogstop(cog[noparse][[/noparse]0])Post Edited (Clock Loop) : 2/17/2010 4:08:43 PM GMT
But when you lower the DIV, eventually that same Pin starts to get smaller, then as you still lower the DIV, that same pin looks entirely different, and almost like a data signal. This is done due to the fact that a computer display has a limited amount of pixels per inch.
Does this happen due to data averaging?
And are the triggers that can be set, reading data that has ALREADY been averaged?
From the looks of all issues I am having, falling trigger and then blanking of the screen, and the CS pulses missing,
It tells me that your looking for the trigger after the data has been averaged, or modified in some way.
But in the case of a CS pulse that has a very short pulse between long periods of nothing, that averaging would do exactly what I am seeing.
It would cause pulses to go missing, and triggers to not work correctly, All depending on the DIV mode used!!!!
I discovered this situation when I was using pattern trigger mode.
You can repeat it by using the same programs above and then going to pattern mode.
1.
-Set Your DIV to 100us
-Set P19 to trigger LOW
-Set P20 to trigger HIGH
See 1.jpg
Notice how everything seems fine.
Trigger working fine.
2.
-Set your DIV to 200us
Notice the flickering. This is the blanking of my screen I was noticing before with my trigger on fall.
The trigger seems to be set to trigger off reduced/averaged screen data, not original data?
Here i suspect its because of the reduction of the pins that switch too fast to be displayed.
If your program looks for triggers BEFORE this reduction of data for the display, the triggering / blanking issue might go away.
But the missing pulses on CS would still exist due to that reduction I suspect.
Another way to squeeze all the data on screen is needed.
Data reduction to fit on screen can be done with a simple rule.
Determine which bit you want to remove, then compare the two bits that surround it.
If the bit you want to remove is in the opposite state of BOTH bits that surround it,
then you need to invert ONE of the bits that surrounds it.
Then you remove the original bit you wanted to remove.
So in these two situations.
101 = 10
and
010 = 01
All other situations, just remove the bit you don't want.
I have no idea if I am on to something here...
Post Edited (Clock Loop) : 2/17/2010 7:59:04 PM GMT
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!
Here is the combined program- basically it:
- uses 1 cog for ViewPort's conduit to share memory with the PC
- uses 1 cog for ViewPort's quicksample object to sample the IO pins at variable frequencies (more about this later)
- uses 1 cog to synthesize a 5MHz square wave signal on pin 19, with a spin loop repeatedly waiting 500uSec and then toggling pin 20 twice in succession
Ok, time for introductions- here is my friend "Nyquist".
Nyquist tells me that in order to accurately measure a signal, I have to sample it at least twice as fast as it is changing: [noparse][[/noparse]url]http://en.wikipedia.org/wiki/Sampling_rate[noparse][[/noparse]/ur]
For example, if I want to sample a 1KHz wave taking a sample every second will do me no good. If I get unlucky, I'll get the same value every measurement- and I would then wrongly report that there was no signal. Sampling that 1KHz signal at 2Ksamples/sec will give me 2 samples/cycle- barely enough to tell that there is a signal. So, moral of the story- you need to sample a signal at the correct rate!
You have two signals- let's start with 5MHz wave on pin 19. A 5MHz signal has a cycle time of 200 nanoseconds! That's quite fast! My buddy Nyquist tells me to sample at least at 10Msamples/sec! When you set the timescale to 100usec or even 200usec, you're almost 3 magnitudes too slow! Try turning the dial to at least 500nsec/div. That will show you 5usec of data- enough for 25 cycles. Turn it even faster to 50nsec/div to see that the signal does indeed take 200nsec (4 divisions) for one cycle.
You're other signal is even harder. You have a long time between transitions (500us), and then a short time for the actual pulse ~10usec. The QuickSample algorithm looks for your trigger, then has to wait for a short time before it can start sampling. In this case, sampling at 50usec/div gives us a good reading. The first pulse that triggered the sampling is not visible, but scrolling to the right reveals the second pulse from 500us to 510usec- and another from 1000 to 1010usec. When we reduce the sampling rate by going to slower than 100us/div the 10us pulse may not even show! 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?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 ClockPin = 19 CS = 20 DiagRX = 31 DiagTX = 30 ClockRate = 5_000_000 '5MHz OBJ vp : "Conduit" 'transfers data to/from PC qs : "QuickSample" 'samples INA continuously in 4 cog to 80mhz ClockGen : "Synth" VAR long cogon, cog, pile[noparse][[/noparse]1000] pub demo|frame[noparse][[/noparse]1600],ctr vp.register(qs.sampleINA(@frame,4)) 'sample INA with 4 cog up to 80Mhz vp.config(string("var:io,ctr(min=0,max=15)")) 'share memory with ViewPort, io,ctr. Ctr's range is 0-15. vp.config(string("lsa:view=io,timescale=1ms")) 'View io with a timescale of 1ms with the lsa graph vp.config(string("start:lsa")) 'Start in lsa mode vp.share(@ctr,@ctr) 'Share ctr start repeat PUB start stop cogon[noparse][[/noparse]0] := (cog[noparse][[/noparse]0] := cognew(ClockOut, @pile[noparse][[/noparse]0]) > 0) ' 2 cogs PUB Clockout dira[noparse][[/noparse]CS]~~ ClockGen.Synth("A",ClockPin, ClockRate) 'Synth({Counter"A" or Counter"B"},Pin, Freq) Repeat !outa[noparse][[/noparse]CS] 'Assuming that a 80 MHz core clock is being used, 800,000 cycles is about 10 ms (1/100th second) of time. 'waitcnt(800 + cnt) 'Wait for 10us -100 khz 'waitcnt(8_000 + cnt) 'Wait for 100 us -10 khz 'waitcnt(80_000 + cnt) 'Wait for 1ms -1000 hz 'waitcnt(800_000 + cnt) 'Wait for 10 ms -100 hz 'waitcnt(8_000_000 + cnt) 'Wait for 100 ms -10hz human reaction speed 'waitcnt(80_000_000 + cnt) 'Wait for 1000 ms -1hz !outa[noparse][[/noparse]CS] 'waitcnt(800 + cnt) 'Wait for 10us -100 khz 'waitcnt(8_000 + cnt) 'Wait for 100 us -10 khz 'waitcnt(40_000 + cnt) 'Wait for 500us waitcnt(38_636 + cnt) 'Wait for 500us ***adjusted for spin loop*** 'waitcnt(80_000 + cnt) 'Wait for 1ms -1000 hz 'waitcnt(800_000 + cnt) 'Wait for 10 ms -100 hz 'waitcnt(8_000_000 + cnt) 'Wait for 100 ms -10hz human reaction speed 'waitcnt(80_000_000 + cnt) 'Wait for 1000 ms -1hz PUB stop '' Unload timer object - frees a cog if cogon[noparse][[/noparse]0]~ ' if object running, mark stopped cogstop(cog[noparse][[/noparse]0])▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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