On Mon, Jun 1, 2020 at 12:21 AM Gerhard Sittig <gerhard.sit...@gmx.net> 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 <t...@iki.fi>
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
