The only issue I had was some confusion at first as to whether autobaud was working, since there's no feedback after the "> " -- you have to type either ^D or ESC to get something printed. That's a relatively minor point, but might bite some newbies.
A ? command for the monitor to show the available commands would be handy, but perhaps too much room?
I requested an autobaud echo some time ago, but that never made the cut. Such an echo is useful for fastest reset exit from a host-boot MCU.
The shortest query to get a response response string from the booter is the "> Prop_Chk 0 0 0 0 " which echoes 13,10,"Prop_Ver ","A",13,10
A waiting host MCU can send "> Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 "..
There may be shorter ones that can hop to other parts of ROM, and hop back to booter ?
Not clear if those shorter ones could work as packed strings at the full baud rate ? ie some delays might be required.
I've loaded the P2v32i FPGA image on my Prop123-A9 board and can access the monitor (reports v1.0) and TAQOZ (reports V1.0--142).
SDCard startup boot from _BOOT_P2.BIX and _BOOT_P2.BIY files works and a "Prop_Chk 0 0 0 0" from the terminal returns "Prop_Ver A".
However, running a ctrl-G "Get hardware version" from pnutv32i.exe will report "no hardware found" IF an SDCard is in the socket. There is no external pullup on P2 pin 60. Remove the SDCard and the "Hardware found" message comes up.
I've loaded the P2v32i FPGA image on my Prop123-A9 board and can access the monitor (reports v1.0) and TAQOZ (reports V1.0--142).
SDCard startup boot from _BOOT_P2.BIX and _BOOT_P2.BIY files works and a "Prop_Chk 0 0 0 0" from the terminal returns "Prop_Ver A".
However, running a ctrl-G "Get hardware version" from pnutv32i.exe will report "no hardware found" IF an SDCard is in the socket. There is no external pullup on P2 pin 60. Remove the SDCard and the "Hardware found" message comes up.
The SD card has the pull-up built-in.
I will modify PNut soon to allow for longer
response times, so that it will work with SD cards.
Question: Do we know how long Cluso's SD booter needs before it fails and tries serial? I need to have a timing constant to work with.
v32i seems to be working on my DE2-115; at least, I'm able to get into TAQOZ and the P2-MONITOR.
The only issue I had was some confusion at first as to whether autobaud was working, since there's no feedback after the "> " -- you have to type either ^D or ESC to get something printed. That's a relatively minor point, but might bite some newbies.
A ? command for the monitor to show the available commands would be handy, but perhaps too much room?
At the end of it we still had a whopping 58 bytes "wasted" It might be an idea to allow for it in the next ROM source as an option (just in case). I will be testing better versions of the ROM (just in case).
BAD SD CARD BOOT - 100ms
I've popped an old 256M card in and booted the P2 which of course fails SD boot. I've then been able to go into TAQOZ and confirm boot failure. The time from first boot activity to fail is about 100ms. ( I will do another post for a good card but no boot files as it will take longer to boot) (Also another one for pull-up only)
Confirming SD detection and failure:
Cold start
----------------------------------------------------------------
Parallax P2 .:.:--TAQOZ--:.:. V1.0--142180530-0135
----------------------------------------------------------------
TAQOZ# SD? . -1 ok
TAQOZ# !SD .L $0000_0000 ok
TAQOZ# 00 cmd . 1 ok
It responds to a CMD0 which says it is a real SD card.
Next I force a crc just for this command since it is still in SD mode and check CMD8.
TAQOZ#$87$34 C! ok
TAQOZ#$1AA 8 CMD .W $0005 ok
I repeatedly test but we need a response of 1 and this old card is not able to accommodate a $1AA capabilities.
No, but even so the card should be rejected according to the SD specs I posted since it does not respond with a 1 to a CMD8 as you can see when I talk to it step by step in TAQOZ.
My next few posts will be testing:
1) Pull-up only
2) Good card - non-FAT32
3) Good card - FAT32 with a long (but not too long) directory but no boot file (longest timeout)
PULL-UP on SD CS but no SD - 2ms
The case of a pull-up on SD CS but no SD isn't too bad. Most of the time seems to be taken up with the slow clocking before checking which I am fairly sure is not required of SDHC cards. However, it is only 2ms.
Confirming the pullup where SD? tests for a pullup and returns true/false where -1 is true. Then CMD0 with data of 0 (0 0 CMD) returns with 0 which could even be $FF if it were pulled up on the DO line but we are looking for a $01.
TAQOZ# SD? . -1 ok
TAQOZ# 00 CMD . 0 ok
Confirming that slow clocking is NOT required I insert a card, check it for pull-up, and issue a raw CMD0 without anything else.
TAQOZ# SD? . -1 ok
TAQOZ# 00 CMD . 63 ok
TAQOZ# 00 CMD . 193 ok
TAQOZ# 00 CMD . 1 ok
The card responded after the 3rd try which is well within what we expect and allow for. Timing this without clocking:
TAQOZ# BEGIN SD? UNTIL5 ms LAP BEGIN 00 CMD 1 = UNTIL LAP .LAP 8475 cycles = 105.937us ok
Type a ^X to repeat the last line executed returns the exact same result:
TAQOZ# 8475 cycles = 105.937us ok
So we could know within around 100us or so that it is a real SD card.
I will modify PNut soon to allow for longer response times, so that it will work with SD cards.
Question: Do we know how long Cluso's SD booter needs before it fails and tries serial? I need to have a timing constant to work with.
is there any down side to having a longer timeout ?
Or you could simply continually repeat send of the Autobaud + query, checking for a reply - that auto-adjusts to any variable path delays.
You could allow the user to stop after some seconds, or just have some umbrella timeout
SD BOOT - NEW BLANK FAT32 - 193ms
Now here's another boot fail case I added, one where we insert a brand new FAT32 card that is blank. The SD booter still goes through the motions looking for a raw file before checking the root directory which is blank. Total time spent here is 193ms.
Confirming it is blank and nothing, not even deleted entries in the root directory:
TAQOZ# SD? ok
TAQOZ# DIR .SDSL08G 3230_3631 NO NAME 32k 7,576M
.SDSL08G 3230_3631 NO NAME 32k 7,576M
ok
TAQOZ# @ROOT FOPEN 0$80 SD DUMP
00000: 00000000000000000000000000000000'................'00010: 00000000000000000000000000000000'................'00020: 00000000000000000000000000000000'................'00030: 00000000000000000000000000000000'................'00040: 00000000000000000000000000000000'................'00050: 00000000000000000000000000000000'................'00060: 00000000000000000000000000000000'................'00070: 00000000000000000000000000000000'................' ok
NON-FAT32 SD BOOT FAIL - 320ms
I tried formatting an SD card to NTFS just to give the SD booter something tough to chew on. It seems NTFS is just unpleasant with a timeout of 320ms.
TAQOZ# SD? . -1 ok
TAQOZ# !sd .L $C0FF_8000 ok
TAQOZ# MOUNT ...NCard 0000_0100 Y u q 4k 0M ok
TAQOZ# DIR
...NCard 0000_0100 Y u q 4k 0M
ok
TAQOZ#
FAT32 - MANY FILES BUT NO BOOT - 244ms
I noticed that this old 4G card had been formatted in a PC incorrectly. Always use a proper SD Formatter utility.
Nonetheless, after searching the root directory it timed out after 244ms.
TAQOZ# SD? . -1 ok
TAQOZ# !SD .L $C0FF_8000 ok
TAQOZ# MOUNT .SM00000 F184_E94B WIDGET 4k 3,758M ok
TAQOZ# DIR
.SM00000 F184_E94B WIDGET 4k 3,758M
WIDGET $0000_42AC2015.02.21.14.520
HOME .HTM $0000_42C42015.02.17.15.1968,037
P8CPU .JPG $0000_434C2015.02.17.15.1867,271
IOTPINS .JPG $0000_43D42015.02.17.15.1540,010
LOVE .WAV $0000_44242015.02.16.18.0614,630,692
MENU .TXT $0007_3E8C2014.01.20.22.591,556
EXTEND .FTH $0000_B3EC2015.02.16.15.3199,338
P8 .H $0000_B4B42015.02.13.23.441,401
EASYNET .FTH $0000_B4BC2015.02.13.15.1937,673
W5500 .FTH $0000_B50C2015.02.13.01.5014,872
EASYFILE.FTH $0000_B52C2015.02.12.18.4845,794
SDCARD .FTH $0000_B58C2015.02.12.18.2216,343
IOT5500H.JPG $0000_B5AC2014.11.20.14.0728,237
DRAGON .JPG $0000_B5E42014.11.20.10.31376,830
AI o T 5. 5$0250_42AC1980.02.07.00.024,294,901,760
IOT5500 .JPG $0000_B8C42014.11.18.21.2583,571
128K .BIN $0000_B96C2014.11.06.16.49131,072
256K .BIN $0000_BA6C2014.10.28.07.59262,144
W5200 .FTH $0000_BC6C2014.09.28.23.1919,889
SYSTEM .ROM $0000_BC942015.02.25.15.0565,536
WELCOME .TEL $0000_BD142014.06.19.18.36212
WELCOME .FTP $0000_BD1C2014.06.19.18.34140
DEBUG .ROM $0000_BD242014.06.19.18.3165,536
POPCORN .WAV $0000_BDA42014.06.17.16.15117,804
P8X32A .PDF $0000_BE8C2014.06.17.15.071,442,886
IMAGE3 $0000_C9942014.06.15.23.5480,286
FRED .PNG $0000_CA342014.06.15.15.447,935
FSRSCH .PNG $0000_CA442014.06.15.15.4499,235
FSRPCB .PNG $0000_CB0C2014.06.15.15.4464,764
IMAGE $0000_CB8C2014.06.15.15.4416,204
HTTP404 .HTM $0000_CBAC2014.06.15.15.44564
IMAGE2 $0000_CBB42014.06.15.15.4451,347
IMAGE1 $0000_CC1C2014.06.15.15.4412,500
LOGON .HTM $0000_CC3C2014.06.15.15.44388
TACHYON .HTM $0000_CC442014.06.15.15.43159,937
SITE0004.LOG $0000_CD842014.02.24.14.311,048,576
SITE0003.LOG $0000_D5842014.02.24.14.311,048,576
SITE0002.LOG $0000_DD842014.02.24.14.311,048,576
SITE0001.LOG $0000_E5842014.02.24.14.311,048,576
FAVICON .ICO $0000_ED842013.12.17.09.578,069
SYSLOG .TXT $0000_ED942013.12.03.01.561,048,576
HCB4208 .JPG $0000_F5942013.06.20.20.45340,668
CHARLCD .JPG $0000_F8342013.03.25.11.3045,446
ECOLCD .PDF $0000_F8942012.05.24.21.20342,919
LOVE .MP3 $0000_FB342012.02.13.00.263,981,374
FIRMWARE.ROM $0001_199C2015.02.25.16.3265,536
EASYNET .AVI $0001_1A1C2015.02.25.17.048,651,838
EASYNET2.OGV $0005_29C42015.02.23.12.4869,830,407
Bm - 2 R. P $0000_42AC2107.15.31.31.634,294,967,295
. g o u. t $0398_42AC1980.03.18.00.036,357,093
GOUTPU~1$0000_42AC2015.02.26.14.590
EASYNET3.AVI $0004_666C2015.02.25.15.1025,601,912
ENU2 .TXT $0007_3E8C2015.02.26.15.171,556
MENU1 .TXT $0000_B3C42015.02.26.10.5719,948
TAQOZ# @BOOT FOPEN 0$100 SD DUMP
00000: EB 5890 6D 6B 6673 2E 6661740002082000'.X.mkfs.fat... .'00010: 0200000000 F8 00001000040000080000'................'00020: 00707500 4E 1D 00000000000002000000'.pu.N...........'00030: 01000600000000000000000000000000'................'00040: 800129 4B E9 84 F1 574944474554202020'..)K...WIDGET '00050: 20204641543332202020 0E 1F BE 77 7C AC ' FAT32 ...w|.'00060: 22 C0 74 0B 56 B4 0E BB 0700 CD 10 5E EB F0 32'".t.V.......^..2'00070: E4 CD 16 CD 19 EB FE 5468697320697320 6E '.......This is n'00080: 6F 7420612062 6F 6F 746162 6C 65206469'ot a bootable di'00090: 73 6B 2E 202050 6C 656173652069 6E 7365'sk. Please inse'
000A0: 727420612062 6F 6F 746162 6C 652066 6C 'rt a bootable fl'
000B0: 6F 7070792061 6E 64 0D 0A 707265737320'oppy and..press '
000C0: 61 6E 7920 6B 65792074 6F 207472792061'any key to try a'
000D0: 676169 6E 20 2E 2E 2E 20 0D 0A 0000000000'gain ... .......'
000E0: 00000000000000000000000000000000'................'
000F0: 00000000000000000000000000000000'................' ok
I could do as Jmg suggests and keep sending out connect strings while waiting for a response. This would adapt to fast and slow systems. We could set the try limit at 500ms. It could actually be faster than it is now, in cases where the initially-tried COM port is the correct one. When searching COM ports for a Prop2, it would then have to spend 500ms on each empty port, instead of the current 100ms.
I could do as Jmg suggests and keep sending out connect strings while waiting for a response. This would adapt to fast and slow systems. We could set the try limit at 500ms. It could actually be faster than it is now, in cases where the initially-tried COM port is the correct one.
When searching COM ports for a Prop2, it would then have to spend 500ms on each empty port, instead of the current 100ms.
A blind scan is useful for easily setting things up initially, but it's not going to be the default development loop, surely ?
Few would want all serial ports being messed with.
Options are to save the port the P2 was found on, in a file, and start there next time, and to support command line param saying which explicit port to use ?
You could alternatively do 2 scan passes, one more rapid one that expects serial-default, and then a slower one for the fall-back choices ?
Jmg, yes, the last-working port is remembered during the run-life of PNut.exe. The first download takes a bit longer than the rest. We could bother to save the port number to disk, as well.
Hey Chip, do you think you could update the front page of the docs with an image of the P2 chip artwork including a status box outlining that the chip and P2 ROM have been submitted and a rider about the hazards of internal "alpha" sampling but with a confident note about the expected positive outcome and maybe when chips are available etc? The image will make it seem more real to many. A block diagram up here would also be super.
I'd like to use this document as a reference but if you also publish this Google doc it will be more readily accessible to those who are just casually perusing the document and if you include a link in your document to this pub doc and vice versa then anyone can click to see the original etc.
Peter, I sort of did it. No talk about "alpha sampling", though.
Thanks, I was thinking of a "fine print" rider, maybe down in a footer just so they've been told and you are covered since everyone will ask
"Great! but when?".
As for a block diagram I'd like to show all 64 smart pins, at least in the overall chip pinout block diagram. Here is a rough sketch of what I am thinking about.
Of course, this is just an outline and each cog could show more detail, and there would be hub stuff, cordic, oscillator stuff etc. I'd try to use a common color so that if I showed cog & LUT RAM then I would have little cyan blocks within the cog etc.
As for a block diagram I'd like to show all 64 smart pins, at least in the overall chip pinout block diagram. Here is a rough sketch of what I am thinking about.
Of course, this is just an outline and each cog could show more detail, and there would be hub stuff, cordic, oscillator stuff etc. I'd try to use a common color so that if I showed cog & LUT RAM then I would have little cyan blocks within the cog etc.
Looks good, Peter. Jazz it up if you want and we can put it in there.
Keep an eye on the drawing file in the P2/docs dropbox folder. There's also a pdf version that I will keep updating. Just for now, these are the bits I'm playing with but I'm a long way off yet (complete with errors - for the moment)
Updated!
Along with the CORDIC and PRGN, there is also CT counter and the LOCK flags. That would round it off. There is plenty more but it would just get messy I'd say.
No, but even so the card should be rejected according to the SD specs I posted since it does not respond with a 1 to a CMD8 as you can see when I talk to it step by step in TAQOZ.
My next few posts will be testing:
1) Pull-up only
2) Good card - non-FAT32
3) Good card - FAT32 with a long (but not too long) directory but no boot file (longest timeout)
Comments
The shortest query to get a response response string from the booter is the "> Prop_Chk 0 0 0 0 " which echoes 13,10,"Prop_Ver ","A",13,10
A waiting host MCU can send "> Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 "..
There may be shorter ones that can hop to other parts of ROM, and hop back to booter ?
Not clear if those shorter ones could work as packed strings at the full baud rate ? ie some delays might be required.
SDCard startup boot from _BOOT_P2.BIX and _BOOT_P2.BIY files works and a "Prop_Chk 0 0 0 0" from the terminal returns "Prop_Ver A".
However, running a ctrl-G "Get hardware version" from pnutv32i.exe will report "no hardware found" IF an SDCard is in the socket. There is no external pullup on P2 pin 60. Remove the SDCard and the "Hardware found" message comes up.
The SD card has the pull-up built-in.
I will modify PNut soon to allow for longer
response times, so that it will work with SD cards.
Question: Do we know how long Cluso's SD booter needs before it fails and tries serial? I need to have a timing constant to work with.
At the end of it we still had a whopping 58 bytes "wasted"
I've popped an old 256M card in and booted the P2 which of course fails SD boot. I've then been able to go into TAQOZ and confirm boot failure. The time from first boot activity to fail is about 100ms. ( I will do another post for a good card but no boot files as it will take longer to boot) (Also another one for pull-up only)
Confirming SD detection and failure:
Cold start ---------------------------------------------------------------- Parallax P2 .:.:--TAQOZ--:.:. V1.0--142 180530-0135 ---------------------------------------------------------------- TAQOZ# SD? . -1 ok TAQOZ# !SD .L $0000_0000 ok TAQOZ# 0 0 cmd . 1 okIt responds to a CMD0 which says it is a real SD card.Next I force a crc just for this command since it is still in SD mode and check CMD8.
TAQOZ# $87 $34 C! ok TAQOZ# $1AA 8 CMD .W $0005 okI repeatedly test but we need a response of 1 and this old card is not able to accommodate a $1AA capabilities.My next few posts will be testing:
1) Pull-up only
2) Good card - non-FAT32
3) Good card - FAT32 with a long (but not too long) directory but no boot file (longest timeout)
The case of a pull-up on SD CS but no SD isn't too bad. Most of the time seems to be taken up with the slow clocking before checking which I am fairly sure is not required of SDHC cards. However, it is only 2ms.
Confirming the pullup where SD? tests for a pullup and returns true/false where -1 is true. Then CMD0 with data of 0 (0 0 CMD) returns with 0 which could even be $FF if it were pulled up on the DO line but we are looking for a $01.
TAQOZ# SD? . -1 ok TAQOZ# 0 0 CMD . 0 okConfirming that slow clocking is NOT required I insert a card, check it for pull-up, and issue a raw CMD0 without anything else.
TAQOZ# SD? . -1 ok TAQOZ# 0 0 CMD . 63 ok TAQOZ# 0 0 CMD . 193 ok TAQOZ# 0 0 CMD . 1 okThe card responded after the 3rd try which is well within what we expect and allow for. Timing this without clocking:TAQOZ# BEGIN SD? UNTIL 5 ms LAP BEGIN 0 0 CMD 1 = UNTIL LAP .LAP 8475 cycles = 105.937us okType a ^X to repeat the last line executed returns the exact same result:
TAQOZ# 8475 cycles = 105.937us okSo we could know within around 100us or so that it is a real SD card.
is there any down side to having a longer timeout ?
Or you could simply continually repeat send of the Autobaud + query, checking for a reply - that auto-adjusts to any variable path delays.
You could allow the user to stop after some seconds, or just have some umbrella timeout
Now here's another boot fail case I added, one where we insert a brand new FAT32 card that is blank. The SD booter still goes through the motions looking for a raw file before checking the root directory which is blank. Total time spent here is 193ms.
Confirming it is blank and nothing, not even deleted entries in the root directory:
TAQOZ# SD? ok TAQOZ# DIR .SDSL08G 3230_3631 NO NAME 32k 7,576M .SDSL08G 3230_3631 NO NAME 32k 7,576M ok TAQOZ# @ROOT FOPEN 0 $80 SD DUMP 00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' okI tried formatting an SD card to NTFS just to give the SD booter something tough to chew on. It seems NTFS is just unpleasant with a timeout of 320ms.
TAQOZ# SD? . -1 ok TAQOZ# !sd .L $C0FF_8000 ok TAQOZ# MOUNT ...NCard 0000_0100 Y u q 4k 0M ok TAQOZ# DIR ...NCard 0000_0100 Y u q 4k 0M ok TAQOZ#I noticed that this old 4G card had been formatted in a PC incorrectly. Always use a proper SD Formatter utility.
Nonetheless, after searching the root directory it timed out after 244ms.
TAQOZ# SD? . -1 ok TAQOZ# !SD .L $C0FF_8000 ok TAQOZ# MOUNT .SM00000 F184_E94B WIDGET 4k 3,758M ok TAQOZ# DIR .SM00000 F184_E94B WIDGET 4k 3,758M WIDGET $0000_42AC 2015.02.21.14.52 0 HOME .HTM $0000_42C4 2015.02.17.15.19 68,037 P8CPU .JPG $0000_434C 2015.02.17.15.18 67,271 IOTPINS .JPG $0000_43D4 2015.02.17.15.15 40,010 LOVE .WAV $0000_4424 2015.02.16.18.06 14,630,692 MENU .TXT $0007_3E8C 2014.01.20.22.59 1,556 EXTEND .FTH $0000_B3EC 2015.02.16.15.31 99,338 P8 .H $0000_B4B4 2015.02.13.23.44 1,401 EASYNET .FTH $0000_B4BC 2015.02.13.15.19 37,673 W5500 .FTH $0000_B50C 2015.02.13.01.50 14,872 EASYFILE.FTH $0000_B52C 2015.02.12.18.48 45,794 SDCARD .FTH $0000_B58C 2015.02.12.18.22 16,343 IOT5500H.JPG $0000_B5AC 2014.11.20.14.07 28,237 DRAGON .JPG $0000_B5E4 2014.11.20.10.31 376,830 AI o T 5. 5 $0250_42AC 1980.02.07.00.02 4,294,901,760 IOT5500 .JPG $0000_B8C4 2014.11.18.21.25 83,571 128K .BIN $0000_B96C 2014.11.06.16.49 131,072 256K .BIN $0000_BA6C 2014.10.28.07.59 262,144 W5200 .FTH $0000_BC6C 2014.09.28.23.19 19,889 SYSTEM .ROM $0000_BC94 2015.02.25.15.05 65,536 WELCOME .TEL $0000_BD14 2014.06.19.18.36 212 WELCOME .FTP $0000_BD1C 2014.06.19.18.34 140 DEBUG .ROM $0000_BD24 2014.06.19.18.31 65,536 POPCORN .WAV $0000_BDA4 2014.06.17.16.15 117,804 P8X32A .PDF $0000_BE8C 2014.06.17.15.07 1,442,886 IMAGE3 $0000_C994 2014.06.15.23.54 80,286 FRED .PNG $0000_CA34 2014.06.15.15.44 7,935 FSRSCH .PNG $0000_CA44 2014.06.15.15.44 99,235 FSRPCB .PNG $0000_CB0C 2014.06.15.15.44 64,764 IMAGE $0000_CB8C 2014.06.15.15.44 16,204 HTTP404 .HTM $0000_CBAC 2014.06.15.15.44 564 IMAGE2 $0000_CBB4 2014.06.15.15.44 51,347 IMAGE1 $0000_CC1C 2014.06.15.15.44 12,500 LOGON .HTM $0000_CC3C 2014.06.15.15.44 388 TACHYON .HTM $0000_CC44 2014.06.15.15.43 159,937 SITE0004.LOG $0000_CD84 2014.02.24.14.31 1,048,576 SITE0003.LOG $0000_D584 2014.02.24.14.31 1,048,576 SITE0002.LOG $0000_DD84 2014.02.24.14.31 1,048,576 SITE0001.LOG $0000_E584 2014.02.24.14.31 1,048,576 FAVICON .ICO $0000_ED84 2013.12.17.09.57 8,069 SYSLOG .TXT $0000_ED94 2013.12.03.01.56 1,048,576 HCB4208 .JPG $0000_F594 2013.06.20.20.45 340,668 CHARLCD .JPG $0000_F834 2013.03.25.11.30 45,446 ECOLCD .PDF $0000_F894 2012.05.24.21.20 342,919 LOVE .MP3 $0000_FB34 2012.02.13.00.26 3,981,374 FIRMWARE.ROM $0001_199C 2015.02.25.16.32 65,536 EASYNET .AVI $0001_1A1C 2015.02.25.17.04 8,651,838 EASYNET2.OGV $0005_29C4 2015.02.23.12.48 69,830,407 Bm - 2 R. P $0000_42AC 2107.15.31.31.63 4,294,967,295 . g o u. t $0398_42AC 1980.03.18.00.03 6,357,093 GOUTPU~1 $0000_42AC 2015.02.26.14.59 0 EASYNET3.AVI $0004_666C 2015.02.25.15.10 25,601,912 ENU2 .TXT $0007_3E8C 2015.02.26.15.17 1,556 MENU1 .TXT $0000_B3C4 2015.02.26.10.57 19,948 TAQOZ# @BOOT FOPEN 0 $100 SD DUMP 00000: EB 58 90 6D 6B 66 73 2E 66 61 74 00 02 08 20 00 '.X.mkfs.fat... .' 00010: 02 00 00 00 00 F8 00 00 10 00 04 00 00 08 00 00 '................' 00020: 00 70 75 00 4E 1D 00 00 00 00 00 00 02 00 00 00 '.pu.N...........' 00030: 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 00040: 80 01 29 4B E9 84 F1 57 49 44 47 45 54 20 20 20 '..)K...WIDGET ' 00050: 20 20 46 41 54 33 32 20 20 20 0E 1F BE 77 7C AC ' FAT32 ...w|.' 00060: 22 C0 74 0B 56 B4 0E BB 07 00 CD 10 5E EB F0 32 '".t.V.......^..2' 00070: E4 CD 16 CD 19 EB FE 54 68 69 73 20 69 73 20 6E '.......This is n' 00080: 6F 74 20 61 20 62 6F 6F 74 61 62 6C 65 20 64 69 'ot a bootable di' 00090: 73 6B 2E 20 20 50 6C 65 61 73 65 20 69 6E 73 65 'sk. Please inse' 000A0: 72 74 20 61 20 62 6F 6F 74 61 62 6C 65 20 66 6C 'rt a bootable fl' 000B0: 6F 70 70 79 20 61 6E 64 0D 0A 70 72 65 73 73 20 'oppy and..press ' 000C0: 61 6E 79 20 6B 65 79 20 74 6F 20 74 72 79 20 61 'any key to try a' 000D0: 67 61 69 6E 20 2E 2E 2E 20 0D 0A 00 00 00 00 00 'gain ... .......' 000E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' 000F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 '................' okI could do as Jmg suggests and keep sending out connect strings while waiting for a response. This would adapt to fast and slow systems. We could set the try limit at 500ms. It could actually be faster than it is now, in cases where the initially-tried COM port is the correct one. When searching COM ports for a Prop2, it would then have to spend 500ms on each empty port, instead of the current 100ms.
A blind scan is useful for easily setting things up initially, but it's not going to be the default development loop, surely ?
Few would want all serial ports being messed with.
Options are to save the port the P2 was found on, in a file, and start there next time, and to support command line param saying which explicit port to use ?
You could alternatively do 2 scan passes, one more rapid one that expects serial-default, and then a slower one for the fall-back choices ?
Looks good. Thanks, Peter.
I'd like to use this document as a reference but if you also publish this Google doc it will be more readily accessible to those who are just casually perusing the document and if you include a link in your document to this pub doc and vice versa then anyone can click to see the original etc.
"Great! but when?".
Of course, this is just an outline and each cog could show more detail, and there would be hub stuff, cordic, oscillator stuff etc. I'd try to use a common color so that if I showed cog & LUT RAM then I would have little cyan blocks within the cog etc.
Looks good, Peter. Jazz it up if you want and we can put it in there.
Updated!
It is looking kind of like a sunflower.
Along with the CORDIC and PRGN, there is also CT counter and the LOCK flags. That would round it off. There is plenty more but it would just get messy I'd say.