Okay, I guess I don't need to understand this fully since I'm not writing video code. In any case, I shouldn't be bothering you with these questions. Is should read Chip's documents myself or his sample code. Sorry!
Chip was only able to test the synthesized logic component of the Prop2 using an FPGA. The memory and I/O pad frame were designed schematically and implemented in silicon by Beau. They won't have a true-blue Prop2 test chip until the shuttle run arrives.
Chip cheated DACs on the FPGA by bringing out the 9 bits of the DAC to R2R ladders, but the limitation in FPGA is that only COG 0 has them brought out to hardware. Surely if you had a Stratix 3 like Chip, there would be enough pins to bring all DACs out to real hardware, but that's pointless.
I recall Chip mentioning something about them getting a couple of silicon chips with the I/O hardware implemented, to test that they worked, but there was some complication with that test run.
Everyone has their fingers crossed that diligence and intelligence will result in 1 test run before they commit to a production run.
David:
I seem to be having a problem starting my program where I compile from $0 with fillers to $1000. The code loads fine but does not execute - I can see this by using your program to do an -m to start the monitor after loading hub. This is really nice because you can actually see what is in cog after the loading.
This is the command (I downloaded the latest v0.003)
p2load -v -s lsd_036.obj -h
My program is attached. It waits 5 secs and then boots the Rom Monitor. It appears that the cog (cog0 because I am on DE0) does not boot or gets lost???
Using -t gives the same result.
I tried the -c option and it fails with
c:\Propeller_II\P2Load>p2load -v -s lsd_036.obj -c 0,1000:0 -t
Trying COM8
Found propeller version 32 on COM8
Loading 'lsd_036.obj' at 0x00000e80
....
Timeout waiting for ACK/NAK
error: send start packet failed
c:\Propeller_II\P2Load>
The default behavior of the loader is to start the program 0xe80 unless either -h or -r are used to change the start address to something else. The -h option changes the start address to 0x1000 and the -r option allows you to set it to whatever you want. For example, "-r 1000" will do what you want. Also, if you are loading a .elf file produced by the GCC linker the default start address is 0x1000 so the -h option is not needed in that case.
David:
I seem to be having a problem starting my program where I compile from $0 with fillers to $1000. The code loads fine but does not execute - I can see this by using your program to do an -m to start the monitor after loading hub. This is really nice because you can actually see what is in cog after the loading.
This is the command (I downloaded the latest v0.003)
p2load -v -s lsd_036.obj -h
My program is attached. It waits 5 secs and then boots the Rom Monitor. It appears that the cog (cog0 because I am on DE0) does not boot or gets lost???
Using -t gives the same result.
I tried the -c option and it fails with
c:\Propeller_II\P2Load>p2load -v -s lsd_036.obj -c 0,1000:0 -t
Trying COM8
Found propeller version 32 on COM8
Loading 'lsd_036.obj' at 0x00000e80
....
Timeout waiting for ACK/NAK
error: send start packet failed
c:\Propeller_II\P2Load>
I just thought of something that might help here. I should probably check for the special case of using "0" as the COG number in the -c option and treat it the same as if you had specified the -r option. In other words:
-c 0,1000:0
would be handled as if you had entered
-r 1000,0
The reason using the -c option didn't work for you is that you loaded something over the top of the second-stage loader and that killed the rest of the load. The -r option tells the loader how to restart COG 0 once the load is complete and the second-stage loader is no longer needed. I'll add that later tonight if I get a chance.
I did find a defficiency in the terminal mode - if you exit with a ^C, it leaves the shell messed up.
Not a big deal, I went back to using GtkTerm for serial I/O, and use p2load to load.
Is there a way of getting PNut to make the obj without downloading?
Oops, sorry about that. I'll look into fixing that later. You can exit by entering ESC in the meantime. That should leave the terminal in a good state.
You can get PNut to generate the .obj file by selecting the "Compile Current and View Info" F9 option in the "Run" menu.
Oops, sorry about that. I'll look into fixing that later. You can exit by entering ESC in the meantime. That should leave the terminal in a good state.
You can get PNut to generate the .obj file by selecting the "Compile Current and View Info" F9 option in the "Run" menu.
I thought I read a message somewhere that Chip had updated PNut to load files larger than 2K. Maybe when he did that he figured no one would need p2load anymore so he removed the F9 option?
David: I think you missed the first part of my problem. The -h didn't work for me. Am I doing something wrong?
Postedit: Just tried v0.004 and the same problem...
This does not work...
p2load -v -s lsd_038.obj -h
and this does work...
p2load -v -s lsd_038.obj -c 0,1000:0
Okay, I think I have this fixed. I'll build a new Windows version and upload it in a few minutes.
david-betzs-macbook-pro:Downloads dbetz$ p2load -s -h LSD_036.obj -t
Found propeller version 32 on /dev/cu.usbserial-A700fKXl
Loading 'LSD_036.obj' at 0x00000e80
....
[ Entering terminal mode. Type ESC or Control-C to exit. ]
=== Propeller II Monitor ===
>
Thanks David. Perhaps with your latest changes, the -h and the -r options are no longer required as we have the -c solution which is far more powerful.
At some time, you may consider adding a value option to the -s command?
Thanks David. Perhaps with your latest changes, the -h and the -r options are no longer required as we have the -c solution which is far more powerful.
At some time, you may consider adding a value option to the -s command?
They're more powerful but they're also more of a pain to type. The -h option was intended to select the "high" address for the COG image following the convention of leaving the space between 0xe80 and 0x1000 for globals and mailboxes. I guess the -r option could be removed since it the same thing can be done with -c now with only two extra characters. I'm not sure if it's worth making yet another change though. I've posted far too many versions of p2load as it is! :-)
Are people generally happy with the way p2load works at this point? Are there any issues that still need addressing or can I consider it stable for the moment?
Are people generally happy with the way p2load works at this point? Are there any issues that still need addressing or can I consider it stable for the moment?
I am about to produce a document for P2Load and reference that in the monitor document where appropriate. For longer term reference, where do I point people to get the current version?
I am about to produce a document for P2Load and reference that in the monitor document where appropriate. For longer term reference, where do I point people to get the current version?
Good question. The sources are part of the PropGCC project on Google Code but my official method of distributing it so far has been the top post of this thread.
I am about to produce a document for P2Load and reference that in the monitor document where appropriate. For longer term reference, where do I point people to get the current version?
And, THANKS for offering to make a document describing p2load! I'd be happy to review anything you come up with.
Comments
I added 0.5 sec wait time before COG-1 starts Monitor
>- !!!!!!!!!!!!!!!!
AND it works
!!!!!!!!!!!!!!!!!!!!!!
Now I can stop COG-0 by monitor and Monitor are running in COG-1
Now I can say ----> -c 1,1000:0 function
p2load -v Head.obj prog.obj,1000 -c 1,1000:0 -t
You can test by rename attached files xxx.obj and run p2load command line in example
Prog.spin 'Stop COG-0 Spawn monitor on COG-1 DAT Monitor org 0 getcnt time add time, delta waitcnt time, delta COGSTOP 0 setcog #1 coginit monitor_pgm,monitor_ptr long $FF[10+32] ''---------------------------------------------------- ''------------ DE2-115 Test LED, Switch ------- '' --- Port A ---------LED -------------------- LEDS long $ _LED15 byte 29 '' DE2-115 _LED16 byte 30 '' DE2-115 _LED17 byte 31 '' DE2-115 '' --- Port B --------------------------------- _LED0 byte 32 '' DE2-115 _LED1 byte 33 '' DE2-115 _LED2 byte 34 '' DE2-115 _LED3 byte 35 '' DE2-115 _LED4 byte 36 '' DE2-115 _LED5 byte 37 '' DE2-115 _LED6 byte 38 '' DE2-115 _LED7 byte 39 '' DE2-115 _LED8 byte 40 '' DE2-115 _LED9 byte 41 '' DE2-115 _LED10 byte 42 '' DE2-115 _LED11 byte 43 '' DE2-115 long 0 long 0 long 0 '' --- Port A ----------SW -------------------- KEYSW long $ _KEY1 byte 29 '' DE2-115 _KEY2 byte 30 '' DE2-115 _KEY3 byte 31 '' DE2-115 '' --- Port B --------------------------------- _SW0 byte 32 '' DE2-115 _SW1 byte 33 '' DE2-115 _SW2 byte 34 '' DE2-115 _SW3 byte 35 '' DE2-115 _SW4 byte 36 '' DE2-115 _SW5 byte 37 '' DE2-115 _SW6 byte 38 '' DE2-115 _SW7 byte 39 '' DE2-115 _SW8 byte 40 '' DE2-115 _SW9 byte 41 '' DE2-115 _SW10 byte 42 '' DE2-115 _SW11 byte 43 '' DE2-115 long 0 long 0 long 0 long 0 monitor_pgm long $70C 'ROM entry point for monitor monitor_ptr long 90<<9 + 91 'Pins for one monitor time long 0 delta long 30000000 Mend long $ MBoxX byte $0[($0FFF-Mend-$E8F)-4] ''/4-(6*4)] MBoxXa org $ long MBoxXa ------------------------------------------------------------------------------------------------------------------------------ F:\-Morph-Temp\_NANO_\Emulator\P2Terminal_cordic\p2load._M>p2load -v Head.obj p rog.obj,1000 -c 2,1000:0 -t Trying COM1 error: hardware lost Trying COM9 Found propeller version 32 on COM9 Loading 'Head.obj' at 0x00000e80 . Loading 'prog.obj' at 0x00001000 . [ Entering terminal mode. Type ESC or Control-C to exit. ] === Propeller II Monitor === > 00000- 50 72 6F 70 32 2E 30 20 00 20 7C 0C 03 CA 7C 0C 'Prop2.0 . |...|.' >all: $(TARGET)
Otherwise Eclipse, and pretty much any Unix environment, won't automatically build without an "all" rule.
Also, I recommend replacing the hardcoded OS selection with some auto-detection.
Chip was only able to test the synthesized logic component of the Prop2 using an FPGA. The memory and I/O pad frame were designed schematically and implemented in silicon by Beau. They won't have a true-blue Prop2 test chip until the shuttle run arrives.
Chip cheated DACs on the FPGA by bringing out the 9 bits of the DAC to R2R ladders, but the limitation in FPGA is that only COG 0 has them brought out to hardware. Surely if you had a Stratix 3 like Chip, there would be enough pins to bring all DACs out to real hardware, but that's pointless.
I recall Chip mentioning something about them getting a couple of silicon chips with the I/O hardware implemented, to test that they worked, but there was some complication with that test run.
Everyone has their fingers crossed that diligence and intelligence will result in 1 test run before they commit to a production run.
I just thought of something that might help here. I should probably check for the special case of using "0" as the COG number in the -c option and treat it the same as if you had specified the -r option. In other words:
-c 0,1000:0
would be handled as if you had entered
-r 1000,0
The reason using the -c option didn't work for you is that you loaded something over the top of the second-stage loader and that killed the rest of the load. The -r option tells the loader how to restart COG 0 once the load is complete and the second-stage loader is no longer needed. I'll add that later tonight if I get a chance.
I did find a defficiency in the terminal mode - if you exit with a ^C, it leaves the shell messed up.
Not a big deal, I went back to using GtkTerm for serial I/O, and use p2load to load.
Is there a way of getting PNut to make the obj without downloading?
You can get PNut to generate the .obj file by selecting the "Compile Current and View Info" F9 option in the "Run" menu.
ESC worked great.
You must use a different version of PNut, mine does not have that menu entry
Hard to say. My copy says "Prop 2 IDE 0.0". Hard to believe there was a version before that. Maybe version -1? :-)
My one to -- Don't have F9 option
Postedit: Just tried v0.004 and the same problem...
This does not work... and this does work...
Okay, I think I have this fixed. I'll build a new Windows version and upload it in a few minutes.
At some time, you may consider adding a value option to the -s command?
For me it is stable at the moment.
If I find any problem -- will report.