Well, you've definitely got errors:
- The first line "Reset...": The pull-up on P59 locks in Serial boot only. It prevents any attempt to boot from Flash or SD.
- The second line "try FLASH...": Says it'll fall back to SD. But there isn't any combinations in which Flash falls back to SD, or SD falls back to Flash.
So here's my assessment of Cluso's table of what the code does compared to what the Google doc claims (and may have been the intent)
P59 P60 P61 Actions Same as Google Doc
None None None Serial, Stop Yes
None None Up Flash, Serial, Stop No, missing first Serial 100ms block
None Up None SD, Serial, Stop Yes
None Up Up Flash, SD, Serial, Stop Absent
Up None None Serial, Stop Yes
Up None Up Serial, Flash, Stop No, claims Flash ignored
Up Up None Serial, SD, Stop No, claims SD ignored
Up Up Up Serial, Flash, SD, Stop No, claims Flash and SD ignored
Down None None Stop No
Down None Up Flash, Stop Yes
Down Up None SD, Stop Yes
Down Up Up Flash, SD, Stop Absent
Well, you've definitely got errors:
- The first line "Reset...": The pull-up on P59 locks in Serial boot only. It prevents any attempt to boot from Flash or SD.
- The second line "try FLASH...": Says it'll fall back to SD. But there isn't any combinations in which Flash falls back to SD, or SD falls back to Flash.
ok, I think I see an error (need time to check)..
- The first line "Reset..." says: If a pull-up on P59 it will try Serial (ie it waits some time) and if not valid (ie else) it will move to the next line and try FLASH. STOP.
- The second line "try FLASH..." says: If a pull-up on P61 it will try FLASH and if not valid (ie else) it will move to the next line and try SD. The code will try SD at code $fc108-fc110.
- The third line "try SD" says: If a pull-up on P60 it will try SD and if not valid (ie else) it will move to the next line and try Serial. My SD code will return to try serial.
- The fourth line "try Serial" says: If a pull-down on P59 it will STOP (ie it will not boot from Serial) else it will try SERIAL (which may be again).
So here's my assessment of what the code does compared to what the Google doc claims (and may have been the intent)
P59 P60 P61 Actions Same as Google Doc
None None None Serial, Stop Yes
None None Up Flash, Serial, Stop No, missing first Serial 100ms block
None Up None SD, Serial, Stop Yes
None Up Up Flash, SD, Serial, Stop Absent
Up None None Serial, Stop Yes
Up None Up Serial, Flash, Stop No, claims Flash ignored
Up Up None Serial, SD, Stop No, claims SD ignored
Up Up Up Serial, Flash, SD, Stop No, claims Flash and SD ignored
Down None None Stop No
Down None Up Flash, Stop Yes
Down Up None SD, Stop Yes
Down Up Up Flash, SD, Stop Absent
Wow, that's massive. Even if it has a few errors that's still way more than either the others.
None None Up Flash, Serial, Stop No, missing first Serial 100ms block
I can assure you the 100 ms does exist. I worked with Eric to iron out getting loadp2 to make use of it.
The 100 ms only triggers if a valid SPI boot is detected - uses a checksum at end of first 1 kByte I think. If not valid, it'll drop straight to serial after reading that first 1 kByte of the SPI device.
Up None Up Serial, Flash, Stop No, claims Flash ignored
Reading the source code, I can't see that sequence coming true either. The P59 pull-up means the SPI device is never checked. The test for P59 is first and serial is jumped to immediately. So the spi_ok flag won't get set, therefore the serial timeout will stop the cog.
EDIT: Same goes for the other two extra cases of P59 pull-up
Up Up None Serial, SD, Stop No, claims SD ignored
Up Up Up Serial, Flash, SD, Stop No, claims Flash and SD ignored
P59 pull-up check is first and the serial code doesn't recheck any pull-up/down states, so will always simply stop after the 60 second timeout.
Up None Up Serial, Flash, Stop No, claims Flash ignored
Reading the source code, I can't see that sequence coming true either. The P59 pull-up means the SPI device is never checked. The test for P59 is first and serial is jumped to immediately. So the spi_ok flag won't get set, therefore the serial timeout will stop the cog.
EDIT: Same goes for the other two extra cases of P59 pull-up
Up Up None Serial, SD, Stop No, claims SD ignored
Up Up Up Serial, Flash, SD, Stop No, claims Flash and SD ignored
P59 pull-up check is first and the serial code doesn't recheck any pull-up/down states, so will always simply stop after the 60 second timeout.
EDIT2: Removed a duplicate line.
Yes, I hadn't read the source but was going by Cluso's analysis of the code. I've updated the language in my post to make that clearer.
Oh, I thought you'd previously done your own testing and that's what you'd found. I can't make sense of what Cluso has written.
I've found Chip's documentation to be pretty bullet proof in general. Many times I've thought I found something wrong only to find I hadn't tested the cases correctly or I've just not understood. The smartpins were a good example, the terminology is consistent and precise but it took a lot of experimenting for me to grok the importance.
@MSwann Welcome to the forums.
This thread is for discussion of Tricks and Traps.
Please start a new thread with the appropriate title and you'll get a lot more help there.
I was replying to JonnyMac's post.
Anyway, seems unfortunate that the waitms/waitus stuff didn't use the full 64bit counter, instead of just the lower 32bits.
Anyway, seems unfortunate that the waitms/waitus stuff didn't use the full 64bit counter, instead of just the lower 32bits.
My guess is those functions are using the event hardware in the cog. Not sure how allocation is managed. Anyway, the event hardware also only has a 32-bit compare register. It never got upgraded to match the system timer.
My guess is those functions are using the event hardware in the cog. Not sure how allocation is managed. Anyway, the event hardware also only has a 32-bit compare register. It never got upgraded to match the system timer.
Here's the code from the latest interpreter that handles waitms() and waitus()
waitus_ getct w 'get ct now to minimize error
rdlong y,#@clkfreq_hub 'get clock frequency
qmul y,x 'multiply clock frequency by us/ms
getqx x
getqy y
cmp pa,#bc_waitus wz 'us or ms time unit?
mov z,##1000
if_z mul z,z
setq y 'divide by time unit
qdiv x,z
getqx x
add x,w 'add ct
jmp #pwct 'do WAITCT
pwct getct w 'a b a: POLLCT(tick)
cmpm w,x wc 'a b b: WAITCT(tick)
if_c jmp #pwct '| b
_ret_ popa x '| b
_ret_ muxnc x,_FFFFFFFF 'a
On the other hand, it might just be a signed 32-bit operation in the routine. And not using any hardware beyond the GETCT instruction. Then it'll just be a case of extending the routine to 64-bit operation.
I think Chip said he was dead out of space for the interpreter; I wonder if that drove the decision to limit the timing to 32 bits.
With more code, it could be achieved. There are 15 identical instructions in the BYTEFILL/WORDFILL/LONGFILL routine that would sure be nice to condense, somehow. Then, we'd have some pennies left over for a 64-bit WAITMS/WAITUS.
The "Mask" location is a list of longs, but the original P1 code has a shell & "less than" sign before each number.
Mask long |<0,|<1,|<2,|<3,|<4,|<5,|<6,|<7
long |<8,|<9,|<10,|<11,|<12,|<13
long |<14,|<15,|<16,|<17,|<18,|<19
long |<20,|<21,|<22,|<23,|<24,|<25
long |<26,|<27,|<28,|<29,|<30,|<31
It will not compile on the P2 unless I remove the shell & less-than sign.
What does that syntax actually mean?
And what should I change to make it work similar on the P2?
My conversion is still not working.
The only other questionable conversion I made was to 4 XOR calls.
The P2 compiler expected an End-of-Line after the 1st variable (wz), so I took off the 2nd variable (nr).
There is no “nr” in the P2.
So in your example, temp will be updated. You have to fix any code using NR in P1 code when converting to P2.
This is where I am hitting a wall.
I am having trouble interpreting the assembly code past this point.
There is 6 XOR calls that have this problem, not 4.
I don't know where to go from here.
Update:
nr seems to be a flag that keeps temp from being overwritten on the P1.
There is no “nr” in the P2.
So in your example, temp will be updated. You have to fix any code using NR in P1 code when converting to P2.
This is where I am hitting a wall.
I am having trouble interpreting the assembly code past this point.
There is 6 XOR calls that have this problem, not 4.
I don't know where to go from here.
Update:
nr seems to be a flag that keeps temp from being overwritten on the P1.
Yes. So you need to create another temporary register and use 2 instructions to cater for the nr, unless you are certain the overwriting doesn’t matter
So
Instr dest,src nr
Becomes
Mov temp,dest
Instr temp,src
Comments
Basically they are the same. My table tries to show how the ROM code works in sequence down the page. The net results are the same.
- The first line "Reset...": The pull-up on P59 locks in Serial boot only. It prevents any attempt to boot from Flash or SD.
- The second line "try FLASH...": Says it'll fall back to SD. But there isn't any combinations in which Flash falls back to SD, or SD falls back to Flash.
Postedit: Fixed language above.
Postedit - except I read it wrong
..... ' If pull-up on spi_di then try serial ' fc06c 01b fb4c76ed callpa #spi_di,#check_pullup fc070 01c cd9007cc if_c jmp #reset_serial ' ' ' If pull-up on spi_cs then try to load from SPI memory ' fc074 01d fb4c7aeb callpa #spi_cs,#check_pullup fc078 01e cd90000c if_c jmp #try_spi ' ' ' If pull-up on spi_ck (also sd_cs) then try to load from SD card ' fc07c 01f fb4c78e9 callpa #spi_ck,#check_pullup fc080 020 cd8fc560 if_c jmp #@_start_sdcard ' ' ' If no pull-down on spi_di then try serial ' fc084 021 fd900378 jmp #try_serial ' ' ' Try to load from SPI memory ' fc088 022 fd647a59 try_spi drvh #spi_cs 'drive spi_cs high fc08c 023 fd647858 drvl #spi_ck 'drive spi_ck low ..... fc100 040 .sum fc100 040 f20acb52 cmp y,csum wz 'verify checksum, z=1 if okay fc104 041 f4868e00 bitz flags,#spi_ok 'if program verified, set spi_ok flag fc108 042 .fail ' ' ' If SPI failed, check for pull-up on spi_ck (also sd_cs) ' fc108 042 5b4c78c6 if_nz callpa #spi_ck,#check_pullup 'if no SPI program, check for pull-up on spi_ck (also sd_cs) fc10c 043 4d8fc560 if_nz_and_c jmp #@_start_sdcard 'if no SPI program and pull-up on spi_ck, try to load from SD card fc110 044 fd9002ec jmp #try_serial 'try serial ..... ' Try serial if no pull-down on spi_di ' else, run SPI program if valid or float SPI pins and shut down ' fc12c 100 f40e8e00 try_serial testb flags,#spi_ok wz 'SPI program? fc130 101 5d647a50 if_nz fltl #spi_cs 'if no SPI program, float SPI pins fc134 102 5d647850 if_nz fltl #spi_ck fc138 103 ad65fe28 if_z setq #$FF 'if SPI program, move it into cog $000..$0FF fc13c 104 ab040000 if_z rdlong 0,#0 fc140 105 fd647659 drvh #spi_di 'check pull-down on spi_di, leave floating fc144 106 fb4c7603 callpa #spi_di,#check_pulldn 'c=0 if pull-down fc148 107 3d900664 if_nc jmp #serial_done 'if pull-down on spi_di, boot if SPI okay (z=1) or shut down fc14c 108 fd90041c jmp #reset_serial 'else try serial ' ' ' Check pin pull-up ' fc150 109 fd63ec58 check_pullup drvl pa 'drive pin low fc154 10a fd643c1f check_pulldn waitx #30*1 'wait >1us fc158 10b fd63ec50 fltl pa 'float pin fc15c 10c fd652c1f waitx #30*5 'wait >5us fc160 10d 0d73ec40 _ret_ testp pa wc 'sample pin ..... ' Reset serial autobaud/receiver interrupt ' fc2b8 210 f527f403 reset_serial andn dira,#%11 'disable timing measurements for autobaud fc2bc 211 fd640025 setint1 #0 'disable int1 ..... ' Attempt to get serial command ' fc2f8 220 fd62c81a get_command getct x 'reset serial timeout in case SPI program ready fc2fc 221 fa62c941 addct1 x,timeout_per fc300 222 f606cc00 mov z,#0 'reset string buffer fc304 223 fdb001d4 .byte call #get_rx 'get byte fc308 224 f20ec81b cmp x,#$1B wz 'esc? fc30c 225 ad8fd028 if_z jmp #@_start_taqoz fc310 226 f20ec804 cmp x,#$04 wz 'ctrl-d? fc314 227 ad8fca88 if_z jmp #@_start_monitor fc318 228 f91acb66 rolbyte y,z,#3 'scroll byte into 2-long/8-byte string buffer fc31c 229 f902cd64 rolbyte z,x,#0 fc320 22a f20acb48 cmp y,text_prop wz '"Prop"? fc324 22b 5d9fffdc if_nz jmp #.byte fc328 22c f20acd4c cmp z,text_txt wz '"_Txt"? fc32c 22d ad90005c if_z jmp #command_txt fc330 22e f20acd4b cmp z,text_hex wz '"_Hex"? fc334 22f ad9000b0 if_z jmp #command_hex fc338 230 f20acd4a cmp z,text_clk wz '"_Clk"? fc33c 231 ad900018 if_z jmp #command_clk fc340 232 f20acd49 cmp z,text_chk wz '"_Chk"? fc344 233 5d9fffbc if_nz jmp #.byte ..... ' Serial done ' on entry, z=1 if SPI program ' fc4fc 2a1 fdb00044 serial_done call #reset_pins 'reset pins fc500 2a2 ad9ff574 if_z jmp #0 'if SPI program, run it, else shut down fc504 2a3 fd62c801 shut_down cogid x 'get cogid (in case jumped to from outside) fc508 2a4 fd640200 hubset #1 'set 20KHz oscillator fc50c 2a5 fd62c803 cogstop x 'shut down cog (floats pins) ..... fc560 f6079a00 _Start_SDcard mov skiprun, #0 ' load/run MBR/VOL code \ --tweek2-- fc564 fdb00050 call #@_SDcard_Init0 ' Init/CSD/CID/MBR/VOL/FSI/FAT (skiprun=0) | --tweek2-- fc568 adb00290 if_e call #@_readDIR ' read directory for filenames '' mov skiprun, #0 ' load/run <file> (already 0) fc56c adb00378 if_e call #@_readFILE ' read/load/run the file fc570 fdb004ec call #@_releaseDO ' /CS=1, send CLKs, tristate CS/CK/DI/DO | --tweek2-- fc574 fd800100 JMP #try_serial ' failed: so go back and try serial- The first line "Reset..." says: If a pull-up on P59 it will try Serial (ie it waits some time) and if not valid (ie else) it will move to the next line and try FLASH. STOP.
- The second line "try FLASH..." says: If a pull-up on P61 it will try FLASH and if not valid (ie else) it will move to the next line and try SD. The code will try SD at code $fc108-fc110.
- The third line "try SD" says: If a pull-up on P60 it will try SD and if not valid (ie else) it will move to the next line and try Serial. My SD code will return to try serial.
- The fourth line "try Serial" says: If a pull-down on P59 it will STOP (ie it will not boot from Serial) else it will try SERIAL (which may be again).
I can assure you the 100 ms does exist. I worked with Eric to iron out getting loadp2 to make use of it.
EDIT: Same goes for the other two extra cases of P59 pull-up P59 pull-up check is first and the serial code doesn't recheck any pull-up/down states, so will always simply stop after the 60 second timeout.
EDIT2: Removed a duplicate line.
Yes, I hadn't read the source but was going by Cluso's analysis of the code. I've updated the language in my post to make that clearer.
Sorry, for adding to the confusion.
I've found Chip's documentation to be pretty bullet proof in general. Many times I've thought I found something wrong only to find I hadn't tested the cases correctly or I've just not understood. The smartpins were a good example, the terminology is consistent and precise but it took a lot of experimenting for me to grok the importance.
Instead of using the cordic solver, how would one use the MUL instruction to do a 32-bit multiply ?
So are you avoiding the CORDIC solver because you want signed 32 bit MUL, or in order to get the work done faster?
This thread is for discussion of Tricks and Traps.
Please start a new thread with the appropriate title and you'll get a lot more help there.
Post such questions here.
To answer the question, the hardware for system timer events fires on msbit rather than rollover. So range is 2^31.
Anyway, seems unfortunate that the waitms/waitus stuff didn't use the full 64bit counter, instead of just the lower 32bits.
When I've made the mistake of replying there in the past I've then asked admin to remove my posts.
With more code, it could be achieved. There are 15 identical instructions in the BYTEFILL/WORDFILL/LONGFILL routine that would sure be nice to condense, somehow. Then, we'd have some pennies left over for a 64-bit WAITMS/WAITUS.
Oh oh, I replied in that post. Please remove it.
The following code makes a reference call to a location called "Mask".
There are 32 of these calls (1 for each pin).
Main_PWM_Loop '------------------------------------------------------------- sub t1 + 00, #1 wc Ch01 if_c xor Ch + 00, Mask + 00 wz if_c_and_z mov t1 + 00, T_Off_Ch + 00 if_c_and_nz mov t1 + 00, T_On__Ch + 00The "Mask" location is a list of longs, but the original P1 code has a shell & "less than" sign before each number.
Mask long |<0,|<1,|<2,|<3,|<4,|<5,|<6,|<7 long |<8,|<9,|<10,|<11,|<12,|<13 long |<14,|<15,|<16,|<17,|<18,|<19 long |<20,|<21,|<22,|<23,|<24,|<25 long |<26,|<27,|<28,|<29,|<30,|<31It will not compile on the P2 unless I remove the shell & less-than sign.
What does that syntax actually mean?
And what should I change to make it work similar on the P2?
It's been replaced with DECOD:
The only other questionable conversion I made was to 4 XOR calls.
The P2 compiler expected an End-of-Line after the 1st variable (wz), so I took off the 2nd variable (nr).
Is this the correct way to handle that?
'xor temp, #UpdateTonToff wz,nr ' Check Ton/Toff} {Replaced with} xor temp, #UpdateTonToff wz ' Check Ton/Toff if_z jmp #_Update_TonToffSo in your example, temp will be updated. You have to fix any code using NR in P1 code when converting to P2.
This is where I am hitting a wall.
I am having trouble interpreting the assembly code past this point.
There is 6 XOR calls that have this problem, not 4.
I don't know where to go from here.
Update:
nr seems to be a flag that keeps temp from being overwritten on the P1.
So
Instr dest,src nr
Becomes
Mov temp,dest
Instr temp,src