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. _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
