Wednesday 31 October 2018

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.

Tuesday 23 October 2018

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.