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!
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.
' 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.
' 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?
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).
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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?
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.
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?
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?
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
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?
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.
Comments
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!
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 didn't know that the DE2-115 had the LEDs and switches connected. What Propeller pins are they on?
' 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.
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.
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.
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
Time for me to start using p2load... I've run into the pnut 2k load limit.
CON BASE = $e80 DAT byte 0[BASE] orgThis 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.
It is possible to use p2load this way ?
p2load file.1 -E80 file.2 1000 file.3 2000.
I need load snippets from 3 different compilers at same time before starting Initial COG.
Sorry --- What ones --- Not available YET before I tested idea that it function
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?
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
For p2load ---- All files are BINARY --- What I place in them --- p2load not need know!