@evanh said:
None of the compiler is needed. Eric and Ross have that side already sorted.
???
None of them output spin2 bytecode.
The bytecode backend I wrote for flexspin is supposed to gain spin2 bytecode capability... eventually(TM)... But Eric is working on a separate thing right now (check the -2nu flag in current git builds) that's AFAICT gonna be somewhere inbetween bytecode and PASM in terms of size and speed.
The -2nu flag generates a custom bytecode interpreter (built to optimize the specific program being compiled) The goal is for it to eventually be both smaller and faster than bytecode. It's not there yet, in part because there's virtually no optimization done yet on the bytecode, nor does the interpreter use skip flags (although the infrastructure is there for that, I recently added XBYTE execution).
@evanh said:
@ManAtWork said:
... If you want you can "emulate" all the debug output with printfs.
That's how Flexspin currently handles existing Spin debug code. When you compile a spin program that has debug code, Flexspin automatically imports some additional C files to handle it.
Ye, it currently just turns debug statements into printf calls. Obviously doesn't work for PASM code, which kinda defeats the point. (I also don't think the backtick syntax works, parser tweakage needed)
I'm not sure it defeats the point -- it's still nice to be able to debug Spin2 code, even if you can't debug the PASM. The backtick syntax is supposed to work, at least it sends some data out, but there's nothing on the PC to interpret the backticks yet. Which I think is the whole point of this thread, it'd be nice to figure out a platform-independent way to display the backtick graphics.
@ersmith said:
... PNut can't access the serial port under Wine (which is a whole other bug that should be looked into) and so any serial based solution won't work on Linux, and probably not on MacOS either.
A belated comment: Pnut actually works just fine. Full graphic debug included. It's Proptool that can't use the comport.
There is one strange non-working part of Pnut - the shell commands! It only works via the GUI. Can't even load a source file from the shell. I use drag'n'drop to load my tests.
EDIT: I used Pnut, with Wine, mostly during the FPGA days. While the instruction set was still in flux.
@ersmith said:
... PNut can't access the serial port under Wine (which is a whole other bug that should be looked into) and so any serial based solution won't work on Linux, and probably not on MacOS either.
A belated comment: Pnut actually works just fine. Full graphic debug included. It's Proptool that can't use the comport.
There is one strange non-working part of Pnut - the shell commands! It only works via the GUI. Can't even load a source file from the shell. I use drag'n'drop to load my tests.
EDIT: I used Pnut, with Wine, mostly during the FPGA days. While the instruction set was still in flux.
Which version of PNut were you able to get work, and with which version of Wine? I've never even tried proptool, but PNut consistently cannot find a serial port when I run it under Wine. Strangely, I also have the opposite experience with the shell commands -- those are working fine for me (except that the "run" fails to find a serial port). Annoyingly, you must leave out the .spin2 extension from the file; perhaps that's tripping you up?
@dgately said:
I was thinking that someone might be able to create a Processing script that converts the serial debug output from Pnut (or the PropTool) to Processing's graphics and Console output. Am I thinking way off or might this be possible?
I've had the same thought -- jus not enough time to learn Processing well.
Processing is probably not the right tool for that job. SDL2/OpenGL seems like the right ticket for that - can handle multiple windows and can draw really fast.
EDIT: I used Pnut, with Wine, mostly during the FPGA days. While the instruction set was still in flux.
Which version of PNut were you able to get work, and with which version of Wine? I've never even tried proptool, but PNut consistently cannot find a serial port when I run it under Wine. Strangely, I also have the opposite experience with the shell commands -- those are working fine for me (except that the "run" fails to find a serial port). Annoyingly, you must leave out the .spin2 extension from the file; perhaps that's tripping you up?
All versions with all versions. I do use the experimental 'Staging' branch of Wine but I can't see that being a factor.
You do need to be in the dialout group: sudo usermod -a -G dialout [username]
@ersmith said:
... Strangely, I also have the opposite experience with the shell commands -- those are working fine for me (except that the "run" fails to find a serial port). Annoyingly, you must leave out the .spin2 extension from the file; perhaps that's tripping you up?
Huh. Thanks for the hints. You're right removing the ".spin2" works [with the v34 pnut]. And some more experimenting tells me the shell path is finding an old version of Pnut (v34). So that explains the lack of command options.
EDIT: Hehe, and the newer Pnut_v35m.exe also accepts .spin2 in the filename. So all my problems are due to path'ng search. Time to clean up ...
Perhaps an easier way to go rather that touching Pnut and its serial handling etc, is to use something like an extended version of loadp2 to just filter out the backtick data (when enabled) and divert it to a named pipe or socket etc.
We already have a Windows solution with PropTool, so that doesn't really need to be modified. It's the non-Windows platforms that would benefit the most. Something like SDL could be useful for the cross platform graphics as @Wuerfel_21 has mentioned (as did I some time back IIRC). Loadp2 can work on Windows too so there is still some chance at getting the serial data extracted on that system too.
I've worked with named pipes in a past life and I know Windows supported them back then. You'd also need some server app to render the data arriving from the pipe.
@rogloh said:
Perhaps an easier way to go rather that touching Pnut and its serial handling etc, is to use something like an extended version of loadp2 to just filter out the backtick data (when enabled) and divert it to a named pipe or socket etc.
We already have a Windows solution with PropTool, so that doesn't really need to be modified. It's the non-Windows platforms that would benefit the most. Something like SDL could be useful for the cross platform graphics as @Wuerfel_21 has mentioned (as did I some time back IIRC). Loadp2 can work on Windows too so there is still some chance at getting the serial data extracted on that system too.
I've worked with named pipes in a past life and I know Windows supported them back then. You'd also need some server app to render the data arriving from the pipe.
Ye, that thing I'm doing just expects serial data to be piped into its stdin (obnoxiously, loadp2 currently doesn't quit on broken pipe, so after closing the debug window, it still needs to be CTRL+C'd normally.
@rogloh said:
Perhaps an easier way to go rather that touching Pnut and its serial handling etc, is to use something like an extended version of loadp2 to just filter out the backtick data (when enabled) and divert it to a named pipe or socket etc.
We already have a Windows solution with PropTool, so that doesn't really need to be modified. It's the non-Windows platforms that would benefit the most. Something like SDL could be useful for the cross platform graphics as @Wuerfel_21 has mentioned (as did I some time back IIRC). Loadp2 can work on Windows too so there is still some chance at getting the serial data extracted on that system too.
I've worked with named pipes in a past life and I know Windows supported them back then. You'd also need some server app to render the data arriving from the pipe.
Ye, that thing I'm doing just expects serial data to be piped into its stdin (obnoxiously, loadp2 currently doesn't quit on broken pipe, so after closing the debug window, it still needs to be CTRL+C'd normally.
If a named pipe were used as an extension to loadp2 (instead of stdout) then maybe it might be able to exit as well if it can detect the pipe closing.
I'm sort of thinking about another command line parameter for loadp2. If this parameter is present it uses it as the pipe name and redirects the serial data. You could split debug data and normal text too, or just leave loadp2 console to take the regular text and the pipe for the debug data for example.
@rogloh said:
Perhaps an easier way to go rather that touching Pnut and its serial handling etc, is to use something like an extended version of loadp2 to just filter out the backtick data (when enabled) and divert it to a named pipe or socket etc.
We already have a Windows solution with PropTool, so that doesn't really need to be modified. It's the non-Windows platforms that would benefit the most. Something like SDL could be useful for the cross platform graphics as @Wuerfel_21 has mentioned (as did I some time back IIRC). Loadp2 can work on Windows too so there is still some chance at getting the serial data extracted on that system too.
I've worked with named pipes in a past life and I know Windows supported them back then. You'd also need some server app to render the data arriving from the pipe.
Ye, that thing I'm doing just expects serial data to be piped into its stdin (obnoxiously, loadp2 currently doesn't quit on broken pipe, so after closing the debug window, it still needs to be CTRL+C'd normally.
If a named pipe were used as an extension to loadp2 (instead of stdout) then maybe it might be able to exit as well if it can detect the pipe closing.
Detecting a broken stdout pipe is certainly possible, FFMPEG does it. On linux the default behaviour for SIGPIPE is to kill the process and I don't see anything to override that, but it doesn't seem to work under Windows/MinGW.
Very interesting @Wuerfel_21 . Is this something that you intend to expand to cover the full set (or subset) of existing DEBUG output capabilities? Is there anything Chip does that wouldn't be able to work nicely on SDL2 in your opinion?
@rogloh said:
Very interesting @Wuerfel_21 . Is this something that you intend to expand to cover the full set (or subset) of existing DEBUG output capabilities? Is there anything Chip does that wouldn't be able to work nicely on SDL2 in your opinion?
Not sure. The bitmap displays should be easy to add, since they can be implemented using blits and pixel sets. They're also one of the ones I like to use. PLOT, SCOPE and friends are a bit more complicated, would have to use an OpenGL window for those and write some simple shaders to draw all the shapes that plot can. What does Chip even use for that?
But ye, one could pretty much implement all DEBUG features in this framework. Maybe not the little coordinate tooltip you get when hovering over the window. That'd have to be handled differently, I think. Like, putting the number in the corner or smth.
I haven't followed all of this discussion and there are many things I don't underrstand. If I read this correctly you, Wuerfel_21, are currently writing an external program that uses pipes to input the P2 debug data stream and outputs it to the screen. You've already implemented text output but not the scope and bitmap displays.
My skills of programming PCs are very limited. I use a framework called "wxWidgets" to implement all the GUI stuff of my applications. wxWidgets is multi-platform enabled so the code can be compiled on Windows, Linux and MAC. I've already made an oscilloscope display for my servo controller:
It doesn't use OpenGL but a "wxDC" (device context) which is an abstract API for drawing an rendering mostly 2D elements. Example:
I'm sure you'll also find a way to do this in your framework. And I think you have much more time, motivation and skill. But in the unlikely event that you need help I could probably contribute something. Is Chip's code for the debug windows available somewhere?
I came over different programming languages and api's of the week to finally have nothing. But the idea, that forth will solve some of my problems. When you brought up wxWidgets I remembered the time I worked with CH, an interpretative C implementation that used wxWidgets. A quick google showed: CH is still alive . My path forked away from CH when a customer required to have compiled programs. But like SPIN the turn around time of CH is very short, so iterative programming can be done without compiling and linking. Is anybody around to know about CH?
I've totally forgotten that my son Simon is a good Java programmer and has some experience with OpenGL. He is a student and has some spare time. I think if we can tell him exactly what is necessary he could program some sort of graphical debug client. Well... that's the actual art of programming. If you can describe the task in detail then coding is almost trivial.
So again: Chip, are you willing to share the source code for the graphical debug windows? I think we could easily write the simpler displays (LOGIC, SCOPE, TERM, BITMAP) from scratch but for the more complex ones (FFT, SPECTRO, MIDI...) it would be good to have some draft or template.
Then we need to agree on the interface for the input data. I think it's difficult to get platform and language independent direct access to the serial ports. Wuerfel21, how do pipes work? On Linux you can use them just like normal files. But on Windows? How about network sockets or TCP/IP ports?
Chip's sources aren't really needed. They might speed up a porting exercise but the full debug command set is well documented already. About 50% of the Spin2 manual is taken up with it. And it's all testable in plain text over the comport.
EDIT: That said, Chip may not have used many libraries but instead just rendered everything into bitmaps. Using his sources would make more sense in this case.
Yes, it's not a big problem. The input data comig from the P2 is well documented. How the output should look can be tried out using PNut or PropTool. But it's a real lot of work to test everything so that it looks right, the log scaling, the FFT and spectrum analysis etc. It would really help if we could look at his code instead of reverse engineer everything and do it by trial and error.
Comments
The -2nu flag generates a custom bytecode interpreter (built to optimize the specific program being compiled) The goal is for it to eventually be both smaller and faster than bytecode. It's not there yet, in part because there's virtually no optimization done yet on the bytecode, nor does the interpreter use skip flags (although the infrastructure is there for that, I recently added XBYTE execution).
I'm not sure it defeats the point -- it's still nice to be able to debug Spin2 code, even if you can't debug the PASM. The backtick syntax is supposed to work, at least it sends some data out, but there's nothing on the PC to interpret the backticks yet. Which I think is the whole point of this thread, it'd be nice to figure out a platform-independent way to display the backtick graphics.
A belated comment: Pnut actually works just fine. Full graphic debug included. It's Proptool that can't use the comport.
There is one strange non-working part of Pnut - the shell commands! It only works via the GUI. Can't even load a source file from the shell. I use drag'n'drop to load my tests.
EDIT: I used Pnut, with Wine, mostly during the FPGA days. While the instruction set was still in flux.
Which version of PNut were you able to get work, and with which version of Wine? I've never even tried proptool, but PNut consistently cannot find a serial port when I run it under Wine. Strangely, I also have the opposite experience with the shell commands -- those are working fine for me (except that the "run" fails to find a serial port). Annoyingly, you must leave out the .spin2 extension from the file; perhaps that's tripping you up?
I've had the same thought -- jus not enough time to learn Processing well.
Processing is probably not the right tool for that job. SDL2/OpenGL seems like the right ticket for that - can handle multiple windows and can draw really fast.
All versions with all versions. I do use the experimental 'Staging' branch of Wine but I can't see that being a factor.
You do need to be in the dialout group:
sudo usermod -a -G dialout [username]Huh. Thanks for the hints. You're right removing the ".spin2" works [with the v34 pnut]. And some more experimenting tells me the shell path is finding an old version of Pnut (v34). So that explains the lack of command options.
EDIT: Hehe, and the newer Pnut_v35m.exe also accepts .spin2 in the filename. So all my problems are due to path'ng search.
Time to clean up ...
So, uhh this is happening I guess
Perhaps an easier way to go rather that touching Pnut and its serial handling etc, is to use something like an extended version of loadp2 to just filter out the backtick data (when enabled) and divert it to a named pipe or socket etc.
We already have a Windows solution with PropTool, so that doesn't really need to be modified. It's the non-Windows platforms that would benefit the most. Something like SDL could be useful for the cross platform graphics as @Wuerfel_21 has mentioned (as did I some time back IIRC). Loadp2 can work on Windows too so there is still some chance at getting the serial data extracted on that system too.
I've worked with named pipes in a past life and I know Windows supported them back then. You'd also need some server app to render the data arriving from the pipe.
Ye, that thing I'm doing just expects serial data to be piped into its stdin (obnoxiously, loadp2 currently doesn't quit on broken pipe, so after closing the debug window, it still needs to be CTRL+C'd normally.
If a named pipe were used as an extension to loadp2 (instead of stdout) then maybe it might be able to exit as well if it can detect the pipe closing.
I'm sort of thinking about another command line parameter for loadp2. If this parameter is present it uses it as the pipe name and redirects the serial data. You could split debug data and normal text too, or just leave loadp2 console to take the regular text and the pipe for the debug data for example.
Detecting a broken stdout pipe is certainly possible, FFMPEG does it. On linux the default behaviour for SIGPIPE is to kill the process and I don't see anything to override that, but it doesn't seem to work under Windows/MinGW.
So here's that thing... https://github.com/Wuerfel21/sdldebug
rake(need to have GCC and SDL2/SDL2_ttf headers installed. And obviously, Rake, too)rake examples(need to have flexspin built from PR#192... or just use PNut, I guess)loadp2 -p COM8 -b 115200 -t | ./p2debug.exeVery interesting @Wuerfel_21 . Is this something that you intend to expand to cover the full set (or subset) of existing DEBUG output capabilities? Is there anything Chip does that wouldn't be able to work nicely on SDL2 in your opinion?
Not sure. The bitmap displays should be easy to add, since they can be implemented using blits and pixel sets. They're also one of the ones I like to use. PLOT, SCOPE and friends are a bit more complicated, would have to use an OpenGL window for those and write some simple shaders to draw all the shapes that plot can. What does Chip even use for that?
But ye, one could pretty much implement all DEBUG features in this framework. Maybe not the little coordinate tooltip you get when hovering over the window. That'd have to be handled differently, I think. Like, putting the number in the corner or smth.
@Wuerfel_21 why not use the CPU 2D rendering? I doubt Chip uses anything else.
Once the context is created, OpenGL actually makes a lot of this pretty easy.
I haven't followed all of this discussion and there are many things I don't underrstand. If I read this correctly you, Wuerfel_21, are currently writing an external program that uses pipes to input the P2 debug data stream and outputs it to the screen. You've already implemented text output but not the scope and bitmap displays.
My skills of programming PCs are very limited. I use a framework called "wxWidgets" to implement all the GUI stuff of my applications. wxWidgets is multi-platform enabled so the code can be compiled on Windows, Linux and MAC. I've already made an oscilloscope display for my servo controller:
It doesn't use OpenGL but a "wxDC" (device context) which is an abstract API for drawing an rendering mostly 2D elements. Example:
void ScopePanel::render (wxDC& dc) { int sizeX, sizeY; dc.GetSize (&sizeX, &sizeY); gridSize= (sizeX>sizeY)?sizeY:sizeX; gridSize-= 20; offsX = (sizeX - gridSize) / 2; offsY = (sizeY - gridSize) / 2; // draw grid dc.SetPen (wxPen (*wxLIGHT_GREY, 1, wxPENSTYLE_DOT)); for (float f=0.0f; f<=1.01; f+= 0.1f) { int i= round (f*float(gridSize)); dc.DrawLine (offsX, offsY + i, offsX+gridSize, offsY + i); dc.DrawLine (offsX + i, offsY, offsX + i, offsY+gridSize); } ...I'm sure you'll also find a way to do this in your framework. And I think you have much more time, motivation and skill. But in the unlikely event that you need help I could probably contribute something. Is Chip's code for the debug windows available somewhere?
I came over different programming languages and api's of the week to finally have nothing. But the idea, that forth will solve some of my problems. When you brought up wxWidgets I remembered the time I worked with CH, an interpretative C implementation that used wxWidgets. A quick google showed: CH is still alive . My path forked away from CH when a customer required to have compiled programs. But like SPIN the turn around time of CH is very short, so iterative programming can be done without compiling and linking. Is anybody around to know about CH?
I've totally forgotten that my son Simon is a good Java programmer and has some experience with OpenGL. He is a student and has some spare time. I think if we can tell him exactly what is necessary he could program some sort of graphical debug client. Well... that's the actual art of programming. If you can describe the task in detail then coding is almost trivial.
So again: Chip, are you willing to share the source code for the graphical debug windows? I think we could easily write the simpler displays (LOGIC, SCOPE, TERM, BITMAP) from scratch but for the more complex ones (FFT, SPECTRO, MIDI...) it would be good to have some draft or template.
Then we need to agree on the interface for the input data. I think it's difficult to get platform and language independent direct access to the serial ports. Wuerfel21, how do pipes work? On Linux you can use them just like normal files. But on Windows? How about network sockets or TCP/IP ports?
Chip's sources aren't really needed. They might speed up a porting exercise but the full debug command set is well documented already. About 50% of the Spin2 manual is taken up with it. And it's all testable in plain text over the comport.
EDIT: That said, Chip may not have used many libraries but instead just rendered everything into bitmaps. Using his sources would make more sense in this case.
Yes, it's not a big problem. The input data comig from the P2 is well documented. How the output should look can be tried out using PNut or PropTool. But it's a real lot of work to test everything so that it looks right, the log scaling, the FFT and spectrum analysis etc. It would really help if we could look at his code instead of reverse engineer everything and do it by trial and error.
@ManAtWork
You should email Chip and explain what you want and why.