Unfortunately, the SD boot is not that fast because it is meant to be callable and so runs in hubexec mode which slows things down because of a tight loop. If it is called at full clock speed it won't be so bad but the booter however could load a 2nd stage minimal SD booter which could operate from cog at 2.5MHz SPI speeds even at 20MHz clock rate but of course could switch to a 200MHz clock and run at 25MHz SPI speeds. So that would make 2 stage SD booting very fast. This is also how Chip has the SPI Flash working, as it is meant to load in a 2nd stage that can then ramp up the clock etc.
TAQOZ itself runs separate SPI read/write routines in cog so even at 20MHz the SPI speeds are 2.5Mhz.
BTW, the 2nd stage loader is probably the way most code will end up loading as we explore the P2 and find better ways of doing things. If we could use the smartpins for SPI bus I think we can access SD at 50MHz SPI speeds as the old standard back in 2003 specified 25MHz max but IIRC this was upgraded to 50MHz.
"how ingrained our thinking becomes because that is how we are so used to writing programs"
That gives hope. Our thinking is not ingrained, it becomes ingrained. And that can be changed. We have to adapt our successful thinking to programming. First look into your purse: 300$, then spend the money. Not spend (300), then realize, nothing to spend!
The world mist the train when HP overprized the HP35 and TI introduced the cheap "scientific calculators for pupils".
The advantage now is: tachyon in frozen in silicon and there will always be a fallback when progress comes to fast to keep track ;-)
Thanks to all for the great work!
Now that Chip has P2 silicon working I will try to keep anything to do with TAQOZ in this thread and so I'm reposting this about selecting 180MHZ for testing although I will have to add in a line to change the console baud rate as well.
So to select 180MHZ from TAQOZ would be:
Now that Chip has P2 silicon working I will try to keep anything to do with TAQOZ in this thread and so I'm reposting this about selecting 180MHZ for testing although I will have to add in a line to change the console baud rate as well.
When I get a chip next week I will go through the clock and analog modes as well.
Some forth code to generate Analog ramps/triangles/sines would be nice to see
Now that Chip has P2 silicon working I will try to keep anything to do with TAQOZ in this thread and so I'm reposting this about selecting 180MHZ for testing although I will have to add in a line to change the console baud rate as well.
When I get a chip next week I will go through the clock and analog modes as well.
Some forth code to generate Analog ramps/triangles/sines would be nice to see
Yes, I'm really interested in the analog part so I will be posting scope shots as well as code and observations.
This is how we ramp PWM from 0 to 100% continually until a key is pressed.
BEGIN 2 PIN 1000 0 DO I 1000 1 PWM 100 us LOOP KEY UNTIL
One liners are handy but extending TAQOZ with your own words is easy too. Here I set pin 2 as a 20M baud UART transmit line, create a transmit string word so that I can pass the string and the pin number to it, and of course I test it.
TAQOZ# : TRANSMIT$ ( string pin -- ) PIN DUP LEN$ TXDAT ; ok
TAQOZ# 2 PIN 20 M TXD ok
TAQOZ# " HELLO WORLD" 2 TRANSMIT$ ok
Yes, I'm really interested in the analog part so I will be posting scope shots as well as code and observations.
This is how we ramp PWM from 0 to 100% continually until a key is pressed.
BEGIN 2 PIN 1000 0 DO I 1000 1 PWM 100 us LOOP KEY UNTIL
Send a dictionary over to augment TAQOS, or a full featured Tachyon.
I wouldn't think this would be the best way to get BlocklyProp working with the P2. Wouldn't it be better to use p2gcc since BlocklyProp is already setup to generate C code?
David, I agree. The question was about Blockly and the built in Forth.
If one were to go that route, initializing things would likely mean a dictionary, or Tachyon be sent over.
The basic point being Forth can take a plaintext load and will operate on that to dial in features needed.
Yeah but if you send a full Tachyon over then it's no different than sending a compiled C program. I agree that it would be cool if you could just use Taqos directly. I don't see any reason BlocklyProp couldn't be made to generate code for it but it would not achieve one of Parallax's goals which is to let people write in BlocklyProp and then see the generated C code as a way to learn C.
Hopefully I can get around to testing the analog and various smartpin modes today. In the meantime here's a fibo benchmark that's run at 280MHz just for the test and then I drop back to 180MHz.
TAQOZ# 280 M CLOCK ok
TAQOZ# 1 46 ADO CRLF ." fibo(" I . ." ) = " LAP I fibo LAP .LAP ." result =" . 5 +LOOP
fibo(1) = 458 cycles = 1,635ns @280MHz result =1
fibo(6) = 778 cycles = 2,778ns @280MHz result =8
fibo(11) = 1,098 cycles = 3,921ns @280MHz result =89
fibo(16) = 1,418 cycles = 5,064ns @280MHz result =987
fibo(21) = 1,738 cycles = 6,207ns @280MHz result =10946
fibo(26) = 2,058 cycles = 7,350ns @280MHz result =121393
fibo(31) = 2,378 cycles = 8,492ns @280MHz result =1346269
fibo(36) = 2,698 cycles = 9,635ns @280MHz result =14930352
fibo(41) = 3,018 cycles = 10,778ns @280MHz result =165580141
fibo(46) = 3,338 cycles = 11,921ns @280MHz result =1836311903 ok
TAQOZ# 180 M CLOCK ok
Copy and paste this text into TAQOZ to change the clock rate seamlessly. The console baud rate is automatically adjusted as well.
You can access the individual clock hubset fields or just pass a frequency value to CLOCK like this:
250 M CLOCK
BTW - I standardized on 2M baud at boot but just change if your terminal is not up to it.
long _baud 2 M _baud !
TAQOZ
( CLOCK MODES )
--- 1098_7654_321098_7654321098_7654_32_10
--- 0000_000E_DDDDDD_MMMMMMMMMM_PPPP_CC_SS
long _clk _clk ~
long _fin
--- set the
: CLKSET _clk @ HUBSET ;
( PLL should run between 100 to 200MHz )
: CLK! ( data mask -- ) _clk @ SWAP ANDN OR _clk ! ;
: PLLEN 24 |< _clk SET ;
: PLLOFF 24 |< _clk CLR ;
: XIDIV ( 1..64 -- ) 1- $1F AND 18 << $00FC0000 CLK! ;
( ends up as multiply)
: VCOMUL ( 1..1024 -- ) 1- $3FF AND 8 << $3FF00 CLK! ;
--- Divide the PLL by 1 2 4 6 ... 30 for the system clock when SS = %11
: PLLDIV ( 2..30 -- ) 2/ 1- $0F AND 4 << $0F0 CLK! ;
: CLKSRC CLKSET DUP 1 > IF 200,000 WAITX THEN 3 AND 3 CLK! CLKSET ;
: USEPLL 3 CLKSRC ;
: USEXTAL 2 CLKSRC ;
: RCSLOW 1 HUBSET _clk ~ ;
: RCFAST 0 HUBSET _clk ~ ;
: CC 3 AND 2 << $0C CLK! ;
: 15PF 2 CC ;
: 30PF 3 CC ;
: 0PF 1 CC ;
: XPF 0 CC ;
long _baud 2 M _baud !
: CONBAUD DUP _baud ! 63 PIN DUP RXD 62 PIN TXD ;
--- Set P2 CLOCK to selected MHZ ( simple PLL settings only )
: CLOCK ( HZ --- )
' CLKHZ 2+ !
30PF PLLEN 12 XIDIV CLKHZ 1000000 U/ VCOMUL 1 PLLDIV USEPLL
_baud @ CONBAUD
;
END
I converted my version of Conway's Game of Life across to TAQOZ and while I haven't yet optimized it I thought you might be interested to see it running at 340MHz while connected to the terminal at 3M baud. Forgive me for the glitchy desktop recording.
BTW - I've found that the P2 autobauds to 3M baud reliably so I am using this as my default now. Dropbox link:
Peter, have you got the ability to boot a short flash program, deterministically, which just does a GETRND and throws it on some pins? We need to make sure it comes up differently after each reset, so we know the seeding is working in the ROM.
Comments
Great
Is there a table yet, of the various boot-paths and boot times for each ?
There were comments about making boot faster ?
TAQOZ itself runs separate SPI read/write routines in cog so even at 20MHz the SPI speeds are 2.5Mhz.
BTW, the 2nd stage loader is probably the way most code will end up loading as we explore the P2 and find better ways of doing things. If we could use the smartpins for SPI bus I think we can access SD at 50MHz SPI speeds as the old standard back in 2003 specified 25MHz max but IIRC this was upgraded to 50MHz.
That gives hope. Our thinking is not ingrained, it becomes ingrained. And that can be changed. We have to adapt our successful thinking to programming. First look into your purse: 300$, then spend the money. Not spend (300), then realize, nothing to spend!
The world mist the train when HP overprized the HP35 and TI introduced the cheap "scientific calculators for pupils".
The advantage now is: tachyon in frozen in silicon and there will always be a fallback when progress comes to fast to keep track ;-)
Thanks to all for the great work!
So to select 180MHZ from TAQOZ would be:
and making a new word so we can switch it easily (but lose console baud rate):
Type WORDS or hit ^W to list the dictionary where you will find words such as RCSLOW etc.
---------------------------------------------------------------- Parallax P2 .:.:--TAQOZ--:.:. V1.0--142 180530-0135 ---------------------------------------------------------------- TAQOZ# WORDS DUP OVER SWAP ROT -ROT DROP 3RD 4TH 2DROP 3DROP NIP 2SWAP 2DUP ?DUP AND ANDN OR XOR ROL ROR >> << SAR 2/ 2* 4/ 4* 8<< 16>> 8>> 9<< 9>> REV |< >| >N >B >9 BITS NOT = <> 0= 0<> 0< < U< > U> <= => WITHIN DUPC@ C@ W@ @ C+! C! C@++ W+! W! +! ! BIT! SET CLR SET? 1+ 1- 2+ 2- 4+ + - UM* * W* / U/ U// // */ UM// C++ C-- W++ W-- ++ -- RND GETRND SQRT SETDACS ~ ~~ W~ W~~ C~ C~~ L>S >W L>W W>B W>L B>W B>L MINS MAXS MIN MAX ABS -NEGATE ?NEGATE NEGATE ON TRUE -1 FALSE OFF GOTO IF ELSE THEN BEGIN UNTIL AGAIN WHILE REPEAT SWITCH CASE@ CASE= CASE> BREAK CASE ADO DO LOOP +LOOP FOR NEXT ?NEXT I J LEAVE IC@ I+ BOUNDS H L T F R HIGH LOW FLOAT PIN@ WRPIN WXPIN WYPIN RDPIN RQPIN AKPIN WAITPIN WRACK PIN @PIN ns PW PULSE PULSES HILO DUTY NCO HZ KHZ MHZ MUTE BLINK PWM SAW BIT BAUD TXD RXD TXDAT WAITX WAITCNT REBOOT RESET 0EXIT EXIT NOP CALL JUMP >R R> >L L> !SP DEPTH COG@ COG! LUT@ LUT! COGID COGINIT COGSTOP NEWCOG COGATN POLLATN SETEDG POLLEDG KEY WKEY KEY! CON NONE COM CONKEY CONEMIT SEROUT EMIT EMITS CRLF CR CLS SPACE SPACES RAM DUMP: DUMP DUMPW DUMPL DUMPA DUMPAW QD QW DEBUG lsio COG LUT KB MB M . PRINT .AS .AS" .DECL .DEC4 HOLD #> <# # #S <D> U. .DEC .BIN .H .B .BYTE .W .WORD .L .LONG .ADDR PRINT$ LEN$ " ." CTYPE ?EXIT DATA? ERASE FILL CMOVE <CMOVE s ms us CNT@ LAP LAP@ .LAP .ms HEX DEC BIN .S WORDS @WORDS GET$ SEARCH $># @DATA HERE @HERE @CODES uemit ukey char delim names TASK REG @WORD SPIN | || , [W] ["] NULL$ $! $= ASM FORGET CREATE$ CREATE VAR pub pri pre : ; [ ] ' := ==! ALIGN DATCON ALLOT org bytes words longs byte word long res [C] GRAB NFA' CPA CFA \ --- ( { } IFNDEF IFDEF TAQOZ TERM AUTO SPIRD SPIRDL SPIWB SPICE SPIWC SPIWW SPIWM SPIWL SPIPINS SPIRX SPITXE SPITX WSLED WAIT CLKDIV RCSLOW HUBSET WP WE CLKHZ ERROR SFPINS SF? SFWE SFINS SFWD SFSID SFJID SFER4 SFER32 SFER64 SFERASE SFWRPG BACKUP RESTORE SFRDS SFWRS SFC@ SFW@ SF@ SF .SF SDBUF sdpins MOUNT DIR !SD !SX SD? CMD ACMD cid SDWR SDRDS SDWRS FLUSH FOPEN FLOAD FGET FREAD FWRITE SECTOR SDRD SDRDS SDADR SD@ SD! SDC@ SDC! SDW@ SD @FAT @BOOT @ROOT fat END 433 okAnother quick demo on P2 of P2 to generate a 10% PWM with a resolution of 1,000 counts with minimum clock division.When I get a chip next week I will go through the clock and analog modes as well.
Some forth code to generate Analog ramps/triangles/sines would be nice to see
Yes, I'm really interested in the analog part so I will be posting scope shots as well as code and observations.
This is how we ramp PWM from 0 to 100% continually until a key is pressed.
(20M was the limit of the scope's decoder)
Those one liners for a novice are a little hard, so I rolled out this line cmapspublic3.ihmc.us/rid=1SX77GSL1-ZZZBPJ-1LND/TAQOZ_One-liner_PWM.cmap to gain a better understanding
Jim
BTW: I wonder if we can combine Blockly with the built in P2 Forth...
Send a dictionary over to augment TAQOS, or a full featured Tachyon.
But, you are right that since we already have BlocklyProp, there maybe wouldn't be much to gain with that approach...
If one were to go that route, initializing things would likely mean a dictionary, or Tachyon be sent over.
The basic point being Forth can take a plaintext load and will operate on that to dial in features needed.
Part of me wonders though. And make no mistake. I am not gonna do this, but:
Making ones own blocks, then assembling would be a Forth kind of thing. I do wonder what people would do with that idea presented visually.
TAQOZ# 280 M CLOCK ok TAQOZ# 1 46 ADO CRLF ." fibo(" I . ." ) = " LAP I fibo LAP .LAP ." result =" . 5 +LOOP fibo(1) = 458 cycles = 1,635ns @280MHz result =1 fibo(6) = 778 cycles = 2,778ns @280MHz result =8 fibo(11) = 1,098 cycles = 3,921ns @280MHz result =89 fibo(16) = 1,418 cycles = 5,064ns @280MHz result =987 fibo(21) = 1,738 cycles = 6,207ns @280MHz result =10946 fibo(26) = 2,058 cycles = 7,350ns @280MHz result =121393 fibo(31) = 2,378 cycles = 8,492ns @280MHz result =1346269 fibo(36) = 2,698 cycles = 9,635ns @280MHz result =14930352 fibo(41) = 3,018 cycles = 10,778ns @280MHz result =165580141 fibo(46) = 3,338 cycles = 11,921ns @280MHz result =1836311903 ok TAQOZ# 180 M CLOCK okYou can access the individual clock hubset fields or just pass a frequency value to CLOCK like this: BTW - I standardized on 2M baud at boot but just change if your terminal is not up to it.
When we type 250 M CLOCK we get action but the current jumps crazy high. We're proceeding with caution.
TAQOZ# 340 M CLOCK ok TAQOZ# 1 46 ADO CRLF ." fibo(" I . ." ) = " LAP I fibo LAP .LAP ." result =" . 5 +LOOP fibo(1) = 480 cycles = 1,411ns @340MHz result =1411 fibo(6) = 800 cycles = 2,352ns @340MHz result =2352 fibo(11) = 1,120 cycles = 3,294ns @340MHz result =3294 fibo(16) = 1,440 cycles = 4,235ns @340MHz result =4235 fibo(21) = 1,760 cycles = 5,176ns @340MHz result =5176 fibo(26) = 2,080 cycles = 6,117ns @340MHz result =6117 fibo(31) = 2,400 cycles = 7,058ns @340MHz result =7058 fibo(36) = 2,720 cycles = 8,000ns @340MHz result =8000 fibo(41) = 3,040 cycles = 8,941ns @340MHz result =8941 fibo(46) = 3,360 cycles = 9,882ns @340MHz result =9882 ok TAQOZ# 100 M CLOCK okLess than 10us for fibo(46) in high level threaded code.Understandable !
What Vcore, Vio and decoupling-cap-count is that 340MHz done with ?
Yes, with 18" grabber cables delivering the powers and ground. It's very sloppy. Just one bypass cap per VDD and VIO, too.
If you are getting 340MHz at 1.8V, going to 2.0V with good heat dissipation could certainly get you higher.
When are the next packaged chips due? About 150 at the end of month???
Don't was to kill any of the current 9 working chips
Are there any big costs to get the remaining ~1500 packaged? And timescale?
BTW - I've found that the P2 autobauds to 3M baud reliably so I am using this as my default now.
Dropbox link: