Shop OBEX P1 Docs P2 Docs Learn Events
Micropython for P2 - Page 17 — Parallax Forums

Micropython for P2

1141517192023

Comments

  • RaymanRayman Posts: 14,683

    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....

  • RaymanRayman Posts: 14,683
    edited 2024-05-18 21:12

    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.

  • RaymanRayman Posts: 14,683

    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

  • TubularTubular Posts: 4,704

    Great, I'll check those out. Should purchase a SimpleP2 from you too, to complete the set

  • RaymanRayman Posts: 14,683
    edited 2024-05-19 16:16

    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:

     print(dir(machine))
    ['__name__', 'Signal', 'mem16', 'mem32', 'mem8', 'soft_reset']
    

    mem32 seems to work, can get the clock freq stored at 0x14 in hub like this:

    machine.mem32[0x14]
    297000000 
    
  • RaymanRayman Posts: 14,683
    edited 2024-05-20 01:07

    can't figure out how to integrate into machine i2c, so just making an i2c module...

    Can scan i2c bus already:

     import i2c
     i2c.init(53,52,400,2)
     i2c.scan()
    I2C Scan:                  
    -- dddd_aaa_0 (8-bit) format                                                    
    
       00 02 04 06 08 0A 0C 0E                                                      
    10 .. .. .. .. .. .. .. ..                                                      
    20 .. .. .. .. .. .. .. ..                                                      
    30 30 .. .. .. .. .. .. ..                                                      
    40 .. .. .. .. .. .. .. ..                                                      
    50 .. .. .. .. .. .. .. ..                                                      
    60 .. .. .. .. .. .. .. ..                                                      
    70 .. .. .. .. .. .. .. ..                                                      
    80 .. .. .. .. .. .. .. ..                                                      
    90 .. .. .. .. .. .. .. ..                                                      
    A0 .. .. .. .. .. .. .. ..                                                      
    B0 .. .. .. .. .. .. .. ..                                                      
    C0 .. .. .. .. .. .. .. ..                                                      
    D0 .. .. .. .. .. .. .. ..                                                      
    E0 .. .. .. .. .. .. .. ..                                                      
    #Devices Found= 1   
    

    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...

  • roglohrogloh Posts: 5,809
    edited 2024-05-20 00:28

    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.

  • RaymanRayman Posts: 14,683

    Wow, I was just looking at that today but somehow missed the p2 port folder.

    This could be helpful thanks.

  • TubularTubular Posts: 4,704
    edited 2024-05-20 03:11

    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..

  • TubularTubular Posts: 4,704

    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

  • roglohrogloh Posts: 5,809
    edited 2024-05-20 04:46

    I believe we ran native P2 MP at 252MHz so we could integrate a VGA/DVI COG with standard timings.

  • RaymanRayman Posts: 14,683

    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...

  • RaymanRayman Posts: 14,683
    edited 2024-05-20 15:15

    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?

  • RaymanRayman Posts: 14,683

    @rogloh said:

    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.

    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...

  • RaymanRayman Posts: 14,683
    edited 2024-05-20 16:52

    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:

    //RJA Not in 1.22.2?  #define MICROPY_PY_RE              (1)
    #define MICROPY_PY_RE              (0)
    

    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..

  • RaymanRayman Posts: 14,683

    @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...

  • JonnyMacJonnyMac Posts: 9,111
    edited 2024-05-21 15:26

    think can just use mul instead of qmul here and fix it...

    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    temp
    

    I 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.

  • RaymanRayman Posts: 14,683

    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...

  • RaymanRayman Posts: 14,683
    edited 2024-05-20 22:12

    @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...

  • RaymanRayman Posts: 14,683
    edited 2024-05-20 23:01

    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…

  • @JonnyMac said:
    You'll still be limited to delays of 2^32 divided by ticks per millisecond. This works in testing and extends the period.

                            rdlong    temp, #$44                    ' get frequency
                            qdiv      temp, ##1000
                            getqx     temp                          ' now have freq/1000 in temp
                            rep       #1, pb
                             waitx    temp
    

    That has a proportional error though, you need to subtract 2 from temp to account for waitx taking 2 extra cycles

  • roglohrogloh Posts: 5,809
    edited 2024-05-21 01:07

    @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:
    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...

    Ok. Cool.

    @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. :)

  • roglohrogloh Posts: 5,809
    edited 2024-05-21 04:26

    @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.

  • TubularTubular Posts: 4,704

    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)

  • roglohrogloh Posts: 5,809
    edited 2024-05-21 05:36

    @Tubular said:
    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:

    • 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."

    Perhaps that's contributing here.

  • roglohrogloh Posts: 5,809

    @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).

  • ersmithersmith Posts: 6,056

    @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.

  • TubularTubular Posts: 4,704

    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

  • roglohrogloh Posts: 5,809
    edited 2024-05-21 14:29

    @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.

Sign In or Register to comment.