@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.
@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.
@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.
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.
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.
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.
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.
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.
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.
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.
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...)
@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?
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:
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...
@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.
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:
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)
@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?
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.
Comments
Super, Wummi!
Thank you for letting me know.
If you run with debug on and generate serial at the appropriate baud rate, it should appear in the debug window.
So, one can just send anything they want out the same com port as the debug window? Didn't know that...
Is the baud definable still? I'm using
DOWNLOAD_BAUD = 230_400 DEBUG_BAUD = DOWNLOAD_BAUDbut 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
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.
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.
Also getting this result too (in PropTool) - I think it might be because the IOCTL is failing.
With PNut v35u I have even worse problems...it freezes with this after selecting Get Hardware Version from the Run menu:
Output from Wine:
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.
Pnut 35u on Wine 7.15 on Linux seems to be okay with all those. Even 3 Mbaud download/debug works surprisingly. No errors.
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:
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.
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.
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.
Documentation needs fleshed out first.
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.
Approximately zero.
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.
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...)
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?
I want to have tools running on the P2, itself, for many reasons. It would be a whole new level of productivity.
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.
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.
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.
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.
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...
Exactly, pages of this thread are OS problem "mess"
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.
Thought so.
I'm calling BS on that.
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.
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.
That's still more hardware than is really necessary.
Recognize that "almost-significant percentage" is an intentionally meaningless term that you can take to mean a sample size of n=1.
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)
Wuerfel_21, I updated the P2_PNut_Public repository with the latest p2com.asm file. I'm glad you noticed that.
...or through a USB/serial connection?
...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.
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?
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.
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.