No, this is not about their killer driver fiasco from a couple of weeks ago. In a sense, that was a success – at least the driver did what it was supposed to do! How about distributing a demo source code for a new product  – probably the very first code a user will try to compile and run  – that has obvious bugs which render it useless?

Bug #1: The Undefined Define

The product I’m talking about is VM800P35A I presented here, and the code is the one that’s linked from the  “AN_275 FT800 Example with Arduino” application note. Here’s the direct URL. It contains a header file (“FT800.h”) and an Arduino sketch (“AN_275.ino”) that you’re supposed to compile on the Arduino IDE and upload into the module itself. Can you guess what happened when I did that? Nothing, exactly. It compiled and got uploaded just fine, but the screen remained blank.

It took me some digging to find out what the problem was. It turned out that there were two #define directives there, for the user to select whether it’s being compiled for the VM800P35A or for an external Arduino (code comments rearranged by me  to fit box):

// Set Arduino platform here
// FTDI FT800 "Plus" board with AT328P 
#define VM800B                
// Arduino Pro, Uno, etc. (I/O 10 on SS#)
//#define ARDUINO

That’s cool – except that VM800B was not used or queried anywhere else in the code! Where it should have been, in the setup() function, there’s another name that wasn’t defined before:

#ifdef FT800P

Isn’t that Just Elegant! Anyway, simply change either of them to the other, and the program loads and works. So we’re all good now, right?

Bug #2: The Shift Of Doom

We were all good, for a time. I managed to get some nice graphics going. Then I tried to get data from the touch screen. This boils down to reading a 32-bit register from the FT800 chip and breaking it into the X and Y coordinates. I did that and got a sensible response for the Y axis, but always zero on the X axis.

After making sure my own code was 100% valid, I was convinced that it was a hardware issue and started writing FTDI support for help. Then something else struck me. Here’s the relevant part from the function FTDI provided for reading a 32-bit register, using the Arduino’s SPI communication:

ftData32 = (SPI.transfer(ZERO));  
ftData32 = (SPI.transfer(ZERO) << 8) | ftData32;
ftData32 = (SPI.transfer(ZERO) << 16) | ftData32;
ftData32 = (SPI.transfer(ZERO) << 24) | ftData32;

Can you spot the problem? Probably not, unless you have some experience with this kind of low-level programming. Here’s another hint, this time from the Arduino SPI library files:

  inline static uint8_t transfer(uint8_t data) {
    SPDR = data;
    asm volatile("nop");
    while (!(SPSR & _BV(SPIF))) ; // wait
    return SPDR;

So we have this method, SPI.transfer, that returns an 8-bit unsigned integer. The register-reading routine calls it four times, each time shifting the incoming bits to the left so that they go into their appropriate position within the thirty-two.

And what, do you think, happens when you shift the bits of an 8-bit integer too far to the left? Why don’t give this little Arduino code a try – remember to open the Serial Monitor:

void setup() {
  Serial.begin(9600);
}

void loop() {
  unsigned long j;
  for (j = 0; j < 32; j++)
    Serial.println(1 << j);
  while (1); 
}

See? If the type of the variable being shifted is implicit, and its value is low enough, the Arduino C++ compiler simply decides it’s a signed integer with 16 bits, and all shifts beyond 15 are lost forever. That’s what happened to the X-axis data. By adding an explicit type cast like so:

(unsigned long) SPI.transfer(ZERO)

 The problem was solved.

This second bug, I admit, is quite subtle and I could have made a similar mistake myself. However, if I developed a brand new product and released an official demo code for it, I would have tested and debugged every single aspect of it  until my ears fell off. How could they let these fundamental bugs slip?  Unbelievable.

I reported the first bug to FTDI some time ago and so far got no response. Since I’m not getting paid to do their QA, that’s the most effort I’m willing to make right now… well, that and ranting to you 😉