mirror of https://github.com/saymrwulf/xous-core.git synced 2026-11-15 08:30:02 +00:00

History

bunnie b7453b627e add API tokens to prediction API The prediction API now takes an API token. This is a 128-bit number that gets passed to the prediction engine, and it's meant to be unique for every context that requires a predictor. It's up to the prediction engine to do anything with the token. For the "null" engines (such as the icontray for `vault` and `tts`) the token is just ignored. But for example, in `shellchat`, the API token is used to store a history record in a HashMap on a per-token basis. This means that every app that uses the `shellchat` history function gets their own history that can only be read out by that app. The actual token itself is mostly passed through the API. The token storage is in the Context layer (each Context has a record for a token, that starts as `None`), and is passed down to the predictor every time the context swaps, and the predictor receives the token and passes it back if the token was `Some`, or allocates a new random token if it was `None`. Note that everything is a Context, including, for example, menus and modal dialog boxes, but not all contexts have predictors. Only Contexts that ask for a predictor have them. This mechanism works smoothly in this model (as opposed to other hacks and work-arounds previously tried getting to this solution).		2022-06-19 01:01:25 +08:00
..
ball	fix #174	2022-06-10 21:36:53 +08:00
hello	apps/services: remove xous::xous_main macro usage	2022-05-31 13:33:30 +08:00
repl	evict f64's from the kernel, and eliminate f32 parsing	2022-06-14 04:14:25 +08:00
vault	add API tokens to prediction API	2022-06-19 01:01:25 +08:00
manifest.json	add a submenu entry for the vault app	2022-06-17 18:29:21 +08:00
README.md	Update README.md	2022-05-29 01:47:53 +08:00

README.md

Xous Apps and the Manifest Format

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

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.
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.
Add an entry to manifest.json in this file so the build system can fold it into the system menus. Format documented below.
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.
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.