Shop OBEX P1 Docs P2 Docs Learn Events
p2load: A Loader for the Propeller II - Page 8 — Parallax Forums

p2load: A Loader for the Propeller II

15681011

Comments

  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 06:15
    Cluso99 wrote: »
    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!
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 06:35
    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.
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 12:38
    Hi David.

    It is that I don't understand else it is BUG
    F:\-Morph-Temp\_NANO_\Emulator\P2Terminal_cordic\p2load._M>  p2load -v Head.obj
     prog.obj,1000 -c 1,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
    .
    Timeout waiting for ACK/NAK
    error: send start packet failed
    
    F:\-Morph-Temp\_NANO_\Emulator\P2Terminal_cordic\p2load._M>  p2load -v Head.obj prog.obj,1000 -c 1,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
    .
    Timeout waiting for ACK/NAK
    error: send start packet failed
    
    F:\-Morph-Temp\_NANO_\Emulator\P2Terminal_cordic\p2load._M>
    

    David Betz wrote: »
    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.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 12:55
    Sapieha wrote: »
    Hi David.

    It is that I don't understand else it is BUG
    F:\-Morph-Temp\_NANO_\Emulator\P2Terminal_cordic\p2load._M>  p2load -v Head.obj
     prog.obj,1000 -c 1,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
    .
    Timeout waiting for ACK/NAK
    error: send start packet failed
    
    F:\-Morph-Temp\_NANO_\Emulator\P2Terminal_cordic\p2load._M>  p2load -v Head.obj prog.obj,1000 -c 1,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
    .
    Timeout waiting for ACK/NAK
    error: send start packet failed
    
    F:\-Morph-Temp\_NANO_\Emulator\P2Terminal_cordic\p2load._M>
    
    Can you send me the files you're having trouble with so I can check this later after my company has left?

    Thanks,
    David
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 13:07
    Hi 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


    David Betz wrote: »
    Can you send me the files you're having trouble with so I can check this later after my company has left?

    Thanks,
    David
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 16:58
    Sapieha wrote: »
    Hi 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?
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 17:08
    Hi David.

    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
    David Betz wrote: »
    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?
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 18:32
    Sapieha wrote: »
    Hi David.

    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
    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.
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 18:42
    Hi David.

    Understand.
    How much time You think Loader need before Monitor will use Ports ---- Maybe I can fix it by anding some WAIT time ?


    David Betz wrote: »
    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.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 18:44
    potatohead wrote: »
    [edited --droid phone barely posts here]

    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?
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 18:47
    Hi David.

    On real Prop II --- all COG's will have DAC's

    But emulation have DAC's only on COG-0

    David Betz wrote: »
    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?
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 18:49
    Sapieha wrote: »
    Hi David.

    On real Prop II --- all COG's will have DAC's

    But emulation have DAC's only on COG-0
    Sorry, I must not be understanding. Aren't DACs associated with pins not COGs?
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 18:52
    Hi David.

    Yes with Pins --- On real Prop II.

    On FPGA emulators Chip needed simplify that -- As FPGA don't have DAC's inside
    David Betz wrote: »
    Sorry, I must not be understanding. Aren't DACs associated with pins not COGs?
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 18:53
    Sapieha wrote: »
    Hi David.

    Yes with Pins --- On real Prop II.

    On FPGA emulators Chip needed simplify that -- As FPGA don't have DAC's inside
    How do you program the DACs under the emulation?
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 18:57
    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
    David Betz wrote: »
    How do you program the DACs under the emulation?
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 19:12
    Sapieha wrote: »
    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?
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 19:16
    Hi David.

    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
    David Betz wrote: »
    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?
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 19:25
    Sapieha wrote: »
    Hi David.

    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!
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 19:28
    Sapieha wrote: »
    Hi David.

    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
    
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 19:42
    Hi David.

    No problem for me.
    You can ask any question --- If I can I will always answer
    David Betz wrote: »
    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!
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 19:45
    Hi David.

    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

    David Betz wrote: »
    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
    
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 19:47
    Hi David.

    If I start code I send You in COG-0 it works.
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 19:53
    Hi David.

    But I think with last program snippet You give me idea how I can manage it.

    Now time to test's
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 19:54
    Sapieha wrote: »
    Hi David.

    If I start code I send You in COG-0 it works.
    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.
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 19:55
    Hi David.

    p2load -v Head.obj prog.obj,1000 -t

    But I will have prog in COG-1...5 started NOT in COG-0
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 20:01
    Sapieha wrote: »
    Hi David.

    p2load -v Head.obj prog.obj,1000 -t

    But I will have prog in COG-1...5 started NOT in COG-0
    That command only runs what is in Head.obj not what is in prog.obj, right? It just loads prog.obj but doesn't run it.
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 20:04
    Sorry


    p2load -v Head.obj prog.obj,1000 -r 1000:0 -t
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 20:06
    Sapieha wrote: »
    Sorry


    p2load -v Head.obj prog.obj,1000 -r 1000:0 -t
    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.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-31 20:08
    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!
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-03-31 20:11
    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>
    

    LSD_036.spin
    LSD_036.obj.bin
Sign In or Register to comment.