j123b567 / scpi-parser

Open Source SCPI device library

SCPI parser library v2

Documentation

Documentation is available at http://j123b567.github.io/scpi-parser.

Examples

Library contains several examples of usage but please note, that this code is just for educational purpose and not production ready. Examples are from several contributors and they are not tested and it is also not known, if they really work or can compile at all.

The core library itself is well tested and has more then 93% of the code covered by unit tests and integration tests and tries to be SCPI-99 compliant as much as possible.

About

SCPI Parser library aims to provide parsing ability of SCPI commands on instrument side. All commands are defined by its patterns eg: "STATus:QUEStionable:EVENt?".

Source codes are published with open source BSD 2-Clause License.

SCPI parser library is based on these standards

• SCPI-99
• IEEE 488.2-2004

SCPI version compliance

SCPI version

v1999.0

Supported command patterns

Feature	Pattern example
Short and long form	MEASure means MEAS or MEASURE command
Common command	*CLS
Compound command	CONFigure:VOLTage
Query command	MEASure:VOLTage?, *IDN?
Optional keywords	MEASure:VOLTage[:DC]?
Numeric keyword suffix Multiple identical capabilities	OUTput#:FREQuency

Supported parameter types

Type	Example
Decimal	10, 10.5
Decimal with suffix	-5.5 V, 1.5 KOHM
Hexadecimal	#HFF
Octal	#Q77
Binary	#B11
String	"text", 'text'
Arbitrary block	#12AB
Program expression	(1)
Numeric list	(1,2:50,80)
Channel list	(@1!2:3!4,5!6)
Character data	MINimum, DEFault, INFinity

scpi-parser's Issues

`Error queue not empty` bit not set

@lhoerl Please can you write here more info about this.

New entry in scpi_special_number_t suggested

CONFigure command accept following values for the 1st arguments: DEF, MIN, MAX, AUTO, . Examples:

CONF:VOLT:DC DEF
CONF:VOLT:DC 12.34
CONF:VOLT:DC AUTO

I'd like to use SCPI_ParamNumber to parse command, but scpi_special_number_t enumeration has no option for AUTO value. Can you add it? Or can I add an exception for this command only to support AUTO option?

Thanks

Visibility of matchCommand function

I found matchCommand very useful in my command handlers like SENSE:FUNC:

scpi_result_t sense_function(scpi_t* context) {
  const char* param;
  size_t param_len;

  if (!SCPI_ParamText(context, &param, &param_len, TRUE)) {
    return SCPI_RES_ERR;
  }

  if (matchCommand("VOLTage", param, param_len)) {
    // switch to DC voltage   
  } else if (matchCommand("VOLTage:RATio", param, param_len)) {
    // switch to DC voltage ratio
  } else...`
}

But visibility of matchCommand prevents using it in my code. Could you change its visibility or add a public wrapper function?

Thanks

Unexpected error -108

I added a handler for command SENSE:FUNCTION that accepts a single argument in double quotes:

SENSE:FUNCTION "VOLT"

My handler looks like this:

scpi_result_t sense_function(scpi_t* context) {
    const char* param;
    size_t param_len;

    if (!SCPI_ParamText(context, &param, &param_len, TRUE)) {
        return SCPI_RES_ERR;
    }

    // process param

    return SCPI_RES_OK;
}

It works well and returns SCPI_RES_OK, but after it returns the SCPI parser pushes error -108 to error stack.

Status Register update from threads

Hi Jan, maybe you can guide me a little through this special aspect.

In my code I run a RTOS (CortexM with Keil RTX). Some of the threads running in the system produce status information (e.g. temperature too high) that I want to report in the questionable status. Just using the SCPI_RegSet() family of functions may lead to multiple acces to the same variable from different threads, here the USB thread and the temperature thread.

Normally I would protect the access with a mutex and I think I will introduce one here.
Can you give a hint where the mutex is best placed?
Is this a common issue that should be noticed in the library?
Can we think of providing a 'shileding function' that does mutexing like the function pointers in scpi_interface?

Any hint is welcome, best regards, Lutz

SCPI commands list in flash (PROGMEM) on AVR

How much of trouble is to support SCPI commands list in PROGMEM on AVR? Usually, there is not much SRAM on these microcontrollers (in my case 8K) and my SCPI commands list is taking a lots of it and soon it will became unsustainable :(

BTW We are using your SCPI parser on this hobby project:

http://www.eevblog.com/forum/projects/diy-programmable-dual-channel-bench-psu-0-50v3a/

Once more, thanks for your excellent parser!

scpi_interface_t.error is not called

I specified my own handler to scpi_interface_t.error, but it is not called when an error occurs. Is this handler overridden somewhere?

Including inc/scpi/config.h in inc/scpi/scpi.h

Can you include inc/scpi/config.h by inc/scpi/scpi.h? I need SCPI_doubleToStr macro in my code and I don't want to include anything but scpi.h.

Make library thread safe

Library is not thread safe. To overcome this issue

• user must use library only in one thread and use message queue to communicate with scpi thread
• user must lock all manipulations with scpi_context

With recursive mutex, it is possible to define some macro and extend the library to perform context locking by itself.

This issue is related to #68 and #63

IEEE 488.2-2004:7.7.6 <ARBITRARY BLOCK PROGRAM DATA> indefinite format

In the specification, there is possible to have arbitrary data without definig length.

#0<UNLIMITED BINARY DATA><NL><^END>

SCPI-99:21.8.1 Correct handling of error queue overflow

Reported in #66

If the queue overflows, scpi-parser doesn't behaves according to the SCPI specification which says (paragraph 21.8.1 The Error/Event Queue):

As errors and events are detected, they are placed in a queue. This queue is first in, first out.
If the queue overflows, the last error/event in the queue is replaced with error
-350,"Queue overflow"
Any time the queue overflows, the least recent errors/events remain in the queue, and the
most recent error/event is discarded.

Strange Output of "SCPI_ParamCopyText"

When I use "SCPI_ParamCopyText" I often get strange results.
I wrote the following test in "test-parser" main.c file:

    TEST_SCPI_INPUT("test:text 'a'\r\n"); //output: TEXT: ***a�`***
    TEST_SCPI_INPUT("test:text 'a a'\r\n"); //output: TEXT: ***a a***
    TEST_SCPI_INPUT("test:text 'aa a'\r\n"); //output: TEXT: ***aa a
***
    TEST_SCPI_INPUT("test:text 'aaa aaaa'\r\n"); //output: TEXT: ***aaa aaaaLj�***, BUT: Sometimes correct!
    TEST_SCPI_INPUT("test:text 'qwerpoiuweroituopquepori'\r\n"); //output: TEXT: ***qwerpoiuweroituopquepori       ***

Thanks for having a look into it!

proper naming of SCPI functions handling integer (and other) types

In our fork we have added functions which handle extra integer types for SCPI_Result*, SCPI_Param* and *To* functions. Please ignore the double types in the tables, I know they are a separate issue.

This functions are present in v2.1:

function	type
SCPI_ResultInt	int32_t
SCPI_ResultIntBase	int32_t
SCPI_ResultDouble	double
SCPI_ParamInt	int32_t
SCPI_ParamUnsignedInt	uint32_t
SCPI_ParamDouble	double
strToLong	int32_t
strToULong	uint32_t
strToDouble	double

This functions were added by Red Pitaya:

function	type
SCPI_ResultUInt	uint32_t
SCPI_ResultLong	int64_t
SCPI_ResultULong	uint64_t
SCPI_ParamLong	int64_t
SCPI_ParamULong	uint64_t
longToStr	int32_t
doubleToStr	double
strToLongLong	int64_t

We use the 64 bit types for values in nanoseconds. The actual hardware is a 32 bit counter with an 8 ns period. Therefore the nanosecond value requires 35 bits. We might also use even larger counters for some features later.

Here I assume you have a much better knowledge of the standard then I do :). Is there in the standard a set of supported data types, preferably with predefined names, I was able to find a list in section 6.4.2 FORMat of the SPCI-99 standard.

type	description
ASCii	Comma-separated data
IFP32	IEEE floating point, 32 bits.
IFP64	IEEE floating point, 64 bits.
INT8	IEEE 8-bit signed integer (default).
INT16	IEEE 16-bit signed integer.
INT32	IEEE 32-bit signed integer.
INT64	IEEE 64-bit signed integer.
SFP32	IEEE swapped floating point, 32 bits.
SFP64	IEEE swapped floating point, 64 bits.
SINT16	Swapped IEEE 16-bit signed integer.
SINT32	Swapped IEEE 32-bit signed integer.
SINT64	Swapped IEEE 64-bit signed integer.
SUINT16	Swapped IEEE 16-bit unsigned integer.
SUINT32	Swapped IEEE 32-bit unsigned integer.
SUINT64	Swapped IEEE 64-bit unsigned integer.
UINT8	IEEE 8-bit unsigned integer.
UINT16	IEEE 16-bit unsigned integerUINT16.
UINT32	IEEE 32-bit unsigned integerUINT32.
UINT64	IEEE 64-bit unsigned integerUINT64.

If we implement functions for additional integer types, do you have a suggestion how to properly name them?

utils.h in src folder

shouldn't this be in the inc folder?

Unexpected parser behaviour

I have defined following SCPI commands:

...
{ .pattern = "MEASure[:SCALar]:CURRent[:DC]?", .callback = SCPI_MeasureCurrentQ, },
{ .pattern = "MEASure[:SCALar]:POWer[:DC]?",   .callback = SCPI_MeasurePowerQ,   },
{ .pattern = "MEASure[:SCALar]:VOLTage[:DC]?", .callback = SCPI_MeasureVoltageQ, },
...

But parser is also accepting :MEAS? as regular header and calls SCPI_MeasureCurrentQ callback. Is this ok?

Non-ASCII character in string param

SCPI parser is blocking if there is non-ASCII character inside string param.

Spaces between commands are not skipped

I send several commands in a single packet separated by semicolon. It works unless there are space(s) between semicolon and next command. Example:

Following request works, ID is printed twice:

_IDN?;_IDN?

Following request fails, only first ID is printed:

*IDN?; *IDN?

Inappropriate signature of scpi_interface_t.test callback

The *TST? SCPI command returns 0 if the self-test is successful and 1 if the test fails.

The scpi_interface_t.test callback returns value of scpi_result_t type with valid values 1 and -1. The returned value is directly passed to output buffed by SCPI_CoreTstQ function. Seems like a minor data mismatch.

Is it possible to modify SCPI_CoreTstQ or change the signature of scpi_interface_t.test?

SCPI-99:6.2.5.2 Multiple Identical Capabilities

Hello,
I'm wondering how to parse parameter in the command.

Here is an example: SENSe[n][:CHANnel]:FUNCtion:RESult:IND?

N could be 1,2,3,4 for example. I don't want to create four patterns for this.
Is it possible with the current version of this great parser?

Thank you in advance.

With kind regards

Manuel

SCPI-99:8.3.2 Channel Lists

Thank you for sharing a great SCPI library.
Is it correctly understood that the library does not support source lists? Do you have any plans about adding support for it?
Best Regards
Christian

missing shared library

building a shared library was removed in the next commit:
6e73d85

We are attempting a migration from v1.2 to v2.1 and we are missing the shared library. Could you explain your reasoning behind this removal?

Support for shared libraries would be needed for example if libscpi was packaged for Debian or another distribution.

need to be Thread Safe

I think it's much better if the parser running thread-safe.
One of the barriers I think is the error fifo.
Is there any plan to enhance the features?

Error message for the SCPI_ERROR_COMMAND_PROTECTED

Following error message is false:

XE(SCPI_ERROR_COMMAND_PROTECTED,            -203, "Command protected TK024")                      

It should be only "Command protected" without TK024. I believe that TK024 is some kind of invisible markup in scpi-99 specification PDF which is preserved when you copy-paste ;)

SCPI_ParamNumber and illegal parameter value

This is the code to get number parameter with scpi_special_numbers_def:

scpi_number_t param;
if (!SCPI_ParamNumber(context, scpi_special_numbers_def, &param, true)) {
    return SCPI_RES_ERR;
}

If I pass illegal parameter value (for example maxc), it will report -224, "Illegal parameter value", which is expected, but it will continue as error didn't happened (SCPI_ParamNumber returns SCPI_RES_OK) and param will be as def parameter was given.

Usage of scpi_special_numbers_def[]

Hello,

I'm a bit puzzled how you can setup special numbers for your instrument?
As I found out, there is scpi_special_numbers_def, in which all necessary MINimum, MAXimum, ... defined.
If I use ParamNumber( ... ) to parse the value, how can I substitute now my DEFault, MINimum and MAXimum?

I think I just oversaw something in the lib or didn't understand something correctly. An Input string which could be used from the commandline is, for example:
conf:volt:dc Default, 1.4 mV
Thx in advance!

Multiple commands per package

Hi all,

first of all thanks for the work you invested in this parser. It saved me some trouble already. I am running the parser on a Zedboard in a bare metal application with LWIP. During some performance tests I ran into the problem that the SCP input buffer was quickly filling up. This is due to the way TCP packages are packed. They can include more than one command ended with \r\n.

I fixed the problem (in a quick and dirty way) with the following simple code modification in parser.c which parses the input buffer until cmdlineTerminator returns NULL.

I replaced this:

ws = skipWhitespace(context->buffer.data, context->buffer.position);
cmd_term = cmdlineTerminator(context->buffer.data + ws, context->buffer.position - ws);
if (cmd_term != NULL) {
int curr_len = cmd_term - context->buffer.data;
result = SCPI_Parse(context, context->buffer.data + ws, curr_len - ws);
memmove(context->buffer.data, cmd_term, context->buffer.position - curr_len);
context->buffer.position -= curr_len;
}

with this:

ws = skipWhitespace(context->buffer.data, context->buffer.position);
cmd_term = cmdlineTerminator(context->buffer.data + ws, context->buffer.position - ws);
while (cmd_term != NULL) {
int curr_len = cmd_term - context->buffer.data;
result = SCPI_Parse(context, context->buffer.data + ws, curr_len - ws);
memmove(context->buffer.data, cmd_term, context->buffer.position - curr_len);
context->buffer.position -= curr_len;
ws = skipWhitespace(context->buffer.data, context->buffer.position);
cmd_term = cmdlineTerminator(context->buffer.data + ws, context->buffer.position - ws);
}

What do you think?

Proposal of API function for automated parameter handling

I would like to introduce some function/set of functions to automate parameter handling.

Nice to have would be this, but we are far from this and it would be hard to do this with limited resources.

SCPI_AllParameters(
    context,
    "<data_handle>, <Boolean>|ONCE [, BUS|IMMediate|EXTernal [, <numeric_value>]]",
    values);

My idea is something like this

/* list of available values of 3rd parameter */
const scpi_choice_def_t trigger_source[] = {
    {"BUS", 5},
    {"IMMediate", 6},
    {"EXTernal", 7},
    SCPI_CHOICE_LIST_END /* termination of option list */
};

/* list of definitions of parameters */
const scpi_parameter_hint_t hints[4] = {
    {
        .types = STRING | MNEMONIC | ARBITRARY,
    },
    {
        .types = BOOL | MNEMONIC,
    },
    {
        .types = MNEMONIC,
        .default_value = 6,
        .choice_list = trigger_source,
    },
    {
        .types = NUMERIC_WITH_SUFFIX | MNEMONIC,
        .default_value = 1e-3,
        .default_unit = A,
    }
};

/* return values */
scpi_parameter_variant_t values[4];
int min_parameters = 2;
int max_parameters = 4;

/* process all parameters */
SCPI_AllParameters(context, hints, values, min_parameters, max_parameters);

/* use values */
process_data(values[0].v.data.ptr, values[0].v.data.len);
set_output_enable(value[1].v.boolean);
set_trigger(values[2].v.integer);
set_limit(values[3].v.number.value, values[3].v.number.unit);

My questions are:

• Can this cover all your needs - all your current/future commands?
• Will this be helpfull = less coding, intuitive?
• Do you have some ideas, how to do this and how not to do this?

IEEE 488.2-2004:8.4.1 <RESPONSE MESSAGE UNIT SEPARATOR>

When I send two or more query commands in a single packet like this:

*OPC?;SYST:ERR?

my Agilent 34401A returns all responses in the single line separated by semicolon:

1;0, "No error"

It is possible to implement this in scpi-parser? Currently command responses are separated by a new line.

how to format syntax properly?

I'm a bit stuck trying to figure out how to write the command syntax, and debugging through the pattern matching isn't getting me very far.

I've got syntax like so: (Trying to match a GW Instek Function Generator's syntax for compatibility)

1  OUTPut[1|2] {OFF|ON}
2  OUTPut[1|2]?
3  OUTPut[1|2]:LOAD {DEFault|INFinity}
4  OUTPut[1|2]:LOAD?

I can get parts of this to work, but not even close to all together. Not even just command 2. Have you got any tips on how to construct the scpi-parser syntaxes for this sort of thing?

SCPI_ExprChannelListEntry() crashes with whitespaces

If you enter a whitespace in your channel list, e. g. (@1, 2) instead of (@1,2), result of SCPI_ExprChannelListEntry == SCPI_EXPR_ERROR and the parser get's somehow messed up, but it doesn't throw an error.

SCPI_ParamText() does not correct the paramlist.length if text is "-capsulated

Not correcting the length will result in "Parameter not allowed error" (more parameters than allowed) - but I'm not on the current code base...
The text parsing is correct, but the tests do not check for the length (== 0) after processing, correct?

I did a quick fix for my needs to detect the "" and correct the length:

// ...
if (locateText(context->paramlist.parameters, 
            context->paramlist.length, value, &length)) {
    *// Work-around: Correct paramlist.length
    if(*context->paramlist.parameters == '"')
        paramSkipBytes(context, 2);

    paramSkipBytes(context, length);
    if (len) {
        *len = length;
    }
    return TRUE;
}

Thanks.

get unsigned integers with SCPI_ParamNumber

Is it possible with the current API to retrieve an unsigned integer value from a numeric parameter like "#hffffffff"?

Adding a double-to-string conversion function to scpi_t

SCPI_ResultDouble function calls doubleToStr, which itself calls standard snprintf function to convert double to string.
On some platforms, e.g. Arduino, standard library does not implement double-to-string conversions, and one has to write his own ones. For example, this code: printf("v=%lg", 1.23) actually prints "v=?".
I suggest adding a double-to-string conversion function to scpi_t type. This function could be optional, i.e. user has not to specify it on platforms where standard library works well.

SCPI-99:7.5.1 Units of Amplitude and Power

Support unit suffixes:

• PK: Peak amplitude
• PP: Peak-to-peak amplitude
• RMS: RMS amplitude

Support unit prefix:

• dB

Support special case:

• dBm: witch is equivalent to dBmW

So it is possible to have unit DBUVRMS which is dBµVrms

• dB is prefix
• UV is µV
• RMS is suffix

How to use SCPI_ExprChannelListEntry()?

Hi,

I want to use the channel list capability you introduced in commit 7dca581.

But how to use/parse it properly?

For example, how to parse
:READ? (@1:2!4) (Reading Channels 1, 2, 4).

Thanks :)

SCPI_CommandNumbers

Using SCPI_CommandNumbers() function it is not possible to find out if number is typed or not because in case if number is not typed it will just return 1. I have a use case when I need to know when number is not typed. Is there a way to find out if number is typed?

Incorrect handling of empty string ""

Handling of empty string "" or '' should be walid. Reported by @koeart in pull request #43

Error handling for device specific errors

Hi, great work!
I wonder how I can add evice specific errors. Example: A command that sets a float value may be perfectly parsed but the value given is below or above a certain level. In this case I would like to have an extra error code. How can I add these codes? How would be the API?

Currently I work an integrating the libscpi to a Cortex-M4 device with USBTMC. It works and uses about 8k of Flash.

Again, thank you for you work.
Best regards
Lutz

SCPI_Input() and input buffer overrun

I think SCPI_Input() doesn't handle input buffer overruns properly. It checks for overrun and returns -1 if it happens. But, what can I do next? If I continue to feed SCPI_Input() with the data it will continue to return -1 and basically block the SCPI parser. I can't reset the buffer, except if I call SCPI_Input() with 0, but in that case it will call SCPI_Parse() with partially received data.

If buffer overrun is detected in SCPI_Input() I think it should generate -363, "Input buffer overrun" error, ignore everything until \r\n and reset the input buffer after that so it can start fresh again.

Binary encoding of larger data types in <ARBITRARY BLOCK PROGRAM DATA>

It would be nice to support arrays of larger types in arbitrary block.

Currently, there is only one function for parameter SCPI_ParamArbitraryBlock() and one for result SCPI_ResultArbitraryBlock()

It is sometimes needed to transfer larger data types e.g. array of 32bit integers, but endiannes is up to the user of the library.

This problem was partially discussed in #51

Possible solutions

• introduce helper function to translate array of native values to "normal" or "swapped" e.g. on x86, swap bytes while transfering array of int16_t in SCPI's "normal" byte order or do nothing special on AVR32.
• introduce new SCPI_ParamArbitraryBlockXYZ functions to do this on the fly but this will probably need additional data buffer

Specification

In the SCPI specification, there are two main chapters about binary encoding of these types

SCPI-99:Volume 1 - 9.1 [:DATA] <type>[,<length>]
SCPI-99:Volume 3 - 6.4.2 FORMat

Among others, there are two types of encoding "normal" and "swapped". It seems that "normal" is big-endian representation and "swapped" is little-endian.

type name	description
ASCii	Comma-separated data
IFP32	IEEE floating point, 32 bits.
IFP64	IEEE floating point, 64 bits.
INT8	IEEE 8-bit signed integer (default).
INT16	IEEE 16-bit signed integer.
INT32	IEEE 32-bit signed integer.
INT64	IEEE 64-bit signed integer.
SFP32	IEEE swapped floating point, 32 bits.
SFP64	IEEE swapped floating point, 64 bits.
SINT16	Swapped IEEE 16-bit signed integer.
SINT32	Swapped IEEE 32-bit signed integer.
SINT64	Swapped IEEE 64-bit signed integer.
SUINT16	Swapped IEEE 16-bit unsigned integer.
SUINT32	Swapped IEEE 32-bit unsigned integer.
SUINT64	Swapped IEEE 64-bit unsigned integer.
UINT8	IEEE 8-bit unsigned integer.
UINT16	IEEE 16-bit unsigned integerUINT16.
UINT32	IEEE 32-bit unsigned integerUINT32.
UINT64	IEEE 64-bit unsigned integerUINT64

strnlen() avaiability on non-linux platforms

strnlen() is not necessarily available everywhere. To make the parser.c function where strnlen doesn't exist, modify parser.c line 190 as follows:

const char * cmd_ptr = cmd;
size_t cmd_len = strlen(cmd);
if (cmd_len>len)cmd_len=len;

More complex units definition

It is currently needed to expand all possible units, prefixes and suffixes.

It will be nice functionality to implement separate definitions of prefixes, separate definitions of suffixes, separate definition of units and connect it somewhare together.

SCPI-99:6.2.4 Traversal of the Header Tree

Implement correct traversal of the Header Tree for experimental branch

e.g. for command patterns

FREQuency::STARt
FREQuency::STOP

allow to call

FREQ:STAR 3 MHZ; STOP 5 MHZ

currently, you must write

FREQ:STAR 3 MHZ; FREQ:STOP 5 MHZ

unit conversion improvement

Currently unit conversion allows only multiplication.

Temperature units would require a linear conversion, so a multiplication and an addition.

Logarithmic units often used for signal power in spectrum analyzers would require logarithmic operations.

how to handle odd units

I know that I can provide my own entire array of units, but do you have ideas on how best to handle things like "Vrms" and Vpp, while still keeping all the existing SI unit prefixes? so I can have mVrms and uVrms without having to to duplicate all the units for all the combinations?

I'm probably just going to ignore supporting this in the direct SOURce#:APPLy:SIN [freq], [ampl], [offset] type functions, and only allow changing it via the explicit SOURce#:VOLTage:UNIT command, but was wondering if you had any ideas on how best to handle this

Missing declarations

I downloaded the beta version and got it working. I then needed the fixes for #16 (multiple commands). I started doing the patched listed and saw that the parser.c had other changes, so I thought I would try to get the latest. I now have several defines missing.
c:\tf_workspaces\cxl\utils.cpp(118): error C3861: 'SCPIDEFINE_doubleToStr': identifier not found
1>c:\tf_workspaces\cxl\utils.cpp(158): error C3861: 'SCPIDEFINE_strncasecmp': identifier not found
1>c:\tf_workspaces\cxl\utils.cpp(181): error C3861: 'SCPIDEFINE_strncasecmp': identifier not found
1>c:\tf_workspaces\cxl\utils.cpp(526): error C3861: 'SCPIDEFINE_strnlen': identifier not found

I also have an error:

error C2039: 'paramlist' : is not a member of '_scpi_t'

I think I have the latest files. Any suggestions are appreciated.

Thanks

Question: Error vs not present for optional parameters

When calling, for example, SCPI_ParamInt with argument mandatory set to FALSE, how to differentiate real errors from the case when parameter is not present (in both cases the return value from this function call will be FALSE)?

Error queue per context

Some questions and issues with error queue:

• Why is the error queue shared between scpi context's? I was expecting that each context has its own unique error queue.
• There should be a way to configure the size of error queue without changing FIFO_SIZE in fifo_private.h, preferably with scpi_user_config.h.
• If the queue overflows, scpi-parser doesn't behaves according to the SCPI specification which says (paragraph 21.8.1 The Error/Event Queue):

As errors and events are detected, they are placed in a queue. This queue is first in, first out.
If the queue overflows, the last error/event in the queue is replaced with error
-350,"Queue overflow"
Any time the queue overflows, the least recent errors/events remain in the queue, and the
most recent error/event is discarded.

Trouble w/ SCPI_ResultDouble

Hello,

I'm developing an embedded ARM Project (ARM7TDMI, Atmel AT91SAM7X128). While integrating SCPI told me about issues with some newlib stuff (which I could solve), I'm now in trouble when trying to display double numbers. Doing multiplactions with them is not a problem, though.

My question: What standard libraries do you rely on? Do you maybe have a suggestion where I can look, what to fix? Unfortunately I cannot connect via JTAG to the controller (and don't have access to UART yet).

I will do a workaround for the time being, but I would be happy if I could fix this later. I'm also looking into other ressources, but maybe there is a hint/fix available for this I think could be a common issue on embedded systems without native floating point support.

Thx in advance!

P.S.: SCPI_ResultDouble and SCPI_ResultText (in conjunction with SCPI_NumberToString) crash.

SCPI-99:8.3.3 Numeric Lists

Implement numeric list parsing