Whoa Mike,
You're misunderstanding. What Chip is proposing now is a way to separate the problem of reliable boot, which is a prop2 specific problem, from the desires of having OS level features added.
Once there is a separation then they can go their own ways.
The new proposal has a nice short name for easy reference at a later date: RCFAST hand-off
I'm confused.
Will people who wish to contribute a timing-critical object to the OBEX2 (or whatever it will be called) have to include a system frequency parameter in the calling convention so that it can be informed by the calling program what frequency has been set?
Or a language agnostic compile-time constant such that every object will need to be provided as source and compiled into a monolithic code blob?
As we lose the hardware assistance of the P1 that every object could rely on to know the system frequency, we now need agreement on the software solution to the same problem. Allocating a long for this seems a no-brainer, and adding a second long to contain the configuration word needed to shift gears (so to speak) also seems totally reasonable.
Without at least the frequency word, having agreement on mailbox locations seems pointless.
RCFAST hand-off works for handing control between programs, but not for coordination of modules from different authors operating in different cogs.
Guys, there has to be agreement on this. The flaw in the clock setting hardware means that not following a convention will create intermittent boot failures. There's no other way to head it off.
What about a fast booter/loader safely returning the clock mode to 20MHz (%00) on its own steam before it launches the app by doing a 'COGINIT #0,#0' ? Then, there'd be no boot problem, as there's no need for agreement.
That only half solves the problem, as there is benefit in having all software that is running knowing the SysCLK.
That means code in each COG can be made smarter and more tolerant of SysCLK, and if that changes then you can all keep in phase.
...
[RANT]
I mashed TAQOZ and FastSpin together. There is a thread about it. But basically I start TAQOZ in COG0 and a FastSpin compiled Program in COG1 able to talk to TAQOZ via Mailbox. Both Programs agree about the locations in HUB where the clocksettigs are.
I CAN change the clockfreq in my FastSpin program while the TAQOZ COG0 is running. FastSpin program will change the HUB location after changing the freq. And TAQOZ still knows what freq we are running on, still knows to pulse a pin at 1,10 or 100 Hz because it knows the system frequency has changed.
Because both programs agree on that location.
[/RANT]
Mike
well - in this example Taqoz will get the new clockfreq when it reads it again.
So the blinker would need to be prepared for this and recalculate a delta each time based on current clockfreq.
And - sorry @Cluso99 - yes we should think about some std mailboxes, there was a big discussion without solution years ago for the P1 to agree on something and it failed.
So lets stay with the current $14 and $18 and discuss if we could agree on some mailboxes at $10, $C, $8 and $4 if $0 jmps to the starting code.
That could be locations for stdout,stderr,stdsd whatever if agreed on LATER,
But for now lets PLEASE stick with the existing agreement of $14 and $18
The new proposal has a nice short name for easy reference at a later date: RCFAST hand-off
I'm confused.
Will people who wish to contribute a timing-critical object to the OBEX2 (or whatever it will be called) have to include a system frequency parameter in the calling convention so that it can be informed by the calling program what frequency has been set?
Or a language agnostic compile-time constant such that every object will need to be provided as source and compiled into a monolithic code blob?
As we lose the hardware assistance of the P1 that every object could rely on to know the system frequency, we now need agreement on the software solution to the same problem. Allocating a long for this seems a no-brainer, and adding a second long to contain the configuration word needed to shift gears (so to speak) also seems totally reasonable.
Without at least the frequency word, having agreement on mailbox locations seems pointless.
RCFAST hand-off works for handing control between programs, but not for coordination of modules from different authors operating in different cogs.
...
[RANT]
I mashed TAQOZ and FastSpin together. There is a thread about it. But basically I start TAQOZ in COG0 and a FastSpin compiled Program in COG1 able to talk to TAQOZ via Mailbox. Both Programs agree about the locations in HUB where the clocksettigs are.
I CAN change the clockfreq in my FastSpin program while the TAQOZ COG0 is running. FastSpin program will change the HUB location after changing the freq. And TAQOZ still knows what freq we are running on, still knows to pulse a pin at 1,10 or 100 Hz because it knows the system frequency has changed.
Because both programs agree on that location.
[/RANT]
Mike
well - in this example Taqoz will get the new clockfreq when it reads it again.
So the blinker would need to be prepared for this and recalculate a delta each time based on current clockfreq.
nono, @MJB it simply works, becaue both COGS agree about the location of clockfreq. So I can switch to 80Mhz (in Spin) or to 160 or 200, does not matter, 56 BLINK blinks in the same frequency. It just works. Because @ersmith and @"Peter Jakacki" agree about the HUB location of clockfreq.
EDIT - ok, I need to send "56 BLINK" again after changing the clockfreq so TAQOZ read the clockfreq again.
...
[RANT]
I mashed TAQOZ and FastSpin together. There is a thread about it. But basically I start TAQOZ in COG0 and a FastSpin compiled Program in COG1 able to talk to TAQOZ via Mailbox. Both Programs agree about the locations in HUB where the clocksettigs are.
I CAN change the clockfreq in my FastSpin program while the TAQOZ COG0 is running. FastSpin program will change the HUB location after changing the freq. And TAQOZ still knows what freq we are running on, still knows to pulse a pin at 1,10 or 100 Hz because it knows the system frequency has changed.
Because both programs agree on that location.
[/RANT]
Mike
well - in this example Taqoz will get the new clockfreq when it reads it again.
So the blinker would need to be prepared for this and recalculate a delta each time based on current clockfreq.
nono, @MJB it simply works, becaue both COGS agree about the location of clockfreq. So I can switch to 80Mhz (in Spin) or to 160 or 200, does not matter, 56 BLINK blinks in the same frequency. It just works. Because @ersmith and @"Peter Jakacki" agree about the HUB location of clockfreq.
EDIT - ok, I need to send "56 BLINK" again after changing the clockfreq so TAQOZ read the clockfreq again.
Mike
that's what I mean -
there is no sysclock has changed interrupt ;-)
but changing sysclock in the middle of some program is not what you often do ...
maybe for power savings ...
the programmer can design this as he likes.
but a standard way to find out the current sysclock would be REALLY helpful
if you think about OBEX objects collaboration.
If I change sysclock from TAQOZ itself, it also recalculates baudrate and VGA NCO based on the new frequency. So if it is running at 160MHz and I type 300 P2MHZ then the console will continue running at the same baudrate and the VGA will continue at the same pixel frequency.
So it can be done dynamically but mostly it is done during reset.
I agree with msrobots. Chip, at this point I think it would be best to conform with what the other tools are doing instead of trying to impose your own arbitrary rules.
...
[RANT]
I mashed TAQOZ and FastSpin together. There is a thread about it. But basically I start TAQOZ in COG0 and a FastSpin compiled Program in COG1 able to talk to TAQOZ via Mailbox. Both Programs agree about the locations in HUB where the clocksettigs are.
I CAN change the clockfreq in my FastSpin program while the TAQOZ COG0 is running. FastSpin program will change the HUB location after changing the freq. And TAQOZ still knows what freq we are running on, still knows to pulse a pin at 1,10 or 100 Hz because it knows the system frequency has changed.
Because both programs agree on that location.
[/RANT]
Mike
well - in this example Taqoz will get the new clockfreq when it reads it again.
So the blinker would need to be prepared for this and recalculate a delta each time based on current clockfreq.
nono, @MJB it simply works, becaue both COGS agree about the location of clockfreq. So I can switch to 80Mhz (in Spin) or to 160 or 200, does not matter, 56 BLINK blinks in the same frequency. It just works. Because @ersmith and @"Peter Jakacki" agree about the HUB location of clockfreq.
EDIT - ok, I need to send "56 BLINK" again after changing the clockfreq so TAQOZ read the clockfreq again.
Mike
that's what I mean -
there is no sysclock has changed interrupt ;-)
but changing sysclock in the middle of some program is not what you often do ...
maybe for power savings ...
the programmer can design this as he likes.
but a standard way to find out the current sysclock would be REALLY helpful
if you think about OBEX objects collaboration.
That is exactly what we are asking for. Some don't seem to see the benefit, or want to dismiss it as "a separate concern and can be defined as desired."
Given that this thread is "Spin2 Interpreter" I don't see how loading handover is relevant, yet object coordination is "a separate concern".
We never had this problem on P1 because the hardware provided the service. P2 doesn't, so we need a software solution. Most languages developed to date have agreed on the solution and SPIN2 is now apparently going a different way. This should be resolved now.
That is exactly what we are asking for. Some don't seem to see the benefit, or want to dismiss it as "a separate concern and can be defined as desired."
Given that this thread is "Spin2 Interpreter" I don't see how loading handover is relevant, yet object coordination is "a separate concern".
It's because there is a flaw in the hardware that is currently being worked around with the help of those mailbox parameters. Chip has identified that this borrowing of the parameters isn't needed after all. As long as the loaders all change to a RCFAST handover instead.
So it is separate, but still needs resolved in its own way. And I'd prefer the option of disentanglement by changing to RCFAST handover.
CON
rxpin = 63
DAT org
begin
andn clkmode, #3 'disable XI+PLL mode
hubset clkmode 'set up oscillator while still in RCFAST mode
waitx ##20_000_000/100 'wait 10 ms
or clkmode, #3 'enable XI+PLL mode
hubset clkmode 'switch to PLL mode
wrfast #0,address 'ready to write entire memory starting at address
setse1 #%010_000000 | rxpin 'select negative edge on p63
mainloop pollse1 'clear edge detector
waitse1 'wait for start bit
waitx waitbit1_5 'wait for middle of 1st data bit
rep @loopend,#8 'get 8 bits
testp #rxpin wc 'sample rx
rcr rxbyte,#1 'rotate bit into byte
waitx waitbit 'wait for middle of nth data bit
loopend
shr rxbyte,#32-8 'justify received byte
wfbyte rxbyte 'write to hub
djnz filesize,#mainloop 'loop until all bytes received
rdfast #0,#0 'wait for last byte to be written
andn clkmode, #3 'disable XI+PLL mode
hubset clkmode 'switch to RCFAST mode
hubset #0 'turn off all crystal/PLL modes
waitx ##20_000_000/100 'wait 10 ms for crystal shutdown
coginit #0,address 'launch cog 0 from address
clkmode res 1 'clock mode
waitbit1_5 res 1 '1.5 bit cycles = 3*clock_freq/baud_rate/2 - 6
waitbit res 1 '1 bit cycles = clock_freq/baud_rate - 6
filesize res 1 'binary file size in bytes
address res 1 'starting address
rxbyte res 1 'received byte
Here's the unchanged version. Obviously, loadp2.c also needs some changes to remove the patching feature.
CON
rxpin = 63
DAT org
begin hubset clkmode 'set up oscillator
waitx ##20_000_000/100 'wait 10 ms
or clkmode, #3 'enable XI+PLL mode
hubset clkmode 'enable oscillator
wrfast #0,address 'ready to write entire memory starting at address
setse1 #%010_000000 | rxpin 'select negative edge on p63
mainloop pollse1 'clear edge detector
waitse1 'wait for start bit
waitx waitbit1_5 'wait for middle of 1st data bit
rep @loopend,#8 'get 8 bits
testp #rxpin wc 'sample rx
rcr rxbyte,#1 'rotate bit into byte
waitx waitbit 'wait for middle of nth data bit
loopend
shr rxbyte,#32-8 'justify received byte
wfbyte rxbyte 'write to hub
djnz filesize,#mainloop 'loop until all bytes received
rdfast #0,#0 'wait for last byte to be written
coginit #0,address 'launch cog 0 from address
clkmode res 1 'clock mode
waitbit1_5 res 1 '1.5 bit cycles = 3*clock_freq/baud_rate/2 - 6
waitbit res 1 '1 bit cycles = clock_freq/baud_rate - 6
filesize res 1 'binary file size in bytes
address res 1 'starting address
rxbyte res 1 'received byte
Guys, I agree that there needs to be statically-located CLKFREQ and CLKMODE longs, as those are most-easily used by all potential language systems.
Personally, I would like those longs to be at $40 and $44, freeing $00..$3F. Others, though, feel it's critical that $00 be preserved as a restart location or null-pointer trap, which singly preempts generic use of $00..$3F. Everyone is already using $14 and $18 (I think) for CLKMODE and CLKFREQ. For now, I will just follow that convention, too.
There will be no $00-based generic hub RAM in this case. So, any mailboxes in hub will have to be worked out on a case-by-case basis. I suppose if I could do anything, I might have $00..$FF free, with an understanding that each potential cog has 16 bytes of space to use for whatever purpose it wants in hub. That might just be superfluous, anyway, and lead people to suppose they must use that RAM, just because it's there. That wouldn't be good.
So, I'll use $14 for CLKMODE and $18 for CLKFREQ. There will be no $00-based free hub RAM. There will be a few reusable longs near $00, but they won't all be contiguous.
The die is cast, such questions are academic now. But sure, that would be one way. Although it may not be a straight forward verilog fix since it will depend on where the mode store flops are located. If they are in the custom ring then there won't be an available read back mechanism without redoing the custom layout. If it comes to that then correcting the flaw would be the right solution.
Actually, didn't Chip say there were extra registers in the Spin2 cog not being used?
Can't you use 2 of those for this and then add some new Spin2 instructions to fetch them?
Ah, oh, um .... all the cogs are part of the synthesised verilog that makes up the bulk core area of the die. The RC oscillators and crystal oscillator and PLL circuits are all in the custom layout (like a circuit board) that rings the outer perimeter of the prop2 die. The flaw is to do with PLL select management which is part of that custom ring.
Where the flops of the mode register are located I don't know. They could be either part of the synthesised core or in the custom ring. If they are in the core then, sure, a respin with a new read back instruction would be quicker and cheaper than relaying the custom layout but it would still be a respin.
I just meant to ask if the clkfreq and clkmode could be stored in COG ram rather than HUB ram.
Chip's Spin2 runs in a cog as interpreter...
I guess FastSpin doesn't use an interpreter cog though...
Here's the unchanged version. Obviously, loadp2.c also needs some changes to remove the patching feature.
Can explain what you changed instead of just posting code? Did you remove something? And why does the pathing feature need to be removed? It is controlled by an optional parameter on the command line.
I don't think everybody has bought into the changes that you and Chip are trying to force on us. It's tactics like this that make me wonder if it's worth spending time on the P2.
Dave Hein, doesn't it appear that Chip agreed to grab and update the system clock parameters from the agreed upon spot?
Isn't this discussion over at this point?
Thanks, I had missed that. I should have read it more carefully. I think I quit reading it after the first couple of lines where it looked like he was still pushing his proposal. My previous response was actually more about evanh's proposal to change loadp2. I don't understand the need for the change. Maybe he'll explain it when he has a chance.
So, I'll use $14 for CLKMODE and $18 for CLKFREQ. There will be no $00-based free hub RAM. There will be a few reusable longs near $00, but they won't all be contiguous.
It's actually the other way around, Chip. $14 is the frequency address and $18 was the CLKMODE.
Personally, I would like those longs to be at $40 and $44, freeing $00..$3F. Others, though, feel it's critical that $00 be preserved as a restart location or null-pointer trap, which singly preempts generic use of $00..$3F. Everyone is already using $14 and $18 (I think) for CLKMODE and CLKFREQ. For now, I will just follow that convention, too.
I sympathise Chip. I rather liked your idea too and thought it opened up some nice options but I guess it became too hard for two reasons...legacy software interests and intercepting the unique 0 call address cases in various languages which was the PITA as it is harder to avoid. We now can't fully use the low memory for larger directly indexed tables if we want compatibility with SPIN2 and the clock frequency long storage. Not ideal but looks like we will just need to live with it. Any custom system independent of SPIN2 can still obviously fully use this memory for its own purposes at least, so all is not lost.
Chip, now is the time for us to work out these addresses which could be $04,$08 or $F8 and $FC even as it is still easily reached with un-augmented rdlong imediate. P1 Spin reserved the first 16 bytes anyway.
My original addresses were mainly for some functionality and I always had the option of changing it later. This has nothing to do with the ROM though, because what's in ROM, stays in ROM.
Comments
You're misunderstanding. What Chip is proposing now is a way to separate the problem of reliable boot, which is a prop2 specific problem, from the desires of having OS level features added.
Once there is a separation then they can go their own ways.
I'm confused.
Will people who wish to contribute a timing-critical object to the OBEX2 (or whatever it will be called) have to include a system frequency parameter in the calling convention so that it can be informed by the calling program what frequency has been set?
Or a language agnostic compile-time constant such that every object will need to be provided as source and compiled into a monolithic code blob?
As we lose the hardware assistance of the P1 that every object could rely on to know the system frequency, we now need agreement on the software solution to the same problem. Allocating a long for this seems a no-brainer, and adding a second long to contain the configuration word needed to shift gears (so to speak) also seems totally reasonable.
Without at least the frequency word, having agreement on mailbox locations seems pointless.
RCFAST hand-off works for handing control between programs, but not for coordination of modules from different authors operating in different cogs.
Many objects have parameters. It's just one init parameter to pass if needed.
That only half solves the problem, as there is benefit in having all software that is running knowing the SysCLK.
That means code in each COG can be made smarter and more tolerant of SysCLK, and if that changes then you can all keep in phase.
So the blinker would need to be prepared for this and recalculate a delta each time based on current clockfreq.
So lets stay with the current $14 and $18 and discuss if we could agree on some mailboxes at $10, $C, $8 and $4 if $0 jmps to the starting code.
That could be locations for stdout,stderr,stdsd whatever if agreed on LATER,
But for now lets PLEASE stick with the existing agreement of $14 and $18
Mike
It completely solves the loading handover problem. Anything else is a separate concern and can be defined as desired.
Exactly @AJL
Mike
nono, @MJB it simply works, becaue both COGS agree about the location of clockfreq. So I can switch to 80Mhz (in Spin) or to 160 or 200, does not matter, 56 BLINK blinks in the same frequency. It just works. Because @ersmith and @"Peter Jakacki" agree about the HUB location of clockfreq.
EDIT - ok, I need to send "56 BLINK" again after changing the clockfreq so TAQOZ read the clockfreq again.
Mike
that's what I mean -
there is no sysclock has changed interrupt ;-)
but changing sysclock in the middle of some program is not what you often do ...
maybe for power savings ...
the programmer can design this as he likes.
but a standard way to find out the current sysclock would be REALLY helpful
if you think about OBEX objects collaboration.
So it can be done dynamically but mostly it is done during reset.
Assuming it only needs to know the sysclock rate at init....
That is exactly what we are asking for. Some don't seem to see the benefit, or want to dismiss it as "a separate concern and can be defined as desired."
Given that this thread is "Spin2 Interpreter" I don't see how loading handover is relevant, yet object coordination is "a separate concern".
We never had this problem on P1 because the hardware provided the service. P2 doesn't, so we need a software solution. Most languages developed to date have agreed on the solution and SPIN2 is now apparently going a different way. This should be resolved now.
So it is separate, but still needs resolved in its own way. And I'd prefer the option of disentanglement by changing to RCFAST handover.
CON rxpin = 63 DAT org begin andn clkmode, #3 'disable XI+PLL mode hubset clkmode 'set up oscillator while still in RCFAST mode waitx ##20_000_000/100 'wait 10 ms or clkmode, #3 'enable XI+PLL mode hubset clkmode 'switch to PLL mode wrfast #0,address 'ready to write entire memory starting at address setse1 #%010_000000 | rxpin 'select negative edge on p63 mainloop pollse1 'clear edge detector waitse1 'wait for start bit waitx waitbit1_5 'wait for middle of 1st data bit rep @loopend,#8 'get 8 bits testp #rxpin wc 'sample rx rcr rxbyte,#1 'rotate bit into byte waitx waitbit 'wait for middle of nth data bit loopend shr rxbyte,#32-8 'justify received byte wfbyte rxbyte 'write to hub djnz filesize,#mainloop 'loop until all bytes received rdfast #0,#0 'wait for last byte to be written andn clkmode, #3 'disable XI+PLL mode hubset clkmode 'switch to RCFAST mode hubset #0 'turn off all crystal/PLL modes waitx ##20_000_000/100 'wait 10 ms for crystal shutdown coginit #0,address 'launch cog 0 from address clkmode res 1 'clock mode waitbit1_5 res 1 '1.5 bit cycles = 3*clock_freq/baud_rate/2 - 6 waitbit res 1 '1 bit cycles = clock_freq/baud_rate - 6 filesize res 1 'binary file size in bytes address res 1 'starting address rxbyte res 1 'received byteCON rxpin = 63 DAT org begin hubset clkmode 'set up oscillator waitx ##20_000_000/100 'wait 10 ms or clkmode, #3 'enable XI+PLL mode hubset clkmode 'enable oscillator wrfast #0,address 'ready to write entire memory starting at address setse1 #%010_000000 | rxpin 'select negative edge on p63 mainloop pollse1 'clear edge detector waitse1 'wait for start bit waitx waitbit1_5 'wait for middle of 1st data bit rep @loopend,#8 'get 8 bits testp #rxpin wc 'sample rx rcr rxbyte,#1 'rotate bit into byte waitx waitbit 'wait for middle of nth data bit loopend shr rxbyte,#32-8 'justify received byte wfbyte rxbyte 'write to hub djnz filesize,#mainloop 'loop until all bytes received rdfast #0,#0 'wait for last byte to be written coginit #0,address 'launch cog 0 from address clkmode res 1 'clock mode waitbit1_5 res 1 '1.5 bit cycles = 3*clock_freq/baud_rate/2 - 6 waitbit res 1 '1 bit cycles = clock_freq/baud_rate - 6 filesize res 1 'binary file size in bytes address res 1 'starting address rxbyte res 1 'received bytePersonally, I would like those longs to be at $40 and $44, freeing $00..$3F. Others, though, feel it's critical that $00 be preserved as a restart location or null-pointer trap, which singly preempts generic use of $00..$3F. Everyone is already using $14 and $18 (I think) for CLKMODE and CLKFREQ. For now, I will just follow that convention, too.
There will be no $00-based generic hub RAM in this case. So, any mailboxes in hub will have to be worked out on a case-by-case basis. I suppose if I could do anything, I might have $00..$FF free, with an understanding that each potential cog has 16 bytes of space to use for whatever purpose it wants in hub. That might just be superfluous, anyway, and lead people to suppose they must use that RAM, just because it's there. That wouldn't be good.
So, I'll use $14 for CLKMODE and $18 for CLKFREQ. There will be no $00-based free hub RAM. There will be a few reusable longs near $00, but they won't all be contiguous.
Can't you use 2 of those for this and then add some new Spin2 instructions to fetch them?
Where the flops of the mode register are located I don't know. They could be either part of the synthesised core or in the custom ring. If they are in the core then, sure, a respin with a new read back instruction would be quicker and cheaper than relaying the custom layout but it would still be a respin.
Chip's Spin2 runs in a cog as interpreter...
I guess FastSpin doesn't use an interpreter cog though...
Isn't this discussion over at this point?
It's actually the other way around, Chip. $14 is the frequency address and $18 was the CLKMODE.
I sympathise Chip. I rather liked your idea too and thought it opened up some nice options but I guess it became too hard for two reasons...legacy software interests and intercepting the unique 0 call address cases in various languages which was the PITA as it is harder to avoid. We now can't fully use the low memory for larger directly indexed tables if we want compatibility with SPIN2 and the clock frequency long storage. Not ideal but looks like we will just need to live with it. Any custom system independent of SPIN2 can still obviously fully use this memory for its own purposes at least, so all is not lost.
My original addresses were mainly for some functionality and I always had the option of changing it later. This has nothing to do with the ROM though, because what's in ROM, stays in ROM.