Understood. PNut is currently saving a raw binary image file if you just use "filename -c".
I will check again -- this didn't seem to be the case with a test I ran yesterday.
I didn't write the uSD loader that is in the P2 ROM, so I am not sure how it works, but my understanding is that if you put a binary file on a formatted SD card called "_BOOT_P2.BIX", it will boot from that.
That only works when the SD card that is comingled with the Flash is attached; I cannot use that SD card in my apps because I am using the the Flash for program configuration values. It was a bad idea to comingle the SD and Flash data lines they way they are -- they made one of the other device useless over the savings of a single pin. Not at all ironic that the person who forced this issue is not long participating in the Propeller community....
Ideally, it would be nice if we had a unified, dual-device driver that would allow us to access files on the Edge Flash and on the Edge uSD at the same time. Until that time, though, I'm using a separate uSD for my files (WAVs, etc.).
I downloaded a simple program to Flash from the latest version of PNut. I used the CLI to create a binary version of the downloaded code (used -c). I then ran a Flash reader in RAM to look at the contents and I found they do not match. I'm not sure why. For the moment I'm assuming I did something wrong -- will keep checking.
@JonnyMac said:
I downloaded a simple program to Flash from the latest version of PNut. I used the CLI to create a binary version of the downloaded code (used -c). I then ran a Flash reader in RAM to look at the contents and I found they do not match. I'm not sure why. For the moment I'm assuming I did something wrong -- will keep checking.
What winds up in the flash is the application (the binary) prepended with the second-stage-flash loader which runs after the ROM's first-stage-flash loader. I will have to make a new command to output this version of the application. When you download with flash, the flash programmer is prepended with the second-stage-flash-loader+binary blob.
I will have to make a new command to output this version of the application. When you download with flash, the flash programmer is prepended with the second-stage-flash-loader+binary blob.
Yes. Please.
@Rayman said:
@cgracey That would be great. Nice to have something that one can just copy to flash and work.
I have made it work as Ray suggests, but I had to do post-processing of the previous binary file before I could copy it from an SD into the Flash to run. In the past I suggested the extension be P2I so that we know it's a bootable P2 image file.
They're all bootable. Just that the EEPROM method, alone, also needs the staged loader. Chip could have chosen it to be a fixed length 512 kB, filling all of hubRAM, but went with the staged loader approach instead. Much faster iterating on updating the Flash chip this way.
Cluso's SD boot method allows a direct binary, without staging, same as serial loading. This is due to the complexities of reading an actual file at boot time. If you can manage that then it's nothing to also handle variable file size as well.
Was just wondering if multitasking could be used for debugging …. Maybe a second task could report variable values over serial and then wait for response to continue …
I frequently use a secondary Spin cog to report values to a terminal for debugging. I don't know that the new multitasking features would be useful here, but I'm interested in your ideas. I really wish there were a P2 DEBUG window that was as easy to use as PST. I guess tasks could be used to update portions of an output instead of doing the whole thing in one go.
@JonnyMac said:
I really which there were a P2 DEBUG window that was as easy to use as PST. I guess tasks could be used to update portions of an output instead of doing the whole thing in one go.
I use loadp2 after compiling with Pnut -cd from a shell. Same as I do with Flexspin. I've got a single line in the shell's history for each combination, eg:
Comments
I will check again -- this didn't seem to be the case with a test I ran yesterday.
That only works when the SD card that is comingled with the Flash is attached; I cannot use that SD card in my apps because I am using the the Flash for program configuration values. It was a bad idea to comingle the SD and Flash data lines they way they are -- they made one of the other device useless over the savings of a single pin. Not at all ironic that the person who forced this issue is not long participating in the Propeller community....
Ideally, it would be nice if we had a unified, dual-device driver that would allow us to access files on the Edge Flash and on the Edge uSD at the same time. Until that time, though, I'm using a separate uSD for my files (WAVs, etc.).
Not from Propeller Tool, no. I went down this road a long time ago. It does save a binary image, but not a clean, ready to boot image.
Ah, OK. I was wrong. The only difference between the Binary and Flash is that the Flash file is zero filled the rest of the 512k.
I downloaded a simple program to Flash from the latest version of PNut. I used the CLI to create a binary version of the downloaded code (used -c). I then ran a Flash reader in RAM to look at the contents and I found they do not match. I'm not sure why. For the moment I'm assuming I did something wrong -- will keep checking.
What winds up in the flash is the application (the binary) prepended with the second-stage-flash loader which runs after the ROM's first-stage-flash loader. I will have to make a new command to output this version of the application. When you download with flash, the flash programmer is prepended with the second-stage-flash-loader+binary blob.
@cgracey That would be great. Nice to have something that one can just copy to flash and work.
Yes. Please.
I have made it work as Ray suggests, but I had to do post-processing of the previous binary file before I could copy it from an SD into the Flash to run. In the past I suggested the extension be P2I so that we know it's a bootable P2 image file.
Thanks, Chip.
They're all bootable. Just that the EEPROM method, alone, also needs the staged loader. Chip could have chosen it to be a fixed length 512 kB, filling all of hubRAM, but went with the staged loader approach instead. Much faster iterating on updating the Flash chip this way.
Cluso's SD boot method allows a direct binary, without staging, same as serial loading. This is due to the complexities of reading an actual file at boot time. If you can manage that then it's nothing to also handle variable file size as well.
Was just wondering if multitasking could be used for debugging …. Maybe a second task could report variable values over serial and then wait for response to continue …
I frequently use a secondary Spin cog to report values to a terminal for debugging. I don't know that the new multitasking features would be useful here, but I'm interested in your ideas. I really wish there were a P2 DEBUG window that was as easy to use as PST. I guess tasks could be used to update portions of an output instead of doing the whole thing in one go.
I use loadp2 after compiling with Pnut -cd from a shell. Same as I do with Flexspin. I've got a single line in the shell's history for each combination, eg:
filename=test_setqrdlong; wine ~/hoard/coding/bin/PNut_v39.exe ${filename}.spin2 -cd; loadp2 ${filename}.bin -p /dev/serial/by-id/usb-Parallax_Inc_Propeller_P2-ES_EVAL_P23YOO42-if00-port0 -t -b 2000000I suppose I should go one step further and save them as a script each, with "filename" as an argument.