Micropython Questions (P2NMP)
Unsoundcode
Posts: 1,530
https://www.parallax.com/propeller-2/get-started/micropython/
This web page details how to install Micropython onto a P2 microcontroller although its a new medium for me everything is working reasonably well.
At the bottom of this same web page is "Further Information" which has a couple of bullet points that have no other reference from what I can see.
If anyone can help I would like further information on the three following items.
Where is combo.py
What is the .CPU method (I'm guessing some kind of inline assembler)
More information on how to access the OzFFS
Further Information
MicroPython Documentation at https://docs.micropython.org/en/latest/
P2 Native MicroPython on github at https://github.com/team-oz
Full list of pin constants. P2NMP uses the same list of pin constants defined in Spin2 v34Z documentation
Using Basic Stamp 2 Functions – import combo.py
OzFFS and the flash storage utilities – ozFFS quick reference (REPL or VGA/KB)
Built in flash storage utilities (VGA/KB). Attach keyboard and press F12 to access
Built in ozFFS editor. Access using F12 then select a file
Calling other code using the .CPU method
Compiling your own variant of MicroPython – config.h, Rogers Notes
Apart from the above things are moving along and I might post some video if I get the time.
Comments
Hi Unsoundcode,
Great, glad you got it running
I believe its built into the image itself. If you type 'import combo.py' at the Micropython prompt you should see it bring in new functions
Its not an assembler, but a way of spinning up another cog using a binary image. There's still the problem of how to communicate with that cog once its running alongside Micropython. One way is via a smartpin in repository mode
Accessing the OzFFS should just be from pressing F12 on the keyboard. It is primarily a way of preserving code that you type in, for the next session after rebooting.
@Tubular thanks for the response, I watched your Micropython/P2 presentation btw which was one of the things that inspired me to have a go at it myself.
As for combo.py I see it nowhere, I even went back and looked at the Git repository.
The "Further Information" text makes it sound like attaching a keyboard and pressing F12 should bring up ozFFS utilities and a file editor but nothing I do makes that happen. The closest thing I have found to a file system is the SPI Flash which has three commands
savefiles and `delete, these three commands operate on the code files in the Mu Code editor and save/view/delete them to flash. I have not figured out how to read and write from this flash using Python code.The Cpu command sounds interesting but I don't think I'm going to need that for a while.
These things may come to light in the near future in the mean time I have other experimentation to try. What I would like to do is share my limited knowledge from square one, the blinking light maybe, with others in the same situation. I just hope I don't hit a brick wall before it becomes useful.
I'll sign off with one last thing, I see no UART object and I wondered why this was left out.
I don't think we ever read/wrote to the flash from the python code, but it should be possible to do this using generic Micropython code. You'll just have to be careful to avoid upsetting ozFFS use of flash, if you're trying to use both systems.
Regarding the uart, its perhaps because we are using the smartpins to do the heavy lifting. The bs2 _functions would shed some light on it, I'll see Brian in a few days and we'll figure it out. We definitely had serial in/out but it was probably using a different technique
The P2 seems such a good microcontroller I thought if I could gain access to just a fraction of its features by using Micropython then I might have something better than an ESP32 or a Micro:bit using the same language. Unfortunately this port of Micropython is outdone by the ESP32 and the Micro:bit, it is possible there is documentation that is more specific to P2NMP that I have been unable to find. I remain hopeful things might change until then I will put this project on hold.
Hi Unsoundcode,
I guess to understand this situation best we need to talk about the history.
As you discovered Micropython on P2 is a little limited, somewhat due to lack of time committed to the project as well as other reasons. I think the original native port itself was done in about 20-30 hours of actual (i.e billable) work or something like that. Most of that was customizing/debugging a toolchain just to be able to build it and not much time for working on the library side (which is the most useful part to a user). Since then there hasn't really been a lot of traction that we've seen on this to date that justified working on it more. You are one of the handful who've tried it out and responded. Further improvements could potentially be done with effort but we do have many restrictions. I ported v1.13 of MP using the customized tools and Makefiles and to tell the truth we were lucky really just to get something working at all (think hacks on top of hacks for the build process). Native P2 really needs a proper GCC compiler for the P2. We did have some earlier toolchain work (p2gcc) done by Dave Hein to be able to use the GCC compiler for P1 and then translate its P1 output code into P2 code but again that effort has been discontinued, and it wasn't ever an ideal solution, and doesn't make full use of the true power of the P2. Also, so far my own old Macbook Pro running OS X 10.10 is the only device I know that can build these MP images, although I tried to document the requirements in case others were keen enough to try to reproduce what I did to take it further. Maybe some lurkers have managed it...who knows. You have to be fairly dedicated to want to attempt it.
Compared to the full extent of what the P2 can offer only basic P2 features were exposed in the limited time allotted and there wasn't an existing MP driver model around that really suited the P2. IIRC we did add soft SPI and soft I2C and support configuring Smartpin based IO (very useful), non-MP COGs can be spawned (thanks to Eric's solution) and files can be read off SD, but that's probably about it. Brian (ozPropDev) also added his custom flash driver and did some other serial console aspects which were separate and put on top of the raw MP interpreter that I provided, for more of a standalone experience, but I wasn't directly involved in those parts.
Another issue is that over time MP has moved on from the original version we had ported and no further resources have been committed to try to keep the P2 up to date with that, so it is out of date these days. Perhaps there are other MP features that now make sense, given as I understand there is some support for multi-cores now (eg. Raspi Pico) but I've not been following along. Chips like the ESP32 and Pico's RP2040 and the STM32 stuff get all the attention and have lots of contributors, but AFAIK we don't have any people other than myself and Eric Smith with his RISC-V emulated version who've done much MP toolchain dev work on the P2. It's just not enough resources unfortunately.
I do think MP for P2 could be so much better if we had a decent P2 GCC compiler and people could easily build it and improve it themselves. It could be wonderful to also make use of the large external PSRAM memory for huge MP programs and for storing import library stuff etc. If the P2 memory model in GCC also allowed some data to come from external RAM and we just kept the MP executable in HUB RAM as well as COG code and stacks for each core we could do multi-core MP nicely. Otherwise there is limited HUB RAM to split over multiple COG instances of the interpreter, and we'd need to have all the heaps and stacks and programs competing for the 512kB of HUB RAM. The other micro's have the benefit of separate flash and RAM spaces, which gives more opportunities for increased memory resources on the RAM side.
That's basically where the situation is at right now, at least as I see it. Hope this helps explain things for you Unsoundcode.
Cheers,
Roger
@rogloh thank you for your extensive and in depth post. It's like a breath of fresh air to be told about the difficulties involved, most of which is over my head, I wish that some of what you have explained was detailed on the product page so that prospective buyers were aware that MP was not very useful on the P2 atm.
My previous post was a summary of what I have learnt over the last week or so and I would be lying to say there was not a hint of frustration in my text but that was due to not being able to get things to work as I had expected and being unable to get any feedback as to why. I still remain hopeful, if it should ever happen I may apply as a beta tester.
Once again thanks for your lengthy response.
No problem. I would like to ask, which parts do you feel need to be added the most? Basically what are you missing (other than soft-UART) that you would like to see on a P2 variant of MP should this work ever continue at some stage?
Also there is more readme information here in case you didn't find it. Somewhat buried down in the tree unfortunately. This stuff is how to build native Micropython for the P2 (not how to use it). It is aimed at potential developers of the interpreter who could improve the port further.
https://github.com/team-oz/p2-native-micropython/tree/p2native/ports/p2
@rogloh How hard would it be to change VGA basepin to 8 and add USB keyboard/mouse support. Or, is USB support already there?
@rogloh my first encounter with micropython was here on these forums using the Micro:bit. I loved the way I could get things, things that are usually quite complex, up and running in a speedy fashion. So it seemed to me that a natural progression would be to move to the P2 running MP which runs a great deal faster, has a built in SD card access to additional USB, lots of GPIO and I really love the P2-ES Eval Board Accessory Set. This progression would be a win win for anyone like me that has a little Python experience but feels daunted with the prospect of having to learn another microcontroller language.
Here is a bullet list of what would make the P2 more enjoyable/functional for me. I have to say that I am not dismissing spin2 altogether, by that I mean I would like to see a lot more documentation on the CPU command, I am not 100% sure on how it works but I suspect it has something to do with talking between cogs and languages which again is a part of the progression and an intriguing possibility.
Some of these items may already be there if they are I can't get them to work with the standard micropython documentation.
The four items above would get me a long way, I have yet to try analog, pwm, I2C I will do that later.
Even something a little buggy would be ok by me in the short term.
I will take a look at the link you provided but I feel it may be out of my realm.
Hi,
If you are looking for an interactive Environment for P2 then I can recommend to have alook at Taqoz Forth. Forth is very much simpler than Python and for human reading it might feel weird at first and second glance. But the simplicity brings a huge advantage of speed and the code is very much more compact. So with Forth you will not need any external RAM. Taqoz has Sd support, inline Assembler, Vga, on board and you can load and compile the code parts, which are needed in your project so you don't need too much Ram. Taqoz also fully supports the usage of multiple cogs, which is probably the reason to choose the P2 controller.
While I do use Micropython or Phyton if I can use their powerful libraries, I think, Forth fit's much better to P2. Just another opportunity....
Christof
Probably a question for @ozpropdev who did the integration work for standalone operation. I'd expect it may be possible if the USB code can all fit in the free HUB space. P2 USB would have come a long way from what was running in the early MP days after everything Wuerfel_21 and macca did to the driver and more devices would be working now with hub support etc.
Note: This is all custom add on stuff as there is no framework for it in MP itself, which has no real concept of video and mice.
Yeah it controls code loaded onto other COGs. Some stuff that talks about it is in a thread I've mentioned a bit further on.
Not present. P2 "UART" pins are dedicated to the console. There is no driver for additional UART pins included in the build.
Soft SPI should be present in this build.
Certainly present. Some information on how to access it was in this thread (which covered a lot of things during MP development work that Eric and I both did on our different versions and could be useful to browse through - it sort of has the history of what was done really).
https://forums.parallax.com/discussion/comment/1471821/#Comment_1471821
also
https://forums.parallax.com/discussion/comment/1483425/#Comment_1483425
also
https://forums.parallax.com/discussion/comment/1484009/#Comment_1484009
Should be possible to read/write from SD if you setup the pins and mount the drive. There have been problems in the past with competing with flash IO pins and choice of microSD card which complicate things further. SD on the P2 in general can be quite hit and miss unfortunately.
Whilst MP has its own driver model/API for PWM, DAC, ADC peripherals in microcontrollers, based on the short time allocated these APIs were not directly mapped to P2 HW in this release, only Smartpin IO pin control has been provided which can mostly achieve the same things but needs some knowledge of P2 Smartpin capabilities first in order to achieve it. IIRC ozpropdev also had a Python layer that interacts with this to use Smartpin based IO. Not sure of what DAC/ADC features were provided.
Soft I2C was included in the build IIRC.
Not sure it's that buggy per se but mainly lacking some features, particularly the more recent stuff.
Yeah, this information was intended for people who want to build the MP environment themselves.
@Unsoundcode I just checked the zip file in the Parallax getting started link in your top post. I found the binary called python_soft_spi_i2c.bin inside it.
Here's what I see when I load it to the P2. It appears to include I2C and SPI and SDCard object methods you are looking for. Maybe that's the version you need to use...? I'm not entirely sure what was built into the other images released by ozprop and Tubular when they took my code and added their parts.
In this particular image it looks like I added some other niceties like the ability to read and write HUB ram, reset the chip, signal other COGs with COTATN, and includes the inbuilt P2 HW random number generator, and the Cpu stuff that Eric created, as well as all the Smartpin stuff in the Pin object and a few other things. If I get a chance later today I'll try to do some of the SPI and I2C stuff to see if it is active. As I recall these are just layers that are built on top of the Pin object using bit banged IO, nothing we've written ourselves. It's part of MP itself.
roger@RLs-Mac-mini py % loadp2 -t python_soft_spi_i2c.binEDIT: can't paste the log without major formatting messups, so had to screen cap instead.
Well soft I2c appears to be functional as I remembered from a while ago...I created an I2C object on pins 56 and pin57 and had a look on the scope at these pins. Didn't have any real I2C devices attached, just looking at signals generated by the scan. Seems to be doing the business.
Not as sure with SPI. Object appears to be present but might be clashing with SD card/flash pins. I don't really know the correct syntax to fire one up.
Edit: okay just figured out the syntax for software SPI for the P2 NMP. This seems to be generating data too. When I read it I just got $ff as nothing was attached but I could see clocks were generated. Capture of two byte write of string "12" is attached. Looks like you need to manually control your own chip select pin too, that's not part of the software SPI stuff.
@rogloh that is an interesting comment about soft spi, I have seen it in the P2NMP zip but I don't know how to load it into the P2 flash, how would I do that on a Windows machine.
You first need to get loadp2 working on your PC. If you install flexspin/flexprop you would hopefully get that utility as part of it. But I use a Mac.
See here...
https://github.com/totalspectrum/flexprop/releases
ps. I updated the above and figured out Soft-SPI in case you read the original post before I figured it out.
Also there may be issues with flashing large image sizes, it is difficult to flash a large image on the P2 IIRC. @Tubular do you know the process that works? I think this was a problem once before fairly recently...Update: here it was: https://forums.parallax.com/discussion/comment/1551532/#Comment_1551532
@"Christof Eb." thanks for the input, I will definitely try that out at some time.
@rogloh looking at the soft spi bin file I think I will steer away from that avenue for now and stick with the original port. I had tried code similar to your SPI example and had no luck but today I tried it again and got some better results, I haven't used hardware yet so all I have is a screen shot from a logic analyzer.
Trying I2C with a small EEPROM I2C.scan() returned an empty list so I'm not sure whats going on there so I'll work more on the SPI at least I seem to be getting some results.
Here is the code that matches the screen shot
from machine import Pin,SPI from time import sleep_us cs=Pin(24,Pin.OUT,value=1) spi= SPI(baudrate=1000000, sck=Pin(25), mosi=Pin(26), miso= Pin(27)) for _ in range(3): cs(0) spi.write(b'12345678') cs(1) sleep_us(2)Good you seem to be making some more progress now Unsoundcode. For this sort of work I find I often need to persevere and then will get there in the end. Giving up early is like throwing the baby out with the bathwater.
Hooked up an i2c RTC chip (DS1337) to the P2 pins, and ran it at 3.3V (which it allows) and ran a MP scan on the i2c bus.
Seeing some truly weird behaviour on the pins during the scan, which may explain the lack of a response.
Not sure what is happening here. Maybe just the peripheral is bad, or the fact I don't have pullup resistors fitted (and expecting MP to enable pin pullups). I can't understand why a scope would show multiple voltage levels like this on the clock line part way through a transaction. Floating a pin should rise/fall exponentially not sit at these intermediate levels.
Update: will try to add some pullups to see if that helps.
EDIT: Doh! Bad eyes. Was off by one pin and was attached to the RTC's 32.768kHz open collector output which was clashing with the clock pin driven by the P2. After fixing that the waveform is good now, but I still don't see devices in the scan list. Need to hook logic analyzer up for a bus decode.
EDIT2: okay might have a dead RTC device, it doesn't appear to ACK the write to address D0 when it should in the scan or maybe the SDA line from the P2 is not tri-stating correctly and allowing the ACK to occur by default. Will have to play with pin modes to try to see if that helps...
Ok found the I2C problem. @Unsoundcode you need to make sure that the P2 pin for SDA is in an open drain compatible state. On the P2 without external pullup resistors you can simulate this with the logic high level being driven through a 1.5k pullup internally in the P2. Ideally you also want to have the clock pin allow open drain too to allow for clock stretching but I don't know whether or not the MP implementation supports that feature.
To get an i2c bus scan result I turned on the 1k5 output drive resistor for the SDA pin and it responded.
If you really want to open drain a pin I imagine you could use machine.Pin.P_HIGH_FLOAT instead, and there is also a weaker 15kohm option too using machine.Pin.P_HIGH_15K. There is also the concept of a pin state in MP that can be set to OPEN_DRAIN as well, I just haven't tried that method. That's probably the official MP way to setup the pin I imagine. If you have external pullup resistors you could try this to see if it works (it didn't for me but I still don't have pullups in my setup).
EDIT: So it just worked for me when I temporarily handheld a pullup resistor to the SDA pin configured for OPEN_DRAIN and set the clock pin to use an internal pullup so I expect it should work with 2 pullups this way and both I2C pins in OPEN_DRAIN mode. I just can't easily test it without some actual soldering or four hands.
I can also see my RTC seconds ticking when I dump the registers so it looks like the I2C reads are really working...
@rogloh good info thanks, before I toss the baby I will try with the internal pin settings. For the test I did I just had two resistors pulled high on scl and sda.
My main obsession right now is to do a little more with SPI/SDCard. I tried to mount an Adafruit SPI SMT 512M SD and I get the error soft_SPI does not have "readblocks", that was late last night I'm hoping to get back to it sometime today.
I appreciate your willingness to provide help.
Yeah in addition to that, maybe you can also try with the OPEN_DRAIN setting enabled on the Pin when you create it too if you had physical resistors. If you miss that step I know it doesn't work - well it didn't for me as it drives the bus pins high and won't let the scan detect the ACK for a device.
Yeah not sure about that, perhaps some limitation with how soft_SPI is connected to the filesystem vs physical SPI bus internally in MP... or you may want to try other devices and/or see what is happening on the SPI with you logic anayser (if anything). If you use the 4 P2 pins associated with the P2 boot flash you might get better results too, but mixing flash and SD on the P2 can be troublesome in general.
No problem, but it will tap out at some point if I can't figure it out...