In my opinion, poor QFN sales are directly related to the fact that the Propeller is not really designed for low power usage, so small-sized end applications are not a mainstream market for the Propeller. As such, real estate is not a concern normally, so space savings is not a factor to drive a QFN vs QFP choice. Also, QFN packages seem to thwart the DIY/hobbyist/low volume avenues for the Propeller so they just aren't chosen. QFPs are much easier to rework with a standard soldering iron. On the flip side, because I have appropriate equipment, all of the Propeller based products I have designed have used the QFN package.
evanh: I will agree in non-commercial usage (for example toaster oven reflow), BGA and QFN packages do have issues in the field, but from a professional manufacturing environment, BGA and QFN packages are very reliable.
My impression from the current P2 discussions is that users desire the QFP and 2 layer boards for any use of the P2. That's a good start, but I would hope Parallax has bigger dreams for the P2.
After going back and forth with OnSemi, I made new markings like Peter's, but without the "P2" being italicized, since I think it looks fuller without the slant. On the part number, I got rid of the "-" and used an "X" to make it more searchable.
After going back and forth with OnSemi, I made new markings like Peter's, but without the "P2" being italicized, since I think it looks fuller without the slant. On the part number, I got rid of the "-" and used an "X" to make it more searchable.
A few thoughts:
1. It would be much better with the OnSemi "AWLYYWWW CCCCC" on a single line and their dummy text would fit at the size shown.
2. The big "P2" looks too squashed vertically and (1) would allow room for it be taller.
3. There is very little gap between characters in "P2X8C4M64P" and if a tiny bit smaller they could fit in the same width but be more legible.
TonyB_, I agree. It is OnSemi's policy to have TWO lines for their own markings. No getting around this. It doesn't even seem worth asking them if they could, at least, center justify those lines.
I detected Chip's hint about liking the non-italicized "P2" marking a few days back, but nobody took the bait and encouraged him to go with it (partly since a couple had stated a preference for the italicized version). But good on you, Chip, for going with your gut (even if your gut feeling changes). Both versions are good: one fills space better to stand out that way, the other uses an edgy slant to stand out. There's no right or wrong as such. Anyway, seeing the artwork on a package diagram has got to be a good sign with respect to progress.
I detected Chip's hint about liking the non-italicized "P2" marking a few days back, but nobody took the bait and encouraged him to go with it (partly since a couple had stated a preference for the italicized version). But good on you, Chip, for going with your gut (even if your gut feeling changes). Both versions are good: one fills space better to stand out that way, the other uses an edgy slant to stand out. There's no right or wrong as such. Anyway, seeing the artwork on a package diagram has got to be a good sign with respect to progress.
I prefer italicized but I'm easy going as long as it makes some sense, which it does. We have a good and meaningful part number, a bold P2 with matching font, and Parallax Inc. This is Chip's chip and with the support of forumistas it is something to be really really proud of, a thing we would call being "chuffed", like a proud happy father.
Now, I am going to do up some "P2 Inside" stickers as well as finish off some pcb designs, but not before I test and finish the ROM.
I'm going through my ROM_Booter code, separating SPI_DI and SPI_DO.
I've got a check in place for a pull-up on SPI_CK (also SD_CS) which will branch to Cluso's SD code.
My pinout is as follows:
P61 = SPI_CS SD_CK
P60 = SPI_CK SD_CS
P59 = SPI_DI SD_DI
P58 = SPI_DO SD_DO
If pull-up on P60branch to SD booter
If pull-up on P61attempt to load from SPI
if SPI data okay
if pull-up on P59immediately run SPI code
allow100ms serial window before running SPI code
allow60s serial window
If a certain character sequence is received during the serial window, a branch to TAQOZ occurs.
Pinouts correct but please don't put the SD card on the pins with verilog. We need to connect our own hardware.
Here is the code section we have been working towards for the pullup tests..
{ BOOT SEQUENCE
SERIAL
+----------------
P63 | RX else = 4th boot SERIAL
P62 | TX ASSERT TXD PU ??????
FLASH SD
+---------------
P61 | CSn CLK spi_cs | sd_ck pu = 4th boot FLASH (APP) (no pd)
P60 | CLK CSn spi_ck | sd_cs pu = 3rd boot SD (no pd)
P59 | DI DI MOSI spi_dq | sd_di pu = 2nd boot SERIAL
NOTE: could use pd here to disable serial & TAQOZ for security conscious product
P58 | DO DO MISO spi_do | sd_do pu = 1st boot FLASH (TEST)
}' WARNING: The following code does not set c & z correctly to go to #main !!!callpa #spi_do,#check_pullup 'spi_dq pull-up? load from FLASH (ROM) <<<<<<<<<<<<<<<<<<<<<<<<<< peter to do !!!!if_cjmp #FLASHROM
callpa #spi_dq,#check_pullup
if_cjmp #\try_serial ' Force serial'callpa #spi_ck,#check_pullup 'spi_ck pull-up? load from SDcardif_cjmp #@_SDcard_boot 'y: (hubexec)callpa #spi_cs,#check_pullup 'spi_cs pull-up? load from FLASH (APP)if_cjmp #\try_flash 'y:
.doserial cmp x,x wc' c=0jmp #\try_serial ' load from SERIAL
FLASHROM
rdlong x,#bootflg '<<<<<<<<<<<<<<<<<< peter to completemov y,#romsig
cmp x,y wzwrlong y,#bootflg
if_zjmp #\try_serial ' skip - already loaded ROM from Flash ''+-----------------------------------------------------------------------------+'+ FLASH: Load from SPI memory, if present (c=1) +'+-----------------------------------------------------------------------------+
try_flash drvh #spi_cs 'make spi_cs high (pbj)'''dirh #spi_cs 'make spi_cs output <<<<<<<<<<<<<<<<<<<<<<<<<< chip to verify happy to do thisdrvl #spi_ck 'make spi_ck outputnegpb,#1'set command bits to all 1'scallpa #2,#spi_cmd 'send exit-quad commandcallpa #8,#spi_cmd 'send exit-quad commandcallpa #16,#spi_cmd 'send exit-dual commandcallpb #$66,#spi_cmd8 'send reset-enable commandcallpb #$99,#spi_cmd8 'send reset commandwaitx ##rc_max/20_000'wait 50uscallpb #$04,#spi_cmd8 'send write-disable command to clear WEL
.wait callpb #$05,#spi_cmd8 'send read-status commandcall #spi_in 'get statustestbn x,#1wz'if WEL high, no SPI memoryif_nzjmp #.floattestbn x,#0wz'if BUSY high, wait for erase/write to finishif_nzjmp #.wait
movpa,#32'send read-from-start commandcallpb #$03,#spi_cmd
cmp bootflg,#romsig wz' ok to rom boot?' '<<<<<<<<<<<<<<<<<< peter to complete/commentif_zdecod y,#14' read 16kB'if_zwrfast #0,##_hubrom ' to hubrom 'if_nzdecod y,#10'ready to input $400 bytes from SPIif_nzwrfast #0,#0'ready to write bytes to hub
.data call #spi_in 'get bytewfbyte x 'store byte into hubdjnz y,#.data 'loop for next byte (y=0 after)cmp bootflg,#romsig wz' ok to run rom boot?'if_zcoginit #0,##_hubrom ' just run this code ' '<<<<<<<<<<<<<<<<<< peter to complete/commentrdfast #0,#0'ready to read longs from hubrep #2,#$100'ready to read and sum $100 longsrflong z 'read longadd y,z 'sum longcmp y,csum wz'verify checksum, z=1 if okayif_zbith flags,#spi_ok 'if program verified, set spi_ok flag{{
if_z callpa #spi_ck,#check_pullup 'check pull-up on spi_ck, c=1 if pull-up '<<<<<<<<<<<<<<<<<<<<<<<?????
}}
.floatif_nzdirl #spi_cs 'if no SPI memory or program didn't verify, float SPI pinsif_nzdirl #spi_ck
.nospi
jmp #main 'jump to main program in lut, if z=c=1 then run SPI program
and the checking for the autoboard sequences...
get_command getct x 'reset serial timeout in case SPI program readyaddct1 x,timeout_per
mov z,#0'reset string buffer
.bytecall #get_rx 'get bytecmp x,#_TAQOZ_ wz'PBJif_zcall #\reset_pins 'RR disable booter serial/autobaud/interruptsif_zjmp #@TAQOZ 'PBJ - jump to TAQOZ (hubexec?) <<<<<<<<<<<<<<<<< peter to check !!!!!cmp x,#_SDcard_ wz'RRif_zcall #\reset_pins 'RR disable booter serial/autobaud/interruptsif_zjmp #@_SDcard_boot 'RR - jump to SD boot (hub)cmp x,#_Monitor_ wz'RRif_zcall #\reset_pins 'RR disable booter serial/autobaud/interruptsif_zjmp #@_Start_Monitor 'RR - jump to Monitor (hub)rolbyte y,z,#3'scroll byte into 2-long/8-byte string bufferrolbyte z,x,#0cmp y,text_prop wz'"Prop"?if_nzjmp #.byte
P61 = SPI_CS SD_CK
P60 = SPI_CK SD_CS
P59 = SPI_DI SD_DI
P58 = SPI_DO SD_DO
If pull-up on P60branch to SD booter
If pull-up on P61attempt to load from SPI
if SPI data okay
if pull-up on P59immediately run SPI code
allow100ms serial window before running SPI code
allow60s serial window
That code looks to disturb 2 pins, before it decides to start serial ?
Is that the lowest practical impact that can be achieved ?
Does this need a package suffix in there, for the TQFP100 ?
Demand might see a QFN or BGA version offered in the future (same die) ?
You could ask OnSemi what size BGA package this could drop into ?
Well, this package is needed for its heat-dissipating ability. Other packages won't have the same ability and won't be usable for this chip. I think this package is going to be the only one.
But 4 years ago the solution was to use a BGA package?
I saw 3.6W absolute max for a Maxim part in TQFP100-EP.
The P1 was P8X32A.
Propeller/8-Core/32-IO Pins/Model or Revision A(I think there was to be a version of the P1 with 64 IO Pins. Specified from OUTB in Spin documentary)
The P2 should be:
P2-Core #(I think it is still 8)X-IO Pin #-Revision#
Something like:
P2-8X68A
I've been trying to finish off testing the boot ROM code but found I really needed a better hardware setup for my CVA9 board, especially in terms of being able to test the SD and Flash on different pins to rule out any peculiarities with the FPGA and its pcb. The code seems to be running well, I just want to be able to test it a bit more. I was worried that there was a problem with the SD and Flash on the same 4-pins but it seems to boot fine. The logic analyzer is causing the ROM to see pull-downs on all the lines so I will have to check this with the 4-ch scope next.
I want to do some more testing but I've been up all night and it's now 5AM so I figure I will try to catch a few hours sleep for now.
Here are some captures plus a session with TAQOZ setting up serial Flash on P0..P3 for testing and checking Flash IDs and dumping etc as well as checking the I/O pin states.
------------------------------------------------------------------------------
Parallax Propeller II .:.:--TAQOZ--:.:. V1.0-180514.2330 V32 FPGA
------------------------------------------------------------------------------
TAQOZ# $00.02.01.03 SFPINS ok
TAQOZ# SFJID .B $EF ok
TAQOZ# SFSID .L SPACE .L $0751.5F27 $C862.4077 ok
TAQOZ# 0 $40 SF DUMP 00.0000: FF FF FF FF FF FF FF FF FF FF FF FF 39 0A 39 0A ............9.9.
00.0010: 746873 0D 0D 09 492040465449 4D 4520 2B ths...I @FTIME +
00.0020: 20574020 2E 465449 4D 45 0D 0D 2D 2D 2D 09 W@ .FTIME..---.
00.0030: 507269 6E 7420746865206669 6C 6520 6E Print the file n ok
TAQOZ# lsio
PINS
P:00000000001111111111222222222233333333334444444444555555555566P:01234567890123456789012345678901234567890123456789012345678901
=:h~~h~d~~~~~~~~~~~~~~~~~dd~~~d~~~~~~~hhhhh~~~d~d~~~hdhhdd~~~~~~ ok
TAQOZ#
I have the 5V power going to a mains remote outlet that I power on and off with a foot-switch while I also have a reset button on the breakout too.
A minor point but I suggest you change your banner to say "Parallax Propeller 2" instead of "Parallax Propeller II" since the official name of the chip seems to be "P2".
A minor point but I suggest you change your banner to say "Parallax Propeller 2" instead of "Parallax Propeller II" since the official name of the chip seems to be "P2".
True true true, I've been concentrating on code but I also see this in Chip's code:
'****************************************
'* *
'* Propeller II ROM Booter *
'* *
'* 5/12/2018 - v32d *
'* *
'****************************************
I think we are probably going to refer to this chip as the P2 rather than the Propeller 2.
Here are some captures plus a session with TAQOZ setting up serial Flash on P0..P3 for testing and checking Flash IDs and dumping etc as well as checking the I/O pin states.
Looking good.
Is serial boot still tested ?
Does flash boot now support a Size.Offset header, or do users still have to manage and load two flash images ?
Can serial boot, call into Flash loader ? (and I guess SD loader ?)
Here are some captures plus a session with TAQOZ setting up serial Flash on P0..P3 for testing and checking Flash IDs and dumping etc as well as checking the I/O pin states.
Looking good.
Is serial boot still tested ?
Does flash boot now support a Size.Offset header, or do users still have to manage and load two flash images ?
Can serial boot, call into Flash loader ? (and I guess SD loader ?)
Serial hasn't changed but I am looking for lockout conditions.
Chip has his reasons for the two stage boot and one of them is that the first stage can switch to whatever faster speed there is and continue to read 1-bit mode from Flash or switch bit modes. I'd still like to see a block method read into hub supported too though.
It doesn't look like Cluso has any command to load SD from serial though. TAQOZ has serial Flash support and can backup and restore etc but doesn't bother trying to access SD.
Here are some captures plus a session with TAQOZ setting up serial Flash on P0..P3 for testing and checking Flash IDs and dumping etc as well as checking the I/O pin states.
Looking good.
Is serial boot still tested ?
Does flash boot now support a Size.Offset header, or do users still have to manage and load two flash images ?
Can serial boot, call into Flash loader ? (and I guess SD loader ?)
Serial hasn't changed but I am looking for lockout conditions.
Chip has his reasons for the two stage boot and one of them is that the first stage can switch to whatever faster speed there is and continue to read 1-bit mode from Flash or switch bit modes. I'd still like to see a block method read into hub supported too though.
It doesn't look like Cluso has any command to load SD from serial though. TAQOZ has serial Flash support and can backup and restore etc but doesn't bother trying to access SD.
Of course you can boot SD from the Monitor, which can be entered from serial like TAQOZ. It's the "R"un command.
Comments
evanh: I will agree in non-commercial usage (for example toaster oven reflow), BGA and QFN packages do have issues in the field, but from a professional manufacturing environment, BGA and QFN packages are very reliable.
My impression from the current P2 discussions is that users desire the QFP and 2 layer boards for any use of the P2. That's a good start, but I would hope Parallax has bigger dreams for the P2.
I've just seen one click up to Rev 'G', but that wont be P2, right ?
Where have you been??? We're already at Rev 'Z'!
Hehe, well yes....
(Does Chip even keep a build counter ? )
Looking forward to getting my first tracking number verifying "P2's on route!" :cool:
A few thoughts:
1. It would be much better with the OnSemi "AWLYYWWW CCCCC" on a single line and their dummy text would fit at the size shown.
2. The big "P2" looks too squashed vertically and (1) would allow room for it be taller.
3. There is very little gap between characters in "P2X8C4M64P" and if a tiny bit smaller they could fit in the same width but be more legible.
I prefer italicized but I'm easy going as long as it makes some sense, which it does. We have a good and meaningful part number, a bold P2 with matching font, and Parallax Inc. This is Chip's chip and with the support of forumistas it is something to be really really proud of, a thing we would call being "chuffed", like a proud happy father.
Now, I am going to do up some "P2 Inside" stickers as well as finish off some pcb designs, but not before I test and finish the ROM.
Thanks Lachlan.
To test you will need to put...
A SPI Flash part on P61-58 as CS, CLK, MOSI, MISO with a pullup on CS - make the pullup linkable
An SD card on P61-58 as CLK, CS, MOSI, MISO (no pullups)
Both Flash and SD can be combined
P58 & P59 may also have pullups for other options (more later) - make these pullups linkable
Standby as Chip said OnSemi require the code Monday!!!
Forgot to answer. Yes, TAQOZ, SD and Monitor are all working nicely sandboxed.
We are still doing tweeks (saving a few longs here and there, nothing risky)
I'm going through my ROM_Booter code, separating SPI_DI and SPI_DO.
I've got a check in place for a pull-up on SPI_CK (also SD_CS) which will branch to Cluso's SD code.
My pinout is as follows:
P61 = SPI_CS SD_CK P60 = SPI_CK SD_CS P59 = SPI_DI SD_DI P58 = SPI_DO SD_DO If pull-up on P60 branch to SD booter If pull-up on P61 attempt to load from SPI if SPI data okay if pull-up on P59 immediately run SPI code allow 100ms serial window before running SPI code allow 60s serial windowIf a certain character sequence is received during the serial window, a branch to TAQOZ occurs.
Does this sound okay Cluso and Peter?
Here is the code section we have been working towards for the pullup tests..
{ BOOT SEQUENCE SERIAL +---------------- P63 | RX else = 4th boot SERIAL P62 | TX ASSERT TXD PU ?????? FLASH SD +--------------- P61 | CSn CLK spi_cs | sd_ck pu = 4th boot FLASH (APP) (no pd) P60 | CLK CSn spi_ck | sd_cs pu = 3rd boot SD (no pd) P59 | DI DI MOSI spi_dq | sd_di pu = 2nd boot SERIAL NOTE: could use pd here to disable serial & TAQOZ for security conscious product P58 | DO DO MISO spi_do | sd_do pu = 1st boot FLASH (TEST) } ' WARNING: The following code does not set c & z correctly to go to #main !!! callpa #spi_do,#check_pullup 'spi_dq pull-up? load from FLASH (ROM) <<<<<<<<<<<<<<<<<<<<<<<<<< peter to do !!!! if_c jmp #FLASHROM callpa #spi_dq,#check_pullup if_c jmp #\try_serial ' Force serial' callpa #spi_ck,#check_pullup 'spi_ck pull-up? load from SDcard if_c jmp #@_SDcard_boot 'y: (hubexec) callpa #spi_cs,#check_pullup 'spi_cs pull-up? load from FLASH (APP) if_c jmp #\try_flash 'y: .doserial cmp x,x wc ' c=0 jmp #\try_serial ' load from SERIAL FLASHROM rdlong x,#bootflg '<<<<<<<<<<<<<<<<<< peter to complete mov y,#romsig cmp x,y wz wrlong y,#bootflg if_z jmp #\try_serial ' skip - already loaded ROM from Flash ' '+-----------------------------------------------------------------------------+ '+ FLASH: Load from SPI memory, if present (c=1) + '+-----------------------------------------------------------------------------+ try_flash drvh #spi_cs 'make spi_cs high (pbj) '''dirh #spi_cs 'make spi_cs output <<<<<<<<<<<<<<<<<<<<<<<<<< chip to verify happy to do this drvl #spi_ck 'make spi_ck output neg pb,#1 'set command bits to all 1's callpa #2,#spi_cmd 'send exit-quad command callpa #8,#spi_cmd 'send exit-quad command callpa #16,#spi_cmd 'send exit-dual command callpb #$66,#spi_cmd8 'send reset-enable command callpb #$99,#spi_cmd8 'send reset command waitx ##rc_max/20_000 'wait 50us callpb #$04,#spi_cmd8 'send write-disable command to clear WEL .wait callpb #$05,#spi_cmd8 'send read-status command call #spi_in 'get status testbn x,#1 wz 'if WEL high, no SPI memory if_nz jmp #.float testbn x,#0 wz 'if BUSY high, wait for erase/write to finish if_nz jmp #.wait mov pa,#32 'send read-from-start command callpb #$03,#spi_cmd cmp bootflg,#romsig wz ' ok to rom boot?' '<<<<<<<<<<<<<<<<<< peter to complete/comment if_z decod y,#14 ' read 16kB' if_z wrfast #0,##_hubrom ' to hubrom ' if_nz decod y,#10 'ready to input $400 bytes from SPI if_nz wrfast #0,#0 'ready to write bytes to hub .data call #spi_in 'get byte wfbyte x 'store byte into hub djnz y,#.data 'loop for next byte (y=0 after) cmp bootflg,#romsig wz ' ok to run rom boot?' if_z coginit #0,##_hubrom ' just run this code ' '<<<<<<<<<<<<<<<<<< peter to complete/comment rdfast #0,#0 'ready to read longs from hub rep #2,#$100 'ready to read and sum $100 longs rflong z 'read long add y,z 'sum long cmp y,csum wz 'verify checksum, z=1 if okay if_z bith flags,#spi_ok 'if program verified, set spi_ok flag {{ if_z callpa #spi_ck,#check_pullup 'check pull-up on spi_ck, c=1 if pull-up '<<<<<<<<<<<<<<<<<<<<<<<????? }} .float if_nz dirl #spi_cs 'if no SPI memory or program didn't verify, float SPI pins if_nz dirl #spi_ck .nospi jmp #main 'jump to main program in lut, if z=c=1 then run SPI programand the checking for the autoboard sequences...
get_command getct x 'reset serial timeout in case SPI program ready addct1 x,timeout_per mov z,#0 'reset string buffer .byte call #get_rx 'get byte cmp x,#_TAQOZ_ wz 'PBJ if_z call #\reset_pins 'RR disable booter serial/autobaud/interrupts if_z jmp #@TAQOZ 'PBJ - jump to TAQOZ (hubexec?) <<<<<<<<<<<<<<<<< peter to check !!!!! cmp x,#_SDcard_ wz 'RR if_z call #\reset_pins 'RR disable booter serial/autobaud/interrupts if_z jmp #@_SDcard_boot 'RR - jump to SD boot (hub) cmp x,#_Monitor_ wz 'RR if_z call #\reset_pins 'RR disable booter serial/autobaud/interrupts if_z jmp #@_Start_Monitor 'RR - jump to Monitor (hub) rolbyte y,z,#3 'scroll byte into 2-long/8-byte string buffer rolbyte z,x,#0 cmp y,text_prop wz '"Prop"? if_nz jmp #.byteCON _TAQOZ_ = $1B '<esc> ' <esc> goto TAQOZ _SDcard_ = $02 '<stx> ' <Ctl-B> goto SD Boot _Monitor_ = $04 '<eot> ' <Ctl-D> goto Monitor/Debug bootflg = 0 ' ' romsig = $1A5 ' check sig for romboot'That code looks to disturb 2 pins, before it decides to start serial ?
Is that the lowest practical impact that can be achieved ?
But 4 years ago the solution was to use a BGA package?
I saw 3.6W absolute max for a Maxim part in TQFP100-EP.
Propeller/8-Core/32-IO Pins/Model or Revision A(I think there was to be a version of the P1 with 64 IO Pins. Specified from OUTB in Spin documentary)
The P2 should be:
P2-Core #(I think it is still 8)X-IO Pin #-Revision#
Something like:
P2-8X68A
I want to do some more testing but I've been up all night and it's now 5AM so I figure I will try to catch a few hours sleep for now.
Here are some captures plus a session with TAQOZ setting up serial Flash on P0..P3 for testing and checking Flash IDs and dumping etc as well as checking the I/O pin states.
------------------------------------------------------------------------------ Parallax Propeller II .:.:--TAQOZ--:.:. V1.0-180514.2330 V32 FPGA ------------------------------------------------------------------------------ TAQOZ# $00.02.01.03 SFPINS ok TAQOZ# SFJID .B $EF ok TAQOZ# SFSID .L SPACE .L $0751.5F27 $C862.4077 ok TAQOZ# 0 $40 SF DUMP 00.0000: FF FF FF FF FF FF FF FF FF FF FF FF 39 0A 39 0A ............9.9. 00.0010: 74 68 73 0D 0D 09 49 20 40 46 54 49 4D 45 20 2B ths...I @FTIME + 00.0020: 20 57 40 20 2E 46 54 49 4D 45 0D 0D 2D 2D 2D 09 W@ .FTIME..---. 00.0030: 50 72 69 6E 74 20 74 68 65 20 66 69 6C 65 20 6E Print the file n ok TAQOZ# lsio PINS P:00000000001111111111222222222233333333334444444444555555555566 P:01234567890123456789012345678901234567890123456789012345678901 =:h~~h~d~~~~~~~~~~~~~~~~~dd~~~d~~~~~~~hhhhh~~~d~d~~~hdhhdd~~~~~~ ok TAQOZ#I have the 5V power going to a mains remote outlet that I power on and off with a foot-switch while I also have a reset button on the breakout too.
'**************************************** '* * '* Propeller II ROM Booter * '* * '* 5/12/2018 - v32d * '* * '****************************************I think we are probably going to refer to this chip as the P2 rather than the Propeller 2.
EDIT: simplified splash string
---------------------------------------------------------------- Parallax P2 .:.:--TAQOZ--:.:. V1.0 ----------------------------------------------------------------P2 BOOT ROM Dropbox folder
Is serial boot still tested ?
Does flash boot now support a Size.Offset header, or do users still have to manage and load two flash images ?
Can serial boot, call into Flash loader ? (and I guess SD loader ?)
Serial hasn't changed but I am looking for lockout conditions.
Chip has his reasons for the two stage boot and one of them is that the first stage can switch to whatever faster speed there is and continue to read 1-bit mode from Flash or switch bit modes. I'd still like to see a block method read into hub supported too though.
It doesn't look like Cluso has any command to load SD from serial though. TAQOZ has serial Flash support and can backup and restore etc but doesn't bother trying to access SD.
Yes, we looked into that, but integration into the design seemed quite complicated. It was more than I felt I could deal with at the time.