Closed krwq closed 5 years ago
I have been looking at this already. The short answer is that the fix works on Ubuntu and I have it running the Ssd1351 sample. However the code that was changed for #540 is not used on Ubuntu as the detection logic doesn't recognise the hardware as a Pi because /proc/cpuinfo doesn't show the hardware details.
The testing I did was using ToInt64 rather than ToInt32. I think that you were right and we should use the 64 bit variant as it seems to work for both pointer sizes.
Any thoughts on how I should proceed ?
@Frankenslag is there any way you can override the logic to think it's PI? (i.e. use the driver directly) If you've tested that code path and work fine I'd leave it
If we can't hit this code path and we're not sure I think it might be safer to go with Int64 option
Yes... task for. Tomorrow.
@krwq I have tested. If we force the use of the RaspberryPi3Driver whilst running Ubuntu/arm64 then IntPtr.ToInt32()
will throw an overflow exception. Using the Toint64()
as the basis of the comparison works for Ubuntu on a Pi3B and Raspbian Buster on a Pi3B and a Pi4B. I intend to raise a PR for the use of ToInt64()
This is already fixed with #560
Follow up on https://github.com/dotnet/iot/pull/540#discussion_r299150881
I.e. Ubuntu can be used for ARM64 testing: https://ubuntu.com/download/iot/raspberry-pi-2-3
cc: @Frankenslag