Blog > Code summary

Home Forums ViewPort Code summary

This topic contains 4 replies, has 2 voices, and was last updated by  Hanno .

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #10649

    Anonymous

    Hi Hanno,

    Just starting out with Viewport and PropBasic.

    Bought your "high speed" version, as I found the 115k version was not reliable at displaying the correct characters in the terminal when running code longer than the simple "Bean" demo.

    I have found getting the default parameters set in edit menu sometimes difficult…. and the program can crash sometimes and "forget" or blank out the settings…. Anyhow, I have just started, so will take some time to try and work things out, and then start hounding you with screen-shots and useful diagnostics later !

    As a note for myself too, I noticed it is possible for the licence registration menu to "popup" [u:zqhovdfe]behind[/u:zqhovdfe] an already-open edit/parameters menu. That is a problem, as you cannot minimise the parameters windows when the licence window is also open, nor can you click cancel on the licence window (its hidden by the parameters window!). So taskmanager/process abort is required. It might be a solution to ensure pop-ups that lock out the other windows are always pushed to the top.

    Anyhow, I am writing too much because I am [b:zqhovdfe]so excited about Viewport and PropBasic together![/b:zqhovdfe]

    [u:zqhovdfe]…Today’s question is about "code summary"[/u:zqhovdfe] :)
    Is it possible, or can it be possible, that when I press F8 (or perhaps shift-F8), a window shows a summary of the code after the compile (or failed compile). Something like in the original propeller tool like longs used/free, etc… (At the moment a fail takes me to the .spin code window, I have to click "ok" to refesh the existing spin code loaded, then can see how many longs I am over by.. That is slow too. A shift F8 which just gave a summary and did not have me clicking modal prompts would certainly improve efficiency).

    It would be very helpful, as the VP_ code takes up a fair few longs, and sometimes it is a real challenge to disable parts of code to test other parts within memory constraints. And this quick summary would definately help!

    Also would be nice if another key could toggle on/off ALL the VP_ code (so I mean remove completely before compiling… like a simple rename all from VP_Str to ‘ vp-debug-off VP_Str, and then toggle back again when needed. Of could it should include all the WATCH, BREAK and LOAD commands also in a PropBasic program). As all your methods seem nicely VP_ prefixed, perhaps that could be possible too?

    I hope I could explain these things well. I really really like ViewPort; I hope this is the right place to document my experiences and Ihope it can help!

    All the best, Max.

    #11676

    Hanno
    Keymaster

    Hi Max!
    What a great attitude! I look forward to lots of "suggestions" and will do my best to fix problems and implement new features as you think of them.
    If you can help me reproduce a problem you’ve had by submitting a screenshot, directions, and/or a bit of code, then I can typically fix the issue right away. I’m surprised you’re having problems with the preferences, please let me know what you’re doing.

    I have noticed that sometimes the license menu is hidden behind the main window, but once you’re registered this shouldn’t affect things. It’s a weird windows timing issue but it’ll be fixed asap.

    The Homespun Compiler which I use to compile spin code does give me all the information you’re looking for, VP already parses a log file for error messages, so implementing a "code summary" is very doable.

    ViewPort already gives you the option to "run with viewport support", or "run with no viewport support". This get’s passed to Bean’s PropBasic compiler which should ignore all "vp_" calls when you’re telling it not to use vp. I’ll chat with Bean about current status of that.

    Hanno

    #11675

    Anonymous

    Hi Hanno,

    I am using the Beta version 4.6.7.

    Hopefully you can re-create the licence issue this way:

    1. Edit / Program perfs (PP) / Reset defaults.
    2. Close PP windows, and DO NOT immediately open it again… :)
    3. Popup window will show licence is 288 days past 30 days limit ! If you had the PP window open here, you would be in trouble!
    4. Enter email & licence code, click register. All ok.
    5. Try to use Run_Diag,… maximum speed only 115k. Restart program, same. Noticed that even if I change the speed in PP, it always sticks at PP. So I guess my high-speed licence not recognised yet.
    6. OK, Help / REgister licence, enter again the email/licence code.
    7. OK, 2nd time round its ok. debug speed can be up to 1Mb/s

    Another thing.

    1. Open PP and change the buffer size from Auto to 1000, click OK
    2. Open PP again. Mine is all blank, and I need to do the procedure above!

    Finally, the VP switch you mentioned sounds just the ticket! That would be great to leave the VP code intact and just compile a version for production use that ignores all the debug symbols. Anytime in the future I want to go back and debug the code, it will be ready for me!

    Would be even better if we could "compile to eeprom image" also! You know, the 32Kb .eeprom file format that proptool produces.

    I am having some head-banging moments getting used to a few things at the moment… The overhead of the VP code is an issue for larger programs, especially where timing is an issue and LMM might not be an option. But I can see this is the way forward, and perhaps if the WATCH / BREAK debugging could work later, then that might solve it as I would not need to insert memory-heavy VP_Str statements everywhere!

    I also noticed the VP_Str uses all the __paramx variables, so I have implemented a new set of "subtmpx" variables for my own code, so that VP_x does not mangle things. That’s a little gotcha that perhaps should be in the user guide!

    One thing I’m not getting yet is how to get the WATCH values to appear in the viewport console. Especially if I have (for example) an rxBuffer byte (100) … should it be possible to see (in viewport) the ascii-string or hex-string contents of this buffer at all times? So say I SERIN "HELLO" to a HUB variable rxBuffer, can I see "HELLO" in viewport?

    Maybe that is what the BREAK in the program to pause execution would be need for, to allow viewport to refresh with the latest value and wait until I had a chance to read it? … Actually, sometimes a BREAK might be ideal, but othertimes NOT ideal as it might affect program flow…. maybe a third command is needed "LOG", which would log all the current watch values to the VP_terminal (or some other window) perhaps with date/time prefixed, but not break the program flow. Then this "log" window would show all the history, and that might also solve having loads of individual "memory-consuming" VP_Str statements throughout the code. Perhaps the LOG format would be: date/time, IO integer (representing IO pin states), watched variable values

    OK, one more…

    I really like the option to just your "WATCH", and thus watch everything. However, if you have a rxBuffer(16384), then an error appears! Something like > 4091 watched values. Is there someway around this… maybe to watch only a selected portion of the buffer? (WATCH rxBuffer 0:1000)

    Well, that’s enough for now.. Gotta do some work this morning!

    Thanks again!

    Max.

    #11674

    Anonymous

    one other quick "Gotcha"…

    If you WATCH an rxBuffer HUB BYTE(64), then VP_ seems to override all the values to zero. Remove the Watch on that buffer, and all ok.

    #11677

    Hanno
    Keymaster

    Hi Max,
    Yes, I’ll add ability to output "eeprom" and "binary" images at the same time as code summary. Good idea!
    The rest of your issue seem related to the PropBasic compiler, I’m having Bean look at them. Thanks!
    Hanno

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.