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.
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.
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
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`
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?
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...
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.
@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?
@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?
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.
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?
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!
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
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
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?
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.
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.
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.
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.
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.
Comments
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.
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?
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.
Not if someone is loading from a local small secure microcontroller, the variance then is all inside the P2.
With the boot code somewhat published, there is less `theory` involved, as many delays are already documented.
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.
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.
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:
and to compile within PNut so that it can be one source file I need to do this: 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:
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!
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
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.
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.
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.
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