I went through that with my serial driver when Chip added FDEC to the debug keywords -- it was the name of one of my serial methods. Since serial use is common, it caused a few headaches
Of all the arbitrary keywords to add, it seems "field" hasn't been identified as being used by anyone else yet. Maybe after-all, that is the clearest & simplest choice, both for docs and code reading clarity ?
Doesn't feel like there will be many (or any) new words to add moving forward now. The language seems pretty well evolved at this point. Although over the years I well recall many new versions of C# having added keywords that trample older code, so I suppose it's just the small price of progress to make some adjustments to older code to access newer compilers. Perhaps it would be silly to have the clutter of "compile with version X compiler" options to the tools, but I suppose that's a possibility if this continues being an issue / progress keeps being made.
Of all the arbitrary keywords to add, it seems "field" hasn't been identified as being used by anyone else yet. Maybe after-all, that is the clearest & simplest choice, both for docs and code reading clarity ?
Doesn't feel like there will be many (or any) new words to add moving forward now. The language seems pretty well evolved at this point. Although over the years I well recall many new versions of C# having added keywords that trample older code, so I suppose it's just the small price of progress to make some adjustments to older code to access newer compilers. Perhaps it would be silly to have the clutter of "compile with version X compiler" options to the tools, but I suppose that's a possibility if this continues being an issue / progress keeps being made.
I kind of like FIELD. It's not all consonants and it means something.
Historically, if our software receives a low flag score (and medium to low severity) and/or is only flagged by lesser-known antivirus systems, it's actually turned out to be completely clean. There were a few false-positives we found a couple years ago and reported to the larger-known AV systems and they confirmed they were false and issued updates back then, but at this point that doesn't seem to be happening here and we're not concerned about these two that are reported.
It's still slightly possible yours was infected on it's way down to your computer, or once on your computer. The best way to check that I know of is to compare SHA256 results on the exe. I think the SHA256 result is included near the top of that VirusTotal page for your comparison against your local copy.
I have had to run the compatibility debugger for windows 10 each time I upgrade Pnut and it seems to fix the problem..
@cgracey , how difficult would it be to add theese options to PNut?
I think, it shouldn't be much work because the actual operations are already implemented so it would only require adding the command line options and function calls.
This would be a great feature because it would enable using the graphical debug for all other compilers (at least on Windows). It would also solve this issue so we could use VSC together with FlexC without limitations on the debug output.
@ManAtWork said:
@cgracey , how difficult would it be to add theese options to PNut?
I think, it shouldn't be much work because the actual operations are already implemented so it would only require adding the command line options and function calls.
This would be a great feature because it would enable using the graphical debug for all other compilers (at least on Windows). It would also solve this issue so we could use VSC together with FlexC without limitations on the debug output.
BTW, yesterday I tried pnut -debug and found out that it just opens an empty (white) editor window but no (black) debug window. Does it need actual input fropm the COM port to start debugging or did I something wrong? I used pnut_v34z. BaudRate is just a number and CommPort must start with "COM", right? So pnut -debug COM24 230400 should work if I want to use COM24.
Chip, I think some time back you may have mentioned you were going to look at ways to enable conditional compilation in PNut/PropTool. Is that feature still on your radar, or has it slipped back a bit? I know I've asked about it before, I still live in hope...
BTW, yesterday I tried pnut -debug and found out that it just opens an empty (white) editor window but no (black) debug window. Does it need actual input fropm the COM port to start debugging or did I something wrong? I used pnut_v34z. BaudRate is just a number and CommPort must start with "COM", right? So pnut -debug COM24 230400 should work if I want to use COM24.
I am not sure and I'm away from my computer at the moment. A later version of PNut might act better. I remember making a bunch of changes a few versions ago that helped command line debugging.
@rogloh said:
Chip, I think some time back you may have mentioned you were going to look at ways to enable conditional compilation in PNut/PropTool. Is that feature still on your radar, or has it slipped back a bit? I know I've asked about it before, I still live in hope...
I have not forgotten, but haven't figured out the best way to go about this, yet.
@cgracey said:
I have not forgotten, but haven't figured out the best way to go about this, yet.
Ok thanks. It will help a lot for people who want to develop more advanced driver software and libraries etc, which can sometimes require more complicated builds.
@ManAtWork said:
@cgracey , how difficult would it be to add theese options to PNut?
I think, it shouldn't be much work because the actual operations are already implemented so it would only require adding the command line options and function calls.
This would be a great feature because it would enable using the graphical debug for all other compilers (at least on Windows). It would also solve this issue so we could use VSC together with FlexC without limitations on the debug output.
I've been looking into this and there are a bunch of compile-time dependencies when adding the debugger into the download. When the Spin2 compiler runs, it compiles all the DEBUG and clock-mode/freq data and then later incorporates it into the binary image which contains the debugger and (potentially) the flash loader. This isn't trivial to do and would require a lot of coordination with other tool makers. Then, if I were to make a change to how it all works, it would leave the other tools behind. It's probably not realistic to do.
@cgracey said:
I've been looking into this and there are a bunch of compile-time dependencies when adding the debugger into the download. When the Spin2 compiler runs, it compiles all the DEBUG and clock-mode/freq data and then later incorporates it into the binary image which contains the debugger and (potentially) the flash loader. This isn't trivial to do and would require a lot of coordination with other tool makers. Then, if I were to make a change to how it all works, it would leave the other tools behind. It's probably not realistic to do.
That's sad. But then, how does the pnut -debug work? Could we make it at least partially usable if we make some restrictions? Say, the user is responsible for setting the correct clock mode and baud rate and PNut only interprets the serial data stream and displays the graphical debug windows?
I think I could make a modification to loadP2 so that it inserts a small delay allowing PNut to take over the COM port before debug output starts.
@ManAtWork said:
@cgracey , how difficult would it be to add theese options to PNut?
I think, it shouldn't be much work because the actual operations are already implemented so it would only require adding the command line options and function calls.
I've been looking into this and there are a bunch of compile-time dependencies when adding the debugger into the download. When the Spin2 compiler runs, it compiles all the DEBUG and clock-mode/freq data and then later incorporates it into the binary image which contains the debugger and (potentially) the flash loader. This isn't trivial to do and would require a lot of coordination with other tool makers. Then, if I were to make a change to how it all works, it would leave the other tools behind. It's probably not realistic to do.
(1) @Wuerfel_21 already has done the work to integrate the debugger with flexspin, at least for a slightly older version of the debugger (v35, I think); but that isn't the main point, because
(2) I don't think @ManAtWork is interested so much in debugging as just using the fancy graphical features like plotting and drawing. For that, any program that can print text should work, shouldn't it? That is, a BASIC program like:
print "`TERM MyTerm SIZE 9 1 TEXTSIZE 40 COLOR red TITLE 'Temp Display'"
for i = 50 to 60
print "`MyTerm 1 'Temp="; i; "'"
pausems 1000
next i
should open a new window titled "Temp Display" with red text and then print some temperatures into it. For that purpose, isn't the baud rate the only thing that the PC side needs to be aware of? That could be set via a command line option, or even just defaulted to some predefined speed (like 2_000_000).
The BASIC example above works with FlexProp's debug display, but so far the only windows I've implemented are TERM and PLOT. I think many people would love to have SCOPE, BITMAP, and the other windows available, and that would be relatively easy if PNut could act as a terminal.
...then the comm port will be opened at the desired baud rate and all serial data will feed into the DEBUG handler. Isn't this all that's needed, or should we also download a binary (which might contain the flash programmer and DEBUG supervisor, too, in the case of PNut-compiled Spin2 programs)?
I'm confused. None of the command line options of PNut seem to work. No matter what I type on the command line PNut just opens a blank white editor window and does nothing else. No error message, no debug window. It also doesn't load the source file.
I've checked that I have the latest version. The about dialog displays "V34z". The downloaded file is named "PNut_v34zb.zip" which is said to be the signed version of 34z.
@ManAtWork
v37 of PNUT is the latest shared here, - see first page of this thread for download link.
Edit: I noticed the PLX homepage link is out-of-date, showing that 34z version. That'll be updated soon- sorry you got caught up with the old version.
Edit2: Homepage download link has been updated, and now points to this forum thread (post 1) where the latest version is always available.
@evanh said:
Having them copied to cogRAM over and over isn't very efficient. I'd like a way to say call this pasm code as execute-in-place hubexec.
JMP PB will jump to inline P2 code placed after an XBYTE bytecode. A _RET_ or RET at the end of this code followed by a NOP will start processing the next bytecode after the NOP. The latter is actually a dummy long that could be any value and is required due to pipelining. As can be seen this procedure is very simple and it works.
Note the JMP PB will reload the FIFO unnecessarily because the jump is to the next address / top of FIFO.
Comments
I went through that with my serial driver when Chip added FDEC to the debug keywords -- it was the name of one of my serial methods. Since serial use is common, it caused a few headaches
Of all the arbitrary keywords to add, it seems "field" hasn't been identified as being used by anyone else yet. Maybe after-all, that is the clearest & simplest choice, both for docs and code reading clarity ?
Doesn't feel like there will be many (or any) new words to add moving forward now. The language seems pretty well evolved at this point. Although over the years I well recall many new versions of C# having added keywords that trample older code, so I suppose it's just the small price of progress to make some adjustments to older code to access newer compilers. Perhaps it would be silly to have the clutter of "compile with version X compiler" options to the tools, but I suppose that's a possibility if this continues being an issue / progress keeps being made.
What about> @VonSzarvas said:
I kind of like FIELD. It's not all consonants and it means something.
New version 37 of PNut at the top of this thread.
New '...' can be used to ignore the rest of the line....
Does that mean comments added after the dots (within a comment symbol) will not cause a compile error ?
please try to add optional parameters to functions like Flex does.
PUB start(pin1, pin2, pin3 = 31, pin4=30)
when not given set default value. VERY useful.
Mike
Doesn't the
^@variablesyntax conflict with3 ^ @variable? Could you make it e.g.@^instead?It doesn't matter what comes after '...' before the line-end. It will all be ignored.
White space makes the difference.
Maybe @^ would be better.
Let me think about this. Not trivial to do.
Would using
.instead of^make sense?.isn't already an infix operator, and you already use.as a modifier for other operators.I have had to run the compatibility debugger for windows 10 each time I upgrade Pnut and it seems to fix the problem..
Thanks for reporting, and glad that solves it!
@cgracey , how difficult would it be to add theese options to PNut?
I think, it shouldn't be much work because the actual operations are already implemented so it would only require adding the command line options and function calls.
This would be a great feature because it would enable using the graphical debug for all other compilers (at least on Windows). It would also solve this issue so we could use VSC together with FlexC without limitations on the debug output.
That shouldn't be too hard to do.
That would be really nice, looking forward to it.
BTW, yesterday I tried
pnut -debugand found out that it just opens an empty (white) editor window but no (black) debug window. Does it need actual input fropm the COM port to start debugging or did I something wrong? I used pnut_v34z. BaudRate is just a number and CommPort must start with "COM", right? Sopnut -debug COM24 230400should work if I want to use COM24.Chip, I think some time back you may have mentioned you were going to look at ways to enable conditional compilation in PNut/PropTool. Is that feature still on your radar, or has it slipped back a bit? I know I've asked about it before, I still live in hope...
I am not sure and I'm away from my computer at the moment. A later version of PNut might act better. I remember making a bunch of changes a few versions ago that helped command line debugging.
I have not forgotten, but haven't figured out the best way to go about this, yet.
Ok thanks. It will help a lot for people who want to develop more advanced driver software and libraries etc, which can sometimes require more complicated builds.
I've been looking into this and there are a bunch of compile-time dependencies when adding the debugger into the download. When the Spin2 compiler runs, it compiles all the DEBUG and clock-mode/freq data and then later incorporates it into the binary image which contains the debugger and (potentially) the flash loader. This isn't trivial to do and would require a lot of coordination with other tool makers. Then, if I were to make a change to how it all works, it would leave the other tools behind. It's probably not realistic to do.
That's sad. But then, how does the
pnut -debugwork? Could we make it at least partially usable if we make some restrictions? Say, the user is responsible for setting the correct clock mode and baud rate and PNut only interprets the serial data stream and displays the graphical debug windows?I think I could make a modification to loadP2 so that it inserts a small delay allowing PNut to take over the COM port before debug output starts.
(1) @Wuerfel_21 already has done the work to integrate the debugger with flexspin, at least for a slightly older version of the debugger (v35, I think); but that isn't the main point, because
(2) I don't think @ManAtWork is interested so much in debugging as just using the fancy graphical features like plotting and drawing. For that, any program that can print text should work, shouldn't it? That is, a BASIC program like:
should open a new window titled "Temp Display" with red text and then print some temperatures into it. For that purpose, isn't the baud rate the only thing that the PC side needs to be aware of? That could be set via a command line option, or even just defaulted to some predefined speed (like 2_000_000).
The BASIC example above works with FlexProp's debug display, but so far the only windows I've implemented are TERM and PLOT. I think many people would love to have SCOPE, BITMAP, and the other windows available, and that would be relatively easy if PNut could act as a terminal.
If you do...
PNut_v37 -debug {CommPort} {BaudRate}...then the comm port will be opened at the desired baud rate and all serial data will feed into the DEBUG handler. Isn't this all that's needed, or should we also download a binary (which might contain the flash programmer and DEBUG supervisor, too, in the case of PNut-compiled Spin2 programs)?
I'm confused. None of the command line options of PNut seem to work. No matter what I type on the command line PNut just opens a blank white editor window and does nothing else. No error message, no debug window. It also doesn't load the source file.
I've checked that I have the latest version. The about dialog displays "V34z". The downloaded file is named "PNut_v34zb.zip" which is said to be the signed version of 34z.
@ManAtWork
v37 of PNUT is the latest shared here, - see first page of this thread for download link.
Edit: I noticed the PLX homepage link is out-of-date, showing that 34z version. That'll be updated soon- sorry you got caught up with the old version.
Edit2: Homepage download link has been updated, and now points to this forum thread (post 1) where the latest version is always available.
Thanks @VonSzarvas, with V37 it works! PNut -debug opens the DEBUG window and displays the output from the P2.
I have to try out if I can get it to work together with VSC and FlexC.
Chip,
I have a few pasm coded routines I use a lot in spin2. But they aren't fast loops but rather just making use of special hardware. eg:
PUB muldiv65( mult1, mult2, divisor ) : result ' 32bit result = 32bit x 32bit / 32bit ' Rounding to nearest variant of muldiv64() org qmul mult1, mult2 mov result, divisor shr result, #1 getqx mult1 ' lower 32 bits of 64-bit intermediate getqy mult2 ' upper 32 bits of 64-bit intermediate add mult1, result wc ' round-to-nearest addx mult2, #0 ' round-to-nearest setq mult2 qdiv mult1, divisor getqx result endHaving them copied to cogRAM over and over isn't very efficient. I'd like a way to say call this pasm code as execute-in-place hubexec.
JMP PBwill jump to inline P2 code placed after an XBYTE bytecode. A_RET_orRETat the end of this code followed by aNOPwill start processing the next bytecode after theNOP. The latter is actually a dummy long that could be any value and is required due to pipelining. As can be seen this procedure is very simple and it works.Note the
JMP PBwill reload the FIFO unnecessarily because the jump is to the next address / top of FIFO.I'm not the wiser as yet. Was there an example removed?