Thanks for explaining, have some catching up to do 
Guess iāll keep my idea of running on linux on hold some more.
My main reason for running linux kernel is being to have a realtime system (one of the iso11783 requirements) for running IsoagLib and doing some Isobus developing. Being able to run AOG on the same board is the reason for asking.
I agree with Torriem. Getting things figured out in C# is a really efficient way to get new ideas going. For example the current idea by Daniel is to use a high speed tesselation class to fill in complex polygons and get away completely from calculating points in boundaries for section control, implement lift etc and do it almost exclusively by graphics. Rapid development using .net allows code to be written and rewritten and rewritten solving issues - code that in C++ would take a lot longer. Once it works, porting to C++ is a very much lot easier.
Iām really excited where all this is going, stuff is getting made - and that is such a win no matter which language because we can easily translate a book rather then writing one initially.
What board or boards do you have in mind? The reason I ask is because Linux support for hardware OpenGL on SBCs is spotty to say the least. Vendors arenāt terribly interested in open source drivers (they only care about Android). I managed to get hardware OpenGL ES working on a Raspberry Pi 3, and Iām now trying to see if I can get it working on a Pine A64 board. ARM is such a proprietary and non-standardized world compared to Intel. I really donāt like it. Proprietary firmware blobs, weird hardware trees, customized boot loaders, special distros, etc. If there was an Intel x86 SBC that was as cheap as an ARM board, and just as capable, Iād pick it any day over an ARM unit. On the other hand if ARM had a standardized hardware abstraction model and I could install any generic distro on it (Fedora, Debian, etc), Iād be quite happy to convert to it wholesale. End of rant.
Have been looking at the raspberry pi, beaglebone and Pine as well.
To pick one i would go for the raspberry pi but at least version 4. why?
It has the biggest community so most stuff like OpenGL will be supported faster than others.
Itās easy to get everywhere and will be until at least 2027
Easy development tools, just like AOG started on arduino instead of a plc
Version Pi 4 is the first to support real time Ethernet ( previous versions had NIC over usb)
More than one hardware UART for real time 2 GPS receivers etc ,instead of usb to uart
Can run pretty generic distroās, so everyone has the same hardware running the software, Meaning no more separating between windows,android and linux.
This way the display can be native or any x86 ARM Android etc device (just like remote desktop)
Drawbacks: 1 the sd card instead emmc/ssd 2 Linux needs proper boot AND shutdown
Because the industry is focused mobile these days my guess is ARM will be their future over Intel, besides price only. Which distro to use ? One with kernel version 5.4 and above would be nice (it has J1939) already baked in.
Just thinking from an end-users point of view: download this image File>flash to SD>Boot from Pi>Connect PC/Laptop/Tablet/Phone display device. Is as complex as they would want.
Having all users and developers on the same hardware would make wikiās, support and development less complex.
Both beaglebone and pine64 boards boot from a micro SD card also.
In my opinion, the worst part about the Raspberry Pi compared to the other boards is the complete lack of electrical power management. Consider how a typical commercial tractor terminal works. You turn the key on, it boots up and does its thing. Then you turn the key off, it does a safe shutdown sequence and powers off. On a Pi you can use an arduino or some other helper circuit to do something on a GPIO pin when the unit should be shut down, which would fire off a script to do the shutdown, but thereās no easy way for it to safely kill the power after it knows shutdown is complete. Currently there are power hats you can use with the Pi to get some of that functionality. But itās not ideal. But I agree itās a common platform with a strong community.
Of all the boards Iāve tried over the years, the Pine A64 (and later) board impressed me the most in this area. It can power itself off, and to turn it back on would only require a simple circuit that briefly shorts out a couple of pins when the ignition switch is on. However Iām not nearly as impressed in how hard itās been to even get HDMI graphical output out of the thing, let alone 3D acceleration.
Did I mention how I donāt love ARM for all these reasons? 
The beaglebone black/green have the slot but perfectly boot from their emmc (try it to see them live up) It also has the most hardware onboard, encoders, canbus, 2 pruās etc(cnc background here) only it doesnāt impress or better ālacksā graphics,
The Pine can do the power on/off the rest would need some externals or like on Isobus send a keep power on request for nSeconds. Still something decent has to take that place for glitches. Donāt ask the things that happen Ignition on > Boot > Start tractor>Power Supply mayhemā¦>tractor runs.
No? please do so, saves my from sharing those thoughts 
My experience with the PI has been quite discouraging - as has with many others - is a power bump takes out the memory card. The Pi runs the gateway for the LoRa network. Runs fine for a month, then craps. Since this is happening repeatedly in a tractor, it needs that problem solved.
Yeah thatās a huge problem. A read-only root partition will help. But thatās certainly an area where the on-board MMC would be superior. And a really good power supply. Perhaps going through a LiPo battery for backup. There are hats for that sort of thing but they cost more than the Pi does.
I wonder how well my now-obsolete cheap x86 Windows 10 tablet would run Linuxā¦ It no longer can run Windows 10 on only 32 GB of storage.
For general AOG use, tablets really do seem to be the best way to go. The android idea interests me but Qt does not really allow you to make apps that can keep running in the background when you switch to a different task (even to mess with Settings). In fact even a native Java android app version of AOG would be an architecture challenge, as background tasks have to be created specially, and wouldnāt have access to the OpenGL hardware near as I can tell.
I think with the PI4 you can run the OS off of a harddrive, eliminating the mem card altogether
Hmm, I donāt see any expansion buses on the Pi 4 other than USB. I saw a SATA hat for Pi but itās just a USB3 to SATA adapter really. I also saw an eMMC drive that plugs in the SD card slotā¦ would that also have the same problems with power? Very disappointing.
There is no fun in jamming paper between the card and slot, or hotglue-ing it shut, to then find out the sd card craps out after a while because the are not made to run a OS.
The Pi 4 can indeed only boot from USB just like the 3. Still the 4 needs a sd for the bootloader because afaik the firmware update is not out yet which should support native USB boot like the 3 does. They all use usb to sdd/nvme as drive.
No more Win 10 on 32 GB? Just reinstalled my AOG Device 2 weeks ago ,also runs on 32 GB. Only couldnāt manage to save room for linux dual boot
Which version of Windows 10 are you running? Iāve read that since 1909, the minimum is 32 GB, and in my experience thatās not enough space to handle updates. My old tablet is stuck on 1809 I think, and thereās no space for any upgrade to 1909 or newer.
1809 indeed on a x2 detachable strange thing has 64 bit processor but 32 bit uefi bootloader so also 32 bit win 10. Installed it with internet off
Hmmm So should i hit check for updatesā¦
Quick watch
Nice video and never lost a decent USB connector on a bump.
19.09 Even smaller albeit on a vm
Great thread, nice work Torriem!
This is very very cool! is there an easy way to compile the latest buil for android? id love to try it out in a couple tablets i have running arround, congrats on your work!
I basically followed the instructions here and here. I didnāt compile Qt myself, but I used the version for Android their installer downloaded for me. Once itās configured, in Qt Creator itās a matter of selecting the Android kit and building it. The build process will make an apk that you can deploy to an android device (Qt Creator can deploy it for you). Anyway itās not a simple process, and requires a lot of downloading to get all the Android SDK parts you need, as well as Qt itself. The Android SDK and NDK, including the compilers Google uses is a couple of GB. Crazy.
As Iāve said quite a few times, thereās currently no way to get QtAOG to work with real hardware yet. It does not have any serial communication in it yet. It only functions with the simulator right now. My development has paused again as weāre well into spring planting now.
Hello,
With a small java code you can run a service in background on android with Qt. It is working for me, and also with java code, inside the Qt project I made three serial/usb adapter working on Qt android with felHR85 UsbSerial lib. It is working on a T585 tablet for me. It was not easy for me, because I never used java, and I am not a programmer.
Very nice. Itās definitely something I want to look into. Although Iād like to keep one source code base between Android and the other platforms, itās looking more and more like Android will require some special code architecture and organization to work with. For example, when QtAOG is running in the background on android it will still need access to the GPU to do some offscreen rendering for the section lookahead. That is possible in Android, but will require significant changes to the want QtAOGās code. At that point it will become much harder to track AgOpenGPSās source code base. But I can see that itās worth going there in the future.