Skip to content

feat(commands, error_queue): implement 'SYSTem:ERRor:ALL?' - #3

Open
AdrianDC wants to merge 2 commits into
7h0ma5:mainfrom
AdrianDC:system_error_all
Open

feat(commands, error_queue): implement 'SYSTem:ERRor:ALL?'#3
AdrianDC wants to merge 2 commits into
7h0ma5:mainfrom
AdrianDC:system_error_all

Conversation

@AdrianDC

Copy link
Copy Markdown
Contributor

Proposal to add SYSTem:ERRor:ALL? support to list SCPI errors without cleaning the queue.


Ugly workaround we had before the patch (unreliable with async multi-clients) :

    // TODO: Migrate to microscpi library
    #[scpi(cmd = "SYSTem:ERRor:ALL?")]
    fn system_error_all_query(&mut self) -> Result<Vec<(i16, String)>, errors::api::Error> {
        let mut errors = Vec::new();
        while let Some(err) = self.error_queue().pop_error() {
            errors.push(err);
        }
        if errors.is_empty() {
            return Ok(vec![(0i16, "".to_string())]);
        }
        let response = errors
            .iter()
            .map(|error| (error.number(), error.to_string()))
            .collect::<Vec<_>>();
        for err in errors {
            self.error_queue().push_error(err);
        }
        Ok(response)
    }

AdrianDC added 2 commits July 11, 2026 12:11
Signed-off-by: Adrian DC <radian.dc@gmail.com>
Signed-off-by: Adrian DC <radian.dc@gmail.com>
@7h0ma5

7h0ma5 commented Jul 31, 2026

Copy link
Copy Markdown
Owner

Hi Adrian,

Thank you very much for your contribution!

The change looks good, but it currently fails to compile in no_std environments because Vec is not provided by core. I guess we have three possible approaches:

  1. Gate the new functions and command registration behind #[cfg(feature = "std")], making them available only when the standard library is enabled.
  2. Add an alloc feature and use alloc::vec::Vec. This would support no_std environments that provide an allocator.
  3. Preserve allocation-free no_std support by using a fixed-capacity heapless::Vec. The capacity could be tied to the maximum size of the error queue.

I am leaning to the third option as the error queue size is already bounded.

What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants