I've seen P1 do 160 MHz as long as there was only one cog running.
If you tried to start a second cog, it'd go belly up.
Wonder if P2 will be like that...
When overclocked by 2x? Yeah, that seems a certainty. Actually, I wonder if you'll even be able to overclock that much in the first place. The layout of the P2 die is bound to be significantly different from what we saw with the P1 (i.e., I don't expect clearly defined cog regions, for instance). I have to imagine that, in order to hit the desired "safe" frequency that Chip wants, the clocking tolerances are going to be fairly tight.
Would CLK+RESET be of any use?
..... Maybe if it would capture on reset, but that's still not useful, it seems.
I think there is already an external Capture, but what I'd call a higher precision model ?
Those high-precision, whole period ones, may be harder to explain and use, than a simple Capture & Reset, so yes, CLK+RESET(capture) sounds useful to me, as a 'spare mode filler'
With Capture & reset, you need only one edge, whilst the higher precision modes need at least two edges.
Addit : examples of simple one-edge echo style uses would be any sonar system, from the low precision Ping units (air), and there are linear probes that use speed of sound in metals & Magnetostrictive pulses.
I found more info on the pulse choices for Magnetostrictive Pulse Linear sensors.
Magnetostrictive Pulse - 4 Choices of Pulse type order code
(PWM is strictly Pulse High Width Modulation, L is ignored)
a) Control Pulse: Interrogate Pulse (IP)~1us Output Pulse (OP) ~1us Tp is probe delay k*mm
IP ___/==\___________________________________________________
OP _________________________________________________/==\_____
Tp |<--------------------- Tp ------------------>|
b) Start/Stop: Interrogate Pulse (IP) Output Pulse (OP)
IP ___/==\___________________________________________________
OP ____/==\_________________________________________/==\_____
Tp |<-------------------- Tp ------------------>|
c) PWM, External trigger Interrogate Pulse (IP) Output Pulse (OP)PWM
IP ___/==\___________________________________________________
OP ____/============================================\________
Tp |<-------------------- Tp ------------------>|
d) PWM, internal interrogation (one less wire, self retriggers)
IP nc
OP ____/============================================\_____/============================================\_____
Tp |<-------------------- Tp ------------------>| L |<-------------------- Tp ------------------>|
Data: "LOW OUTPUT VARIES DEPENDING ON LENGTH PROGRAMMED VIA DIP SW2 SWITCHES 1-6"
e) Choice of TTL and RS422 signaling.
Next step is to match P2 Smart Pin modes, to each of the above ?
Smart pin DOCs are very terse, but let's try anyway....
It is also not clear what rise or edge means, usually edge means change in level, does it mean either rise or fall ?
is %01 = A-input rise to B-input edge
== %01 = A-input rise to B-input change
== %01 = A-input rise to B-input rise or fall
'Count states' - what is a state ?
c) I think can use this one %10001 = Time A-input high states Continuous high states are counted in clock cycles.
Upon each high-to-low transition, the previous high duration count is placed in Z, and IN is raised.
d) can use above, or the smarter %10011 = For X periods, count time
- unclear which sub-mode for LEVEL gating ? or is this mode purely edges-only ?
%00 = A-input rise to B-input rise, where B = !A, would be A _/= to A =\_ which is HIGH time.
where X can accumulate whole pulse widths, over 10,16 or 100 (etc) echos to allow lower SysCLK speeds for same precision LSB
or, d) could use %10010 = Time X A-input highs Time is measured until X highs are accumulated.
b) can use A=B mapping, for %10011 = For X periods, count time
%00 = A-input rise to B-input rise
a) is trickier, provided IP pin is close to OP pin, It can use the same as b), but if IP is a distant pin ??
If the P2 'clips onto' an existing system, both Start and End are IP, so they can be close-by ?
However, if a P2 as master design wanted a common trigger for a dozen probes, that's outside A-B reach, so maybe
%10000 = Time A-input states ? - this seems to need 2 edges ?
Perhaps inverted version of : %10001 = Time A-input high states
Upon each high-to-low transition, the previous high duration count is placed in Z, and IN is raised.
Using !A, combined with software clear/start, that may work as Capture ?
!A means _/= captures TimeL -> Z, which is what is needed.
It is also not clear what rise or edge means, usually edge means change in level, does it mean either rise or fall ?
is %01 = A-input rise to B-input edge
== %01 = A-input rise to B-input change
== %01 = A-input rise to B-input rise or fall
'Count states' - what is a state ?
Yeah, that's about my understanding too. "States" is both high and low. "Edge" is both rise and fall. Some of the earlier modes say rising edge where the later modes just say rise.
I gather IP and OP are both digital inputs. And Tp is the time we want to measure/calculate, right?
In both b) and c), IP seems to be irrelevant.
IP and OP are probe-relative, & from the probe-end the Interrogate Pulse (IP)~1us is required for all modes, except D (as per the nc)
Where the P2 is master, it will generate the ~1us Interrogate Pulse (IP).
Where P2 is attached to some other system, it can passively read both IP and OP
From a measurement-angle, b) c) d) need no knowledge of the timing of IP, and those modes are more tolerant of cable length.
Mode a) includes any cable & driver delay in the Tp.
Okay. New v19 is done. See the first post in this thread.
I'll get the documentation updated in the next several hours. Just a few things to change there. The Google sheet for instruction encodings is done, already.
Looks like we lost 2 smart pins with P123 since last time I updated...
had to change all my wc,wz to wcz
need to change outn to DRVNOT
change SETLUT to LUTSON
change max to FLE (or FGE?) one of those anyway
bitn to bitnot
testin to testb ina,
setcz #0 to modcz _CLR,_CLR wcz
JNP to testp #DP wc then if_nc JMP?
Got a video driver working.
USB doesn't work though...
Might need Garryj's help...
Note to anyone that might be using Wine. With the release of Wine 2.8 the developers saw fit to mess around with how the comports assignment system works ...
Wine now automatically overwrites the old symbolic links, that one used to hand craft, with a predefined mapping of COM1 to COM32 for ISA mapped ports so that USB mapped ports then start at COM33 ... !!!
Chip,
I can't get any of the sample programs to run on the v19 image. Not even all_cogs_blink. Has the Prop2 download protocol changed from v18a to v19?
With v19 the behaviour of loadp2 now appears similar to PNut.exe. loadp2 still works fine if I put v18a back in the FPGA.
EDIT: Ah, I see Dave's loadp2 first downloads a small piece of built-in binary code labelled "mainloader", that'll need updated ... I presume I can use PNut to build the official MainLoader.spin2 file ...
Got a video driver working.
USB doesn't work though...
Might need Garryj's help...
Yep, there's definitely something amiss on the USB side, and my only guess right now is that it may be associated with LUT sharing. During startup, the host and driver cogs (host is cog0, driver is cog1) are getting started OK, the P2 clock gets set to 120Mhz OK, and the serial output, which is handled by the driver cog, gets started OK, as I'm getting splash banner text output to the terminal at 3Mbaud.
Both cogs are using SETLUTS #1 as both host and driver have several LUT locations in the "other" cog that they write to. But when the host cog tries to initialize a LUT location of the driver cog that it *should* have permission to write to, it appears to go off the rails at the WRLUT instruction. If I comment out this instruction, the host cog goes into its "idle" loop as it should. I've got things short-circuited to keep both cogs in their idle loops, if they get that far, and the only smart pin in use is serial TX.
So far, this is the only info I have. I've run out of time to play today, but I'll try to get back to it to tomorrow to dig further.
Chip,
I can't get any of the sample programs to run on the v19 image. Not even all_cogs_blink. Has the Prop2 download protocol changed from v18a to v19?
With v19 the behaviour of loadp2 now appears similar to PNut.exe. loadp2 still works fine if I put v18a back in the FPGA.
EDIT: Ah, I see Dave's loadp2 first downloads a small piece of built-in binary code labelled "mainloader", that'll need updated ... I presume I can use PNut to build the official MainLoader.spin2 file ...
The MainLoader.spin2 used with loadp2 is slightly different than Chip's version. However, it may not need to be recompiled as long as the codepoints haven't changed for the instructions it uses. There are two lines that need to be changed in loadp2.c. They are the following two lines
Chip,
I can't get any of the sample programs to run on the v19 image. Not even all_cogs_blink. Has the Prop2 download protocol changed from v18a to v19?
With v19 the behaviour of loadp2 now appears similar to PNut.exe. loadp2 still works fine if I put v18a back in the FPGA.
EDIT: Ah, I see Dave's loadp2 first downloads a small piece of built-in binary code labelled "mainloader", that'll need updated ... I presume I can use PNut to build the official MainLoader.spin2 file ...
Yes, PNut will compile the MainLoader.spin2 file. The error is due to now running at 120MHz. The WAITX values need adjusting. Also, MainLoader sets the clock to just 60MHz via 'CLKSET #$7F'.
I tried compiling the MainLoader.spin2 file used by loadp2, and it fails on the testin instruction. This needs to be changed to testp. I should change the name of the file I use so there's no confusion with Chip's version. After compiling with v19 there is one byte that is different in the generated binary as compared to v18. So in loadp2.c the hex code "4f" should be changed to "40" in the MainLoader string. This hex code is located in the middle of the MainLoader string. Just search for "4f" to find it.
So that change plus the other two lines should fix loadp2 for v19. That's assuming that everything works OK at 120MHz. If not, the clkset instruction should use $7F, and 60MHz should be used in the delay computations. Also, the third hex code in the MainLoader string would need to be changed from "65" to "64".
I just tested all the LUT events and they work okay.
The only difference from the last release is that the LUT r/w events are now sensed one clock later than they were before. I had to use some flops to capture the ENA, WR, and ADDR, in order to make sense of them in the next cycle, as there was insufficient time to do it all in one clock. So, the LUT events are sensed one clock later than they used to be, causing events/interrupts to trigger one clock later. It seems unlikely that anyone's code would be so sensitive to such a small change.
It looks to me like LUT sharing is working okay. I'll test the LUT events next.
Ah. Both cogs set up SE1 events to catch when the partner cog has written to their LUT.
Garryj, smart pin modes %011xx have changed and have been remapped, somewhat. Are you using any of those modes? The latest Google Doc explains the new modes.
Ok I'm made some progress with the V19 update changes.
This one took a while to pin down.
The result from a TESTB D,#S WZ is inverted compared to V19.
dat org
'v18 led is off
'v19 led is on
testb oz,#1 wz
drvz #32
jmp #$
oz long 2
I changed some IF_Z's to IF_NZ and things started working.
Still digging....
Ah, yes, I forgot about that. With all the flag-logic instructions, it seemed to me that we had better get rid of flag inversion on WZ. I hope garryj's problems are related to this change.
Comments
If you tried to start a second cog, it'd go belly up.
Wonder if P2 will be like that...
When overclocked by 2x? Yeah, that seems a certainty. Actually, I wonder if you'll even be able to overclock that much in the first place. The layout of the P2 die is bound to be significantly different from what we saw with the P1 (i.e., I don't expect clearly defined cog regions, for instance). I have to imagine that, in order to hit the desired "safe" frequency that Chip wants, the clocking tolerances are going to be fairly tight.
I think there is already an external Capture, but what I'd call a higher precision model ?
Those high-precision, whole period ones, may be harder to explain and use, than a simple Capture & Reset, so yes, CLK+RESET(capture) sounds useful to me, as a 'spare mode filler'
With Capture & reset, you need only one edge, whilst the higher precision modes need at least two edges.
Addit : examples of simple one-edge echo style uses would be any sonar system, from the low precision Ping units (air), and there are linear probes that use speed of sound in metals & Magnetostrictive pulses.
I found more info on the pulse choices for Magnetostrictive Pulse Linear sensors.
Next step is to match P2 Smart Pin modes, to each of the above ?
Smart pin DOCs are very terse, but let's try anyway....
It is also not clear what rise or edge means, usually edge means change in level, does it mean either rise or fall ?
is %01 = A-input rise to B-input edge
== %01 = A-input rise to B-input change
== %01 = A-input rise to B-input rise or fall
'Count states' - what is a state ?
c) I think can use this one
%10001 = Time A-input high states Continuous high states are counted in clock cycles.
Upon each high-to-low transition, the previous high duration count is placed in Z, and IN is raised.
d) can use above, or the smarter
%10011 = For X periods, count time
- unclear which sub-mode for LEVEL gating ? or is this mode purely edges-only ?
%00 = A-input rise to B-input rise, where B = !A, would be A _/= to A =\_ which is HIGH time.
where X can accumulate whole pulse widths, over 10,16 or 100 (etc) echos to allow lower SysCLK speeds for same precision LSB
or, d) could use
%10010 = Time X A-input highs Time is measured until X highs are accumulated.
b) can use A=B mapping, for
%10011 = For X periods, count time
%00 = A-input rise to B-input rise
a) is trickier, provided IP pin is close to OP pin, It can use the same as b), but if IP is a distant pin ??
If the P2 'clips onto' an existing system, both Start and End are IP, so they can be close-by ?
However, if a P2 as master design wanted a common trigger for a dozen probes, that's outside A-B reach, so maybe
%10000 = Time A-input states ? - this seems to need 2 edges ?
Perhaps inverted version of :
%10001 = Time A-input high states
Upon each high-to-low transition, the previous high duration count is placed in Z, and IN is raised.
Using !A, combined with software clear/start, that may work as Capture ?
!A means _/= captures TimeL -> Z, which is what is needed.
In both b) and c), IP seems to be irrelevant.
Where the P2 is master, it will generate the ~1us Interrogate Pulse (IP).
Where P2 is attached to some other system, it can passively read both IP and OP
From a measurement-angle, b) c) d) need no knowledge of the timing of IP, and those modes are more tolerant of cable length.
Mode a) includes any cable & driver delay in the Tp.
I'll get the documentation updated in the next several hours. Just a few things to change there. The Google sheet for instruction encodings is done, already.
had to change all my wc,wz to wcz
need to change outn to DRVNOT
change SETLUT to LUTSON
change max to FLE (or FGE?) one of those anyway
bitn to bitnot
testin to testb ina,
setcz #0 to modcz _CLR,_CLR wcz
JNP to testp #DP wc then if_nc JMP?
Got a video driver working.
USB doesn't work though...
Might need Garryj's help...
OUTNOT #PIN {WCZ} And I think to replace TESTIN, you can also use:
TESTP #PIN WC/WZ
Assembler now sees them as labels and not errors...
Think I'll just wait and hope garryj posts new version...
Getting rid of JNP/JP allowed things to run quite a bit faster. Most other changes were to harmonize mnemonics and flag effects (TESTB/TESTP).
Wine now automatically overwrites the old symbolic links, that one used to hand craft, with a predefined mapping of COM1 to COM32 for ISA mapped ports so that USB mapped ports then start at COM33 ... !!!
What the bloody hell were they thinking?!
Anyway, the new instruction on how to override, using regedit, this new behaviour with preset assignments again are provided here - https://wiki.winehq.org/index.php?title=Wine_User's_Guide&oldid=2519#Serial_and_Parallel_Ports
I can't get any of the sample programs to run on the v19 image. Not even all_cogs_blink. Has the Prop2 download protocol changed from v18a to v19?
With v19 the behaviour of loadp2 now appears similar to PNut.exe. loadp2 still works fine if I put v18a back in the FPGA.
EDIT: Ah, I see Dave's loadp2 first downloads a small piece of built-in binary code labelled "mainloader", that'll need updated ... I presume I can use PNut to build the official MainLoader.spin2 file ...
Both cogs are using SETLUTS #1 as both host and driver have several LUT locations in the "other" cog that they write to. But when the host cog tries to initialize a LUT location of the driver cog that it *should* have permission to write to, it appears to go off the rails at the WRLUT instruction. If I comment out this instruction, the host cog goes into its "idle" loop as it should. I've got things short-circuited to keep both cogs in their idle loops, if they get that far, and the only smart pin in use is serial TX.
So far, this is the only info I have. I've run out of time to play today, but I'll try to get back to it to tomorrow to dig further.
txval(3*80000000/LOADER_BAUD/2-6); txval(80000000/LOADER_BAUD-6);These assume a clock rate of 80MHz. With v19 the clock rate will be 120MHz, so those two lines should be changed totxval(3*120000000/LOADER_BAUD/2-6); txval(120000000/LOADER_BAUD-6);This may be all that needs to be changed.I'm away from home right now, so I won't be able to test this until I get back on Thursday.
Yes, PNut will compile the MainLoader.spin2 file. The error is due to now running at 120MHz. The WAITX values need adjusting. Also, MainLoader sets the clock to just 60MHz via 'CLKSET #$7F'.
Made all the changes to all my stuff, with some still not working.
I'll keep digging....
I just updated the WMLONG description in the Google Doc to reflect this change. Thanks for pointing this out. Sorry I forgot about that.
So that change plus the other two lines should fix loadp2 for v19. That's assuming that everything works OK at 120MHz. If not, the clkset instruction should use $7F, and 60MHz should be used in the delay computations. Also, the third hex code in the MainLoader string would need to be changed from "65" to "64".
I then successfully changed over to 60 MHz as per your second description.
PS: I note the examples like all_cogs_blink.spin2 cycle at different speeds a result of the different clock rates.
The only difference from the last release is that the LUT r/w events are now sensed one clock later than they were before. I had to use some flops to capture the ENA, WR, and ADDR, in order to make sense of them in the next cycle, as there was insufficient time to do it all in one clock. So, the LUT events are sensed one clock later than they used to be, causing events/interrupts to trigger one clock later. It seems unlikely that anyone's code would be so sensitive to such a small change.
Garryj, smart pin modes %011xx have changed and have been remapped, somewhat. Are you using any of those modes? The latest Google Doc explains the new modes.
This one took a while to pin down.
The result from a TESTB D,#S WZ is inverted compared to V18.
I changed some IF_Z's to IF_NZ and things started working.
Still digging....
Ah, yes, I forgot about that. With all the flag-logic instructions, it seemed to me that we had better get rid of flag inversion on WZ. I hope garryj's problems are related to this change.