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

p2load: A Loader for the Propeller II

2456711

Comments

  • David BetzDavid Betz Posts: 14,511
    edited 2012-12-29 13:22
    Cluso99 wrote: »
    David: That comment was in jest - "vaporsilicon". Yes I know the other cogs are not in the fpga because they don't fit in the chip used. Thanks for letting me know what the DE2-115 does (I could have looked it up but the thread is quite long now).

    It is really fantastic that we can test a single cog on a $79 platform. I think this has to be a first by any company, with or without NDA.

    I need to add some leds to my DE0 so that I can test the I/O port with spin. It is simple enough - 8 superbright leds and a SIL resistor network will make this a simple job.
    Yes, I figured you knew that the extra COGs were just missing not broken. I just posted that so others would know that it isn't a sign of problems with the design, just a limitation of the FPGA implementation.

    I'd like to wire up some LEDs to one or both of my boards. Actually, the DE2-115 board has lots of switches and LEDs so I'm surprised that Chip didn't hook a few of them up to Propeller pins. I guess he's pretty busy with other stuff though. As you say, it is really fantastic that they offered these FPGA configuration files at all and they are certainly good enough to get some serious work done!
  • potatoheadpotatohead Posts: 10,253
    edited 2012-12-29 19:13
    I thought the DE2 ran at 80Mhz.

    The switches and LED's are connected on the DE2. I use them constantly right now.

    From the file:
    ' Terasic DE2-115 Prop2 Emulator Setup
    '

    '
    ' This arrangement gives you six cogs and a full 128KB hub memory.
    '
    ' See the DE2_115_Prop2_Hookup.png file for the Prop2 pinout guide.
    '
    ' To Program the DE2-115 board, you must place the SW19 slide switch
    ' in the lower left corner of the board to the PROG position. Power up
    ' the board and have the USB cable connected, with Quartus running on
    ' your PC. Go to Tools>Programmer and select 'Active Serial Programming'.
    ' Load the DE2_115_Prop2.pof file. See the DE2_115_Prop2_Programming.png
    ' image. When everything is in order, click 'Start' to load the board.
    ' Afterwards, place SW19 in the RUN position and cycle the power to boot
    ' it into the Prop2 configuration.
    '
    ' To communicate with the board, plug a Propeller Plug into the header
    ' as shown in the DE2_115_Hookup.png image.
    '
    ' Once you're powered up and plugged in, you can run the ROM monitor by
    ' hitting <space> via a terminal program, or hit F10 within PNut.exe to
    ' assemble, download, and run an assembly language program.
    '
    ' The pushbutton labeled 'KEY3' will reset the Prop2. The eight green
    ' LEDs will indicate which cogs are running, even though only six cogs
    ' are actually implemented.
    '
    ' Pushbuttons KEY2..KEY0 are mapped to Propeller pins P52..P50. The 18
    ' slide switches are mapped to P49..P32. The 18 red LEDs are driven by
    ' P49..P32 outputs, though the inputs will always read the slide switch
    ' states.
    '
    ' A program should only contain CON and DAT sections. PUB/PRI blocks will
    ' not be interpreted properly, as the tool is in a state of flux now.
    I can't find where 80Mhz was mentioned... still looking.

    Ahh, found it. http://forums.parallax.com/showthread.php?125543-Propeller-II-update-BLOG&p=1143832&viewfull=1#post1143832 They can run at 80, not sure whether or not they are. Need to test this.
  • David BetzDavid Betz Posts: 14,511
    edited 2012-12-30 04:03
    potatohead wrote: »
    I thought the DE2 ran at 80Mhz.

    The switches and LED's are connected on the DE2. I use them constantly right now.

    From the file:


    I can't find where 80Mhz was mentioned... still looking.

    Ahh, found it. http://forums.parallax.com/showthread.php?125543-Propeller-II-update-BLOG&p=1143832&viewfull=1#post1143832 They can run at 80, not sure whether or not they are. Need to test this.
    I think my DE2-115 must be running at 60mhz or my serial code wouldn't be working. It assumes a 60mhz clock.

    I didn't know that the DE2-115 had the LEDs and switches connected. What Propeller pins are they on?
  • nutsonnutson Posts: 242
    edited 2012-12-30 04:10
    ' Pushbuttons KEY2..KEY0 are mapped to Propeller pins P52..P50. The 18
    ' slide switches are mapped to P49..P32. The 18 red LEDs are driven by
    ' P49..P32 outputs, though the inputs will always read the slide switch
    ' states.
  • David BetzDavid Betz Posts: 14,511
    edited 2012-12-30 04:47
    nutson wrote: »
    ' Pushbuttons KEY2..KEY0 are mapped to Propeller pins P52..P50. The 18
    ' slide switches are mapped to P49..P32. The 18 red LEDs are driven by
    ' P49..P32 outputs, though the inputs will always read the slide switch
    ' states.
    Thanks! That will be very helpful. Do you know if the LCD is mapped anywhere?
  • nutsonnutson Posts: 242
    edited 2012-12-30 05:18
    This is what Chip has given us, besides the pins P0-P31 mapped to the DE0 and DE2 extension connector. The DE2 LCD is not mapped to propeller pins (nor is the SRAM, SD card socket etc ) These are not available on the DE3 development board he is using, I assume he has mapped all remaining pins to HSMC connectors (the DE3 has 4 HSMC connectors) for add-on boards with pin hardware (A/D and D/A circuits).
  • David BetzDavid Betz Posts: 14,511
    edited 2012-12-30 06:14
    nutson wrote: »
    This is what Chip has given us, besides the pins P0-P31 mapped to the DE0 and DE2 extension connector. The DE2 LCD is not mapped to propeller pins (nor is the SRAM, SD card socket etc ) These are not available on the DE3 development board he is using, I assume he has mapped all remaining pins to HSMC connectors (the DE3 has 4 HSMC connectors) for add-on boards with pin hardware (A/D and D/A circuits).
    I hadn't even noticed the SD socket since it is mounted on the bottom of the PCB. It would be very nice if that was connected to some P2 pins as it would allow me to get the PropGCC SD support working. Maybe Chip will add that when he gets back from the holiday break. The other stuff probably isn't critical. Even just having the LEDs and switches is a big bonus! Thanks for the info.
  • potatoheadpotatohead Posts: 10,253
    edited 2012-12-30 12:07
    Chip said elsewhere he would make them behave the same. 60Mhz is called out in the NANO explanation, and no clock is called out on the DE2, with it just being a different arrangement from the NANO. Makes sense.
  • Cluso99Cluso99 Posts: 18,066
    edited 2013-03-26 22:32
    David:

    I have just found that pnut creates 2 output files, a .BIN and a .obj
    The .BIN is a truncated file with the 2KB limitation of the pnut loader. However, the .obj file is correct and works fine with your p2load.

    I am presuming that the -h option skips the first $E80 bytes, and starts COG 0 execution at $1000. Is this correct, or do you skip the whole $1000 bytes?
    Postedit: Question answered by trial - the "-h" option is not supported.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-27 07:11
    Cluso99 wrote: »
    David:

    I have just found that pnut creates 2 output files, a .BIN and a .obj
    The .BIN is a truncated file with the 2KB limitation of the pnut loader. However, the .obj file is correct and works fine with your p2load.

    I am presuming that the -h option skips the first $E80 bytes, and starts COG 0 execution at $1000. Is this correct, or do you skip the whole $1000 bytes?
    Postedit: Question answered by trial - the "-h" option is not supported.
    Yes, p2load can load the .BIN files produced by PNut.exe. That's how I got PropGCC working in the first place before I tought p2load to read .elf files.

    The -s option strips the first 0xe80 bytes from the .BIN file since that is where the loader lives.

    The -h option causes the COG image at 0x1000 to be loaded rather than loading a COG image at 0xe80 which is the default. This is based on a discussion we had a while back about reserving the space between 0x0e80 and 0x1000 for global variables and mailboxes. We never really finished that discussion so I don't currently do anything with that space other than put CLKFREQ at the long starting at 0x0e80 for PropGCC programs.
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-03-27 07:46
    I am planning to put the smallest amount of pasm code at $e80 to re-start the cog at $1000, I think only three longs are needed, we could use the fourth for the clock frequency. This would leave $e90-$fff available for mailboxes.
    David Betz wrote: »
    Yes, p2load can load the .BIN files produced by PNut.exe. That's how I got PropGCC working in the first place before I tought p2load to read .elf files.

    The -s option strips the first 0xe80 bytes from the .BIN file since that is where the loader lives.

    The -h option causes the COG image at 0x1000 to be loaded rather than loading a COG image at 0xe80 which is the default. This is based on a discussion we had a while back about reserving the space between 0x0e80 and 0x1000 for global variables and mailboxes. We never really finished that discussion so I don't currently do anything with that space other than put CLKFREQ at the long starting at 0x0e80 for PropGCC programs.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-27 07:50
    I am planning to put the smallest amount of pasm code at $e80 to re-start the cog at $1000, I think only three longs are needed, we could use the fourth for the clock frequency. This would leave $e90-$fff available for mailboxes.
    Shouldn't we start at 0xe80 with CLKFREQ and CLKMODE to be similar to P1?
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-03-27 07:53
    If I recall correctly, Chip's boot loader loads & executes a cog image starting at 0xe80... and if that is correct, we should not be storing CLKFREQ and CLKMODE there, as they would be executed.
    David Betz wrote: »
    Shouldn't we start at 0xe80 with CLKFREQ and CLKMODE to be similar to P1?
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-27 07:56
    If I recall correctly, Chip's boot loader loads & executes a cog image starting at 0xe80... and if that is correct, we should not be storing CLKFREQ and CLKMODE there, as they would be executed.
    That's the second-stage loader. All it does is loads the rest of the program and restarts with the COG image starting at 0x1000 at least for PropGCC. The second-stage loader is not needed after that.
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-03-27 08:18
    Ok, so if I understand the sequence correctly now:

    1) Chip's SPI flash loader loads an initial first stage loarder at $E80

    2) In that loader you set $E80 to CLKFREQ, and $E84 to CLKMODE

    3) subsequently that loader loads a cog image at $1000, and replaces itself in the boot cog with that image.

    If the above is correct, then

    4) only first stage boot loaders need to worry about starting at $E80

    5) $E88-$FFF will be available for mailboxes

    6) elf executables will be loaded starting $1000
    David Betz wrote: »
    That's the second stage loader. All it does is loads the rest of the program and restarts with the COG image starting at 0x1000 at least for PropGCC. The second-stage loader is not needed after that.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-27 08:22
    Ok, so if I understand the sequence correctly now:

    1) Chip's SPI flash loader loads an initial first stage loarder at $E80

    2) In that loader you set $E80 to CLKFREQ, and $E84 to CLKMODE

    3) subsequently that loader loads a cog image at $1000, and replaces itself in the boot cog with that image.

    If the above is correct, then

    4) only first stage boot loaders need to worry about starting at $E80

    5) $E88-$FFF will be available for mailboxes

    6) elf executables will be loaded starting $1000
    Yes, that's how the PropGCC loader works now as well as p2load when it loads .BIN files produced by PNut. The same happens when it loads over the serial connection except that the second-stage loader is sent over the serial link rather than being read from the SPI flash. That single COG image either reads the full hub image over the serial link or loads it from the SPI flash and then replaces itself with the COG image starting at 0x1000. It doesn't actually patch CLKFREQ and CLKMODE. Those are expected to be part of the hub image that it loads either from the serial link or from the flash.
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-03-27 08:37
    Cool - thanks.

    Time for me to start using p2load... I've run into the pnut 2k load limit.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-27 08:42
    Cool - thanks.

    Time for me to start using p2load... I've run into the pnut 2k load limit.
    Didn't someone say recently that PNut was able to load more than 2k? It wasn't able to do that when I started writing p2load but it may have been upgraded since then.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-27 08:45
    Cool - thanks.

    Time for me to start using p2load... I've run into the pnut 2k load limit.
    By the way, the -s option in p2load is because I was writing PASM code starting with this:
    CON
            BASE = $e80
    
    DAT
                    byte    0[BASE]
    
                    org
    

    This was to make sure that hub addresses came out right. This is what caused $e80 bytes of zeros to be at the start of my .BIN files. I added the -s option to skip over those zero bytes and start loading hub memory starting at $e80.
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-27 08:47
    Hi David.

    It is possible to use p2load this way ?

    p2load file.1 -E80 file.2 1000 file.3 2000.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-27 08:50
    Sapieha wrote: »
    Hi David.

    It is possible to use p2load this way ?

    p2load file.1 -E80 file.2 1000 file.3 2000.
    I'm not exactly sure what you're trying to do here but p2load currently can only load one file at a time. Are you trying to load multiple files each at a different address?
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-27 08:54
    Something else that I should point out is that I've moved my development over to propeller-load which currently knows how to load either P1 or P2. The advantage of propeller-load is that it knows how to write a bootable image to the SPI flash. The p2load program can't do that at present. Are current or perspective users of p2load willing to use propeller-load instead? Later this evening I'll make sure that propeller-load can handle the .BIN files produced by PNut. If there is still interest in p2load, I'll try to merge in the SPI flash writing code into that as well.
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-27 08:55
    Hi David.

    I need load snippets from 3 different compilers at same time before starting Initial COG.

    David Betz wrote: »
    I'm not exactly sure what you're trying to do here but p2load currently can only load one file at a time. Are you trying to load multiple files each at a different address?
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-27 08:57
    Sapieha wrote: »
    Hi David.

    I need load snippets from 3 different compilers at same time before starting Initial COG.
    Three different compilers? Which compilers are you using? What kind of output do they produce? Just binary image files?
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-27 09:02
    Hi David.

    Sorry --- What ones --- Not available YET before I tested idea that it function

    David Betz wrote: »
    Three different compilers? Which compilers are you using? What kind of output do they produce? Just binary image files?
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-27 09:05
    Sapieha wrote: »
    Hi David.

    Sorry --- What ones --- Not available YET before I tested idea that it function
    Ah, more secret projects!

    Let me understand your command line syntax. You're expecting the loader to take an option switch to select load address before each filename. Is that correct?

    And, even though these are secret languages, can you at least say if they produce binary images?
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-27 09:10
    Hi David.

    You are correct on this. It can be 2 - 5 parts

    It will be both binary and text -- but for consistency all loaded same way. But very important that every one will be placed in correct MEM position as that position will be even reference address for that other parts


    David Betz wrote: »
    Ah, more secret projects!

    Let me understand your command line syntax. You're expecting the loader to take an option switch to select load address before each filename. Is that correct?

    And, even though these are secret languages, can you at least say if they produce binary images?
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-27 09:13
    Sapieha wrote: »
    Hi David.

    You are correct on this. It can be 2 - 5 parts

    It will be both binary and text -- but for consistency all loaded same way. But very important that every one will be placed in correct MEM position as that position will be even reference address for that other parts
    Okay, once you define the file formats let me know and I'll add multi-file capability to p2load.
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-27 09:17
    Hi David.

    For p2load ---- All files are BINARY --- What I place in them --- p2load not need know!


    David Betz wrote: »
    Okay, once you define the file formats let me know and I'll add multi-file capability to p2load.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-03-27 09:18
    Sapieha wrote: »
    Hi David.

    For p2load ---- All files are BINARY --- What I place in them --- p2load not need know!
    Okay, I guess I misunderstood. I thought you mentioned a text file format as well.
Sign In or Register to comment.