Refactor public interfaces of some low-level driver code for the Nonin sensor

[rohanpurohit]

This PR includes:

• remove enums that were not used
• Reorder enums, consts to Types.h
• Rename SignalAmplitude to SignalQuality
• Rename Pleth to PlethPulseAmplitudes
• Rename PacketMeasurements to Sample
• Rename StatusByteStruct to Status
• Reorder StatusByteStruct fields as per datasheet
• Reorder fields in Sample as per datasheet (pg 6, Serial Data format (2) table)
• Rename heart_rate to hr
• Rename spo2_d_beat to spo2_b_b
• Rename spo2_d_fast to spo2_fast (as per datasheet)
• Rename nonin_oem_revision to firmware_revision
• Remove unnecessary code comments
• Use FrameBufferStatus for FrameBuffer instead of BufferStatus
• Rename get_6bit_data to get_spo2_data as it essentialy only gets SpO2 data from the packet
• Rename get_9bit_data to get_hr_data
• Rename mask_6bit to spo2_missing_data which is equal to 0x7F or 127, this is an indicator for missing SpO2 data, we just ignore it if we get these bytes
• Rename mask_9bit to hr_missing_data which is 0x01FF or 511 this is an indicator for missing HR data, we just ignore it if we get these bytes
• Rename FrameInputStatus available enum to output_ready
• Rename FrameInputStatus framing_error enum to checksum_failed
• Rename PacketStatus framing_error enum to checksum_failed
• Rename PacketStatus missed_data enum to frame_loss
• Rename PacketInputStatus missed_data enum to frame_loss
• Rename PacketStatus available enum to ok

TODO: check for other changes

[ethanjli]

Partial review of the existing Nonin OEM III code:

• Types.h:
  • Should we move enum class statuses for Receiver classes specific to those classes (e.g. "FrameInputStatus") into those classes (e.g. "FrameReceiver::InputStatus")?
  • enum class PacketStatus:
    • What does "not_available" mean? Presumably any value other than "available" should imply "not available".
    • What's the difference between "framing_error" and "missed_data"?
  • enum class SignalAmplitude:
    • Should this be renamed to SignalQuality?
  • struct StatusByteStruct:
    • Should this be renamed to FrameStatus or even just Status?
  • using StatusByteError:
    • Should this be renamed to FrameStatuses or even just Statuses?
    • Is this just dead code?
  • using Pleth:
    • Should this be renamed to PlethPulseAmplitudes?
  • struct PacketMeasurements:
    • Should this be renamed to Sample?
    • Should the fields in here be reordered to match the order of items on page 8 of the datasheet? (e.g. hr_d should be after spo2)
    • Should "heart_rate" in the field names be renamed to "hr" for consistency with the datasheet's names?
    • uint8_t spo2_d_beat:
      • Should this be renamed to spo2_b_b for consistency with the datasheet's name?
    • uint8_t nonin_oem_revision:
      • Should this be renamed to firmware_revision to match the description in the datasheet?
      • Should our Sensor class check that this value should be within some allowed range?
    • The datasheet says that spo2 = 127 and hr = 511 as sentinel values when those quantities cannot be computed. How are we reporting missing data here? Should we add bool fields has_spo2 and has_hr, or is that already reported in some other way?
    • std::array<bool, packet_size> ...:
      • Should we make a using Flags = std::array<bool, packet_size> and then just use that for all these declarations?
  • static const uint8t mask*:
    • Since these are single-byte masks, we should use binary notation (and we can use the digit grouping symbol ' for readability)
• FrameBuffer.h
  • Frame framebuffer:
    • The doxygen comment for the output method has an unclear description which doesn't describe what it actually does
    • Should this be renamed to frame_?
  • uint8_t received_length:
    • This should be a size_t since it's used for array indexing (and then we can remove a static_cast in the cpp file)
• FrameBuffer.cpp
  • There are too many useless comments (e.g. /* Increment the frame buffer index */), it adds too much noise to code comments.
  • received_length_++:
    • In general we should use the prefix ++ and -- rather than the postfix ++ and --: e.g. ++received_length_
  • BufferStatus input(), BufferStatus output():
    • The way these methods use BufferStatus::partial abuses the semantics for BufferStatus, where partial means "only a partial buffer operation was possible" - this is a safety problem. FrameBuffer should instead have something more like ok and waiting, and maybe empty and fullif needed, or else we should redesign the interface and separation of responsibilities betweenFrameBufferandBufferReceiverto remove the need for apartialorwaitingstatus code fromFrameBuffer. Or we could just haveokandwaiting, and alsoinput_overwrittenlike inChunkSplitter`.
  • shift_left:
    • We should instead do if (received_length_ == 0) return;

[rohanpurohit]

1. This project is licensed under Apache License v2.0 for any software, and Solderpad Hardware License v2.1 for any hardware - do you agree that your contributions to this project will be under these licenses, too? Yes.
2. Were any of these contributions also part of work you did for an employer or a client? No.
3. Does this work include, or is it based on, any third-party work which you did not create? No.