I need to write a udev rule for a particular keyboard which does not seem to have any unique attribute against which to match.
The lines below are the output of udevadm monitor upon insertion of the device. Is there something here I could use to uniquely identify this keyboard?
KERNEL[58443.215701] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 (usb)
KERNEL[58443.218536] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
KERNEL[58443.218662] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:04B3:3025.0005 (hid)
KERNEL[58443.221610] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input15 (input)
KERNEL[58443.221669] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input15/event4 (input)
KERNEL[58443.221868] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:04B3:3025.0005/hidraw/hidraw0
UDEV [58443.236718] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2 (usb)
UDEV [58443.238026] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0 (usb)
UDEV [58443.239532] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:04B3:3025.0005 (hid)
UDEV [58443.240670] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:04B3:3025.0005/hidraw/hidraw0
UDEV [58443.288767] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input15 (input)
UDEV [58443.319799] add /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input15/event4 (input)
Edit:
Below are the lines from plugging the keyboard into a different usb port. As far as I can tell, it seems that there is no information that remains constant.
KERNEL[59428.187673] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1 (usb)
KERNEL[59428.190323] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0 (usb)
KERNEL[59428.190494] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/0003:04B3:3025.0006 (hid)
KERNEL[59428.193088] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/input/input16 (input)
KERNEL[59428.193266] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/input/input16/event4 (input)
KERNEL[59428.193426] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/0003:04B3:3025.0006/hidraw/hidraw0
UDEV [59428.300690] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1 (usb)
UDEV [59428.301790] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0 (usb)
UDEV [59428.302553] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/0003:04B3:3025.0006 (hid)
UDEV [59428.303130] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/0003:04B3:3025.0006/hidraw/hidraw0
UDEV [59428.319082] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/input/input16 (input)
UDEV [59428.321444] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/input/input16/event4 (input)
Edit: Using lsusb -v, I was able to find the idVendor and idProduct.
Bus 002 Device 009: ID 04b3:3025 IBM Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x04b3 IBM Corp.
idProduct 0x3025
bcdDevice 1.09
iManufacturer 1 LITE-ON Technology
iProduct 2 USB NetVista Full Width Keyboard.
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 HID Keyboard
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 70mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 5 EP1 Interrupt
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 65
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 24
Device Status: 0x0000
(Bus Powered)
So I have created the following udev rule:
SUBSYSTEM=="usb", ATTR{idVendor}=="0x04b3", ATTRS{idProduct}=="0x3025", RUN+="/home/myuser/bin/udev_jap.sh"
However, nothing is triggered so far. And strangely, the idVendor and idProduct information doesn't show up on udevadm monitor. Does this mean udev can't match against these attributes?
This is an old question, anyway:
You have to remove 0x hexadecimal prefix.
Note that ATTR and ATTRS are different, but for your case both should work.
Your script udev_jap.sh should start with shebang #!/bin/sh or run shell itself:
RUN+="/bin/sh /home/myuser/bin/udev_jap.sh"
Try this:
SUBSYSTEM=="usb", ATTR{idVendor}=="04b3", ATTR{idProduct}=="3025", RUN+="/home/myuser/bin/udev_jap.sh"
Related
how do you simulate the RTI (Real Time Interrupt) in the 68HC11 THRSim11 simulator (see http://www.hc11.demon.nl/thrsim11/thrsim11.htm)? the following program works at the 68HC11 module but not in THRSim11. It's a test program to read from Analog to Digital Converter and display results to serial port using RTI. I tried the RTI interrupt vector 00EB and FFF0. My chip is the 68H711E9 with the following memory map.
I expected the THRSim11 to simulate the interrupt vector. When running the "again BRA again" just before CLI (enable Interrupt). It must be running the subroutine that reads from ADC and display to serial. It works perfectly in my 68HC711E9 Evaluation board with buffalo
REGBS EQU $1000 ;start of registers
BAUD EQU REGBS+$2B ;sci baud reg
SCCR1 EQU REGBS+$2C ;sci control1 reg
SCCR2 EQU REGBS+$2D ;sci control2 reg
SCSR EQU REGBS+$2E ;sci status reg
SCDR EQU REGBS+$2F ;sci data reg
TMSK2 EQU REGBS+$24 ;Timer Interrupt Mask Register 2
TFLG2 EQU REGBS+$25 ;Timer Interrupt Flag Register 2
ADR3 EQU $1033 ;ADC address 3
OPTION EQU $1039 ;ADC enable
SCS EQU $2E ;SCSR low bit
ADCTL EQU $1030 ;ADC setting
ADCT EQU $30 ;ADC setting low bit
PACTL EQU $1026 ;Pulse Accumulator control
***************************************************************
* Main program starts here *
***************************************************************
ORG $0110
* ORG $E000
start LDS #$01FF ;set stack pointer
JSR ONSCI ;initialize serial port
JSR t_init ;initialize timer
CLI ;enable interrupts
again BRA again
************************************************************
* t_init - Initialize the RTI timer
************************************************************
t_init LDAA #$01 ; set PTR1 and PTR0 to 0 and 1
STAA PACTL ;which leads to an RTI rate of 8.19 ms
LDAA #$40
STAA TFLG2 ;clears RTIF flag (write 1 in it!)
STAA TMSK2 ;sets RTII to allow interruptssec
RTS
************************************************************
* ADC_SERIAL - timer overflow interrupt service routine
************************************************************
ADC_SERIAL
LDX #REGBS
LDAA #%00010010
STAA ADCTL
LDAB #6
ADF00 DECB
BNE ADF00
ldaa ADR3 ; read ADC value
ldab SCSR ; read first Status
staa SCDR ; save in TX Register
BUFFS BRCLR SCS,X #$80 BUFFS
CLRFLG LDAA #$40
STAA TFLG2 ;clear RTIF
RTI ;return from ISR
************************************************************
* ONSCI() - Initialize the SCI for 9600
* baud at 8 MHz
************************************************************
ONSCI LDAA #$30
STAA BAUD baud register
LDAA #$00
STAA SCCR1
LDAA #$0C
STAA SCCR2 enable
LDAA #%10011010 ; enable the ADC
STAA OPTION
RTS
* Interrupt Vectors for BUFALO monitor
* ORG $FFF0 ;RTI vector for microcontroller
*
ORG $00EB ;Real Time Interrupt under Buffalo monitor
JMP ADC_SERIAL ;this instruction is executed every
* time there is a timer overflow
Presumably you mixed up "vector table" and "jump table". The HC11 expects an address at $FFF0, not an instruction.
In contrast, the Buffalo monitor expects an instruction at $00EB.
ORG $FFF0 ;RTI vector for microcontroller
FDB ADC_SERIAL
ORG $FFFE ;Reset vector for microcontroller
FDB start
As you will note, the same holds true for the reset vector at $FFFE.
With these changes it works for me. Be aware that the simulation is really slow*, depending on the number and kind of views opened.
Another side note: You send the single byte of conversion result without further processing. The serial receiver view of the simulator will try to interpret this byte as an ASCII character, and only if it fails, show a decimal number in angles. You might want to consider to convert the conversion result into a human readable value. The most simple solution may be a hex representation.
EDIT:
*) A simulator needs to be factors faster than the original machine, depending on the specific implementation of the simulation. In this case, they seem to have used a quite slow way. The documentation has some words on this. To gain some speed, close any view you don't need, and use the fastest PC you can get. To gain some understanding, think about how slow a simulation would be if it will simulate the analog electronics with each semiconductor of the chip. And even that is just a model, the "real" world currently starts at quantum mechanics.
Without further measure, you cannot use Buffalo's jump table entries, because the Buffalo monitor is not included in the simulator.
If you want to use an unmodified version of your firmware, you will need to add at least the used parts of the Buffalo monitor. If you have the monitor as a file loadable by the simulator, you might want to load it before loading your application.
The least you could do is to provide the jump table yourself, placing the appropriate address of the jump in the vector:
ORG $FFF0 ;RTI vector for microcontroller
FDB $00EB
The "problem" with the ASCII interpretation becomes visible, if values of printable characters are sent. Put the slider in the first third, and you will see some letter or digit or punctuation. Slide it minimally up and down for other characters. Yes, terminals can be dumb, and this one is no exception. Actually it is a little bit smart and shows the printable characters instead of their ASCII value. Additionally it knows at least CR (carriage return, $0D, decimal 13) and LF (line feed, $0A, decimal 10). You might want to write a little test program that sends "Hello, world", CR, LF. Or another experiment that sends all values from $00 to $FF.
The meaning of a value always depends on its interpretation. This terminal interprets values as ASCII characters, if possible.
In Operating Systems Design and Implementation by Andrew S. Tanenbaum and Albert S. Woodhull, there's the following fragment:
In MINIX 3 every file has an 11-bit mode used for protection. Nine of these bits are the read-
write-execute bits for the owner, group, and others.
And then, a few lines after, they write:
The other two protection bits, 02000 [octal 200] and 04000 [octal 400], are the SETGID (set-group-id) and SETUID (set-
user-id) bits, respectively.
But Python shows that octal 400 is a 12-bit long mask:
>>> len(str(bin(0o4000))) - len('0b')
12
How can a 12-bit long mask be applied on a 11-bit field?
01000 is the "sticky" bit in Unix, and Minix didn't support it at the time the book was released. It didn't add support until 2010 (the book was released in 2005).
I am deploying a Qt application to a beaglebone black that is running Stretch. I am attempting to use linuxfb with libinput to handle touch events. The touch screen input was inverted, so I set the Coordinate Transformation Matrix with a .conf file. The touch works correctly on the desktop, but is still inverted in my Qt app.
Here are my environment settings for Qt:
QT_LOGGING_RULES=*=true
QT_QPA_EGLFS_HEIGHT=600
QT_QPA_EGLFS_PHYSICAL_HEIGHT=92
QT_QPA_EGLFS_PHYSICAL_WIDTH=155
QT_QPA_EGLFS_WIDTH=1024
QT_QPA_FB_DRM=1
QT_QPA_PLATFORM=linuxfb
With the above settings, the app renders correctly and is responsive, but the touch input is inverted.
Here is the Qt console output when running with these parameters:
11:24:44: Checking available ports...
11:24:44: Found 101 free ports.
11:24:44: Starting /usr/bin/gdbserver...
11:24:44: Debugging starts
Listening on port 10000
Remote debugging from host 192.168.13.104
Process /home/debian/test created; pid = 1473
qt.qpa.eglfs.kms: Using backend-provided DRM device /dev/dri/card0
qt.qpa.fb: DRM device /dev/dri/card0 opened
qt.qpa.eglfs.kms: Found 1 planes
qt.qpa.eglfs.kms: plane 0: id = 18 countFormats = 2 possibleCrtcs = 0x1 supported formats = XR24 AR24
qt.qpa.eglfs.kms: property 0: id = 5 name = 'type'
qt.qpa.eglfs.kms: type is ENUM, value is 1, possible values are:
qt.qpa.eglfs.kms: enum 0: Overlay - 0
qt.qpa.eglfs.kms: enum 1: Primary - 1
qt.qpa.eglfs.kms: enum 2: Cursor - 2
qt.qpa.eglfs.kms: "LVDS1" mode count: 1 crtc index: 0 crtc id: 19
qt.qpa.eglfs.kms: mode 0 1024 x 600 # 45 hz
qt.qpa.eglfs.kms: Selected mode 0 : 1024 x 600 # 45 hz for output "LVDS1"
qt.qpa.eglfs.kms: Physical size is QSizeF(155, 92) mm for output "LVDS1"
qt.qpa.eglfs.kms: Output LVDS1 can use 1 planes: 18
qt.qpa.fb: Got a new output: LVDS1
qt.qpa.eglfs.kms: Sorted screen list: QVector()
qt.qpa.fb: Got a dumb buffer for size 1024x600 and bpp 32: handle 1, pitch 4096, size 2457600
qt.qpa.fb: FB is 25 (DRM format 0x34325258), mapped at 0xb364d000
qt.qpa.fb: Got a dumb buffer for size 1024x600 and bpp 32: handle 2, pitch 4096, size 2457600
qt.qpa.fb: FB is 26 (DRM format 0x34325258), mapped at 0xb33f5000
qt.qpa.fb: QRect(0,0 1024x600) QSizeF(155, 92) 24 4
qt.qpa.input: libinput: input device 'gpio_keys', /dev/input/event2 is tagged by udev as: Keyboard
qt.qpa.input: libinput: input device 'gpio_keys', /dev/input/event2 is a keyboard
qt.qpa.input: libinput: input device 'tps65217_pwr_but', /dev/input/event0 is tagged by udev as: Keyboard
qt.qpa.input: libinput: input device 'tps65217_pwr_but', /dev/input/event0 is a keyboard
qt.qpa.input: libinput: input device 'DELL Dell USB Entry Keyboard', /dev/input/event3 is tagged by udev as: Keyboard
qt.qpa.input: libinput: input device 'DELL Dell USB Entry Keyboard', /dev/input/event3 is a keyboard
qt.qpa.input: libinput: input device 'SIGMACHIP Usb Mouse', /dev/input/event4 is tagged by udev as: Mouse
qt.qpa.input: libinput: input device 'SIGMACHIP Usb Mouse', /dev/input/event4 is a pointer caps
qt.qpa.input: libinput: input device 'EP0790M09', /dev/input/event1 is tagged by udev as: Touchscreen
qt.qpa.input: libinput: input device 'EP0790M09', /dev/input/event1 is a touch device
qt.qpa.input: Using xkbcommon for key mapping
I have also tried it with these environment settings:
DISPLAY=:0
QT_LOGGING_RULES=*=true
QT_QPA_EGLFS_HEIGHT=600
QT_QPA_EGLFS_INTEGRATION=eglfs_x11
QT_QPA_EGLFS_PHYSICAL_HEIGHT=92
QT_QPA_EGLFS_PHYSICAL_WIDTH=155
QT_QPA_EGLFS_WIDTH=1024
XAUTHORITY=/home/debian/.Xauthority
Using this configuration, I can only run the app if the beaglebone has a bare xsession running. The app renders correctly, but is laggy, and the touch is still inverted.
Here is the Qt console output for this configuration:
11:26:52: Checking available ports...
11:26:52: Found 101 free ports.
11:26:52: Starting /usr/bin/gdbserver...
11:26:52: Debugging starts
Listening on port 10001
Remote debugging from host 192.168.13.104
Process /home/debian/test created; pid = 1893
qt.qpa.egldeviceintegration: EGL device integration plugin keys: ("eglfs_emu", "eglfs_kms_egldevice", "eglfs_kms", "eglfs_x11")
qt.qpa.egldeviceintegration: EGL device integration plugin keys (sorted): ("eglfs_x11", "eglfs_emu", "eglfs_kms_egldevice", "eglfs_kms")
qt.qpa.egldeviceintegration: Trying to load device EGL integration "eglfs_x11"
qt.qpa.egldeviceintegration: Using EGL device integration "eglfs_x11"
libEGL warning: DRI2: failed to authenticate
qt.qpa.input: libinput: input device 'gpio_keys', /dev/input/event2 is tagged by udev as: Keyboard
qt.qpa.input: libinput: input device 'gpio_keys', /dev/input/event2 is a keyboard
qt.qpa.input: libinput: input device 'tps65217_pwr_but', /dev/input/event0 is tagged by udev as: Keyboard
qt.qpa.input: libinput: input device 'tps65217_pwr_but', /dev/input/event0 is a keyboard
qt.qpa.input: libinput: input device 'DELL Dell USB Entry Keyboard', /dev/input/event3 is tagged by udev as: Keyboard
qt.qpa.input: libinput: input device 'DELL Dell USB Entry Keyboard', /dev/input/event3 is a keyboard
qt.qpa.input: libinput: input device 'SIGMACHIP Usb Mouse', /dev/input/event4 is tagged by udev as: Mouse
qt.qpa.input: libinput: input device 'SIGMACHIP Usb Mouse', /dev/input/event4 is a pointer caps
qt.qpa.input: libinput: input device 'EP0790M09', /dev/input/event1 is tagged by udev as: Touchscreen
qt.qpa.input: libinput: input device 'EP0790M09', /dev/input/event1 is a touch device
qt.qpa.input: Using xkbcommon for key mapping
Running on a software rasterizer (LLVMpipe), expect limited performance.
qt.opengl.diskcache: GL_ARB_get_program_binary support = 1
qt.opengl.diskcache: Supported binary format count = 0
qt.opengl.diskcache: Shader cache supported = 0
Here is my .conf that is applied to the touchscreen:
Section "InputClass"
Identifier "calibration"
MatchProduct "EP0790M09"
MatchDevicePath "/dev/input/event*"
Driver "libinput"
Option "TransformationMatrix" "-1.0 0.0 1.0 0.0 -1.0 1.0 0.0 0.0 1.0"
EndSection
Here is what xinput lists for the device properties:
Device 'EP0790M09':
Device Enabled (115): 1
Coordinate Transformation Matrix (116): -1.000000, 0.000000, 1.000000, 0.000000, -1.000000, 1.000000, 0.000000, 0.000000, 1.000000
libinput Calibration Matrix (270): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
libinput Calibration Matrix Default (271): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
libinput Send Events Modes Available (272): 1, 0
libinput Send Events Mode Enabled (273): 0, 0
libinput Send Events Mode Enabled Default (274): 0, 0
Device Node (236): "/dev/input/event1"
Device Product ID (235): 0, 0
Version info:
$lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.5 (stretch)
Release: 9.5
Codename: stretch
$ uname -a
Linux beaglebone 4.4.9 #2 SMP Thu Mar 22 13:59:11 CDT 2018 armv7l GNU/Linux
How can I invert the touch input inside my qt app?
The solution ended up being to use evdev touch in my app and use QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS to fix the input events.
My final run environment ended up being:
QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS=/dev/input/event1:rotate=180
QT_QPA_FB_NO_LIBINPUT=1
QT_QPA_PLATFORM=linuxfb
I have two digium cards ,models are TE420 4 port card,TE121 single port card.
After the configuration 4 port card
if i execute "dahdi show status" in asterisk prompt , I got following output
Description Alarms IRQ bpviol CRC4
T4XXP (PCI) Card 0 Span 1 OK 46 0 0
T4XXP (PCI) Card 0 Span 2 OK 46 0 0
T4XXP (PCI) Card 0 Span 3 OK 46 0 0
T4XXP (PCI) Card 0 Span 4 OK 46 0 0
Wildcard TE121 card 0 OK 32457 0 0
Why I am not getting the Span 5 for the single port card.
check by typing pri show spans in asterisk cli
and also in linux shell type dahdi_cfg -vvvv it will output all the channesl configured
The description you see there is the span description filled in by the DAHDI drivers for each span. When they fill in the description they do not yet know what global span number they were assigned. The 1-4 is just showing the spans that are exported by card 0. Since TE121 only export a single span, they only indicate their card number.
If you're using these cards with PRI, I agree that with striker that 'pri show spans' is a more useful command to see the status of the spans.
Running dahdi_maint from the console is also a good way to see the current status of any DAHDI spans you have configured in your system.
Can somebody suggest me any disassembler for Atmel AVR 8-bit microcontrollers? There are opensource projects for this?
Thanx.
You can also use avr-objdump, a tool part of the avr-gcc toolset ( http://www.nongnu.org/avr-libc/ ). Ex:
avr-objdump -s -m <avr architecture> .d program.hex > program.dump
where <avr architecture> is found on http://www.nongnu.org/avr-libc/user-manual/using_tools.html
[plug]IDA Pro supports AVR disassembly[/plug]:
As for opensource, AVR GCC package includes a port of objdump, including disassembling functionality.
http://www.onlinedisassembler.com/odaweb/
Lots of platforms (AVR also) but Microchip (which you didn't need either) is missing.
Big plus is that it is web based.
Checkout vAVRdisasm.
AVRDisassembler is an open source (MIT) AVR / Arduino disassembler written in .NET Core (which means it can run on Windows, Mac, Linux). Apart from writing the disassembly to stdout, it can also emit a JSON dump (for interopability, analysis purposes).
Disclaimer: I am the author of said library.
I'm using avrdisas by Johannes Bauer. It works with dumped flash, rather than the .hex file or ELF.
Compiling the following :
.include "tn13def.inc"
ldi r16,1
out ddrb,r16 ; PB0 as output
sbiw r24,1 ; slight wait
brne PC-1
sbi pinb,pinb0 ; toggle
rjmp PC-3 ; forever
produces listing:
C:000000 e001 ldi r16,1
C:000001 bb07 out ddrb,r16 ; PB0 as output
C:000002 9701 sbiw r24,1 ; slight wait
C:000003 f7f1 brne PC-1
C:000004 9ab0 sbi pinb,pinb0 ; toggle
C:000005 cffc rjmp PC-3 ; forever
extracting the flash contents with:
$ avrdude -p t13 -P usb -c usbtiny -U flash:r:flash.bin:r
gives: e001 bb07 9701 f7f1 9ab0 cffc
disassembly:
$ ./avrdisas -a1 -o1 -s1 flash.bin
; Disassembly of flash.bin (avr-gcc style)
.text
main:
0: 01 e0 ldi r16, 0x01 ; 1
2: 07 bb out 0x17, r16 ; 23
; Referenced from offset 0x06 by brne
; Referenced from offset 0x0a by rjmp
Label1:
4: 01 97 sbiw r24, 0x01 ; 1
6: f1 f7 brne Label1
8: b0 9a sbi 0x16, 0 ; 0x01 = 1
a: fc cf rjmp Label1
and this works for me, even if the endian-ness does not match the listing and I would need to resolve 0x17 back to DDRB etc.
As opensource disassembler I've tried Radare2 which is command-line oriented but you can also use the GUI called Cutter. https://rada.re/n/
Or you can just use the classical avr-objdump:
avr-objdump.exe -j .sec1 -d -m avr5 dumpfile.hex
Information source here
The question is rather about disassembling the HEX file and as a solution there are mentioned quite a lot tools above in other answers. Hard to add something more.
But if someone is looking for: it is also possible to disassemble the C/C++ while running in IDE. With Atmel studio with its integrated disassembling tool it can be done following way:
Run project (it can be run in simulator without debugger hardware);
Pause or stop at breakpoint;
Press CTRL + ALT + D
This can be useful in order to verify that particular code fragments are compiled as needed because the optimization sometimes skips/mangles the sequence and leads to some unexpected behavior.