You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
(9) |
May
(20) |
Jun
(1) |
Jul
|
Aug
(8) |
Sep
(8) |
Oct
|
Nov
|
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(25) |
Feb
(1) |
Mar
(14) |
Apr
(12) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
(8) |
Nov
(14) |
Dec
(3) |
2012 |
Jan
|
Feb
(13) |
Mar
(17) |
Apr
(32) |
May
(22) |
Jun
(35) |
Jul
(56) |
Aug
(16) |
Sep
(8) |
Oct
(26) |
Nov
(30) |
Dec
(29) |
2013 |
Jan
(23) |
Feb
(19) |
Mar
(9) |
Apr
(39) |
May
(30) |
Jun
(23) |
Jul
(33) |
Aug
(7) |
Sep
(13) |
Oct
(40) |
Nov
(91) |
Dec
(43) |
2014 |
Jan
(59) |
Feb
(37) |
Mar
(28) |
Apr
(43) |
May
(37) |
Jun
(21) |
Jul
(56) |
Aug
(43) |
Sep
(44) |
Oct
(102) |
Nov
(31) |
Dec
(48) |
2015 |
Jan
(111) |
Feb
(114) |
Mar
(36) |
Apr
(59) |
May
(19) |
Jun
(17) |
Jul
(13) |
Aug
(36) |
Sep
(24) |
Oct
(43) |
Nov
(66) |
Dec
(39) |
2016 |
Jan
(41) |
Feb
(33) |
Mar
(21) |
Apr
(54) |
May
(48) |
Jun
(34) |
Jul
(42) |
Aug
(73) |
Sep
(31) |
Oct
(115) |
Nov
(41) |
Dec
(48) |
2017 |
Jan
(31) |
Feb
(32) |
Mar
(23) |
Apr
(20) |
May
(70) |
Jun
(26) |
Jul
(17) |
Aug
(22) |
Sep
(15) |
Oct
(14) |
Nov
(20) |
Dec
(4) |
2018 |
Jan
(45) |
Feb
(27) |
Mar
(16) |
Apr
(54) |
May
(30) |
Jun
(50) |
Jul
(25) |
Aug
(5) |
Sep
(7) |
Oct
(60) |
Nov
(75) |
Dec
(21) |
2019 |
Jan
(18) |
Feb
(14) |
Mar
(17) |
Apr
(15) |
May
(17) |
Jun
(9) |
Jul
(12) |
Aug
(11) |
Sep
(22) |
Oct
(30) |
Nov
(19) |
Dec
(18) |
2020 |
Jan
(29) |
Feb
(12) |
Mar
(54) |
Apr
(51) |
May
(50) |
Jun
(50) |
Jul
(34) |
Aug
(29) |
Sep
(54) |
Oct
(77) |
Nov
(26) |
Dec
(16) |
2021 |
Jan
(71) |
Feb
(22) |
Mar
(63) |
Apr
(15) |
May
(23) |
Jun
(30) |
Jul
(23) |
Aug
(15) |
Sep
(5) |
Oct
(12) |
Nov
(7) |
Dec
(5) |
2022 |
Jan
(44) |
Feb
(33) |
Mar
(16) |
Apr
(5) |
May
(9) |
Jun
(13) |
Jul
(7) |
Aug
(34) |
Sep
(22) |
Oct
(5) |
Nov
(31) |
Dec
(33) |
2023 |
Jan
(15) |
Feb
(3) |
Mar
(9) |
Apr
(20) |
May
(50) |
Jun
(6) |
Jul
(6) |
Aug
(6) |
Sep
(4) |
Oct
(7) |
Nov
(7) |
Dec
(6) |
2024 |
Jan
(8) |
Feb
(10) |
Mar
(8) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(6) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Gerhard S. <ger...@gm...> - 2020-06-02 18:47:29
|
On Mon, 2020-06-01 at 22:50 -0700, Timo Kokkonen wrote: > > On Mon, Jun 1, 2020 at 12:21 AM Gerhard Sittig <ger...@gm...> wrote: > > [ ... ] > > Common support for endianess conversion? > > Sorry, I meant 'serializers', didn't seem to find anything with > quick find/grep on sources.... You may have noticed there is the "simple, one-shot" RL16() et al group of accessors. And the "stream like" *_inc() variants which I added after finding myself repeating the read/write access _and_ the address increment too many times, which "just felt wrong" to me. Depending on your specific use case (fixed layout, or variable layout and "more of a stream") you may prefer one or the other, or pick by the mood of the day. > Btw, looking the endian conversion routines they all seem to "suffer" > some kind of compiler warning fix (?) > > For example: > static inline uint32_t read_u32le(const uint8_t *p) > { > uint32_t u; > > u = 0; > u <<= 8; u |= p[3]; > u <<= 8; u |= p[2]; > u <<= 8; u |= p[1]; > u <<= 8; u |= p[0]; > > return u; > } > > Seems as if "u = 0" has been added later to fix compiler waning about using > uninitialized variable, etc? Making the first "u <<=8;" > unnecessary/redundant.... Not sure what you perceive as "afterthought" there, or "workaround" for potential compiler warnings. The code was written that way from the start, by design, for good reasons. Not a second was spent on dropping the initial zero assignment, or not putting it there at all. Let's see why. Gotta change from LE to BE format? Just swap the lines which collect the bytes. Gotta create a 32bit reoutine after 16bit support exists? Just add two more lines. Need to support funny alternatives to ABCD and DCBA, like BADC? Just swap the lines. Found a typo/braino in the implementation? Just arrange the lines in the correct order. Simple manipulation, straight diff, easy to read, easy to reason about, keeps working reliably, etc etc. Spent some time typing the characters? Count them, didn't take one second. How much more often is the code read, and needs to be pondered on? Takes a lot longer. Computers are good at boring stuff. Constant folding (the 0 << 8 expression) are bread and butter to them. As a human I only have limited resources, and suck at juggling dozens of things in my head. So I'd rather concentrate on the application perspective, and leave the tedium to the machine. Try to be extra smart, and you end up outsmarting yourself. That's why I hate exceptions, especially when they are unnecessary (think trailing comma, order of include directives, and others). There are some things that humans just should not have to spend precious conscious resources on. They got other things to do, and can use these resources in more productive ways. > Or am I missing something? Minor detail really, was just wondering if > if I'm not seeing something obvious... > (good compiler probably will optimize it away though...) That's the very point of these inline routines. Better optimizers may not even shift at all, or access individual bytes, do any math, etc etc. They may just pick the one machine instruction which "does just that" and be done. I don't care how compilers translate the source to machine opcodes (though I trust that today's compilers grok these phrases very well, and know what they intend to do). All I want is the thing to work, and reliably so. And then forget this foundation stuff and do the real work in the application layer. If you want to help, review and extend the test sequence for the endianess conversion. Getting more coverage is highly desirable. Spotting potential issues in the current implementation (from the caller's perspective) is as beneficial as increasing confidence in the existing code. If you are curious, give the source to the godbolt compiler explorer. Disclaimer: I haven't, just assumed that these phrases map well to CPU instructions. Call it an educated guess. virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. |
From: Frank S. <fra...@gm...> - 2020-06-02 11:03:20
|
On Sun, May 31, 2020 at 11:26 AM, Timo Kokkonen <tj...@ik...> wrote: > On Sat, May 30, 2020 at 11:18 PM Gerhard Sittig <ger...@gm...> wrote: > > - Check portability. Do you fill in structs and then send _these_ > > to the wire? Might be convenient but need not work everywhere. > > It's probably better to accept the tedium and properly stream > > requests and responses for improved reliability. Notice that > > the tedium is less with the recently introduced conversion > > helpers which also advance their position in the stream. > > Code should be portable (?) I'm aware of dangers different cpu > architectures, but yes I'm "cheating" little bit by using a struct, > but the struct is (on purpose) just an array of bytes. This allows referencing > positions in the buffer conveniently... > I can't think of portability issues with this approach, or am I > missing something? When you have a struct you want to send over the line "as is" and not want the compiler to optimize it (avoid padding), you should add "__attribute__((packed))". E.g.: struct __attribute__((packed)) my_packet { uint8_t my_unsigned_8_bit_field; int16_t my_signed_16_bit_field; }; IIRC this works for clang and gcc. Cheers Frank |
From: Frank S. <fra...@gm...> - 2020-06-02 10:23:55
|
Hi Timo, nice job! :) You might want to add support for SmuView? Then you want to add a mutex (GMutex) to make the serial read/write thread safe. Background is that data acquisition and getting/setting of config keys are running in separate threads in SmuView. Have a look at the arachnid-labs-re-load-pro driver (acquisition_mutex) or the korad-kaxxxxp driver (rw_mutex) for examples. For bonus points you want to add the SR_CONF_LIST capability to the SR_CONF_REGULATION config key and return something like {"CV", "CC", "UR", ...}. This is useful for sigrok-cli and very useful for SmuView. See also the arachnid-labs-re-load-pro driver for an example. But wait, there are extra bonus points :) When the status of the device changes (e.g. entering over current protection, changing the output state, etc.) you can send a meta package, so that SmuView can show this change or sigrok-cli print a message to the terminal. This is already implemented in some of the drivers, like arachnid-labs-re-load-pro and korad-kaxxxxp. Cheers Frank |
From: Timo K. <tj...@ik...> - 2020-06-02 09:30:41
|
On Wed, May 27, 2020 at 10:46 PM Gerhard Sittig <ger...@gm...> wrote: > The reason why I ask: Does that change of collapsing _any_ of the > CR and/or LF combinations affect other devices which currently > are supported? I know that there are empty requests (initiating > remote operation by sending a mere newline). Are there empty > responses, too? Because these now would get dropped, or are not > detected any longer, or are mistaken as something different and > the request/response relation gets out of sync. I re-thought the changes to SCPI and it's now down to one tiny change to scpi_serial.c that should not break any existing SCPI devices. Since any devices that work with current SCPI (serial) code must be terminating their responses with NL (<LF>), or they won't work (symptom being SCPI commands timing out). I'm suggesting changing the scpi_serial_read_data() slightly to look for special case where returned data ends with <LF><CR> and squash the <CR> (only in this specific instance). This allows any devices that interpret the spec like GW-Instek does to work. Eithout affecting devices terminating responses with only <LF> like what seems to be how majority of vendors interpret the spec. diff --git a/src/scpi/scpi_serial.c b/src/scpi/scpi_serial.c index 90c01424..43bd044d 100644 --- a/src/scpi/scpi_serial.c +++ b/src/scpi/scpi_serial.c @@ -190,7 +190,12 @@ static int scpi_serial_read_data(void *priv, char *buf, int maxlen) if (ret > 0) { if (buf[ret - 1] == '\n') { sscpi->got_newline = TRUE; - sr_spew("Received terminator"); + sr_spew("Received NL terminator"); + } else if (ret > 1 && + buf[ret - 2] == '\n' && buf[ret - 1] == '\r') { + sscpi->got_newline = TRUE; + sr_spew("Received NL+CR terminator"); + ret--; } else { sscpi->got_newline = FALSE; } Well, there is another minor change to scpi.c, but this clearly won't break any existing stuff (?). Since it simply adds support for devices that respond to SCPI command *IDN? with out the serial number field: diff --git a/src/scpi/scpi.c b/src/scpi/scpi.c index 2477cf23..cc213ff8 100644 --- a/src/scpi/scpi.c +++ b/src/scpi/scpi.c @@ -1117,8 +1117,8 @@ SR_PRIV int sr_scpi_get_hw_id(struct sr_scpi_dev_inst *scpi, */ tokens = g_strsplit(response, ",", 0); num_tokens = g_strv_length(tokens); - if (num_tokens < 4) { - sr_dbg("IDN response not according to spec: %80.s.", response); + if (num_tokens < 3) { + sr_dbg("IDN response not according to spec: '%s'", response); g_strfreev(tokens); g_free(response); return SR_ERR_DATA; @@ -1134,8 +1134,13 @@ SR_PRIV int sr_scpi_get_hw_id(struct sr_scpi_dev_inst *scpi, hw_info->manufacturer = g_strstrip(g_strdup(idn_substr + 4)); hw_info->model = g_strstrip(g_strdup(tokens[1])); - hw_info->serial_number = g_strstrip(g_strdup(tokens[2])); - hw_info->firmware_version = g_strstrip(g_strdup(tokens[3])); + if (num_tokens < 4) { + hw_info->serial_number = g_strdup("Unknown"); + hw_info->firmware_version = g_strstrip(g_strdup(tokens[2])); + } else { + hw_info->serial_number = g_strstrip(g_strdup(tokens[2])); + hw_info->firmware_version = g_strstrip(g_strdup(tokens[3])); + } g_strfreev(tokens); I would really appreciate comments and review of these changes: The following changes since commit cbfaf5e073765175236d562c05f21fef9d9cd54f: uni-t-ut181a: comment on how to start a recording (2020-06-01 18:35:05 +0200) are available in the Git repository at: https://github.com/tjko/libsigrok gwinstek for you to fetch changes up to bea151f4ea17f9a2fa66224f79053fd15c133bb3: Make sure we report "INFINITY" when meter displays "0L" (2020-06-02 01:50:13 -0700) ---------------------------------------------------------------- Timo Kokkonen (4): added support to GW-Instek 8200A series bench meters add support for (broken?) devices sending NR+CR terminator Add support for devices that do not report serial number in response to *IDN? command. And fix bug in sr_dbg() format string. Make sure we report "INFINITY" when meter displays "0L" src/hardware/scpi-dmm/api.c | 69 +++++++++++++ src/hardware/scpi-dmm/protocol.c | 209 +++++++++++++++++++++++++++++++++++++++ src/hardware/scpi-dmm/protocol.h | 2 + src/scpi/scpi.c | 13 ++- src/scpi/scpi_serial.c | 7 +- 5 files changed, 295 insertions(+), 5 deletions(-) -- Timo <tj...@ik...> |
From: Timo K. <tj...@ik...> - 2020-06-02 05:50:48
|
On Mon, Jun 1, 2020 at 12:21 AM Gerhard Sittig <ger...@gm...> wrote: > An approach was suggested on IRC, may or may not go mainline, and > make the frame format spec optional when it's 8n1. There are > other meters out there which run "funny" UART frame formats, and > will keep requiring this spec. I just merged updates from official repo and looks like this change has been incorporated, works great.... > Since you probably don't run the project's official mirror and > your repo is not a read-only copy of the source, may I suggest > that you adjust your repo's description? :) (Don't worry, it's > rather popular to not notice.) Thanks, it's now updated. I had not paid too much attention to github (web) interface... > fields even. Something to remain aware of during maintenance. If > you don't expect later commits to change the "everything is a > byte" packet struct layout, then things may be acceptable. Using > proper serializers from the start just avoids this potential for > errors for the remaining driver's lifetime. I added comment as reminder, to discourage someone coming later and be tempted to make such changes... I would not expect the struct ever changing, its fixed 26 byte frame/buffer. > Common support for endianess conversion? Sorry, I meant 'serializers', didn't seem to find anything with quick find/grep on sources.... > An alternative is to just lookup the RL16() identifier that was > mentioned before, and see the group of conversion helpers for all > kinds of width and signedness and endianess. You seem to need the > 8 and 16 and 32 bit variants. Thanks, found those code is now updates to use these instead. (dogyxen tags in the source is perfect :) Btw, looking the endian conversion routines they all seem to "suffer" some kind of compiler warning fix (?) For example: static inline uint32_t read_u32le(const uint8_t *p) { uint32_t u; u = 0; u <<= 8; u |= p[3]; u <<= 8; u |= p[2]; u <<= 8; u |= p[1]; u <<= 8; u |= p[0]; return u; } Seems as if "u = 0" has been added later to fix compiler waning about using uninitialized variable, etc? Making the first "u <<=8;" unnecessary/redundant.... Or am I missing something? Minor detail really, was just wondering if if I'm not seeing something obvious... (good compiler probably will optimize it away though...) -- Timo <tj...@ik...> |
From: Gerhard S. <ger...@gm...> - 2020-06-01 07:16:39
|
On Sun, 2020-05-31 at 02:26 -0700, Timo Kokkonen wrote: > > [ ... ] > > Btw, is there convention how to only specify bitrate (speed) on command line? As of now, current mainline support code for serial communication makes all of the bitrate and the frame format mandatory. An approach was suggested on IRC, may or may not go mainline, and make the frame format spec optional when it's 8n1. There are other meters out there which run "funny" UART frame formats, and will keep requiring this spec. > I didn't really have a git repo (I had "read-only" clone from of the > official repo), but I have now created one: > > https://github.com/tjko/libsigrok.git Well if you cloned it, that clone is yours and you can write to it as much as you want to. The "read-only" refers to the sigrok project's github repo which is not _the_ project's official home, but "just" a mirror that the project keeps for the convenience of those who prefer to clone from github, for whatever reason. You can clone from any repo that you like. The sigrok.org site would be the official one. As the project's home page states. Since you probably don't run the project's official mirror and your repo is not a read-only copy of the source, may I suggest that you adjust your repo's description? :) (Don't worry, it's rather popular to not notice.) > Code should be portable (?) I'm aware of dangers different cpu > architectures, but yes I'm "cheating" little bit by using a struct, > but the struct is (on purpose) just an array of bytes. This allows > referencing positions in the buffer conveniently... > I can't think of portability issues with this approach, or am I > missing something? In this very specific case of all-bytes in the struct, it happens to work. It's just that I recently "fought" a driver source code which assumed a specific memory layout for C language variables, including struct members of different types and widths, and bit fields even. Something to remain aware of during maintenance. If you don't expect later commits to change the "everything is a byte" packet struct layout, then things may be acceptable. Using proper serializers from the start just avoids this potential for errors for the remaining driver's lifetime. An alternative approach to the struct with all bytes in them would be an array, and a declaration of indices for specific fields in the packet. May not make a difference on popular platforms, but could increase portability in the strict sense. Let's see what others suggest. > Do you have reference/link to documentation on these conversion > helpers? (those sound interesting) Common support for endianess conversion? Just see the recent libsigrok history, it's been only a couple of days ago that they got improved for robustness. The test code can demonstrate how to use them, if the inline doc is not sufficient. An alternative is to just lookup the RL16() identifier that was mentioned before, and see the group of conversion helpers for all kinds of width and signedness and endianess. You seem to need the 8 and 16 and 32 bit variants. virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. |
From: Timo K. <tj...@ik...> - 2020-06-01 06:16:54
|
On Sat, May 30, 2020 at 11:18 PM Gerhard Sittig <ger...@gm...> wrote: > Have also learned that maintainers prefer to fetch from public > repos instead of having patches sent when you plan to submit core > more often on different subjects, or when you expect several > iterations of review and improvement. Dealing with individual > files many times quickly gets old. Just send a URL to the repo, > that's easier. I cleaned up the code and incorporated most of the suggested changes. So current version is likely much better to review: https://github.com/tjko/libsigrok.git https://github.com/sigrokproject/libsigrok/compare/master...tjko:master -- Timo <tj...@ik...> |
From: Jurgen K. <gtm...@xs...> - 2020-05-31 15:05:45
|
Hi, I just acquired a Siglent SPD1168X programmable power supply. It comes with both USB and LAN connectivity. Via LAN it supports the SCPI interface. Looking through the Sigrok sources my guess is that support can be added through the scpi-pps driver? The manual states commands need a '\n' to work, it that normal for a SCPI device? I am heading in the right direction here? I'd like to add support for it. Jurgen |
From: Timo K. <tj...@ik...> - 2020-05-31 09:26:50
|
On Sat, May 30, 2020 at 11:18 PM Gerhard Sittig <ger...@gm...> wrote: > How many sigrok drivers have you created before that? This one Just this one, if not counting changes/patch to scpi-dmm to add GW-Instek bench meter support... Got an idea earlier this week to hook up all various test equipment on my bench to RasberryPi, and that lead to Sigrok, and then that lead into pulling libsigrok sources to see how much work would it be to get my bench meter and electronic load supported... And here we are :) > Are models using different UART bitrates or frame parameters? If > these are default values, the driver could encode them, and users > need not specify them. Simplifies the invocation. But you might > as well have provided them for demonstration. No issue there. Units seem to have 9600/8n1 factory default (only bitrate is configurable). Driver has default setting so that don't have to always specify "serialcomm". (need to check that I set it to 9600 and not 38400 that I use...) Btw, is there convention how to only specify bitrate (speed) on command line? > This suggests that you have the commits in a git repo, and have > an account for a service. Instead of "hiding" the patches in a > gist, would it not be easier to push the commits to a public > repo? I didn't really have a git repo (I had "read-only" clone from of the official repo), but I have now created one: https://github.com/tjko/libsigrok.git > Things that come to mind: > - Does your driver *depend* on the serial transport in the build > instructions? So that it automatically gets deselected when an > essential dependency is missing, and won't break the build. I added "serial_comm" as dependency in configure.ac, that's what you meant, right? > - You need not re-invent endianess conversion. Macros like RL16() > have been around for ages, recently read_u16le() got added. Thanks, I'll take a look and use those. > - Check whitespace, sometimes operands and operators "run into > each other", which is harder to read. > - Check data types, use of "char" where bytes get processed is > unexpected. Prefer C99 uint8_t etc types over "unsigned char" > stuff to even better reflect intent? Thanks, I'll do some cleanup. > - Check text line length, and indentation depth. There may be > different styles preferred by different persons. Let's hear > what others say. I personally like to see the structure first > and not indent continuation lines _that_ deep. That's Emacs (learned to use Emacs in late 80's, and it's hard to change habits :) I noticed Debian (Rasbian) finally had "linux kernel" mode included by default, but seems like its still kind of "broken".... I don't suppose there published Emacs settings/config that produces layout preferred by the project? > - Check portability. Do you fill in structs and then send _these_ > to the wire? Might be convenient but need not work everywhere. > It's probably better to accept the tedium and properly stream > requests and responses for improved reliability. Notice that > the tedium is less with the recently introduced conversion > helpers which also advance their position in the stream. Code should be portable (?) I'm aware of dangers different cpu architectures, but yes I'm "cheating" little bit by using a struct, but the struct is (on purpose) just an array of bytes. This allows referencing positions in the buffer conveniently... I can't think of portability issues with this approach, or am I missing something? Do you have reference/link to documentation on these conversion helpers? (those sound interesting) > Are you aware of a wiki page for this load? Want to update or > create one? I can't promise that I have time, but if you create entry under sigrok wiki for these, I could be tempted to make some updates... -- Timo <tj...@ik...> |
From: Gerhard S. <ger...@gm...> - 2020-05-31 06:40:13
|
On Sat, 2020-05-30 at 00:59 -0700, Timo Kokkonen wrote: > > I was testing new driver for electronic loads and noticed odd behavior with > sigrok-cli. > > Output seems fine without "-O csv": There probably are several issues that interact in your setup. When you just specify the -O format but omit the -o file spec, your screen may see interleaved output that gets emitted from several code paths in parallel (and with optional buffering which additionally garbles the output). In other words the screen output may differ from a generated output file without the remaining screen output. > # ./sigrok-cli -d itech-it8500:conn=/dev/ttyUSB1:serialcomm=38400/8n1 --samples 4 > FRAME-BEGIN > V1: 12.01100 V DC > I1: 499.60 mA DC > P1: 6.00000 W DC > FRAME-END > [ ... ] > > But CSV output seems messed up: > > # ./sigrok-cli -d itech-it8500:conn=/dev/ttyUSB1:serialcomm=38400/8n1 --samples 4 -O csv > ; CSV generated by libsigrok 0.6.0-git-7e46c8ec > ; from ITECH IT8500 series on Sat May 30 00:48:31 2020 > ; Channels (3/3): V1, I1, P1 > ; Samplerate: 10 Hz > > V1: 12.01000 V DC > I1: 499.50 mA DC > V DC,A DC,W DC > 12.01,0.4995,5.999 > FRAME-END > > [ ... ] The current implementation of CSV export was created with logic data in mind. That's what the source code suggests, concentration on a specific use case, and either assumption that other uses are not tried, or that they get addressed at a later point in time. CSV export may work with a single analog channel. But for mixed signal data, or multiple analog channels, results very probably are unexpected, and incorrect. That's how I read the comments in the implementation. The code needs to get extended. That's a known limitation, has been that way for years, and nobody has yet gone and done something about it. Developers are busy and don't use this feature, and users haven't contributed something better. Which makes me believe that either the feature is not used in the field, or that users perceive the current lack of better support as not important enough to do something about it. Another explanation would be that other output formats are available as workarounds, or that the CSV output is not used in combination with analog data types. -- I don't know, as I don't use CSV myself either. Your guess is as good as mine. > Is this perhaps something in sigrok-cli, or could it be the driver somehow? Neither, it's the src/output/csv.c output module. virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. |
From: Gerhard S. <ger...@gm...> - 2020-05-31 06:14:14
|
On Sat, 2020-05-30 at 16:30 -0700, Timo Kokkonen wrote: > > This is a new driver for the DC electronic loads made by ITECH. It > would seem ITECH is the OEM manufacturer of BK Precision 8500 series > loads (their programming specs are pretty much identical and units > look identical except logos), so those BK Precision units should work > with that driver "as is"... How many sigrok drivers have you created before that? This one looks awesome. Instantly operational with all features that you could support for a new device, in a consistent style and with useful abstractions. Nice! Minor style nits remain, but these are easy to address. Haven't dug too deep (reason: see below), but am confident only little adjustment remains to be done before mainline integration. > I've been testing the driver using ITECH IT8511+ which reports itself > as "8511" via the (TTL) serial interface: > > # ./sigrok-cli -d itech-it8500:conn=/dev/ttyUSB1:serialcomm=38400/8n1 --scan > The following devices were found: > itech-it8500 - ITECH 8511 1.13 [S/N: 0717xxxxxx] with 3 channels: V1 I1 P1 Are models using different UART bitrates or frame parameters? If these are default values, the driver could encode them, and users need not specify them. Simplifies the invocation. But you might as well have provided them for demonstration. No issue there. > [ ... ] > > Patches are available at (it's split into two patches): > https://gist.github.com/tjko/492e147f3b84a8f2003da4616711b7f9 This suggests that you have the commits in a git repo, and have an account for a service. Instead of "hiding" the patches in a gist, would it not be easier to push the commits to a public repo? This would let others use either their browser or git or any other tool of choice, on either patches or resulting files. Would provide more options on the consumer's side and reduce the amount of work to get the content, and would help during review. > Any comments most welcome. I tried to follow the recommended > guidelines and used the existing (electronic load) drivers as model > for this driver. Things that come to mind: - Does your driver *depend* on the serial transport in the build instructions? So that it automatically gets deselected when an essential dependency is missing, and won't break the build. - You need not re-invent endianess conversion. Macros like RL16() have been around for ages, recently read_u16le() got added. - Check whitespace, sometimes operands and operators "run into each other", which is harder to read. - Check data types, use of "char" where bytes get processed is unexpected. Prefer C99 uint8_t etc types over "unsigned char" stuff to even better reflect intent? - Check text line length, and indentation depth. There may be different styles preferred by different persons. Let's hear what others say. I personally like to see the structure first and not indent continuation lines _that_ deep. - Check portability. Do you fill in structs and then send _these_ to the wire? Might be convenient but need not work everywhere. It's probably better to accept the tedium and properly stream requests and responses for improved reliability. Notice that the tedium is less with the recently introduced conversion helpers which also advance their position in the stream. This was unsorted, and from the top of my head. Might have another look when the patches are available in a git branch which is easier to handle than downloading patches from web pages. Have also learned that maintainers prefer to fetch from public repos instead of having patches sent when you plan to submit core more often on different subjects, or when you expect several iterations of review and improvement. Dealing with individual files many times quickly gets old. Just send a URL to the repo, that's easier. Are you aware of a wiki page for this load? Want to update or create one? Want "more interactive" discussion than what's possible in a mailing list? Many developers hang out in IRC. virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. |
From: Timo K. <tj...@ik...> - 2020-05-30 23:30:22
|
This is a new driver for the DC electronic loads made by ITECH. It would seem ITECH is the OEM manufacturer of BK Precision 8500 series loads (their programming specs are pretty much identical and units look identical except logos), so those BK Precision units should work with that driver "as is"... I've been testing the driver using ITECH IT8511+ which reports itself as "8511" via the (TTL) serial interface: # ./sigrok-cli -d itech-it8500:conn=/dev/ttyUSB1:serialcomm=38400/8n1 --scan The following devices were found: itech-it8500 - ITECH 8511 1.13 [S/N: 0717xxxxxx] with 3 channels: V1 I1 P1 # ./sigrok-cli -d itech-it8500:conn=/dev/ttyUSB1:serialcomm=38400/8n1 --scan -l 3 sr: itech-it8500: Probing serial port: /dev/ttyUSB1 sr: itech-it8500: Model name: 8511 (v1.13) sr: itech-it8500: Serial number: 0717xxxxxx sr: itech-it8500: Address: 0 sr: itech-it8500: Max current: 30 A sr: itech-it8500: Max power: 200 W sr: itech-it8500: Voltage range: 0.1 - 120.0 V sr: itech-it8500: Resistance range: 0.05 - 7500.00 Ohm sr: itech-it8500: Mode: CC sr: itech-it8500: State: OFF The following devices were found: itech-it8500 - ITECH 8511 1.13 [S/N: 0717xxxxxx] with 3 channels: V1 I1 P1 Patches are available at (it's split into two patches): https://gist.github.com/tjko/492e147f3b84a8f2003da4616711b7f9 Any comments most welcome. I tried to follow the recommended guidelines and used the existing (electronic load) drivers as model for this driver. -- Timo <tj...@ik...> |
From: Timo K. <tj...@ik...> - 2020-05-30 08:00:00
|
I was testing new driver for electronic loads and noticed odd behavior with sigrok-cli. Output seems fine without "-O csv": # ./sigrok-cli -d itech-it8500:conn=/dev/ttyUSB1:serialcomm=38400/8n1 --samples 4 FRAME-BEGIN V1: 12.01100 V DC I1: 499.60 mA DC P1: 6.00000 W DC FRAME-END FRAME-BEGIN V1: 12.01100 V DC I1: 499.60 mA DC P1: 6.00000 W DC FRAME-END FRAME-BEGIN V1: 12.01100 V DC I1: 499.50 mA DC P1: 5.99900 W DC FRAME-END FRAME-BEGIN V1: 12.01100 V DC I1: 499.50 mA DC P1: 5.99900 W DC FRAME-END But CSV output seems messed up: # ./sigrok-cli -d itech-it8500:conn=/dev/ttyUSB1:serialcomm=38400/8n1 --samples 4 -O csv ; CSV generated by libsigrok 0.6.0-git-7e46c8ec ; from ITECH IT8500 series on Sat May 30 00:48:31 2020 ; Channels (3/3): V1, I1, P1 ; Samplerate: 10 Hz V1: 12.01000 V DC I1: 499.50 mA DC V DC,A DC,W DC 12.01,0.4995,5.999 FRAME-END V1: 12.01000 V DC I1: 499.50 mA DC 12.01,0.4995,5.999 FRAME-END V1: 12.01000 V DC I1: 499.50 mA DC 12.01,0.4995,5.999 FRAME-END V1: 12.01000 V DC I1: 499.50 mA DC 12.01,0.4995,5.999 FRAME-END Is this perhaps something in sigrok-cli, or could it be the driver somehow? -- Timo <tj...@ik...> |
From: Soeren A. <so...@ap...> - 2020-05-29 12:50:07
|
Hello Fred, You may want to check the output in the log. You can access it from within the settings dialog. Regards -Soeren On Fri, 2020-05-29 at 08:36 -0400, Fred Decker wrote: > Hi needed to fix a bug in the DCC decoder included in Pulseview. > Using Windows 10, I opened it in notepad++ and added some > hashtag comments and changed 3 lines of the code. Saving it was an > issue since the program files folder is write protected, so I saved > it to my desktop and then used windows to copy it to the program > folder and overwrite the one there. Now it disappeared from the > decoder menu. > > I then copied the file to C:\ProgramData\libsigrokdecode\decoders\dcc > since I saw that on the web help. Nothing. So I tried copying one of > the other files that I didn't mess with and just changed the name and > id inside it. That didn't work either. Nothing I create shows up in > the decoder list. > _______________________________________________ > sigrok-devel mailing list > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Fred D. <fnd...@gm...> - 2020-05-29 12:37:29
|
Hi needed to fix a bug in the DCC decoder included in Pulseview. Using Windows 10, I opened it in notepad++ and added some hashtag comments and changed 3 lines of the code. Saving it was an issue since the program files folder is write protected, so I saved it to my desktop and then used windows to copy it to the program folder and overwrite the one there. Now it disappeared from the decoder menu. I then copied the file to C:\ProgramData\libsigrokdecode\decoders\dcc since I saw that on the web help. Nothing. So I tried copying one of the other files that I didn't mess with and just changed the name and id inside it. That didn't work either. Nothing I create shows up in the decoder list. |
From: Jacques P. <jpe...@ie...> - 2020-05-28 08:37:13
|
Pulseview compiled successfully with the latest version of cmake (3.17) Works fine! Le 20-05-27 à 05 h 14, Jacques Pelletier a écrit : > I use cmake 3.5.1 > > > Le 20-05-19 à 12 h 54, Soeren Apel a écrit : >> Hello Jacques, >> >> Sounds like a bug in automoc. >> >> Which version of CMake do you use? >> >> -Soeren >> >> >> On Tue, 2020-05-19 at 11:24 -0400, Jacques Pelletier wrote: >>> Hi, >>> >>> I'm trying to compile pulseview but I get error messages. >>> >>> "error: redefinition of ‘struct >>> qt_meta_stringdata_pv__views__trace__CustomScrollArea_t’..." >>> >>> This is caused by the double include in pulseview_automoc.cpp >>> >>> #include "moc_view.cpp" >>> >>> How can I correct this if the file pulseview_automoc.cpp is >>> generated? >>> >>> >>> JP >>> >>> >>> >>> _______________________________________________ >>> sigrok-devel mailing list >>> sig...@li... >>> https://lists.sourceforge.net/lists/listinfo/sigrok-devel > > > > > _______________________________________________ > sigrok-devel mailing list > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Timo K. <tj...@ik...> - 2020-05-28 07:41:32
|
On Wed, May 27, 2020 at 10:46 PM Gerhard Sittig <ger...@gm...> wrote: > Is this covered by the SCPI spec? Thought CR/LF was the canonical > EOL condition, but don't know the spec by heart, so could be wrong. SCPI-1999 doesn't seem to go that "low level". But it would seem this is covered in IEEE 488.2-1992. Looking the spec "response message terminator" is defined as: NL + ^END NL is defined in the spec as ASCII 0x0A i.e. line-feed (or LF). But it seems bit unclear if ^END could be interpreted as carriage-return (ASCII 0x0D)... [OffTopic: Based on spec it would seem existing sr_scpi_get_string() breaks the spec since it strips "CR" from the response message (if it happens to end in "CR"), which it really shouldn't do (?) since according to spec anything before NL is part of the message....] Would it be acceptable to not squash/collapse arbitrary CR/LF combinations, but just add specific case/exception for "<LF><CR>" at the end of received message? (as "<LF>" and "<CR><LF>" are being squashed already...) Since it would seems like any existing devices that libsigrok is accessing using the "SCPI" code must be always terminating their response message with <LF>, or things would not work... So adding this special case to treat "<LF><CR>" at the end of received data as "<LF>" should not break anything? Or would you recommend going the route of completely separate driver for these GW-Instek bench meters? (extending scpi-dmm driver seemed good choice to avoid having lot of "redundant" code...) -- Timo <tj...@ik...> |
From: Gerhard S. <ger...@gm...> - 2020-05-28 05:42:30
|
On Tue, 2020-05-26 at 21:07 -0700, Timo Kokkonen wrote: > > - Update SCPI code to support devices sending different kinds of line > termination sequences; <LF>, <CR>, <CR><LF>, <LF><CR> Is this covered by the SCPI spec? Thought CR/LF was the canonical EOL condition, but don't know the spec by heart, so could be wrong. Mind you, I do understand that this is a workaround for a device which was found "in the wild". Which may talk something that is SCPI like, but may not be strictly SCPI. So the motivation is obvious. The reason why I ask: Does that change of collapsing _any_ of the CR and/or LF combinations affect other devices which currently are supported? I know that there are empty requests (initiating remote operation by sending a mere newline). Are there empty responses, too? Because these now would get dropped, or are not detected any longer, or are mistaken as something different and the request/response relation gets out of sync. virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. |
From: Soeren A. <so...@ap...> - 2020-05-27 10:42:56
|
Hi guys, Quick feedback from my side: PV is certainly going to have RLE compression implemented, by fall if things go as planned. The biggest hurdle is maintaining the drawing performance, as Gerhard pointed out. -Soeren On Tue, 2019-09-24 at 11:08 +0200, David Given wrote: > I was in the same position a little while back, when I needed to > compare traces from multiple captures. I didn't find anything, > unfortunately. > > What I ended up doing was writing a little tool which converted my > captures into audio files, and then loading them as multiple tracks > into Audacity for visual comparison. I was only capturing about > 1000ms of single-channel data at 24MHz so the file sizes were > reasonable. But Audacity is actually a reasonably good poor-man's- > waveform-visualiser, having useful features like the ability to nudge > traces left and right to make them line up. > > On Tue, 24 Sep 2019 at 03:24, Stuart Longland < > st...@lo...> wrote: > > Hi all, > > > > Silly question, I'm using `sigrok-cli` with a DSLogic Plus to do > > some > > analysis of some code performance at work. > > > > Namely we've instrumented OpenThread to wiggle some GPIOs when a > > 802.15.4 frame is first received and whilst it is performing the > > AES-ECB > > encryption (it implements its own AES-CCM atop mbedtls AES-ECB). > > The > > aim is to compare the amount of time spent doing encryption whilst > > using > > the microcontroller's hardware AES encryption module versus doing > > it in > > software with mbedtls. > > > > I've got `sigrok-cli` to capture 4 channels at 25MHz (any faster > > and it > > gives up, despite the device being able to "stream" at 100MHz). > > I've > > run 6 tests; 3 with hardware crypto enabled, and 3 without, and > > saved > > the VCD dumps from `sigrok-cli`. > > > > Now VCD is simple enough that I've been able to rough up some > > scripts to > > analyse these, but the "there must be a better way" thought is > > still > > nagging me to keep looking around. > > > > Specifically, I want to be able to compare two waveforms side-by- > > side, > > and gather some stats like how wide a given pulse is or how much > > time a > > signal has been sampled in a given state. > > > > Best I've found for just viewing the waveform has been `gtkview`. > > However, it is quite limited. I haven't been able to get the sorts > > of > > stats out I need. > > > > PulseView can import a VCD, but doing so is a recipe for watching > > my > > workstation grind to a halt until OOMkiller sorts it out. (A > > similar > > foot-gun is setting the sample rate and period too high.) > > > > I suspect PulseView may be trying to load the entire raw file into > > memory: "decompressing" the changes and thus generating the > > original raw > > samples. 40 seconds worth of 4-bit 25MHz samples is quite a lot of > > data > > and I'm not sure how PulseView represents it internally -- perhaps > > that > > is worth looking at. > > > > DSView I know can give some of these stats, but it can't import > > VCDs at > > all. Given it's a distant PulseView fork, I suspect it might have > > the > > same problem if it did. > > > > - Are there plans to address how PulseView manipulates pre- > > recorded > > (specifically delta-recorded like VCD) data to prevent OOM issues? > > - Are there plans to develop tools for manipulating (cropping, > > merging, > > appending) logic traces for comparison and analysis? > > > > Regards, > > -- > > Stuart Longland (aka Redhatter, VK4MSL) > > > > I haven't lost my mind... > > ...it's backed up on a tape somewhere. > > > > > > _______________________________________________ > > sigrok-devel mailing list > > sig...@li... > > https://lists.sourceforge.net/lists/listinfo/sigrok-devel > > > _______________________________________________ > sigrok-devel mailing list > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Jacques P. <jpe...@ie...> - 2020-05-27 09:14:39
|
I use cmake 3.5.1 Le 20-05-19 à 12 h 54, Soeren Apel a écrit : > Hello Jacques, > > Sounds like a bug in automoc. > > Which version of CMake do you use? > > -Soeren > > > On Tue, 2020-05-19 at 11:24 -0400, Jacques Pelletier wrote: >> Hi, >> >> I'm trying to compile pulseview but I get error messages. >> >> "error: redefinition of ‘struct >> qt_meta_stringdata_pv__views__trace__CustomScrollArea_t’..." >> >> This is caused by the double include in pulseview_automoc.cpp >> >> #include "moc_view.cpp" >> >> How can I correct this if the file pulseview_automoc.cpp is >> generated? >> >> >> JP >> >> >> >> _______________________________________________ >> sigrok-devel mailing list >> sig...@li... >> https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Timo K. <tj...@ik...> - 2020-05-27 04:32:29
|
On Tue, May 26, 2020 at 8:58 PM Timo Kokkonen <tj...@ik...> wrote: > > I've implemented support for GW-Instek GDM-8200A series (GDM-8251A and > GDM-8255A) bench multimeters in libsigrok. > > Sharing these incase these might be useful for others... I've been > using sigrok-cli with my bench meter (GDM-8251A) for a while without > issue using this patch. This was tested with both RS232 and USB connections. USB port on these meters use a generic serial to USB chip (CP2102), without unique USB IDs, so auto-detection doens't seem possible with current libsigrok framework (?) Patches are also available at: https://gist.github.com/tjko/97e0c08a942c582f779f614b1a6fdb22 -- Timo <tj...@ik...> |
From: Timo K. <tj...@ik...> - 2020-05-27 04:14:57
|
- add support to GW-Instek meters: GDM-8251A, GDM-8255A - dev_acquisition_start(): implement sending DMM_CMD_QUERY_PREC command to meter (if it supports it), and save response in driver private context (so measurement "callback" function can access it if needed), since DMM_CMD_QUERY_PREC was not implemented before, for backwards compatibility if it fails it only gets logged using sr_info(), so it shouldnt affect any existing meter definitions - new function scpi_dmm_get_meas_gwinstek() that GW-Instek meters use for data acquisition (as how things work is substantially different from HP/Agilent) |
From: Timo K. <tj...@ik...> - 2020-05-27 04:07:53
|
- Update SCPI code to support devices sending different kinds of line termination sequences; <LF>, <CR>, <CR><LF>, <LF><CR> - sr_scpi_get_hw_id(): add support for devices that omit serial number in *IDN? responses - sr_scpi_get_hw_id(): fix bug in sr_dbg() call "%80.s" |
From: Timo K. <tj...@ik...> - 2020-05-27 03:58:53
|
I've implemented support for GW-Instek GDM-8200A series (GDM-8251A and GDM-8255A) bench multimeters in libsigrok. Sharing these incase these might be useful for others... I've been using sigrok-cli with my bench meter (GDM-8251A) for a while without issue using this patch. I was initially about to implement new drivers for these, but then noticed that scpi-dmm driver has nice framework for supporting DMMs that implement SCPI interface. However, I noticed couple quirks with the SCPI support, it doesn't like it if meter doesn't send <LF> at the end response, so that broke GW-Instek meters since these happen to send <LF><CR> sequence... So patch is split in two parts; small change to SCPI code to make it support all possible <LF> and <CR> combinations without affecting existing usage of the code, and second patch has the changes to scpi-dmm to add support for two new meters. -- Timo <tj...@ik...> |
From: Uwe H. <uw...@he...> - 2020-05-21 23:05:30
|
On Thu, May 21, 2020 at 07:50:21PM +0200, Soeren Apel wrote: > Hello Phill, > > PulseView only supports logic analyzers and oscilloscopes at this time, > which is why other drivers are filtered out as you noticed. > > If you want to use a DMM with a graphical interface, I suggest using > either > https://sigrok.org/wiki/Sigrok-meter > or > https://sigrok.org/wiki/SmuView And for command-line usage you can use sigrok-cli: $ sigrok-cli -d va-va18b:conn=/dev/ttyUSB0 --samples 2 P1: 0 mV DC AUTO P1: 0 mV DC AUTO Cheers, Uwe. -- http://hermann-uwe.de | http://randomprojects.org | http://sigrok.org |