Sounds good, but probably won't be up early enough for that.
Will post things soon.
Just added DAC and ADC to p2 module. Kinda wanted to get that in there first....
Here are some binaries to try. I've been loading them with FlexProp, but there are probably other ways.
It may require that uSD be inserted, not sure.
On Eval type board, the flash jumper has to be off.
Big difference between P2Eval and SimpleP2 is the P2 pins used for the uSD.
There are some variants here with extra stuff.
USB has USB on basepin16.
VGA has VGA on basepin8
WiFi has Parallax Wifi module with DO on P29 and DI pin P30
Without USB, VGA, and WIFI, I'm seeing 241792 bytes memory available from pye.
Want to add some things like I2C. Looks like what they want you to do is implement it in the "machine" module.
I've been putting stuff like this in a module that is called "P2" instead.
Guess I'll see how much work it takes to add stuff to machine...
But, something is wrong with _waitms(). This is built into the RISCVp2 compiler as a CSR.
Since it's broke, must mean it something that I put in. Seems my P2 assembly is wrong here:
millis_write_csr
' wait pb milliseconds
rdlong temp, #$14 ' get frequency
qdiv temp, ##1000
getqx temp ' now have freq/1000 in temp
qmul pb, temp
getqx pb
waitx pb
ret
think can just use mul instead of qmul here and fix it...
Related to post #413 I had some code for enabling soft I2C and soft SPI that followed their newer scheme and a variety of other machine stuff. You may want to take a look at that. It integrates with pin control stuff in mphal so you'll likely need that part too if your version doesn't already use those APIs (not sure what yours has). https://github.com/team-oz/p2-native-micropython/tree/p2native/ports/p2
Do you have your source tree published anywhere by the way? The MP guys might be able to help more with any integration work or questions if they had access to that too.
Related to post #413 I had some code for enabling soft I2C and soft SPI that followed their newer scheme and a variety of other machine stuff. You may want to take a look at that. It integrates with pin control stuff in mphal so you'll likely need that part too if your version doesn't already use those APIs (not sure what yours has). https://github.com/team-oz/p2-native-micropython/tree/p2native/ports/p2
Do you have your source tree published anywhere by the way? The MP guys might be able to help more with any integration work or questions if they had access to that too.
We have Rays image running here now. The MP people have offered to help if we need it.
We'll see some of them in about 54 hours from now..
Ray one issue we had a long time ago was an issue with 230k as the default baudrate - it was a bit patchy when dumping code in raw mode, and could sometimes corrupt or give traceback erorrs
115200 might be safer, with a bonus that Thonny would also work (Thonny uses a fixed 115200 rate)
We can't remember exactly what P2 clock rate we were using at the time, though. It might have been 252 MHz, or not, our own memories are also a bit corrupt
Both the P2 clock and the uart are built into the RISCVP2 jit engine here.
You can change the clock, but there are a couple other things in the RISCVP2 code that have to be adjusted.
The uart driver appears to be robust, it is interrupt driven and has a cache. I've not seen any issues with that at all so far.
But, haven't tried "dumping code in raw mode", so who knows.
Ok, I see Thonny is a Python editor. There's also ArduinoLab.
I suppose having a good editor is important for larger programs.
Also, if there's an easy way to send code from IDE to p2 and run it, suppose that is nice...
So, one must have invoke a script in REPL that does something like ymodem and saves the data to a file right?
Do you have your source tree published anywhere by the way? The MP guys might be able to help more with any integration work or questions if they had access to that too.
I tried Thonny and don't see a way to connect to serial port. Is that some kind of mod?
Maybe VSCode would be good for this?
Online-python is interesting...
@JonnyMac Thanks for the code idea. Not sure if I can use rep in this situation or not, maybe? Have to look into that...
I'm concerned that my present way of doing waitms(x) will fail if x is large...
@Rayman said:
The uart driver appears to be robust, it is interrupt driven and has a cache. I've not seen any issues with that at all so far.
But, haven't tried "dumping code in raw mode", so who knows.
If you paste large blocks of textual python code with CTRL-A or CTRL-B (can't recall offhand which one is Raw-mode) I found you can hit problems with MP. Even if you can keep up with the individual characters in your serial input driver, once the input buffer gets full because MP has to process something you'll overrun it. This happens because parsing the Python needs some variable amount of processing time per line depending on what it has to do. To try to resolve this without proper flow control signals you either have to slow down the entire baud rate to far lower input speeds which is not good, or better yet introduce a time delay at the end of each input line after you've sent the line - however that feature is serial terminal console application dependent and not all can do it.
Another thing (which is what I often do) is just break the entire text into multiple smaller chunks to be pasted each time so as not to blow past the serial buffer size.
@Rayman said:
@rogloh appears you used the code in machine_i2c.c to do i2c?
That seems like the right way to do it, but can't get it to compile...
Feels like missing something simple, but don't know what...
Ok, well I know you'd need integration with some local port specific mp_hal functions and enabling it in the port's config file. Hopefully it's not some particular Makefile issue again.
You also need the machine_pin.c stuff in the port specific folder and included in the files built.
I just did a hack to the binary to get 115200 baud. Both Mu and Thonny see the P2 now.
Thonny doesn't seem to load code though.
Mu seems to be working......running more tests now.
@Rayman said:
Btw: I’m still thinking Pye is pretty awesome. With vga and usb keyboard you basically have a stand alone development system. No pc needed.
If can figure out how to run binaries, might even say it’s an os. Might have to cheat and use psram for that…
I still wish/wonder if we could somehow make good use of the PSRAM for the MP heap (perhaps with some small amount of HUB caching to improve performance). That would allow positively huge MicroPython programs and free up the precious HUB RAM for either more native PASM driver COGs to be included in the build, or more MP features that consume executable space like LittleFS, or multiple JIT caches and stacks for multi-COG MicroPython, or other general uses like text frame buffers for local standalone console video drivers, USB keyboards/mice etc. This PSRAM could also be shared for graphics mode frame buffers at the same time if required.
16k stack for the MicroPython task and approximately 100k Python heap.
So the P2 is already competitive with that micro in terms of heap space. I thought the heap should be larger if the ESP32 can run its code directly from flash although I am unfamiliar with its specifics. There is 520kB SRAM in an ESP32 so it's similar to the P2. I did however read this disclaimer from Espressif docs:
There is 520 KB of available SRAM (320 KB of DRAM and 200 KB of IRAM) on the ESP32. However, due to a technical limitation, the maximum statically allocated DRAM usage is 160 KB. The remaining 160 KB (for a total of 320 KB of DRAM) can only be allocated at runtime as heap."
@Tubular if you are meeting the MP guys tomorrow you might want to ask if there is a way to configure MP to keep the heap in an external memory and read/write data from there indirectly via a port-specific API instead of from addresses directly memory mapped into the micro's address space. If that's possible then we might be able to use external PSRAM for that purpose. If not, you might like to ask if they would consider that capability down the line. It's likely a matter of just using some optional API to read/write the heap where it is required, although if that touches a lot of places I can imagine they'd not be too keen. If instead all the heap data structure accesses go through some common function(s) then it might be feasible to tap into that function to redirect to read/write from external RAM (perhaps).
@rogloh said:
@Tubular if you are meeting the MP guys tomorrow you might want to ask if there is a way to configure MP to keep the heap in an external memory and read/write data from there indirectly via a port-specific API instead of from addresses directly memory mapped into the micro's address space. If that's possible then we might be able to use external PSRAM for that purpose. If not, you might like to ask if they would consider that capability down the line. It's likely a matter of just using some optional API to read/write the heap where it is required, although if that touches a lot of places I can imagine they'd not be too keen. If instead all the heap data structure accesses go through some common function(s) then it might be feasible to tap into that function to redirect to read/write from external RAM (perhaps).
For the RISC-V version, at least, we could do this in the RISC-V emulation -- instead of compiling loads and stores to rdlong/wrlong we could compile them to subroutine calls that do the real load/store from external memory.
I wonder if it might be better to use the external storage for code (and perhaps a framebuffer) rather than the MP heap, though? I think most MicroPython ports use execute in place from flash, so they expect a relatively large text segment but not so much room for data.
@Tubular said:
Thats an interesting couple of ideas Eric. Wonder what kind of performance hit would be incurred
Damien confirmed "Yes, the heap can be anywhere that’s memory addressable", presumably this applies to code too
I think the problem is that he likely means the heap can be put anywhere in the overall address space that the GCC linker sees. So not necessarily something accessed indirectly via an API/mailbox, although that needs confirmation from him.
EDIT: sorry I read this before fully realizing Eric's suggestion.
Comments
Sounds good, but probably won't be up early enough for that.
Will post things soon.
Just added DAC and ADC to p2 module. Kinda wanted to get that in there first....
Here are some binaries to try. I've been loading them with FlexProp, but there are probably other ways.
It may require that uSD be inserted, not sure.
On Eval type board, the flash jumper has to be off.
Big difference between P2Eval and SimpleP2 is the P2 pins used for the uSD.
There are some variants here with extra stuff.
USB has USB on basepin16.
VGA has VGA on basepin8
WiFi has Parallax Wifi module with DO on P29 and DI pin P30
Without USB, VGA, and WIFI, I'm seeing 241792 bytes memory available from pye.
I put these binaries and most of the info needed to make them on this new web page:
https://www.rayslogic.com/Propeller2/upy/micropython.html
Great, I'll check those out. Should purchase a SimpleP2 from you too, to complete the set
Want to add some things like I2C. Looks like what they want you to do is implement it in the "machine" module.
I've been putting stuff like this in a module that is called "P2" instead.
Guess I'll see how much work it takes to add stuff to machine...
Not much there now:
mem32 seems to work, can get the clock freq stored at 0x14 in hub like this:
can't figure out how to integrate into machine i2c, so just making an i2c module...
Can scan i2c bus already:
But, something is wrong with _waitms(). This is built into the RISCVp2 compiler as a CSR.
Since it's broke, must mean it something that I put in. Seems my P2 assembly is wrong here:
millis_write_csr ' wait pb milliseconds rdlong temp, #$14 ' get frequency qdiv temp, ##1000 getqx temp ' now have freq/1000 in temp qmul pb, temp getqx pb waitx pb retthink can just use mul instead of qmul here and fix it...
Related to post #413 I had some code for enabling soft I2C and soft SPI that followed their newer scheme and a variety of other machine stuff. You may want to take a look at that. It integrates with pin control stuff in mphal so you'll likely need that part too if your version doesn't already use those APIs (not sure what yours has).
https://github.com/team-oz/p2-native-micropython/tree/p2native/ports/p2
Do you have your source tree published anywhere by the way? The MP guys might be able to help more with any integration work or questions if they had access to that too.
Wow, I was just looking at that today but somehow missed the p2 port folder.
This could be helpful thanks.
We have Rays image running here now. The MP people have offered to help if we need it.
We'll see some of them in about 54 hours from now..
Ray one issue we had a long time ago was an issue with 230k as the default baudrate - it was a bit patchy when dumping code in raw mode, and could sometimes corrupt or give traceback erorrs
115200 might be safer, with a bonus that Thonny would also work (Thonny uses a fixed 115200 rate)
We can't remember exactly what P2 clock rate we were using at the time, though. It might have been 252 MHz, or not, our own memories are also a bit corrupt
I believe we ran native P2 MP at 252MHz so we could integrate a VGA/DVI COG with standard timings.
Both the P2 clock and the uart are built into the RISCVP2 jit engine here.
You can change the clock, but there are a couple other things in the RISCVP2 code that have to be adjusted.
The uart driver appears to be robust, it is interrupt driven and has a cache. I've not seen any issues with that at all so far.
But, haven't tried "dumping code in raw mode", so who knows.
I'll have to look up what Thonny is...
Ok, I see Thonny is a Python editor. There's also ArduinoLab.
I suppose having a good editor is important for larger programs.
Also, if there's an easy way to send code from IDE to p2 and run it, suppose that is nice...
So, one must have invoke a script in REPL that does something like ymodem and saves the data to a file right?
Sorry, I missed this...
It's at https://www.rayslogic.com/Propeller2/upy/micropython.html
But, a couple days old now... Doesn't have i2c stuff yet... And, waitus() is broke...
Noticed a couple things when building from scratch...
First the library RE seems to be missing from 1.22.2, not sure what it is or why missing.
Turned off in mpconfigureport.h like this:
Second, it seems like mp_machine_idle() needs to be implemented somewhere, so stuck this in board.c:
//RJA Seems we need some implementation void mp_machine_idle() { }The propeller2.h issue is already fixed in what posted on my website..
@rogloh appears you used the code in machine_i2c.c to do i2c?
That seems like the right way to do it, but can't get it to compile...
Feels like missing something simple, but don't know what...
You'll still be limited to delays of 2^32 divided by ticks per millisecond. This works in testing and extends the period.
Fixed per suggestion from Ada.
rdlong temp, #$44 ' get frequency qdiv temp, ##1000 getqx temp ' now have freq/1000 in temp sub temp, #2 ' fix for waitx rep #1, pb waitx tempI was testing with the PNut compiler which is why the frequency location differs from what you show.
BTW, I like Thonny for uPython and CircuitPython on the RP2040. It's a nice little tool, free of cruft.
I tried Thonny and don't see a way to connect to serial port. Is that some kind of mod?
Maybe VSCode would be good for this?
Online-python is interesting...
@JonnyMac Thanks for the code idea. Not sure if I can use rep in this situation or not, maybe? Have to look into that...
I'm concerned that my present way of doing waitms(x) will fail if x is large...
Btw: I’m still thinking Pye is pretty awesome. With vga and usb keyboard you basically have a stand alone development system. No pc needed.
If can figure out how to run binaries, might even say it’s an os. Might have to cheat and use psram for that…
That has a proportional error though, you need to subtract 2 from temp to account for waitx taking 2 extra cycles
If you paste large blocks of textual python code with CTRL-A or CTRL-B (can't recall offhand which one is Raw-mode) I found you can hit problems with MP. Even if you can keep up with the individual characters in your serial input driver, once the input buffer gets full because MP has to process something you'll overrun it. This happens because parsing the Python needs some variable amount of processing time per line depending on what it has to do. To try to resolve this without proper flow control signals you either have to slow down the entire baud rate to far lower input speeds which is not good, or better yet introduce a time delay at the end of each input line after you've sent the line - however that feature is serial terminal console application dependent and not all can do it.
Another thing (which is what I often do) is just break the entire text into multiple smaller chunks to be pasted each time so as not to blow past the serial buffer size.
Ok. Cool.
Ok, well I know you'd need integration with some local port specific mp_hal functions and enabling it in the port's config file. Hopefully it's not some particular Makefile issue again.
You also need the machine_pin.c stuff in the port specific folder and included in the files built.
I just did a hack to the binary to get 115200 baud. Both Mu and Thonny see the P2 now.
Thonny doesn't seem to load code though.
Mu seems to be working......running more tests now.
I still wish/wonder if we could somehow make good use of the PSRAM for the MP heap (perhaps with some small amount of HUB caching to improve performance). That would allow positively huge MicroPython programs and free up the precious HUB RAM for either more native PASM driver COGs to be included in the build, or more MP features that consume executable space like LittleFS, or multiple JIT caches and stacks for multi-COG MicroPython, or other general uses like text frame buffers for local standalone console video drivers, USB keyboards/mice etc. This PSRAM could also be shared for graphics mode frame buffers at the same time if required.
Agreed, PSRAM would be super nice, because the other thing it would also make possible would be more than 1 core running MP
I haven't checked but does the ESP32 port support a big psram based heap? (they commonly have those 64Mbit soic-8 psrams)
Just had a quick look here
https://github.com/micropython/micropython/tree/master/ports/esp32
didn't see anything obvious about PSRAM heaps but interestingly it did mention this:
So the P2 is already competitive with that micro in terms of heap space. I thought the heap should be larger if the ESP32 can run its code directly from flash although I am unfamiliar with its specifics. There is 520kB SRAM in an ESP32 so it's similar to the P2. I did however read this disclaimer from Espressif docs:
Perhaps that's contributing here.
@Tubular if you are meeting the MP guys tomorrow you might want to ask if there is a way to configure MP to keep the heap in an external memory and read/write data from there indirectly via a port-specific API instead of from addresses directly memory mapped into the micro's address space. If that's possible then we might be able to use external PSRAM for that purpose. If not, you might like to ask if they would consider that capability down the line. It's likely a matter of just using some optional API to read/write the heap where it is required, although if that touches a lot of places I can imagine they'd not be too keen. If instead all the heap data structure accesses go through some common function(s) then it might be feasible to tap into that function to redirect to read/write from external RAM (perhaps).
For the RISC-V version, at least, we could do this in the RISC-V emulation -- instead of compiling loads and stores to rdlong/wrlong we could compile them to subroutine calls that do the real load/store from external memory.
I wonder if it might be better to use the external storage for code (and perhaps a framebuffer) rather than the MP heap, though? I think most MicroPython ports use execute in place from flash, so they expect a relatively large text segment but not so much room for data.
Thats an interesting couple of ideas Eric. Wonder what kind of performance hit would be incurred
Damien confirmed "Yes, the heap can be anywhere that’s memory addressable", presumably this applies to code too
I think the problem is that he likely means the heap can be put anywhere in the overall address space that the GCC linker sees. So not necessarily something accessed indirectly via an API/mailbox, although that needs confirmation from him.
EDIT: sorry I read this before fully realizing Eric's suggestion.