Cluso99, I like the way you have it, already. I don't think it is a good idea to switch the clock in your code. Sure, you could make the chip run faster, based on some custom clock setting, but now your code has to accommodate a huge variance of clock rates, which is completely impractical. It's better to assume ~24MHz and allow second-stage code to do something unique at higher clock speeds.
Agreed
I also don't want to fall back into TAQOZ if it means twiddling a bunch of pins, and causing surprise behavior on people's hardware. That would be a disaster, as Samuell pointed out.
Yes.
There are 60 seconds to invoke TAQOZ by the “ <“ and <esc> serial sequence, which has the added bonus of autobaud.
I was searching for how many clocks elapse after a DRVL/DRVH instruction executes, and also how many clocks prior to a TESTP instruction is the pin latched. I couldnt find it.
Having a user specified clock config that the bootloader can use is a no-brainer. Even my optimized cog code runs at 340MHz as well as RCFAST so why can't the bootloader?
@cgracey - I'd like TAQOZ to be included in the boot chain and not just summoned with an arcane invocation that needs to be entered in less than 60 seconds. There is no reason why this can't be so and while TAQOZ can autoboot a user program that may access user I/O, it does not do this automatically, except in my current test version where I run VGA.
So obviously if TAQOZ in ROM were booted then it would check the SD and perhaps the Flash for a config file so that it can startup at the user specified baud-rate and with VGA and keyboard if so desired. But in a totally blank system TAQOZ can only check the standard boot devices and listen to the serial console, and if it hasn't saved any clock config from a previous boot, then it would have to autobaud.
If there is no boot code or activity then I guess it could shutdown although running at RCFAST should be sufficient considering that the P2 is nothing like the P1 but requires switching regulators that normally would still draw considerable quiescent current, even with a very light load.
@msrobots - btw, I already mentioned in previous posts that I could incorporate a mailbox (it's a no-brainer too).
I was searching for how many clocks elapse after a DRVL/DRVH instruction executes, and also how many clocks prior to a TESTP instruction is the pin latched. I couldnt find it.
Anyone recall or have a link?
I couldn’t think of a way to test/verify it.
From the P2 documentation...
I/O PIN TIMING
I/O pins are controlled by cogs via the following cog registers:
DIRA - output enable bits for P0..P31 (active high) DIRB - output enable bits for P32..P63 (active high) OUTA - output state bits for P0..P31 (corresponding DIRA bit must be high to enable output) OUTB - output state bits for P32..P63 (corresponding DIRB bit must be high to enable output)
I/O pins are read by cogs via the following cog registers:
INA - input state bits for P0..P31 INB - input state bits for P32..P63
Aside from general-purpose instructions which may operate on DIRA/DIRB/OUTA/OUTB, there are special pin instructions which operate on singular bits within these registers:
DIRL/DIRH/DIRC/DIRNC/DIRZ/DIRNZ/DIRRND/DIRNOT {#}D - affect pin D bit in DIRx OUTL/OUTH/OUTC/OUTNC/OUTZ/OUTNZ/OUTRND/OUTNOT {#}D - affect pin D bit in OUTx FLTL/FLTH/FLTC/FLTNC/FLTZ/FLTNZ/FLTRND/FLTNOT {#}D - affect pin D bit in OUTx, clear bit
in DIRx
DRVL/DRVH/DRVC/DRVNC/DRVZ/DRVNZ/DRVRND/DRVNOT {#}D - affect pin D bit in OUTx, set bit in DIRx
As well, aside from general-purpose instructions which may read INA/INB, there are special pin instructions which can read singular bits within these registers:
TESTP {#}D WC/WZ/ANDC/ANDZ/ORC/ORZ/XORC/XORZ -read pin D bit in INx and affect C or Z TESTPN {#}D WC/WZ/ANDC/ANDZ/ORC/ORZ/XORC/XORZ -read pin D bit in !INx and affect C or Z
When a DIRx/OUTx bit is changed by any instruction, it takes THREE additional clocks after the instruction before the pin starts transitioning to the new state. Here this delay is demonstrated using DRVH:
____0 ____1 ____2 ____3 ____4 ____5 Clock: / \____/ \____/ \____/ \____/ \____/ \____/ DIRA: | | DIRA-->| REG-->| REG-->| REG-->| P0 DRIV | OUTA: | | OUTA-->| REG-->| REG-->| REG-->| P0 HIGH | | | Instruction: | DRVH #0 |
When an INx register is read by an instruction, it will reflect the state of the pins registered TWO clocks before the start of the instruction. Here this delay in demonstrated using TESTB:
____0 ____1 ____2 ____3 ____4 Clock: / \____/ \____/ \____/ \____/ \____/ INA: | P0 IN-->| REG-->| REG-->| ALU-->| C/Z-->| | | Instruction: | TESTB INA,#0 |
When a TESTP/TESTPN instruction is used to read a pin, the value read will reflect the state of the pin registered ONE clock before the start of the instruction. So, TESTP/TESTPN get fresher INx data than is available via the INx registers:
____0 ____1 ____2 ____3 Clock: / \____/ \____/ \____/ \____/
INA: | P0 IN-->| REG-->| REG-->| C/Z-->| | | Instruction: | TESTP #0 |
@Cluso99 - I found that I needed to read after the clock goes low but I also had to add an extra nop for reliability at higher speeds. Here is my general SPI READ routine that shows this.
SPIRD rep @sre1,#8 ' 8 bits
outnot sck ' clock (low high)
RWAIT nop
outnot sck
nop
testp miso wc ' read data from card
rcl tos,#1 ' shift in msb first
sre1 ret
Having a user specified clock config that the bootloader can use is a no-brainer. Even my optimized cog code runs at 340MHz as well as RCFAST so why can't the bootloader?
@cgracey - I'd like TAQOZ to be included in the boot chain and not just summoned with an arcane invocation that needs to be entered in less than 60 seconds. There is no reason why this can't be so and while TAQOZ can autoboot a user program that may access user I/O, it does not do this automatically, except in my current test version where I run VGA.
So obviously if TAQOZ in ROM were booted then it would check the SD and perhaps the Flash for a config file so that it can startup at the user specified baud-rate and with VGA and keyboard if so desired. But in a totally blank system TAQOZ can only check the standard boot devices and listen to the serial console, and if it hasn't saved any clock config from a previous boot, then it would have to autobaud.
If there is no boot code or activity then I guess it could shutdown although running at RCFAST should be sufficient considering that the P2 is nothing like the P1 but requires switching regulators that normally would still draw considerable quiescent current, even with a very light load.
@msrobots - btw, I already mentioned in previous posts that I could incorporate a mailbox (it's a no-brainer too).
The difference here is that I hope you stated you would do this and not you could do this.
I am pretty sure you can do this, I am just begging you to do it.
I also think it would be nice to end up in TAQOZ if every thing else fails, and I see no problem there with unknown hardware attached since TAQOZ just uses the same pins as the booter.
Maybe shut down if serial boot is disabled, else end up in TAQOZ if nothing else works?
TAQOZ is there to help get a board running and perform some tests.
TAQOZ would NOT be present for a commercial system, at least in it's current version. The commercial system would load its' own code from Flash or SD or be loaded by something else. If TAQOZ is being used, it would be in an extended for with other goodies.
IMHO for a commercial designer, I would probably not want my system to fall into TAQOZ if the booting failed.
However, hobbyists would probably prefer it to fall into TAQOZ.
I am more inclined to see that falling into TAQOZ would be viewed by the commercial designer as a "hobbyist" chip and give it a miss for their designs. We had that stigma with the P1.
So, I am more inclined to say that it should not fall into TAQOZ. Sorry Peter. It is easy enough to invoke, just like the Monitor/Debugger.
The same goes for "calling" TAQOZ from a user (hobbyist) program. If you are calling it, you will want the extended "bells and whistles" version of TAQOZ and that will be loaded from Flash/SD/Downloaded.
A professional program that uses TAQOZ will also be loaded with the extended TAQOZ and user routines.
..
So, I am more inclined to say that it should not fall into TAQOZ. Sorry Peter. It is easy enough to invoke, just like the Monitor/Debugger.
I'm unclear on what this "fall into TAQOZ" really means ?
Currently when I enter TAQOZ now, there is a significant delay ( ~ 250ms to load) and then a splash screen on the terminal.
That means a failure could spit a lot a chaff out the serial port, at a totally unexpected time.
That's not really a good idea, and certainly unwanted in any commercial system.
Instead of it being an interactive fall-through, how about it being a non-interactive extended TAQOZ SD boot mode? It would look for a signature in the MBR different from the one Cluso's SD booter looks for, and, upon finding this signature, run the MBR as compiled TAQOZ bytecode with full access to the rest of TAQOZ. There would be a TAQOZ utility - whether in ROM or in an extension - for compiling TAQOZ code into bytecode and then writing it to the MBR.
I agree with Cluso's take on this. From an industrial viewpoint, 'do nothing' is what you want, should a boot fail.
I think from a hobbyist perspective, we'll be using boards which have a flash chip on there, so boot and debug behaviour can be loaded into the flash. As hobbyists with the P1 almost all boards had an EEPROM to achieve this
However, as a compromise, are there any boot resistor combinations left over? One of those pullup/pulldown/float combinations could perhaps direct to Taqoz in the event of all others failing
I agree with Cluso's take on this. From an industrial viewpoint, 'do nothing' is what you want, should a boot fail.
I think from a hobbyist perspective, we'll be using boards which have a flash chip on there, so boot and debug behaviour can be loaded into the flash. As hobbyists with the P1 almost all boards had an EEPROM to achieve this
However, as a compromise, are there any boot resistor combinations left over? One of those pullup/pulldown/float combinations could perhaps direct to Taqoz in the event of all others failing
I really like the idea of having this behavior set by resistor combo. I'm finding it mildly annoying to enter the key sequence every time I reconnect the P2-ES as I've spent most of my time in TaqOZ. I do understand how commercial applications would prefer the do nothing approach.
From a hobbyist perspective of the P1, I really wish I didn't need the EEPROM to boot into SD which you guys did a great job solving. But now we have the further complication of TaqOZ, a very welcome one but a new problem to solve. I guess I'm happy with the way it is now if all else fails. I just think it would be nice to be able to plug-in the board and have it drop into TaqOZ by setting a switch, or something.
IMHO for a commercial designer, I would probably not want my system to fall into TAQOZ if the booting failed........
As a field service engineer who services, upgrades, and refurbishes equipment I would want my system to fall into TAQOZ so that I could then perform remote diagnostics via the internet or a modem. That would be a great boon, particularly for equipment at remote locations.
As a field service engineer who services, upgrades, and refurbishes equipment I would want my system to fall into TAQOZ so that I could then perform remote diagnostics via the internet or a modem. That would be a great boon, particularly for equipment at remote locations.
Surely you can do that now ? - It requires merely that you be the one in control of that 'remote diagnostics via the internet or a modem' connection.
The present eventual fall thru to power-minimum, is a choice by Chip to conserve batteries - anyone with link control, can reset P2, wake it up, and enter TAQOZ.
Auto-fall into TAQOZ means the battery is likely flat when you try to remotely connect...
As a field service engineer who services, upgrades, and refurbishes equipment I would want my system to fall into TAQOZ so that I could then perform remote diagnostics via the internet or a modem. That would be a great boon, particularly for equipment at remote locations.
+1
Mind you all the times I dealt with devices having this capability you could hardly call them embedded. But they were a godsend at the time.
I'm actually quite appalled by the attitude towards TAQOZ both as a "hobbyist" tool, and that it is too "dangerous" to be given control in the bootchain.
Chip, Ray, others, are you guys serious? I'm mean really, what is this great thing about "saving batteries" in a system that is so far removed from the humble pencell driven Stamps and even Prop chips to a system that "requires" switching regulators, LDOs, and dozens of caps for a minimal system. Those devices alone will draw quiescent power that can eat up batteries.
We have the chance finally to have a chip that has sufficient software resources onboard and inbuilt not only to support hardware diagnostics but also includes VGA text and graphics as well as PS/2 keyboard, and includes what is shaping up to be one mean SD disk utility among other things. To "boot" you can also develop code without any external compilers, completely platform independent it is. I'm sure I could write many more paragraphs summarizing the features and advantages but all this is squeezed into the 16KB of ROM along with Chip's booter and Ray's SD booter and debugger which wasn't asked for at the time but Cluso99 volunteered to add SD boot even though TAQOZ has this built-in. So what was the advantage now of this extra uncalled for SD booter??? At least TAQOZ would be more flexible and faster with loading files since it can now also treat Flash as a FAT32 device too.
By appalled I mean I'm really cheesed off. I don't know why I'm knocking myself out to do what I do since it is all so easily dissed.
I'm actually quite appalled by the attitude towards TAQOZ both as a "hobbyist" tool, and that it is too "dangerous" to be given control in the bootchain.
Chip, Ray, others, are you guys serious? I'm mean really, what is this great thing about "saving batteries" in a system that is so far removed from the humble pencell driven Stamps and even Prop chips to a system that "requires" switching regulators, LDOs, and dozens of caps for a minimal system. Those devices alone will draw quiescent power that can eat up batteries.
We have the chance finally to have a chip that has sufficient software resources onboard and inbuilt not only to support hardware diagnostics but also includes VGA text and graphics as well as PS/2 keyboard, and includes what is shaping up to be one mean SD disk utility among other things. To "boot" you can also develop code without any external compilers, completely platform independent it is. I'm sure I could write many more paragraphs summarizing the features and advantages but all this is squeezed into the 16KB of ROM along with Chip's booter and Ray's SD booter and debugger which wasn't asked for at the time but Cluso99 volunteered to add SD boot even though TAQOZ has this built-in. So what was the advantage now of this extra uncalled for SD booter??? At least TAQOZ would be more flexible and faster with loading files since it can now also treat Flash as a FAT32 device too.
By appalled I mean I'm really cheesed off. I don't know why I'm knocking myself out to do what I do since it is all so easily dissed.
Because some of us truly appreciate all of your effort, and are quite impressed with the result.
I can understand you feeling cheesed off, but its important to remember we're discussing individual preferences here. People are going to have different preferences based on experiences good and bad. Kwinn and I probably are discussing the same scenario but have different takes for different reasons.
Given the unavoidable schism, how bad would resistor selection be?
I'm very happy with Taqoz and having it in the ROM, likewise with SD boot
What you have done with TAQOZ is truly amazing and the fact we have it in ROM is even more so.
And it’s not that i only see it as hobbyist, for i really don’t.
This is how I see it...
IMHO the ROM version of TAQOZ is a tool for...
1. Experimenting with the P2
2. Debugging hardware in case of board faults
3. Hobbyist playing (yes last)
Now, your full-blown TAQOZ will be loaded from Flash/SD/serial and is useful for...
4. Developing software
5. Hobbyist snd Commercial software solutions
You see, anyone wanting to use the full power of TAQOZ will need to load it with their code, and that is going to require Flash/SD/serial to boot the code. In this case, there is no requirement to have TAQOZ to autoboot.
There have already been some asking for TAQOZ to be available for more general use, such as calling TAQOZ from their program, passing it commands, redirecting the serial, etc. This will only be likely with the fuller version of TAQOZ.
Thinking on this a bit more, and also digesting Cluso's comments, if TAQOZ were added as proposed in the above images, perhaps removing the 60 second serial window would make sense. Or make it 100 ms instead.
Reasons being...
If the TAQOZ prompt is desired, there seems little point waiting 60 seconds for it. (Sure, you can ESC > into it, but that's another thing)
From the prompt, I assume you can execute whatever code you'd like from SD (and maybe from FLASH) anyhow?
If TAQOZ could either call a reset or invoke the serial window, then serial download will also be an option in this mode.
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.
Thinking on this a bit more, and also digesting Cluso's comments, if TAQOZ were added as proposed in the above images, perhaps removing the 60 second serial window would make sense. Or make it 100 ms instead.
Reasons being...
If the TAQOZ prompt is desired, there seems little point waiting 60 seconds for it. (Sure, you can ESC > into it, but that's another thing)
From the prompt, I assume you can execute whatever code you'd like from SD (and maybe from FLASH) anyhow?
If TAQOZ could either call a reset or invoke the serial window, then serial download will also be an option in this mode.
Just because you drop into TAQOZ if all else fails, does not mean that you can avoid entering an autobaud character sequence. TAQOZ will need to autobaud instead of Chips serial booter.
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.
Just because you drop into TAQOZ if all else fails, does not mean that you can avoid entering an autobaud character sequence. TAQOZ will need to autobaud instead of Chips serial booter.
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.
Perhaps autobaud is only desirable from the serial terminal?
I don't know- I can totally see this debate from both sides.
Sure, full TAQOZ can run from Flash or SD. And one might argue, why have TAQOZ in the rom at all.
But by the same logic, the same could be said for the SD booter. That could also be a user-added Flash routine, rather than resident in rom and unchangeable for future versions of SD or file format.
If TAQOZ does reside in rom (which I've been thankful for many times already), then it just seems kinda flunky to hide it only behind a difficult to remember key press sequence.
TAQOZ seems like a positive feature and selling point. If nothing else, then the P2 providing a simple terminal from which to run some "proof of life" scripts has been far more valuable in development than booting from SD has been. So from a development perspective, I'd actually remove booting from SD and let the user implement that in Flash code, before removing TAQOZ.
Sure- I'm biased to a narrow use case in this analysis.
As I said, I can see there are clear benefits to both SD Boot and TAQOZ for different users. And neither are useful for others.
So that gets me back to the same thinking as Mike above. If it's there, then show the feature and be proud!
If all else fails it seems like the chip should default to the monitor program. It has a small number of commands that are easily understood, and it allows the user to probe the chip a bit. If someone wants to use taqoz they can just hit a few keys to start it from the monitor.
Just because you drop into TAQOZ if all else fails, does not mean that you can avoid entering an autobaud character sequence. TAQOZ will need to autobaud instead of Chips serial booter.
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.
Perhaps autobaud is only desirable from the serial terminal?
I don't know- I can totally see this debate from both sides.
Sure, full TAQOZ can run from Flash or SD. And one might argue, why have TAQOZ in the rom at all.
But by the same logic, the same could be said for the SD booter. That could also be a user-added Flash routine, rather than resident in rom and unchangeable for future versions of SD or file format.
If TAQOZ does reside in rom (which I've been thankful for many times already), then it just seems kinda flunky to hide it only behind a difficult to remember key press sequence.
TAQOZ seems like a positive feature and selling point. If nothing else, then the P2 providing a simple terminal from which to run some "proof of life" scripts has been far more valuable in development than booting from SD has been. So from a development perspective, I'd actually remove booting from SD and let the user implement that in Flash code, before removing TAQOZ.
Sure- I'm biased to a narrow use case in this analysis.
As I said, I can see there are clear benefits to both SD Boot and TAQOZ for different users. And neither are useful for others.
So that gets me back to the same thinking as Mike above. If it's there, then show the feature and be proud!
Autobaud is required, not for the primary reason to determine the baud, but to determine the rcfast frequency. So autobaud is mandatory until a switch can be made to the crystal/oscillator.
The SD Booter was actually requested many years ago. I was one of the proponents but was not the only one. The benefitvof an SD Booter is so that the Flash part is not required. Its a cost and BOM impediment for volumme production if SD is required. If SD isn’t required, then Flash is required. Some may have both, but I would expect if SD is used in production, then Flash will not be fitted.
TAQOZ in ROM has been an absolute gem. I used it to get the P2D2 proving sigb of life even brfore i inserted an SD card with a simple LED flashing file. No-one is saying remove TAQOZ from ROM. certainly i am not! Peter is trying to squeeze even more features in so he’s even worked out compression.
But, P1 suffered the stigma of being a hobbyist chip, principally becsuse of the “Beanie”. What a joke, but that’s real
We don’t want the P2 to suffer because it drops into TAQOZ, or the Monitor/Debugger for that matter. Make it a determined key sequence. It’s just a shame it’s not an easy to remember sequence. FWIW I suggested “at” like we used for modems back in the day.
Unfortunately some will incorrectly percieve TAQOZ as being a toy. Some think spin is a toy too. Both are wrong, but we don’t want any negatives for P2.
FWIW some chips have bootloaders inbuilt. But they are all invoked by some method. They don’t fall into them.
Comments
There are 60 seconds to invoke TAQOZ by the “ <“ and <esc> serial sequence, which has the added bonus of autobaud.
Anyone recall or have a link?
I couldn’t think of a way to test/verify it.
@cgracey - I'd like TAQOZ to be included in the boot chain and not just summoned with an arcane invocation that needs to be entered in less than 60 seconds. There is no reason why this can't be so and while TAQOZ can autoboot a user program that may access user I/O, it does not do this automatically, except in my current test version where I run VGA.
So obviously if TAQOZ in ROM were booted then it would check the SD and perhaps the Flash for a config file so that it can startup at the user specified baud-rate and with VGA and keyboard if so desired. But in a totally blank system TAQOZ can only check the standard boot devices and listen to the serial console, and if it hasn't saved any clock config from a previous boot, then it would have to autobaud.
If there is no boot code or activity then I guess it could shutdown although running at RCFAST should be sufficient considering that the P2 is nothing like the P1 but requires switching regulators that normally would still draw considerable quiescent current, even with a very light load.
@msrobots - btw, I already mentioned in previous posts that I could incorporate a mailbox (it's a no-brainer too).
From the P2 documentation...
I/O PIN TIMING I/O pins are controlled by cogs via the following cog registers: DIRA - output enable bits for P0..P31 (active high) DIRB - output enable bits for P32..P63 (active high) OUTA - output state bits for P0..P31 (corresponding DIRA bit must be high to enable output) OUTB - output state bits for P32..P63 (corresponding DIRB bit must be high to enable output) I/O pins are read by cogs via the following cog registers: INA - input state bits for P0..P31 INB - input state bits for P32..P63 Aside from general-purpose instructions which may operate on DIRA/DIRB/OUTA/OUTB, there are special pin instructions which operate on singular bits within these registers: DIRL/DIRH/DIRC/DIRNC/DIRZ/DIRNZ/DIRRND/DIRNOT {#}D - affect pin D bit in DIRx OUTL/OUTH/OUTC/OUTNC/OUTZ/OUTNZ/OUTRND/OUTNOT {#}D - affect pin D bit in OUTx FLTL/FLTH/FLTC/FLTNC/FLTZ/FLTNZ/FLTRND/FLTNOT {#}D - affect pin D bit in OUTx, clear bit in DIRx DRVL/DRVH/DRVC/DRVNC/DRVZ/DRVNZ/DRVRND/DRVNOT {#}D - affect pin D bit in OUTx, set bit in DIRx As well, aside from general-purpose instructions which may read INA/INB, there are special pin instructions which can read singular bits within these registers: TESTP {#}D WC/WZ/ANDC/ANDZ/ORC/ORZ/XORC/XORZ -read pin D bit in INx and affect C or Z TESTPN {#}D WC/WZ/ANDC/ANDZ/ORC/ORZ/XORC/XORZ -read pin D bit in !INx and affect C or Z When a DIRx/OUTx bit is changed by any instruction, it takes THREE additional clocks after the instruction before the pin starts transitioning to the new state. Here this delay is demonstrated using DRVH: ____0 ____1 ____2 ____3 ____4 ____5 Clock: / \____/ \____/ \____/ \____/ \____/ \____/ DIRA: | | DIRA-->| REG-->| REG-->| REG-->| P0 DRIV | OUTA: | | OUTA-->| REG-->| REG-->| REG-->| P0 HIGH | | | Instruction: | DRVH #0 | When an INx register is read by an instruction, it will reflect the state of the pins registered TWO clocks before the start of the instruction. Here this delay in demonstrated using TESTB: ____0 ____1 ____2 ____3 ____4 Clock: / \____/ \____/ \____/ \____/ \____/ INA: | P0 IN-->| REG-->| REG-->| ALU-->| C/Z-->| | | Instruction: | TESTB INA,#0 | When a TESTP/TESTPN instruction is used to read a pin, the value read will reflect the state of the pin registered ONE clock before the start of the instruction. So, TESTP/TESTPN get fresher INx data than is available via the INx registers: ____0 ____1 ____2 ____3 Clock: / \____/ \____/ \____/ \____/ INA: | P0 IN-->| REG-->| REG-->| C/Z-->| | | Instruction: | TESTP #0 |Hopefully that helps!
SPIRD rep @sre1,#8 ' 8 bits outnot sck ' clock (low high) RWAIT nop outnot sck nop testp miso wc ' read data from card rcl tos,#1 ' shift in msb first sre1 retThis code works fine at RCFAST and at 340MHz.
Thanks. I knew i had seen that info somewhere and i know it was also fiscussed in one of the threads.
@"Peter Jakacki"
Thanks. I was just eanting to verify what i have. It works fine but always nice to confirm theory too.
Wondering if this will change in the new silicon with the clock gating changes ???
The difference here is that I hope you stated you would do this and not you could do this.
I am pretty sure you can do this, I am just begging you to do it.
I also think it would be nice to end up in TAQOZ if every thing else fails, and I see no problem there with unknown hardware attached since TAQOZ just uses the same pins as the booter.
Maybe shut down if serial boot is disabled, else end up in TAQOZ if nothing else works?
Enjoy!
Mike
+1
TAQOZ is there to help get a board running and perform some tests.
TAQOZ would NOT be present for a commercial system, at least in it's current version. The commercial system would load its' own code from Flash or SD or be loaded by something else. If TAQOZ is being used, it would be in an extended for with other goodies.
IMHO for a commercial designer, I would probably not want my system to fall into TAQOZ if the booting failed.
However, hobbyists would probably prefer it to fall into TAQOZ.
I am more inclined to see that falling into TAQOZ would be viewed by the commercial designer as a "hobbyist" chip and give it a miss for their designs. We had that stigma with the P1.
So, I am more inclined to say that it should not fall into TAQOZ. Sorry Peter. It is easy enough to invoke, just like the Monitor/Debugger.
The same goes for "calling" TAQOZ from a user (hobbyist) program. If you are calling it, you will want the extended "bells and whistles" version of TAQOZ and that will be loaded from Flash/SD/Downloaded.
A professional program that uses TAQOZ will also be loaded with the extended TAQOZ and user routines.
I'm unclear on what this "fall into TAQOZ" really means ?
Currently when I enter TAQOZ now, there is a significant delay ( ~ 250ms to load) and then a splash screen on the terminal.
That means a failure could spit a lot a chaff out the serial port, at a totally unexpected time.
That's not really a good idea, and certainly unwanted in any commercial system.
I think from a hobbyist perspective, we'll be using boards which have a flash chip on there, so boot and debug behaviour can be loaded into the flash. As hobbyists with the P1 almost all boards had an EEPROM to achieve this
However, as a compromise, are there any boot resistor combinations left over? One of those pullup/pulldown/float combinations could perhaps direct to Taqoz in the event of all others failing
I really like the idea of having this behavior set by resistor combo. I'm finding it mildly annoying to enter the key sequence every time I reconnect the P2-ES as I've spent most of my time in TaqOZ. I do understand how commercial applications would prefer the do nothing approach.
From a hobbyist perspective of the P1, I really wish I didn't need the EEPROM to boot into SD which you guys did a great job solving. But now we have the further complication of TaqOZ, a very welcome one but a new problem to solve. I guess I'm happy with the way it is now if all else fails. I just think it would be nice to be able to plug-in the board and have it drop into TaqOZ by setting a switch, or something.
Just my 2c..
As a field service engineer who services, upgrades, and refurbishes equipment I would want my system to fall into TAQOZ so that I could then perform remote diagnostics via the internet or a modem. That would be a great boon, particularly for equipment at remote locations.
Surely you can do that now ? - It requires merely that you be the one in control of that 'remote diagnostics via the internet or a modem' connection.
The present eventual fall thru to power-minimum, is a choice by Chip to conserve batteries - anyone with link control, can reset P2, wake it up, and enter TAQOZ.
Auto-fall into TAQOZ means the battery is likely flat when you try to remotely connect...
+1
Mind you all the times I dealt with devices having this capability you could hardly call them embedded. But they were a godsend at the time.
Chip, Ray, others, are you guys serious? I'm mean really, what is this great thing about "saving batteries" in a system that is so far removed from the humble pencell driven Stamps and even Prop chips to a system that "requires" switching regulators, LDOs, and dozens of caps for a minimal system. Those devices alone will draw quiescent power that can eat up batteries.
We have the chance finally to have a chip that has sufficient software resources onboard and inbuilt not only to support hardware diagnostics but also includes VGA text and graphics as well as PS/2 keyboard, and includes what is shaping up to be one mean SD disk utility among other things. To "boot" you can also develop code without any external compilers, completely platform independent it is. I'm sure I could write many more paragraphs summarizing the features and advantages but all this is squeezed into the 16KB of ROM along with Chip's booter and Ray's SD booter and debugger which wasn't asked for at the time but Cluso99 volunteered to add SD boot even though TAQOZ has this built-in. So what was the advantage now of this extra uncalled for SD booter??? At least TAQOZ would be more flexible and faster with loading files since it can now also treat Flash as a FAT32 device too.
By appalled I mean I'm really cheesed off. I don't know why I'm knocking myself out to do what I do since it is all so easily dissed.
Because some of us truly appreciate all of your effort, and are quite impressed with the result.
I can understand you feeling cheesed off, but its important to remember we're discussing individual preferences here. People are going to have different preferences based on experiences good and bad. Kwinn and I probably are discussing the same scenario but have different takes for different reasons.
Given the unavoidable schism, how bad would resistor selection be?
I'm very happy with Taqoz and having it in the ROM, likewise with SD boot
What you have done with TAQOZ is truly amazing and the fact we have it in ROM is even more so.
And it’s not that i only see it as hobbyist, for i really don’t.
This is how I see it...
IMHO the ROM version of TAQOZ is a tool for...
1. Experimenting with the P2
2. Debugging hardware in case of board faults
3. Hobbyist playing (yes last)
Now, your full-blown TAQOZ will be loaded from Flash/SD/serial and is useful for...
4. Developing software
5. Hobbyist snd Commercial software solutions
You see, anyone wanting to use the full power of TAQOZ will need to load it with their code, and that is going to require Flash/SD/serial to boot the code. In this case, there is no requirement to have TAQOZ to autoboot.
There have already been some asking for TAQOZ to be available for more general use, such as calling TAQOZ from their program, passing it commands, redirecting the serial, etc. This will only be likely with the fuller version of TAQOZ.
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.
Reasons being...
If the TAQOZ prompt is desired, there seems little point waiting 60 seconds for it. (Sure, you can ESC > into it, but that's another thing)
From the prompt, I assume you can execute whatever code you'd like from SD (and maybe from FLASH) anyhow?
If TAQOZ could either call a reset or invoke the serial window, then serial download will also be an option in this mode.
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
Just because you drop into TAQOZ if all else fails, does not mean that you can avoid entering an autobaud character sequence. TAQOZ will need to autobaud instead of Chips serial booter.
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.
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.
Perhaps autobaud is only desirable from the serial terminal?
I don't know- I can totally see this debate from both sides.
Sure, full TAQOZ can run from Flash or SD. And one might argue, why have TAQOZ in the rom at all.
But by the same logic, the same could be said for the SD booter. That could also be a user-added Flash routine, rather than resident in rom and unchangeable for future versions of SD or file format.
If TAQOZ does reside in rom (which I've been thankful for many times already), then it just seems kinda flunky to hide it only behind a difficult to remember key press sequence.
TAQOZ seems like a positive feature and selling point. If nothing else, then the P2 providing a simple terminal from which to run some "proof of life" scripts has been far more valuable in development than booting from SD has been. So from a development perspective, I'd actually remove booting from SD and let the user implement that in Flash code, before removing TAQOZ.
Sure- I'm biased to a narrow use case in this analysis.
As I said, I can see there are clear benefits to both SD Boot and TAQOZ for different users. And neither are useful for others.
So that gets me back to the same thinking as Mike above. If it's there, then show the feature and be proud!
The SD Booter was actually requested many years ago. I was one of the proponents but was not the only one. The benefitvof an SD Booter is so that the Flash part is not required. Its a cost and BOM impediment for volumme production if SD is required. If SD isn’t required, then Flash is required. Some may have both, but I would expect if SD is used in production, then Flash will not be fitted.
TAQOZ in ROM has been an absolute gem. I used it to get the P2D2 proving sigb of life even brfore i inserted an SD card with a simple LED flashing file. No-one is saying remove TAQOZ from ROM. certainly i am not! Peter is trying to squeeze even more features in so he’s even worked out compression.
But, P1 suffered the stigma of being a hobbyist chip, principally becsuse of the “Beanie”. What a joke, but that’s real
We don’t want the P2 to suffer because it drops into TAQOZ, or the Monitor/Debugger for that matter. Make it a determined key sequence. It’s just a shame it’s not an easy to remember sequence. FWIW I suggested “at” like we used for modems back in the day.
Unfortunately some will incorrectly percieve TAQOZ as being a toy. Some think spin is a toy too. Both are wrong, but we don’t want any negatives for P2.
FWIW some chips have bootloaders inbuilt. But they are all invoked by some method. They don’t fall into them.