Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 140 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

1137138140142143160

Comments

  • Cluso99Cluso99 Posts: 18,066
    The final ROM code is almost done.
    TAQOZ is just getting a little smarter.
    Monitor can now locate,load and run files using R<filename><cr> where filename is the usual 8.3 short filenames.
    We can jump backand forth (fourth) between TAQOZ and Monitor.

    SD boots if the card is installed.
    Flash boots if the CS pullup is present.
    Serial boots on a pullup, and will not run with a pulldown.
    Serial/TAQOZ/Monitor have all been tested to run with the FPGA 20MHz clock sending at 3,000,000 baud !!!

    Expecting to see a new BeMicroCV-A9 with the final ROM in a few hours for very brief testing before the ROM is given to OnSemi.
  • Cluso99 wrote: »
    The final ROM code is almost done.
    TAQOZ is just getting a little smarter.
    Monitor can now locate,load and run files using R<filename><cr> where filename is the usual 8.3 short filenames.
    We can jump backand forth (fourth) between TAQOZ and Monitor.

    SD boots if the card is installed.
    Flash boots if the CS pullup is present.
    Serial boots on a pullup, and will not run with a pulldown.
    Serial/TAQOZ/Monitor have all been tested to run with the FPGA 20MHz clock sending at 3,000,000 baud !!!

    Expecting to see a new BeMicroCV-A9 with the final ROM in a few hours for very brief testing before the ROM is given to OnSemi.
    Why not a Prop123-A9 image as well?

  • Cluso99Cluso99 Posts: 18,066
    Other images will come later. Peter and I need to do a final check with the real image in ROM.
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    The transmit delay of 1ms at 20MHz is kind of long, but we don't have the actual baud rate, as it was set and forgotten within the auto-baud routine.

    If you do not want to preserve the baud values, and alternative is to simply remove the tx start delay entirely, as I think that's a legacy from the single-pin boot mode (that is no longer in the ROM I believe) ?
    All MCUs and USB links, have Duplex UARTS so they do not care about relative phase of TX.RX.



    Working with Cluso and Peter, we added a new variable to capture the initial baud rate. I'm now using it (a0) to generate an adaptive delay of 16 bit periods:
    '
    '
    ' Transmit message
    '
    transmit_sta	mov	i,#text_sta		'point to status character
    
    transmit	setd	i,#1			'set auto-increment for altgb
    
    		mov	y,a0			'wait 16 bit periods to allow host turn-around time
    		shr	y,#16-4+2		'shr 16 gets clocks/bit, -4 gets 16 bits, +2 gets 4 clocks/djnz
    		djnz	y,#$			'y=0 after (djnz allows interrupts, unlike waitx)
    
    .byte		altgb	y,i			'get next byte of string, increment y
    		getbyte	z
    
    	_ret_	tjnz	z,#.send		'if zero, done
    
    .send		wypin	z,#tx_pin		'send byte
    
    		waitx	#1			'accommodate wypin -> rdpin latency
    
    .wait		rdpin	z,#tx_pin	wc	'wait for transmit done
    	if_c	jmp	#.wait
    
    		jmp	#.byte			'loop for more bytes
    
  • jmgjmg Posts: 15,140
    edited 2018-05-15 20:54
    cgracey wrote: »
    Working with Cluso and Peter, we added a new variable to capture the initial baud rate. I'm now using it (a0) to generate an adaptive delay of 16 bit periods:
    :)
    Great, in the quest for fastest boot times, and easiest sense of reset exit, every 1000us saved is significant !

    On the topic of fastest possible times, I wondered about a Prop_Pin command that allows a loading MCU to very quickly define the pin states, then it can continue loading.
    It would use the common syntax, but have fields that defined light pullups, or inputs, or a simpler version could just set all pins as light pullups.
    In use, someone would send a repeating `> Prop_chk 0 0 0 0 ` and on response (P2 finally exits reset), send `Prop_Pin 0 0 0 0 etc`


  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    Working with Cluso and Peter, we added a new variable to capture the initial baud rate. I'm now using it (a0) to generate an adaptive delay of 16 bit periods:
    :)
    Great, in the quest for fastest boot times, and easiest sense of reset exit, every 1000us saved is significant !

    On the topic of fastest possible times, I wondered about a Prop_Pin command that allows a loading MCU to very quickly define the pin states, then it can continue loading.
    It would use the common syntax, but have fields that defined light pullups, or inputs, or a simpler version could just set all pins as light pullups.
    In use, someone would send a repeating `> Prop_chk 0 0 0 0 ` and on response (P2 finally exits reset), send `Prop_Pin 0 0 0 0 etc`


    What would be the point in setting pin states up when the downloaded program is about to take over, anyway?
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    What would be the point in setting pin states up when the downloaded program is about to take over, anyway?

    Speed.
    You are trying to minimise & stabalise disturbance in the case of a watchdog reset, and want the least time for pins to float to possibly unsafe states...
    This also avoids growing programs taking longer and longer to finally launch, causing hard to find problems...
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    What would be the point in setting pin states up when the downloaded program is about to take over, anyway?

    Speed.
    You are trying to minimise & stabalise disturbance in the case of a watchdog reset, and want the least time for pins to float to possibly unsafe states...
    This also avoids growing programs taking longer and longer to finally launch, causing hard to find problems...

    It seems that reset-to-serial times are going to be all over the place, considering how things work these days. If there's anything critical, I would think the designer would put a pull-up or pull-down where needed.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    It seems that reset-to-serial times are going to be all over the place, considering how things work these days..

    Not if someone is loading from a local small secure microcontroller, the variance then is all inside the P2.

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-15 23:24
    @jmg - perhaps if you program up a small support chip like that MAX device you could test your theory and let us know how it goes. Are you doing any testing?
  • jmgjmg Posts: 15,140
    @jmg - perhaps if you program up a small support chip like that MAX device you could test your theory and let us know how it goes. Are you doing any testing?
    Physical testing is not possible, with no FPGA board, but I use that more common and proven code test path, of pencil and paper.
    With the boot code somewhat published, there is less `theory` involved, as many delays are already documented.

  • Out of curiosity, has everything been handed over to OnSemi now? Or is the chip being delayed again?
  • jmgjmg Posts: 15,140
    edited 2018-05-16 02:17
    Seairth wrote: »
    Out of curiosity, has everything been handed over to OnSemi now? Or is the chip being delayed again?

    Everything, minus the ROM code. I guess that means the P2 is already all placed and routed ? - and just waiting on the ROM-metal patterns....

    addit: This from another thread ~ 4 hrs ago
    cgracey 10:27AM We had the weekly status meeting with OnSemi a few hours ago. They are wait for us to deliver the ROM. I hope we get it right.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-16 02:28
    See my post here about submitting the ROM code to Chip.
    Chip, Cluso, and I were on another 2 hour skype call last night and they left it with me as I wanted to add some high level SD support into the boot ROM. I didn't have time to transcribe all my code across but I did get the SD part along with the virtual memory layer. If we have SD though then that means we can boot a full-blown version of Tachyon anyway.
  • How are you finding the P1 to P2 code transcribing process, Peter? Fairly easy?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-16 03:26
    Tubular wrote: »
    How are you finding the P1 to P2 code transcribing process, Peter? Fairly easy?

    I'm not actually transcribing P1 code, this is the high level Tachyon P2 code into PNut format mostly as wordcode structures that are "interpreted" by the VM. This means that branches have to be calculated manually or via labels and literals have to be encoded in a suitable format etc

    For instance, this bit of source looks like this:
    pub SECTOR ( sect -- )
    ---	skip it if we already have it
    	DUP @sector @ = IF DROP EXIT THEN
    ---	update sector pointer for this file channel
    	0 FLUSH DUP @sector !
    	SDBUF
    --- SD CARD READ BLOCK - Read sector from SD into dst
    pub SDRD    ( sector dst --  )
    ---	read block command
    	SWAP #17 CMD DUP 0= ( data cmd -- res )
    	IF
    ---	  wait for data - read block else terminate early & return false
    	  DROP SDRES =dtk = IF SDRDBK ELSE SDCLK SDCLK STAT@ 2DROP FALSE THEN
    	THEN
    ---	extra clk and save crc/flg
    	SDCLK DUP _sdrd ! @scrc !
    	SPICE
    	;
    


    and to compile within PNut so that it can be one source file I need to do this:
    '' pub SECTOR ( sect -- )
    SECTOR	word	DUP,_sector,FETCH,_EQ,_IF+02,DROP,EXIT
    	word	_0,FLUSH,DUP,_sector,STORE,SDBUF
    '' pub SDRD    ( sector dst --  )
    SDRD	word	SWAP,w+17,CMD,DUP,_ZEQ,_IF+12
    	word	DROP,SDRES,dtk,_EQ,_IF+02,SDRDBK,sdrd1+ex
    	word	SDCLK2,SDSTAT,DROP2,_0
    sdrd1	word	SDCLK,SPICE,DUP,_sdrd,STORE,seccrc,STORE,EXIT
    
    See what happens, I spotted a bug as that _IF+12 should now be +11 due to a change. I could use labels and mess with them but it is mostly faster to manually count the word displacement.

    The headers are added into the dictionary section like this:
    	byte	6,"SECTOR"
    	word			SECTOR
    	byte	4,"SDRD"
    	word			SDRD
    
  • Well, we have a bit of a wait. Honestly, I was feeling angst over the commit time. It's not like anyone wants it longer, but being able to get it right is worth a lot!

    I personally am quite pleased with how this is all turning out. Staying quiet. Let you guys do this well. important.

    Travel prevents me from testing right at this time. Major bummer!
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-05-16 13:45
    There was a last minute change to the boot sequence. Serial pull-up is checked first, then Flash, and last SD. IF SD exists but is faulty or there is no P2 boot data/file then the code shuts down the prop because it's not possible to jump back to the booter.

    Chip and I played with TAQOZ while on Skype this evening. Was nice to see a set of pins flash with a simple command. IIRC it was
    10 FOR I PIN I 1+ HZ NEXT
    Not bad hey!

    The Monitor can do it too...
    R_BOOT_P2.BIY
    But it requires a file on the SD that flashes the pins ;)
    It's a bit more than a 1 liner too
  • Cluso99 wrote: »
    There was a last minute change to the boot sequence. Serial pull-up is checked first, then Flash, and last SD. IF SD exists but is faulty or there is no P2 boot data/file then the code shuts down the prop because it's not possible to jump back to the booter.

    Chip and I played with TAQOZ while on Skype this evening. Was nice to see a set of pins flash with a simple command. IIRC it was
    10 FOR I PIN I 1+ HZ NEXT
    Not bad hey!

    The Monitor can do it too...
    R_BOOT_P2.BIY
    But it requires a file on the SD that flashes the pins ;)
    Nice! I am looking forward to playing with TAQOZ.

  • Cluso99Cluso99 Posts: 18,066
    Latest BeMicroCV-A9 boots SD (requires an external SD as the on-board SD causes internal pullup issues), Serial which can then go to the Monitor or TAQOZ. I haven't tried Flash but Chip is happy with this part.
  • Is there going to be a Prop123-A9 image that contains the new ROM?
  • David Betz wrote: »
    Is there going to be a Prop123-A9 image that contains the new ROM?

    Chip is making sure the code works on the CVA9 first since we can test it straight away and then compile images for 123-A9 and DE2 etc.
    Not sure about DE0s though, they just don't have enough resources to test properly.
  • David Betz wrote: »
    Is there going to be a Prop123-A9 image that contains the new ROM?

    Chip is making sure the code works on the CVA9 first since we can test it straight away and then compile images for 123-A9 and DE2 etc.
    Not sure about DE0s though, they just don't have enough resources to test properly.
    Does Chip have a CVA9 board? I thought the Prop123-A9 board was supposed to be the official development board for P2. That's why I bought it.

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-17 01:32
    David, I see Chip sent a new image for CVA9 and 123-A9 so I have these files in the FPGA_v32e folder in my P2 folder.
  • David, I see Chip sent a new image for CVA9 and 123-A9 so I have these files in the FPGA_v32e folder in my P2 folder.
    Thanks! Now how do I get to TAQOZ? I can't seem to remember what control character to type after the ">" that does the auto baud.

  • David Betz wrote: »
    David, I see Chip sent a new image for CVA9 and 123-A9 so I have these files in the FPGA_v32e folder in my P2 folder.
    Thanks! Now how do I get to TAQOZ? I can't seem to remember what control character to type after the ">" that does the auto baud.
    Never mind. I figured it out. I typed ">" to auto baud and then ESC to get into TAQOZ. I even ran an incredibly complicated Forth program and it worked!
    1 2 + .
    

    Now I'm waiting for the TAQOZ docs like Chip. BTW, I'm using PuTTY to talk to TAQOZ. What can I do to try to duplicate the problem you said that Chip was having? So far I've just used 115200 baud.

  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-17 02:12
    I'm just updating the doco for that but after the autobaud greater than + space "> " just hit escape

    Anytime you try something that appears to be stuck like BEGIN AGAIN you can hit escape four times in a row to bring you back.
    Use ^D to go to Cluso's debugger and ESC<CR> from there to come back to TAQOZ.
  • Is there a way to reset the P2 other than power cycling the Prop123-A9 board? It takes forever to load the FPGA configuration on power on.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-17 02:24
    The FPGA config is locked in after programming so you only ever have to do this once. But you do need to cycle power first time after configuration though. Your terminal can toggle DTR which will generate a reset through the PropPlug or ^G from PNut will reset the P2.

    The moment I power up my FPGA I just type the two autobaud characters "> " + ESC ($3E,$20,$1B) and I am up and running in TAQOZ
  • The FPGA config is locked in after programming so you only ever have to do this once. But you do need to cycle power first time after configuration though. Your terminal can toggle DTR which will generate a reset through the PropPlug or ^G from PNut will reset the P2.

    The moment I power up my FPGA I just type the two autobaud characters "> " + ESC ($3E,$20,$1B) and I am up and running in TAQOZ
    I got it working and I think I figured out that one of the buttons on the Prop123-A9 board resets the P2. Now I'll wait for a TAQOZ document before doing any more playing. I can guess simple Forth commands but I won't be able to do anything with the P2 hardware without more docs.

Sign In or Register to comment.