Multi-platform DEBUG output
ManAtWork
Posts: 2,080
I know, this has been discussed in several places before. I haven't follewed the P2 live forum sessions lately but I know there have been some suggestions about extracting the graphical debug window features of PNut and putting it into a seperate program so that it can be compiled for different platforms and IDEs.
What about this a s a first step to minimize the required work: The IDE, terminal, loader or whatever software is used to communicate with the P2 could capture the serial debug stream and redirect it to a network socket. PNut could connect to the other side and read from the socket. It can be run in command line mode on the same (windows) PC or in an emulator (on linux/mac systems) or even on a different PC.
This would be a bit less comfortable for Linux or Mac users as if the debug windows had ben seamlessly integrated but it would be at least better than having nothing at all. And it's a lot less work than having to port the debug graphics to a different language or even having to re-write it from scratch.
Comments
As mentioned a couple of times Chip uses Pascal. Not sure if still Turbo-Pascal or already a 20+ years old version of Delphi.
It was mentioned that Proptool/Pnut are using 3-party components not portable that easy to other platforms.
I am not sure if the Debug Windows also use those components, but my best bet would be to try to combine the Debug screens with a simple serial Terminal screen and use a newer version of Delphi or even Freepascal to build a cross-platform Debug-enabled PST.
Enjoy!
Mike
Yes, I know that Chip uses Pascal. Therefore my suggestion to leave it as it is instead of trying to port it to a different language. All Chip had to do would be a small change, reading the debug data from a configurable socket instead of the serial COM port.
I also know that this doesn't provide a native solution for Linux and Mac users. PNut still has to run in an Windows emulator or even on a different PC which is then used as a debug terminal. But it would mean that they could use their Linux/Mac PC with their favorite editor and compiler.
And yes, a truely portable version is the final goal. But if that goal is far away I think an intermediate solution makes some sense instead of defering the project to never-ever day. Or is there already work in progress?
Ok, nobody has responded.
Does this mean that...
1. nobody is interested?
2. there's already work in progress?
3. my idea is bad and there's a better way?
It sounds like it would work, but it requires Parallax to modify PNut to open the socket and read from it. Until that happens nothing else can be done, and I suspect Parallax does not have the resources to do this work.
I just use a second USB UART Adapter. With that I can keep the setup as ManAtWork describes it.
You mean you run your compiler on PC A and PNut on PC B and have forked the RX signal to both? That works?
I thought you had to press F10 or F11 for PNut or Propeller tool to trigger opening of the debug windows. And that wouln't happen if programming failed due to the stolen TX signal. But if you know a trick please tell us.
Isn't the Delphi source avaliable? That would be something to discuss at the live forum, tomorrow. I know there already have been lots of discussions about this but I think they gave up because it was considered too much work rewriting or porting the whole source. Adding sockets should be much less AFAIKS.
If it is Pascal/Delphi, it can be Lazarus, new, free and multiplatform.
I think @ManAtWork is discussing how to get the fancy debug features (graphics and such) to display on a non-Windows box. 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.
If you want it real obnoxious, you could run a Windows VM (use XP or smth that won't eat your entire RAM) and pass the serial port through
Porting or even rewriting the actual debug displays shouldn't be a major issue, just has to be done.
Getting the actual debugger into flexspin for ASM support also seems doable (though it would require touching the parser, which I don't have any experience)
Speaking of, I, uhhh, aquired a copy of the PNut compiler core and got it to build on Linux, but the way it handles including objects is kinda braindead and requires some work from the code calling into it, which I'm apparently doing wrong (I don't have the full PNut code), so I'm getting weird errors on bigger programs. Chip hasn't responded to my email about this, guess he's on vacation?
I think Chip went offline to concentrate on helping out with the rewrite of the docs, mainly. But probably also generally to help with the business too. He's been away from that for a long time.
uhhh, aquired? Did you pull the ASM code out of the binary?
@Wuerfel_21, you are a quite interesting person. Good to have you here in the Forums.
Enjoy!
Mike
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 think Chip mentioned a cmdline switch for Pnut to just display the debug screens and in your source you can specify a DEBUG_PIN so you could use a proplug on other pins connected to a windows PC/VM but this is sort of sub-optimal.
My current guess why debug can not be put into a single program easy is that it uses the parser of the compiler to generate the debug strings/info stored in the debug area and needs some of that existing code in Pnut to display the Screens.
We should pester Chip tomorrow to give the Pnut and PST source to - hmm - anybody interested to try to get it running with Lazarus/FreePascal or even Delphi community edition.
I don't know Pascal, Ada? anyone?
curious,
Mike
The various compilers would have to all generate code that in-turn generate compatible debug output. On second thoughts, they would probably do better by incorporating Chip's Spin2_debugger.spin2.
Yes, but that part should be easy.
What Chip is doing is to send some strings out of the debug HUB area to configure the Screens on the PC and then just sends data.
If I remember correctly he uses the backtick as escape character, else it is simple serial data you could also send those strings and data from a P1, Basic Stamp, even a Ar..ino. Does not matter.
If you look at the Binary in HEX you see the debug data generated by the compiler. The first part is the debugger code at the end are the variable data parts.
The loading part is as simple as it gets, you take a normal compiled binary and add that stub before it. The stub gets executed first, writes the debug HUB area then relocates the binary in HUB down to 0 and starts it at HUB 0 with debug mode.
My fear is more that the debug screens are intertwined with his X86 Asm so are not pure pascal. I am asking Chip for a while now but could not really get a clear answer out of him.
Will try again tomorrow.
Enjoy!
Mike
No, I just got sent some only slightly outdated version of it by Cluso who got it from Chip at one point.
I'm only interesting on the internet, IRL I'm really boring and kinda obnoxious ;3
For some reason (only sensible to Chip I guess), the debug data is parsed in the ASM code, but from a quick glance the only interaction with the rest of the code is using the symbol table for window names. That part should be really easy to rewrite in literally any language with regular expressions.
The debug data segment obviously needs to be generated by the compiler.
Yeah, give that a try. And tell him to check his mailbox ;)
Programming languages are like... uhhmm something....
Anyways, if you know one you know them all, to some extent.
I think I've seen, but not written, some Pascal in my time.
It still has to be standardised if it is to be supported by other, eg: Flex, Catalina, compilers too.
Assuming standardised debug commands, it would be up to the terminal program to do the displays. On that front, I guess it falls to loadp2. Eric didn't write loadp2, although he has added a couple of features to it.
That sounds like PNut is maybe using too low-level access to serial ?
I find this,
https://forum.lazarus.freepascal.org/index.php?topic=20481.300
which says this
TLazSerial is a component for GUI application. For console application use synaser.
and
The Interfaces unit links in the GUI widgetset of the LCL which is not really what you want for a command line application. Do as Jurassic Pork (and Michael on the mailing list) suggested and use the serial component of Synaser directly (TLazSerial is "simply" a GUI wrapper for that).
I downloaded the example on page 1
https://forum.lazarus.freepascal.org/index.php/topic,20481.0.html
LazSerial.7z (39.23 kB - downloaded 5705 times.)
https://forum.lazarus.freepascal.org/index.php?action=dlattach;topic=20481.0;attach=6115
and follow the steps to Open the package ( packages/open a package file) LazSerialPort.lpk - compile package.
Then, the test can build and run fine on Win10 (looks just like the example), and finds and connects to either of my 2 connected COM ports
I see it is coded to use a table for baud rates
, which should change to be integer value. (COM port HW should always select baud granularity, not user software)
A quick edit-test to add another line to the table worked fine.
If Chip could modify PNut (or debug portion?) to use TLazSerial, that should open Windows and Linux builds.
Chip mentioned that Pnut/PropTool use very old 3rd party components for the edit screens (and more?) and they are neither cross platform nor available anymore.
For that reason I am pledging to use PST as base or just add a Terminal debug screen and build it stand alone.
Heck you could even use it from Blockly...
Mike
"I'm really boring and kinda obnoxious"
I conquer that
The problem with the world is that the intelligent people are full of doubts, while the stupid ones are full of confidence.
Mike
The main pnut guts are in x86 (386 style) and uses Borland Turbo v5 Assembler to compile. The HLL code AFAIK is only used for the IDE in pnut. I am not sure how this is all integrated, but the compiler is in x86.
I tried to convert the x86 asm code to HLL (python syntax) using a set of python programs to convert the asm code. There were some stumbling blocks and I couldn't really test anything so after a few weeks gave up. Unfortunately, the x86 code needs to be able to be converted at will because Chip will just continue development in x86 and all changes will need to be continually ported. His x86 code is a moving target
None of the compiler is needed. Eric and Ross have that side already sorted.
???
None of them output spin2 bytecode.
That certainly doesn't matter.
In fact Spin isn't even a requirement at all. Debug commands can come from any program in any language.
Wait, wait, before this all get's too complicated, again....
Some basic things to examine, first:
Does the debug output require access to the symbol table or anything else generated by the compiler? I thought, NO. AFAIKS, all commands, symbols etc. are included in the serial output stream from the program running on the target. If I look at the raw (text) debug window I see that not only the values (hex numbers etc.) are output but also the variable names.
UHEX_LONG(i)outputsCog0 i = $0000_0009commands with backticks output the command names and all parameters. So if my assumption is valid, all the graphical debug stuff should be possible without parsing anything except for the serial data stream itself. No access to the program or any hidden compiler data should be required.Of course, a complete different task would be to implement the DEBUG commands of Spin2 in other languages, for example FlexProp C. But that's only a "diligence exercise". If you want you can "emulate" all the debug output with printfs.
Again, the ultimate goal is to have debug output on all platforms and all programming languages. But if that goal is out of reach for now it would be good to have some compromise or work-around that makes graphical debug output available earlier even if that has some drawbacks as requiring an external program to run or even a second PC.
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.
EDIT: And correct, debug() output is not for an actual debugger. It is an enhanced printf() extended with graphics features. Superior to any debugger, IMHO, when you already have access to everything right to the metal. No hidden library code. No NDAs. And hardware openly documented.
Yes, that's correct.
That's why I linked to the portable Lazarus/FPC library, TLazSerial, that works UARTs in GUI mode in Windows and Linux.
That would merge with Chip's Debug-pane handling parsers, when re-coded to use the same graphics that TLazSerial supports.
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
-2nuflag in current git builds) that's AFAICT gonna be somewhere inbetween bytecode and PASM in terms of size and speed.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)