Device programming
Really glad you made the transition to GitLab!
Project types
First thing to consider, is creating project types, as different project scenarios have totally different requirements:
- We need (yet) at least the two project types: “Application” and “System”
- While “System” projects target processors directly, the type “Application” seems to need sub-types:
- “Gnome / UNIX / GUI Application”
- “System (i.e. non-UI) Application”
- “Android Application”
- “RTOS/eCos Application” (programs based on a device-specific operating system)
- “Web development” (for usage in combination with NGINX, web frameworks, etc.)
- Own category for languages like Julia
- Maybe own categories “Kernel” and “Kernel modules”? Or how could this be handeled?
- Currently implemented Gnome-application-specific stuff (like Flatpak) should just be tied to the “(Gnome/UNIX/GUI) Application” project type.
- Categories need to specify “run variants” (or whatever they are called…)
- Profiler and Valgrind perspectives seem to not be useful for devices.
- The current debug perspective may need rework for working in conjunction with external devices.
- Projects may specify the project type “None” first (providing basic functionality, for viewing sole files etc.). That later could be expanded to the above mentioned types, what then would provide type-specific additions.
- Not sure if changeing from “None” to a type could/should be revertable?
Project preferences
Second step would be to provide appropriate, type-specific project settings. I added my suggested GUI below, the following text points out the details further:
- Initial project setup dialog should also let the user setup the following settings.
- Profile options (edit name, clone, delete) should be hidden by a hamburger icon (alt: arrow icon like in Lollypop) directly next to the profile name
- When switching between profiles, the currently displayed stack-switcher page should be kept active.
- When cloning a profile, it would be cool if that profile could be converted to a “super profile” with now having the former profile as a “sub profile”, and additionally the new requested, second “sub profile”. The user then should be able to select what settings should differ between a sub and it’s super profile (with the rest of settings being inherited). This is, because most profiles just have some small distinctions – for example “flash to RAM” or “flash to flash memory” – here, all other settings should be done in the super profile with all sub profiles inheriting them.
Page “Project”
- Super project
- Not yet implemented [see Bugzilla #790195], but should maybe be considered when reworking project settings.
- Use cases: CPU1 & CPU2 (TI microcontrollers) / client & server / sender & receiver…
- Sub-projects could be of different project types.
- Channel
- Would be cool if we could switch between release channels here.
- Runtime
- Two-stage setup: First runtime selection, then version selection ⇒ The combination of both then should be shown in the runtime definition box.
- Reverse-DNS names should be un-reversed.
- Maybe this setting could be of use for systems development, too.
Page “Compilation”
- Building may involve several steps (compiling, converting to a flashable format, flashing, etc.).
- Builder::device.c/device_manager.c should provide target-specific build chain command scelettons.
- This could be done by pre-defined CMake-targets using variables – these (required) variables then need to be exported to and defined by this “Compilation” settings page.
- Maybe this could also be done by Meson?
- Available compilers should be filtered by device selection (which is done at “Devices” settings page, see below).
- Maybe compiler version selection via side pane?
- All ${target_setup} variables get defined in “Target” settings page (see below).
- Required paths/defines by compiler/SDKs could automatically be shown up greyed-out (and thus non-deletable).
- Eventually advanced device-specific compilation settings.
Page “Devices” [and target hardware settings]
- Caution:
- Targets could be programmed by multiple connetions (e.g. programming via bootloader & JTAG).
- Connections could provide multiple targets.
- Debug connections may exist (e.g. a USB-tunneled UART could send data to the machine)
- Here the processor-specific compiler settings are defined (e.g. for avr-gcc: -mmcu, -DF_CPU, etc.)
- Maybe also flash setup…
- Triplets for system development targets:
<Device> – <Processor> [Architecture]
- Triplets for application development targets:
<Device> – <OS> [<Kernel>]
- Are processor/architecture indications really useful here?
- I think FreeBSD doesn’t need to specify a kernel (as it equals OS version)
Page “Target” [target software settings]
- Device SDKs and stuff like “Device Family Packs”
- Auxiliary SDKs should be filtered by device selection
Page “Versioning”
- No proposal from my side here, but I think that a page for versioning would be useful if that won’t be done via some other interface.
Mock-up
- Shown corrupted(?!), please open in Inkscape…
Additional thoughts
- We have to see how we could implement the combination of (RT)OS-installation and deploying a OS-based program to a device.
- One way could be, to have a “System” sub-project installing the (RT)OS, and an “Application” sub-project installing the program (which then runs on a remote target and uses the (RT)OS).
- For the device programming implementation, I’d like a modular approach – that could be providing separate libraries, so that these could be updated independently from Builder (and also could be used elsewhere), for example
libide-processors[-{arm,arduino}]
&libide-android
.- I think it’s best providing this as Rust libraries. We then could easily specify and download/use compatible/exact versions via Cargo (if that works?), and I generally prefer programming in Rust.
Edited by Frank Brütting