The Nordic nRF52840-DK is a relatively popular dev board, using the same main CPU as the currently supported Feather Express board.

It also has been used in a number of written guides for Rust, including Ferrous Systems' trainings and Knurling sessions, which means many Rust folks will already have one in a drawer.

In order to support this board, two main things need to happen:

• We need some way of handling multiple pin mappings, to handle the difference between the two boards (either statically through cfg or at runtime)
• We need some way of handling multiple QSPI parts, to handle the different flash memory available between the two boards (again statically through cfg or at runtime)

This would be a great first issue for someone familiar with embedded Rust, and interested in getting started with the kernel!

At the moment, the app-loader binary (and associated functionality) is loaded in the kernel via include_bytes!().

It might make sense to move this functionality into the kernel, as a function that gets called on startup, rather than as a totally separate application.

This would also make it easier to have a faster development loop, e.g. the "kernel-app-loader" could open a port that could be used to immediately upload an application. This could work well with a cargo runner that partially replaces the dumbloader application, as well as potentially (partially) the crowtty application (it could pass stdio through to port 0, at least, after a cargo run.

This would mean (with no other desktop apps running), you could:

• Start the MnemOS PC
• Move to your new application project
• type cargo run --release, which will:
  • Build the application, creating an app
  • Invoke objcopy (or perform the same functionality somehow), creating an appbin
  • Open the (actual/physical) serial port
  • Begin uploading the application over port 1
  • Begin passing stdio through to port 0
• While the kernel-app-loader would:
  • At startup, open port 0 (for the CLI interface)
  • Open port 2 (for the direct-to-memory-loader)
  • Wait for commands
  • Get the upload command, and begin copying directly to the app region
  • Check the app uploaded correctly, boot directly into the new app
• The new application could then immediately begin using virtual port 0.
• If the user needs more than virtual port 0, they could close the cargo run command, and start crowtty instead
  • In the future, we could have a "just flash" or "flash and run" command option or something

It would be nice for app developers to be able to develop userspace applications on the desktop.

I wonder if this could be done by making a different version of the "userspace" library that did something like IPC for syscalls instead of an actual syscall.

I think the harder part would be figuring out how the library could have the "real" entrypoint, but there might be some way around this.

An alternative would be to have a desktop version of the kernel, and map in the application somehow.