Random DSF/SBC questions
-
Now that I have my duet3 working with a RaspPi4, I want to start tinkering...
Has anyone used DSF with one of the 64 bit "Raspberry Pi OS" builds? Did you recompile DSF for aarch64, or leave it 32bit? (has a DSF aarch64 build been tested?)
The DSF "building" instructions state that "you need to get the latest .NET SDK", but doesn't specify the version. The latest core 3.1? The latest core 5.0? (I tried to figure this out on the pre-configured duetPi image, but "dotnet --list-runtimes" returns a surprising "dotnet: command not found")
I think that .net core currently supports UI elements. Has anyone built a user interface for DSF that uses dot net instead of relying on the bloated and CPU hungry chromium running DWC? (On my Pi4, chromium running DWC when nothing at all is printing is sucking 80% CPU according to htop. That's with changing the refresh in DWC to 1000ms.)
-
Everything compiles fine with just dotnet 5.0 installed.
I also took an hour to grab the August 2020 RaspPi OS 64-bit image, set it up, updated it, adding the duet servers, and installed DSF on it. It seemed to pull arm64 (aarch64) binaries via apt and they work fine. (I didn't try to recompile with arm64, but I don't see any reason why the compile wouldn't work.)
At this time, I'm not sure if there's any advantage to using the 64bit distros with DSF. I didn't notice any, but I only went to far as to installing it and making it sure it talked to my printer. Once I saw that chromium is just as resource hungry on arm64, I pulled that sdcard out and put back the 32bit one.
I think that's all the questions I posted above, so I guess I'll mark this as solved.
-
Answering one of my questions, it appears that DSF uses ".Net Core 3.1" (and not ".Net 5.0" which many might consider to be "the latest version."
This was determined by examining DuetControlServer.runtimeconfig.json.
I've also submitted a PR to the DSF Readme.md that specifies "latest .NET Core 3.1 SDK" instead of just "latest .NET SDK"
--
For another question, I was wrong about .NET Core (even 5.0) supporting UI elements under linux. That should come with .net 6.
On the other hand, there are 3rd party (open source) libs that allow GUI work within .net core on linux. I might try to tinker with one. I still think having a real binary executable GUI (even one using .net's CIL) would be faster and less resource intensive than having chromium running on the Pi.
--
As for arm64... I haven't tried that yet... hopefully someone knows and answers that before I potentially spend a few hours figuring it out.
-
Well, I guess I was wrong with the dot net version. From @chrishamm on github in response to my PR:
DSF does require .NET SDK 5 because it uses C# 9 features but with the .NET Core 3.1 runtime. So there is absolutely nothing wrong with it. I'll upgrade the runtime to .NET 5 as part of v3.3 too.
Sadly, instead of correcting my the instructions request to specify ".NET 5.0", it's been left vague and meaningless.
@chrishamm , "the latest .net SDK" is about as meaningful as "the latest duet board."
If I reported a bug stating that I'm using "the latest duet board", no one would know if I mean the latest revision Duet 3 6HC, the latest Duet 2 wifi, the latest Duet 2 Ethernet, etc. Or, perhaps I mean one of the "duet 3 mini" boards?
Microsoft has not discontinued .net core 3.1 and .net core 2.1 - both are actively getting "new versions." In fact, according to https://dotnet.microsoft.com/download/dotnet-core, they were both updated yesterday with new versions (3.1.11 and 2.1.24.)
-
Everything compiles fine with just dotnet 5.0 installed.
I also took an hour to grab the August 2020 RaspPi OS 64-bit image, set it up, updated it, adding the duet servers, and installed DSF on it. It seemed to pull arm64 (aarch64) binaries via apt and they work fine. (I didn't try to recompile with arm64, but I don't see any reason why the compile wouldn't work.)
At this time, I'm not sure if there's any advantage to using the 64bit distros with DSF. I didn't notice any, but I only went to far as to installing it and making it sure it talked to my printer. Once I saw that chromium is just as resource hungry on arm64, I pulled that sdcard out and put back the 32bit one.
I think that's all the questions I posted above, so I guess I'll mark this as solved.
