-
-
Notifications
You must be signed in to change notification settings - Fork 192
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Giga: compatibility fixes with M4 builds #741
Conversation
Not sure if it is best to ask this here or on forum or new issue? In a test sketch, that I am using to test my version of ILI9341 library, I added Serial1.begin(1000000); On M7 works fine. Thanks |
@KurtE using this PR or without? I just tested with this PR applied and the baud is correct |
Hi @facchinm I have done a bit of testing with the fix and both the M4 and M7 now agree on microseconds but not on milliseconds, so I'm guessing the M7 may have an issue with milliseconds?. Using some test code here with the M4 using delay(1000) over 120 seconds has the following drift from M7 to M4: Using some test code here with the M4 spinning on micros() over 120 seconds has the following drift from M7 to M4: The us figures seem good but the ms figures are quite a bit off. M4 code
M7 code
some data:
|
I put a logic analyser to work. microseconds are spot on for each. milliseconds are wrong and different for each, one slow, one fast. The issue seems to be the mbed::LowPowerTimer used for ms, if you undefine DEVICE_LPTICKER then ms are also spot on for each. |
This allows having all the generic code in a single place, including the needed clock configuration override
f5f4bad
to
373e7c6
Compare
Sorry, I'm not very familiar with GitHub.. so does it work now? |
@Nocentinia - It is not merged yet. Once it is merged, so it is not yet in any build. But I am keeping my fingers crossed that it will be soon |
Hi @facchinm As you are looking into the M4 I have found out that reading from the SDRAM is not working correctly on this core. https://forum.arduino.cc/t/sdram-read-not-working-correctly-on-m4/1182865 Cheers Andy |
@AndrewCapon the last commit of this series 3490221 fixes the issue of using the SDRAM on M4; however, the RAM cannot be initialized by both M7 and M4 but this is currently not guarded. |
Great @facchinm thanks for that :) |
@facchinm could you confirm the expected behavior of WiFi on the M4 core after these changes? I see that you removed the define for the M4 in the wl_definitions file but didn't add one for the generic M4 core. Does this officially mean that the M4 should not/cannot manage the WiFi portion of the Murata radio on the Portenta? Currently the behavior on the public release of the core is that calling Edit: I should also add I pulled your forks of the Mbed core and BLE library and was able to compile them and the Portenta no longer panics when the M4 core calls BLE.begin(), but it hangs and does not continue with execution. I know it's still in progress but just wanted to add what I was experiencing with the current commits. |
This allows `while (!SerialRPC)` construct to work
@trylaarsdam I just retested the BLE patchset from scratch and everything seem to work on my side, however I'll provide some more "finished" examples as soon as the patchset gets merged. Talking about wifi, instead, there seem to be some hardware idiosyncrasies between the M4 and SDMMC1 bus, no documentation from ST states that it's impossible so I'll still try for some days to get it working. If nothing happens, I'm going to merge this PR as is so we can at least have basic HW functionalities on the M4 |
Well it looks like this likely made my code no longer compatible with M4 |
@Bexin3 can you expand? Or share the code that doesn't work anymore? The change was made to be completely backwards compatible so any regression will be investigated seriously. |
Hello, the code can be found here; |
The screen tear only happens when the image changes though |
Fixes #726 and supersedes #740