Monday, December 23, 2013

3208Clock Part 4: Get started with the HT1632C display driver

There are several ways to get started with the HT1632C display driver. One attempt, and this was also my first step, is to check on Google if someone has already written a driver or a library for the HT1632C. And yes, there are a lot of them.

At first I was playing around with the Arduino library from Adafruit. After some modifications I was able to write something to the display.

A Picture from one my first tests with the Adafruit lib

I also figured out that an update of the complete display (from the frame buffer into the HT1632C display driver) took 8.3ms and was only done with a clock speed of approx 35kHz. Please keep in mind that the ATmega8 of the 3208Clock is running at only 8MHz.

Yellow: Chip Select (CS)
Blue: Clock (WR)

A closer look also showed that the duration of the clock cycles is not equal during the transmission. The frequency of the clock is increasing which means that the time for one period of the clock cycle decreases during the transmission of a 16bit value from 33.6µs to 24.8µs.

Yellow: Chip Select (CS)
Blue: Clock (WR)
Yellow: Chip Select (CS)
Blue: Clock (WR)

At this point I wanted to know 2 things.
  1. Why is the duration of the clock cycles not constant during the transmission?
  2. Why is there only a clock frequency of approx 35 kHz (Datasheet says on page 4 1MHz is ok) which causes a update time for the entire display of 8.3ms?

Investigations and benchmarks

At first I figured out that HT1632::writeScreen() and HT1632::writedata(uint16_t d, uint8_t bits) are the functions of the Adafruit library which take care for the transmission. To have something which makes it easier to investigate I have prepared some small Arduino sketches where I only implemented the corresponding functions.

writedata(uint16_t d, uint8_t bits)

In this function the bit banging except the selection of the chip (CS) is done.

void writedata(uint16_t d, uint8_t bits)
{
  pinMode(_data, OUTPUT);
  for (uint8_t i=bits; i > 0; i--) {
    digitalWrite(_wr, LOW);
    if (d & _BV(i-1)) { digitalWrite(_data, HIGH); }
    else { digitalWrite(_data, LOW); }
    digitalWrite(_wr, HIGH);
  }
  pinMode(_data, INPUT);
}

 Answer for Question No 1

In the line "if (d & _BV(i-1))" happens the magic which causes that the clock cycles are varying during the transmission.

_BV(i-1) is the same like (1<<(i-1)), i is the iterator of the for-loop which is initialized with the number of bits. In the worst case the the iterator i is initialized with 16 which causes that in the check for the if-statement a "left shift operation" is executed 15 times. Because that i gets smaller every bit it has to do less and less shift operations to check the if-statement. And this causes that the clock cycle is not equal over the transmission of multiple bits.

I have fixed the problem with the clock speed by the following code modification:


void writedata(uint16_t d, uint8_t bits)
{
  uint16_t compareBit = 0;
  // 0x8000 -> set MSB
  compareBit = bits == 16 ? 0x8000 : compareBit |= (1<<(bits-1)); 
  
  pinMode(_data, OUTPUT);
  for (uint8_t i=bits; i > 0; i--)
  {
    digitalWrite(_wr, LOW);
    if (d & compareBit) { digitalWrite(_data, HIGH); } // 1
    else { digitalWrite(_data, LOW); } // 0
    compareBit = compareBit >> 1;
    digitalWrite(_wr, HIGH);
  }
  pinMode(_data, INPUT);
}

At the beginning of the function I have made a new variable for the comparison if the DATA pin has to be set. These are some lines more code but in this case the bit shift is only executed once in the for-loop. I also set the compareBit variable in a clever way because the most data packages are 16bit in this case the variable is preset with 0x8000 which is nothing else than setting the MSB true. Otherwise we have a repetitive shift operation for the amount of bits that have to be sent.


After this modification the frequency of the clock has been increased to approx 41.5kHz and the duration for a complete screen refresh is now 6.9ms this is 83% of the time it took before the modification.


Yellow: Chip Select (CS)
Blue: Clock (WR)
 

Yellow: Chip Select (CS)
Blue: Clock (WR)


Answer for Question No 2

After the initial improvement of the clock speed to 41.5kHz it still felt to slow for me. So I have removed all the Arduino specific stuff from the corresponding functions and replaced it by native "avr gcc" code.


void writedata(uint16_t d, uint8_t bits)
{
  uint16_t compareBit = 0;
  // 0x8000 -> set MSB
  compareBit = bits == 16 ? 0x8000 : compareBit |= (1<<(bits-1));
  
  DDRB |= (1<<DATA);
  for (uint8_t i=bits; i > 0; i--)
  {
    PORTB &= ~(1<<WR);
    if (d & compareBit) { PORTB |= (1<<DATA); } // 1
    else { PORTB &= ~(1<<DATA); } // 0
    compareBit = compareBit >> 1;
    PORTB |= (1<<WR);
  }
  DDRB &= ~(1<<DATA);
}


I was not aware that the speed improvement would be factor 10!


Yellow: Chip Select (CS)
Blue: Clock (WR)

Yellow: Chip Select (CS)
Blue: Clock (WR)

All three sketches can be downloaded from my GitHub repository.
Slow is the original code, medium is the code with the bugfix for the varying clock cycle and fast is the code for with all improvements.

Friday, December 20, 2013

The Idea, the Design, the Mistake

I know, it's been a long time since my last post. But I was busy with other stuff and also my laziness (a skill which I have trained close to perfection) has prevent me from doing a new post.

This time I want to write about the good, the bad and the ugly the idea, the design and the mistake.

The Idea

While using an Arduino MEGA 2560 with the Ethernet shield I've discovered that there are still a lot of unused and free pins available.


It covers the pins 14-53 and A8-A15 (A6,A7 are also free but difficult to reach with a additional board).

These pins include:
  • USART 1-3 (14-19)
  • I2C (20,21)
  • PWM (44-46)
  • SPI (50-53)
  • ATmega2560 external memory interface (22-37, 39-41)
  • +5V and GND
This brought me to the idea to make a small prototyping shield for these pins.

The Design

For aesthetic reasons I wanted to make a *duino shaped board so I've downloaded the Arduino Mega 2560 reference design form the Arduino homepage to get the exact measurements for the pins and the board outline. Based on that I was able to create a EAGLE library with some templates (board outlines and connectors) to create own shields for the Arduino Mega.


The Mistake

After a lot of checks of the EAGLE *.brd file and additional checks of each of the Gerber layers I've ordered the the PCB at OSH Park. 24 Days later I've found the boards in a nice purple envelope in my mailbox.

I quickly unpacked the PCBs, fired up my soldering station and searched for some pin headers in my assortment boxes. Just some seconds after I have found the pin headers I have discovered that they do not fit trough the holes of the vias - I experienced a strong feeling of disappointment/frustration :-(

A cigarette later I decided to investigate what went wrong. I have discovered that the drilling of all vias in my design of the board where only 0.8mm and a diameter of at least 1.0mm is necessary to put pin header trough the holes. I've decided to make the holes of the vias for the connectors to the Arduino 1.2mm and the rest of the holes of the prototyping area 1.1mm.
I also have updated all packages in my EAGLE Arduino library

But even if the pin headers do not fit to the board I was able to see that it would fit nicely. So I have ordered the updated revision of the board directly again at OSH Park. In 3-4 weeks I will see the final result.