Ok, interesting. Yes its normal for the P2 to reset when exiting the terminal programs. And yes this makes me wonder how things worked going from step1 to step2 in flexpropgui, previously, when the terminal is closed in between those steps
Most of the dev work around this was using flexpropgui 4.0.6 I believe, which I still have set up. Its the weekend here now, but I should be able to get into work at some point and test things again with that version.
Sometimes we break DTR by using a 4 pin stackthru connector, and bending the reset pin out of the way slightly, so only RX TX and GND carry through. But I don't recall having to do that with P2 native MicroPython, so I'll go over it again
Its that big to give 128kB of working memory once its all fired up. It can be less (its set in the MP config file), but thats a round power of 2 that (just) fits and works
@Tubular said:
Its that big to give 128kB of working memory once its all fired up. It can be less (its set in the MP config file), but thats a round power of 2 that (just) fits and works
Whats this alleged 496K limit about @Wuerfel_21 ?
If the image was rebuilt to put the heap at the end of the binary, the problem would be avoided.
Ok, sounds like there's a list of things that need nailing down to make this all easier to get up and running. We need to improve the docs, support the new Led location on the edge, test with Linux and Mac, test all prop plug revisions, test and debunk a few myths in the software end (busted/plausible/confirmed)
I do know however that zip file works, because we did a fair bit of development with it a few (4~5) years back, and built a fair bit on top of the same (editors, flash file system, video drivers, debug etc). I did do a fair bit of 64 GB SDXC card testing perhaps 3 years ago (results are here somewhere), but perhaps its time to revisit all this to make the experience smoother. The problem that time is particularly short this month
We need to get @pedward running asap, then make the above test and documentation improvements before too long
@Tubular said:
Its that big to give 128kB of working memory once its all fired up. It can be less (its set in the MP config file), but thats a round power of 2 that (just) fits and works
Whats this alleged 496K limit about @Wuerfel_21 ?
If the image was rebuilt to put the heap at the end of the binary, the problem would be avoided.
Micropython puts the heap in 'third quarter' for whatever reason.
You can see a visual representation of all-of-hub on the lower screen in this vid from around 6m14s https://www.youtube.com/watch?v=c3Xa-DOU0D0&t=374s
That factorial demo chews up almost all the heap. The white flashes represent changes being made in that sector of hub ram (from memory each character represents 512 bytes, but don't hold me to that). Disclaimer - technically this is using Eric's early risc-v MP image, before we moved to P2 Native MicroPython, the hub layout would be very similar
I'll be honest, after being out of the Prop universe for about 8 years, some things have improved (like the fact SD can boot, 2Mbit download, large on-board flash, faster boot times). Some things have stayed the same (Windows centric end-user focus). Some things appear to have not aged well. The Rpi Pico has a drag-n-drop firmware loader that behaves like a disk. They have some issues with their docs too, not being up to date with current uP changes, having gaps, etc.
Overall, the P2 promises to be a good solution, if expensive. My disappointment comes from Python not being treated as a Tier 1 language. It should be seamless to get running.
Python is a language which has become universal, even though it's relatively slow, because it's easy to use, widely supported, and many people have learned it. At work I will choose to write in Python first, knowing that C or other languages are considered "esoteric" and thus are harder for people to understand and maintain.
I'm disappointed that old, unsigned, drivers are distributed with the latest Proptool. Even with the right drivers it seems to choke on code downloads.
I'm running, near as I can tell, the same laptop that Ken uses, but my vanilla install doesn't work correctly.
I am rather impressed with the cross platform Linux/Unix support, but I'm a little disappointed that the SimpleIDE didn't live on. It was rather polished, but I think something got in the way. I wrote Unicode support for the terminal for that.
Huh, I would've thought Windoze would have a default built-in comport driver these days. Not needing anything shipped with Proptool. That's been the norm on Linux for so long I'd forgotten it was a thing.
PS: There is talk that Proptool is effectively depreciated and only on life-support from now. Chip is wanting to make the tools completely cross-platform but still has some decisions to make as to what path exactly. Link - https://forums.parallax.com/discussion/comment/1551187/#Comment_1551187
There is an NPN transistor in the PropPlug that is used to pull the reset line low. This transistor is capacitivly coupled to the DTR line. A change is state of DTR can cause a reset, even when you don't want that to happen.
I'm disappointed that old, unsigned, drivers are distributed with the latest Proptool. Even with the right drivers it seems to choke on code downloads.
@evanh said:
Huh, I would've thought Windoze would have a default built-in comport driver these days. Not needing anything shipped with Proptool. That's been the norm on Linux for so long I'd forgotten it was a thing.
It does. Anything vaguely normal should auto-download the driver from Windows Update. And I'm pretty sure the driver that comes with proptool is signed. Unsigned drivers have not worked without major workaround ever since vista. Getting the security confirmation dialog does not mean the driver is unsigned. Having to enable test signing mode from the terminal, rebooting and having a permanent watermark on your desktop means the driver is unsigned. And yes, linux generally ships with every possible driver preinstalled and somehow still takes less disk space than Win11.
Overall, the P2 promises to be a good solution, if expensive. My disappointment comes from Python not being treated as a Tier 1 language. It should be seamless to get running.
Python is a language which has become universal, even though it's relatively slow, because it's easy to use, widely supported, and many people have learned it. At work I will choose to write in Python first, knowing that C or other languages are considered "esoteric" and thus are harder for people to understand and maintain.
Well that's a them problem. Having a Hammer doesn't mean that every problem is a nail. Why splurge on a high-performance MCU with special acceleration features and then load it up with a slow script language runtime that can't really take advantage of the hardware? It makes no sense (unless the interactive scripting ability is the point of the project). That's why effort isn't being poured in that avenue. (Also, the current micropython builds are based either on RISC-V emulation or on a hacky translation of P1 GCC output to P2, which means the performance is a lot worse than it needs to be and promoting it in that state might make the chip look weak or something)
Either a Qt based application (like SimpleIDE) or Electron (Chromium + Javascript) would be the 2 candidates for a cross-platform tool.
Electron is what vscode and Slack use, it makes it easier to attract developers because Javascript.
Qt is faster but requires you to find C++ programmers.
We have a VSC plugin and solid CLI tools. Let's stop reinventing the text editor wheel. It has been tried at least 5 times and it never worked out.
We have a VSC plugin and solid CLI tools. Let's stop reinventing the text editor wheel. It has been tried at least 5 times and it never worked out.
This should be promoted at the entry point page for every Propeller 2 page on the site. If there really is seamless vscode support, that should be what all effort is put behind.
Well that's a them problem. Having a Hammer doesn't mean that every problem is a nail. Why splurge on a high-performance MCU with special acceleration features and then load it up with a slow script language runtime that can't really take advantage of the hardware? It makes no sense (unless the interactive scripting ability is the point of the project). That's why effort isn't being poured in that avenue. (Also, the current micropython builds are based either on RISC-V emulation or on a hacky translation of P1 GCC output to P2, which means the performance is a lot worse than it needs to be and promoting it in that state might make the chip look weak or something)
Do you realize that you are literally painting anyone under the age of 40 with the same brush? Python continues to be either the most popular programming language, or trades blows for the top 3, year over year.
I do understand the value in all the whiz-bang capabilities of the P2, but there are times when ultimate speed isn't necessary. If you need more speed and features, you could always write spin/pasm modules to run in other cogs.
Getting new people to adopt the P2 requires getting it into their hands and getting them coding in as little time as possible. Micropython makes the choice of processor even less relevant, but 64 io pins is a big draw and people will see Python as a gateway.
Do you realize that you are literally painting anyone under the age of 40 with the same brush? Python continues to be either the most popular programming language, or trades blows for the top 3, year over year.
If anyone is painting with such brushes, it must be you. I don't know, I'm 22 and I write a script language when a script language is needed (I prefer ruby over python but who cares), C when C is needed, asm when asm is needed. It's not that hard to pick up a language that's more useful to a certain end, especially if you're young and the stuffing in your head is fluffy still. They're all C with different sprinkles anyways (Excluding FORTH, Prolog, Haskell and friends). The idea that that isn't the case leads us down dark godless paths, such as Java VMs on credit cards.
If anyone is painting with such brushes, it must be you. I don't know, I'm 22 and I write a script language when a script language is needed (I prefer ruby over python but who cares), C when C is needed, asm when asm is needed. It's not that hard to pick up a language that's more useful to a certain end, especially if you're young and the stuffing in your head is fluffy still. They're all C with different sprinkles anyways (Excluding FORTH, Prolog, Haskell and friends). The idea that that isn't the case leads us down dark godless paths, such as Java VMs on credit cards.
In industry Python is #1 and when you literally have 2 hours to solve a problem from beginning to end, it gets the job done so you can move on. It's also extensible and (largely) frees the programmer from having to do tedious things, so they can just work on "what is this thing supposed to do". Sprinkle some Copilot in the mix and you can get a Smile ton done in a short time.
As for what started this whole thread, I have a board that I intend to use as a test fixture and I designed it so it could take a Pico or a P2, and because Python on uP is so similar, I could write the same code and run it on both without changing anything.
I don't have time to learn the nuances of the Pico (or P2) and code tight stuff in C, what I'm doing isn't sensitive to speed so if it takes 5s to complete, no biggie. What matters to me is a language that uses USB as a console so it can talk to a computer, I can write code that doesn't require a huge learning curve to deploy, and it doesn't cost me a lot.
That last point was kinda lost on the P2. At $79 for an Edge it literally costs more by itself than 2 complete boards stuffed with a Pico and all the components (including an $18 connector).
Python allows you to take what you know from a desktop, apply it to a microcontroller, and not sweat the details of what makes the microcontroller tick.
Ironically, SPIN syntax and Python syntax have a lot of similarities.
If anyone is painting with such brushes, it must be you. I don't know, I'm 22 and I write a script language when a script language is needed (I prefer ruby over python but who cares), C when C is needed, asm when asm is needed. It's not that hard to pick up a language that's more useful to a certain end, especially if you're young and the stuffing in your head is fluffy still. They're all C with different sprinkles anyways (Excluding FORTH, Prolog, Haskell and friends). The idea that that isn't the case leads us down dark godless paths, such as Java VMs on credit cards.
In industry Python is #1 and when you literally have 2 hours to solve a problem from beginning to end, it gets the job done so you can move on. It's also extensible and (largely) frees the programmer from having to do tedious things, so they can just work on "what is this thing supposed to do". Sprinkle some Copilot in the mix and you can get a Smile ton done in a short time.
As for what started this whole thread, I have a board that I intend to use as a test fixture and I designed it so it could take a Pico or a P2, and because Python on uP is so similar, I could write the same code and run it on both without changing anything.
I don't have time to learn the nuances of the Pico (or P2) and code tight stuff in C, what I'm doing isn't sensitive to speed so if it takes 5s to complete, no biggie. What matters to me is a language that uses USB as a console so it can talk to a computer, I can write code that doesn't require a huge learning curve to deploy, and it doesn't cost me a lot.
That last point was kinda lost on the P2. At $79 for an Edge it literally costs more by itself than 2 complete boards stuffed with a Pico and all the components (including an $18 connector).
Python allows you to take what you know from a desktop, apply it to a microcontroller, and not sweat the details of what makes the microcontroller tick.
Ironically, SPIN syntax and Python syntax have a lot of similarities.
If Python is good enough for your application, why not just use a Raspberry Pi? There are plenty of things a P2 can do that a Pi can't, but it can't do much, if any, of those things when it's running Python. It would seem that if you're considering using a P2 for a project, it's already a safe assumption that Python isn't gonna cut it performance-wise.
and when you literally have 2 hours to solve a problem from beginning to end, it gets the job done so you can move on. It's also extensible and (largely) frees the programmer from having to do tedious things, so they can just work on "what is this thing supposed to do".
Yes, that is a situation where you bust out your favorite script language. I was not dissing scripting languages in general. I write a lot of Ruby. A lot of Ruby that no one ever sees that is awful and slow.
Sprinkle some Copilot in the mix and you can get a Smile ton done in a short time.
And then disappear in an even shorter time so you're gone before the boss realizes you just did a plagiarism.
As for what started this whole thread, I have a board that I intend to use as a test fixture and I designed it so it could take a Pico or a P2, and because Python on uP is so similar, I could write the same code and run it on both without changing anything.
I don't have time to learn the nuances of the Pico (or P2) and code tight stuff in C, what I'm doing isn't sensitive to speed so if it takes 5s to complete, no biggie. What matters to me is a language that uses USB as a console so it can talk to a computer, I can write code that doesn't require a huge learning curve to deploy, and it doesn't cost me a lot.
What nuances? The basic pin I/O is the same on every MCU and every language. And the advanced stuff is platform and language specific.
Python allows you to take what you know from a desktop, apply it to a microcontroller, and not sweat the details of what makes the microcontroller tick.
Until the MCU stops ticking every few seconds to garbage collect the heap....
Look, I'm not saying there shouldn't be Python on P2 and you specifically shouldn't use it, I just said that complaining about it not being a first priority in terms of tooling is ludicrous. You don't get a hammer with a Meccano kit.
Anyways, unproductive discussion that is mildly off-topic is unproductive, more at 11.
@Wuerfel_21 said:
We have a VSC plugin and solid CLI tools. Let's stop reinventing the text editor wheel. It has been tried at least 5 times and it never worked out.
Can you point me to this plugin? I see 2 extensions:
Spin2
Spin
Both seem to be syntax highlighting and grammar extensions, but do not offer any "Hit play to run" functionality that you get with Flexprop and Proptool.
The Spin2 extension is the correct one (look at the update dates).
VSC doesn't have a run button* , the workflow is that you use the terminal or set up the project tasks manually. The P2 extension page has instructions on this.
(* There is a run button as part of the debug pane, but that has very limited support, only works when a corresponding debug configuration is available.)
What matters to me is a language that uses USB as a console so it can talk to a computer
P2 has built-in Forth. Reset, starting esc sequence, and Forth is running, talking to the serial terminal.
The main power of Python is a library for everything. From this import that, ready. A web server needed? Import it, add 10 lines of code, it works. These libraries are written mostly in C, to be fast when called from inside Python interpreter.
The P2 is a strange beast. Do we have libraries for Python that do what a P2 can do? I think we haven't. Someone has to write them all. Then we will end with a bunch of libraries incompatible with anything. We have 8 cogs, 64 strange smart pins, no other systems have these, no code exchange, except for basic functions. Simply wasting a P2.
Of course it would be good to have a native, working Python on a P2. Every new language working on a P2 is good (...and I want Pascal... in fpc flavor although the FlexBasic can be a good replacement of it now...) but there are more important problems to solve first. No one of students asked me about Python when I presented a P2. They asked instead - "Can I program it in C?" I can answer - yes, you can: there is Flexprop that has a C compiler in it. There is also Catalina now. We need mature C compilers, to build for example, a native Python interpreter and port the most needed libraries. And we the people that starts their adventure with a P2 still need a complete, easy readable documentation. I had no problem to start playing with P2, but I have P1 background...
I tried to use Python some time ago. There were several things to do where I couldn't find a library to do it fast enough. Native Python function was way too slow. A quick look to a documentation, how to write a Python library, was enough for me to close the Python IDE and start to write the code in good, old Pascal (fpc/Lazarus) where I still have a lot of ready-made libraries and a freedom, including using asm, where needed.
And how depending on libraries and being unable to write one ends?
When I was studying for my PhD, one of my colleagues wanted to study chaotic systems in Matlab. When the professor asked him how he was going to do it it, he replied: I'll use this toolbox, I'll use that toolbox (that's what libraries are called in Matlab). The professor asked him - what if there is no function that you need in these toolboxes?
The answer was complete silence
He tried to implement a simple chaotic system using Matlab, a proper toolbox for chaotic systems, a bridge from Matlab to Quartus, and a full version of Quartus and DE2-115. A simple system that I can write using 15 lines of Verilog. Get a big truck, to drive 100 meters/yards to the grocery store, buy one apple, transport it home using the truck.
(and yes, this boy didn't graduate)
I'm 22 and I write a script language when a script language is needed
Being 57 I am at the other end of the spectrum but I am now trying to write "a script language" - a standalone retromachine type Basic interpreter, inputting from USBnew kbd/mouse, outputting on HDMI... I am at the very start of the project, so no topic yet...
Every time it boots from SD, it ends up sending the 4 byte string B00294FD over and over.
FDB00924 looks a little like a 32 bit P2 opcode (translates to CALL #$294 using relative address offset). Maybe some debug output gets enabled or something internally that is printing opcode traces etc... almost looks like two COGs are outputting serial data to the same pin. I can see the word "Python" buried here:
FD B0M02 9c Fr B0Py2 th on 0 #2
Maybe there is corruption going on with the flashed image or your flash chip or something got changed with P2 debug and flashing tools and while it used to work before when MP was initially released some time ago it doesn't now for some reason. While I've not used flash myself with MP I'm reasonably confident Tubular and OzPropDev have had it booting from flash in the past in their own dev work, plus whoever wrote up the flash sequence would have tested that too.
What if somehow the last sector in flash is not being programmed correctly before a serial disconnect reset happens when the terminal is exited...? It would be good to write something that reads back the flash binary and compares is to a binary image being programmed. Also you already mentioned that your SD card image had a different md5sum before @pedward . That's not a good sign. Plus your own reported MP size of 511071 bytes isn't matching what's was Lachlan's disk as 512488 bytes. This is the P2uP_1_0_24.binary file in the zip which is 512488 bytes - I just checked that too from the download link mentioned in the write up. Your 511071 number is not aligned to a multiple of 4 either which is weird. Are you sure your original file is valid and not somehow truncated?
Every time it boots from SD, it ends up sending the 4 byte string B00294FD over and over.
FDB00924 looks a little like a 32 bit P2 opcode (translates to CALL #$294 using relative address offset). Maybe some debug output gets enabled or something internally that is printing opcode traces etc... almost looks like two COGs are outputting serial data to the same pin. I can see the word "Python" buried here:
FD B0M02 9c Fr B0Py2 th on 0 #2
Maybe there is corruption going on with the flashed image or your flash chip or something got changed with P2 debug and flashing tools and while it used to work before when MP was initially released some time ago it doesn't now for some reason. While I've not used flash myself with MP I'm reasonably confident Tubular and OzPropDev have had it booting from flash in the past in their own dev work, plus whoever wrote up the flash sequence would have tested that too.
What if somehow the last sector in flash is not being programmed correctly before a serial disconnect reset happens when the terminal is exited...? It would be good to write something that reads back the flash binary and compares is to a binary image being programmed. Also you already mentioned that your SD card image had a different md5sum before @pedward . That's not a good sign. Plus your own reported MP size of 511071 bytes isn't matching what's was Lachlan's disk as 512488 bytes. This is the P2uP_1_0_24.binary file in the zip which is 512488 bytes - I just checked that too from the download link mentioned in the write up. Your 511071 number is not aligned to a multiple of 4 either which is weird. Are you sure your original file is valid and not somehow truncated?
This is booting from SD card, the file is copied directly to the SD. When booting from flash you get the REPL initialization, but it never responds after printing that to the serial interface.
I agree that the image is truncated, by exactly 8000h, because the image is 512K and the flasher is 32K, the last 32K is truncated during download. Looking at the binary, there is code in the last 32K, which is unfortunate because the entire binary could be shortened by 128K by putting the heap at the end.
As a starting point I tried loading how I remember it being used, initially with P2Eval since thats what we were using
In proptool 2.6.2,
Step 1 completes (P56 blinking), but you have to disable debug first. Fair enough.
Step 2 fails - I get this error message in Proptool:
"Error: communication stalled due to system problem"
(debug is still turned off from step1)
Comments
Ok, interesting. Yes its normal for the P2 to reset when exiting the terminal programs. And yes this makes me wonder how things worked going from step1 to step2 in flexpropgui, previously, when the terminal is closed in between those steps
Most of the dev work around this was using flexpropgui 4.0.6 I believe, which I still have set up. Its the weekend here now, but I should be able to get into work at some point and test things again with that version.
Sometimes we break DTR by using a 4 pin stackthru connector, and bending the reset pin out of the way slightly, so only RX TX and GND carry through. But I don't recall having to do that with P2 native MicroPython, so I'll go over it again
I think thats why there's the first step involving a different (shifted?) uP binary image
This is the file size I have for the main binary
The SD boot is limited to 496K (allegedly, anyways), so i guess that's why that won't work. Why is it so big?
Its that big to give 128kB of working memory once its all fired up. It can be less (its set in the MP config file), but thats a round power of 2 that (just) fits and works
Whats this alleged 496K limit about @Wuerfel_21 ?
"Alleged" because the docs claim it and I haven't empirically verified it.
Its 496K because the SD boot code lives in the 16K ROM-loaded area and doesn't want to overwrite itself.
I personally always leave those 16K alone (esp. since that's where debug blobs go and I like being able to debug...).
If the image was rebuilt to put the heap at the end of the binary, the problem would be avoided.
Ok, sounds like there's a list of things that need nailing down to make this all easier to get up and running. We need to improve the docs, support the new Led location on the edge, test with Linux and Mac, test all prop plug revisions, test and debunk a few myths in the software end (busted/plausible/confirmed)
I do know however that zip file works, because we did a fair bit of development with it a few (4~5) years back, and built a fair bit on top of the same (editors, flash file system, video drivers, debug etc). I did do a fair bit of 64 GB SDXC card testing perhaps 3 years ago (results are here somewhere), but perhaps its time to revisit all this to make the experience smoother. The problem that time is particularly short this month
We need to get @pedward running asap, then make the above test and documentation improvements before too long
Micropython puts the heap in 'third quarter' for whatever reason.
You can see a visual representation of all-of-hub on the lower screen in this vid from around 6m14s
https://www.youtube.com/watch?v=c3Xa-DOU0D0&t=374s
That factorial demo chews up almost all the heap. The white flashes represent changes being made in that sector of hub ram (from memory each character represents 512 bytes, but don't hold me to that). Disclaimer - technically this is using Eric's early risc-v MP image, before we moved to P2 Native MicroPython, the hub layout would be very similar
I'll be honest, after being out of the Prop universe for about 8 years, some things have improved (like the fact SD can boot, 2Mbit download, large on-board flash, faster boot times). Some things have stayed the same (Windows centric end-user focus). Some things appear to have not aged well. The Rpi Pico has a drag-n-drop firmware loader that behaves like a disk. They have some issues with their docs too, not being up to date with current uP changes, having gaps, etc.
Overall, the P2 promises to be a good solution, if expensive. My disappointment comes from Python not being treated as a Tier 1 language. It should be seamless to get running.
Python is a language which has become universal, even though it's relatively slow, because it's easy to use, widely supported, and many people have learned it. At work I will choose to write in Python first, knowing that C or other languages are considered "esoteric" and thus are harder for people to understand and maintain.
I'm disappointed that old, unsigned, drivers are distributed with the latest Proptool. Even with the right drivers it seems to choke on code downloads.
I'm running, near as I can tell, the same laptop that Ken uses, but my vanilla install doesn't work correctly.
I am rather impressed with the cross platform Linux/Unix support, but I'm a little disappointed that the SimpleIDE didn't live on. It was rather polished, but I think something got in the way. I wrote Unicode support for the terminal for that.
Huh, I would've thought Windoze would have a default built-in comport driver these days. Not needing anything shipped with Proptool. That's been the norm on Linux for so long I'd forgotten it was a thing.
PS: There is talk that Proptool is effectively depreciated and only on life-support from now. Chip is wanting to make the tools completely cross-platform but still has some decisions to make as to what path exactly. Link - https://forums.parallax.com/discussion/comment/1551187/#Comment_1551187
Either a Qt based application (like SimpleIDE) or Electron (Chromium + Javascript) would be the 2 candidates for a cross-platform tool.
Electron is what vscode and Slack use, it makes it easier to attract developers because Javascript.
Qt is faster but requires you to find C++ programmers.
There is an NPN transistor in the PropPlug that is used to pull the reset line low. This transistor is capacitivly coupled to the DTR line. A change is state of DTR can cause a reset, even when you don't want that to happen.
It does. Anything vaguely normal should auto-download the driver from Windows Update. And I'm pretty sure the driver that comes with proptool is signed. Unsigned drivers have not worked without major workaround ever since vista. Getting the security confirmation dialog does not mean the driver is unsigned. Having to enable test signing mode from the terminal, rebooting and having a permanent watermark on your desktop means the driver is unsigned. And yes, linux generally ships with every possible driver preinstalled and somehow still takes less disk space than Win11.
Well that's a them problem. Having a Hammer doesn't mean that every problem is a nail. Why splurge on a high-performance MCU with special acceleration features and then load it up with a slow script language runtime that can't really take advantage of the hardware? It makes no sense (unless the interactive scripting ability is the point of the project). That's why effort isn't being poured in that avenue. (Also, the current micropython builds are based either on RISC-V emulation or on a hacky translation of P1 GCC output to P2, which means the performance is a lot worse than it needs to be and promoting it in that state might make the chip look weak or something)
We have a VSC plugin and solid CLI tools. Let's stop reinventing the text editor wheel. It has been tried at least 5 times and it never worked out.
This should be promoted at the entry point page for every Propeller 2 page on the site. If there really is seamless vscode support, that should be what all effort is put behind.
Do you realize that you are literally painting anyone under the age of 40 with the same brush? Python continues to be either the most popular programming language, or trades blows for the top 3, year over year.
I do understand the value in all the whiz-bang capabilities of the P2, but there are times when ultimate speed isn't necessary. If you need more speed and features, you could always write spin/pasm modules to run in other cogs.
Getting new people to adopt the P2 requires getting it into their hands and getting them coding in as little time as possible. Micropython makes the choice of processor even less relevant, but 64 io pins is a big draw and people will see Python as a gateway.
If anyone is painting with such brushes, it must be you. I don't know, I'm 22 and I write a script language when a script language is needed (I prefer ruby over python but who cares), C when C is needed, asm when asm is needed. It's not that hard to pick up a language that's more useful to a certain end, especially if you're young and the stuffing in your head is fluffy still. They're all C with different sprinkles anyways (Excluding FORTH, Prolog, Haskell and friends). The idea that that isn't the case leads us down dark godless paths, such as Java VMs on credit cards.
In industry Python is #1 and when you literally have 2 hours to solve a problem from beginning to end, it gets the job done so you can move on. It's also extensible and (largely) frees the programmer from having to do tedious things, so they can just work on "what is this thing supposed to do". Sprinkle some Copilot in the mix and you can get a Smile ton done in a short time.
As for what started this whole thread, I have a board that I intend to use as a test fixture and I designed it so it could take a Pico or a P2, and because Python on uP is so similar, I could write the same code and run it on both without changing anything.
I don't have time to learn the nuances of the Pico (or P2) and code tight stuff in C, what I'm doing isn't sensitive to speed so if it takes 5s to complete, no biggie. What matters to me is a language that uses USB as a console so it can talk to a computer, I can write code that doesn't require a huge learning curve to deploy, and it doesn't cost me a lot.
That last point was kinda lost on the P2. At $79 for an Edge it literally costs more by itself than 2 complete boards stuffed with a Pico and all the components (including an $18 connector).
Python allows you to take what you know from a desktop, apply it to a microcontroller, and not sweat the details of what makes the microcontroller tick.
Ironically, SPIN syntax and Python syntax have a lot of similarities.
If Python is good enough for your application, why not just use a Raspberry Pi? There are plenty of things a P2 can do that a Pi can't, but it can't do much, if any, of those things when it's running Python. It would seem that if you're considering using a P2 for a project, it's already a safe assumption that Python isn't gonna cut it performance-wise.
Today's famously healthy captitalist software industry that is known to produce high-quality bug-free software that doesn't use orders of magnitude more resources than it needs to.
Yes, that is a situation where you bust out your favorite script language. I was not dissing scripting languages in general. I write a lot of Ruby. A lot of Ruby that no one ever sees that is awful and slow.
And then disappear in an even shorter time so you're gone before the boss realizes you just did a plagiarism.
What nuances? The basic pin I/O is the same on every MCU and every language. And the advanced stuff is platform and language specific.
Until the MCU stops ticking every few seconds to garbage collect the heap....
Look, I'm not saying there shouldn't be Python on P2 and you specifically shouldn't use it, I just said that complaining about it not being a first priority in terms of tooling is ludicrous. You don't get a hammer with a Meccano kit.
Anyways, unproductive discussion that is mildly off-topic is unproductive, more at 11.
Can you point me to this plugin? I see 2 extensions:
Both seem to be syntax highlighting and grammar extensions, but do not offer any "Hit play to run" functionality that you get with Flexprop and Proptool.
I hear you @pedward
Before things slide too far - did you get up and running? With SD card or flash?
The Spin2 extension is the correct one (look at the update dates).
VSC doesn't have a run button* , the workflow is that you use the terminal or set up the project tasks manually. The P2 extension page has instructions on this.
(* There is a run button as part of the debug pane, but that has very limited support, only works when a corresponding debug configuration is available.)
P2 has built-in Forth. Reset, starting esc sequence, and Forth is running, talking to the serial terminal.
The main power of Python is a library for everything. From this import that, ready. A web server needed? Import it, add 10 lines of code, it works. These libraries are written mostly in C, to be fast when called from inside Python interpreter.
The P2 is a strange beast. Do we have libraries for Python that do what a P2 can do? I think we haven't. Someone has to write them all. Then we will end with a bunch of libraries incompatible with anything. We have 8 cogs, 64 strange smart pins, no other systems have these, no code exchange, except for basic functions. Simply wasting a P2.
Of course it would be good to have a native, working Python on a P2. Every new language working on a P2 is good (...and I want Pascal... in fpc flavor
although the FlexBasic can be a good replacement of it now...) but there are more important problems to solve first. No one of students asked me about Python when I presented a P2. They asked instead - "Can I program it in C?" I can answer - yes, you can: there is Flexprop that has a C compiler in it. There is also Catalina now. We need mature C compilers, to build for example, a native Python interpreter and port the most needed libraries. And we the people that starts their adventure with a P2 still need a complete, easy readable documentation. I had no problem to start playing with P2, but I have P1 background...
I tried to use Python some time ago. There were several things to do where I couldn't find a library to do it fast enough. Native Python function was way too slow. A quick look to a documentation, how to write a Python library, was enough for me to close the Python IDE and start to write the code in good, old Pascal (fpc/Lazarus) where I still have a lot of ready-made libraries and a freedom, including using asm, where needed.
And how depending on libraries and being unable to write one ends?
When I was studying for my PhD, one of my colleagues wanted to study chaotic systems in Matlab. When the professor asked him how he was going to do it it, he replied: I'll use this toolbox, I'll use that toolbox (that's what libraries are called in Matlab). The professor asked him - what if there is no function that you need in these toolboxes?
The answer was complete silence
He tried to implement a simple chaotic system using Matlab, a proper toolbox for chaotic systems, a bridge from Matlab to Quartus, and a full version of Quartus and DE2-115. A simple system that I can write using 15 lines of Verilog. Get a big truck, to drive 100 meters/yards to the grocery store, buy one apple, transport it home using the truck.
(and yes, this boy didn't graduate)
Being 57 I am at the other end of the spectrum but I am now trying to write "a script language" - a standalone retromachine type Basic interpreter, inputting from USBnew kbd/mouse, outputting on HDMI... I am at the very start of the project, so no topic yet...
Nope, I just formatted a 64G SD with FAT32, copied the binary as
_BOOT_P2.BIXto the root directory, then installed it in the P2 Edge module.On startup it sends a bunch of garbage to the serial and starts spamming the same 4 byte string over and over:
B0 02 94 FDEDIT: I resized the partition to 1G, reformatted it, then tried again, same result.
Ok, I'll have a look using the new hardware (edge instead of p2eval) later today
FDB00924 looks a little like a 32 bit P2 opcode (translates to CALL #$294 using relative address offset). Maybe some debug output gets enabled or something internally that is printing opcode traces etc... almost looks like two COGs are outputting serial data to the same pin. I can see the word "Python" buried here:
FD B0M02 9c Fr B0Py2 th on 0 #2Maybe there is corruption going on with the flashed image or your flash chip or something got changed with P2 debug and flashing tools and while it used to work before when MP was initially released some time ago it doesn't now for some reason. While I've not used flash myself with MP I'm reasonably confident Tubular and OzPropDev have had it booting from flash in the past in their own dev work, plus whoever wrote up the flash sequence would have tested that too.
What if somehow the last sector in flash is not being programmed correctly before a serial disconnect reset happens when the terminal is exited...? It would be good to write something that reads back the flash binary and compares is to a binary image being programmed. Also you already mentioned that your SD card image had a different md5sum before @pedward . That's not a good sign. Plus your own reported MP size of 511071 bytes isn't matching what's was Lachlan's disk as 512488 bytes. This is the P2uP_1_0_24.binary file in the zip which is 512488 bytes - I just checked that too from the download link mentioned in the write up. Your 511071 number is not aligned to a multiple of 4 either which is weird. Are you sure your original file is valid and not somehow truncated?
This is booting from SD card, the file is copied directly to the SD. When booting from flash you get the REPL initialization, but it never responds after printing that to the serial interface.
I agree that the image is truncated, by exactly 8000h, because the image is 512K and the flasher is 32K, the last 32K is truncated during download. Looking at the binary, there is code in the last 32K, which is unfortunate because the entire binary could be shortened by 128K by putting the heap at the end.
As a starting point I tried loading how I remember it being used, initially with P2Eval since thats what we were using
In proptool 2.6.2,
Step 1 completes (P56 blinking), but you have to disable debug first. Fair enough.
Step 2 fails - I get this error message in Proptool:
"Error: communication stalled due to system problem"
(debug is still turned off from step1)
If we don't already have this, the P2 ultimately needs a robust way to be able to flash 512kB images.