Chip,
can you also toggle RTS concurrently to DTR for a reset. This will allow to use also USB to Serial chips which have only RTS outputs.
PropTool and flexProp have an option for RTS-reset, only PNUT does not provide this.
If that's supposed to be a hard reset then it's missing a digit. What it is doing at the moment is enabling the PLL, disabling the crystal oscillator, and switching to RCFAST clock source.
@Cluso99 said:
pnut is not part of PropTool, but a copy of it with some necessary changes AFAIK.
PropTool’s inbuilt compiler is a (modified???) copy of pnut from some perhaps/often prior version on pnut.
PNut is our R&D software that is built/modified any time a new/modified feature of the compiler or debugger system is needed for the P2 (and the P1 years ago).
Propeller Tool is our full editor system meant for general use and has its own set of design goals.
Propeller Tool uses the Compiler from the PNut editor (unmodified) and the Debugger system from the PNut editor (modified only very slightly; so far). The latest version of the compiler and debugger are in PNut first, and Propeller Tool second. The timing of this varies and we are striving to make it faster.
You can determine the version of the Compiler/Debugger (as it relates to PNut) that is included in Propeller Tool by looking at the Release notes for Propeller Tool and searching for "PNut."
@cgracey : I mentioned this in the floating point thread but I'm not sure if you saw it. PNut seems to parse "-1.0" in PUB methods as "-(1.0)" and hence produces $c080_0000, the 32 bit two's complement of the number, instead of $bf80_0000, the floating point representation of negative 1. I don't know what the heck it's doing in DAT sections, but it's outputting "0" for negative floats declared there. The CON section seems to be OK.
For example:
CON
_clkfreq = 180_000_000
a_con = -1.0
DAT
a_dat
long -1.0
PUB demo() | a
a := -1.0
DEBUG(uhex(a))
DEBUG(uhex(a_dat))
DEBUG(uhex(a_con))
shows $C0800000 $00000000 and $BF800000. If I change all the "-1.0" to "1.0" then all three show up as the correct $3F800000.
Is this working as intended? The DAT section, at least, seems somewhat off.
@ersmith said:
@cgracey : I mentioned this in the floating point thread but I'm not sure if you saw it. PNut seems to parse "-1.0" in PUB methods as "-(1.0)" and hence produces $c080_0000, the 32 bit two's complement of the number, instead of $bf80_0000, the floating point representation of negative 1. I don't know what the heck it's doing in DAT sections, but it's outputting "0" for negative floats declared there. The CON section seems to be OK.
For example:
CON
_clkfreq = 180_000_000
a_con = -1.0
DAT
a_dat
long -1.0
PUB demo() | a
a := -1.0
DEBUG(uhex(a))
DEBUG(uhex(a_dat))
DEBUG(uhex(a_con))
shows $C0800000 $00000000 and $BF800000. If I change all the "-1.0" to "1.0" then all three show up as the correct $3F800000.
Is this working as intended? The DAT section, at least, seems somewhat off.
Eric, I must have broken something a while back. Thanks for pointing this out. I will look at it.
If that's supposed to be a hard reset then it's missing a digit.
Yes, thank you ! I did a mistake, I don't know why did I typed the command without the missing zero. It was confusing, because when I executed the wrong command (without repeat) it looked as if it was actually resetting the chip over and over again in a loop. And then when I tested with the repeat loop and it didn't has the same debug output.
Later I have done more testing, and I have found that because I am uploading into RAM then the reset will just stop there even if there is a repeat loop. I guess this is because the reset will erase RAM. Only if I program flash maybe I could see some loop.
Chip,
I just tried editing with Pnut and found an oddity that didn't used to happen with Wine. The cursor no longer lines up with the text that you're editing. It's horizontally further to the right by maybe an additional 50%.
After looking through my archive of zips I see the regression happened between v34s and v34ta.
PS: It's not a biggie. As you can tell, I haven't been using it for editing anyway.
@evanh said:
Chip,
I just tried editing with Pnut and found an oddity that didn't used to happen with Wine. The cursor no longer lines up with the text that you're editing. It's horizontally further to the right by maybe an additional 50%.
After looking through my archive of zips I see the regression happened between v34s and v34ta.
PS: It's not a biggie. As you can tell, I haven't been using it for editing anyway.
Thanks, Evan. By 50%, do you mean 50% of a character or of the window? What if you do Ctrl-Up or Ctrl-Down, does it correct?
Nope, font size adjustment doesn't help. The offset scales equally.
It's dynamic, following the characters. The further across the line the larger the offset.
Also, if I use the mouse to select text from right to left the text will shift as I drag the selection box. First character selected will jump the whole offset with a gap formed between the selected and unselected. Each step in the selection the selected text moves a little left, until once the whole line is selected it is back in the unselected position.
There is no pixel glitching, the font looks tidy the whole time.
It's like there is two settings for specifying a fixed-width of the font, and they aren't matching. It may be highlighting a bug in Wine.
Using PNUT v34zb i think i have found some unexpected behaviour
con
_clkfreq=100_000_000
dat
org
rep @done,#0
drvnot #0
done
If I compile it with PNUT it knows about the 100MHz set in the con block and the P2 is indeed running with 100MHz after downloading to ram via PNUT. In the .bin file there are only 8 bytes as expected. It seems PNUT uses the bootloader feature to change the Clock to PLL 100MHz. This may be an unexpected behaviour.
In the .lst file PNUT incudes the clock settings.
TYPE: CON VALUE: 05F5E100 NAME: _CLKFREQ
TYPE: CON VALUE: 0100090B NAME: CLKMODE_
TYPE: CON VALUE: 05F5E100 NAME: CLKFREQ_
TYPE: DAT_LONG VALUE: 00200008 NAME: DONE
CLKMODE: $0100090B
CLKFREQ: 100,000,000
XINFREQ: 20,000,000
Hub bytes: 8
00000- 00 02 DC FC 5F 00 64 FD '...._.d.'
@Surac said:
Using PNUT v34zb i think i have found some unexpected behaviour
con
_clkfreq=100_000_000
dat
org
rep @done,#0
drvnot #0
done
If I compile it with PNUT it knows about the 100MHz set in the con block and the P2 is indeed running with 100MHz after downloading to ram via PNUT. In the .bin file there are only 8 bytes as expected. It seems PNUT uses the bootloader feature to change the Clock to PLL 100MHz. This may be an unexpected behaviour.
In the .lst file PNUT incudes the clock settings.
TYPE: CON VALUE: 05F5E100 NAME: _CLKFREQ
TYPE: CON VALUE: 0100090B NAME: CLKMODE_
TYPE: CON VALUE: 05F5E100 NAME: CLKFREQ_
TYPE: DAT_LONG VALUE: 00200008 NAME: DONE
CLKMODE: $0100090B
CLKFREQ: 100,000,000
XINFREQ: 20,000,000
Hub bytes: 8
00000- 00 02 DC FC 5F 00 64 FD '...._.d.'
You need to add the ASMCLK instruction to establish the clock mode at run time.
@cgracey said:
You need to add the ASMCLK instruction to establish the clock mode at run time.
Hi @cgracey
Thanks for the answer. I already knew about the ASMCLK macro, but what i do not know is how to tell PNUT not to set any clock information while downloading?
@Ariba said:
Just remove the: _clkfreq = 100_000_000
Thank you!
So PNUT reacting to this line in a pasm only program is unexpected.
BUT for asmclk to work _clkfreq must been set... and PNUT then sets the clock while downloading
I know it is not a big deal but imagine the following scenario:
initialize all your program using rcfast and later change the clock to lets say 100 MHz
i must omit _clkfreq = 100_000_000 in the CON block (means i can't use asmclk later)
programm the clock to pll by hand later (no big deal but why?)
I think PNUT programming the clock while downloading should be omitted, it serves nobody
@evanh said:
Surac,
Your imagined scenario is actually the default behaviour, and has been since day dot. I don't see what the complaint is.
Hi
The complaint is:
If PNUT sees a _clkferq=xxxx line in a CON block it will automatically behind the scenes programme the clock WHILE DOWNLADING to ram, regardless of it is a SPIN, SPIN2 or PSAM only program.
To NOT have PNUT program the clock while downloading you must omit the _clkferq=xxxx line in the CON block. But this makes using the ASMCLK macro impossible, because it relies on having a _clkferq=xxxx line in a CON block. So starting up in RCFAST is only possible if you omit _clkferq=xxxx line what makes using ASMCLK later impossible. THIS IS ONLY HAPPENS IF YOU USE PNUT TO COMPILE AND DOWNLOAD.
Not even PropTools (wich contains PNUT to some part) or FLEXPROP shows this behaviour
Sorry if it is hard to understand what i write, English ist not my first language
Flexspin (Flexprop) simply doesn't support ASMCLK at all. I'm guessing from what you're saying neither does Proptool ... yet. And yet you seem to be saying you want to use ASMCLK.
Maybe you're wanting to dynamically set the clock frequency. ASMCLK doesn't do that of course, it's all pre-calculated at assembly time and inlined, like a macro.
There is various examples but probably not a tidy one in pure assembly. My own routine has the XMUL component as the singular parameter. It provides a good selection of frequencies but, since the other components are constants, there is no searching for optimal combinations.
@evanh said:
Flexspin (Flexprop) simply doesn't support ASMCLK at all. I'm guessing from what you're saying neither does Proptool ... yet. And yet you seem to be saying you want to use ASMCLK.
Just try it, they both do. ASMCLK works like a charm in both, and they both do not program the P2 clock while downloading to RAM.
Maybe you're wanting to dynamically set the clock frequency. ASMCLK doesn't do that of course, it's all pre-calculated at assembly time and inlined, like a macro.
No, i understand how it's done. I just wanted to point out that PNUT has some wired behaviour (or bug) while downloading to RAM. If this is not the right tread for such a thing, please forgive me
If reporting a strange behaviour (or bug) is not desired, please forgive me.
Eric has clarified that previously. What's happening is the text "ASMCLK" in the source file is treated as a label in Flexspin. So there is no error or even a warning. But there no code generated, it doesn't set the clock frequency, your program stays on RCFAST when assembled with Flexspin.
This has caused some sad faces already because it is a compatibility issue. On that basis, Eric would rather ASMCLK didn't exist either.
@evanh
Soory, you seem to miss that my complaint is not a concern of code generation but in the process of downloading the code to p2 ram
And if you have a look in the code generated by proptooks and flexspin you can see that asmclk works quite well
My problem is NOT asmclk
My problem is how PNUT downloads the code, as it uses a bootloader feature to set the clock before p2 starts executing the code
@evanh said:
Pnut downloading is always done at RCFAST. Chip has even said so just above.
Yes, it starts in RCFAST, but PNUT then uses the "Prop_Clk" command over the serial bootloader to set the clock. This seems ether unintentional or Chip just forgot about it.
Comments
Chip,
can you also toggle RTS concurrently to DTR for a reset. This will allow to use also USB to Serial chips which have only RTS outputs.
PropTool and flexProp have an option for RTS-reset, only PNUT does not provide this.
Andy
If that's supposed to be a hard reset then it's missing a digit. What it is doing at the moment is enabling the PLL, disabling the crystal oscillator, and switching to RCFAST clock source.
PNut is our R&D software that is built/modified any time a new/modified feature of the compiler or debugger system is needed for the P2 (and the P1 years ago).
Propeller Tool is our full editor system meant for general use and has its own set of design goals.
Propeller Tool uses the Compiler from the PNut editor (unmodified) and the Debugger system from the PNut editor (modified only very slightly; so far). The latest version of the compiler and debugger are in PNut first, and Propeller Tool second. The timing of this varies and we are striving to make it faster.
You can determine the version of the Compiler/Debugger (as it relates to PNut) that is included in Propeller Tool by looking at the Release notes for Propeller Tool and searching for "PNut."
@cgracey : I mentioned this in the floating point thread but I'm not sure if you saw it. PNut seems to parse "-1.0" in PUB methods as "-(1.0)" and hence produces $c080_0000, the 32 bit two's complement of the number, instead of $bf80_0000, the floating point representation of negative 1. I don't know what the heck it's doing in DAT sections, but it's outputting "0" for negative floats declared there. The CON section seems to be OK.
For example:
shows $C0800000 $00000000 and $BF800000. If I change all the "-1.0" to "1.0" then all three show up as the correct $3F800000.
Is this working as intended? The DAT section, at least, seems somewhat off.
Eric, I must have broken something a while back. Thanks for pointing this out. I will look at it.
Yes, thank you ! I did a mistake, I don't know why did I typed the command without the missing zero. It was confusing, because when I executed the wrong command (without repeat) it looked as if it was actually resetting the chip over and over again in a loop. And then when I tested with the repeat loop and it didn't has the same debug output.
Later I have done more testing, and I have found that because I am uploading into RAM then the reset will just stop there even if there is a repeat loop. I guess this is because the reset will erase RAM. Only if I program flash maybe I could see some loop.
Chip,
I just tried editing with Pnut and found an oddity that didn't used to happen with Wine. The cursor no longer lines up with the text that you're editing. It's horizontally further to the right by maybe an additional 50%.
After looking through my archive of zips I see the regression happened between v34s and v34ta.
PS: It's not a biggie. As you can tell, I haven't been using it for editing anyway.
Thanks, Evan. By 50%, do you mean 50% of a character or of the window? What if you do Ctrl-Up or Ctrl-Down, does it correct?
Nope, font size adjustment doesn't help. The offset scales equally.
It's dynamic, following the characters. The further across the line the larger the offset.
Also, if I use the mouse to select text from right to left the text will shift as I drag the selection box. First character selected will jump the whole offset with a gap formed between the selected and unselected. Each step in the selection the selected text moves a little left, until once the whole line is selected it is back in the unselected position.
There is no pixel glitching, the font looks tidy the whole time.
It's like there is two settings for specifying a fixed-width of the font, and they aren't matching. It may be highlighting a bug in Wine.
Maybe you're missing the font? IIRC PNut uses Consolas, which needs to be manually installed in Wine
It's true, I don't possess that font ... Yep, installing Consolas does fix the issue. The font size is different now too.
So, Pnut v34s and earlier were just using a different font back then?
I think they were using "courier new". Maybe I should make it selectable between courier/consolas/parallax fonts.
Parallax font! I do have that installed already.
Using PNUT v34zb i think i have found some unexpected behaviour
con _clkfreq=100_000_000 dat org rep @done,#0 drvnot #0 doneIf I compile it with PNUT it knows about the 100MHz set in the con block and the P2 is indeed running with 100MHz after downloading to ram via PNUT. In the .bin file there are only 8 bytes as expected. It seems PNUT uses the bootloader feature to change the Clock to PLL 100MHz. This may be an unexpected behaviour.
In the .lst file PNUT incudes the clock settings.
We are up to pnut35L IIRC.
You need to add the ASMCLK instruction to establish the clock mode at run time.
Hi @cgracey
Thanks for the answer. I already knew about the ASMCLK macro, but what i do not know is how to tell PNUT not to set any clock information while downloading?
Thank you!
i just downloaded PNUT from https://parallax.com/propeller-2/programming-tools/ but was not aware that the Parallax site was outdated
Just remove the:
_clkfreq = 100_000_000Surac, if you download a PASM-only program, your program starts in RCFAST mode (internal >20MHz mode).
Thank you!
So PNUT reacting to this line in a pasm only program is unexpected.
BUT for asmclk to work _clkfreq must been set... and PNUT then sets the clock while downloading
I know it is not a big deal but imagine the following scenario:
initialize all your program using rcfast and later change the clock to lets say 100 MHz
I think PNUT programming the clock while downloading should be omitted, it serves nobody
Surac,
Your imagined scenario is actually the default behaviour, and has been since day dot. I don't see what the complaint is.
Hi
The complaint is:
Sorry if it is hard to understand what i write, English ist not my first language
Flexspin (Flexprop) simply doesn't support ASMCLK at all. I'm guessing from what you're saying neither does Proptool ... yet. And yet you seem to be saying you want to use ASMCLK.
Maybe you're wanting to dynamically set the clock frequency. ASMCLK doesn't do that of course, it's all pre-calculated at assembly time and inlined, like a macro.
There is various examples but probably not a tidy one in pure assembly. My own routine has the XMUL component as the singular parameter. It provides a good selection of frequencies but, since the other components are constants, there is no searching for optimal combinations.
Just try it, they both do. ASMCLK works like a charm in both, and they both do not program the P2 clock while downloading to RAM.
No, i understand how it's done. I just wanted to point out that PNUT has some wired behaviour (or bug) while downloading to RAM. If this is not the right tread for such a thing, please forgive me
If reporting a strange behaviour (or bug) is not desired, please forgive me.
Eric has clarified that previously. What's happening is the text "ASMCLK" in the source file is treated as a label in Flexspin. So there is no error or even a warning. But there no code generated, it doesn't set the clock frequency, your program stays on RCFAST when assembled with Flexspin.
This has caused some sad faces already because it is a compatibility issue. On that basis, Eric would rather ASMCLK didn't exist either.
Huh? What do you mean not?! That's ASMCLK's only purpose. It's not working at all if it fails to program the clock frequency.
@evanh
Soory, you seem to miss that my complaint is not a concern of code generation but in the process of downloading the code to p2 ram
And if you have a look in the code generated by proptooks and flexspin you can see that asmclk works quite well
My problem is NOT asmclk
My problem is how PNUT downloads the code, as it uses a bootloader feature to set the clock before p2 starts executing the code
Huh, just downloaded the newest Flexspin and found it now supports ASMCLK. And here's what it generates now:
And comparing that to Pnut's equivalent list file:
They're a byte for byte match!
PS: This example is for _clkfreq = 50_000_000
Pnut downloading is always done at RCFAST. Chip has even said so just above.
Yes, it starts in RCFAST, but PNUT then uses the "Prop_Clk" command over the serial bootloader to set the clock. This seems ether unintentional or Chip just forgot about it.