Difference between revisions of "User:PeterMortensen"
(→Shortcuts: Added shortcut for Linux nightlies.)
(→2020-01: Actually, the Fujitsu is a more modern one, with the Windows key, etc.)
|(11 intermediate revisions by the same user not shown)|
|Line 1:||Line 1:|
Latest revision as of 15:24, 12 January 2020
Getting insight into what happens with PC keyboards on the signal level and on higher levels (related to repurposing an old PS/2 keyboard (BTC 5349) as a macro keyboard, with the help of an Arduino Leonardo):
- For the keyboards listed below: Verify that all keys work (by capturing in PulseView and observe there is actually a signal. Note that the accent and umlaut key requires pressing a letter after).
- For the keyboards listed below: Capturing and submitting information for PS/2 PC keyboards (CLK and DATA), including during pressing and releasing and bidirectional traffic (PC initialising the keyboard, e.g. at connect and/or PC startup). Submit to Git repository "sigrok-dumps": Keyboards (all European layout):
- BTC 5349 (102 keys IBM/AT type, corresponding to IBM Model M (Enhanced)). 100 mA (measured). Mechanical keyboard?
- Fujitsu/Siemens (105 keys + 10 media keys (sleep, mail, play, stop, speaker controls, etc.). IBM/AT type. ?? mA.
- Microsoft "Natural Keyboard Elite". 105 keys. 500 mA (nominal).
- Apple Extended Keyboard II. 105 keys + one power key. ??? mA. Mechanical keyboard. Uses ADB, not PS/2 (physically similar, but 4-pin mini-DIN connector). A single pin for data and 'PSW' connected directly to the power switch. All communication is host initiated (polling).
- Consider adding regression tests for the PS/2 decoder. It will include if it handles the 2-3% clock frequency offset for the BTC 5349 (probably, as there is CLK, but that is not the case if decoding as the UART protocol decoder).
- Some higher-level protocol decoder work for PC keyboards (not decided on yet), e.g. identifying scan code sequences as the corresponding keys.
- Some hardware to allow an Arduino Leonardo to pose as a PC (open collector outputs). To explore what commands various keyboards responds to and what modes they might enter (for example, Linux allegedly tries put keyboards into "Set 3" (the powerup default is usually "Set 2")). The three LEDs on the keyboard can also be used for user feedback for the macro keyboard.
- Existing content on the wiki, etc. regarding PC keyboards, etc.:
- Keyboards (none found, but are probably not supposed to exist, only actual capturing hardware(?)).
- PS/2 decoder page. Does not exist??
- "The decode of some PS/2 (or USB) keyboard/mouse traffic could yield an ASCII text file of all the keys that were pressed on the keyboard." (on a planning page)
- Look in bug tracker for PS/2, keyboards, etc.
- Look in Git log
- Look in IRC log
- Look in blog posts for info on PS/2, etc.
- Updating the wiki
- Add PS/2 low-level reference (details about the CLK signal) to the PS/2 protocol decoder page. IRC ref. [2020-01-07 01:49:07] and [2020-01-07 18:09:02] (UTC+1)). Add to the resources section. Is: http://www.nerdkits.com/videos/interrupts_and_ps2_keyboard/
- Add keyboard documentation, pictures (not decided on yet).
- Deliberately send data to the keyboard with a parity error.
- Deliberately add noise to the signals (say, wide-band white noise by electronics means), forcing parity errors. This should force the receiver (keyboard or host PC) to respond.
- Send unknown commands to the keyboard. It should respond with 0xFE (in contrast to the normal 0xFA).
- Try all the keyboard commands in Keyboard commands.
- For a keyboard that is both capable of USB and PS/2: Record the startup sequence when connected via PS/2 to a PC host. To see if there is any indication on the signal level of such capability.
- Updating broken links here. For example, for the CAN protocol decoder.
- Building a Docker container for compiling sigrok-cli and PulseView. It is supposed to both run under Linux and Windows (x64).
- Testing a new driver by user droghio that should work for the TDS2024C Tektronix oscilloscope. Some placeholding:
Submitting comprehensive sample data for CAN bus, both 11-bit and 29-bit messages, and corresponding test cases (mostly for regression test - especially regression for the 2018-04-12 fix to the decoding at the end of the CRC part).
Notes to self:
- Original acquired analog data: C:\temp2\2017-12-23\CAN decoder, new stuff bit handling at the end of the CRC segment\Data67\In\ACQ000009_Tektronix.txt
Recording 22483 traces for the purpose of evaluating a proposed fix to the CAN protocol decoder (actually only changing a single number from 16 to 17), stuff bit at the very end of the CRC segment, with a modified trigger scheme:
- Change the position of the trigger point to the end (right) so there is always a CAN message in the trace (for the previous), but still 26 µs recessive.
The time division was 100 µs / division (about 225 bit times max) to always record whole CAN messages - at 10 samples per bit time.
Using the sigrok command-line ("sigrok-cli") to bulk process data derived from Tektronix oscilloscope data of 250 kbit/s CAN traffic on a real-world system (mobile cranes). The first sample data set is 5335 oscilloscope traces obtained with the trigger set to a negative pulse on CAN-H (to start off at the end of a CAN message) - corresponding to 6.5 recessive bits, 26 µsec (detecting the space in-between CAN messages). Sometimes there is a CAN message right after this, sometimes it is a bit delayed, and sometimes it is completely empty.
A sample command line (on Windows) is:
sigrok-cli -P can:bitrate=250000:can_rx="CAN RX" -P timing:data="CAN RX" -I csv:header=true:samplerate=5000000 -i "T:\stdHMF\UserData\scripts\Tektronix2PulseView\_PulseView_AllChannels_ACQ000001_Tektronix_f5000000.txt"
Currently not in priority order.
- Allow import of analog data through CSV files. (Related: fixed bug 1064 - locale issue, decimal point, "," vs. ".".).
- Add detection of error frames to the CAN protocol decoder
- Add support for the gigga watt EEVBlog multimeter (Bluetooth, etc.)
- Add a snap feature to the "cursor" (blue) in PulveView
- Change number of significant digits for the time display in the "cursor" (blue) in PulveView
- Submit selected sample traces for CAN decoder change (for CRC segment) validation. With and without stuff bits in various places. With and without timing deviations. (Related: bug 1085, celeron55's fix, if len(self.bits) > self.last_databit + 16 → if len(self.bits) > self.last_databit + 17 (16 → 17)).
- Add support for the TDS2000 series in libsigrok, and thus, by extension, use by the new shiny stuff in PulveView.
- Change recommended procedure for submitting sample Sigrok files (traces), on Example dumps.
- BBB BeagleBone Black
- GH GitHub
- ISTR ????
- LA Logic analyser
- ML Mailing list
- OLS ????
- PR Pull request (a Git term). Not "problem report".
- SR Sigrok
- srd ????
- WIP Work in progress. Mostly related to particular Git commits.
- PD protocol decoder. Non-standard spellings are Pd and pd.
- PV PulseView. Non-standard spellings are Pv and pv.
Some bug reports
- Possible problem with the MSO-19 USB driver on Windows. PulveView crashes at startup if the MSO-19 is connected.
I am mostly interested in:
- The CAN protocol decoder (that page is currently empty, but it is listed on the protocol decoders page)
- CAN bus loggers, like IXXAT's (now acquired by HMS) USB-to-CAN compact/USB-to-CAN V2 and Kvaser's Memorator.
- The higher-level CANopen protocol (on top of CAN)
Non-empty wiki pages
Currently (2017-07-08), 28 of 77 protocol decoders (36%) have non-empty pages here on the wiki:
- ARM ETMV3
- ARM ITM
- ARM TPIU
- AVR PDI
- IR NEC
- RGB LED SPI
- SPI flash
- Stepper motor
Profile: see my Wikipedia user page.
Credentials: more than 5000 edits on the English Wikipedia.
- PulseView manual
- sigrok-cli man page
- Google+ group for sigrok (now defunc as Google+ closed down)
- PulseView. Includes the command line to get the source code using Git.
- PulseView, Windows binaries (nightly - development). Alternative location (but it seems redundant).
- PulseView, Linux binaries (nightly - development).
- Example data dumps - sample data in .sr format. Also includes instructions on how to contribute new ones. Includes the command line to get the whole thing using Git (as of 2017-11-26, 2286 "objects", 724 .sr files, about 65 MB in download size, 192 MB on disk).
- Random page
- Native app image (not official yet). Is for Linux and x86 only. See also AppImage (Wikipedia).
- Press. List of annotated links, mostly blog posts.
- Probe comparison
- MSO-19. Mixed oscilloscope and logic analyser by Link Instruments that (or rather its driver) crashes PulveView at startup when connected (until some time in mid 2018(?)). Some reverse engineering has been done in 2012, but it is not supported (has status "Planned"). Sigrok bug report for the crash. Software download page for it.
- sigrok, Microsoft Windows page
- The CAN bus protocol decoder
- Protocol decoder HOWTO
- Protocol decoder API
- Supported protocol decoders
- On Debian (e.g. Raspberry Pi): Installing required software
- On Debian (e.g. Raspberry Pi): Actual build
- Alternative to following the wiki pages: a script that will do most of it. ([sigrok-util.git] / cross-compile / linux / sigrok-cross-linux)
- On Windows: Native build using MSYS2 (but may not really work - sigrok-cli and PulseView are listed as not working).
- Cross compile on Linux (using MXE). The script is /sigrok-util/cross-compile/mingw/sigrok-cross-mingw. Used for nightlies? Jenkins page for the debug version.
- The Jenkins thingy - automatic build, e.g. nightlies for PulseView and "AppImage" (self-contained executable for x86 Linux). Sample: sigrok-cli with 44 configurations (43 cross-compiles), e.g. cross-x86_64-w64-mingw32 (for Windows 64-bit?).
- The LD_LIBRARY_PATH trick