@cgracey said:
I just tried something on a lark and it actually works now:
CON download_baud = 3_000_000 'debug_baud will inherit the download_baud value
The new serial works at 3 Megabaud!
Did you test any of this running via a FT232H or FT2232H ?
Running those HS Serial links, should let you shake out bugs in the code, as the driver-side of those have higher thru-put limits, and larger HW buffers.
It would also be useful to compare where WINE systems fail, if running those HS-USB Serial parts.
There are growing serial bridge choices these days, I have some CH9102 parts here and some PL2303GC which are FS-USB parts with different top baud speeds.
There is also a CH347 I'd like to trial, (TSSOP20 HS-USB) when I can source a module.
@cgracey said:
I just tried something on a lark and it actually works now:
CON download_baud = 3_000_000 'debug_baud will inherit the download_baud value
The new serial works at 3 Megabaud!
Did you test any of this running via a FT232H or FT2232H ?
Running those HS Serial links, should let you shake out bugs in the code, as the driver-side of those have higher thru-put limits, and larger HW buffers.
It would also be useful to compare where WINE systems fail, if running those HS-USB Serial parts.
There are growing serial bridge choices these days, I have some CH9102 parts here and some PL2303GC which are FS-USB parts with different top baud speeds.
There is also a CH347 I'd like to trial, (TSSOP20 HS-USB) when I can source a module.
I have an FT231XS chip on my prop plug. The part is supposed to be good for 3M baud. That's all I've got.
In order to get 3Mbaud working, the Latency Timer needs to be set to 1ms in the Device Manager, in order to not overflow the internal buffers, and having a dedicated thread in Windows helps, too.
@cgracey said:
I just tried something on a lark and it actually works now:
CON download_baud = 3_000_000 'debug_baud will inherit the download_baud value
The new serial works at 3 Megabaud!
Did you test any of this running via a FT232H or FT2232H ?
Running those HS Serial links, should let you shake out bugs in the code, as the driver-side of those have higher thru-put limits, and larger HW buffers.
It would also be useful to compare where WINE systems fail, if running those HS-USB Serial parts.
There are growing serial bridge choices these days, I have some CH9102 parts here and some PL2303GC which are FS-USB parts with different top baud speeds.
There is also a CH347 I'd like to trial, (TSSOP20 HS-USB) when I can source a module.
I have an FT231XS chip on my prop plug. The part is supposed to be good for 3M baud. That's all I've got.
In order to get 3Mbaud working, the Latency Timer needs to be set to 1ms in the Device Manager, in order to not overflow the internal buffers, and having a dedicated thread in Windows helps, too.
The HS-USB link uses a 125us frame, and most HS-USB bridge parts have larger HW buffers. You can also define larger PC-side buffers as part of the open step.
The CH347 data says this : Each serial port has a built-in 12K-byte receive FIFO and a 4K-byte transmit FIFO.
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.
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.
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.
That is interesting, Macca. What do you use for a compiler inside it?
No external compiler, all integrated, developed my own by reverse engineering PropTools and PNut binary outputs (with some help from the interpreter source).
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.
That is interesting, Macca. What do you use for a compiler inside it?
No external compiler, all integrated, developed my own by reverse engineering PropTools and PNut binary outputs (with some help from the interpreter source).
Wow! That is quite an endeavor.
I put the compiler for our tools into a github repository. I just updated it today with the latest stuff. Do you ever look at that?
PASM-only programs which use non-RCFAST clock modes now get prepended with a 16-long clock-setter program which sets the clock mode, moves the PASM program down into position, and then executes it. This means that the ASMCLK instruction is no longer needed at the start of PASM-only programs. This harmonizes with the PASM-level debugger's operation, where the clock is automatically set.
I see why - So debug() can stay as a set at assemble-time sysclock frequency ... Not the direction I was hoping this would take.
Automatic clock setup added for PASM-only programs. No more need for ASMCLK.
That sounds troublesome. Where and how does that happen?
From the version notes:
"PASM-only programs which use non-RCFAST clock modes now get prepended with a 16-long clock-setter program which sets the clock mode, moves the PASM program down into position, and then executes it. This means that the ASMCLK instruction is no longer needed at the start of PASM-only programs. This harmonizes with the PASM-level debugger's operation, where the clock is automatically set."
There could be a symbol which, if defined, would disable this 16-long program from being prepended to your PASM-only program. Then, you would have to manually control it.
It is impossible to single-step through clock-setting code, because it affects the serial baudrate and blows up the debugger. So, it's good to get it out of the way. It makes stepping through small PASM programs so much cleaner, because you don't have the awkward clock-setting ASMCLK code to work around and you don't have to suffer it cluttering up your code.
PASM-only programs which use non-RCFAST clock modes now get prepended with a 16-long clock-setter program which sets the clock mode, moves the PASM program down into position, and then executes it. This means that the ASMCLK instruction is no longer needed at the start of PASM-only programs. This harmonizes with the PASM-level debugger's operation, where the clock is automatically set.
I see why - So debug() can stay as a set at assemble-time sysclock frequency ... Not the direction I was hoping this would take.
About the ASMCLK code where there are six instructions which set a crystal/PLL combo, I should probably precede it with a REP #6,#1 instruction to shield it from interrupts, especially debug interrupts.
At the moment I generally don't use debug() for one reason - It breaks when run-time adjusting the sysclock frequency.
In my own diagnostic printing code, that I maintain, I have a two step process of adjusting the sysclock frequency then adjusting the baud ratio of the serial pins. eg:
Here's my existing pllset() source code (Based off your posted compile-time source). It has a one line commented baudval(), straight after its clkset() call, ready to be uncommented when such a function exists as standard:
pub pllset( targetfreq ) : xinfreq | mode, mult, divd, divp, post, Fpfd, Fvco, error, besterror, vcolimit
mode := clkmode_
if clkmode_ >> 24 & 1 ' compiled with PLL on
divd := clkmode_ >> 18 & $3f + 1
mult := clkmode_ >> 8 & $3ff + 1
divp := (clkmode_ >> 4 + 1) & $f
divp := divp ? divp * 2 : 1
xinfreq := muldiv65( divp * divd, clkfreq_, mult )
elseif clkmode_ >> 2 & 3 ' compiled with PLL off
xinfreq := clkfreq_ ' clock pass-through
else ' unknown build mode
xinfreq := 20_000_000 ' default to 20 MHz crystal
mode := %10_00 ' default to 15 pF loading
mode := %11_11 & mode | %11 ' keep %CC, force %SS, ditch the rest
besterror := div33( targetfreq, 100 ) ' _errfreq at 1.0% of targetfreq
vcolimit := targetfreq + besterror
vcolimit := vcolimit < 201_000_000 ? 201_000_000 : vcolimit
repeat post from 0 to 15
divp := post ? post * 2 : 1
repeat divd from 64 to 1
Fpfd := div33( xinfreq, divd )
mult := muldiv65( divp * divd, targetfreq, xinfreq )
Fvco := muldiv65( xinfreq, mult, divd )
if Fpfd >= 250_000 and mult <= 1024 and Fvco > 99_000_000 and Fvco <= vcolimit
error := div33( Fvco, divp ) - targetfreq
if abs( error ) <= abs( besterror ) ' the last iteration at equality gets priority
besterror := error
mode := (mode&%11_11) | 1<<24 | (divd-1)<<18 | (mult-1)<<8 | ((post-1)&15)<<4
if mode.[24] ' PLL-ON bit set when calculation is valid
clkset( mode, targetfreq + besterror ) ' make the frequency change
' baudval() ' recalibrate debug comms as well
else
xinfreq := -1 ' failed, no change
@"frank freedman" said:
Just installed the latest Pnut-spin2 v35v. Norton 360 choked on the .exe file. Is this a false Norton indication?
The file is fine. It was not signed, though, which may be causing the problem. Jeff here at Parallax usually signs files, but I just posted it without signing.
@evanh said:
Here's my existing pllset() source code (Based off your posted compile-time source). It has a one line commented baudval(), straight after its clkset() call, ready to be uncommented when such a function exists as standard:
pub pllset( targetfreq ) : xinfreq | mode, mult, divd, divp, post, Fpfd, Fvco, error, besterror, vcolimit
mode := clkmode_
if clkmode_ >> 24 & 1 ' compiled with PLL on
divd := clkmode_ >> 18 & $3f + 1
mult := clkmode_ >> 8 & $3ff + 1
divp := (clkmode_ >> 4 + 1) & $f
divp := divp ? divp * 2 : 1
xinfreq := muldiv65( divp * divd, clkfreq_, mult )
elseif clkmode_ >> 2 & 3 ' compiled with PLL off
xinfreq := clkfreq_ ' clock pass-through
else ' unknown build mode
xinfreq := 20_000_000 ' default to 20 MHz crystal
mode := %10_00 ' default to 15 pF loading
mode := %11_11 & mode | %11 ' keep %CC, force %SS, ditch the rest
besterror := div33( targetfreq, 100 ) ' _errfreq at 1.0% of targetfreq
vcolimit := targetfreq + besterror
vcolimit := vcolimit < 201_000_000 ? 201_000_000 : vcolimit
repeat post from 0 to 15
divp := post ? post * 2 : 1
repeat divd from 64 to 1
Fpfd := div33( xinfreq, divd )
mult := muldiv65( divp * divd, targetfreq, xinfreq )
Fvco := muldiv65( xinfreq, mult, divd )
if Fpfd >= 250_000 and mult <= 1024 and Fvco > 99_000_000 and Fvco <= vcolimit
error := div33( Fvco, divp ) - targetfreq
if abs( error ) <= abs( besterror ) ' the last iteration at equality gets priority
besterror := error
mode := (mode&%11_11) | 1<<24 | (divd-1)<<18 | (mult-1)<<8 | ((post-1)&15)<<4
if mode.[24] ' PLL-ON bit set when calculation is valid
clkset( mode, targetfreq + besterror ) ' make the frequency change
' baudval() ' recalibrate debug comms as well
else
xinfreq := -1 ' failed, no change
I think we need to convey DEBUG baud to the debugger.
Since there is no guaranteed-unclaimed hub RAM, what if we put P62 and P63 into long-repository mode (P62 could output a steady high) outside of the debug interrupt ISR and we used them to hold ClkFreq and DebugBaud, so that the debugger could compute appropriate WXPIN values to configure the same pins for serial I/O?
How to notify of parameter passing? I was thinking there would be a debug command added. In which case the new command would be able to pass those needed variables into the protected space.
@evanh said:
How to notify of parameter passing? I was thinking there would be a debug command added. In which case the new command would be able to pass those needed variables into the protected space.
If you changed the ClkFreq, you would just do:
WXPIN ClkFreq,#62
If you wanted to change BOTH, which would probably not make sense, you would do:
WXPIN ClkFreq,#62
WXPIN DebugBaud,#63
The debugger ISR would do:
RQPIN ClkFreq,#62
RQPIN DebugBaud,#63
...in order to compute the WXPIN values for the same pins in serial mode.
Before leaving the ISR, it would return P62 and P63 to repository mode and reload the values it read.
...That would be best, because P62 could remain in async serial transmit mode, staying high, regardless of whether someone changed its OUT or DIR bit. P63 in repository mode would be impervious to OUT and DIR changes, as well.
It would be good to know whether or not DEBUG is active in Spin2. I could have the Spin2 interpreter's "CLKSET(NewCLKMODE, NewCLKFREQ)" instruction do a "WXPIN NewCLKFREQ,#63" when in DEBUG mode. I could just NOP the instruction from the compiler when DEBUG is off.
For PASM-only code, you would have to do the WXPIN yourself. You would always want to use a "REP #codesize,#1" to shield the clock change and WXPIN together.
Comments
Did you test any of this running via a FT232H or FT2232H ?
Running those HS Serial links, should let you shake out bugs in the code, as the driver-side of those have higher thru-put limits, and larger HW buffers.
It would also be useful to compare where WINE systems fail, if running those HS-USB Serial parts.
There are growing serial bridge choices these days, I have some CH9102 parts here and some PL2303GC which are FS-USB parts with different top baud speeds.
There is also a CH347 I'd like to trial, (TSSOP20 HS-USB) when I can source a module.
Addit: A search just found there is now a CH347 module, so I've ordered some to trial https://www.tindie.com/products/johnnywu/ch347-development-board/
I have an FT231XS chip on my prop plug. The part is supposed to be good for 3M baud. That's all I've got.
In order to get 3Mbaud working, the Latency Timer needs to be set to 1ms in the Device Manager, in order to not overflow the internal buffers, and having a dedicated thread in Windows helps, too.
The HS-USB link uses a 125us frame, and most HS-USB bridge parts have larger HW buffers. You can also define larger PC-side buffers as part of the open step.
The CH347 data says this : Each serial port has a built-in 12K-byte receive FIFO and a 4K-byte transmit FIFO.
Very good to hear! I agree!
I'm sure this will cause me troubles, but I have developed this thing a while ago:
https://forums.parallax.com/discussion/174436/spin-tools-ide
The discussion wasn't updated in a while, but if anybody is interested, the latest version is available here:
https://www.maccasoft.com/spin-tools-ide/
Just my 2cents.
That is interesting, Macca. What do you use for a compiler inside it?
No external compiler, all integrated, developed my own by reverse engineering PropTools and PNut binary outputs (with some help from the interpreter source).
Wow! That is quite an endeavor.
I put the compiler for our tools into a github repository. I just updated it today with the latest stuff. Do you ever look at that?
I posted a new PNut_v35v at the top of this thread.
I also update the P2_PNut_Public repository.
https://github.com/parallaxinc/P2_PNut_Public
That sounds troublesome. Where and how does that happen?
From the notes:
I see why - So debug() can stay as a set at assemble-time sysclock frequency ... Not the direction I was hoping this would take.
From the version notes:
"PASM-only programs which use non-RCFAST clock modes now get prepended with a 16-long clock-setter program which sets the clock mode, moves the PASM program down into position, and then executes it. This means that the ASMCLK instruction is no longer needed at the start of PASM-only programs. This harmonizes with the PASM-level debugger's operation, where the clock is automatically set."
There could be a symbol which, if defined, would disable this 16-long program from being prepended to your PASM-only program. Then, you would have to manually control it.
It is impossible to single-step through clock-setting code, because it affects the serial baudrate and blows up the debugger. So, it's good to get it out of the way. It makes stepping through small PASM programs so much cleaner, because you don't have the awkward clock-setting ASMCLK code to work around and you don't have to suffer it cluttering up your code.
Evan, what would you like to see?
About the ASMCLK code where there are six instructions which set a crystal/PLL combo, I should probably precede it with a REP #6,#1 instruction to shield it from interrupts, especially debug interrupts.
At the moment I generally don't use debug() for one reason - It breaks when run-time adjusting the sysclock frequency.
In my own diagnostic printing code, that I maintain, I have a two step process of adjusting the sysclock frequency then adjusting the baud ratio of the serial pins. eg:
lib.pllset( test_freq ) lib.baudinit( DEBUG_BAUD )An alternative would be incorporate the second step into
pllset()or evenclkset().Here's my existing
pllset()source code (Based off your posted compile-time source). It has a one line commentedbaudval(), straight after itsclkset()call, ready to be uncommented when such a function exists as standard:pub pllset( targetfreq ) : xinfreq | mode, mult, divd, divp, post, Fpfd, Fvco, error, besterror, vcolimit mode := clkmode_ if clkmode_ >> 24 & 1 ' compiled with PLL on divd := clkmode_ >> 18 & $3f + 1 mult := clkmode_ >> 8 & $3ff + 1 divp := (clkmode_ >> 4 + 1) & $f divp := divp ? divp * 2 : 1 xinfreq := muldiv65( divp * divd, clkfreq_, mult ) elseif clkmode_ >> 2 & 3 ' compiled with PLL off xinfreq := clkfreq_ ' clock pass-through else ' unknown build mode xinfreq := 20_000_000 ' default to 20 MHz crystal mode := %10_00 ' default to 15 pF loading mode := %11_11 & mode | %11 ' keep %CC, force %SS, ditch the rest besterror := div33( targetfreq, 100 ) ' _errfreq at 1.0% of targetfreq vcolimit := targetfreq + besterror vcolimit := vcolimit < 201_000_000 ? 201_000_000 : vcolimit repeat post from 0 to 15 divp := post ? post * 2 : 1 repeat divd from 64 to 1 Fpfd := div33( xinfreq, divd ) mult := muldiv65( divp * divd, targetfreq, xinfreq ) Fvco := muldiv65( xinfreq, mult, divd ) if Fpfd >= 250_000 and mult <= 1024 and Fvco > 99_000_000 and Fvco <= vcolimit error := div33( Fvco, divp ) - targetfreq if abs( error ) <= abs( besterror ) ' the last iteration at equality gets priority besterror := error mode := (mode&%11_11) | 1<<24 | (divd-1)<<18 | (mult-1)<<8 | ((post-1)&15)<<4 if mode.[24] ' PLL-ON bit set when calculation is valid clkset( mode, targetfreq + besterror ) ' make the frequency change ' baudval() ' recalibrate debug comms as well else xinfreq := -1 ' failed, no changeJust installed the latest Pnut-spin2 v35v. Norton 360 choked on the .exe file. Is this a false Norton indication?
The file is fine. It was not signed, though, which may be causing the problem. Jeff here at Parallax usually signs files, but I just posted it without signing.
I think we need to convey DEBUG baud to the debugger.
Since there is no guaranteed-unclaimed hub RAM, what if we put P62 and P63 into long-repository mode (P62 could output a steady high) outside of the debug interrupt ISR and we used them to hold ClkFreq and DebugBaud, so that the debugger could compute appropriate WXPIN values to configure the same pins for serial I/O?
How to notify of parameter passing? I was thinking there would be a debug command added. In which case the new command would be able to pass those needed variables into the protected space.
If you changed the ClkFreq, you would just do:
WXPIN ClkFreq,#62
If you wanted to change BOTH, which would probably not make sense, you would do:
WXPIN ClkFreq,#62
WXPIN DebugBaud,#63
The debugger ISR would do:
RQPIN ClkFreq,#62
RQPIN DebugBaud,#63
...in order to compute the WXPIN values for the same pins in serial mode.
Before leaving the ISR, it would return P62 and P63 to repository mode and reload the values it read.
Won't that just be overwritten on the next debug()?
I added to the prior post about this.
I don't think it would ever be necessary to actually change the baud rate, right? It would be ClkFreq that would have to be accounted for.
Maybe just P63 holds the ClkFreq in repository mode. The debug baud rate can be set by the compiler.
...That would be best, because P62 could remain in async serial transmit mode, staying high, regardless of whether someone changed its OUT or DIR bit. P63 in repository mode would be impervious to OUT and DIR changes, as well.
Oh, so the two smartpins continuously appear as repositories from the user perspective. Yeah, I'm good with that.
Yep, no problem. Wouldn't want to adjust target baud on the fly.
Okay. I will work on this today.
It would be good to know whether or not DEBUG is active in Spin2. I could have the Spin2 interpreter's "CLKSET(NewCLKMODE, NewCLKFREQ)" instruction do a "WXPIN NewCLKFREQ,#63" when in DEBUG mode. I could just NOP the instruction from the compiler when DEBUG is off.
For PASM-only code, you would have to do the WXPIN yourself. You would always want to use a "REP #codesize,#1" to shield the clock change and WXPIN together.