A comparison of the TM1637 protocol with I2C protocol

The TM1637 is a Chinese made IC designed to drive up to 6 7-segment LEDs. It offers serial data input so that only 4 wires are need to connect to the display: POWER, GND, CLOCK and DATA. In fact it can also scan a keyboard matrix and return the key status to the controller. It can be found on integrated 4 digit displays available on eBay from Chinese sellers for a dollar or two. It follows on from the trend by MAXIM display chips serving similar functions. It's an attractive component if your microcontroller project needs a display and you don't want to use up lots of lines, drivers and resistors driving LED digits yourself, not to mention the coding of the multiplexing. A display board incorporating this controller costs only a little more than the displays on it.

The serial protocol has already been explained in this blog post. It's fairly easy to implement in the language of your choice, provided you can do low level bit-banging. This post is to explain the differences between and I2C protocol and the custom protocol designed by Titan Micro Electroncs, the manufacturer. TM explicitly says their protocol (call it TMP) is not compatible with I2C, but it's easy to see it has similarities. You can see that TM pared the protocol down to only what they needed.

These are the major differences:

• I2C has addresses so a master can drive multiple slaves. TMP doesn't have this. So I2C is a bus and TMP is point-to-point. This means each display needs two lines. No daisy-chaining either. This also means TM didn't have to pay to get a slave address assigned to their chip. BTW I2C assigns the lowest bit in the address byte to indicate the direction of the data flow. Alternatively you may regard the slave as having two consecutive addresses.
• I2C specifies that after the address comes the register address within the slave. TMP is flatter, you send a command followed by any data expected.
• I2C sends the most significant bit first, TMP sends the least significant bit first. This only shows up in the low-level bit-banging.
• I2C has the concept of clock-stretching. TMP has no way for the slave to tell the master to wait. It isn't needed as the chip will respond within the specified time. There is also no need to worry about a pull-up resistor as a result.
• I2C specifies various clock speed tiers. TMP only implements their speed, a max of about 250kHz, which is fast enough.
• As it's a custom protocol you won't be able to use any silicon or firmware assists for I2C that may be present.

Here's a project of mine that uses a display board with this controller.

Login to standalone Samba server from Windows 7 (and above)

At a workplace we have a server in the DMZ running Samba and other things and therefore not joined to the Windows domain. It has a small set of local users (no, no, we would never share a CIFS over the Internet) whose passwords are managed with smbpasswd. When a user tries to connect to a Samba share, the Windows desktop "helpfully" prefills the login name as domain\username. The login fails because the Samba server is not in the domain. This did not happen in XP.

Extremely simple solution, opt to login as a different user and use:

\username

to login. For some reason this is not widely known. NET USE will also work but then the user has to use a COMMAND window.

It works for me and it also worked for this person.

Avoid calling basename or dirname by using parameter expansion

These short cuts have been documented under parameter expansion for a long time but are not well known because people are used to writing basename and dirname.

Instead of using:

file=$(basename "$path")

use

file=${path##*/}

Instead of using:

dir=$(dirname "$path")

use

dir=${path%/*}

The advantage is not calling basename as an extra process. Although basename might be implemented as a builtin in some shells.

See the linked page for further short cuts.

Chrome/Chromium is storing the url and referrer of downloaded files in extended attributes

When I turned on extended attributes for a rsync command (-X option) I noticed that it proposed to copy attributes for a bunch of files it had not before. Most of those files appeared to be PDFs or zip files. So I wondered what those attributes were. Here is an example:

$ getfattr -d work/uC/asm7000.zip
# file: work/uC/asm7000.zip
user.xdg.origin.url="http://cd.textfiles.com/emspro1/ASMUTIL/ASM7000.ZIP"
user.xdg.referrer.url="http://cd.textfiles.com/emspro1/ASMUTIL/"

Oh! That's not good! The origin of this file is harmless, but what if it had been a file downloaded from a sensitive location or the URL contained sensitive parameters. I may want to give the file to somebody without revealing the URL I got it from, which may contain side channel information. You can imagine your own scenario.

I should add this is only an issue for you if you have enabled extended attributes on your filesystem and mounted with that option. Look for the option user_xattr in /etc/fstab lines. But maybe Android does enable extended attributes. That would be a big worry; your phone may be retaining information you didn't know about.

Doing a search found this recent Debian bug report with no resolution. Also these attributes are listed as in current use by freedesktop.org. And it looks like wget too stores the url. Update 2019-03-18: I have been informed that wget from 1.20.1 has options to control storage of the attributes.

This really should be behaviour that can be turned off in Chrome/Chromium. Until then, I'm not backing up extended attributes for my own files. You should also screen extended attributes in files you transfer to other systems.

It does have one use though. If you forgot where you got a file from, you can recover the URL.

Addendum: Here are some situations on Linux showing whether the extended attributes will be transferred and potentially revealed to others.

• Email as attachment: Extended attributes are not included. But see archive files further on.
• Zip archive: Extended attributes are not captured.
• Tar archive: Extended attributes could be copied, depending on command line options and the compiled default. It seems to be not on by default on my system (openSUSE).
• Transfer on DOS or Windows filesystem, e.g. flash storage: As far as I can tell these extended attributes are not stored on FAT or NTFS.
• Transfer on CD/DVD: ISO9660 can store extended attributes but mkisofs doesn't seem to store these despite mention of GETXATTR and SETXATTR error message suppression. I haven't found information on UDF regarding extended attributes yet.
• Transfer on external storage with Linux filesystem: This depends on whether the filesystem has user_xattr enabled and it is mounted with this enabled, and the copy command transfers it. cp -p doesn't but cp -a does. rsync without -X doesn't.
• Uploaded to the cloud: This would depend on the client doing the upload. Also see here.

More testing is required. Send additions and corrections by commenting on this blog post.

The true origin of "the NUXI Problem"

A bit of computer history today.

The Cathedral and Bazaar website defines the NUXI Problem and various other web pages have elaborated on how it is due to endianess of the CPU interacting with data transfer.

All well and good, but the name given to the problem dates from before data transfer. In those days, telecommunications was slow and data transfer was by magnetic tape. So it wasn't due to encountering problems with FTP or something like that, Internet Protocol had not come to Unix yet.

Rather it was named after the glitch observed on the console upon booting up a port of Unix V6 to, my unreliable memory tells me, the Interdata 7/32. The ports were done independently at two places, Bell Labs and University of Woolongong. Here is the story from the veteran of the UW port.

The PDP/11 is little-endian and the recipient of the port was big-endian so when Unix V6 booted up, the message on the console was supposed to be:

UNIX V6...

which came out as:

NUXI...

Obviously a fix had to be applied to the order of bytes within words in compiler generated code for C strings.

I don't know which team encountered this symptom first. The tale was told to me by Piers Lauder, the Unix guru at the time at Basser Dept. of CS at the U of Sydney.

Ancient EPROMS: 2516, 2716, 2532, 2732

I needed to burn a 16kb (2kB) EPROM as part of a restoration project on an old piece of equipment. When I couldn't burn the EPROMs on my TL-866 programmer, I started investigating. Here's what I found out, summarised for your benefit.

Programming voltage

Practically all EPROMs of this era require 25V programming voltage. That's why my TL-866 couldn't do it, it failed on the first byte, it can only go up to 21V. I can understand why it's not supported, only a tiny fraction of chips require 25V programming. Maybe your programmer supports 25V. However some parts suffixed with A are 21V programmable so try that voltage first. I didn't have any A parts.

Pinouts

This article goes into detail about the differences. To summarise:

For the 2716, the Texas Instruments equivalent is 2516. The TI 2716 is a different beast, fortunately quite rare.

For the 2732, this time TI came out with the 2532, with a different pinout from the more widespread 2732. So TI 2532 != other 2732. Again my programmer cannot program 2532s, not just insufficient voltage but different algorithm too. If you need to only read them, say you want to put 2732 EPROMs in a machine using 2532 EPROMs, it's possible to make an adaptor that reroutes three pins. The article is only for subscribers, but if you click on the PDF image of the PCB, it will be obvious what they have done to the three pins 18, 20 and 21.

From the 2764 onwards, TI fell in line.

EEPROM substitutes

So I had no programmable EPROMs in my spares box, but fortunately I had a Xicor 2816 which is an EEPROM with pinout compatible with the 2716. It speeds up my development too as I don't need to go through the UV erase step.

28pin to 24 pin adaptor

If you can't get hold of a suitable chip or programmer, another way out is to build an adaptor using two IC sockets and patch wire so that you can use the much more widespread 28 pin EPROMs (2764 and above). Fortunately I don't have to do this (yet).

pdftk cannot open some protected PDFs

I receive some documents as protected PDFs. I got tired of inputting the password every time I viewed them with okular so I decided to batch unprotect all the ones I have. This is on a computer which only I use.

I tried the recommended pdftk command:

pdftk protected.pdf input_pw secret output plain.pdf

but it kept telling me OWNER PASSWORD REQUIRED. Eventually I decided it was pdftk's fault, not mine, so I switched to qpdf, using the command:

qpdf --password=secret --decrypt protected.pdf plain.pdf

and that worked.

A web search showed various complaints about this. I haven't investigated when or why the problem occurs.