Describe the changes this PR makes. Why should it be merged?

This PR adds support for building for WebAssembly to be simulated.

• Cargo config has updated linker flags
  • Memory is no longer shared because there is no need to simulate FreeRTOS task switching. Before, the simulator would essentially do multithreading (but only run 1 thread at once). Multithreading in WASM requires memory to be marked as shared.
  • Indirect function table is now imported instead of exported. This makes it easier to develop the simulator because the jump table can be set up before booting. I didn't do this with the memory because it seems like Dlmalloc can't see imported memory and always returns OOM errors?
• Wasm32 is now a checked target by rust-analyzer; this was necessary for making sure everything compiled on both platforms.
• Added NoopCriticalSection for WASM
  • WASM doesn't have interrupts or any way to disable them so I'm pretty sure it's safe. Also because the module's memory is not shared there is guaranteed to not be any multithreading.
• Cfg's for ARM assembly
  • The operations being performed at the start of the program aren't actually necessary in WASM.

Additional Context

• I have tested these changes on a VEX V5 brain.
• I have tested these changes in a simulator.

Describe the changes this PR makes. Why should it be merged?

This PR adds the vexide-graphics crate with a brain display driver for Slint and embedded-graphics.

Additional Context

• These changes update the crate's interface (e.g. functions/modules added or changed).
• I have tested these changes on a VEX V5 brain.

Bug Description

Disabling the critical_section feature makes the crate not compile.

Code to reproduce

N/A

Expected vs. actual behavior

There shouldn't be any broken features.

Additional information

• I have tested this issue on the latest development release.
• Rust version (see rustc --version): rustc 1.78.0-nightly (256b6fb19 2024-02-06)
• vexide version (see Cargo.toml): 273c7bffa9945d6d89c1321c3ae19a71279fe33d

Describe the changes this PR makes. Why should it be merged?

Adds initial support for the following ADI devices:

• Quad Encoder
• WS2812B Addressible LEDs

Additionally refactors a few things.

• Renamed AdiUltrasonic to AdiRangeFinder for clarity and renamed ping/echo to input/output to match the physical labeling on the wires.

Additional Context

• Untested

Bug Description

When testing locally without a competition happening, my driver control code never starts.

Code to reproduce

TODO, I'll come back to this later once I make a minimum reproducible sample

Expected vs. actual behavior

Operator control code should run even if the robot is not at a competition. In reality it never starts.

Additional information

• I don't have access to a competition hub so it's possible that driver control code never runs whatsoever.

Describe the changes this PR makes. Why should it be merged?

This PR adds a exit function to vexide-startup which blocks for 3ms to flush the serial buffer and then exits the program with vexSystemExitRequest.

Additional Context

• I have tested these changes on a VEX V5 brain.

Describe the changes this PR makes. Why should it be merged?

This PR changes the name of all crates to vexide-* except for pros-sys which will be removed soon. In the future the name of the repo should also be changed to vexide. Pros-sync was deleted entirely because it isn't needed anymore.

Additional Context

No code functionality was changed, just crate paths.

Describe the changes this PR makes. Why should it be merged?

• Adds the task and time modules (mirrored off of tokio's crate structure more or less).
• Re-exports Task and FallibleTask from async_task to allow users to store task handles without manually adding async_task as a dependency.
• Refactors SleepFuture (now named Sleep) to internally store an Instant. This required some minor changes to the reactor.
• Adds sleep_until which should be pretty self explanatory.
• Updates docs.

Describe the changes this PR makes. Why should it be merged?

Makes vexide_macro's depdendency on the syn crate not conflict with the versions specified in snafu-derive and pin-project-internal, resulting in this error when attempting to use the vexide crate from an external project:

Describe the changes this PR makes. Why should it be merged?

Smart devices are currently not Send or Sync, which makes them not shareable between async tasks. This is because we store a raw device handle V5_DeviceT for convenience when interacting with the SDK. Sending raw pointers across threads isn't inherently unsound, and the lack of Send + Sync on raw pointers exists more as a lint.

Describe the changes this PR makes. Why should it be merged?

• Changes text drawing to no longer support the line positioning mode, since that has some inconsistent behavior.
• Removed direct usage of mint::Point2, instead adding our own Point2 struct with an actually practical implementation.
• Re-exports some mint types used by devices through the geometry module.
• draw pixel is now dead. Instead we blanket-impl Fill for all types that can be converted into a Point2.
• Fixes various issues caused by not taking the program header into account while drawing.

Additional Context

Closes #44. Needs hardware testing.

Describe the changes this PR makes. Why should it be merged?

Refactors Position to hopefully have more precision. It now always stores data in terms of ticks with a TPR value being the LCM between the two largest TPR devices (motor and rotation sensor). I've also adjusted the naming to match similar standard library types like Duration.

Additional Context

TODO:

• Hardware test (of course)
• Update examples

What's the motivation for this feature?

Both of these devices are ones i've been avoiding for a while for various reasons, but we need to support them at some point.

Describe the solution you'd like

• Add an AdiGyro support for abstracting over the old 3-wire yaw-rate gyro.
• Add an AdiServo struct for controlling the legacy cortex-era servos.

Describe the drawbacks, if any

Both of these devices are very poorly documented in the SDK and may utilize private API functionality on VEXCode's side. Not sure.

• In AdiGyro's case, VEXCode has an is_calibrating function while PROS does not. There's no provided function in the SDK for this functionality, meaning it's probably some undocumented status bit. Fun.
• PROS also is forced into immediately calibrating the sensor as soon as vexDeviceAdiPortConfigSet is called.
• In AdiServo's case, PROS doesn't even support it at all. The units/range of the ADI setter is comlpetely unknown.

I also don't have access to any of this hardware to test on.

What's the motivation for this feature?

We currently don't support the following new smart devices from the CTE workcell kit:

• CteArm
• CtePneumatics
• CteSignalTower

Describe the solution you'd like

Add support for these devices.

Describe the drawbacks, if any

This hardware is very new. I think Liam may have access to a few units, though.

What's the motivation for this feature?

vex-sdk currently supports the AI Vision SDK functions. We should probably look into supporting that.

Describe the solution you'd like

Use vex-sdk's syscalls to implement an AiVisionSensor struct that abstracts over the smart device. This API might need to end up being a little different than the current VisionSensor API (which is far more scuffed internally).

Describe the drawbacks, if any

• Barely anyone has access to this hardware at this point in time, making it difficult to test. Some features of it may also change in the future.
• We might want to share some functionality between the old vision sensor and this struct, depending on how similar the APIs are (I don't recall them being that similar, though). We should probably figure out how to best do this (should these sensors be in a single vision module?).

What's the motivation for this feature?

We current lack support for the V5 GPS sensor as provided by vex-sdk.

Describe the solution you'd like

Adding support shouldn't be too bad (it'd essentially be the InertialSensor API but with a few extra getters). We might want to have an Imu trait or something for common functionality to be shared between the two sensors, since their APIs are near identical in the imu-facing hardware abstractions.

Describe the drawbacks, if any

I don't have a GPS sensor to test on. Think Liam does, though, so we could use that.

Describe the alternative solutions, if any

None

We currently leverage talc, which is a fairly experimental memory allocator for embedded systems. Right now, we just use talc because it works and hasn't really raised any trouble. To my knowledge, talc isn't quite up to speed with some competing allocators, but i'm curious around how it stacks up against libc's malloc in libpros, as well as the performance of other allocator options (both performance-wise and efficiency-wise).

Potential benchmark contenders:

• linked_list_allocator/embedded_alloc (if we can get it to work)
• libc's malloc
• dlmalloc
• https://github.com/yvt/rlsf