@Rayman said:
Think fixed 640x480 VGA by changing cell size from 8 to 4. Hopefully that problem doesn't come back...
Did you change all the definitions in vgatext.h? That's where the screen is defined (it's the screen_buffer member of the vgatext structure). Alternatively, if you change them in vgatext.spin you can then regenerate vgatext.c and vgatext.h by running spin2cpp on the .spin file.
@ersmith Now including them in makefile with name that says the resolution.
The 640x480 was fine until I added some more code to the binary, then it went off the rails...
But, changing cell size seemed to fix it and foreground and background colors still look good.
Added some extra superfluous code to binary and still looks good.
@Rayman said:
@rogloh that is quite a bit of memory…
I see mention of code compression in @ersmith docs but don’t really know if that is enabled here or not, or how much that would reduce the overhead.
Perhaps it is worth thinking about going back to more basic things... It is possible and very much less complicated to use a block file system. Just load a number of consecutive sectors starting from a sector number x. Such "file system" can be achieved with perhaps 1k of code and it can achieve so very much....
In Taqoz there is a more "advanced" compromise. No subdirectories and files cannot have scattered sectors and therefore claim a maximum file size when created.
Just figured out how to use/abuse the CSR hooks in RISCVP2 to enable adding a rgbpixel() function to the p2 module.
The docs say "0xbc4-0xbc7: available for hooks", but 0xbc4 looks occupied by a uart monitor, so using 0xbc5 for the code below.
@ersmith How much code can I add here before things go off the rails?
One problem is that these functions only take one parameter. I'm sending color. But, would like to send color, pin#, and #leds in string...
Hmm... Maybe can do 16-bit color and then use the other two bytes for pin# and #leds...
rgbled_read_csr
ret
rgbled_write_csr
drvl #28'pin ' make pin output/low
'for clkfreq = 160 MHz, 1us = 160 ticks
waitx ##160*50 'reset ' allow reset
'looks like input comes in on pb
shl pb,#8 'shift all the way left
.pixloop
mov temp,pb ' get pixel dat
movbyts temp, #%%2310 ' swap red & green
getct pb ' initialize bit timer
.bitloop
rep #7, #24 ' loop through 24 bits
shl temp, #1 wc ' get MSB
drvh #28'pin ' pin on
if_nc waitx ##160*400/1000'b0tix ' hold for bit timing
if_c waitx ##160*800/1000'b1tix
drvl #28'pin ' pin off
addct1 pb,#200'ticks, bittix ' update bit timer
waitct1 ' let bit timing finish
'djnz n,#.pixloop ' update count, continue if more
ret
Ok, got it working by packing pin#, #leds in strip, and 16bit color into one long and then invoking the riscvp2 CSR#5 (code for that posted here).
Added some color constants too.
So, can now do this to set a 2 led long string on P28 to orange:
import p2
p2.setpix(28,2,p2.ORANGE)
Here is the micropython routine to call it:
//set rgb pixel strip
STATIC mp_obj_t p2_setpix(mp_obj_t pin_in, mp_obj_t nled_in, mp_obj_t clr) {
int rgb24=mp_obj_get_int(clr);
int r=(rgb24>>16)&0xFF;
int g=(rgb24>>8)&0xFF;
int b=rgb24&0xFF;
int rgb = ((r>>3)<<11)|((g>>2)<<5)|(b>>3);
rgb = rgb & 0xFFFF;
int pin=mp_obj_get_int(pin_in);
int nled=mp_obj_get_int(nled_in);
int command = ((pin&0x7F)<<24)+((nled&0xFF)<<16)+rgb;
//printf("RGB= %x Command= %x\r\n",rgb,command);
_csr_write(0xbc5, command);
return mp_const_none;
}
STATIC MP_DEFINE_CONST_FUN_OBJ_3(p2_setpix_obj, p2_setpix);
@"Christof Eb." uSD support is baked in with fatfs, so it’s rock solid. Automagically mounts on boot even. There is a long file name usage issue that have to address at some point though. Not tested directories but imagine can fully use those already.
However to boot a binary file, might want to stop all that, assume the files blocks are contiguous and use the FSRW block driver cog to load into hub and then reset.
Maybe you could use Chip's flash driver instead of little FS - would be a lot smaller. But it would require some fairly deep object integration between C & PASM2 to be able to make proper Micropython file system calls, so it'd be rather tricky to achieve. Spawning a dedicated COG would be simpler, but you'd have to manage your own file system IO then...messy.
Ray congrats on getting this all fired up and running again
I've been attending the monthly MP meetups, but there hasn't been a whole lot of relevant new stuff for the P2, until recently. In the next release (v1.23) we're getting both USB (Tinyusb) framework, and also OpenAMP support (multiple processors), both of which will be super useful from a P2 perspective.
Yes I'm thinking it would be good to dust these off again, is there a reason you're only on v1.12 Ray? Now that that you have it building successfully it might be worth trying the version that includes LittleFS
I'll try and find out how far off 1.23 might be. The milestone list shows only 3 items to complete, but it blows out every now and then
Yes, the MP version. Between version 1.12/1.13 and now there haven't been many features that would benefit the P2 in a big way. However the next release 1.23 will have USB device framework, as well as the OpenAMP support for multiple cores. Hopefully it won't be too much longer before release.
You're right the littlefs was baked into that version you're using. I don't think we used it, OzPropDev had his own flash file system with some wear levelling, iirc.
If/when we get MP 1.23 working, it might be worth trying to get it onto the 'main line' of the MP releases, so P2 would then be another port along side the other ports included in each release. I've asked the question as to what's involved to make this happen.
@Tubular That does sound good. Do wonder if the new features are targeted at a particular chip. It seems like Micropython is mainly targeted at the Pyb board and whatever chip it uses. But, does allow for other chips.
Imagine this is the reason that Adafruit made their own version...
Just compiled with 297 MHz P2 clock version of RiscVP2. 160 MHz just seems to conservative these days.
Would like to use 300 MHz, but want to allow for 1080p/720p display with picky monitors...
Anyway, good news is that terminal interface works and VGA works.
uSD is broke bad though. Won't boot if uSD is inserted.
I'm sure USB is broke too, but want to update that with newer version that autocorrects for clock anyway.
While googling micropython robots, stumbled across Lego page where using Blockly to create Python code for robot.
This is kind of interesting...
I see now that Blockly can natively create Python 3 code...
Added Ping(pin) function to P2 module. Returns millimeters of distance using ultrasonic Parallax Ping device.
There is surprisingly little P2 code around for this but found something here: https://forums.parallax.com/discussion/174320/flexbasic-p2-ping
It's a little difficult to code stuff like this because a lot of things are missing in the RiscVP2 version of Propeller2.h...
//Ping (based on post by JonnyMac and Parallax documentation)
STATIC mp_obj_t p2_ping(mp_obj_t pin_in) {
int pin=mp_obj_get_int(pin_in);
int d;
int cnt;
//pinclear(pin); //don't have pinclear in riscvp2 version
_pinf(pin);
_wrpin(pin,0);
_pinh(pin);
_waitus(5);
_pinl(pin);
_waitus(5);
//pinstart(pin,P_HIGH_TICKS,0,0); //don't have pinstart either
_pinf(pin);
_wrpin(pin,P_HIGH_TICKS);
_wxpin(pin,0);
_wypin(pin,0);
_pinh(pin);
cnt=_cnt();
for (;;)
{
if ((_cnt()-cnt) > (25*(_clockfreq()/1000)))
return mp_obj_new_int(0);
d=_pinr(pin);
if (d>0)
{
d=_rdpin(pin);
d=(d/(_clockfreq()/1000000))>>1; //microseconds
d=d*331500/1000000; //millimeters
printf("ping = %d\r\n",d);
return mp_obj_new_int(d);
}
}
//should never get here...
return mp_obj_new_int(0);
}
STATIC MP_DEFINE_CONST_FUN_OBJ_1(p2_ping_obj, p2_ping);
Shoot, just noticed above returns negative numbers for distances above ~1.6 meters... Have to tweak it a bit..
Ok, all better now... d=d331500/1000000; --> d=d3315/10000;
Also, fixed the timeout to a simpler 100ms
Seems ping doesn’t actually time out? But if ping not connected then code would freeze without the timeout
Started looking at uPython versions again...
Can compile up to v1.19...
Above that, can't get past this error yet: Wrong configuration file (ffconf.h).
There's some magical stuff in there that I don't understand yet...
Just reading notes on v1.20 and this looks interesting:
A new port has been added, the "embed" port, which is a port of MicroPython that targets the C language and outputs a set of self-contained .c and .h files for embedding into a wider project. An example is provided to show how this works.
So, 1.19 compiles fine, but my P2 module is missing somehow... I'm in over my head here for sure...
Oh wow 1.18 is actually pretty good going, quite a leap. Well done
There's a micropython discord with some friendly dev people who might be able to help get 1.19 or 1.20 going. I'll ask Damien whether we can have a P2 discussion area on the discord, it would probably help no matter how this goes from here
After doing a bunch of windiff on the files and reading change logs, not really convinced anything substantive is changing here…. They move the same files into different folder names and things like that. And change the names for defines and stuff like that…. But need to look more carefully…
In reading changelog and stuff for 1.20 it seems like a major change, but not in anything that helps us here I think...
Seems that most of it is optimizing for .mpy files that we can't use.
The rest of it is for other microcontrollers...
So, think I'll just sit at 1.19 for now.
Plus, the changes needed to get 1.20 working seem to be beyond my skill set...
Comments
Did you change all the definitions in vgatext.h? That's where the screen is defined (it's the screen_buffer member of the vgatext structure). Alternatively, if you change them in vgatext.spin you can then regenerate vgatext.c and vgatext.h by running spin2cpp on the .spin file.
@ersmith Now including them in makefile with name that says the resolution.
The 640x480 was fine until I added some more code to the binary, then it went off the rails...
But, changing cell size seemed to fix it and foreground and background colors still look good.
Added some extra superfluous code to binary and still looks good.
Perhaps it is worth thinking about going back to more basic things... It is possible and very much less complicated to use a block file system. Just load a number of consecutive sectors starting from a sector number x. Such "file system" can be achieved with perhaps 1k of code and it can achieve so very much....
In Taqoz there is a more "advanced" compromise. No subdirectories and files cannot have scattered sectors and therefore claim a maximum file size when created.
Cheers Christof
Just figured out how to use/abuse the CSR hooks in RISCVP2 to enable adding a rgbpixel() function to the p2 module.
The docs say "0xbc4-0xbc7: available for hooks", but 0xbc4 looks occupied by a uart monitor, so using 0xbc5 for the code below.
@ersmith How much code can I add here before things go off the rails?
One problem is that these functions only take one parameter. I'm sending color. But, would like to send color, pin#, and #leds in string...
Hmm... Maybe can do 16-bit color and then use the other two bytes for pin# and #leds...
rgbled_read_csr ret rgbled_write_csr drvl #28'pin ' make pin output/low 'for clkfreq = 160 MHz, 1us = 160 ticks waitx ##160*50 'reset ' allow reset 'looks like input comes in on pb shl pb,#8 'shift all the way left .pixloop mov temp,pb ' get pixel dat movbyts temp, #%%2310 ' swap red & green getct pb ' initialize bit timer .bitloop rep #7, #24 ' loop through 24 bits shl temp, #1 wc ' get MSB drvh #28'pin ' pin on if_nc waitx ##160*400/1000'b0tix ' hold for bit timing if_c waitx ##160*800/1000'b1tix drvl #28'pin ' pin off addct1 pb,#200'ticks, bittix ' update bit timer waitct1 ' let bit timing finish 'djnz n,#.pixloop ' update count, continue if more retOk, got it working by packing pin#, #leds in strip, and 16bit color into one long and then invoking the riscvp2 CSR#5 (code for that posted here).
Added some color constants too.
So, can now do this to set a 2 led long string on P28 to orange:
Here is the micropython routine to call it:
//set rgb pixel strip STATIC mp_obj_t p2_setpix(mp_obj_t pin_in, mp_obj_t nled_in, mp_obj_t clr) { int rgb24=mp_obj_get_int(clr); int r=(rgb24>>16)&0xFF; int g=(rgb24>>8)&0xFF; int b=rgb24&0xFF; int rgb = ((r>>3)<<11)|((g>>2)<<5)|(b>>3); rgb = rgb & 0xFFFF; int pin=mp_obj_get_int(pin_in); int nled=mp_obj_get_int(nled_in); int command = ((pin&0x7F)<<24)+((nled&0xFF)<<16)+rgb; //printf("RGB= %x Command= %x\r\n",rgb,command); _csr_write(0xbc5, command); return mp_const_none; } STATIC MP_DEFINE_CONST_FUN_OBJ_3(p2_setpix_obj, p2_setpix);@"Christof Eb." Yes, very basic use of flash is certainly easy. But wouldn’t have wear leveling…
But if littlefs is already in the binary, might not need much more space to be awesome….
Was thinking about sd card, where wear levelling is handled by its controller.
@"Christof Eb." uSD support is baked in with fatfs, so it’s rock solid. Automagically mounts on boot even. There is a long file name usage issue that have to address at some point though. Not tested directories but imagine can fully use those already.
However to boot a binary file, might want to stop all that, assume the files blocks are contiguous and use the FSRW block driver cog to load into hub and then reset.
Maybe you could use Chip's flash driver instead of little FS - would be a lot smaller. But it would require some fairly deep object integration between C & PASM2 to be able to make proper Micropython file system calls, so it'd be rather tricky to achieve. Spawning a dedicated COG would be simpler, but you'd have to manage your own file system IO then...messy.
Got RELP interface over WiFi going. Testing with the Parallax WiFi SIP module...
This could be very useful for certain applications...
Uses a slightly hacked version of simplestserial.
Ray congrats on getting this all fired up and running again
I've been attending the monthly MP meetups, but there hasn't been a whole lot of relevant new stuff for the P2, until recently. In the next release (v1.23) we're getting both USB (Tinyusb) framework, and also OpenAMP support (multiple processors), both of which will be super useful from a P2 perspective.
You can see what's getting baked into the next release (v1.23) here,
https://github.com/micropython/micropython/milestone/6
And some details on OpenAMP here,
https://docs.micropython.org/en/latest/library/openamp.html
And USB here
https://docs.micropython.org/en/latest/library/machine.USBDevice.html
@Tubular that looks pretty great.
That’s the PropGCC version I presume.
Maybe good to get both versions going again, seems like some dusting off needed..
Its applies to either version really.
Yes I'm thinking it would be good to dust these off again, is there a reason you're only on v1.12 Ray? Now that that you have it building successfully it might be worth trying the version that includes LittleFS
I'll try and find out how far off 1.23 might be. The milestone list shows only 3 items to complete, but it blows out every now and then
Ok, so pretend I don’t know what versions mean here in this context...
I think littlefs is included here though…
See it in the filenames anyway….
Connecting it to flash or anything useful might be a different story…
@Tubular ok you must mean version of MicroPython itself…
I guess you are pointing out some new features
Yes, the MP version. Between version 1.12/1.13 and now there haven't been many features that would benefit the P2 in a big way. However the next release 1.23 will have USB device framework, as well as the OpenAMP support for multiple cores. Hopefully it won't be too much longer before release.
You're right the littlefs was baked into that version you're using. I don't think we used it, OzPropDev had his own flash file system with some wear levelling, iirc.
If/when we get MP 1.23 working, it might be worth trying to get it onto the 'main line' of the MP releases, so P2 would then be another port along side the other ports included in each release. I've asked the question as to what's involved to make this happen.
@Tubular That does sound good. Do wonder if the new features are targeted at a particular chip. It seems like Micropython is mainly targeted at the Pyb board and whatever chip it uses. But, does allow for other chips.
Imagine this is the reason that Adafruit made their own version...
The Pyb and Pyb-D use STM32 processors, I think that's what Damien prefers.
The USB code coming up is mainly targeting RP2040 and SAMD devices, I believe.
Not really sure why Adafruit did CircuitPython tbh
Just compiled with 297 MHz P2 clock version of RiscVP2. 160 MHz just seems to conservative these days.
Would like to use 300 MHz, but want to allow for 1080p/720p display with picky monitors...
Anyway, good news is that terminal interface works and VGA works.
uSD is broke bad though. Won't boot if uSD is inserted.
I'm sure USB is broke too, but want to update that with newer version that autocorrects for clock anyway.
Thought this might fix uSD, but didn't:
Seems to be working after this though:
While googling micropython robots, stumbled across Lego page where using Blockly to create Python code for robot.
This is kind of interesting...
I see now that Blockly can natively create Python 3 code...
@ersmith Used spin2cpp on newer USB code and see a message:
warning: PASM code must be relocated at run time; you may need to manually tweak the C/C++ output if attribute((constructor)) is not supported
I see there is this function in the output:
static void _doreloc(void) __attribute__((constructor)); static void _doreloc(void) { static int done = 0; if (!done) { _dorelocs( (uint8_t*)&dat[0], &_reloc_dat[0]); done = 1; } }Do I need to call this somehow, or is it somehow automatically done?
--> Ok, never mind. Think see do need to call this manually. Added that in and now USB seems to be working
Added Ping(pin) function to P2 module. Returns millimeters of distance using ultrasonic Parallax Ping device.
There is surprisingly little P2 code around for this but found something here:
https://forums.parallax.com/discussion/174320/flexbasic-p2-ping
It's a little difficult to code stuff like this because a lot of things are missing in the RiscVP2 version of Propeller2.h...
//Ping (based on post by JonnyMac and Parallax documentation) STATIC mp_obj_t p2_ping(mp_obj_t pin_in) { int pin=mp_obj_get_int(pin_in); int d; int cnt; //pinclear(pin); //don't have pinclear in riscvp2 version _pinf(pin); _wrpin(pin,0); _pinh(pin); _waitus(5); _pinl(pin); _waitus(5); //pinstart(pin,P_HIGH_TICKS,0,0); //don't have pinstart either _pinf(pin); _wrpin(pin,P_HIGH_TICKS); _wxpin(pin,0); _wypin(pin,0); _pinh(pin); cnt=_cnt(); for (;;) { if ((_cnt()-cnt) > (25*(_clockfreq()/1000))) return mp_obj_new_int(0); d=_pinr(pin); if (d>0) { d=_rdpin(pin); d=(d/(_clockfreq()/1000000))>>1; //microseconds d=d*331500/1000000; //millimeters printf("ping = %d\r\n",d); return mp_obj_new_int(d); } } //should never get here... return mp_obj_new_int(0); } STATIC MP_DEFINE_CONST_FUN_OBJ_1(p2_ping_obj, p2_ping);Shoot, just noticed above returns negative numbers for distances above ~1.6 meters... Have to tweak it a bit..
Ok, all better now... d=d331500/1000000; --> d=d3315/10000;
Also, fixed the timeout to a simpler 100ms
Seems ping doesn’t actually time out? But if ping not connected then code would freeze without the timeout
Started looking at uPython versions again...
Can compile up to v1.19...
Above that, can't get past this error yet: Wrong configuration file (ffconf.h).
There's some magical stuff in there that I don't understand yet...
Just reading notes on v1.20 and this looks interesting:
A new port has been added, the "embed" port, which is a port of MicroPython that targets the C language and outputs a set of self-contained .c and .h files for embedding into a wider project. An example is provided to show how this works.
So, 1.19 compiles fine, but my P2 module is missing somehow... I'm in over my head here for sure...
Ok, seems can only get to 1.18 and have things work. Maybe not so bad though, only a couple years old...
Oh wow 1.18 is actually pretty good going, quite a leap. Well done
There's a micropython discord with some friendly dev people who might be able to help get 1.19 or 1.20 going. I'll ask Damien whether we can have a P2 discussion area on the discord, it would probably help no matter how this goes from here
After doing a bunch of windiff on the files and reading change logs, not really convinced anything substantive is changing here…. They move the same files into different folder names and things like that. And change the names for defines and stuff like that…. But need to look more carefully…
In reading changelog and stuff for 1.20 it seems like a major change, but not in anything that helps us here I think...
Seems that most of it is optimizing for .mpy files that we can't use.
The rest of it is for other microcontrollers...
So, think I'll just sit at 1.19 for now.
Plus, the changes needed to get 1.20 working seem to be beyond my skill set...