Since the micropython thread has picked up in activity, would anybody like to summarize the current setup and functionality of this at Wednesday's Propeller Live Forum?
@Rayman said:
Trying to figure out best approach to a few things...
Things that used to be in pyb are moved to machine.
So what to do about pyb.cpu()? This is special module for launching code in another P2 core.
Guess should also be moved to machine...
Also need to figure out where to put neopixel ... Seems some ports just have it on file system as neopixel.py while others include it as a built in...
Anyway, first want to get SPI working and then address these other things...
Yes things ideally need to move over to use the machineXXX module file structure and away from "pyb" which is meant for PyBoard HW. Also modmachine.c/h are used too for some HW stuff related to clocking and reset. We probably want to create a P2 specific module for low level P2 specific functionality called "modp2.c" with support for things like ATN and random number generation etc, basically anything low level P2. The other microcontroller ports have similar modesp32.c and modrp2.c files etc with custom features of each micro inside those module source files.
As to the neopixel library API I'd expect it should be readily doable for the P2 with either bitbanging or smartpins - although bit timing is important so there would be dependencies on the clock frequency. You'll need to see how the other ports like ESPxx and RP2 do it to see how you can tap into any shared package/API used for this.
@"Ken Gracey" said:
Since the micropython thread has picked up in activity, would anybody like to summarize the current setup and functionality of this at Wednesday's Propeller Live Forum?
Thanks! Ken Gracey
@"Ken Gracey" Not sure I can as boarding cruise ship in Baltic Sea this afternoon….
A related question is what to do about the Pin module. Looks like @ersmith made it so that pyb code would work with P2.
But, now thinking that maybe anything using Pin should use P2 specific commands, like pinh(), pinl(), wrpin(), etc.
That's how it is now, but not sure how viable that is yet...
Somehow, SoftSPI would have to interact with Pin module.
Appears they now have it so that port code can handle the port specific things, but who knows...
@Rayman take a look at how I separated out the machine_pin.c and mphalport.h code in our p2-native-micropython code on github. This put Pin module code in places where they should be (at least for 1.13) and allowed Pins to be defined and used by softSPI IIRC. You'll mainly then need to change the associated gpio.c/h code to use the special RISC-V calls instead of direct PASM2 code I did for things like wxpin/wrpin etc.
Of course if the MP guys have changed the related pin structure since 1.13 this won't necessarily be valid so more work may possibly be needed.
One thing that really should be done over time is to make the smart pins an alternative function, or "AF" mode of the pin. MP already has some sort of framework for doing this as most micros have separate alternative functions for certain IO pins. IMO it would make sense to then have P2 smart pin mode 0 as pure GPIO which still allows pins to be defined as inputs or outputs or be open drains, and the other non zero smart pin mode values as putting the Pin into an "AF" mode. This however needs more custom integration and transitions between modes need to be figured out and it may get tricky if non-MP COGs are also controlling some smart pin states too.
Back on this after a long break...
Think have SPI working, at least to some degree.
Here's a session where reading the "Chip Version" of an W5500 based module.
Returns the right answer, 4.
Next, need to figure out why there's no "network" module...
Ok, think found switch to turn on network in "mpconfigport.h".
Now, have to figure out what this error is about...
../../extmod/modnetwork.c:56:2: error: #error "MICROPY_PY_NETWORK_HOSTNAME_DEFAULT must be set in mpconfigport.h or mpconfigboard.h"
56 | #error "MICROPY_PY_NETWORK_HOSTNAME_DEFAULT must be set in mpconfigport.h or mpconfigboard.h"
Made some progress with Wiznet5k. Got it past the initialization phase. Problem there was strange. Somehow reset pin "on" and "off" mean different things for esp32... Had to reverse them here in wiznet5k.py:
# reset wiznet module prior to initialization
if reset:
reset.on()
time.sleep(0.1)
reset.off()
time.sleep(0.1)
After then, it successfully reads and writes to a few registers to verify connection.
Another strange thing is that have to import wiznet5k_socket before wiznet5k. Think there's some kind of circular importing going on, but not sure.
Anyway, current issue is that doesn't have "time", although time was imported.
I think this Wiznet code might be too old to work... It's acting strangely...
Or, maybe some magic happens when they convert the py files to mpy files...
Made some progress but then got to this error that don't know what to do with:
Think time to build up some skills before trying to tackle this...
One of my boards was occasionally putting random garbage into the terminal...
Just figured out it was because had WiFi enabled with no wifi module present.
Seems serial input on a floating pin is a bad idea...
Another board didn't show this, but has PSRAM on these pins.
Must be just enough of a load to prevent this...
But, noticed that needed to add a delay() function, so did that.
The Pyb LED object is way overkill for such a simple thing.
Smartpins save from needing to do complex timing things.
So, I've implemented it as p2.startled() and p2.setled() , similar to the servo functions.
Here's my version:
import p2
LedPin =52
p2.startled(LedPin,0)
tick = 0 # counter variable
while True:
if tick < 40:
# self.tick % 20 gives a number 0 to 19
# subtracting 9 makes it -9 to 10
# abs maps it 9 to 0 to 10
# subtracting from 10 maps it 1 to 10 to 0
# multiplying by 25 scales it 25 to 250 to 0
p2.setled(LedPin,((10 - (abs((tick % 20) - 9))) * 25))
tick = (tick + 1) % 100
p2.delay(10)
LED looks like what you'd expect...
Am noticing, however, that CTRL-C can't get you out of the infinite loop.
Pretty sure it should, have to look into that...
@Rayman said:
Am noticing, however, that CTRL-C can't get you out of the infinite loop.
Pretty sure it should, have to look into that...
Not 100% sure but you may have to define:
MICROPY_KBD_EXCEPTION somewhere, perhaps in the mpconfigport.h file, as it is required to setup the interrupt char (assuming that part is not working). There may be other things that control this too, didn't dig fully into it.
Just figured out what f-strings are and how to enable them
Seems this is a way to print out formatted text, like with variables.
Very useful. This should make that 9DOF code work as is.
Wish there was a comprehensive list of all the options for mpconfigureport.h, but haven't seen one.
Had to google to find out that needed to add this:
Just figured out that with the Mu python editor, one can use "pyboard" "mode" to interact with P2 REPL.
Had to change the baud to 115_200 to make that work though (in riscvp2_master, so changes the compiler).
Feeling like have the P2 port Micropython 1.23.0 at a good place now, with I2C and SPI working.
Figured out how to add f-string support and some other tidbits.
One thing that is very useful here is the "shell.c" example that comes with FlexProp.
With this, one can transfer files from PC to uSD without removing it from your board.
It uses Plan9 to make the folder where shell.c is launched from accessible to the P2.
Type "dir" to see files in that folder.
Do "mount /sd" to get uSD access.
Then, say to transfer test1.py from PC to uSD, do:
"copy test1.py /sd/test1.py"
To transfer test1.py from uSD to PC, do:
"copy /sd/test1.py /host/test1.py"
I see this can also access PSRAM, that might be interesting...
Pretty sure that is correct info above.
The SimpleP2 board uses different pins for uSD.
Here's a version of shell.c for SimpleP2:
Just noticed something that is very strange...
With VGA and USB and WiFi removed, the binary size INCREASES...
From 500kB to 508kB. Might have to ask @ersmith how that is possible, escapes me...
@Rayman said:
Just noticed something that is very strange...
With VGA and USB and WiFi removed, the binary size INCREASES...
From 500kB to 508kB. Might have to ask @ersmith how that is possible, escapes me...
Yeah that seems somewhat bizarre. It's definitely the same toolchain on both builds and only the Makefile/mpconfigport.h file that differs?
Comments
Regarding pyb.CPU the openAmp pull request contains background discussion about where it should go,
https://github.com/micropython/micropython/pull/12961
It looks like the heavy lifting on that was by Kye's business partner over at OpenMV (they use STM32s primarily)
Since the micropython thread has picked up in activity, would anybody like to summarize the current setup and functionality of this at Wednesday's Propeller Live Forum?
Thanks! Ken Gracey
Yes things ideally need to move over to use the machineXXX module file structure and away from "pyb" which is meant for PyBoard HW. Also modmachine.c/h are used too for some HW stuff related to clocking and reset. We probably want to create a P2 specific module for low level P2 specific functionality called "modp2.c" with support for things like ATN and random number generation etc, basically anything low level P2. The other microcontroller ports have similar modesp32.c and modrp2.c files etc with custom features of each micro inside those module source files.
As to the neopixel library API I'd expect it should be readily doable for the P2 with either bitbanging or smartpins - although bit timing is important so there would be dependencies on the clock frequency. You'll need to see how the other ports like ESPxx and RP2 do it to see how you can tap into any shared package/API used for this.
@"Ken Gracey" Not sure I can as boarding cruise ship in Baltic Sea this afternoon….
A related question is what to do about the Pin module. Looks like @ersmith made it so that pyb code would work with P2.
But, now thinking that maybe anything using Pin should use P2 specific commands, like pinh(), pinl(), wrpin(), etc.
That's how it is now, but not sure how viable that is yet...
Somehow, SoftSPI would have to interact with Pin module.
Appears they now have it so that port code can handle the port specific things, but who knows...
@Rayman take a look at how I separated out the machine_pin.c and mphalport.h code in our p2-native-micropython code on github. This put Pin module code in places where they should be (at least for 1.13) and allowed Pins to be defined and used by softSPI IIRC. You'll mainly then need to change the associated gpio.c/h code to use the special RISC-V calls instead of direct PASM2 code I did for things like wxpin/wrpin etc.
Of course if the MP guys have changed the related pin structure since 1.13 this won't necessarily be valid so more work may possibly be needed.
One thing that really should be done over time is to make the smart pins an alternative function, or "AF" mode of the pin. MP already has some sort of framework for doing this as most micros have separate alternative functions for certain IO pins. IMO it would make sense to then have P2 smart pin mode 0 as pure GPIO which still allows pins to be defined as inputs or outputs or be open drains, and the other non zero smart pin mode values as putting the Pin into an "AF" mode. This however needs more custom integration and transitions between modes need to be figured out and it may get tricky if non-MP COGs are also controlling some smart pin states too.
Back on this after a long break...
Think have SPI working, at least to some degree.
Here's a session where reading the "Chip Version" of an W5500 based module.
Returns the right answer, 4.
Next, need to figure out why there's no "network" module...
Ok, think found switch to turn on network in "mpconfigport.h".
Now, have to figure out what this error is about...
../../extmod/modnetwork.c:56:2: error: #error "MICROPY_PY_NETWORK_HOSTNAME_DEFAULT must be set in mpconfigport.h or mpconfigboard.h"
56 | #error "MICROPY_PY_NETWORK_HOSTNAME_DEFAULT must be set in mpconfigport.h or mpconfigboard.h"
Think seeing that the wiznet5k module is pyb port specific and not going to be easily used here...
But, did find a micropython coded driver that might be able to be used:
https://github.com/Ayyoubzadeh/ESP32-Wiznet-W5500-Micropython
Seems it was adapted from circuitpython...
Just tried the .py version and complains about a print line that uses f-strings.
Seems we don't have f-string handling turned on...
f-string support was easy, just added this:
#define MICROPY_PY_FSTRINGS (1)to "mpconfigport.h".
Now, it's complaining about no module "random"...
"One thing leads to another"
Made some progress with Wiznet5k. Got it past the initialization phase. Problem there was strange. Somehow reset pin "on" and "off" mean different things for esp32... Had to reverse them here in wiznet5k.py:
# reset wiznet module prior to initialization if reset: reset.on() time.sleep(0.1) reset.off() time.sleep(0.1)After then, it successfully reads and writes to a few registers to verify connection.
Another strange thing is that have to import wiznet5k_socket before wiznet5k. Think there's some kind of circular importing going on, but not sure.
Anyway, current issue is that doesn't have "time", although time was imported.
Time.time() is strange... Not sure why doesn't exist and can't figure out how to add it...
Think will just modify the wiznet code to use time.ticks_ms()/1000 instead....
I think this Wiznet code might be too old to work... It's acting strangely...
Or, maybe some magic happens when they convert the py files to mpy files...
Made some progress but then got to this error that don't know what to do with:
Think time to build up some skills before trying to tackle this...
One of my boards was occasionally putting random garbage into the terminal...
Just figured out it was because had WiFi enabled with no wifi module present.
Seems serial input on a floating pin is a bad idea...
Another board didn't show this, but has PSRAM on these pins.
Must be just enough of a load to prevent this...
Now that SPI seems to be working, want to look at accessing the onboard boot flash chip.
Think added littlefs, but now binary is too big...
Could turn off USB and VGA, but not sure want to...
Think will try just using FAT on Flash to start with...
Awesome work Ray!
Thanks @ke4pjw . I'm in way over my head, but it's a challenge to dig myself out...
Tried again to get running code from flash working, but PYE just won't work no matter what I try...
Was trying to test out a micropy example from here:
https://github.com/mithru/MicroPython-Examples/blob/master/01.LEDs/heartbeatFade.py
But, noticed that needed to add a delay() function, so did that.
The Pyb LED object is way overkill for such a simple thing.
Smartpins save from needing to do complex timing things.
So, I've implemented it as p2.startled() and p2.setled() , similar to the servo functions.
Here's my version:
import p2 LedPin =52 p2.startled(LedPin,0) tick = 0 # counter variable while True: if tick < 40: # self.tick % 20 gives a number 0 to 19 # subtracting 9 makes it -9 to 10 # abs maps it 9 to 0 to 10 # subtracting from 10 maps it 1 to 10 to 0 # multiplying by 25 scales it 25 to 250 to 0 p2.setled(LedPin,((10 - (abs((tick % 20) - 9))) * 25)) tick = (tick + 1) % 100 p2.delay(10)LED looks like what you'd expect...
Am noticing, however, that CTRL-C can't get you out of the infinite loop.
Pretty sure it should, have to look into that...
Not 100% sure but you may have to define:
MICROPY_KBD_EXCEPTION somewhere, perhaps in the mpconfigport.h file, as it is required to setup the interrupt char (assuming that part is not working). There may be other things that control this too, didn't dig fully into it.
26 #include "py/obj.h" 27 #include "py/mpstate.h" 28 29 #if MICROPY_KBD_EXCEPTION 30 31 int mp_interrupt_char = -1; 32 33 void mp_hal_set_interrupt_char(int c) { 34 mp_interrupt_char = c; 35 } 36 37 #endifTried defining MICROPY_KBD_EXCEPTION, but didn't work...
Just found a page saying you should do it like this:
def foo(): while True: pass try: foo() except KeyboardInterrupt: print('Got ctrl-c') finally: # Optional cleanup codehttps://forum.micropython.org/viewtopic.php?t=4637
But, it doesn't work either...
Just figured out what f-strings are and how to enable them
Seems this is a way to print out formatted text, like with variables.
Very useful. This should make that 9DOF code work as is.
Wish there was a comprehensive list of all the options for mpconfigureport.h, but haven't seen one.
Had to google to find out that needed to add this:
Somewhat puzzled as to why this doesn't increase the binary size, but I'll take it.
Just figured out that with the Mu python editor, one can use "pyboard" "mode" to interact with P2 REPL.
Had to change the baud to 115_200 to make that work though (in riscvp2_master, so changes the compiler).
The usefulness is questionable, but there is one interesting feature, the "Plotter".
Followed the directions here: https://codewith.mu/en/tutorials/1.2/plotter
Had to add the "random" module back in, that got removed somehow...
Used pye to save the code to uSD and then invoked "plot.py" in REPL and hit the Plotter button:
A bit concerned about changing default baud to 115_200, so changed back to 230_400.
But, made this little script that one can use to change baud at runtime to 115_200 and then work with Mu.
Mu should support a different baudrate setting: https://github.com/mu-editor/mu/issues/865
@rosco_pc thanks!
Feeling like have the P2 port Micropython 1.23.0 at a good place now, with I2C and SPI working.
Figured out how to add f-string support and some other tidbits.
So, just posted binaries and source code here:
https://www.rayslogic.com/Propeller2/upy/micropython.html
One thing I didn't realize going in is that doing anything really useful is port dependent. So, need to make some P2 specific examples...
One thing that is very useful here is the "shell.c" example that comes with FlexProp.
With this, one can transfer files from PC to uSD without removing it from your board.
It uses Plan9 to make the folder where shell.c is launched from accessible to the P2.
Type "dir" to see files in that folder.
Do "mount /sd" to get uSD access.
Then, say to transfer test1.py from PC to uSD, do:
"copy test1.py /sd/test1.py"
To transfer test1.py from uSD to PC, do:
"copy /sd/test1.py /host/test1.py"
I see this can also access PSRAM, that might be interesting...
Pretty sure that is correct info above.
The SimpleP2 board uses different pins for uSD.
Here's a version of shell.c for SimpleP2:
Just noticed something that is very strange...
With VGA and USB and WiFi removed, the binary size INCREASES...
From 500kB to 508kB. Might have to ask @ersmith how that is possible, escapes me...
Yeah that seems somewhat bizarre. It's definitely the same toolchain on both builds and only the Makefile/mpconfigport.h file that differs?