Strange ViewPort operation
HShanko
Posts: 402
On a QuickStart board I can scope that appropriate signals are changing states with an oscilloscope, but ViewPort doesn't display any of the 32 I/Os changing states! How can this happen?
The traces are either high or low; though pin 30 may show some transitions. No triggering ever occurs for any pin selected! Occasionally, say a minute or several later, there might be some activity on-screen, the steady states until a next 'flurry'. I am using rev: 4.6.0. The USB LEDs show activity but no changes occur on screen.
Anyone seen this happen before? The source is below.
LCD_24x1.spin
The traces are either high or low; though pin 30 may show some transitions. No triggering ever occurs for any pin selected! Occasionally, say a minute or several later, there might be some activity on-screen, the steady states until a next 'flurry'. I am using rev: 4.6.0. The USB LEDs show activity but no changes occur on screen.
Anyone seen this happen before? The source is below.
LCD_24x1.spin
spin
12K
Comments
as the red message "wait for triggering" was showing up again. I changed the io-pin that does the triggering from pin no 8 to pin no 0
vp.config(string("lsa:view=io,timescale=50ms,trigger=io[0]r")) 'after that the lsa-view gets updated because this pin is really toggling.I connected pin 8 to an led on my PPDB but the LED stays dark ==> no toggling at all.
I'm no expert about ViewPort. But I guess the lsa-screen gets only updated when a full set of samples
is made. Collecting the samples seems to depend on the trigger-pin to really trigger.
@Hanno: you should add a possabiity to have an auto-sample-mode that does not depend on any IO-pin-triggering
but just on the timebase of the big knob inside viewport
@Hanno: I re-read the help-text on triggering. This help-text suffers from expert-blindness for beginner-difficulties.
I read the auto-trigger option but I'm left with the question how does the configure string look like for auto-triggering?
I can start fiddling around trying different versions. But that's bad supportstyle.
Please add explicit written examples for all three trigger-types including diagrams showing the trigger-condition over time with arrows that show when the triggering occurs
This leads me to another idea how ViewPort can be improved
please add a feature that shows the logic status of all pins a simple points like PASD.
This will give an easy way to check if a IO-pin does change his logical state at all.
keep the questions coming
best regards
Stefan
And yesterday I measured all the timing for the init_LCD PUB. Next time I fired it up I couldn't get it to Load. This morning it just presented a static screen. Yet a scope shows all the active I/Os. Hate such 'head scratching'. Mystery time, but don't enjoy this sort of mystery. Maybe something got 'broke'. Maybe the cats were trying to 'help' me debug a few things!
To state the obvious: did you re-load the changed code to the EEPROM with configure-string set to trigger on io-pin 0
Is the plot-option in ViewPort lsa-view set to "io"? I get a frozen screen too if its set to "cntDn" or "chr"
Do the values shown in the "val" columm change?
keep the questions coming
best regards
Stefan
Maybe I need to back out of Windows and Parallels, and start anew. Don't know if it is a Windows thing, or ??? If it can find the Prop, Load, Configure and then Run but display nothing but a static screen, that is quite strange. On the right it does show the 'io' is changing state. If it can see the I/Os, why not be able to display. More testing....
Fortunately, yesterday things were working OK and I was able to verify the LCD initialization was working properly. The values transferred and timing looked good. Have been unable to get any display on the 24 x 1 LCD. Happy the init code ran as expected. Did some cleanup after that, which shouldn't have changed VP any.
The code basically only initializes the LCD, and presents the 256 bit down counter to the quickStart board LEDs. Thus I know the Spin code is working fine. But ViewPort just doesn't display what it sees on the I/Os, except for that display of 'io' at the upper right. Hope the 'light bulb' goes off soon. This gets frustrating when simple tasks are held up with 'the tester' not working as expected.
Stefen, you must be 8-9 hours later than here. Your last post must have been quite late. Sleep well.
You posted code that was supposed to trigger on Pin 8 . There is no activity on pin 8 as far as I can tell.
I can disable the trigger and see all signals.
It may be a Mac thing, but works fine on Windows 7 64 Bit.
That is good news, and looks right. Now if only my setup showed the same display
There should be one positive trigger each cycle of the 256 counts. I'll look into that detail. Maybe it was a cat's input via stepping/laying on the keyboard. You mean one has to 'decat' the code also?
best regards
Stefan
waitcnt(MS_001 * 20 + cnt) ' delay about 20 ms
where MS_001 is defined as 80_000_000/1_000. With a stop watch I see the LSA screen (on left side) updating fast about every ~53 seconds. Even if I don't trigger on any I/O!!!
Why doesn't the left side display change, even though the right side ('Overview') is changing rapidly all the time?
What the code is doing is counting down from $FF to $00, then doing an LCD initialization, which is where the 20 ms waitcnt is, If the LEDs on the QuickStart board are displaying the counter, and the 'io' value appears to change along with the LEDs, why no display on the left side of the screen? And again why does ViewPort wait about 53 second to update the LSA display?
How can my code run the 'io' values yet not display those I/O line activity?
By the way, the line OUTA[reset_LCD]~ in PUB initLCD should have been OUTA[reset_LCD]~~. I'd bet when I was cleaning up some formatting with the font of small size for printing, I missed that one '~' got cut out during editing. Had I used OUTA[reset_LCD] := 1 the compiler would have caught the missing '1' on edit.
The source code is basically same as in first post. Thanks for any assistance on this weird problem.
I can't believe this is happening. Like everything is turning to Smile! And that was on two different Prop ProtoBoards.
I still can not comprend how the QuickStart board LEDs continue the countdown yet ViewPort won't display the waveforms. Regardless of any trigger, the waveforms should appear to run across the LSA screen, like lost 'sync' But to see the screen 'update/change' about every 53 second! And yet the 'io' values change at the rate, it appears, at the LED flashing rate. Think I need a vacationn.. Or a padded cell...
Somehow strange but: Please create an archive of your complete code and attach it to a posting.
As it happends on VP4.6 and VP4.5.3 and two different protoboards the probability of a software-bug related to the systemcounter seems high to me.
If I can confirm your results we know it's a propeller-softwarebug in your code. If I can not confirm it this points towards a bug in one of the objects that communicate with ViewPort.i mean
I mean the conduit-object and the quicksample-object.
As Hanno has not posted yet. Write an Email to him including archived objects.
Please also attach the 4bit-counter-example. Use the archive-function of the propeller-tool. Does something change if you turn the timesale-knob to 1 microsecond?
keep the questions coming
best regards
Stefan
Hope you can make some sense of what isn't right. At least not working as expected. As I mentioned, i find it very strange if the values of 'io' appear on the right changing, yet none of the traces displayed o the left are changing. Trigger or no trigger (rising, falling edges, no selection) one should still see something if the I/Os are changing; NO?
If I compile and run the 4bitcounter or your LCD24x1-code with the conduit and quicksample-versions that are stored locally in the folders where I unzipped your archives I get the same results as you.
If I rename the quicksample-files in this folders that ViewPort does not find the local version and then takes the quicksample-sourcecodes from the folder
C:\Program Files\ViewPort\lib\ your code is running.
After that I compared the content of your quicksample-files with mine in the folder C:\Program Files\ViewPort\lib\ I can see substantial differencies between the two codeversions.
So I guess if you make sure that you use always the one and the same conduit.spin and the one and the same quicksample.spin which is delivered with ViewPort and installed to the folder
C:\Program Files\ViewPort\lib\ it will work properly. You don't have to copy these files to our project-folders as ViewPort will search them always in the ...\lib-folder.
I guess copying these files around to project-folders caused this problem.
The only exception I would make is to copy the actual conduit.spin and quicksample.spin to the folder C:\Program Files\Parallax Inc\Propeller Tool v1.3\Library that if you compile the code with the propellertool the files will be found automatically too.
I'm using ViewPort 4.5.3
the fileversion I used were
{***************************************** * ViewPort QuickSample v4.2.1 9/09 * * Adjustable 80 Mhz Sampling of INA * * (C) 2010 HannoWare.com, Inc. *keep the questions comingNow this explains why the value got updated but not the LSA-view. conduit updates the variables.
Quicksample does what its name says. sampling and after collecting a bunch of samples transfering them from the propeller to ViewPort.
I want to add some reflective thoughts about how I did the analysing:
The most important thing is to go back to a system that is well known as running properly (in this case my working version of ViewPort)
If you suspect that windows, the registry, drivers or something similar is the problem this would mean take another PC that runs windows well and is a virgin under the aspect of ViewPort.
Installing Viewport and then testing it with the delivered examplecodes. From that point start varying details. Only one detail at a time. Then do the checking again.
This is the way to surely narrow down the problem. It needs quite a lot effort but it is sure.
Now if you start changing more than one thing or using a modified system the possability to overlook the bug grows. Doing some quick shots that don't need much time makes sense.
But if you don't find it after some quick shots. Quick shooting around will get you even slower to the solution as systematic analysis like described above.
I'm really no expert about viewport. I tryed a certain strategy than can be expressed in a very general way and applied this strategy to this problem: Compare the details of a running system with the buggy system.
best regards
Stefan
Didn't understand about renaming some files. If I recall, when I installed VP rev 4.6.0 and tried to run it, a window came up saying something about no Conduit file in \lib folder. So I just copied what was in the Tutorials folder. I don't understand why a revision download doesn't have everything it needs to run right off.
You showed some comparison of two files. Have no idea why that was done. What did it tell you? I'm pretty lost inside of Windows. I always felt its design was overly complex. Sort of lost in it like I was back in CP/M days.
I'd hoped by re-downloading VP and installing it, that should clear up problems. But didn't.
If you have further suggestions, throw them at me. Not sure what to do right now. I read over your last post several times trying to realize what it meant and what to do.
I realized I'd not done an UNINSTALL before installing VP 4.6.0. Doing the Uninstall and re-installing VP was required. That allowed me to see the 4-bit counter demo to be displayed properly, and the counter running what I recall it should look like. But my LCD_24x1 still wouldn't run right. Looking further into the Tutorials folder I noticed that when the counter demo ran there was no Conduit.spin or QuickSample.spin files in that folder. So moved them out temporarily, and that fixed that ugly problem.
Apparently way back VP needed those files in with the user's programs, maybe? Anyway that was a treat to see my program running again. Apparently one absolutely needs to Uninstall always prior to installing another version. Apologies for creating such a problem. Another Windows lesson to remember; do the Uninstall first. (Seems Macintosh apps automatically do that step when an update/revision/whatever is done; spoils a person)
the SPIN-files conduit.spin and quicksample.spin are nescessary to communicate with ViewPort. Those two files manage the datatransfer from the propeller-chip to your PC running ViewPort.
the archived files LCD_24x1 - Archive [Date 2011.08.20 Time 16.55].zip
and 01_Four Bit Counter - Archive [Date 2011.08.20 Time 17.07].zip
contained an old version quicksample.spin.
This old version of the file Quicksample.spin is incompatible with the ViewPort-version 4.53 and ViewPort-version 4.6
So my recommendation is to search through all your harddiscs and all its partitions to find all files named Quicksample.spin.
Deleting all files named Quicksample.spin. After that copy the attached version of the file quicksample.spin to your " ...\ViewPort\lib"-folder.
If you load code from inside ViewPort to the propeller ViewPort will look automatically into the folder " ...\ViewPort\lib" if the files conduit.spin and Quicksample.Spin are there.
If ViewPort finds the files there it can compile your code. If you never copy these two files to any other folder you make sure that ViePort will always use the files
in the folder " ...\ViewPort\lib" and you have only one place to check if these two files are uptodate.
keep the questions coming
best regards
Stefan
In the early months of VP I was one of the beta-testers and appreciated having this wonderful tool called ViewPort. It was just the tool I needed to view the timing relationships of a board I was working on using two Props.
For some reason I note I can usually get a program running on a Prop ProtoBoard, but get a load problem with QuickStart board. Not sure if that is because the so called '5v' power is closer to 4.88v. So at times I cannot get the QS board running in VP. Programs OK from the Parallax IDE. Runs OK as I can see the LEDs flashing as the count down cycles. I need to look in to see if that 'diode' in series with the '5v' point on the QS board can be shorted out and then run OK. Too many other problems were in the way previously.
Again thanks so much for helping on this problem. Sometimes one stumbles over their own feet, other times is is built into the app until a stable version is created. Lots of work from conception to having a stable version. I appreciated all the effort Hanno put into this neat app.
Thanks Stefan for helping Harley! Great suggestion to test one thing at a time. And looks like you found the culprit- outdated files. FYI-ViewPort, just like the Parallax Prop Tool, installs library files to a library directory- in ViewPort's case: "program files/viewport/lib". You should NOT have separate copies of those files (conduit, quicksample) in other directories- unless you know what you're doing... Sounds like this could be confusing- so I'm thinking of adding a setting which defaults to giving the "lib" directory the highest priority- which would have solved Harley's problem of keeping outdated files in user directories...
Here a couple responses and things I'm hoping will resolve similar problems in the future.
The "trigger" configuration string is optional- when you don't use it, ViewPort will show every sample. However, if you do use it, then ViewPort will wait until that trigger has been met before it takes and shows samples. If you don't want to use the text configuration strings you can click to disable the trigger.
- I'm revising the manual to include more samples- again, to sample without a trigger use a string like this:
vp.config(string("lsa:view=io,timescale=50ms"))
and to use a trigger use this:
vp.config(string("lsa:view=io,timescale=50ms,trigger=io[0]r"))
- I'll look at the possibility always updating the IO pins- even when the quicksample cog is waiting for a trigger.
Hanno
Good to hear from you and of further improvements to ViewPort. A most useful tool for the Propeller. Hope Prop 2 will also have ViewPort (2?),
I always assumed a later version of ViewPort would include the latest versions of the Conduit and QuickSample Spin files. I'm not sure if I've always done an Uninstall before installing a later version. That probably would have left lots of old copies behind, no? And would a newer version of ViewPort run if an older version had not been uninstalled?
Here's the question: Should one create a 'work' folder to place their Spin files rather than any other place? For years now I've been putting my Spin files in the Tutorials folder, as I though was suggeste initially (during beta test days).
What I notice is if I have QuickStart and Conduit Spin files in the 'lib' folder; when I compile the Paralax IDE seems to want those Spin files in the 'work folder in addition. If I create a 'work' folder, will ViewPort and the Parallax IDE like that arrangement, with QuickStart-/Conduit.Spin files there? I thought I'd ask before I try it and find out there is a multitude of other problems by doing that. Sometimes s*it happens.
Thanks for any suggestions. I'd like to create a situation where IF either Parallax IDE or ViewPort later version is installed, there be no problems after4 the update. Maybe with te exception of havinng to install the latest QuickStart or Conduit files in that 'work' folder, regardless of its name. Been wondering about this situation for a log time; thought it long overdue to ask.
When you install a new version of ViewPort, it will install the latest "library" files (quicksample, conduit, etc) into "install path/lib". Typically "install path" will be "program files/viewport"- but you can install multiple versions if you really want. The Parallax compiler is severely limited in that you can't specify include directories- so after asking for this feature for years I've stopped using it in favor of the much better HomeSpun compiler- which does allow multiple include directories. ViewPort sets these to the the Parallax Prop tool library, the ViewPort library, and your current working directory. This means you can put your user files wherever you want. Ideally you should just leave your "viewport library" files in the "viewport/lib" directory- but if you really must use the Propeller Tool- then you'll need to copy those files into either your Propeller Tool library- or your user directory. If you do that- make sure you always update those library files when you install a new version of ViewPort.
Hanno
Thank you for that explanation. I figured it might be something like that, but if it didn't work right it is such a pain to move files around in Windows, for me at least. So had to ask. Thanks for the clear answer.