@bperrybap.
I've now also tested the sniffer against your HD44780 library also in auto configure mode. It appears to work OK, but the sniffer does not currently support a reversion from 4 bit mode to 8 bit mode, so could get out of phase if it sees multiple start up sequences. The cleanest use case is that the sniffer is running, then the LCD goes through a complete initialisation from power reset onwards. Incidentally, the Saleae 44780 protocol analyser, at least with its standard configuration, could not recognise the output of this library.
I've attached a new version LCD1602_sniffer_V0_06 to this post. I've restructured it to transfer the main activity from the ISR to the loop() so, for one thing, it easier to add custom debugging statements. When it gets so far, I will put a definitive version in the OP. That could be after it is tested running in 8 bit mode and some other tidying up.
I just want to emphasize here, if it is not already clear, that the target audience for this tool is the relatively experienced user. New users will have difficulties with the complex analysis and integration activities this tool is intended to support. Further, it is fully expected that the user will have to make coding changes to it to match the target environment and the format of the data to be extracted etc., so it is really to be regarded as sort of framework and not a ready made solution.
I'm not so worried about the sniffer having problems with floating pins ( I hope I have understood you correctly here) . If the target application uses 4 bit mode (pins D7 to D4 only) and, during the initialisation sequence, puts the 44780 cleanly into 4 bit mode, then the sniffer would not look at the unused pins. However, if the raw data is presented to the user, I agree that the unused pins should be masked to avoid confusion.
@karlisakis
You have an interesting project there. Especially with a game, you may well have a problem relating the data sent to the display with the current image on the display, as @bperrybap has said. Just as an example, those custom characters could easily be created dynamically, and constantly loaded. All you will see is their position in the internal ram of the device and there are only 5 postions (at least in the standard case assuming no custom font table). If multiple special characters, during the progress of the game, share, at different times, the same position, you can't do a simple look up to see which character is being referred to.
Under Windows "Photos" I can magnify the traces, but I am wondering what I am seeing. I guess the display leaves D0 to D3 unconnected, since you are showing only 7 traces. Further, it looks like the 'E' (enable) pin is on DIO 2. DIO 0 looks rather wild. Anyway, you should say what your pin mapping is.
LCD1602_sniffer_V0_06.zip (4.9 KB)
LCD1602_write_V0_03.ino (860 Bytes)
Note: Post #41 contains the latest version of the sniffer.