xous-core/apps
bunnie cae402fad0 fix case where an idle font selection menu can crash the system while in TOTP mode
when the font menu is raised while in TOTP mode, the "pump"
thread continues to prompt for redraws, which can eventually lead to
an overflow of the server queue on the main thread that leads to
deadlock and eventually a crash.

This patch does two things:

- splits the allow_host variable and the allow_totp_rendering variable
so that the two flags have distinct meanings

- use the allow_totp_rendering variable to control when the
totp thread is allowed to pump the main thread to animate the
timer bar.

Previously the allow_host variable was introduced to control access
to sensitive data, and it incidentally was also used to control
TOTP rendering because when host readout is activated this can
freeze the UI for extended periods of time.

By splitting the flag we can now control both independently of
each other. Rendering still stops when host readout is enabled,
but it also stops when any other blocking dialog boxes are popped up,
hopefully preventing future crashes if a user is distracted in
the middle of a UX flow that can block the main loop.
2023-07-06 16:36:10 +08:00
..
ball update pins, again 2023-07-04 11:20:12 +08:00
hello update pins, again 2023-07-04 11:20:12 +08:00
mtxcli update pins, again 2023-07-04 11:20:12 +08:00
repl update pins, again 2023-07-04 11:20:12 +08:00
transientdisk update pins, again 2023-07-04 11:20:12 +08:00
vault fix case where an idle font selection menu can crash the system while in TOTP mode 2023-07-06 16:36:10 +08:00
manifest.json apps/transientdisk: app to demonstrate userspace usb mass storage api 2023-01-26 19:31:40 +01:00
README.md Update README.md 2022-05-29 01:47:53 +08:00

Xous Apps and the Manifest Format

You can add apps to Xous by creating crates in this directory and adding them to the workspace.

  1. Create an app by adding its crate to this directory, perhaps by copying an existing template and giving it a new name. Don't forget to change the name of the app in the app's newapp/Cargo.toml file, as this is what the build system uses to refer to the app.
  2. Register the crate in the Workspace by editing the root ../Cargo.toml (one directory above this README), and adding the new app crate's path to the default-members and the members lists.
  3. Add an entry to manifest.json in this file so the build system can fold it into the system menus. Format documented below.
  4. Rebuild using cargo xtask app-image [app1] [app2] [...], where the appN are the names of the app crates you want to have built into your burnable Xous image.
  5. Burn your new xous.img file onto your device using tools/usb_update.py -k. You will likely need to set up some drivers or install some packages, please refer to the update guide for more details.

As of Xous 0.9.6, the OS takes up about half the available RAM (8 out of 16 MiB) for code + data. For smooth operation of the PDDB and other resources, we suggest leaving about 4MiB of free space, so apps should try to stay within the range of 4MiB in size.

Note that as of Xous 0.9.6, code is copied into RAM from FLASH, so a large portion of the RAM usage is actually the code. This may be addressed in future versions, but this would require a fairly major break with how code verification and updates are done.

manifest.json Format

Each entry for an app needs a record in manifest.json with this format:

    "app_crate_name": {
        "context_name": "freeform name",
        "menu_name": {
            "appmenu.app_name": {
                "en": "app name in english",
                "ja": "app name in japanese",
                "zh": "app name in chinese",
                "en-tts": "app name for the blind"
            }
        }
    },
  • All app names and descriptors must be unique across the build system
  • app_crate_name should be replaced with the name of your app as specified by the "package" name in the app's Cargo.toml file.
  • context_name is a reserved keyword and cannot be modified; its associated value ("freeform name" in this example) is a unique, free-from name that you give your app. There is a 64-character limit on this field.
  • menu_name is a reserved keyword and cannot be modified.
  • appmenu.app_name is the localization substitution string. This must be a unique name, and it s free-form. By convention, we use appname. as a prefix to the name of the app as described in the crate, but as long as it is unique nothing should break.
  • Within the the appmenu.app_name record are the localized names for your App. We suggest creating strings for every language supported by the system. If you don't know how to translate your name, just use the same name in the language of your preference. This will at least prevent builds from breaking in different languages.