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