Yes, I'm not sure if debuggers will actually need the whole 16K, but since it's mapped and protected in an all-or-nothing way I thought I would leave it all for now. Obviously in "production" we may want to revisit that but I expect that for now people may find interesting uses for 16KB of hub memory that the python interpreter leaves alone.
not sure if this is the right place - but I tried github first (no issues available) and even forked the repository to try and create a PR - but the step2.spin was not found in the repo (or I was to stupid).
I encountered a few hickups on my path to micropython on P2, and wanted to report them so the experience becomes better in the future. I followed the instructions on
First thing: I have the P2 eval board, and while I managed (I think, see below) I found the dip-switch instructions for the eval-board less clear than the ones for the P2 edge. I now put the settings to OFF ON OFF OFF. Maybe it's possible to also have a foto for P2 eval?
Then I discovered a small bug in step2.spin: it only works on systems with case-insensitive filesystems. Windows and macOS. But I'm on Linux most of the time, and there the case needs to be correct. So it's just a matter of replacing the contents of step2.spin with
dat orgh
file "P2uP_1_0_121.binary"
Then I hit a snag with the autodetection of the P2 port in flexprop GUI. It worked for step1.spin, but not two. So I had to manually figure out the port and flash. No idea why but maybe that's something that can either be sorted out or mentioned in the instructions.
Last but not least: I now get a uPy repl - but read-only Both in flexprop GUI as well as screen. I will try mu alpha next, however I'd be surprised if there was any difference. After all I have experience with uPy on other platforms (ESP*), and there screen /dev/ttyUSB0 115200 works just fine.
Any ideas as to what could be wrong here?
Here is my current repl:
#########################
# Native P2 MicroPython #
# Heap Size: 128 kB #
#########################
Heap ptr = 0x434d9, Stack ptr = 0x7f760
MicroPython v1.13-8-g4b51b34d8-dirty on 2020-10-28; P2 BOARD with Propeller2 P2X8C4M64P
Type "help()" for more information.
>>>
From memory, there is a $8000 offset in the config of the loader of FlexGui 5, that wasn't there in version 4. If you take out the $8000 offset you should have an interactive repl
Thanks for the feedback about other issues, we'll update the instructions
EDIT: It seems latest macOS (Big Sur) is indeed case-insensitive... At least, from the UNIX level (in the Terminal, "file.txt" is the same as "FILE.TXT")...
First thing: I have the P2 eval board, and while I managed (I think, see below) I found the dip-switch instructions for the eval-board less clear than the ones for the P2 edge. I now put the settings to OFF ON OFF OFF. Maybe it's possible to also have a foto for P2 eval?
Then I discovered a small bug in step2.spin: it only works on systems with case-insensitive filesystems. Windows and macOS. But I'm on Linux most of the time, and there the case needs to be correct. So it's just a matter of replacing the contents of step2.spin with
dat orgh
file "P2uP_1_0_121.binary"
Then I hit a snag with the autodetection of the P2 port in flexprop GUI. It worked for step1.spin, but not two. So I had to manually figure out the port and flash. No idea why but maybe that's something that can either be sorted out or mentioned in the instructions.
Last but not least: I now get a uPy repl - but read-only Both in flexprop GUI as well as screen. I will try mu alpha next, however I'd be surprised if there was any difference. After all I have experience with uPy on other platforms (ESP*), and there screen /dev/ttyUSB0 115200 works just fine.
Any ideas as to what could be wrong here?
Here is my current repl:
#########################
# Native P2 MicroPython #
# Heap Size: 128 kB #
#########################
Heap ptr = 0x434d9, Stack ptr = 0x7f760
MicroPython v1.13-8-g4b51b34d8-dirty on 2020-10-28; P2 BOARD with Propeller2 P2X8C4M64P
Type "help()" for more information.
>>>
I'd like to get the instructions on this page updated to be correct and appreciate your comments here. Are these correct updates @Tubular, based on what was posted:
(1) Add in photo for P2 Evaluation Board with correct DIP switch setting OFF-ON-OFF-OFF
I'm not sure about the Linux part and FlexProp, but could certainly get this current for our Windows users. If somebody can sort this out for Linux and document it for us, I'll very happily add those instructions too @__deets__ . Thanks,
I've updated the P2NMP113.zip in the team-oz Github
the step1 and step2 spin2 files now include text for any setting changes, eg for spin2
'step2.spin2
'P2 Native MicroPython binary
'Perform this step after completing Step1, while led P56 is flashing
' Propeller Tool: Press F11 to send this to flash
' FlexPropGui: Change menu Commands/Configure Commands/Flash Command to
' cmd.exe /c start "Propeller Output %p" "%D/bin/loadp2" %P -b%r "@0=%B" -t -k
' then Control-E to compile-and-flash binary
dat orgh
file "P2uP_1_0_124.binary"
I've also update the binary from build 121 to 124
Let me know if there are any problems with this
thanks
Lachlan
Are you sure that works? Loading at offset 0 would cause the micropython binary to overwrite the flash program. I could see it running micropython immediately, but I don't think it would write into flash.
If you're not trying to write to flash, then the ordinary default loadp2 command line has no @8000 offset, so it should be fine.
Last but not least: I now get a uPy repl - but read-only Both in flexprop GUI as well as screen. I will try mu alpha next, however I'd be surprised if there was any difference. After all I have experience with uPy on other platforms (ESP*), and there screen /dev/ttyUSB0 115200 works just fine.
Any ideas as to what could be wrong here?
I have basically the same result, running flexprop on macOS (Big Sur)... After running through the step1 & step 2 .spin compile & load RAM & upload to ROM processes, I get the REPL as you did (tried it with a @0 offset as well). When I type, I can see that the P2Eval's USB LED lights up for each character, so I know that the text is being received by the P2. But... the REPL does not respond. Tried Mu-Editor (Alpha version as required) and get the same response. Tried my normal terminal app (CoolTerm) and it also displays the initial REPL display, but no response from keyboard input.
What I see:
1) the install process seems to complete
2) REPL is able to send its initial text back to a terminal
3) REPL does not respond to any input from the terminal
thank you folks for the plenty and helpful replies. Shortly after posting (and w/o getting some notifications in my mailbox ) I went on a vacation, so I couldn't check until now.
@Tubular I can confirm that the two files you provided above did in fact create a working REPL! Thanks!
And some insights into the macOS case sensitivity: since I owned macs (10.1 or 10.2 or so) they have been case preserving, but not case sensitive. You *can* make this happen, HFS+ supports this. I needed that to cross-compile Linux kernels on mac, via a sparse disk image formatted that way. Don't try converting your main volume to case sensitive HFS+though, there be dragons.
These days my main machine is a beefy Linux PC. So feel free to ping me if you need any verification on that platform!
And I stumbled about another hurdle: I can access pins (56, HOORAY!)
I then tried to save code (I want to support a MPU6050, and that's a bit too much code to just put into the REPL). However this wouldn't work with the error-message No FLASH detected!
I tried looking into the github repository for clues. The search of github didn't result in anything, but the branch p2native looks promising. Trying to check this out I stumbled once more: the checked in .gif and .zip files are considered text by git, and automatically translated to LF, thus changing them. It then refuses to checkout another branch, as that would mean discarding changes itself just created. Stashing doesn't help.
I have to admit that the whole auto-translation of line-endings is confusing to me as well, but smart people in my company sorted that one out (and actually enforce it via git hooks) - you need to declare the file endings to be binary explicit in .gitattributes.
So I added
.gif binary
.zip binary
to the repo, committed, and then ran
git checkout-index --force --all
This solved that problem, and I would suggest you do the same. This issue can also crop up on mac, btw. A customer and I had to painstakingly convert their windows-born repository the other day.
But then I still didn't find the No FLASH detected message - so I'm stuck. Any pointers?
Hmm we saw the same thing at one stage and OzProp tweaked the timing on the flash programming code (from memory). However i'm not sure whether that code is in v124 or not, and ozprop is away for a bit
I'll check it out but its going to be a day or two. If i BTW what P2 Board are you using?
@Tubular ok so I tried using it. Downloaded, hooked up my P2 eval.
With the dip switches set to off/on/off/off (on for flash) I get "Could not find a P2 on port /dev/ttyUSB0". Where it in fact resides - I can screen into it and get the uPy REPL.
With the dip set to "on/on/off/off" (usb res + flash) I get something. There it says "entering terminal mode" and then for a while nothing happens, until some stray binary characters appear (LEDs on the board flicker). But it seems the REPL is still the old one (MicroPython v1.13-8-g4b51b34d8-dirty on 2020-10-28; P2 BOARD with Propeller2 P2X8C4M64P)
I suspect that opening MP message will be the same with any version 1.13
Let me retrace my steps and see what version actually did the flash correction on my system. I'm also using P2 eval, but using it with Windows and therefore Pnut/Propeller Tool.
There's also a worst-case load the image from terminal at 115200 baud option that we tested, should things get desperate (in case its something to do with loading from FlexPropGui's loadp2)
I retraced my steps loading binary versions 1.21 and 1.24 successfully from Propeller Tool 2.4 and FlexPropGui 5.0.0, and no matter what I can always do a `files (backtick shared with tilde key) and see the flash files on the P2 Eval just fine. In other words everything seems to be working fine for me. Note that I change the offset to the flash loader when in FlexPropGui, to remove the $8000 offset, as listed in the instructions
However whats slightly unnerving is that I couldn't reproduce a situation I know that I had some months back, where I also was unable to see flash (causing OzProp to make some timing changes to the flash writing routines)
So, where to go from here,
1. I can try this with a glob top p2eval board (ie different p2eval), but not until much later today
2. We could nicely ask @dgately to try typing `files on his setup, to see whether its working for him
3. Check for any subtle differences between the P2 Eval Rev B that we use here, vs P2 Eval Rev C more widely available. eg is it exactly the same flash chip marked 25Q128JVSM (appears to be)
I wonder whether the 'No FLASH detected' message means what it says, or whether it really can see the flash but not any files on it.
In testing all this I'm reminded of the importance of having a 'null' program that can be written to flash and just turns on a led, in between trials, to make sure each step really is doing what you think it is
Sorry you're encountering issues, we'll get to the bottom of it...
Note that I change the offset to the flash loader when in FlexPropGui, to remove the $8000 offset, as listed in the instructions
I don't understand how that can work, because the flash loader binary is in fact looking at memory location $8000 for the data (regardless of what you put on the loadp2 command line).
Are you actually trying to use FlexProp to program the flash?
Also, using a 'null' program to erase flash in between, to make sure it really is FlexProp doing its job, rather than just booting from a previous successful flash write
Yes, using version 5.0.0 of FlexProp Gui tool. I should perhaps try latest but I don't think much has changed in this area
Previously, I was using version 4.0.6 successfully
The image runs and I can interact seemingly fine with P2 NMP, but is it possible something is getting truncated? The binary image is 480kB
Something doesn't add up... The flash loader program looks in HUB RAM at $8000 for the size of the program to flash, and writes data starting from $8004. Those values are hard coded, so changing them on the command line will not work. The source code is in loadp2/board/P2ES_flashloader.spin2 if you want to look for yourself. I don't know why it seems to be working for you, but it doesn't work for me and I don't think it will work in general. I can't see any way that it could .
I retraced my steps loading binary versions 1.21 and 1.24 successfully from Propeller Tool 2.4 and FlexPropGui 5.0.0, and no matter what I can always do a `files (backtick shared with tilde key) and see the flash files on the P2 Eval just fine. In other words everything seems to be working fine for me. Note that I change the offset to the flash loader when in FlexPropGui, to remove the $8000 offset, as listed in the instructions
However whats slightly unnerving is that I couldn't reproduce a situation I know that I had some months back, where I also was unable to see flash (causing OzProp to make some timing changes to the flash writing routines)
So, where to go from here,
1. I can try this with a glob top p2eval board (ie different p2eval), but not until much later today
2. We could nicely ask @dgately to try typing `files on his setup, to see whether its working for him
$ /Users/altergator/flexprop/bin/loadp2 -b115200 /Users/altergator/source/p2-native-micropython/P2NMP113/Flash_loader_1.2.binary -k -T; osascript -e 'tell application "Wish" to activate'; exit 0
( Entering terminal mode. Press Ctrl-] to exit. )
#########################
# Native P2 MicroPython #
# Heap Size: 128 kB #
#########################
Heap ptr = 0x434d9, Stack ptr = 0x7f760
MicroPython v1.13-8-g4b51b34d8-dirty on 2020-10-28; P2 BOARD with Propeller2 P2X8C4M64P
Type "help()" for more information.
>>>
>>> `files
No FLASH detected!
I haven't been following this thread for a while. Is your MicroPython interpreter now using FlexProp? How did you get around the makefile build model that assumes separate compilation of C files?
I fired up my JonnyMac/P2 edge combo which only had 3 files in flash. I deleted these. Now it says 'No files in SPI Flash.', different to the 'No FLASH detected' message. So at least it reports accurately
I wonder whether some kind of formatting or flash preparation is needed?
I have some dip8 winbond flash chips, I might disable the onboard flash and hook these in manually on the JonnyMac breadboard, to better understand it. All the boards here have files in flash already.
This'll need to be tomorrow, though.
I haven't been following this thread for a while. Is your MicroPython interpreter now using FlexProp? How did you get around the makefile build model that assumes separate compilation of C files?
P2 native MicroPython is still built using P2gcc.
Once compiled (v1.13 by Rogloh), the theory is that the 480kB binary payload can be loaded into a P2 board's flash memory, using either Propeller Tool, Pnut, or FlexPropGui
I haven't been following this thread for a while. Is your MicroPython interpreter now using FlexProp? How did you get around the makefile build model that assumes separate compilation of C files?
P2 native MicroPython is still built using P2gcc.
Once compiled (v1.13 by Rogloh), the theory is that the 480kB binary payload can be loaded into a P2 board's flash memory, using either Propeller Tool, Pnut, or FlexPropGui
I see. I was hoping someone had come up with a good way to use the standard Makefile build environment with FlexProp.
Comments
not sure if this is the right place - but I tried github first (no issues available) and even forked the repository to try and create a PR - but the step2.spin was not found in the repo (or I was to stupid).
I encountered a few hickups on my path to micropython on P2, and wanted to report them so the experience becomes better in the future. I followed the instructions on
https://www.parallax.com/propeller-2/get-started/micropython/
First thing: I have the P2 eval board, and while I managed (I think, see below) I found the dip-switch instructions for the eval-board less clear than the ones for the P2 edge. I now put the settings to OFF ON OFF OFF. Maybe it's possible to also have a foto for P2 eval?
Then I discovered a small bug in step2.spin: it only works on systems with case-insensitive filesystems. Windows and macOS. But I'm on Linux most of the time, and there the case needs to be correct. So it's just a matter of replacing the contents of step2.spin with
dat orgh file "P2uP_1_0_121.binary"Then I hit a snag with the autodetection of the P2 port in flexprop GUI. It worked for step1.spin, but not two. So I had to manually figure out the port and flash. No idea why but maybe that's something that can either be sorted out or mentioned in the instructions.
Last but not least: I now get a uPy repl - but read-only
Any ideas as to what could be wrong here?
Here is my current repl:
Thanks for the feedback about other issues, we'll update the instructions
I'd like to get the instructions on this page updated to be correct and appreciate your comments here. Are these correct updates @Tubular, based on what was posted:
(1) Add in photo for P2 Evaluation Board with correct DIP switch setting OFF-ON-OFF-OFF
I'm not sure about the Linux part and FlexProp, but could certainly get this current for our Windows users. If somebody can sort this out for Linux and document it for us, I'll very happily add those instructions too @__deets__ . Thanks,
Ken Gracey
4.0.6 - Default works
cmd.exe /c start "Propeller Output %p" "%D/bin/loadp2" %P -b230400 "%B" "-9%b" -q -k
5.0.0 - Default doesn't work.
cmd.exe /c start "Propeller Output %p" "%D/bin/loadp2" %P -b%r "@0=%F,@8000+%B" -t -k
doesn't work. locked up. no 4 escapes
5.0.0 fixed by removing offset
cmd.exe /c start "Propeller Output %p" "%D/bin/loadp2" %P -b%r "@0=%B" -t -k
the step1 and step2 spin2 files now include text for any setting changes, eg for spin2
'step2.spin2 'P2 Native MicroPython binary 'Perform this step after completing Step1, while led P56 is flashing ' Propeller Tool: Press F11 to send this to flash ' FlexPropGui: Change menu Commands/Configure Commands/Flash Command to ' cmd.exe /c start "Propeller Output %p" "%D/bin/loadp2" %P -b%r "@0=%B" -t -k ' then Control-E to compile-and-flash binary dat orgh file "P2uP_1_0_124.binary"I've also update the binary from build 121 to 124
Let me know if there are any problems with this
thanks
Lachlan
Are you sure that works? Loading at offset 0 would cause the micropython binary to overwrite the flash program. I could see it running micropython immediately, but I don't think it would write into flash.
If you're not trying to write to flash, then the ordinary default loadp2 command line has no @8000 offset, so it should be fine.
I have basically the same result, running flexprop on macOS (Big Sur)... After running through the step1 & step 2 .spin compile & load RAM & upload to ROM processes, I get the REPL as you did (tried it with a @0 offset as well). When I type, I can see that the P2Eval's USB LED lights up for each character, so I know that the text is being received by the P2. But... the REPL does not respond. Tried Mu-Editor (Alpha version as required) and get the same response. Tried my normal terminal app (CoolTerm) and it also displays the initial REPL display, but no response from keyboard input.
What I see:
1) the install process seems to complete
2) REPL is able to send its initial text back to a terminal
3) REPL does not respond to any input from the terminal
dgately
In the interim here's a "step2" replacement that can be Run (Control-R) from within FlexProp (as opposed to control-E binary load inside Flexprop)
I went back and retraced some steps, and it appears I was fooled by a previous image in flash, because it isn't working for me now either
Let me know how you go with attached files
dgately
thank you folks for the plenty and helpful replies. Shortly after posting (and w/o getting some notifications in my mailbox
@Tubular I can confirm that the two files you provided above did in fact create a working REPL! Thanks!
And some insights into the macOS case sensitivity: since I owned macs (10.1 or 10.2 or so) they have been case preserving, but not case sensitive. You *can* make this happen, HFS+ supports this. I needed that to cross-compile Linux kernels on mac, via a sparse disk image formatted that way. Don't try converting your main volume to case sensitive HFS+though, there be dragons.
These days my main machine is a beefy Linux PC. So feel free to ping me if you need any verification on that platform!
I then tried to save code (I want to support a MPU6050, and that's a bit too much code to just put into the REPL). However this wouldn't work with the error-message No FLASH detected!
I tried looking into the github repository for clues. The search of github didn't result in anything, but the branch p2native looks promising. Trying to check this out I stumbled once more: the checked in .gif and .zip files are considered text by git, and automatically translated to LF, thus changing them. It then refuses to checkout another branch, as that would mean discarding changes itself just created. Stashing doesn't help.
I have to admit that the whole auto-translation of line-endings is confusing to me as well, but smart people in my company sorted that one out (and actually enforce it via git hooks) - you need to declare the file endings to be binary explicit in .gitattributes.
So I added
.gif binary
.zip binary
to the repo, committed, and then ran
git checkout-index --force --all
This solved that problem, and I would suggest you do the same. This issue can also crop up on mac, btw. A customer and I had to painstakingly convert their windows-born repository the other day.
But then I still didn't find the No FLASH detected message - so I'm stuck. Any pointers?
I'll check it out but its going to be a day or two. If i BTW what P2 Board are you using?
This is the latest I could find, see if it fixes the issue for you
With the dip switches set to off/on/off/off (on for flash) I get "Could not find a P2 on port /dev/ttyUSB0". Where it in fact resides - I can screen into it and get the uPy REPL.
With the dip set to "on/on/off/off" (usb res + flash) I get something. There it says "entering terminal mode" and then for a while nothing happens, until some stray binary characters appear (LEDs on the board flicker). But it seems the REPL is still the old one (MicroPython v1.13-8-g4b51b34d8-dirty on 2020-10-28; P2 BOARD with Propeller2 P2X8C4M64P)
Any clues to what I can/should do here?
Let me retrace my steps and see what version actually did the flash correction on my system. I'm also using P2 eval, but using it with Windows and therefore Pnut/Propeller Tool.
There's also a worst-case load the image from terminal at 115200 baud option that we tested, should things get desperate (in case its something to do with loading from FlexPropGui's loadp2)
However whats slightly unnerving is that I couldn't reproduce a situation I know that I had some months back, where I also was unable to see flash (causing OzProp to make some timing changes to the flash writing routines)
So, where to go from here,
1. I can try this with a glob top p2eval board (ie different p2eval), but not until much later today
2. We could nicely ask @dgately to try typing `files on his setup, to see whether its working for him
3. Check for any subtle differences between the P2 Eval Rev B that we use here, vs P2 Eval Rev C more widely available. eg is it exactly the same flash chip marked 25Q128JVSM (appears to be)
I wonder whether the 'No FLASH detected' message means what it says, or whether it really can see the flash but not any files on it.
In testing all this I'm reminded of the importance of having a 'null' program that can be written to flash and just turns on a led, in between trials, to make sure each step really is doing what you think it is
Sorry you're encountering issues, we'll get to the bottom of it...
Are you actually trying to use FlexProp to program the flash?
Previously, I was using version 4.0.6 successfully
The image runs and I can interact seemingly fine with P2 NMP, but is it possible something is getting truncated? The binary image is 480kB
Something doesn't add up... The flash loader program looks in HUB RAM at $8000 for the size of the program to flash, and writes data starting from $8004. Those values are hard coded, so changing them on the command line will not work. The source code is in loadp2/board/P2ES_flashloader.spin2 if you want to look for yourself. I don't know why it seems to be working for you, but it doesn't work for me and I don't think it will work in general. I can't see any way that it could
I fired up my JonnyMac/P2 edge combo which only had 3 files in flash. I deleted these. Now it says 'No files in SPI Flash.', different to the 'No FLASH detected' message. So at least it reports accurately
I wonder whether some kind of formatting or flash preparation is needed?
I have some dip8 winbond flash chips, I might disable the onboard flash and hook these in manually on the JonnyMac breadboard, to better understand it. All the boards here have files in flash already.
This'll need to be tomorrow, though.
P2 native MicroPython is still built using P2gcc.
Once compiled (v1.13 by Rogloh), the theory is that the 480kB binary payload can be loaded into a P2 board's flash memory, using either Propeller Tool, Pnut, or FlexPropGui