@ersmith The terminal from loadp2 seems to be much better handling the escape sequences than the Flexprop terminal. Is that something that could be added as an option to Flexprop?
Was very happy with the loadp2 terminal window for being in color and seeming to work perfectly for pye (editor).
But, was sad to see that backspace key doesn't work. Seems to just be ignored.
Not really sure how that is even possible...
But, fortunately, web search showed me that CTRL-h will do backspace.
This seems odd, but guess it's from ASCII
Hmm seems now that backspace key acts like "DEL" key should...
What's this loadp2 terminal window you speak of? Isn't loadp2 just a command-line program that uses your OS's terminal, or is the Windows version different?
@ersmith pye seems to run perfectly when it is the first thing to run.
But, seems to crash sometimes when called later.
Not exactly sure what is going on there, but maybe related to it crashing with HIMEM=flash...
Maybe one just needs to import pye first thing... Trying that now... Yikes, it just erased the whole uSD...
Perhaps my version of pye is broke... Maybe it was me that broke it... Have to try the original again...
@Rayman said:
@ersmith Seems that using _execve() is fine, except that uSD doesn't mount. Is there any way to fix that?
I don't know. _execve is a bit dicey for very large programs (like micropython) so I'm actually kind of surprised it works. Do you have any idea (debug messages from upython or anything similar) why the uSD isn't mounting?
@Rayman said:
@ersmith The terminal from loadp2 seems to be much better handling the escape sequences than the Flexprop terminal. Is that something that could be added as an option to Flexprop?
loadp2 doesn't have any terminal, it just uses the one the operating system provides.
If you happen to know what escape sequences aren't being handled let me know and I can try to fix them in Flexprop.
Tried the pye.py from the @ersmith github with HIMEM=flash and it doesn't work either...
So, that is still broke. Was hoping that some change that was made in my version of pye was why it was broke, but no dice...
Better than it was though. At least pye loads. Locks up shortly after loading though.
The terminal window launched from Visual Studio Community just got a lot stranger on a very new Win 11 and VS install.
In the pye text editor, CTRL-S stopped working.
This was very odd. Right clicking on top of window showed a whole bunch of new options that weren't there before.
Somehow, was able to click the right thing and now it's back like it was and CTRL-S works again.
Another thing just noticed is that copy and past works with Micropython in this kind of terminal.
Very handy. So that, along with the escape sequences working better has me sold on this.
It's just the strangeness of backspace working like del and ctrl-h needed for backspace this is the downside so far...
Learned enough Micropython to create this driver that talks to PASM2 driver that gets loaded into a cog.
It's definitely not as fast as the Spin2 version from whence it came, but this is fun too...
Using "main.py" option saved a ton of typing during testing. This port is rigged to execute this file at startup. Wasn't sure if it would replace the exec(open("main.py").read()) that I was having to type all the time, or if it would act more like import main. The import is no good because what it does goes out of scope when finished. Anyway, it works like "exec", perfect.
Also figured out that the terminal that loadp2 is opening, although doesn't do backspace right, does do backspace like expected with CTRL-backspace. Strange, but I'll take it.
Next, suppose have to see about the I2C touchscreen chip... Could do with machine.I2C, but think will try to stuff into the assembly driver...
One nice thing about this approach is that doesn't need a framebuffer. Still, am thinking about trying to get microgui going with this. Or, maybe better to see about getting PSRAM involved...
The backspace thing - i vaguely recall Ozpropdev intercepting the backspace character and replacing it with backspace-space-backspace, but that was taking advantage of a smartpin redirect in between the serial interface and micropython
@Rayman said:
Also figured out that the terminal that loadp2 is opening, although doesn't do backspace right, does do backspace like expected with CTRL-backspace. Strange, but I'll take it.
Probably one of those DEL vs BS things, or it's treating BS as non-destructive cursor move only.
Ok, got touch working and got the screen update moved to assembly.
So, it is useable now.
Had to add this to mpconfigureport.h to get some of the demos to work:
The one thing that a bit too slow is sliders. Seems they changed it at some point from moving the slider to where it is being touched, to slowly moving toward where being touched.
If this Micropython were about 5X faster would be OK, but a bit too slow as is. So, if using sliders would probably change the code back to moving to where touched.
In general, seems this Micropython must be slow, compared to others. But, we have the advantage of spare cogs.
So, for gui type work would probably be better to push more to assembly.
But, this is OK. For a larger screen though, would definitely need more in assembly.
Comments
@ersmith The terminal from loadp2 seems to be much better handling the escape sequences than the Flexprop terminal. Is that something that could be added as an option to Flexprop?
Was very happy with the loadp2 terminal window for being in color and seeming to work perfectly for pye (editor).
But, was sad to see that backspace key doesn't work. Seems to just be ignored.
Not really sure how that is even possible...
But, fortunately, web search showed me that CTRL-h will do backspace.
This seems odd, but guess it's from ASCII
Hmm seems now that backspace key acts like "DEL" key should...
What's this loadp2 terminal window you speak of? Isn't loadp2 just a command-line program that uses your OS's terminal, or is the Windows version different?
IDK, but it's what I get when using loadp2 to launch code.
Maybe because it's the "new console"?
@ersmith pye seems to run perfectly when it is the first thing to run.
But, seems to crash sometimes when called later.
Not exactly sure what is going on there, but maybe related to it crashing with HIMEM=flash...
Maybe one just needs to import pye first thing... Trying that now... Yikes, it just erased the whole uSD...
Perhaps my version of pye is broke... Maybe it was me that broke it... Have to try the original again...
I don't know. _execve is a bit dicey for very large programs (like micropython) so I'm actually kind of surprised it works. Do you have any idea (debug messages from upython or anything similar) why the uSD isn't mounting?
loadp2 doesn't have any terminal, it just uses the one the operating system provides.
If you happen to know what escape sequences aren't being handled let me know and I can try to fix them in Flexprop.
@ersmith well it’s primarily the foreground and background color ones.
But also, those that pye uses to redraw the screen. Those are not working right.
Especially, when trying to scroll down past the first page of a file…
Tried the pye.py from the @ersmith github with HIMEM=flash and it doesn't work either...
So, that is still broke. Was hoping that some change that was made in my version of pye was why it was broke, but no dice...
Better than it was though. At least pye loads. Locks up shortly after loading though.
The terminal window launched from Visual Studio Community just got a lot stranger on a very new Win 11 and VS install.
In the pye text editor, CTRL-S stopped working.
This was very odd. Right clicking on top of window showed a whole bunch of new options that weren't there before.
Somehow, was able to click the right thing and now it's back like it was and CTRL-S works again.
Another thing just noticed is that copy and past works with Micropython in this kind of terminal.
Very handy. So that, along with the escape sequences working better has me sold on this.
It's just the strangeness of backspace working like del and ctrl-h needed for backspace this is the downside so far...
Learned enough Micropython to create this driver that talks to PASM2 driver that gets loaded into a cog.
It's definitely not as fast as the Spin2 version from whence it came, but this is fun too...
Using "main.py" option saved a ton of typing during testing. This port is rigged to execute this file at startup. Wasn't sure if it would replace the
exec(open("main.py").read())that I was having to type all the time, or if it would act more likeimport main. The import is no good because what it does goes out of scope when finished. Anyway, it works like "exec", perfect.Also figured out that the terminal that loadp2 is opening, although doesn't do backspace right, does do backspace like expected with CTRL-backspace. Strange, but I'll take it.
Next, suppose have to see about the I2C touchscreen chip... Could do with machine.I2C, but think will try to stuff into the assembly driver...
One nice thing about this approach is that doesn't need a framebuffer. Still, am thinking about trying to get microgui going with this. Or, maybe better to see about getting PSRAM involved...
Great progress, Ray
The backspace thing - i vaguely recall Ozpropdev intercepting the backspace character and replacing it with backspace-space-backspace, but that was taking advantage of a smartpin redirect in between the serial interface and micropython
Probably one of those DEL vs BS things, or it's treating BS as non-destructive cursor move only.
Think have the touch version of microgui working
Was pretty easy to adapt, except for this:
we don't have viper, so it's very slow.
And, the ptr16 thing doesn't work, that tripped me up...
Not sure if touch is working or not.
Think can speed up a lot by pushing to whole screen update routine into the assembly driver.
Hopefully, will be useable then.
Ok, got touch working and got the screen update moved to assembly.
So, it is useable now.
Had to add this to mpconfigureport.h to get some of the demos to work:
The one thing that a bit too slow is sliders. Seems they changed it at some point from moving the slider to where it is being touched, to slowly moving toward where being touched.
If this Micropython were about 5X faster would be OK, but a bit too slow as is. So, if using sliders would probably change the code back to moving to where touched.
In general, seems this Micropython must be slow, compared to others. But, we have the advantage of spare cogs.
So, for gui type work would probably be better to push more to assembly.
But, this is OK. For a larger screen though, would definitely need more in assembly.