neotron-compute / neotron-common-bios Goto Github PK

https://github.com/OpenNuvoton/N9H30_emWin_NonOS

This library contains an Apache 2.0 licensed non-OS USB Host stack, supporting OHCI (USB 1.1 Full/Low Speed) and EHCI (USB 2.0 High Speed) controllers.

Sometimes the OS wants to do things with a global variable. Rust wants to ensure nothing else can touch the data at the same time. You can't use a CAS AtomicBool because not all platforms have them. So instead the BIOS should have critical_section_enter and critical_section_exit APIs. Entering critical_section_enter twice without calling critical_section_exit first would cause an Exception as that's an OS programming bug.

The Neotron Pico BIOS supports defmt over RTT. Maybe it could expose a log write function. To avoid exposing defmt it would take a string slice, maybe supplemented with a slice of integers. That would cover most use cases. Other BIOS implementations could chuck it over a UART or something, or stick it a RAM buffer. The Desktop BIOS would printf it.

They say things like:

The underlying hardware could not accept the given configuration. The numeric code is BIOS implementation specific but may give some clues.

But the enum no-longer has numeric values in it - it's a plain enum.

Could support soft loading fonts. One function takes a 4096 (8x16) array, the other a 2048 (8x8) array.

Also need to document that default font must be Code Page 850. Or we should return the code page of the default font.

Need the API fixes, and the pc-keyboard based keycodes.

If the BIOS HID API used pc-keyboard types, the OS/BIOS could use the pc-keyboard keymaps.

We should report sensor info, up to 255 of them. Just like the other APIs.

Neotron Pico BIOS can provide:

• CPU temp (RP2040 on-die reading)
• 5.0V and 3.3V rail voltage (from BMC)
• perhaps some info from the RP2040 bus matrix (bus collisions, etc)
• ROM and die revision

Each value should be of an enum representing the units, and which holds a u32 or similar. This type can then impl Display for printing.

Kind::Voltage(u32) might print as xx.yyy V and be stored in units of 1/1000 Volt.

Kind::Temperature(u32) prints xx.y °C but is stored in units of 1/100 Kelvin.

Kind::RawHex(u32) prints 0xXXXXXXXX

Kind::Percent(u8) prints as xxx %

etc

Each sensor also has a human readable name.

Should the common BIOS API have naive blocking functions? They are easy to use and simple to implement, but they hurt performance (e.g. printing 15 characters when you only have an 8 character FIFO will cause the CPU to spin for the duration of 7 characters - or 608 microseconds at 115,200 bps).

Non-blocking functions are more complicated - you'd have to get some aynchronous object back which represents the transaction which you'd need to poll for completion at some later date (c.f. Windows Overlapped IO).

A compromise might be functions which process as much data as they can without spinning, and return a value indicating how much has been processed. Obviously disk reads block until the entire sector is available, but writing a [u8; 16] to a UART might write half the buffer into a FIFO and then return 8 to indicate some data was left unwritten. The OS can then decide whether to retry immediately or come back later after doing some other work.

If you don't set the framebuffer pointer and mode at the same time, it is possible to read too much data from the framebuffer and cause a crash.

Sadly we need a breaking change to the API.

Once #27 is merged we should do a release and then update both the OS and the various BIOSes.

The OS needs a release here

Applications and the OS need to be able to enter critical sections in order to safely mutate global variables (we might have signal handlers running under interrupt context, for example).

Add an API for acquire and release which the SDK can use to implement the critical-section crate.