I think I've fixed the long int problems I had, so hopefully you won't need to go to such extremes to access the smart-pin registers now. One side effect of my change is that the readxval() method returns an unsigned integer rather than signed (so if the pin is in repository mode "p.xval(-1)" followed by "p.readzval()" will actually return 4294967295. I'm not sure if this is a good change or not; will it cause any problems for you?
I've also added floating point support, so you can use math.sin(), math.cos(), and the like.
Here's a binary that will program the P2-ES Eval boards SPI FLASH with Eric's micropython V6 image.
Make sure the "FLASH" dip switch is on before loading the binary.
LEDS 56 and 57 will show program completion and after 10 seconds the board will reset.
From there on micropython will boot on reset.
Thanks for checking this Brian. Yes, it was a constant that needed tweaking; there's a predefined array that determines how much RAM is available for the garbage collector. I've increased its size from 32K to 128K and updated the binary in the first post. It can still go a bit bigger, but OTOH we're also probably not adding features to the code yet, so it's probably wise to leave some space. We could also disable some features (like floating point) if we don't think they're needed.
I have been running all sorts of tests on P2 Micropython and it's looking good.
Any chance of getting a peek at how you got Micropython going on P2?
Cheers
Brian
Because OzProp's work is really interesting to watch, here's a quick video showing MicroPython digesting some new code.
There's a full hub memory map in the top half of the screen, and a zoom in memory block in the lower half. From what I understand the yellow and cyan 'V' sections are video buffers for the two vga screens being driven in 80x30 text mode. The magenta 'C' is Eric's Risc-V micropython binary, and the green below it is MicroPython heap which grows as the code is brought in and digested
Hey I think OzPropDev added some colour since the last time you showed it to me. Nice. Always handy to see live memory updates to help check memory/stack usage etc. This type of thing could come in handy as part of a more complete future debugger/monitoring system for MicroPython. How many COGs are used for it and what penalties/limits currently apply?
How many COGs are used for it and what penalties/limits currently apply?
Hey Roger
The current setup uses 3 cogs. 1 each for the two vga text displays and one for the memory monitor.
The VGA text drivers are jam packed with code,font data in cog/lut ram and generates video on the fly.
This means their hub impact is kept to ~5k each.
The memory monitor cog also has a full lut and has zero impact on hub memory use.
This sounds great Brian! So with this effort you can basically write Python code and run it fully standalone? Now that you added a console you probably want to add a filesystem to let you save it, is that next? Also is there a fast way to download Python code snippets from a UART etc or do you need to type it in? Sorry if these are basic questions, I've sort of forgotten what you had working last time I visited, and what HW/Cog access your MicroPython currently supports.
Interesting, Brian. Is the USB code fairly modular? I have a VGA driver already (in both original P2 and RISC-V forms) but the USB keyboard and mouse have eluded me so far.
I haven't had time yet to organize the micropython build environment, but it's basically a standard micropython build using an rv32im RISC-V toolchain and linked with the RISC-V emulator from my github repository (https://github.com/totalspectrum/riscvemu).
That's right Roger, you can type and run code without a PC terminal.
It still supports UART terminal paste mode as well, so downloads can be done from a PC too.
The "glue" that binds all these P2 code pieces together is a little messy.
For example to get the USB keyboard and VGA console working with Micropython required
some modification/patching of the existing Tx/Rx smart pins used by Micropython.
I redirect and intercept Rx/Tx pins to allow buffering and injection of data
into the data stream. The buffering was necessary for reliable downloads from PC @230400 baud.
Attaching a file system gets a little trickier, but I have a few ideas that might work.
Here's a .obj file that can be loaded onto a P2-ES Eval board.
Place the VGA accessory board on header pins 48:55 (top right header)
Pace USB accessory board on header pins 8:15 (lower left side)
Ok got that up and running. Bit of a false start because of an earlier micropython in the flash memory, but switched it off and now all is good.
Wow, real hosted micropython. Ironically I cannot find a USB keyboard at home to test with, only about 5 ps/2 keyboards. Perhaps as a result of this work of yours and GarryJ those keyboards can now be retired. Its super neat being able to enter commands either via terminal or USB keyboard, though
I notice there's a special bonus easter egg if you connect the VGA to P40~47 (debug screen). I found that by accidently connecting to the 'other' top right header
For others following along, just copy the .obj file to _BOOT_P2.BIX on the uSD card, and switch off flash (switch 2, only applies if you have something preloaded in flash) to boot the uPython from uSD.
I've updated the first post with a version having 192K of user memory. There's still a little bit of space left, but we also don't have USB or SD card support built in yet, so I don't know how much room we'll need for that.
I also fixed a few of the problems @ozpropdev noticed. There's still a crash with expressions like "1e39"; strangely, doing:
x = 1e38
10 * x
does seem to work correctly, so I'm not sure what's going wrong.
I have VGA code that I can plug in to upython easily enough. I don't have keyboard support though. Is there a stand-alone USB module with a reasonably simple interface that we could use to add keyboard support?
I think my next p2asm "lite" usb keyboard/mouse coming up should be pretty easy to incorporate. The .bin file is currently ~8KB, or less if a mouse is not needed.
I think my next p2asm "lite" usb keyboard/mouse coming up should be pretty easy to incorporate. The .bin file is currently ~8KB, or less if a mouse is not needed.
The Spin2 version of your driver sounds like it's exactly what I need (I can easily convert it to C with spin2cpp). I'm looking forward to it, thanks!
I've updated the zip file in the first post with a new version that supports VGA (via my VGA tile driver, the 800x600 version) and a USB keyboard (via @garryj's single COG USB driver, ported to C by me). The VGA is provided via the P2 A/V board plugged in to the pin group starting at 48, and USB via Port A on the Serial Host board plugged in to pin group 16.
Now all that's really left to make it a comfortable stand alone environment is sd card support.
I've updated the zip file in the first post with a new version that supports VGA (via my VGA tile driver, the 800x600 version) and a USB keyboard (via @garryj's single COG USB driver, ported to C by me). The VGA is provided via the P2 A/V board plugged in to the pin group starting at 48, and USB via Port A on the Serial Host board plugged in to pin group 16.
Now all that's really left to make it a comfortable stand alone environment is sd card support.
I've updated the zip file in the first post with a new version that supports VGA (via my VGA tile driver, the 800x600 version) and a USB keyboard (via @garryj's single COG USB driver, ported to C by me). The VGA is provided via the P2 A/V board plugged in to the pin group starting at 48, and USB via Port A on the Serial Host board plugged in to pin group 16.
Now all that's really left to make it a comfortable stand alone environment is sd card support.
and a USB keyboard (via @garryj's single COG USB driver, ported to C by me)..
Nice.
How does the C version compare with the Spin and p2asm versions in garryj's thread.
Should the C version be included in that thread's first post, with notes on Size/speed/ when to choose each version ?
Nice! Did you run into any issues integrating the usb keyboard object that I might be able to smooth out to make it easier?
Not really... the hard part was that the C translation (via spin2cpp) was producing a static array for the DAT section, but that needed to be relocated because there were references to HUB addresses. In theory loc was supposed to fix this, but loc only works if all the code is in the same code range (LUT, COG, or HUB) and obviously that wasn't the case here (and rightly so, COG and LUT are faster than HUB). So I had to add a simple relocator to spin2cpp. The only minor change I had to make to your code was to change a sequence like:
mov htmp, ##@h_lut_end - 4
sub htmp, ##@hlut_start
into:
mov htmp. ##(@h_lut_end-4) - @hlut_start
because the relocation couldn't handle AUGS prefixes; the second form doesn't need relocation (it's a constant).
and a USB keyboard (via @garryj's single COG USB driver, ported to C by me)..
Nice.
How does the C version compare with the Spin and p2asm versions in garryj's thread.
Should the C version be included in that thread's first post, with notes on Size/speed/ when to choose each version ?
The C version is a mechanical translation using spin2cpp. It's not necessary (at all) with fastspin, but I needed it because I wanted to compile the code with the Risc-V version of gcc. So it's probably not generally useful, although I suppose it might with some tweaking be usable under PropGCC or Catalina.
Comments
I think I've fixed the long int problems I had, so hopefully you won't need to go to such extremes to access the smart-pin registers now. One side effect of my change is that the readxval() method returns an unsigned integer rather than signed (so if the pin is in repository mode "p.xval(-1)" followed by "p.readzval()" will actually return 4294967295. I'm not sure if this is a good change or not; will it cause any problems for you?
I've also added floating point support, so you can use math.sin(), math.cos(), and the like.
The updated interpreter is in the first post.
Regards,
Eric
V6 improvements working nicely.
Unsigned result on readzval() seems OK to me.
Thanks again for your efforts!
Cheers
Brian
Make sure the "FLASH" dip switch is on before loading the binary.
LEDS 56 and 57 will show program completion and after 10 seconds the board will reset.
From there on micropython will boot on reset.
In PNUT you can load the binary simply by
def input(prompt): print(prompt,end="") m = "" key=pyb.Pin(63) key.read() while True: if key.read() == 1: q = key.readzval() >> 24 if q == 13: print() return m elif q == 8: if len(m) != 0: m = m[0:len(m)-1] print(chr(8)+" "+chr(8),end="") else: m = m + chr(q) print(chr(q),end="")and a esc key check that can be used to break while loops.def esc_pressed(): key=pyb.Pin(63) if key.read() == 1: q = key.readzval() >> 24 if q == 27: return True return FalseI seem to have hit a memory limit when running micropython.
I've been capturing P2's hub activity and here's the result.
The locations indicated by the "EE" markers (3b400) are the limit.
Hopefully it's simply a constant that needs tweaking.
Cheers
Brian
Cheers,
Eric
I found a few little issues with P2 Mucropython.
I've included comparison results from a Pybaord.
First one is the handling of infinite numbers. (Locks up)
The second one is the reporting of undefined labels.
When you have multiple labels in a line, helps to know which one.
and the third one and the most important is auto indentation is not working.
I have been running all sorts of tests on P2 Micropython and it's looking good.
Any chance of getting a peek at how you got Micropython going on P2?
Cheers
Brian
There's a full hub memory map in the top half of the screen, and a zoom in memory block in the lower half. From what I understand the yellow and cyan 'V' sections are video buffers for the two vga screens being driven in 80x30 text mode. The magenta 'C' is Eric's Risc-V micropython binary, and the green below it is MicroPython heap which grows as the code is brought in and digested
Here's a link to the video which would be too big to post here
https://drive.google.com/open?id=1xZ65tY-cwBPGlDr4T1Y2r9c90tEr1a6V
And here's a still photo of the screen
The current setup uses 3 cogs. 1 each for the two vga text displays and one for the memory monitor.
The VGA text drivers are jam packed with code,font data in cog/lut ram and generates video on the fly.
This means their hub impact is kept to ~5k each.
The memory monitor cog also has a full lut and has zero impact on hub memory use.
Just got my first quick and dirty version of a self hosted Micropython running on P2-ES.
Using a modified version of garryj's USB keyboard driver and a custom VGA 80*30 text driver
interfaced to hacked version of ersmiths's Micropython .
Having self hosted MicroPython, multiple monitors, usb keyboard is all sounding pretty compelling.
I haven't had time yet to organize the micropython build environment, but it's basically a standard micropython build using an rv32im RISC-V toolchain and linked with the RISC-V emulator from my github repository (https://github.com/totalspectrum/riscvemu).
It still supports UART terminal paste mode as well, so downloads can be done from a PC too.
The "glue" that binds all these P2 code pieces together is a little messy.
For example to get the USB keyboard and VGA console working with Micropython required
some modification/patching of the existing Tx/Rx smart pins used by Micropython.
I redirect and intercept Rx/Tx pins to allow buffering and injection of data
into the data stream. The buffering was necessary for reliable downloads from PC @230400 baud.
Attaching a file system gets a little trickier, but I have a few ideas that might work.
Here's a .obj file that can be loaded onto a P2-ES Eval board.
Place the VGA accessory board on header pins 48:55 (top right header)
Pace USB accessory board on header pins 8:15 (lower left side)
Wow, real hosted micropython. Ironically I cannot find a USB keyboard at home to test with, only about 5 ps/2 keyboards. Perhaps as a result of this work of yours and GarryJ those keyboards can now be retired. Its super neat being able to enter commands either via terminal or USB keyboard, though
I notice there's a special bonus easter egg if you connect the VGA to P40~47 (debug screen). I found that by accidently connecting to the 'other' top right header
For others following along, just copy the .obj file to _BOOT_P2.BIX on the uSD card, and switch off flash (switch 2, only applies if you have something preloaded in flash) to boot the uPython from uSD.
Any chance of more than that 128kB working memory? Asking for a friend who has some neat debugging code in Python
I also fixed a few of the problems @ozpropdev noticed. There's still a crash with expressions like "1e39"; strangely, doing: does seem to work correctly, so I'm not sure what's going wrong.
The Spin2 version of your driver sounds like it's exactly what I need (I can easily convert it to C with spin2cpp). I'm looking forward to it, thanks!
Now all that's really left to make it a comfortable stand alone environment is sd card support.
The source code for this is checked in to my github at https://github.com/totalspectrum/micropython.
Sounds good, Eric.
How does the C version compare with the Spin and p2asm versions in garryj's thread.
Should the C version be included in that thread's first post, with notes on Size/speed/ when to choose each version ?
Not really... the hard part was that the C translation (via spin2cpp) was producing a static array for the DAT section, but that needed to be relocated because there were references to HUB addresses. In theory loc was supposed to fix this, but loc only works if all the code is in the same code range (LUT, COG, or HUB) and obviously that wasn't the case here (and rightly so, COG and LUT are faster than HUB). So I had to add a simple relocator to spin2cpp. The only minor change I had to make to your code was to change a sequence like:
mov htmp, ##@h_lut_end - 4 sub htmp, ##@hlut_startinto: because the relocation couldn't handle AUGS prefixes; the second form doesn't need relocation (it's a constant).Thanks,
Eric
The C version is a mechanical translation using spin2cpp. It's not necessary (at all) with fastspin, but I needed it because I wanted to compile the code with the Risc-V version of gcc. So it's probably not generally useful, although I suppose it might with some tweaking be usable under PropGCC or Catalina.