David, I think you read too much into people's actions.
The simple fact is that PNut was available as soon as we had FPGAs, and that is what was presented. PNUT is only an assembler, but most of the current users realize that this is a microcontroller, and as in the past it will be necessary to write code in PASM to extract the most from the chip.
Nobody is writing high level code for the P2, so you can relax.
The early adopters in this group do not represent any part of the cross section of potential P2 users, all of the folks in this group are hardcore Propellerheads and enjoy doing things the "hard" way.
Okay, I'll keep quiet now and work on p2load enhancements. :-)
I've built the p2test branch specifically so I could start using it for larger programs, however I am running into some limitations (that should be easy to address)
1) the LMM kernel needs to run on cog 1 (or 2..5) as video drivers MUST run in cog 0 on the FPGA's
2) an easy way to incorporate pnut.obj driver blobs (which may exist, perhaps I just need some info on how to do it)
3) a way to specify the last hub address the elf executable may use (so we can reserve frame buffer space) ie $8000
Can you give me some example code I can use to test feature 1?
The version of p2load checked into Google Code now supports the following options for running the main program. In the absence of any of these options, the program is started at either 0xe80 or 0x1000 depending on whether -h is specified and in COG 0.
[ -r addr[:param] ] run program in COG 0 from addr with parameter param
[ -r n, ] run program in COG n
[ -r n,addr[:param] ] run program in COG n from addr with parameter param
For example, to run a program in COG 1 you would use this command:
p2load myprog.obj -r 1,
I know the trailing comma is kind of ugly but it lets me continue to support the previous syntax where -r was used to specify the COG image address and parameter to pass to the main program.
Here is another new p2load option to write to flash. This option is very primitive and should probably be supplemented with an option to construct a bootable image to write to flash rather than requiring the user to create his/her own flash boot program. I'm adding this because I think it still may be useful even after a more automated mechanism is in place to write data to flash.
[ -f faddr,haddr,count ] write count bytes of hub data at haddr to flash at faddr
For example, to load a file "foo.bin" that is 0x1000 bytes long to flash at address 0x4000 you can use this command:
p2load foo.bin,e80 -f 4000,e80,1000
You can, of course, repeat this sequence multiple times in a single command. One minor problem with this is that you need to know the size of the file for the -f option. Maybe something like this would be better although it isn't as flexible:
p2load -f foo.bin,4000
This would need to write foo.bin to hub memory but it could automatically use e80 as the buffer address. The user would have to be aware that the data at e80 would be trashed by this operation.
The version of p2load checked into Google Code now supports the following options for running the main program. In the absence of any of these options, the program is started at either 0xe80 or 0x1000 depending on whether -h is specified and in COG 0.
[ -r addr[:param] ] run program in COG 0 from addr with parameter param
[ -r n, ] run program in COG n
[ -r n,addr[:param] ] run program in COG n from addr with parameter param
For example, to run a program in COG 1 you would use this command:
p2load myprog.obj -r 1,
I know the trailing comma is kind of ugly but it lets me continue to support the previous syntax where -r was used to specify the COG image address and parameter to pass to the main program.
Here is another new p2load option to write to flash. This option is very primitive and should probably be supplemented with an option to construct a bootable image to write to flash rather than requiring the user to create his/her own flash boot program. I'm adding this because I think it still may be useful even after a more automated mechanism is in place to write data to flash.
[ -f faddr,haddr,count ] write count bytes of hub data at haddr to flash at faddr
For example, to load a file "foo.bin" that is 0x1000 bytes long to flash at address 0x4000 you can use this command:
p2load foo.bin,e80 -f 4000,e80,1000
You can, of course, repeat this sequence multiple times in a single command. One minor problem with this is that you need to know the size of the file for the -f option. Maybe something like this would be better although it isn't as flexible:
p2load -f foo.bin,4000
This would need to write foo.bin to hub memory but it could automatically use e80 as the buffer address. The user would have to be aware that the data at e80 would be trashed by this operation.
This could be used to solve the binary blobs issue without linking - by reading the cog image to run from flash.
Suggestions:
-e fadd1-faddr2 - erase all 4k blocks in specified range
-d faddr,count - hex dump bytes to stdio (for verification, looking at flash)
I was thinking of and even started writing a flash loader that would essentially do the same thing as p2load. In other words, it could load areas of flash into hub memory and start COGs running images. You could even load up a bunch of COGs and then reload hub memory with your program so that your drivers don't actually waste hub space.
The way the -f option works now it always erases a block just before it starts writing to it. That worked well for propeller-load but I guess it does mean that you can't really write partial blocks.
Also, p2load currently has no way of reading data back from either hub memory or flash. That could be added of course.
Yep. JavaScript is what we need on the PII.
JS runs in your browser.
JS runs on your servers: http://nodejs.org/
JS now runs on your tiny ARM based MCUs: http://www.espruino.com/
Forget C, C++, Java, Ruby, Python. JS is where all the cool kids are now:)
Hmm... have not used it, but as I recall, there was a way of getting the cogid() from within propgcc, so something like:
printf("LMM kernel running on cog %d",cogid());
would be good and if the cogid > 0 then we know it works.
A more thorough test would require binary driver blobs and reserving a screen buffer, as currently I am playing with graphics.
This:
#include <stdio.h>
#include <propeller.h>
int main(void)
{
printf("Launched on COG %d\n", cogid());
return 0;
}
Produces this:
david-betzs-macbook-pro:p2load dbetz$ p2load -b 115200 runtest.elf -r 2, -t
Found propeller version 32 on /dev/cu.usbserial-A800f7XO
Loading 'runtest.elf' at 0x00000e80
..............
[ Entering terminal mode. Type ESC or Control-C to exit. ]
Launched on COG 2
I was thinking of and even started writing a flash loader that would essentially do the same thing as p2load. In other words, it could load areas of flash into hub memory and start COGs running images. You could even load up a bunch of COGs and then reload hub memory with your program so that your drivers don't actually waste hub space.
The way the -f option works now it always erases a block just before it starts writing to it. That worked well for propeller-load but I guess it does mean that you can't really write partial blocks.
Exactly. Once nice thing about these flash chips is that any erased byte ($FF) can be programmed. For whole images, erasing before writing works great, and it is a good way to start. Down the line, programming in a grain as fine as one byte can be extremely useful.
David,
Thanks for the new features in P2Load. I am not ready yet to use them, but they seem really useful.
BTW Is P2Load written in C?
Would you be willing to share the flash code? I may be interested to include it in my debugger (LMM PASM).
Exactly. Once nice thing about these flash chips is that any erased byte ($FF) can be programmed. For whole images, erasing before writing works great, and it is a good way to start. Down the line, programming in a grain as fine as one byte can be extremely useful.
I guess what I'm trying to avoid is complex options to do simple things. This is a loader after all not a filesystem manager. Would you really want to have to do both a -e and a -f every time you want to write something to flash? I'm not saying I won't do it but I'm wondering if this is making the common use cases harder to allow for use cases that may be uncommon. It might be better to have another program do the fine-grained flash access that you're talking about.
Reading hub and flash is definitely something I should add. The only reason I've been stalling on that is that my packet driver doesn't currently work in reverse. It handles packets sent from the PC to the Propeller but not in the reverse direction. There is no reason that can't be done but I just have to find time for it.
I guess what I'm trying to avoid is complex options to do simple things. This is a loader after all not a filesystem manager. Would you really want to have to do both a -e and a -f every time you want to write something to flash? I'm not saying I won't do it but I'm wondering if this is making the common use cases harder to allow for use cases that may be uncommon. It might be better to have another program do the fine-grained flash access that you're talking about.
I like your simple erase-and-load too.
Perhaps that can stay as the default flash write?
Since you already have the ability to erase, perhaps a separate command to erase a range? -e addr1-addr2
A separate way of invoking program-only, with start address and byte count, would allow setting flags etc.
Basically, your current write flash does both erase+program, with extra options, an advanced user could just erase, and just program in finer grains.
Reading hub and flash is definitely something I should add. The only reason I've been stalling on that is that my packet driver doesn't currently work in reverse. It handles packets sent from the PC to the Propeller but not in the reverse direction. There is no reason that can't be done but I just have to find time for it.
Reading back would be very useful - otherwise we might not detect a corrupted write. It could also be used to check the contents of areas of a chip.
Having the capability to erase/read/write independently, in fine grain, would allow storing various resources (fonts, bitmaps, tile data, cog drivers, etc etc) in the flash, and even modifying it without having to re-load and re-flash the whole chip.
You mentioned file systems. I think we will eventually want a flash file system, but we are not there yet. And "bare metal" applications don't really need a file system.
Personally, I am waiting to see how Chip intends to use the flash for not only the boot loader cog, but the "bare metal" application.
So I think my next step will be to implement one more option, let's call it -x for now. What this option will do is write a bootloader to the SPI flash and then write the data that would normally be written to hub memory to flash so that the bootloader can load it to hub memory on reset. In other words, the bootloader will work as though it is executing the original p2load command without the -x option. This should allow you to load up a bunch of stuff into hub memory, start COGs, and finally start your main program out of reset without having to download anything from the PC.
So I think my next step will be to implement one more option, let's call it -x for now. What this option will do is write a bootloader to the SPI flash and then write the data that would normally be written to hub memory to flash so that the bootloader can load it to hub memory on reset. In other words, the bootloader will work as though it is executing the original p2load command without the -x option. This should allow you to load up a bunch of stuff into hub memory, start COGs, and finally start your main program out of reset without having to download anything from the PC.
yes, and no. I've checked it into Google Code so you could pull it from there and build it yourself. My guess is you don't want to have to do that so I'll build a Windows version as soon as I finish this round of updates unless you want to use it right away. It shouldn't take me too long to add that new -x option.
yes, and no. I've checked it into Google Code so you could pull it from there and build it yourself. My guess is you don't want to have to do that so I'll build a Windows version as soon as I finish this round of updates unless you want to use it right away. It shouldn't take me too long to add that new -x option.
No problem. I just updated the file attachment in the top post of that thread. I'll warn you though that the -f option essentially hasn't been tested because I need to add -x or a way to read flash to verify that writing is working. Let me know if you have any problems.
No problem. I just updated the file attachment in the top post of that thread. I'll warn you though that the -f option essentially hasn't been tested because I need to add -x or a way to read flash to verify that writing is working. Let me know if you have any problems.
I'm sorry to say that I have now verified that the -f option will not work in the version I just uploaded. However, I'll update a fixed version as soon as I finish implementing the -w option (new name for what I was calling -x).
I've tested the -r option that lets you start the program in another COG so I'm pretty sure that works. I'll have to do more work on the -f and -w options before they will be usable. Sorry.
Comments
Thanks
[ -r addr[:param] ] run program in COG 0 from addr with parameter param [ -r n, ] run program in COG n [ -r n,addr[:param] ] run program in COG n from addr with parameter paramFor example, to run a program in COG 1 you would use this command: I know the trailing comma is kind of ugly but it lets me continue to support the previous syntax where -r was used to specify the COG image address and parameter to pass to the main program.For example, to load a file "foo.bin" that is 0x1000 bytes long to flash at address 0x4000 you can use this command: You can, of course, repeat this sequence multiple times in a single command. One minor problem with this is that you need to know the size of the file for the -f option. Maybe something like this would be better although it isn't as flexible: This would need to write foo.bin to hub memory but it could automatically use e80 as the buffer address. The user would have to be aware that the data at e80 would be trashed by this operation.
Any thoughts?
printf("LMM kernel running on cog %d",cogid());
would be good
A more thorough test would require binary driver blobs and reserving a screen buffer, as currently I am playing with graphics.
This could be used to solve the binary blobs issue without linking - by reading the cog image to run from flash.
Suggestions:
-e fadd1-faddr2 - erase all 4k blocks in specified range
-d faddr,count - hex dump bytes to stdio (for verification, looking at flash)
The way the -f option works now it always erases a block just before it starts writing to it. That worked well for propeller-load but I guess it does mean that you can't really write partial blocks.
Also, p2load currently has no way of reading data back from either hub memory or flash. That could be added of course.
JS runs in your browser.
JS runs on your servers: http://nodejs.org/
JS now runs on your tiny ARM based MCUs: http://www.espruino.com/
Forget C, C++, Java, Ruby, Python. JS is where all the cool kids are now:)
#include <stdio.h> #include <propeller.h> int main(void) { printf("Launched on COG %d\n", cogid()); return 0; }Produces this:
Sounds great!
Exactly. Once nice thing about these flash chips is that any erased byte ($FF) can be programmed. For whole images, erasing before writing works great, and it is a good way to start. Down the line, programming in a grain as fine as one byte can be extremely useful.
yep - that is useful for verification, also for reading headers (ie version of a cog image) etc
Thanks for the new features in P2Load. I am not ready yet to use them, but they seem really useful.
BTW Is P2Load written in C?
Would you be willing to share the flash code? I may be interested to include it in my debugger (LMM PASM).
Reading hub and flash is definitely something I should add. The only reason I've been stalling on that is that my packet driver doesn't currently work in reverse. It handles packets sent from the PC to the Propeller but not in the reverse direction. There is no reason that can't be done but I just have to find time for it.
You are welcome - I appreciate all the work you are doing.
I like your simple erase-and-load too.
Perhaps that can stay as the default flash write?
Since you already have the ability to erase, perhaps a separate command to erase a range? -e addr1-addr2
A separate way of invoking program-only, with start address and byte count, would allow setting flags etc.
Basically, your current write flash does both erase+program, with extra options, an advanced user could just erase, and just program in finer grains.
Reading back would be very useful - otherwise we might not detect a corrupted write. It could also be used to check the contents of areas of a chip.
Having the capability to erase/read/write independently, in fine grain, would allow storing various resources (fonts, bitmaps, tile data, cog drivers, etc etc) in the flash, and even modifying it without having to re-load and re-flash the whole chip.
You mentioned file systems. I think we will eventually want a flash file system, but we are not there yet. And "bare metal" applications don't really need a file system.
Personally, I am waiting to see how Chip intends to use the flash for not only the boot loader cog, but the "bare metal" application.
[ -f file,faddr ] write contents of file to flash at faddr [ -f faddr,haddr,count ] write count bytes of hub data at haddr to flash at faddrSo to write the file "foo.bin" to 0x10000 in flash you would use:
Also like msg#42, missed it before.
Much appreciated.
Thanks
Nice idea.
-G(oto)
Have You uploaded it ?
Yes
I want Windows Ver. in this thread http://forums.parallax.com/showthread.php/144384-p2load-A-Loader-for-the-Propeller-II
Thanks
Will do.
Thanks
Anyway, I finished writing the -w code but it isn't working yet and I'm not going to be able to debug in tonight. Sorry!
Both - Thanks