I had a duh moment, I realized I couldn't use ROM Flash on the same pins as SD, so I moved the pull-up/CS to P57 instead and we can still separate SPI data pins. There may be a point to supporting 4-pin mode only in the future but if we always test for 3-pin mode then it means that some designs will be able to use that one extra pin. The thing that concerns me is that with all the pullup options we are introducing caveats for the use of those pins. Since there is no other easy way to do it then maybe we just need to accept that just as P1 reserved 4 pins for booting, that P2 needs 6/7 pins?
Here is what I see as the user connection of Flash and SD.
For 4pin SPI, the resistor is removed and the flash DO pin is connected to P58.
The ROM boot will check for a pullup on P61=CS(Flash) to determine if Flash is present.
The ROM boot will check for a pullup on P60=CS(SD Card internal pullup) to determine if an SD card exists.
When sending information to the Flash, the ROM boot should check for a reply on both P59 and P58. If the reply is on P59 then its 3-pin mode, or the reply is on P58 then its 4pin mode.
I had a duh moment, I realized I couldn't use ROM Flash on the same pins as SD, so I moved the pull-up/CS to P57 instead and we can still separate SPI data pins. There may be a point to supporting 4-pin mode only in the future but if we always test for 3-pin mode then it means that some designs will be able to use that one extra pin. The thing that concerns me is that with all the pullup options we are introducing caveats for the use of those pins. Since there is no other easy way to do it then maybe we just need to accept that just as P1 reserved 4 pins for booting, that P2 needs 6/7 pins?
Keep in mind, with all this pin creep, that you can buy small MCUs now that can boot using just the Serial pins at first, for ~25c, ~21c, with 16-18k of FLASH.
At one stage there was a single pin boot mode, allows just one pin to be committed.
Keep in mind, with all this pin creep, that you can buy small MCUs now that can boot using just the Serial pins at first, for ~25c, ~21c, with 16-18k of FLASH.
At one stage there was a single pin boot mode, allows just one pin to be committed.
You know I love those little support micros, especially since they are just another cheap tiny component these days. In fact they can be smaller and cheaper than the main crystal, but whereas everyone sees a crystal and a regulator as a key component, an extra support micro is a little different. Even though it may be small and cheap, it has to be programmed, somewhere, somehow, sometime. If they were as common and cheap as a 2N2222 and readily and easily available then it could probably be specified as a key component. But there are a lot of crystal and regulator manufacturers and types so that we are not overly dependent upon any one type or source.
The P1 has slow I2C EEPROM but the advantage there was that it was two wire and it was a bus, so you could add more devices to the same 2 wires. What the world needs is I2C addressing but SPI speeds, which is possible, it's just that they don't do it. What a pity. I always think of start and stop conditions as chip selects and never see a need for multi-master or arbitration or clock stretching, it is unnecessary cruft that get in the way of bus speeds.
But the P2 can't afford to come into the world already hobbled by the need for a support chip. Sure, hardware designers can use a micro for single pin booting up to 2M serial but there would have to be a good reason to do so and most designs would never need it.
How do I ensure that a JMP and CALL to a "#label" gets defined as a hub address?
I presume the use of "#@label" just forces an absolute cog/lut/hub address. "##@label" is invalid.
The label can also be in cog or lut space due to the code following cog/lut code.
This is at least one reason why v133a is not working as I have decoded pnut's output.
I have removed the pullups from the SD card on the BeMicroCV-A9 but I am still seeing pullups in software on P61 and P59.
The pullup on P58 has now gone and P60 follows the SD-CSn depending on whether the SD card is inserted or not, as it should.
A pulldown are now seen on P58. P60 has a pulldown if an SD card is not present.
The pullup on P59 (source unknown) causes v133a to go direct to serial (bypassing the further tests - which were also wrong)
The tests for <esc> (TAQOZ) and ctl-D (Monitor) don't work because of the JMP going to cog/lut instead of hub
Overriding P59 with a 10K pulldown does not pull the pin down either.
How do I ensure that a JMP and CALL to a "#label" gets defined as a hub address?
I presume the use of "#@label" just forces an absolute cog/lut/hub address. "##@label" is invalid.
The label can also be in cog or lut space due to the code following cog/lut code.
This is at least one reason why v133a is not working as I have decoded pnut's output.
Cluso
Ttry using #\
For immediate-branch and LOC address operands, "#" is used before the
address. In cases where there is an option between absolute and relative
addressing, the assembler will choose absolute addressing when the branch
crosses between cog and hub domains, or relative addressing when the
branch stays in the same domain. Absolute addressing can be forced by
following "#" with "\".
I certainly got confused about the assembler directives the moment I used a COGINIT. Never did sort it out. I'm guessing this is what Cluso is dealing with too.
@Cluso - don't forget to add the coginit at address 0 to your test code. It doesn't matter if you leave it in there for the final ROM either as only the hub ROM is used anyway but there is no other way to test when you load it via PNut.
orgh 0
org 0
coginit #0,##_hubROM
BTW - I've decided that I don't really need a second SPI Flash for the test "ROM", I will simply read in 16kB from the SPI Flash. So immediately after the mask ROM is loaded and run it will check if there is a pullup on P58 which assigned to the Flash and SD Dout. If so, it will proceed to overwrite the hub ROM with 16kB from the SPI Flash. This doesn't interfere with and has nothing to do with hub ROM loading user code either. I'm thinking of placing the HUB rom code at the start of $0F.C000 in the SPI Flash since the smallest devices we would use are 8Mbit at least and that also corresponds nicely with the hub ROM address.
@Chip - when I test out this code perhaps you can incorporate it into FPGA and also make sure to unmap the I/O so that we can attached SD and SPI Flash to the external I/O pins rather than using the internal memory since we have no control of pullups on the pcb. This way we can test with and without pullups etc and also check the timing and sequencing while we are at it.
@Cluso - don't forget to add the coginit at address 0 to your test code. It doesn't matter if you leave it in there for the final ROM either as only the hub ROM is used anyway but there is no other way to test when you load it via PNut.
orgh 0
org 0
coginit #0,##_hubROM
BTW - I've decided that I don't really need a second SPI Flash for the test "ROM", I will simply read in 16kB from the SPI Flash. So immediately after the mask ROM is loaded and run it will check if there is a pullup on P58 which assigned to the Flash and SD Dout. If so, it will proceed to overwrite the hub ROM with 16kB from the SPI Flash. This doesn't interfere with and has nothing to do with hub ROM loading user code either. I'm thinking of placing the HUB rom code at the start of $0F.C000 in the SPI Flash since the smallest devices we would use are 8Mbit at least and that also corresponds nicely with the hub ROM address.
@Chip - when I test out this code perhaps you can incorporate it into FPGA and also make sure to unmap the I/O so that we can attached SD and SPI Flash to the external I/O pins rather than using the internal memory since we have no control of pullups on the pcb. This way we can test with and without pullups etc and also check the timing and sequencing while we are at it.
I think all this can be done by using the FPGA version I posted that allows the ROM to be overwritten. Just change the software to use the lower pins, for now, instead of P61..P58.
I will switch my ROM code to use the 4-wire setup for SPI.
This is how I would like the pull-up options to be. Does this look okay to you guys?
Serial
+----------------
P63 | RX
P62 | TX
SPI SD
+---------------
P61 | CSn CLK
P60 | CLK CSn
P59 | DI DI
P58 | DO DO
P61 P60
-----------
serial !up !up
serial window + SD !up up
serial window + SPI up !up
SPI or serial if SPI error up up
I had a duh moment, I realized I couldn't use ROM Flash on the same pins as SD, so I moved the pull-up/CS to P57 instead and we can still separate SPI data pins. There may be a point to supporting 4-pin mode only in the future but if we always test for 3-pin mode then it means that some designs will be able to use that one extra pin. The thing that concerns me is that with all the pullup options we are introducing caveats for the use of those pins. Since there is no other easy way to do it then maybe we just need to accept that just as P1 reserved 4 pins for booting, that P2 needs 6/7 pins?
Another approach to reduce affected pins, is to have a resistor between pins also convey user config information.
That's a common trick in i2c address expansion, where they want to get more info encoded into fewer pins.
This is how I would like the pull-up options to be. Does this look okay to you guys?
A variant on that using pin-to-pin resistors, would be this (below). The advantage here, is P60 is now undisturbed for UART boot cases. Only P61 needs to be tested, reducing the impact
The other 3 choices are still covered, and 2 pins are disturbed only once you know you need to use SD/SPI.
Serial
+----------------
P63 | RX
P62 | TX
SPI SD
+---------------
P61 | CSn CLK
P60 | CLK CSn
P59 | DI DI
P58 | DO DO
P61 P60
-------------
serial !up xx P61 floating is Serial, P60 is untouched for serial boot.
serial window + SD up up
serial window + SPI up R-P61 R between P60 & P61 gives another signal case.
SPI or serial if SPI error up !up
I will switch my ROM code to use the 4-wire setup for SPI.
This is how I would like the pull-up options to be. Does this look okay to you guys?
Serial
+----------------
P63 | RX
P62 | TX
SPI SD
+---------------
P61 | CSn CLK
P60 | CLK CSn
P59 | DI DI
P58 | DO DO
P61 P60
-----------
serial !up !up
serial window + SD !up up
serial window + SPI up !up
SPI or serial if SPI error up up
No Chip.
P60's pull-up is not a physical pull-up but rather the internal pull-up inside the SD Card.
Perhaps we can have a chat. I will put up Skype in about 1/2 hr if you are available. Not sure about Peter as he is not at home but will have his laptop with him. I'll call him.
Postedit
Just read your other post Chip where you will be at your mum's so let's wait till Thursday for that call.
No Chip.
P60's pull-up is not a physical pull-up but rather the internal pull-up inside the SD Card.
I'm not clear why that matters ? - the code does not care if it is on the PCB, or inside the SD ?
It does matter that the sense chosen, of pullup, matches what the SD actually does - which it seems to do just fine ?
SERIAL
+----------------
P63 | RX
P62 | TX
FLASH SD
+---------------
P61 | CSn CLK
P60 | CLK CSn
P59 | DI DI MOSI
P58 | DO DO MISO
P61 P60
-----------
!up !up SERIAL
x up SD then SERIAL if SD error
up !up FLASH then SERIAL if FLASH error
My reasoning...
Professional users want the fastest boot time, and they will be using either Flash, SD or both.
The SD card can (normally) be removed. The argument saying it cannot be removed is the same as Flash cannot be removed - it isn't relevant.
SD should take preference over FLASH. Why - because it can be removed, causing Flash or serial to be used instead. And SD can have the program updated on the SD externally.
For download development, either don't fit FLASH/SD or override P61 pull-up with stronger pull-down, and remove SD. We will need you to test the timing and values with the shuttle chip please.
Other option...
Run SERIAL in parallel on a second cog, and if/when the "> " autobaud sequence is seen, terminate the SD/FLASH cog.
Or, have P59 pull-up force SERIAL (disregarding P60 & P61 pull-ups)
3-pin FLASH...
I have no problem with supporting 3-pin as long as 4-pin is also supported. It is quite easy to test for a reply on both P58 & P59 and determine which mode is being used for subsequent replies.
Cluso, that would complicate downloading to RAM vs flash. It would necessitate a switch or a jumper.
Does anyone know if it's possible to change the PC-side DTR line output state without interrupting the data stream being transmitted by the PC? How about on a Mac or a Chromebook? I'm thinking about getting around needing a serial timing window.
I will switch my ROM code to use the 4-wire setup for SPI.
This is how I would like the pull-up options to be. Does this look okay to you guys?
Serial
+----------------
P63 | RX
P62 | TX
SPI SD
+---------------
P61 | CSn CLK
P60 | CLK CSn
P59 | DI DI
P58 | DO DO
P61 P60
-----------
serial !up !up
serial window + SD !up up
serial window + SPI up !up
SPI or serial if SPI error up up
No Chip.
P60's pull-up is not a physical pull-up but rather the internal pull-up inside the SD Card.
Perhaps we can have a chat. I will put up Skype in about 1/2 hr if you are available. Not sure about Peter as he is not at home but will have his laptop with him. I'll call him.
Postedit
Just read your other post Chip where you will be at your mum's so let's wait till Thursday for that call.
Aside from CSn, does an SD card introduce any other pull-ups?
Cluso, that would complicate downloading to RAM vs flash. It would necessitate a switch or a jumper.
Does anyone know if it's possible to change the PC-side DTR line output state without interrupting the data stream being transmitted by the PC? How about on a Mac or a Chromebook? I'm thinking about getting around needing a serial timing window.
There are trade-offs here. What is the prime target? Hobbyist downloading or development vs commercial production?
It's easy enough to program the flash with a non-compliant checksum to force skipping the flash, making serial come up quicker.
The alternative is to run serial in a second cog and terminate the sd/flash download by cogstop.
As for DTR, there are enough problems with PC's etc now with serial. But you are never going to get accurate timing on DTR because the OS will be in the way.
Does anyone know if it's possible to change the PC-side DTR line output state without interrupting the data stream being transmitted by the PC? How about on a Mac or a Chromebook? I'm thinking about getting around needing a serial timing window.
Depends what 'interrupting' means - it is very hard to ensure the DTR has exact character timing, but that can be improved by reading after writing, which I think uses another USB frame (so adds 1ms) and I've not tested it with varying buffer depths...
Some delay will always be present as P2 exits reset, but you can send a continually repeating _Chk string, and Autobaud from that.
ie you can toggle DTR to pulse reset and immediately start TX, and it does not matter what exact timing of DTR/CHAR is, or which (partial) frame the P2 comes out of reset on. The HW Autobaud is strict enough to trigger only on the first whole ">".
That continual send is what a host MCU would do, in order to get the fastest possible boot time.
We know what xerox is doing but we question that operation. Look at the preceding instruction. Together, they imply all bits other than P62 should be zeroed.
Otherwise a DIRH #63 would have been more appropriate.
We know what xerox is doing but we question that operation. Look at the preceding instruction. Together, they imply all bits other than P62 should be zeroed.
Otherwise a DIRH #63 would have been more appropriate.
I still believe the ZEROX instruction should be #29 not #30.
Yes, the DECODE instruction doesn't seem to belong.
A DRVH #62 for idle state would make more sense.
Comments
For 4pin SPI, the resistor is removed and the flash DO pin is connected to P58.
The ROM boot will check for a pullup on P61=CS(Flash) to determine if Flash is present.
The ROM boot will check for a pullup on P60=CS(SD Card internal pullup) to determine if an SD card exists.
When sending information to the Flash, the ROM boot should check for a reply on both P59 and P58. If the reply is on P59 then its 3-pin mode, or the reply is on P58 then its 4pin mode.
Keep in mind, with all this pin creep, that you can buy small MCUs now that can boot using just the Serial pins at first, for ~25c, ~21c, with 16-18k of FLASH.
At one stage there was a single pin boot mode, allows just one pin to be committed.
You know I love those little support micros, especially since they are just another cheap tiny component these days. In fact they can be smaller and cheaper than the main crystal, but whereas everyone sees a crystal and a regulator as a key component, an extra support micro is a little different. Even though it may be small and cheap, it has to be programmed, somewhere, somehow, sometime. If they were as common and cheap as a 2N2222 and readily and easily available then it could probably be specified as a key component. But there are a lot of crystal and regulator manufacturers and types so that we are not overly dependent upon any one type or source.
The P1 has slow I2C EEPROM but the advantage there was that it was two wire and it was a bus, so you could add more devices to the same 2 wires. What the world needs is I2C addressing but SPI speeds, which is possible, it's just that they don't do it. What a pity. I always think of start and stop conditions as chip selects and never see a need for multi-master or arbitration or clock stretching, it is unnecessary cruft that get in the way of bus speeds.
But the P2 can't afford to come into the world already hobbled by the need for a support chip. Sure, hardware designers can use a micro for single pin booting up to 2M serial but there would have to be a good reason to do so and most designs would never need it.
I need some help with pnut...
How do I ensure that a JMP and CALL to a "#label" gets defined as a hub address?
I presume the use of "#@label" just forces an absolute cog/lut/hub address. "##@label" is invalid.
The label can also be in cog or lut space due to the code following cog/lut code.
This is at least one reason why v133a is not working as I have decoded pnut's output.
The pullup on P58 has now gone and P60 follows the SD-CSn depending on whether the SD card is inserted or not, as it should.
A pulldown are now seen on P58. P60 has a pulldown if an SD card is not present.
The pullup on P59 (source unknown) causes v133a to go direct to serial (bypassing the further tests - which were also wrong)
The tests for <esc> (TAQOZ) and ctl-D (Monitor) don't work because of the JMP going to cog/lut instead of hub
Overriding P59 with a 10K pulldown does not pull the pin down either.
Cluso
Ttry using #\
Thanks for that info.
But how can I enforce Hub?
JMP/CALL #addr varies depending on code and placement of org/orgh and the label "addr"
JMP/CALL #@addr seems to always use absolute hub
JMP/CALL #\addr uses absolute cog or absolute hub, depending on code and placement of org/orgh and the label "addr"
BTW - I've decided that I don't really need a second SPI Flash for the test "ROM", I will simply read in 16kB from the SPI Flash. So immediately after the mask ROM is loaded and run it will check if there is a pullup on P58 which assigned to the Flash and SD Dout. If so, it will proceed to overwrite the hub ROM with 16kB from the SPI Flash. This doesn't interfere with and has nothing to do with hub ROM loading user code either. I'm thinking of placing the HUB rom code at the start of $0F.C000 in the SPI Flash since the smallest devices we would use are 8Mbit at least and that also corresponds nicely with the hub ROM address.
@Chip - when I test out this code perhaps you can incorporate it into FPGA and also make sure to unmap the I/O so that we can attached SD and SPI Flash to the external I/O pins rather than using the internal memory since we have no control of pullups on the pcb. This way we can test with and without pullups etc and also check the timing and sequencing while we are at it.
I think all this can be done by using the FPGA version I posted that allows the ROM to be overwritten. Just change the software to use the lower pins, for now, instead of P61..P58.
I will switch my ROM code to use the 4-wire setup for SPI.
This is how I would like the pull-up options to be. Does this look okay to you guys?
Serial +---------------- P63 | RX P62 | TX SPI SD +--------------- P61 | CSn CLK P60 | CLK CSn P59 | DI DI P58 | DO DO P61 P60 ----------- serial !up !up serial window + SD !up up serial window + SPI up !up SPI or serial if SPI error up upAnother approach to reduce affected pins, is to have a resistor between pins also convey user config information.
That's a common trick in i2c address expansion, where they want to get more info encoded into fewer pins.
A variant on that using pin-to-pin resistors, would be this (below). The advantage here, is P60 is now undisturbed for UART boot cases. Only P61 needs to be tested, reducing the impact
The other 3 choices are still covered, and 2 pins are disturbed only once you know you need to use SD/SPI.
Serial +---------------- P63 | RX P62 | TX SPI SD +--------------- P61 | CSn CLK P60 | CLK CSn P59 | DI DI P58 | DO DO P61 P60 ------------- serial !up xx P61 floating is Serial, P60 is untouched for serial boot. serial window + SD up up serial window + SPI up R-P61 R between P60 & P61 gives another signal case. SPI or serial if SPI error up !upP60's pull-up is not a physical pull-up but rather the internal pull-up inside the SD Card.
Perhaps we can have a chat. I will put up Skype in about 1/2 hr if you are available. Not sure about Peter as he is not at home but will have his laptop with him. I'll call him.
Postedit
Just read your other post Chip where you will be at your mum's so let's wait till Thursday for that call.
It does matter that the sense chosen, of pullup, matches what the SD actually does - which it seems to do just fine ?
This is the way I see it
SERIAL +---------------- P63 | RX P62 | TX FLASH SD +--------------- P61 | CSn CLK P60 | CLK CSn P59 | DI DI MOSI P58 | DO DO MISO P61 P60 ----------- !up !up SERIAL x up SD then SERIAL if SD error up !up FLASH then SERIAL if FLASH errorMy reasoning...
Professional users want the fastest boot time, and they will be using either Flash, SD or both.
The SD card can (normally) be removed. The argument saying it cannot be removed is the same as Flash cannot be removed - it isn't relevant.
SD should take preference over FLASH. Why - because it can be removed, causing Flash or serial to be used instead. And SD can have the program updated on the SD externally.
For download development, either don't fit FLASH/SD or override P61 pull-up with stronger pull-down, and remove SD. We will need you to test the timing and values with the shuttle chip please.
Other option...
Run SERIAL in parallel on a second cog, and if/when the "> " autobaud sequence is seen, terminate the SD/FLASH cog.
Or, have P59 pull-up force SERIAL (disregarding P60 & P61 pull-ups)
3-pin FLASH...
I have no problem with supporting 3-pin as long as 4-pin is also supported. It is quite easy to test for a reply on both P58 & P59 and determine which mode is being used for subsequent replies.
Does anyone know if it's possible to change the PC-side DTR line output state without interrupting the data stream being transmitted by the PC? How about on a Mac or a Chromebook? I'm thinking about getting around needing a serial timing window.
Aside from CSn, does an SD card introduce any other pull-ups?
It's easy enough to program the flash with a non-compliant checksum to force skipping the flash, making serial come up quicker.
The alternative is to run serial in a second cog and terminate the sd/flash download by cogstop.
As for DTR, there are enough problems with PC's etc now with serial. But you are never going to get accurate timing on DTR because the OS will be in the way.
No, the card itself only pulls CS high, provided of course the hw designer doesn't go putting resistors on all pins
Depends what 'interrupting' means - it is very hard to ensure the DTR has exact character timing, but that can be improved by reading after writing, which I think uses another USB frame (so adds 1ms) and I've not tested it with varying buffer depths...
Some delay will always be present as P2 exits reset, but you can send a continually repeating _Chk string, and Autobaud from that.
ie you can toggle DTR to pulse reset and immediately start TX, and it does not matter what exact timing of DTR/CHAR is, or which (partial) frame the P2 comes out of reset on. The HW Autobaud is strict enough to trigger only on the first whole ">".
That continual send is what a host MCU would do, in order to get the fastest possible boot time.
Peter & I both think the use of zerox is wrong here. Could you confirm please?
'+-----------------------------------------------------------------------------+ '+ Reset smart pins + '+-----------------------------------------------------------------------------+ reset_pins setint1 #0 'disable int1 mov dira,#0 'reset smart pins (avoids output on mode clears) ''zerox dirb,#30 '' what were you thinking? decod dirb,#(tx_pin-32) wrpin #0,#rx_ths 'clear rx_ths mode wrpin #0,#rx_tne 'clear rx_tne mode wrpin #0,#rx_pin 'clear rx_pin mode _ret_ wrpin #0,#tx_pin 'clear tx_pin mode lut_endThe intent is not clear though.
Basically Chip is doing a single instruction AND dirb,##3fffffff
Otherwise a DIRH #63 would have been more appropriate.
This instruction clears all other dir bits except the txd pin.
Yes, the DECODE instruction doesn't seem to belong.
A DRVH #62 for idle state would make more sense.