Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jrb improvements 2 #8

Merged
merged 5 commits into from
Aug 17, 2018
Merged

Jrb improvements 2 #8

merged 5 commits into from
Aug 17, 2018

Conversation

jrbyrne
Copy link
Contributor

@jrbyrne jrbyrne commented Aug 17, 2018

Here is a miscellaneous set of improvements I did when debugging a serial problem recently. They aren't really related to each other so I can split these up into multiple pull requests if you would prefer.

James Byrne added 5 commits August 16, 2018 11:50
Mark all internal functions as static and use 'void' for functions that
take no parameters.

Allows us to build cleanly with stricter warnings on GCC
(-Wmissing-prototypes -Wstrict-prototypes).
- Check the return value from write() for the one/two byte write case
(-y/-z) and report any errors.
- Use perror for reporting failures that set errno.
- Print all fatal errors to stderr.
- Don't report EAGAIN errors from write(). These are expected since we
are using non-blocking I/O.
- Missing port argument now exits with a code of 1 rather than 0.
- Clamp the exit code to a maximum of 125 to avoid clashes with standard
shell exit codes.
Use long long ints for the counter variables so that they won't wrap
when running a long soak test.
Previously a message would be printed every second if no data was being
received. This commit improves things so that it prints messages for
both transmission and reception timing out, and tells you how long it
has been since data was last received/transmitted. The initial timeout
for both transmission and reception is now two seconds, and after that
messages are printed every second.
This adds a new option to have the output bytes range from 32 to 126
instead of the default 0 to 255. There are two reasons why this is
useful, one is that you can directly output the bytes at the receiving
end without getting any unprintable codes, and the other is that the
sequence is not a power of two in length, which would reveal problems
where a faulty serial driver dropped a complete buffer of data (e.g. 256
bytes or 1024 bytes) that would get missed using the default sequence.
@cbrake cbrake merged commit c07e3d9 into cbrake:master Aug 17, 2018
@cbrake
Copy link
Owner

cbrake commented Aug 17, 2018

Looks good -- thanks for the changes.

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