Saddest Arduino Demo

The Adafruit 2.8 inch TFT Touch Shield for Arduino v2 seems just about ideal for a small control panel, such as one might use with a modified sewing machine. All you need is a few on-screen buttons, a few status display, and a bit of Arduino love: what more could one ask?

So I gimmicked up some small buttons with GIMP, made two large buttons with ImageMagick, and lashed together some Arduino code based on the Adafruit demo:

Adafruit TFT display - timing demo

Adafruit TFT display – timing demo

The picture doesn’t do justice to the display: it’s a nice piece of hardware that produces a crisp image. The moire patterns come from the interaction of TFT display pixels / camera pixels / image resizing.

It’s not obvious from the Adafruit description, but the display is inherently portrait-mode as shown. The (0,0) origin lies in the upper left corner, just over the DC power jack, and screen buffer updates proceed left-to-right, top-to-bottom from there.

The gotcha: even with the Arduino Mega’s hardware SPI, writing the full display requires nearly 4 seconds. Yeah, slow-scan TV in action.  Writing the screen with a solid color requires several seconds.

After commenting out the serial tracing instructions from the Adafruit demo and tweaking a few other things, these timings apply:

-------------
Writing background
Elapsed: 3687
Writing six buttons
Elapsed: 529
Overwriting six buttons
Elapsed: 531
Rewriting buttons 10 times
Elapsed: 1767
Overwriting 2 large buttons
Elapsed: 1718

The timings work out to:

  • Background: 240×320 → 48 µs/pixel
  • Smaller buttons: 50×25 → 71 µs/pixel → 88 ms/button
  • Rewriting one button: 71 µs/pixel
  • Larger buttons: 120×64 → 56 µs/pixel → 430 ms/button

The button images come from BMP files on a MicroSD card and 8 KB of RAM won’t suffice for even a small button. Instead, the transfer loop buffers 20 pixels = 60 bytes from the card, writes them to the display, and iterates until it’s done.

Trust me on this: watching the buttons gradually change is depressing.

Yes, it could work as a control panel for the sewing machine, but it doesn’t have nearly the pep we’ve come to expect from touch-screen gadgetry. On the other paw, Arduinos are 8-bit microcontrollers teleported from the mid-90s, when crappy 20×4 LCD panels were pretty much as good as it got.

The SPI hardware clock runs at half the oscillator frequency = 16 MHz/2 = 8 MHz = 125 ns/bit. Clocking a single byte thus requires 1 µs; even allowing that each pixel = 3 bytes = 6 SPI operations, there’s a lot of software overhead ripe for the chopping block. I’d be sorely tempted to write a pair of unrolled loops that read 20 pixels and write 20 pixels with little more than a pointer increment & status spin between successive SPI transfers.

It’ll make hotshot C++ programmers flinch, but splicing all that into a single routine, throwing out all the clipping and error checking, and just getting it done might push the times down around 20 µs/pixel. Admittedly, that’s barely twice as fast, but should be less depressing.

However, even with all that effort, the time required to update the screen will clobber the motor control. You can’t devote a big fraction of a second to rewriting a button at the same time you’re monitoring the pedal position, measuring the motor speed, and updating the control voltage. That’s the same problem that makes Arduino microcontrollers inadequate for contemporary 3D printers: beyond a certain point, the hardware is fighting your efforts, not helping you get things done.

A reasonable workaround: no screen updates while the motor turns, because you shouldn’t have any hands free while you’re sewing.

There’s also no way to make up for not having enough RAM or video hardware. The same display runs full-speed video on a Raspberry Pi…

The Arduino source code, hacked from the Adafruit demo:

// 2.8 inch TFT display exercise
// Crudely hacked from Adafruit demo code: spitftbitmap.ino
// 2014-07-03 Ed Nisley KE4ZNU

/***************************************************
  This is our Bitmap drawing example for the Adafruit ILI9341 Breakout and Shield
  ----> http://www.adafruit.com/products/1651

  Check out the links above for our tutorials and wiring diagrams
  These displays use SPI to communicate, 4 or 5 pins are required to
  interface (RST is optional)
  Adafruit invests time and resources providing this open source code,
  please support Adafruit and open-source hardware by purchasing
  products from Adafruit!

  Written by Limor Fried/Ladyada for Adafruit Industries.
  MIT license, all text above must be included in any redistribution
 ****************************************************/

#include <Adafruit_GFX.h>    // Core graphics library
#include "Adafruit_ILI9341.h" // Hardware-specific library
#include <SPI.h>
#include <SD.h>

#define TFT_DC 9
#define TFT_CS 10
Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC);

#define SD_CS 4

unsigned long MillisNow, MillisThen;

void setup(void) {
  Serial.begin(115200);

  tft.begin();
  tft.fillScreen(ILI9341_BLACK);

  Serial.print(F("Initializing SD card..."));
  if (!SD.begin(SD_CS)) {
    Serial.println(F("failed!"));
  }
  Serial.println(F("OK!"));

}

void loop() {
  Serial.println(F("--------------"));
  Serial.println(F("Writing background"));
  MillisThen = millis();

  bmpDraw("Test1.bmp", 0, 0);

  MillisNow = millis();
  Serial.print(F(" Elapsed: "));
  Serial.println(MillisNow - MillisThen);

  Serial.println(F("Writing 6 small buttons"));
  MillisThen = millis();

  bmpDraw("Red50x25.bmp",10,10);
  bmpDraw("Red50x25.bmp",10,50);
  bmpDraw("Red50x25.bmp",10,100);

  bmpDraw("Grn50x25.bmp",80,25);
  bmpDraw("Grn50x25.bmp",80,75);
  bmpDraw("Grn50x25.bmp",80,125);

  MillisNow = millis();
  Serial.print(F(" Elapsed: "));
  Serial.println(MillisNow - MillisThen);

  Serial.println(F("Overwriting 6 small buttons"));
  MillisThen = millis();

  bmpDraw("Grn50x25.bmp",10,10);
  bmpDraw("Grn50x25.bmp",10,50);
  bmpDraw("Grn50x25.bmp",10,100);

  bmpDraw("Red50x25.bmp",80,25);
  bmpDraw("Red50x25.bmp",80,75);
  bmpDraw("Red50x25.bmp",80,125);

  MillisNow = millis();
  Serial.print(F(" Elapsed: "));
  Serial.println(MillisNow - MillisThen);

  Serial.println(F("Writing small button 10x2 times"));
  MillisThen = millis();

  for (byte i=0; i<10; i++) {
    bmpDraw("Grn50x25.bmp",10,175);
    bmpDraw("Red50x25.bmp",10,175);
  }

  MillisNow = millis();
  Serial.print(F(" Elapsed: "));
  Serial.println(MillisNow - MillisThen);

  Serial.println(F("Overwriting 2 large buttons"));
  MillisThen = millis();  

  bmpDraw("GelDn.bmp",0,250);
  bmpDraw("GelUp.bmp",0,250);

  bmpDraw("GelUp.bmp",120,250);
  bmpDraw("GelDn.bmp",120,250);

  MillisNow = millis();
  Serial.print(F(" Elapsed: "));
  Serial.println(MillisNow - MillisThen);

}

// This function opens a Windows Bitmap (BMP) file and
// displays it at the given coordinates.  It's sped up
// by reading many pixels worth of data at a time
// (rather than pixel by pixel).  Increasing the buffer
// size takes more of the Arduino's precious RAM but
// makes loading a little faster.  20 pixels seems a
// good balance.

#define BUFFPIXEL 20

void bmpDraw(char *filename, uint8_t x, uint16_t y) {

  File     bmpFile;
  int      bmpWidth, bmpHeight;   // W+H in pixels
  uint8_t  bmpDepth;              // Bit depth (currently must be 24)
  uint32_t bmpImageoffset;        // Start of image data in file
  uint32_t rowSize;               // Not always = bmpWidth; may have padding
  uint8_t  sdbuffer[3*BUFFPIXEL]; // pixel buffer (R+G+B per pixel)
  uint8_t  buffidx = sizeof(sdbuffer); // Current position in sdbuffer
  boolean  goodBmp = false;       // Set to true on valid header parse
  boolean  flip    = true;        // BMP is stored bottom-to-top
  int      w, h, row, col;
  uint8_t  r, g, b;
  uint32_t pos = 0, startTime = millis();

  if((x >= tft.width()) || (y >= tft.height())) return;

//  Serial.println();
//  Serial.print(F("Loading image '"));
//  Serial.print(filename);
//  Serial.println('\'');

  // Open requested file on SD card
  if ((bmpFile = SD.open(filename)) == NULL) {
//    Serial.print(F("File not found"));
    return;
  }

  // Parse BMP header
  if(read16(bmpFile) == 0x4D42) { // BMP signature
//    Serial.print(F("File size: "));
//	Serial.println(read32(bmpFile));
	read32(bmpFile);
    (void)read32(bmpFile); // Read & ignore creator bytes
    bmpImageoffset = read32(bmpFile); // Start of image data
//    Serial.print(F("Image Offset: ")); Serial.println(bmpImageoffset, DEC);
    // Read DIB header
//    Serial.print(F("Header size: "));
//	Serial.println(read32(bmpFile));
	read32(bmpFile);
    bmpWidth  = read32(bmpFile);
    bmpHeight = read32(bmpFile);
    if(read16(bmpFile) == 1) { // # planes -- must be '1'
      bmpDepth = read16(bmpFile); // bits per pixel
//      Serial.print(F("Bit Depth: ")); Serial.println(bmpDepth);
      if((bmpDepth == 24) && (read32(bmpFile) == 0)) { // 0 = uncompressed

        goodBmp = true; // Supported BMP format -- proceed!
//        Serial.print(F("Image size: "));
//        Serial.print(bmpWidth);
//        Serial.print('x');
//        Serial.println(bmpHeight);

        // BMP rows are padded (if needed) to 4-byte boundary
        rowSize = (bmpWidth * 3 + 3) & ~3;

        // If bmpHeight is negative, image is in top-down order.
        // This is not canon but has been observed in the wild.
        if(bmpHeight < 0) {
          bmpHeight = -bmpHeight;
          flip      = false;
        }

        // Crop area to be loaded
        w = bmpWidth;
        h = bmpHeight;
        if((x+w-1) >= tft.width())  w = tft.width()  - x;
        if((y+h-1) >= tft.height()) h = tft.height() - y;

        // Set TFT address window to clipped image bounds
        tft.setAddrWindow(x, y, x+w-1, y+h-1);

        for (row=0; row<h; row++) { // For each scanline...

          // Seek to start of scan line.  It might seem labor-
          // intensive to be doing this on every line, but this
          // method covers a lot of gritty details like cropping
          // and scanline padding.  Also, the seek only takes
          // place if the file position actually needs to change
          // (avoids a lot of cluster math in SD library).
          if(flip) // Bitmap is stored bottom-to-top order (normal BMP)
            pos = bmpImageoffset + (bmpHeight - 1 - row) * rowSize;
          else     // Bitmap is stored top-to-bottom
            pos = bmpImageoffset + row * rowSize;
          if(bmpFile.position() != pos) { // Need seek?
            bmpFile.seek(pos);
            buffidx = sizeof(sdbuffer); // Force buffer reload
          }

          for (col=0; col<w; col++) { // For each pixel...
            // Time to read more pixel data?
            if (buffidx >= sizeof(sdbuffer)) { // Indeed
              bmpFile.read(sdbuffer, sizeof(sdbuffer));
              buffidx = 0; // Set index to beginning
            }

            // Convert pixel from BMP to TFT format, push to display
            b = sdbuffer[buffidx++];
            g = sdbuffer[buffidx++];
            r = sdbuffer[buffidx++];
            tft.pushColor(tft.color565(r,g,b));
          } // end pixel
        } // end scanline
//        Serial.print(F("Loaded in "));
//        Serial.print(millis() - startTime);
//        Serial.println(" ms");
      } // end goodBmp
    }
  }

  bmpFile.close();
  if(!goodBmp) Serial.println(F("BMP format not recognized."));
}

// These read 16- and 32-bit types from the SD card file.
// BMP data is stored little-endian, Arduino is little-endian too.
// May need to reverse subscript order if porting elsewhere.

uint16_t read16(File &f) {
  uint16_t result;
  ((uint8_t *)&result)[0] = f.read(); // LSB
  ((uint8_t *)&result)[1] = f.read(); // MSB
  return result;
}

uint32_t read32(File &f) {
  uint32_t result;
  ((uint8_t *)&result)[0] = f.read(); // LSB
  ((uint8_t *)&result)[1] = f.read();
  ((uint8_t *)&result)[2] = f.read();
  ((uint8_t *)&result)[3] = f.read(); // MSB
  return result;
}
About these ads

4 Comments

Interplak Water Jet: End of the Line

The brittle tubing on Mary’s Interplak water jet continued to disintegrate, so I replaced the entire tube with Tygon:

Interplak water jet - interior

Interplak water jet – interior

Nisley’s First Rule of Plumbing: Never, ever look inside the pipes delivering water to your faucet.

Interplak handle - interior view

Interplak handle – interior view

That’s not quite inside the pipes, but it’s pretty grotendous, isn’t it?

As expected, flexible tubing doesn’t transmit the pressure pulses nearly as well as the OEM rigid tubing, so we finally bought a new Waterpik. At least you can get replacement tubing for Waterpiks, but I’ll wait until it fails before stocking up.

Contrary to what you might expect, I cut the Interplak’s cord, harvested the motor windings, and dumped the carcass in the trash.

8 Comments

Turtle Teleportation: Love Road

We spotted another turtle while on a grocery ride:

Turtle on Love Rd - as spotted - 2014-07-02

Turtle on Love Rd – as spotted – 2014-07-02

Although this is certainly meddling in the turtle’s affairs, it seemed reasonable on a torrid day with plenty of hot asphalt to cross:

Turtle on Love Rd - pickup - 2014-07-02

Turtle on Love Rd – pickup – 2014-07-02

I made the (possibly unwarranted) assumption that the turtle wanted to cross the road; I’ve been wrong before.

In any event, this must be what teleportation feels like:

Turtle on Love Rd - delivery - 2014-07-02

Turtle on Love Rd – delivery – 2014-07-02

There’s not really much on that side of the road, other than an inactive oil spill site left over from when Love Oil ran a tank farm. That’s why it’s called Love Rd, of course.

Perhaps someone else will help the turtle cross the road in the other direction…

 

 

2 Comments

Forester Trailer Hitch: Installation Notes

Start with loose parts rattling around inside a battered cardboard package:

Trailer hitch receiver - as received

Trailer hitch receiver – as received

I backed the Forester up to put the rear tires over the edge of the garage apron, which provided enough room to work underneath without jacking the thing; there’s a chock under the left front wheel, never fear.

The instructions from etrailer.com were entirely adequate, so there’s not much point in a detailed writeup. Their time estimate (an hour) seems grossly understated, but I wasn’t in any hurry.

A morning of pleasant wrenching produced a good-looking, albeit nearly invisible, result:

Forester trailer hitch - installed

Forester trailer hitch – installed

Both hitches bolt directly to the frame and I have no idea what effect that has on the collision behavior. My guess is that the Subaru hitch would be more bendy, if only because it has a much lower load rating, but that probably doesn’t make much difference.

Some notes:

Remove the muffler, which is trivially easy on a new car, and reuse the crushable gasket, which is probably not recommended. After releasing the muffler, you can ease the mounting pins out of their rubber supports without applying any lube or issuing many curses. The tailpipe remains in place, conveniently away from the proceedings.

As others have noted, remove the heat shield, snip a few square inches from the inside front corner, and reinstall with only three screws. I chopped clearance holes for the hitch bolts using a box cutter, but you could probably just punch them right through the butter-soft aluminum sheet.

The instructions suggest drilling / rasping the center mounting holes to 1-1/8 inch diameter. Being that type of guy, I used a step drill to get a 1 inch hole, filed slots on the front and rear sides to accommodate the reinforcing plates, then filed the corners where the slots meet the hole for the carriage bolt heads. The bolts and plates just barely fit, but that leaves more metal on the frame;  I doubt any of that matters.

I felt badly about leaving steel filings inside the frame, but there’s no practical way to extract them. I didn’t prime-and-paint the raw edges, either, as they’re buried deep inside the hitch frame; I may regret that decision.

Wear eye protection: those six fish wires have lethally sharp and very whippy ends.

You can support the hitch on your chest to maneuver it into position, but an assistant must hold it in the proper alignment while you fiddle with fish wires, bolts, and nuts.

I don’t know what happens to the raised bump in the frame under the heat shield, but I suspect it gets crushed flat after torquing the nuts on either side.

When you reinstall the muffler, remember to take the gasket off the mounting pin where you put it for safekeeping before maneuvering the pins back into the hangers …

The Official Subaru OEM Hitch Assembly Instructions commence with loosening the taillight housings and then get complicated. That hitch mounts on a crossbar that completely replaces the bumper beam inside the dress cover, the receiver extends through a small square section of the cover that you cut out as part of the process, the mount occupies the two rearmost holes in the frame members, and it doesn’t require trimming the heat shield. It also costs nigh onto $800 including dealer labor.

 

 

2 Comments

Shimano SPD Pedals: Creaking Resolved

Both Shimano SPD pedals on my Tour Easy have been creaking while climbing hills and I’ve gradually eliminated all the usual mechanical suspects: loose bottom bracket bearings (it’s a cartridge), loose cranks (they’re the old-school tapered squares), loose pedal spindles, and so forth. Of course, it’s impossible to produce the creak with the bike clamped in the work stand, which make debugging particularly frustrating.

After all that, I noticed the shoe soles were wearing the pedal frames just outside the cleat clamps:

Shimano SPD pedal - shoe sole abrasion

Shimano SPD pedal – shoe sole abrasion

So I went so far as to carve away a bit of the sole:

Shimano SPD cleat - trimmed shoe sole

Shimano SPD cleat – trimmed shoe sole

Turns out none of that solved the problem.

What did solve the problem: a drop of oil on the rear of the cleat. You can see a smear of oil on the sole; it doesn’t take quite so much.

As nearly as I can tell, the rear of the cleat drags on the slightly irregular surface of the clamp and, both surfaces being hardened steel, they stick-and-slip just slightly.

A dab of grease may provide longer-lasting relief …

2 Comments

Kenmore 158: NPN Transistor vs. Rectified 120 VAC

Eks found some heavy-duty ET227 NPN transistors in his heap and put them on the basement steps for me … months ago, because he knew I’d be needing them.

Mounting an ET227 on a massive CPU heatsink with thermal compound and wiring it in place of the failed MOSFET produces this lashup:

Kenmore 158 - ET227 FW drive

Kenmore 158 – ET227 FW drive

The base drive comes directly from a bench supply and the collector sees full-wave rectified 120 VAC from the isolated Variac. The maximum base current rating of 40 A at DC suggests it’ll be difficult to screw this one up. The rectifier bridge doesn’t dissipate enough power to warm up, even without a heatsink.

The SOA plot from the ET227 datasheet has the expected 1 kV and 100 A limits that you can’t actually reach under most conditions:

ET227 - Safe Operating Area

ET227 – Safe Operating Area

The Kenmore 158 motor has a DC resistance of about 50 Ω, so the locked-rotor current won’t be more than about 3 A. The motor current runs around 700 mA with a voltage drop across the transistor ranging from 20 V to 50 V at normal operating conditions, so it’s just barely within the DC SOA. So far, my efforts to kill it by stalling the motor have been unavailing; I have four spares and Eks has at least five more in his heap.

The ET227 has a 960 W (!) maximum dissipation on an ideal heatsink, so the piddly 35 W it might see here doesn’t amount to much. The heatsink should have a quiet demand-driven fan.

The operating current is offscale low along the left edge of the DC Current Gain plot, which suggests a DC gain under 10:

ET227 - DC Current Gain

ET227 – DC Current Gain

As it turned out, the gain was around 7, with 100 mA base drive producing 700 mA of collector current at VBE = 0.9 V, although that comes from the bench supply’s low-res meters. There being an exponential relation between the bench supply’s voltage output and the transistor’s base current, along with the motor’s square-law positive feedback, speed control was mmmm touchy.

So the challenge will be stuffing 100 mA into a 1 V base voltage, with much better resolution and much less ripple than the usual Arduino PWM output, from an isolated supply. Given the amount of power I’m willing to burn in the ET227, a few more watts of base drive won’t make a bit of difference.

Perhaps the best way to handle all the nonlinearities in the current control path will be an isolated current feedback monitor. Hello, Hall effect sensors … [sigh]

9 Comments

Kenmore 158: MOSFET vs. Rectified 120 VAC

This arrangement actually worked:

Kenmore 158 - FW bridge MOSFET test

Kenmore 158 – FW bridge MOSFET test

At least until I blew out the MOSFET, which is about what I expected. It’s screwed to that randomly selected heatsink, with a dab of thermal compound underneath.

Incoming AC from an isolated variable transformer (basically, an isolated Variac) goes to a bridge rectifier. Rectified output: positive to the motor, motor to MOSFET drain, MOSFET source to negative.

MOSFET gate from bench supply positive and supply negative to source.

Hall effect current probe clamped around the motor current path.

The MOSFET was an IRF610: 200 V / 3.3 A. That’s under-rated for what I was doing, but I had a bunch of ‘em.

I actually worked up to that mess, starting with the bare motor on the bench running from the 50 VDC supply. That sufficed to show that you can, in fact, control the motor speed by twiddling the gate voltage to regulate the current going into the motor. It also showed that a universal-wound motor’s square-law positive feedback loop will definitely require careful tuning; think of an unstable fly-by-wire airplane and you’ve got the general idea.

In any event, flushed with success, I ignored the safe operating area graph (from the Vishay datasheet):

IRF610 - Safe Operating Area

IRF610 – Safe Operating Area

Drain current over half an amp at 160-ish peak volts (from rectified 120 VAC) will kill the MOSFET unless you apply it as short single pulses, not repetitive 120 Hz hammerblows.

I also ignored the transfer characteristics graph:

IRF610 - Typical Transfer Characteristics

IRF610 – Typical Transfer Characteristics

The curve starting at the lower left should be labeled 25 °C and the other should be 150 °C. The key point is that they cross around VGS = 6.5 V, where IDS = 2 A. Below that point, the MOSFET conducts more current as it heats up… which means that if a small part of the die heats up, it will conduct more current, heat up even more, and eventually burn through.

Yes, MOSFETs can suffer thermal runaway, too.

The motor draws about half an amp while driving the sewing machine, which suggests the gate voltage will be around 5 V. In round numbers, it was 5.5 to 6 V as I twiddled the knob to maintain a constant speed.

At half an amp, the MOSFET dissipated anywhere from a bit under 1 W (from RDS(on) = 1.5 Ω to well over 25 W (while trying to maintain headway with friction on the handwheel). I ran out of fingers to record the numbers, but dropping 10 to 20 V across the MOSFET seemed typical and that turns into 5 to 10 W.

It eventually failed shorted and the sewing machine revved up to full speed. Sic transit gloria mundi.

In any event, I think the only way to have a transistor survive that sort of abuse is to start with one so grossly over-rated that it can handle a few amps at 200 V without sweating. It might actually be easier to get an ordinary NPN transistor with such ratings; using a hockey puck IGBT or some such seems like overkill.

Eks probably has a box full of the things …

6 Comments