That might be best. I got this idea from them though:
Internally in the source code the "STATIC" macro definition has been removed. Code should now just use "static" instead. If you have C/C++ code that uses "STATIC" then either replace it with "static", or provide your own #define to define "STATIC" as "static". See commit decf8e6 for details.
Got hard spi to compile. Copied from STM32 port, then commented out all the STM stuff.
It lists now, but doesn't have the actual code to do anything yet:
Tried to get soft SPI working, but couldn't figure it out.
There's only one sorta issue perhaps...
Had to comment out this check for soft spi because it depends on soft spi being present:
By the way, both propeller2.h and smartpins.h seem to be missing from your build files - I'm getting an error when trying to build from your zip file sources after installing and running your Makefile @Rayman . Should propeller2.h come from the P2 RISCV toolchain include files or are you obtaining it from elsewhere?
p2.c:13:10: fatal error: smartpins.h: No such file or directory
#include "smartpins.h" //RJA for smartpin constants
I've just moved propeller2.h from spin2cpp into /opt/riscvp2/include folder which will hopefully fix the missing propeller2.h file but don't see smartpins.h anywhere in the zip. EDIT: Ok grabbed it from spin2cpp as well.
@rogloh said:
I've just moved propeller2.h from spin2cpp into /opt/riscvp2/include folder which will hopefully fix the missing propeller2.h file but don't see smartpins.h anywhere in the zip. EDIT: Ok grabbed it from spin2cpp as well.
Nope
In file included from /opt/riscvp2/riscv-none-embed/include/propeller.h:4,
from platform.h:2,
from simplestserial.c:23:
/opt/riscvp2/riscv-none-embed/include/propeller2.h:78:4: error: unknown type name 'int32_t'
int32_t x, y;
^~~
/opt/riscvp2/riscv-none-embed/include/propeller2.h:83:4: error: unknown type name 'uint32_t'
uint32_t r, t;
^~~~
/opt/riscvp2/riscv-none-embed/include/propeller2.h:88:5: error: unknown type name 'uint32_t'
uint32_t low, high;
^~~~
-e See https://github.com/micropython/micropython/wiki/Build-Troubleshooting
make: *** [../../py/mkrules.mk:90: build/simplestserial.o] Error 1
Got further. I'd missed the step of doing the make install in the code that patches the RISCV toolchain with Eric's files. That copied the special propeller2.h file.
Just about got it building now apart from this link problem:
/opt/riscvp2/bin/../lib/gcc/riscv-none-embed/8.3.0/../../../../riscv-none-embed/bin/ld: build/extmod/modmachine.o: in function 'machine_idle':
modmachine.c:(.text.machine_idle+0x4): undefined reference to 'mp_machine_idle'
collect2: error: ld returned 1 exit status
make: *** [Makefile:115: build/firmware.elf] Error 1
Thanks I've been going about trying this exact thing. Am thinking some of these types of build problems relate to the use of the earlier and potentially outdated Makefile and/or mpconfigport.h formats.
Finally got it to build but needed to remove STATIC in the newly created mp_machine_idle function so it was visible to external modules (still got a warning from extmod/modmachine.c file though). I can try it out on real HW now.
LINK build/firmware.elf
text data bss dec hex filename
224514 12272 260148 496934 79526 build/firmware.elf
UPDATE:
Got it working with some small effort on a P2 Edge in my Bull Ant P2 setup. Mainly needed to patch base pins and disable USB which seems to be somewhat hard-coded. I found the included VGA driver is a bit jittery compared to what I'm used to with my own drivers and is not cleanly syncing to pixel edges on my monitor. Might be fractional clock related, not some nice integer multiple between the CPU and pixel clock frequencies as I typically use...
Noticed vga looking off when added Wi-Fi module so thought it was that. But still there with Wi-Fi module removed . If you see it too, must be something actually wrong …
Ok, VGA is looking perfect today at 252 MHz and 297 MHz. So, not sure what to do about that. I have been ignoring some compiler warnings though, maybe there's some random thing that can go wrong...
Now that I think about it... Way back when started, was having trouble with VGA to HDMI adapter not centering 640x480 on screen the way wanted. So, played with timings a bit. Maybe something is off, not sure...
My observed outcome seemed to be the classic LCD not syncing pixels to analog VGA input text crisply and flickering along some vertical edges in fonts when text is on screen. I never typically see this issue when I clock VGA from the P2 using standard timings with my driver, and my Dell 2405 monitor is very forgiving and normally makes most things look really good, plus the 1920 pixel wide panel is an exact multiple of 640 pixels. So it was a surprise to see this effect showing up. I was guessing it could be using fractional clocks such that precise pixel widths can vary but I didn't dig into the driver or timings and it's not my own code.
The only other thing I was wondering was whether the recent repairs to this monitor somehow affected things. I did have to change the SMPS switcher chip to use a lower frequency as the original replacement chip needed was obsolete and it was replaced by one which operates about 60% of the original clock rate. But the effect of that should be mainly voltage/power related and hopefully wouldn't cause some sync timing interference on analog video input channels or something. I have definitely seen it working okay with other resolutions after the repairs, but perhaps I need to re-test with my own driver with stock VGA timing specifically.
Are you testing on an analog monitor or an LCD? I don't think this effect would be noticeable on an analog monitor if you happen to be using one of those for testing.
Just ran MP on a P2-EVAL with VGA breakout board and saw the same pixel issue, so not something specifically in my Bull Ant HW and the P2-Edge. Then I loaded up my VGA text driver helloworld.spin2 example and the VGA text is all clean without shimmery edges happening every few characters on the screen. Both input signals were being reported as the same 640x480 60Hz in the monitor's menu. Pretty sure it's going to be down to not using an integer multiple of the CPU clock for the pixel clock in the driver which results in some jitter.
EDIT: I just performed a monitor auto-adjust on the input and it seemed to fix this problem. So it must have recognized it as some older mode and setup the wrong clock in the monitor. I guess that can happen if syncs are in different positions.
For 640x480, non-integer clock ratio should not be an issue at all. Each pixel is at least 10 clocks wide, so the jitter is minimal. Ideally, somewhere you'd use XZERO instead of XCONT to stop the rounding from compounding over time.
@Wuerfel_21 said:
For 640x480, non-integer clock ratio should not be an issue at all. Each pixel is at least 10 clocks wide, so the jitter is minimal. Ideally, somewhere you'd use XZERO instead of XCONT to stop the rounding from compounding over time.
For sure on an analog monitor it won't be visible. But if an LCD's pixel clock phase is imperfectly centred within the pixel and samples the data near a transition it can be visible. In the end that may have happened here as I found this monitor just had a learned a previous mode at the same resolution but likely with a different pixel frequency (sync and blanking params looked the same as mine in the end). Once the monitor was auto-adjusted it seemed to lock on okay to the updated signal timing and not show further artefacts. I just found that the driver code bundled in Rayman's MP tree calculates timing parameters for a 25MHz dot clock but the sysclk is 252MHz AFAIK. So not a perfect fraction. Should really be 25.2 Mpixels/s to keep it as a 10:1 ratio.
EDIT: In fact it looks like this MP image built from Rayman's code was setting the pixel clock to 25000000 and uses a sysclk of 297MHz according to what MP reports as the system clock frequency. So does seem that fractional clocks were in play here.
@rogloh said:
For sure on an analog monitor it won't be visible. But if an LCD's pixel clock phase is imperfectly centred within the pixel and samples the data near a transition it can be visible.
I would say the opposite is true. The analog monitor shows what it has been given. The LCD wants to sample the center point of the pixel, which should be far from any shifty edges. The other day, I actually got 1920x1200 to work with a non-integer clock ratio for the Tempest 2000 port. You can try that one (set VGA5X mode), to see is to believe.
When I say won't be visible on analog monitors, I really mean it just won't be noticeable in this specific case with just pixel variation between full width and 9/10s of the width as the variable size. Technically it could be visible if your analog monitor has a high enough resolution to show it or if the size difference is much larger.
By the way, I've not been able to find where the 297MHz clock is setup in the source files. It must be somewhere in the USB driver code (of which the particular source file here was not provided - OneCogKbM3c.spin2 was missing which probably defined the _FCLKFREQ as 297000000. The original version supplied called "OneCogKb.spin2" still has 160MHz defined there instead which is not the frequency the MP image runs at). The whole clock setting thing is a bit of a mess here. Looks like it needs to be patched into the binary somehow by loadp2 or otherwise. Would be nicer if it could come from the MicroPython Makefile and controlled from there, although I understand that driver COGs like USB and video are coupled closely with this value and sometimes want to define it themselves.
@rogloh if you mean the .spin2 version of the usb code, it's attached here.
Appears that spin2cpp was done on it elsewhere and the resulting c and h files copied over but not the .spin2 file. Probably should keep the .spin2 file with the port though...
The initial P2 clock is currently defined in the riscvp2 file, riscvtrace_p2.spin.
It somehow winds its way into the compiler when you do "sudo make install" in the riscvp2 folder...
@Rayman said:
The initial P2 clock is currently defined in the riscvp2 file, riscvtrace_p2.spin.
It somehow winds its way into the compiler when you do "sudo make install" in the riscvp2 folder...
Ok cool. Was wondering where it was.
@rogloh if you mean the .spin2 version of the usb code, it's attached here.
Thanks for that.
Appears that spin2cpp was done on it elsewhere and the resulting c and h files copied over but not the .spin2 file. Probably should keep the .spin2 file with the port though...
Yeah it was hard to see what exactly was compiled without the source. Best to keep original spin2 sources in the same folder for reference at least.
Also there’s a function in the p2 module that prints the clock freq…
Yes I found and used that to learn it was actually running at 297MHz.
Ok, if you are using riscvp2, then you might want to get the latest files from @ersmith github repo. There, he added the above way to change the P2 clock frequency and has it set to 252 MHz and also made it so can use the latest riscv compiler files... Or, maybe you already have that and somehow got a version where it was changed to 297 MHz...
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...
I remember we spent a bit of time on 'where things should go' when we did v1.13. We can seek clarification if need be, but what you're proposing looks right.
Regarding Neopixel, my vote would be to build it in, its one of those key things that 'sparks joy' and encourages further exploration
Comments
That might be best. I got this idea from them though:
Internally in the source code the "STATIC" macro definition has been removed. Code should now just use "static" instead. If you have C/C++ code that uses "STATIC" then either replace it with "static", or provide your own #define to define "STATIC" as "static". See commit decf8e6 for details.
Got hard spi to compile. Copied from STM32 port, then commented out all the STM stuff.
It lists now, but doesn't have the actual code to do anything yet:
Tried to get soft SPI working, but couldn't figure it out.
There's only one sorta issue perhaps...
Had to comment out this check for soft spi because it depends on soft spi being present:
mp_obj_t machine_hard_spi_make_new(const mp_obj_type_t *type, size_t n_args, size_t n_kw, const mp_obj_t *all_args) { MP_MACHINE_SPI_CHECK_FOR_LEGACY_SOFTSPI_CONSTRUCTION(n_args, n_kw, all_args);No idea how much trouble this might be though...
By the way, both propeller2.h and smartpins.h seem to be missing from your build files - I'm getting an error when trying to build from your zip file sources after installing and running your Makefile @Rayman . Should propeller2.h come from the P2 RISCV toolchain include files or are you obtaining it from elsewhere?
I've just moved propeller2.h from spin2cpp into /opt/riscvp2/include folder which will hopefully fix the missing propeller2.h file but don't see smartpins.h anywhere in the zip. EDIT: Ok grabbed it from spin2cpp as well.
Nope
Ok, I remember now that propeller2.h is actually in the riscvp2 folders.
And, very specific for that compiler . Would need some work to port to the native compiler..
Smartpin.h have to look
Got further. I'd missed the step of doing the make install in the code that patches the RISCV toolchain with Eric's files. That copied the special propeller2.h file.
Just about got it building now apart from this link problem:
Ok, so this stuff is tricky...
I think you might need to include the port modmachine.c in the makefile.
There, there is this:
STATIC void mp_machine_idle(void) { _waitms(1); }Probably not right, but at least compiles...
Thanks I've been going about trying this exact thing. Am thinking some of these types of build problems relate to the use of the earlier and potentially outdated Makefile and/or mpconfigport.h formats.
Finally got it to build but needed to remove STATIC in the newly created mp_machine_idle function so it was visible to external modules (still got a warning from extmod/modmachine.c file though). I can try it out on real HW now.
UPDATE:
with some small effort on a P2 Edge in my Bull Ant P2 setup. Mainly needed to patch base pins and disable USB which seems to be somewhat hard-coded. I found the included VGA driver is a bit jittery compared to what I'm used to with my own drivers and is not cleanly syncing to pixel edges on my monitor. Might be fractional clock related, not some nice integer multiple between the CPU and pixel clock frequencies as I typically use...
Got it working
I’ve noticed vga being a bit off too. Thought was power supply or something but maybe it is the clock …
Noticed vga looking off when added Wi-Fi module so thought it was that. But still there with Wi-Fi module removed . If you see it too, must be something actually wrong …
Ok, VGA is looking perfect today at 252 MHz and 297 MHz. So, not sure what to do about that. I have been ignoring some compiler warnings though, maybe there's some random thing that can go wrong...
Now that I think about it... Way back when started, was having trouble with VGA to HDMI adapter not centering 640x480 on screen the way wanted. So, played with timings a bit. Maybe something is off, not sure...
Ok, after some testing, pretty sure the slight VGA flicker I'm seeing is just the monitor I'm using. Seeing same thing with basic VGA driver.
My observed outcome seemed to be the classic LCD not syncing pixels to analog VGA input text crisply and flickering along some vertical edges in fonts when text is on screen. I never typically see this issue when I clock VGA from the P2 using standard timings with my driver, and my Dell 2405 monitor is very forgiving and normally makes most things look really good, plus the 1920 pixel wide panel is an exact multiple of 640 pixels. So it was a surprise to see this effect showing up. I was guessing it could be using fractional clocks such that precise pixel widths can vary but I didn't dig into the driver or timings and it's not my own code.
The only other thing I was wondering was whether the recent repairs to this monitor somehow affected things. I did have to change the SMPS switcher chip to use a lower frequency as the original replacement chip needed was obsolete and it was replaced by one which operates about 60% of the original clock rate. But the effect of that should be mainly voltage/power related and hopefully wouldn't cause some sync timing interference on analog video input channels or something. I have definitely seen it working okay with other resolutions after the repairs, but perhaps I need to re-test with my own driver with stock VGA timing specifically.
Ok, tried on a newer monitor and VGA looks perfect, to me anyway. That other monitor is ancient, probably going bad...
Are you testing on an analog monitor or an LCD? I don't think this effect would be noticeable on an analog monitor if you happen to be using one of those for testing.
Just ran MP on a P2-EVAL with VGA breakout board and saw the same pixel issue, so not something specifically in my Bull Ant HW and the P2-Edge. Then I loaded up my VGA text driver helloworld.spin2 example and the VGA text is all clean without shimmery edges happening every few characters on the screen. Both input signals were being reported as the same 640x480 60Hz in the monitor's menu. Pretty sure it's going to be down to not using an integer multiple of the CPU clock for the pixel clock in the driver which results in some jitter.
EDIT: I just performed a monitor auto-adjust on the input and it seemed to fix this problem. So it must have recognized it as some older mode and setup the wrong clock in the monitor. I guess that can happen if syncs are in different positions.
Ok. I'm not exactly sure why @ersmith picked 252 MHz. But, it's easy to change now. Or, maybe could set pixel clock to 25.2 MHz and be still OK?
I normally use 252MHz as well for VGA. It should be okay.
For 640x480, non-integer clock ratio should not be an issue at all. Each pixel is at least 10 clocks wide, so the jitter is minimal. Ideally, somewhere you'd use XZERO instead of XCONT to stop the rounding from compounding over time.
For sure on an analog monitor it won't be visible. But if an LCD's pixel clock phase is imperfectly centred within the pixel and samples the data near a transition it can be visible. In the end that may have happened here as I found this monitor just had a learned a previous mode at the same resolution but likely with a different pixel frequency (sync and blanking params looked the same as mine in the end). Once the monitor was auto-adjusted it seemed to lock on okay to the updated signal timing and not show further artefacts. I just found that the driver code bundled in Rayman's MP tree calculates timing parameters for a 25MHz dot clock but the sysclk is 252MHz AFAIK. So not a perfect fraction. Should really be 25.2 Mpixels/s to keep it as a 10:1 ratio.
EDIT: In fact it looks like this MP image built from Rayman's code was setting the pixel clock to 25000000 and uses a sysclk of 297MHz according to what MP reports as the system clock frequency. So does seem that fractional clocks were in play here.
I would say the opposite is true. The analog monitor shows what it has been given. The LCD wants to sample the center point of the pixel, which should be far from any shifty edges. The other day, I actually got 1920x1200 to work with a non-integer clock ratio for the Tempest 2000 port. You can try that one (set VGA5X mode), to see is to believe.
When I say won't be visible on analog monitors, I really mean it just won't be noticeable in this specific case with just pixel variation between full width and 9/10s of the width as the variable size. Technically it could be visible if your analog monitor has a high enough resolution to show it or if the size difference is much larger.
By the way, I've not been able to find where the 297MHz clock is setup in the source files. It must be somewhere in the USB driver code (of which the particular source file here was not provided - OneCogKbM3c.spin2 was missing which probably defined the _FCLKFREQ as 297000000. The original version supplied called "OneCogKb.spin2" still has 160MHz defined there instead which is not the frequency the MP image runs at). The whole clock setting thing is a bit of a mess here. Looks like it needs to be patched into the binary somehow by loadp2 or otherwise. Would be nicer if it could come from the MicroPython Makefile and controlled from there, although I understand that driver COGs like USB and video are coupled closely with this value and sometimes want to define it themselves.
I’m pretty sure usb driver source code is there somewhere…. It has been updated to a version that automatically adjusts for clock frequency.
The actual start up clock frequency is specified in the compiler files though.
Also there’s a function in the p2 module that prints the clock freq…
@rogloh if you mean the .spin2 version of the usb code, it's attached here.
Appears that spin2cpp was done on it elsewhere and the resulting c and h files copied over but not the .spin2 file. Probably should keep the .spin2 file with the port though...
The initial P2 clock is currently defined in the riscvp2 file, riscvtrace_p2.spin.
It somehow winds its way into the compiler when you do "sudo make install" in the riscvp2 folder...
Ok cool. Was wondering where it was.
Thanks for that.
Yeah it was hard to see what exactly was compiled without the source. Best to keep original spin2 sources in the same folder for reference at least.
Yes I found and used that to learn it was actually running at 297MHz.
Ok, if you are using riscvp2, then you might want to get the latest files from @ersmith github repo. There, he added the above way to change the P2 clock frequency and has it set to 252 MHz and also made it so can use the latest riscv compiler files... Or, maybe you already have that and somehow got a version where it was changed to 297 MHz...
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...
I remember we spent a bit of time on 'where things should go' when we did v1.13. We can seek clarification if need be, but what you're proposing looks right.
Regarding Neopixel, my vote would be to build it in, its one of those key things that 'sparks joy' and encourages further exploration