I have had an SD on most of my P1 boards since my first design about 2008. But I need to fit an EEPROM just so I can boot the SD. The eeprom code is minimal snd it pretty much hasnt changed since. In fact i write protect the eeprom so it cannot accidentally get corrupted.
I personally think that TAQOZ does not make it a Hobbyist Processor. Heck every SUN machine has some FORTH bios. And SUN is not really Hobbyist.
Since a couple of month I am now almost praying here to just embrace TAQOZ by including the ability to use it as a smart IO processor in one COG while running any other language of choice in the other ones.
Not hiding TAQOZ, but putting it right on top of the list, next to the smart pins a optional programable smart COG able to be called via serial/mailbox.
This is a big feature of the P2 not something to be ashamed of, because it smells like Hobbyist.
nuff said,
Mike
Every thing you want to with TAQOZ could be done with a loadable TAQOZ. You will need to load your own program anyway, so you may as well load TAQOZ with it. So you will need Flash, SD or download.
All that you want cannot be done with TAQOZ in ROM because it does not fit.
You will not require the autobaud character sequence to run TAQOZ if you load it.
and here I fully disagree with you.
Because using the TAQOZ provided in ROM will ensure that every P2 has the same one. I just leave the first 64K in my program free (or for init code not needed after TAQOZ start)
Now I can be SURE about what words TAQOZ knows, and can copy any TAQOZ on-liner and use it from C, or Basic, or Spin or even assembler if @"Peter Jakacki" implements a mailbox option instead of just using pins 63 and 62.
It would make TAQOZ available almost like your Monitor in ROM but just in lower RAM, if started.
I really want to push this before it is to late.
It can't be so complicated to have a ROM address to jump to start TAQOZ as it already exists and a second address to jump to, to start TAQOZ in Mailbox mode with fixed address in lower RAM?
The P2 is very different from everything else out there.
And that is true by design, over years of time. That discussion is out there for all to see. Call it a virtual "beanie."
Being different = risk
No risk, no reward.
I say go big or go home. Maximize the differences and make them known, feature benefit style. They are strengths, and should the resistor combo Peter mentioned make sense, a fall through to TAQOS makes sense too.
In many other ways, "go big" was the choice. Seems to me the die is cast whether or not there is a fall through to TAQOS. Play to the strengths. Shying away from them makes very little sense given so many other choices already set in stone.
Can some combination of pullup/pulldown resistors on the upper pins decide the last resort boot mode?
I believe there is one combination up for grabs, that could (and I believe should) include TAQOZ.
Referring to the attached image (taken from the P2-EVAL schematic).
And the second image which extends the scheme.
Note the second row would change , so that the FLASH (P61) requirement is OFF (instead of ON or OFF).
Caveat: If this seems reasonable in theory, then it will need careful checking to ensure no conflicts are introduced.
Dropping into TAQOZ as an option via the pullups would be a good compromise for my needs. Other considerations such as auto baud detection are not an issue since a crystal will always be used for accurate timing, and baud rates will not normally be changing once the equipment is set up and running.
Can some combination of pullup/pulldown resistors on the upper pins decide the last resort boot mode?
I believe there is one combination up for grabs, that could (and I believe should) include TAQOZ.
This discussion is really about boot tree choices, not the merits of TAQOZ, so it certainly makes sense to focus on the boot options possible via combination of pullup/pulldown resistors
Could TAQOZ start at a reasonable fixed baud in the case of "drop in" ? And if needed, have a TAQOZ command to change baud for the current session.
Not really, because the RCFAST is all a freshly reset P2 knows, and the PVT tolerance of that is outside baud range.
Autobaud in P2 works very well, but it is a step that is required.
Other considerations such as auto baud detection are not an issue since a crystal will always be used for accurate timing, and baud rates will not normally be changing once the equipment is set up and running.
When a freshly reset P2 starts, it has no idea what crystal is installed. The ROM certainly does not have that info, and if the system falls into TAQOZ, it still has no idea.
User control of the reset exit sequence is always going to be needed and that same control can enter TAQOZ.
Peter, let's talk on Skype or Hangouts. I'm sure we'll come to mutual agreement. This week has been spent moving our mom, so I've been somewhat neglectful of the forum and you've gotten the wrong vibe from me. I sent you some invitations to talk. I hope we can talk soon.
I personally think that TAQOZ does not make it a Hobbyist Processor. Heck every SUN machine has some FORTH bios. And SUN is not really Hobbyist.
Since a couple of month I am now almost praying here to just embrace TAQOZ by including the ability to use it as a smart IO processor in one COG while running any other language of choice in the other ones.
Not hiding TAQOZ, but putting it right on top of the list, next to the smart pins a optional programable smart COG able to be called via serial/mailbox.
This is a big feature of the P2 not something to be ashamed of, because it smells like Hobbyist.
nuff said,
Mike
Every thing you want to with TAQOZ could be done with a loadable TAQOZ. You will need to load your own program anyway, so you may as well load TAQOZ with it. So you will need Flash, SD or download.
All that you want cannot be done with TAQOZ in ROM because it does not fit.
You will not require the autobaud character sequence to run TAQOZ if you load it.
and here I fully disagree with you.
Because using the TAQOZ provided in ROM will ensure that every P2 has the same one. I just leave the first 64K in my program free (or for init code not needed after TAQOZ start)
Now I can be SURE about what words TAQOZ knows, and can copy any TAQOZ on-liner and use it from C, or Basic, or Spin or even assembler if @"Peter Jakacki" implements a mailbox option instead of just using pins 63 and 62.
It would make TAQOZ available almost like your Monitor in ROM but just in lower RAM, if started.
I really want to push this before it is to late.
It can't be so complicated to have a ROM address to jump to start TAQOZ as it already exists and a second address to jump to, to start TAQOZ in Mailbox mode with fixed address in lower RAM?
still hoping,
Mike
Mike,
You are missing the points...
There is insufficient ROM space for what you want. Something else in TAQOZ would have to be removed.
It will take Peter time to include these features. The ROM window is closing quickly so there is no time to implement this and test it.
If you load your program, why not load TAQOZ with it - combine both of them at once. Why be limited with a less feature rich version?
I am going to throw this out there, just to see what you all think...
In the current ROM I have the SD Booter. That will stay, just with the updates to tweek it.
Also in the current ROM is my Monitor/Debugger...
Are there any features that could be removed?(to save space)
Are there any features you would like added?(will use more space so anything that can be replaced?)
Here are some examples...
The list command to dump cog/lut/hub
The load command to input and save to cog/lut/hub
Would a decimal command output be nice? (like the hex commands)
Would a binary command output be nice?
BTW there is nothing to stop you patching the ROM to replace the two lowest level HubTx and HubRx routines with your own. All higher level routines call these.
The list command to dump cog/lut/hub
The load command to input and save to cog/lut/hub
Would a decimal command output be nice? (like the hex commands)
Would a binary command output be nice?
Plenty of things might be nice, but the ROM is limited, so should focus on broadly useful items.
eg I'd place HEX as the most important format, with decimal and binary merely nice to have. More important things to spend ROM bytes on.
eg Things that cannot be done externally.
It would be very useful to be able to easily read the AutoBaud capture value, (rx_tne), to provide a means to calibrate the RCFAST.
I think currently that value is currently lost in subsequent scaling in the ROM, but if it were preserved, there may be ROM routines (Monitor / TAQOZ?) already there that could read it in HEX ?
Lowest Baud supported by FT231X is 300Baud, and I calc that even RCSLOW could be captured on that, to ~0.2% precision.
@jmg
The monitor and taqoz currently inherit the baud setting from Chips booter. But we don't copy that setting from the booter. I plan on copying this for the respin - it is available in register A0 in cog when we get are passed control.
Of course, this is not available if autobaud did not run first.
I am going to throw this out there, just to see what you all think...
In the current ROM I have the SD Booter. That will stay, just with the updates to tweek it.
Also in the current ROM is my Monitor/Debugger...
Are there any features that could be removed?(to save space)
Are there any features you would like added?(will use more space so anything that can be replaced?)
Here are some examples...
The list command to dump cog/lut/hub
The load command to input and save to cog/lut/hub
Would a decimal command output be nice? (like the hex commands)
Would a binary command output be nice?
BTW there is nothing to stop you patching the ROM to replace the two lowest level HubTx and HubRx routines with your own. All higher level routines call these.
Yes I did that and your stuff is working absolute nicely doing that. But TAQOZ resets the smartpins after lsio and I am not able to communicate with it after the fact.
As far as I understand the source of TAQOZ (and that is a challenge) it IS already using a mailbox for subsequent TAQOZ COGs and even @"Peter Jakacki" said it might be a no-brainer.
Even with a LZH compacted TAQOZ there is a ROM address where the booter jumps too, to uncompact TAQOZ and load it to the lower RAM.
We would just need one different jmp address to start TAQOZ using a mailbox instead of pins. Or TAQOZ not destroying the current pin settings on lsio.
The question is, would it be more important to use TAQOZ as smart subsystem from any language, or having it in ROM and NOT being able to use it as smart sub-system from other languages.
Mike,
Its because you fail to understand. Postedit: Sorry I was a bit rough with my answer
Just because you have a second entry point, doesn’t mean everything just works. Its a lot more than just the one long. If it were that simple Peter would have done it.
Without Peters update.
Note my Monitor calls remain in the same location but some of my SD routines moved slightly although the main call is in the same location.
Without Peters update.
Note my Monitor calls remain in the same location but some of my SD routines moved slightly although the main call is in the same location.
So, you are saying you have a little more testing to do on it?
Yes. I just compiled to ensure that worked.
No more changes to do provided it tests ok.
I have to massage it to load and run on my dev board to test that i didnt break the code.
I am off to bed so will test tomorrow
Please test it out with any SD cards that you have. You will need to set the P59^ switch ON. BOD is also ON. FLASH and P59v switches OFF.
(this prevents the sd from booting initially so you can download the code)
If your SD card(s) is formatted with FAT32 then copy the file "_BOOT_P2.BIX" (rename "_BOOT_P2_BIX.SPIN") to the root directory.
Now with pnut, compile and run the file "ROM_v32i_SD-002d.spin"
The file should run and display something similar to this. At the end, P56 LED should flash.
Getting very inconsistent results from other cards. Sometimes they boot, sometimes not. I may have a loose uSD holder. Will try to hit it with a heat gun later.
If the PTN type is not 0B or 0C they will not boot. These two types are FAT32. IIRC $06 is FAT16 and $07 is either NTFS or exFAT. Why MS uses the same i don’t know.
Currently the code still supports older cards using byte addressing.
Comments
Good points, especially this.
and here I fully disagree with you.
Because using the TAQOZ provided in ROM will ensure that every P2 has the same one. I just leave the first 64K in my program free (or for init code not needed after TAQOZ start)
Now I can be SURE about what words TAQOZ knows, and can copy any TAQOZ on-liner and use it from C, or Basic, or Spin or even assembler if @"Peter Jakacki" implements a mailbox option instead of just using pins 63 and 62.
It would make TAQOZ available almost like your Monitor in ROM but just in lower RAM, if started.
I really want to push this before it is to late.
It can't be so complicated to have a ROM address to jump to start TAQOZ as it already exists and a second address to jump to, to start TAQOZ in Mailbox mode with fixed address in lower RAM?
still hoping,
Mike
And that is true by design, over years of time. That discussion is out there for all to see. Call it a virtual "beanie."
Being different = risk
No risk, no reward.
I say go big or go home. Maximize the differences and make them known, feature benefit style. They are strengths, and should the resistor combo Peter mentioned make sense, a fall through to TAQOS makes sense too.
In many other ways, "go big" was the choice. Seems to me the die is cast whether or not there is a fall through to TAQOS. Play to the strengths. Shying away from them makes very little sense given so many other choices already set in stone.
[goes back to testing / work]
Dropping into TAQOZ as an option via the pullups would be a good compromise for my needs. Other considerations such as auto baud detection are not an issue since a crystal will always be used for accurate timing, and baud rates will not normally be changing once the equipment is set up and running.
This discussion is really about boot tree choices, not the merits of TAQOZ, so it certainly makes sense to focus on the boot options possible via combination of pullup/pulldown resistors
Not really, because the RCFAST is all a freshly reset P2 knows, and the PVT tolerance of that is outside baud range.
Autobaud in P2 works very well, but it is a step that is required.
When a freshly reset P2 starts, it has no idea what crystal is installed. The ROM certainly does not have that info, and if the system falls into TAQOZ, it still has no idea.
User control of the reset exit sequence is always going to be needed and that same control can enter TAQOZ.
'
Mike,
You are missing the points...
There is insufficient ROM space for what you want. Something else in TAQOZ would have to be removed.
It will take Peter time to include these features. The ROM window is closing quickly so there is no time to implement this and test it.
If you load your program, why not load TAQOZ with it - combine both of them at once. Why be limited with a less feature rich version?
In the current ROM I have the SD Booter. That will stay, just with the updates to tweek it.
Also in the current ROM is my Monitor/Debugger...
Are there any features that could be removed? (to save space)
Are there any features you would like added? (will use more space so anything that can be replaced?)
Here are some examples...
The list command to dump cog/lut/hub
The load command to input and save to cog/lut/hub
Would a decimal command output be nice? (like the hex commands)
Would a binary command output be nice?
BTW there is nothing to stop you patching the ROM to replace the two lowest level HubTx and HubRx routines with your own. All higher level routines call these.
eg I'd place HEX as the most important format, with decimal and binary merely nice to have. More important things to spend ROM bytes on.
eg Things that cannot be done externally.
It would be very useful to be able to easily read the AutoBaud capture value, (rx_tne), to provide a means to calibrate the RCFAST.
I think currently that value is currently lost in subsequent scaling in the ROM, but if it were preserved, there may be ROM routines (Monitor / TAQOZ?) already there that could read it in HEX ?
Lowest Baud supported by FT231X is 300Baud, and I calc that even RCSLOW could be captured on that, to ~0.2% precision.
The monitor and taqoz currently inherit the baud setting from Chips booter. But we don't copy that setting from the booter. I plan on copying this for the respin - it is available in register A0 in cog when we get are passed control.
Of course, this is not available if autobaud did not run first.
Yes I did that and your stuff is working absolute nicely doing that. But TAQOZ resets the smartpins after lsio and I am not able to communicate with it after the fact.
As far as I understand the source of TAQOZ (and that is a challenge) it IS already using a mailbox for subsequent TAQOZ COGs and even @"Peter Jakacki" said it might be a no-brainer.
Even with a LZH compacted TAQOZ there is a ROM address where the booter jumps too, to uncompact TAQOZ and load it to the lower RAM.
We would just need one different jmp address to start TAQOZ using a mailbox instead of pins. Or TAQOZ not destroying the current pin settings on lsio.
The question is, would it be more important to use TAQOZ as smart subsystem from any language, or having it in ROM and NOT being able to use it as smart sub-system from other languages.
because of one or two longs in the ROM.
why are you so against the proposal?
Mike
Its because you fail to understand.
Postedit: Sorry I was a bit rough with my answer
Just because you have a second entry point, doesn’t mean everything just works. Its a lot more than just the one long. If it were that simple Peter would have done it.
Tried a fix. It requires a minimum of 3 H-L clocks on CLK with CS=1.
I am working that into the ROM candidate now.
@all
Please cast your eye over them to make sure I haven't missed anything
save 3 longs (sends >74 clocks to initialise the sd card)
mov ctr1, #(96*2) .count waitx ##delay5us '\ 5us+5us (ie 100KHz) outnot #sd_ck '| CLK=0-->1-->0 djnz ctr1, #.count '/ waitx ##delay5us ' CLK=0 (idle) & /CS=1changed to (now 17us instead of 5us to allow for faster clocks)rep @.rep,#(96*2) waitx #delay17us '\ 17us*2 ~30KHz @30MHz outnot #sd_ck '| CLK=0-->1-->0 .rep '/ waitx #delay17us ' CLK=0 (idle) & /CS=1and this saves 1 long changed to (now 17us also)
and this saves 1 long
and reply, #$7F cmp reply, #0 wz ' $00/80? inactive/activechanged toand this saves 1 long
.scan rdlong reply, bufad '\ check this entry cmp reply, #0 wz '| $0 = empty?changed toThis change forces the SD-DO to tristate, and tristates the P2 SD pins too
' load Cog & jmp #$000 ._success setq #cog_len-1 ' length -1 rdlong cog_start0, _hubdata ' copy loaded code into cog jmp #$0 ' execute loaded cog code ' load cog & jmp #$020 _success80 setq #cog_len80-1 ' length -1 rdlong cog_start0, _hubdata ' copy loaded code into cog jmp #$020 ' execute loaded cog code from $080+changed to (uses 3 extra longs)._success ' <-- NZ: load Cog & jmp #$000 if_ne mov reply, #cog_len-1 ' set to copy whole cog (496 longs) _success80 ' <-- Z: load cog & jmp #$020 if_e mov reply, #cog_len80-1 ' set to copy 512 bytes (128 longs) call #@_sendFF ' clocks to release SD-DO andn dirb, ##($F<<26) ' tristate SD pins P58:61 setq reply ' length -1 rdlong cog_start0, _hubdata ' copy loaded code into cog if_ne jmp #$0 ' NZ: execute loaded cog code jmp #$020 ' Z: execute loaded cog code from $080+This change also forces the SD-DO to tristate, and tristates the P2 SD pins too changed to (uses 3 extra longs)
_fail call #@_sendFF ' clocks to release SD-DO andn dirb, ##($F<<26) ' tristate SD pins P58:61 _RET_ MODCZ _set,_clr wcz ' C & NZ = failandn dirb, ##($F<<26) ' tristate SD pins P58:61
...could be...
bitl dirb,#3<<5 + 26 'clear bit 26, plus the next 3
...But test it to be sure.
Code attached - not verified yet
Without Peters update.
Note my Monitor calls remain in the same location but some of my SD routines moved slightly although the main call is in the same location.
So, you are saying you have a little more testing to do on it?
No more changes to do provided it tests ok.
I have to massage it to load and run on my dev board to test that i didnt break the code.
I am off to bed so will test tomorrow
Please test it out with any SD cards that you have. You will need to set the P59^ switch ON. BOD is also ON. FLASH and P59v switches OFF.
(this prevents the sd from booting initially so you can download the code)
If your SD card(s) is formatted with FAT32 then copy the file "_BOOT_P2.BIX" (rename "_BOOT_P2_BIX.SPIN") to the root directory.
Now with pnut, compile and run the file "ROM_v32i_SD-002d.spin"
The file should run and display something similar to this. At the end, P56 LED should flash.
If SD DO pin fails to release you will see SD-DO failed!!!
I am also interested to see if cards with ptn type 0C can find/load/run the boot file.
Oh, and I am looking for 2 longs
Postedit: Updated to final candidate (plus debugging)
SanDisk Ultra 32GB
Currently the code still supports older cards using byte addressing.
Unirex 4GB uSD HC:
Sandisk 1GB (non-sdhc)
Sandisk 4GB
Sandisk Ultra 32GB
Tried partition types 0xB and 0xC for each
Cheers,
Jesse