Everything has arrived for me, which means I'll start sometime this week. I'll be using XP / win7, and I like the $1000 suggestion and the more complex format capable of launching COGS.
Everything has arrived for me, which means I'll start sometime this week. I'll be using XP / win7, and I like the $1000 suggestion and the more complex format capable of launching COGS.
Which FPGA board do you have? I just realized that I can't do anything with COG launching right away because I only have a DE0-Nano board that only supports a single COG.
David, I'd really prefer to keep $0E80-$1000 clear of any code; if anyone uses it for a boot loader area etc. eventually people will rely on that.
Keeping it clear has two additional benefits:
- the RAM can grow for future chips without the mailboxes having to move
- the monitor ROM area can grow a bit / shrink a bit without mailboxes having to move
Mailboxes should be assigned from $0FFF down in order to facilitate the above.
Heck, if I had things my way, I'd use:
$008E0-$00FFF: mailbox/system variables
$01000-$017FF: cog image area (COI)
$01800-$01FFF: four SD / flash sector buffers (SDFLASH)
$02000-$1FFFF: user code area
Advantages:
- standard area for mailboxes, system pointers etc
- standard area to launch cog images from
- standard area for file buffers
This way drivers could be loaded into the COI and launched from there, file systems would have a reserved area for buffers, and a dedicated space for STDIO mailboxes - giving us a head start at decoupling STDIO drivers and removing most cog images from loadable images.
The above is actually a cut-down version of what I was planning for Largos.
David - Re/ Platforms:
I use Ubuntu 12.04, WinXPPro, Win7Pro for production boxes. I have a Mac Mini, but it is not a development box, it is wifey's
TDavid, I'd really prefer to keep $0E80-$1000 clear of any code; if anyone uses it for a boot loader area etc. eventually people will rely on that.
I wasn't suggesting that we put code there. I was just suggesting that the loader could place initialized mailbox structures and other configuration information if it is used in its more complex mode where it loads COG drivers in advance of loading the user program. The COG image of the user's program would start at $1000 as you suggest.
I'd really prefer to keep $0E80-$1000 clear of any code; if anyone uses it for a boot loader area etc. eventually people will rely on that.
I don't understand why there is such a push to compartmentalize the hub ram space. Wouldn't it's usage entirely depend on the tool(s) you use to generate your code/data?
I don't understand why there is such a push to compartmentalize the hub ram space. Wouldn't it's usage entirely depend on the tool(s) you use to generate your code/data?
Of course, if we have an executable file format that is a bit more complex than just a binary dump of hub memory, we could make the loader able to handle different memory layouts. Something as simple as a header that contains a start address and list of stuctures giving file offsets, sizes, and load addresses would provide a lot of flexiblity.
I don't understand why there is such a push to compartmentalize the hub ram space. Wouldn't it's usage entirely depend on the tool(s) you use to generate your code/data?
I think the goal is to set some standards so the various tools used to generate code/data can create interoperable objects.
Getting this worked out and implemented in a few tools could really help jump start P2 development when actual chips hit the street.
Obviously a developer is free to do as they choose, but having such "standards", can really save time in allowing sharing of objects and preventing constant re-development of the wheel.
I wasn't suggesting that we put code there. I was just suggesting that the loader could place initialized mailbox structures and other configuration information if it is used in its more complex mode where it loads COG drivers in advance of loading the user program. The COG image of the user's program would start at $1000 as you suggest.
Code / Object reuse is why we want to establish a few basic things right now. Of course, anyone is free to just stuff a binary into their Prop, and that's gonna happen too. But, the majority use case will be to leverage other code. Drivers, etc... all really shine when they can be dropped in lego style as much as possible. A robust loader does this very nicely, and the P2 is both roomy enough for that to make sense and it's got threads, both of which up the game to the point where it makes a lot of sense to have some structure.
Code / Object reuse is why we want to establish a few basic things right now. Of course, anyone is free to just stuff a binary into their Prop, and that's gonna happen too. But, the majority use case will be to leverage other code. Drivers, etc... all really shine when they can be dropped in lego style as much as possible. A robust loader does this very nicely, and the P2 is both roomy enough for that to make sense and it's got threads, both of which up the game to the point where it makes a lot of sense to have some structure.
One nice thing about P2 is that it only has a simple first-stage loader in ROM. The second-stage loader that you load using the ROM loader can do anything it wants.
Here is an early version of my p2load program built using Cygwin to run under Windows. If someone would try this who doesn't have Cygwin installed I'd appreciate it. I'm sure I need to include a few DLLs but I'm not sure which are required. Let me know and I'll add them to the zip file.
This loader should be able to load .BIN and .obj files created with PNut.exe. I've included a sample program (my "Hello, Propeller II!" program). You should be able to load it like this:
p2load -v p2-hello.BIN -t
The -v just gets you some additional information that might be useful to me if you have problems. The -t says to enter a simple terminal emulator after completing the load.
This is a command-line tool. I might consider making a GUI version of it using Qt if there is a need.
Edit: Updated the zip file to include cygwin1.dll
Edit: Updated the zip file to also include cyggcc_s-1.dll
Edit: Added a -b option to select the baud rate
Here is an early version of my p2load program built using Cygwin to run under Windows. If someone would try this who doesn't have Cygwin installed I'd appreciate it. I'm sure I need to include a few DLLs but I'm not sure which are required. Let me know and I'll add them to the zip file.
This loader should be able to load .BIN and .obj files created with PNut.exe. I've included a sample program (my "Hello, Propeller II!" program). You should be able to load it like this:
p2load -v p2-hello.BIN -t
The -v just gets you some additional information that might be useful to me if you have problems. The -t says to enter a simple terminal emulator after completing the load.
This is a command-line tool. I might consider making a GUI version of it using Qt if there is a need.
Sure. I guess there are many in this category. Are you willing to try the command-line version to see if it works for you? The GUI version will take a while.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Leon>cd\p2load
C:\p2load>p2load -v p2-hello.BIN -t
C:\p2load>path = c:\cygwin\bin
C:\p2load>p2load -v p2-hello.BIN -t
Trying COM1
found propeller version 32
loading 'p2-hello.BIN' on port COM1
..
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Hello, Propeller II!
Without a path to the Cygwin/bin directory I get a Windows error:
pload2.exe - Entry Point Not Found.
I just saw Sapieha's post; it's the same error he got, but in English.
Okay, I've updated the zip file again to include cyggcc_s-1.dll. I wonder how many more there will be? :-(
I think it only needed the 2 DLLs you included. BTW, you should be able to test this on your PC by running p2load under a Window's "Command Prompt" window.
I use these to troubleshoot application installations fairly regularly, like when one version doesn't clean up, and another fails to write, etc...
Thanks for the suggestion! I grabbed depends.exe and it looks like cygwin1.dll and cyggcc_s-1.dll are the only Cygwin DLLs needed for p2load.exe so I hope that the updated zip file is now complete.
Thanks for the suggestion! I grabbed depends.exe and it looks like cygwin1.dll and cyggcc_s-1.dll are the only Cygwin DLLs needed for p2load.exe so I hope that the updated zip file is now complete.
Comments
Which FPGA board do you have? I just realized that I can't do anything with COG launching right away because I only have a DE0-Nano board that only supports a single COG.
David, I'd really prefer to keep $0E80-$1000 clear of any code; if anyone uses it for a boot loader area etc. eventually people will rely on that.
Keeping it clear has two additional benefits:
- the RAM can grow for future chips without the mailboxes having to move
- the monitor ROM area can grow a bit / shrink a bit without mailboxes having to move
Mailboxes should be assigned from $0FFF down in order to facilitate the above.
Heck, if I had things my way, I'd use:
$008E0-$00FFF: mailbox/system variables
$01000-$017FF: cog image area (COI)
$01800-$01FFF: four SD / flash sector buffers (SDFLASH)
$02000-$1FFFF: user code area
Advantages:
- standard area for mailboxes, system pointers etc
- standard area to launch cog images from
- standard area for file buffers
This way drivers could be loaded into the COI and launched from there, file systems would have a reserved area for buffers, and a dedicated space for STDIO mailboxes - giving us a head start at decoupling STDIO drivers and removing most cog images from loadable images.
The above is actually a cut-down version of what I was planning for Largos.
David - Re/ Platforms:
I use Ubuntu 12.04, WinXPPro, Win7Pro for production boxes. I have a Mac Mini, but it is not a development box, it is wifey's
I don't understand why there is such a push to compartmentalize the hub ram space. Wouldn't it's usage entirely depend on the tool(s) you use to generate your code/data?
I think the goal is to set some standards so the various tools used to generate code/data can create interoperable objects.
Getting this worked out and implemented in a few tools could really help jump start P2 development when actual chips hit the street.
Obviously a developer is free to do as they choose, but having such "standards", can really save time in allowing sharing of objects and preventing constant re-development of the wheel.
C.W.
Thanks for the clarification - it definitely helped (so did a nice big cup of cofee) :-)
Yes, the loader placing initialized mailboxes there makes a lot of sense. Good suggestion.
This loader should be able to load .BIN and .obj files created with PNut.exe. I've included a sample program (my "Hello, Propeller II!" program). You should be able to load it like this:
p2load -v p2-hello.BIN -t
The -v just gets you some additional information that might be useful to me if you have problems. The -t says to enter a simple terminal emulator after completing the load.
This is a command-line tool. I might consider making a GUI version of it using Qt if there is a need.
Edit: Updated the zip file to include cygwin1.dll
Edit: Updated the zip file to also include cyggcc_s-1.dll
Edit: Added a -b option to select the baud rate
I prefer GUI. thanks
Look on attached Pic.
Thanks,
David
I'll add that DLL to the zip file.
Thanks
It worked OK for me (I have Cywin):
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Leon>cd\p2load
C:\p2load>p2load -v p2-hello.BIN -t
C:\p2load>path = c:\cygwin\bin
C:\p2load>p2load -v p2-hello.BIN -t
Trying COM1
found propeller version 32
loading 'p2-hello.BIN' on port COM1
..
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Hello, Propeller II!
Without a path to the Cygwin/bin directory I get a Windows error:
pload2.exe - Entry Point Not Found.
I just saw Sapieha's post; it's the same error he got, but in English.
What DLL is it?
I've updated the zip file in post #224 to include cygwin1.dll.
Look PIC.
BTW: I'm fine with command line. That can always be wrapped in a batch file, and or called by some other GUI, etc... no worries here.
Something like this: http://support.codegear.com/article/36834 (there are lots of them)
I use these to troubleshoot application installations fairly regularly, like when one version doesn't clean up, and another fails to write, etc...
Look on PIC.
DONE
Thanks for the suggestion! I grabbed depends.exe and it looks like cygwin1.dll and cyggcc_s-1.dll are the only Cygwin DLLs needed for p2load.exe so I hope that the updated zip file is now complete.
Now as it function ---> Can You add second line parameter to specify Baud-rate
The ldd command in cygwin should give you a list of the dynamic load libraries an executable needs.
Up to 3.000.000 at least --- For test possibility's --- Same way PuTTY use it --- no any fast values