thanks david. i will try again tomorrow.
btw did you find the problem with setcog ?
I guess there is no problem. Several people pointed out that the instruction encoding that I was using was correct. I tried my original code again this morning and now it seems to work. I'm not sure what was going wrong before. Sorry for the false alarm!
I just posted today's first update to the top post. This fixes a bug where the -c option could cause the second-stage loader to crash. It also switches to using cogid since it now seems to be working for me. Not sure why it was failing before.
I just posted today's first update to the top post. This fixes a bug where the -c option could cause the second-stage loader to crash. It also switches to using cogid since it now seems to be working for me. Not sure why it was failing before.
I wanted me that -t flag terminate loader COG and transfer me to Monitor mode.
Forum will not manage OBJ files --- So I renamed them by adding .BIN
Thanks! I downloaded the files and get the same result as you do. I'll try to figure out what's going wrong. What should this program do if it was working correctly?
Thanks! I downloaded the files and get the same result as you do. I'll try to figure out what's going wrong. What should this program do if it was working correctly?
It is test program and shall start Monitor in COG-1. It works if I start it in my way by loading COG-0 with empty OBJ file (same as stop COG
This may be the problem. You can't start code in another COG that uses the serial connection because the loader is still using the connection to complete the load. You've basically grabbed the terminal out from under the second-stage loader. Maybe you should have your main program launch the monitor after it starts. In the meantime, I'll verify that -c is really working.
This may be the problem. You can't start code in another COG that uses the serial connection because the loader is still using the connection to complete the load. You've basically grabbed the terminal out from under the second-stage loader. Maybe you should have your main program launch the monitor after it starts. In the meantime, I'll verify that -c is really working.
The DAC emulation output only exists on COG 0. I think everything else is on the other COGS. Pin emulation isn't complete either, but what there is exists on the four DAC pins on COG 0.
And that is why we need to put the display on COG 0 for now.
Oh, and no more Excel macros to format a monitor load file. (I know, but it was stupid easy) The load is really fast now!
I guess I'm confused by this. Aren't the DACs associated with pins not COGs? If certain pins have DAC emulation, shouldn't that be avaiable from any COG since every COG can access any pin?
I guess I'm confused by this. Aren't the DACs associated with pins not COGs? If certain pins have DAC emulation, shouldn't that be avaiable from any COG since every COG can access any pin?
Same way as on real Prop II --- But not all hardware are inside FPGA ---- It is why AD on boards have dac resistors on them and use 9 FPGA pins to one DAC
Same way as on real Prop II --- But not all hardware are inside FPGA ---- It is why AD on boards have dac resistors on them and use 9 FPGA pins to one DAC
Thanks for trying to explain but I'm still not getting it. If the DACs are in the pins then I don't understand why they are restricted to COG 0 even in the FPGA. Don't all of the COGs have access to all of the pins even on the FPGA? Or are there some pins (the ones with the DACs) that can only be accessed by COG 0? If so, what happens if one of the other COGs tries to access those pins?
Thanks for trying to explain but I'm still not getting it. If the DACs are in the pins then I don't understand why they are restricted to COG 0 even in the FPGA. Don't all of the COGs have access to all of the pins even on the FPGA? Or are there some pins (the ones with the DACs) that can only be accessed by COG 0? If so, what happens if one of the other COGs tries to access those pins?
These pin's are not accessible BY COG but simplified DAC handler hardware Chip made for them in FPGA.
For handler that can handle DAC's in FPGA from all COG's it is no place in FPGA's logic area
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!
Understand.
How much time You think Loader need before Monitor will use Ports ---- Maybe I can fix it by anding some WAIT time ?
There needs to be enough time for the loader to process another packet from the PC saying to start the program in COG 0 (your main program). I'm not sure how long that takes. Why not put a one second delay in just as a test to see if this even solves the problem.
By the way, I tried a test similar to what you're doing with code that doesn't access the serial port and it seems to work. I think this means that starting code in another COG is working. Here is the code I used to test. I loaded this into COG 1 along with the propgcc fibo demo running in COG 0 and it works.
DAT
getcnt time
add time, delta
loop notp #32
waitcnt time, delta
jmp #loop
time long 0
delta long 30000000
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!
There needs to be enough time for the loader to process another packet from the PC saying to start the program in COG 0 (your main program). I'm not sure how long that takes. Why not put a one second delay in just as a test to see if this even solves the problem.
By the way, I tried a test similar to what you're doing with code that doesn't access the serial port and it seems to work. I think this means that starting code in another COG is working. Here is the code I used to test. I loaded this into COG 1 along with the propgcc fibo demo running in COG 0 and it works.
DAT
getcnt time
add time, delta
loop notp #32
waitcnt time, delta
jmp #loop
time long 0
delta long 30000000
You mean you're loading prog.obj in COG 0 with a command like this?
p2load prog.obj -t
That should work because the loader is finished when it starts COG 0 and doesn't need access to the serial port anymore. When you launch it with -c the loader still needs to launch the main program in COG 0 so it needs the serial port until that is done. The idea behind -c was to load COGs that would spin on a mailbox waiting to be activated by the main program. If you launch a program that runs automatically you'll need to make sure it doesn't interfere with the further functioning of the loader. Sorry if I'm not explaining this well.
Okay, that works because it launches what's at 1000 in COG 0. Once it runs a program in COG 0 it doesn't need access to the serial port anymore. In fact, the second-stage loader is no longer running after starting a program in COG 0. I would expect this to work. What caused you trouble before is that you were using -c to run your program in some other COG and the loader was still needed in COG 0 to start the main program. You'll have to at least put a delay in the program you're running in COG 1 if you want that to work. Better would be some form of positive handshaking.
By the way, it's late here and I have to get up early. I'm going to sign off for the night. I'll answer any more questions in the morning. Sorry for abandoning you! I hope you have a good evening or whatever time it is where you live!
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>
Comments
It is that I don't understand else it is BUG
Thanks,
David
Send You OBJ files used.
I wanted me that -t flag terminate loader COG and transfer me to Monitor mode.
Forum will not manage OBJ files --- So I renamed them by adding .BIN
Thanks! I downloaded the files and get the same result as you do. I'll try to figure out what's going wrong. What should this program do if it was working correctly?
Thanks.
It is test program and shall start Monitor in COG-1. It works if I start it in my way by loading COG-0 with empty OBJ file (same as stop COG
Understand.
How much time You think Loader need before Monitor will use Ports ---- Maybe I can fix it by anding some WAIT time ?
On real Prop II --- all COG's will have DAC's
But emulation have DAC's only on COG-0
Yes with Pins --- On real Prop II.
On FPGA emulators Chip needed simplify that -- As FPGA don't have DAC's inside
These pin's are not accessible BY COG but simplified DAC handler hardware Chip made for them in FPGA.
For handler that can handle DAC's in FPGA from all COG's it is no place in FPGA's logic area
By the way, I tried a test similar to what you're doing with code that doesn't access the serial port and it seems to work. I think this means that starting code in another COG is working. Here is the code I used to test. I loaded this into COG 1 along with the propgcc fibo demo running in COG 0 and it works.
No problem for me.
You can ask any question --- If I can I will always answer
Thanks -- will test that
But it is not in COG-0 --- It is in COG-1 I will start that code with COG-0 shut down
If I start code I send You in COG-0 it works.
But I think with last program snippet You give me idea how I can manage it.
Now time to test's
p2load -v Head.obj prog.obj,1000 -t
But I will have prog in COG-1...5 started NOT in COG-0
p2load -v Head.obj prog.obj,1000 -r 1000:0 -t
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
LSD_036.spin
LSD_036.obj.bin