Shop OBEX P1 Docs P2 Docs Learn Events
PNut/Spin2 Latest Version (v46 - DEBUG gating, clock-setter control, VAR flexibility, C_Z for DEBUG) - Page 52 — Parallax Forums

PNut/Spin2 Latest Version (v46 - DEBUG gating, clock-setter control, VAR flexibility, C_Z for DEBUG)

1495052545565

Comments

  • cgraceycgracey Posts: 14,156

    @wummi said:
    Hi chip,
    It works on my iMac with "download_baud = 1_000_000"
    With 3Mbaud and 2Mbaud it is not working.
    I think that is too much for the VM.

    Super, Wummi!

    Thank you for letting me know.

  • cgraceycgracey Posts: 14,156
    edited 2022-08-26 18:53

    @evanh said:

    @cgracey said:
    ... For now, just set DOWNLOAD_BAUD and it will use the same value for DEBUG_BAUD.

    Okay, I was always setting both the same anyway.

    I do have a slight puzzle with the debug terminal. Can it be used with send() ? I'm trying but failing to print text to the comport using F10 compile + run and with the F12 debug terminal open.

    If you run with debug on and generate serial at the appropriate baud rate, it should appear in the debug window.

  • RaymanRayman Posts: 14,683

    So, one can just send anything they want out the same com port as the debug window? Didn't know that...

  • evanhevanh Posts: 15,969
    edited 2022-08-27 02:33

    @cgracey said:

    @evanh said:

    @cgracey said:
    ... For now, just set DOWNLOAD_BAUD and it will use the same value for DEBUG_BAUD.

    Okay, I was always setting both the same anyway.

    I do have a slight puzzle with the debug terminal. Can it be used with send() ? I'm trying but failing to print text to the comport using F10 compile + run and with the F12 debug terminal open.


    If you run with debug on and generate serial at the appropriate baud rate, it should appear in the debug window.

    Is the baud definable still? I'm using

        DOWNLOAD_BAUD = 230_400
        DEBUG_BAUD = DOWNLOAD_BAUD
    

    but not getting anything showing in the F12 terminal. If I instead use the same program (Pnut's compiled binary) on the Prop2 but Loadp2 to download and monitor then all is good, so I know my serial print routines do work.

    PS: Source code attached

  • evanhevanh Posts: 15,969
    edited 2022-08-27 02:36

    PPS: The main reason I want this ability is because Pnut's proper debug can't handle a change in sysclock frequency. So I'm doing my own print routines with it.

  • roglohrogloh Posts: 5,809
    edited 2022-08-27 05:58

    Has anyone who uses Wine with PropellerTool/Pnut been able to get baud rates over 230kbps working?
    I just installed Wine 5.0 on my Mac (OSX 10.10) and tried with Propeller tool and it has IOCTL issues with rates over 230kbps as shown in the logs below when I was selecting higher baud rates.
    It would be nice to have this working in order to use the debugger at high speeds.

    Also if anyone wants to use Wine for PropellerTool and even see the serial port under Wine on a Mac, you may have to follow this..
    https://www.downtowndougbrown.com/2013/03/getting-x-ctu-in-wine-to-detect-your-serial-ports/
    I found that the typical way to map a USB serial port just by creating a symlink to COM1 and a single registry entry itself was insufficient, and required following these extra steps mentioned. I think this is due to the way PropellerTool is iterating through serial ports.

    002e:err:comm:set_baud_rate baudrate 1000000
    002e:fixme:ntdll:server_ioctl_file Unsupported ioctl 1b0004 (device=1b access=0 func=1 method=0)
    002e:err:comm:set_baud_rate baudrate 1500000
    002e:fixme:ntdll:server_ioctl_file Unsupported ioctl 1b0004 (device=1b access=0 func=1 method=0)
    002e:err:comm:set_baud_rate baudrate 2000000
    002e:fixme:ntdll:server_ioctl_file Unsupported ioctl 1b0004 (device=1b access=0 func=1 method=0)
    002e:err:comm:set_baud_rate baudrate 921600
    002e:fixme:ntdll:server_ioctl_file Unsupported ioctl 1b0004 (device=1b access=0 func=1 method=0)
    002e:err:comm:set_baud_rate baudrate 460800
    002e:fixme:ntdll:server_ioctl_file Unsupported ioctl 1b0004 (device=1b access=0 func=1 method=0)
    002e:err:comm:set_baud_rate baudrate 250000
    
  • Also getting this result too (in PropTool) - I think it might be because the IOCTL is failing.


  • roglohrogloh Posts: 5,809
    edited 2022-08-27 06:19

    With PNut v35u I have even worse problems...it freezes with this after selecting Get Hardware Version from the Run menu:

    Output from Wine:

    RLs-MacBook-Pro:install roger$ wine PNut_v35u.exe
    0009:err:comm:set_baud_rate tcsetattr error 'Invalid argument'
    

    UPDATE: seems to work better if I build a file with DOWNLOAD_BAUD and DEBUG_BAUD at 115200bps first. It will detect the P2 then.

  • evanhevanh Posts: 15,969

    Pnut 35u on Wine 7.15 on Linux seems to be okay with all those. Even 3 Mbaud download/debug works surprisingly. No errors.

  • evanhevanh Posts: 15,969
    edited 2022-08-27 13:09

    @rogloh said:
    Also if anyone wants to use Wine for PropellerTool and even see the serial port under Wine on a Mac, you may have to follow this..
    https://www.downtowndougbrown.com/2013/03/getting-x-ctu-in-wine-to-detect-your-serial-ports/

    That made a difference but Proptool is still no go.

    Before adding that registry entry I was getting:

    With the added entry I get:

    COM6 is linked to ttyUSB1 - Which is the PropPlug attached to a Propeller1 I'm developing with:

    $ ls -l ...wineprefixes/propeller/dosdevices/com*
    lrwxrwxrwx 1 evanh evanh 10 Aug 28 00:49 ...wineprefixes/propeller/dosdevices/com1 -> /dev/ttyS0
    lrwxrwxrwx 1 evanh evanh 12 Aug 28 00:49 ...wineprefixes/propeller/dosdevices/com36 -> /dev/ttyUSB0
    lrwxrwxrwx 1 evanh evanh 12 Aug 28 00:49 ...wineprefixes/propeller/dosdevices/com37 -> /dev/ttyUSB1
    lrwxrwxrwx 1 evanh evanh 12 Aug 28 00:49 ...wineprefixes/propeller/dosdevices/com5 -> /dev/ttyUSB0
    lrwxrwxrwx 1 evanh evanh 12 Aug 28 00:49 ...wineprefixes/propeller/dosdevices/com6 -> /dev/ttyUSB1
    
    $ ls -l /dev/serial/by-id/
    total 0
    lrwxrwxrwx 1 root root 13 Aug 27 14:23 usb-Parallax_Inc_Propeller_P2-ES_EVAL_P23YOO42-if00-port0 -> ../../ttyUSB0
    lrwxrwxrwx 1 root root 13 Aug 27 14:23 usb-Parallax_Inc_PropPlug_P7ehkogg-if00-port0 -> ../../ttyUSB1
    
  • evanhevanh Posts: 15,969
    edited 2022-08-27 13:37

    Holy cow! It works with the Propeller2. Proptool can now download and debug on Wine! I setup COM5 since it is an Eval Board.

    .
    EDIT: Hmm, it's not quite usable though. Proptool gets an internal error 120 after one run of program using the debug terminal then stops working.

    EDIT2: And PST doesn't see any sent data either.

  • EDIT: Hmm, it's not quite usable though. Proptool gets an internal error 120 after one run of program using the debug terminal then stops working.

    Yes unfortunately this is what I get too. It essentially hangs at that point and won't let me close Proptool and I need to shutdown the wineserver to restart it. Pity. It'd be nice to have Proptool work fully on a Mac this way as its so fast to load up.

  • hinvhinv Posts: 1,255
    edited 2022-08-27 15:01

    Please @cgracey , just EOL the Delphi based PNut and rewrite it for the P2 itself to avoid all of these platform issues. It could then debug a second P2, or even the same P2 (with full Heisenberg!). So then, whoever wants to develop on a P2 would have to buy a P2. And, people who want to learn how to program the P2 can see your example of how to use it's features, since almost noone here is interested in learning Delphi and i386 assembly. With the P2 and the extra memory options, you have everything you need, and you have said it yourself that the P2 can do this debug task better! 3Mbaud, no problem. 10Mbaud, even better! What is the limit? I guess we will find out!
    I wonder how many people would rather buy a 2nd P2 for debugging big apps that used more than the cogs left after implementing debug??? Speaking of resources, I'm guessing that debug could be made modular so that the simplest debug can be made to run in a single cog while the more complex stuff like sprites, graphs, etc can be added on. This would not only conserve resources, but would break up the code into manageable testable chunks, thus being open for contribution from other geniuses.

  • evanhevanh Posts: 15,969

    Documentation needs fleshed out first.

  • hinvhinv Posts: 1,255

    Oh, with all of this old processor emulation going on, Pnut on the P2 could then be modified to have much simpler debug screens for the emulated processors like 6502, Z80, 68000, etc.

  • @hinv said:
    I wonder how many people would rather buy a 2nd P2 for debugging big apps that used more than the cogs left after implementing debug???

    Approximately zero.

  • JonnyMacJonnyMac Posts: 9,111
    edited 2022-08-27 16:40

    Please @cgracey , just EOL the Delphi based PNut and rewrite it for the P2 itself...

    Sure, dump the old version of Delphi, but don't make us do development on the P2. Update the Spin compiler to an external app, written in a x-platform language that can be compiled anywhere and does dead code removal, share it with others for improvements/new features (but maintain an official version). Focus on specialty hardware (the P1 and P2), and generalize the development. Developing only for Windows has hurt the Parallax bottom line.

  • Wuerfel_21Wuerfel_21 Posts: 5,074
    edited 2022-08-27 17:27

    We do have the official Spin2 compiler as a cross-platform command line tool. (binaries here) (though now somewhat outdated. Also @cgracey I think you forgot to update the ASM file on github!!!) Still asm on the inside, but the CLI is in C and the whole thing builds on any OS with 32bit libs (this really only excludes MacOS, because imagine having an OS that doesn't constantly break itself).

    Though IMO flexspin should become the official/default compiler. It's a slight mess on the inside, but orders of magnitudes more maintain- and portable than the PNut compiler. Main obstacles to that:
    - Getting Chip/Parallax to do it.
    - Traditional bytecode support on P2. (Exists for P1, designed to be extensible)
    - Rework method pointers (currently use heap allocation -> bloat and runtime uncertainty)
    - Refactor code to run as library (so PropTool can call it without tempfile / process spawn overhead)
    - Improve test suite to catch more flexsplorps before they make it to production (@ersmith still hasn't gotten to merge the change to allow P1 exectests to run on CI...)

  • hinvhinv Posts: 1,255
    edited 2022-08-27 17:53

    @Wuerfel_21 said:

    @hinv said:
    I wonder how many people would rather buy a 2nd P2 for debugging big apps that used more than the cogs left after implementing debug???

    Approximately zero.

    Really, you'd rather deal with the OS and emulation problems with running serial & the lag, limited bandwidth of the a Delphi app than P2 code displaying to HDMI or VGA with deterministic, low latency response? Do you run PNut Debug now?

    How many people did you poll before answering that?

  • cgraceycgracey Posts: 14,156

    I want to have tools running on the P2, itself, for many reasons. It would be a whole new level of productivity.

  • hinvhinv Posts: 1,255

    @JonnyMac said:

    Please @cgracey , just EOL the Delphi based PNut and rewrite it for the P2 itself...

    Sure, dump the old version of Delphi, but don't make us do development on the P2. Update the Spin compiler to an external app, written in a x-platform language that can be compiled anywhere and does dead code removal, share it with others for improvements/new features (but maintain an official version).

    For those that want to develop on Window, there is the Propeller Tool, not maintained by Chip, and for Mac & Linux there is FlexProp(which I think already does dead code removal), also not maintained by Chip.

    Focus on specialty hardware (the P1 and P2), and generalize the development. Developing only for Windows has hurt the Parallax bottom line.

    Agreed! But for those that would rather develop on the P2, that would be great, but I think debugging on the P2 is more important.

  • @hinv said:

    @Wuerfel_21 said:

    @hinv said:
    I wonder how many people would rather buy a 2nd P2 for debugging big apps that used more than the cogs left after implementing debug???

    Approximately zero.

    Really, you'd rather deal with the OS and emulation problems with running serial & the lag, limited bandwidth of the a Delphi app than P2 code displaying to HDMI or VGA with deterministic, low latency response?

    What problems? All the weird serial port issues are solvable. Just needs some actual looking-into beyond "works on my machine lmao". It is a mess kinda.

    What I'd really rather not deal with is having to have twice the P2 wiring mess and at least 3 monitors and 3 keyboards on my desk at all times (One for the PC, one for the actual P2, one for the hypothetical debugger P2) (and realistically you need 2 PC monitors for decent productivity).

    Also, most of my debug use either involves logging debug data to disk and then analyzing it there (sometimes using custom scripts) or figuring out the reason for some sort of crash/hang, neither of which is latency sensitive. The former wouldn't even be feasible on a P2 debugger.

    Do you run PNut Debug now?

    If you mean debugging in general, yes, all the time. I haven't really messed with the interactive debugger on account of none of my projects actually compiling under PNut.

    How many people did you poll before answering that?

    Some almost-significant percentage of the people owning more than one P2 devboard.

    And considering the retail prices, you'd kinda have to be braindead to buy two of them just to get started.

  • I'd love to see the on-chip development working, as it definitely brings back fond memories of using 8-bitters in the 80's with the instant-bootup and gratification of changing a line of code and typing run or whatever to see the results. BUT, I have to agree with a few others, it definitely shouldn't be "the" dev environment. Decouple the compiler from the IDE and make them cross-platform as has been said so there at least can be a cohesive system that's familiar to outsiders enough to attract them to the platform. There's no reason both can't then exist...

  • hinvhinv Posts: 1,255

    @Wuerfel_21 said:

    @hinv said:

    @Wuerfel_21 said:

    @hinv said:
    I wonder how many people would rather buy a 2nd P2 for debugging big apps that used more than the cogs left after implementing debug???

    Approximately zero.

    Really, you'd rather deal with the OS and emulation problems with running serial & the lag, limited bandwidth of the a Delphi app than P2 code displaying to HDMI or VGA with deterministic, low latency response?

    What problems? All the weird serial port issues are solvable. Just needs some actual looking-into beyond "works on my machine lmao". It is a mess kinda.

    Exactly, pages of this thread are OS problem "mess"

    What I'd really rather not deal with is having to have twice the P2 wiring mess and at least 3 monitors and 3 keyboards on my desk at all times (One for the PC, one for the actual P2, one for the hypothetical debugger P2) (and realistically you need 2 PC monitors for decent productivity).

    This is why it should be modular..like your NeoYume is. If you want to run serial in from some other source, like the serial terminal on FlexProp. This could be handled similar to how you handle joystick inputs.
    So for debugging NeoYume, in my thinking, the P2nut Debug would run on a P2 board with HDMI or VGA screen and just a mouse, with serial input coming from your PC. Otherwise, you could put a KVM on your setup.

    Also, most of my debug use either involves logging debug data to disk and then analyzing it there (sometimes using custom scripts) or figuring out the reason for some sort of crash/hang, neither of which is latency sensitive. The former wouldn't even be feasible on a P2 debugger.

    Do you run PNut Debug now?

    If you mean debugging in general, yes, all the time. I haven't really messed with the interactive debugger on account of none of my projects actually compiling under PNut.

    Thought so.

    How many people did you poll before answering that?

    Some almost-significant percentage of the people owning more than one P2 devboard.

    I'm calling BS on that.

    And considering the retail prices, you'd kinda have to be braindead to buy two of them just to get started.

    I would agree with you on that. But just getting started doesn't mean a multicore application, either. I don't think with the performance of the P2 that surpassing the performance on the PC would take more than 4 cores, leaving 4 or more cores for a beginner's application. Plus if it is modular, the sprite module/object, for instance wouldn't need to be loaded for a beginner either. Of course debugging on a the same P2 as running your code can run into conflicts of resources, so these would have to be sorted.

  • ElectrodudeElectrodude Posts: 1,658
    edited 2022-08-27 19:16

    I can't see myself doing serious P2 development directly on a P2 any time soon. If it ever happened, it would be through a network connection from a PC, so I could still have a web browser without needing two separate displays/keyboards, since a P2 will never™ run a web browser.

    All of your serial port problems only exist on Windows (and Wine, which has to emulate much of Windows's stupidity). In my experience with Linux and Mac OS, you plug it in, and just it works, at any baud rate up to the max the USB-to-serial chip supports.

    I haven't tried the PNut debugger yet, but if it works in Wine, I guess I could try it. I generally prefer Flexspin over PNut, though, since it has an optimizer and is easier to use in a command-line environment.

  • @hinv said:

    @Wuerfel_21 said:

    @hinv said:

    @Wuerfel_21 said:

    @hinv said:
    I wonder how many people would rather buy a 2nd P2 for debugging big apps that used more than the cogs left after implementing debug???

    Approximately zero.

    Really, you'd rather deal with the OS and emulation problems with running serial & the lag, limited bandwidth of the a Delphi app than P2 code displaying to HDMI or VGA with deterministic, low latency response?

    What problems? All the weird serial port issues are solvable. Just needs some actual looking-into beyond "works on my machine lmao". It is a mess kinda.

    Exactly, pages of this thread are OS problem "mess"

    What I'd really rather not deal with is having to have twice the P2 wiring mess and at least 3 monitors and 3 keyboards on my desk at all times (One for the PC, one for the actual P2, one for the hypothetical debugger P2) (and realistically you need 2 PC monitors for decent productivity).

    This is why it should be modular..like your NeoYume is. If you want to run serial in from some other source, like the serial terminal on FlexProp. This could be handled similar to how you handle joystick inputs.
    So for debugging NeoYume, in my thinking, the P2nut Debug would run on a P2 board with HDMI or VGA screen and just a mouse, with serial input coming from your PC. Otherwise, you could put a KVM on your setup.

    That's still more hardware than is really necessary.

    How many people did you poll before answering that?

    Some almost-significant percentage of the people owning more than one P2 devboard.

    I'm calling BS on that.

    Recognize that "almost-significant percentage" is an intentionally meaningless term that you can take to mean a sample size of n=1.

    And considering the retail prices, you'd kinda have to be braindead to buy two of them just to get started.

    I would agree with you on that. But just getting started doesn't mean a multicore application, either. I don't think with the performance of the P2 that surpassing the performance on the PC would take more than 4 cores, leaving 4 or more cores for a beginner's application. Plus if it is modular, the sprite module/object, for instance wouldn't need to be loaded for a beginner either. Of course debugging on a the same P2 as running your code can run into conflicts of resources, so these would have to be sorted.

    The only real performance bottleneck is the P2-side debug IRQ overhead and serial transmit (and to some extent, the bit of latency from FTDI serial).
    Debug UI on same chip is a nonstarter, too much possibility to mess it up (plus you probably can't fit the whole thing into 16K)

  • cgraceycgracey Posts: 14,156

    Wuerfel_21, I updated the P2_PNut_Public repository with the latest p2com.asm file. I'm glad you noticed that.

  • hinvhinv Posts: 1,255

    @Electrodude said:
    I can't see myself doing serious P2 development directly on a P2 any time soon. If it ever happened, it would be through a network connection from a PC, so I could still have a web browser without needing two separate displays/keyboards, since a P2 will never™ run a web browser.

    ...or through a USB/serial connection?

    All of your serial port problems only exist on Windows (and Wine, which has to emulate much of Windows's stupidity). In my experience with Linux and Mac OS, you plug it in, and just it works, at any baud rate up to the max the USB-to-serial chip supports.

    ...which would seem to support my argument that at least PNut shouldn't be on Windows... If on the P2 and modular, it would probably get more users.

    I haven't tried the PNut debugger yet, but if it works in Wine, I guess I could try it. I generally prefer Flexspin over PNut, though, since it has an optimizer and is easier to use in a command-line environment.

    Would you run a P2 based debugger similar to P2 Debug but more modular so you can load the parts of it that you want?

  • hinvhinv Posts: 1,255

    How many chips does it take to debug a P2 program? Just one if that chip is another P2(or the same one) with PNut Debug ported to it.

  • cgraceycgracey Posts: 14,156
    edited 2022-08-28 00:37

    I just updated the file at the top of this thread, as well as the GitHub sources, since I fixed a divide-by-zero bug in the command line "-debug" mode. The P2 Clock Frequency is zero in that case and I was doing some math with it when the user pointed the mouse to the "CT" box in the debugger.

Sign In or Register to comment.