Arduino Nano “USB Device Not Recognised” Fix

January 19, 2019 at 5:06 pm (maker) (, , , )

I have quite a range of Arduino Nano boards of varying vintage, but I’ve found some always come up with “USB Device Not Recognised” in Windows and wanted to work out why.  Symptoms are:

  • all fine if powered externally or via the ISP header.
  • “USB Device Not Recognised” errors otherwise.

These are Arduino Nano v3.0 boards I believe, and it turns out there is a known issue where the TEST pin of the FTDI chip isn’t correctly grounded, which makes the boards unreliable at best, and constantly failing at worst.

The faulty boards look like this:

arduino nano ftdi - toparduino nano ftdi - bottom

Notice the FTDI chip on the bottom of the board – this is the cause of the issue.  Many of the other cheap clones of the Arduino Nano use the CH340 chip, these don’t seem to have a similar issue.  For reference, they look like something like this instead:

arduino nano ch340 - bottom

The fix for the issue is described here on the Arduino Forums: http://forum.arduino.cc/index.php/topic,23025.0.html

But you will need your soldering iron and a very steady hand (and probably a magnifying glass).  Basically the poster shorted pins 26 (TEST) and 25 (AGND) on the chip and that seems to do the trick.  These pins (3rd and 4th from the top right hand side of the chip) are highlighted below (see the FT232RL datasheet for details).

arduino-nano-ftdi-fix.jpg

ftdi-ft232rl-pinout

Attempt the fix at your own risk of course.  Double check the part number of the chip, the orientation with the spot and the datasheet for the part number you are reading on the chip before you go near the soldering iron.

It worked for me.  YMMV.

Kevin

 

Advertisements

Permalink Leave a Comment

Dual ScrollPhatHD 17×14 LED Array

January 13, 2019 at 12:31 pm (maker) (, , , , , )

Having now had a play with my ScrollPhatHDs with the Arduino I’ve now successfully linked two together via a TCA9548A breakout board (having solved my Weird Multi-I2C Bus Issues as previously described).

The ultimate aim was to make a self-contained unit containing two ScrollPhatHD boards, an Arduino Nano and the TCA9584A.  I’ve now managed that using a square piece of breadboard, various jumper wires and most importantly, the Pimoroni Pogo-a-go-go Solderless header pins – I just didn’t want to spoil the neat look of the ScrollPhatHD’s by soldering to them directly.  The Pogo-pins are just perfect for spring-loaded connections between the ScrollPhatHDs and breadboard.

The one quirk, is that if I wanted all boards nicely sandwiched between the ScrollPhatHDs and the breadboard, but wanted to use the pogo-pins, then the breadboard needs to be strip-side up.

Here is the plan, followed by some photos of the finished item.

scrollphat-breakout_bb

I’ve left the nano and tca breakout off, so I can see the tracks.  This was from a first experiment with the two Phats, so it already had three full height sets of cuts in tracks – hence the few places where there were a couple of bits of patching to do, which were just done with solder links.  There are a few pins added to support the nano, especially at the USB end where I’ll be plugging in and out, which aren’t connected to anything on the stripboard.  And the four pins highlighted for the two ScrollPhat’s themselves weren’t soldered pins – that is the location for the pogo-pins.

In the final board, I put the jumper wires on the underside, and used headers pushed right through from below.  I also added a reset switch (not shown in the plan) wired to the Nano RST and ground on the strip board.

The linking of the two Phats isn’t perfect – the Nano USB port is just a fraction too high to perfectly fit, meaning the two boards bow out slightly in the middle.  Note the use of the pogo-pins.  I could replace them all with a slightly longer stand-off, but this is fine for a prototype.

Also, I made sure to drop some insulating tape on the bottom of both the Nano and the TCA board, to make sure it wouldn’t short anything on the copper of the stripboard.  I also put a bit around the shield of the USB port just in case, but I don’t think there was anything conductive on the back of the Phat.

So I now have a USB-accessible, self-contained, programmable 17×14 LED array.

Software wise, this uses the modified Adafruit IS31FL3731 Library I mentioned before, with the added quirk that one of the boards needs the coordinates reversing.  Coupled with the need to switch boards using the TCA as well, this means the basic idea of using the board is as follows:

#include <Wire.h>
#include <Adafruit_GFX.h>
#include <ScrollPhat_IS31FL3731.h>

// ScrollPhats connected using a TCA9548A I2C Multiplexer
// These are the I2C bus numbers used
#define TCAONE       0
#define TCATWO       1

//  HOR = number in horizontal (x) plane
//  VER = number in vertical (y) plane
#define HOR 17
#define VER 14

// Scrollphats have a hardcoded I2C address.
// Assumes connected as follows:
//      ledmatrix1 - using SC0 via the TCA
//      ledmatrix2 - using SC1 via the TCA
ScrollPhat_IS31FL3731 ledmatrix1 = ScrollPhat_IS31FL3731();
ScrollPhat_IS31FL3731 ledmatrix2 = ScrollPhat_IS31FL3731();

#define TCAADDR 0x70
void tcaselect(uint8_t i) {
  if (i > 7) return;
 
  Wire.beginTransmission(TCAADDR);
  Wire.write(1 << i);
  Wire.endTransmission();  
}

void setup () {
  // Initialse the I2C handling
  Wire.begin();
  
  tcaselect(TCAONE);
  ledmatrix1.begin();
  tcaselect(TCATWO);
  ledmatrix2.begin();
    
  // Do something to initialse your pixel array
}

void loop () {
  // Do stuff on your pixel array
  // Don't forget to write the displayRead(x,y) function
  // used in the scan routine

  ScanDisplay();
}

// Note: you need to implement the displayRead (x,y) function
//      to determine if a pixel is on or off
//
void ScanDisplay () {
  // Scan the first matrix
  tcaselect(TCAONE);
  for (uint8_t x=0; x<HOR; x++) {
    for (uint8_t y=0; y<VER/2; y++) {
      if (displayRead (x, y)) {
        ledmatrix1.drawPixel(x, y, 64);
      } else {
        ledmatrix1.drawPixel(x, y, 0);
      }
    }
  }

  // Scan the second matrix
  // Note this is oriented 180 degrees, so reverse both
  // x and y prior to setting, also of course, only using
  // the second half of the pixel array to display here.
  tcaselect(TCATWO);
  for (uint8_t x=0; x<HOR; x++) {
    for (uint8_t y=0; y<VER/2; y++) {
      if (displayRead (HOR-x-1, VER/2-1-y+VER/2)) {
        ledmatrix2.drawPixel(x, y, 64);
      } else {
        ledmatrix2.drawPixel(x, y, 0);
      }
    }
  }
}

 

Kevin

Permalink Leave a Comment

Weird Multi-I2C Bus Issues

January 11, 2019 at 8:17 pm (maker) (, , , )

This is just a quick post as a future reminder really.  I have two ScrollPhat HD Pimoroni boards that I’m using with an Arduino Nano, but as the I2C address is fixed for the boards, I’m using a TCA9548A I2C multiplexer breakout board to change I2C buses between accessing the two ScrollPhatHD boards.

But I was getting weird bus issues – sometimes only one of the boards came up, sometimes none, very occasionally, they were both fine.  I tried different channels off the TCA, swapping the boards over, I tried linking the RESET line of the TCA to the RESET line of the Arduino.  I even tried connecting the RESET line of the TCA to a digital pin and resetting the TCA manually on power up, but nothing seemed to work.

Then I saw a post somewhere about some weird I2C bus issues and one of the responses was “make sure you are calling Wire.begin();”.  I’d forgotten to put that in.

Once the code was calling Wire.begin() (only once mind), all was well.  It now powers up reliably and no resetting of the TCA is required.  All is good.

Kevin

 

Permalink 1 Comment

Pogo-pin ISP Programming Header

January 9, 2019 at 8:20 pm (maker) (, , , )

I have a batch of Arduino Nanos that have been used on projects but now don’t seem to accept a download unless I burn a new bootloader to them.  I have an excellent USBasp  ISP programmer to do that, but connecting to unpopulated ISP header pads on a nano without taking it out of a project is a bit fiddly, so I wanted a pogo-pin ISP header programmer.

But this is one of those times where I just haven’t seemed to hit on the right search terms to bring one up to buy.  So after a bit of experimenting, I’ve made my own.

Shopping list:

  • Cheap pogo-pins (I grabbed a pack of 50 from China).
  • “Dupont” crimp headers for a 3×2 header block (I got a multi-pack with a range of headers and male and female crimp inserts).
  • Your favourite ISP programmer of course.

2019-01-09 19.39.47

The idea is the solder the pogo-pins into the crimp part of the pins instead of a cable, and end up with a two-sided 3×2 header blog – pins on one side, pogo-pins on the other, as follows:

2019-01-09 19.41.142019-01-09 19.40.002019-01-09 19.55.20

The only thing to watch out for is getting the pins straight enough to make a neat 3×2 grid that will line up with header pads.  This can then be inserted in your ISP adapter header in the usual way.

2019-01-09 19.56.30

The only downside for me is that the pins are a little small still to make a perfect connection to an unpopulated set of header pads with solder holes.  But its more reliable than just poking an unsoldered 3×2 header block in the holes, which is what I was doing before.

Its a pretty simple idea, but I’ve just not seen anything like it around to buy off the shelf, or described in any kind of diy manner.  Let me know if you know of a better (cheap) solution.

Kevin

Permalink Leave a Comment

Pimoroni ScrollPhat using Adafruit IS31FL3731 Library

December 29, 2018 at 11:08 pm (maker) (, , , , , , )

I finally got myself a genuine Adafruit IS31FL3731 driver board and LED matrix (that I mentioned in a previous post) and glued an Arduino Nano on the back, thus creating a very neat little self-contained USB-driven 16×9 matrix of surface mount LEDs, which is great.

This uses the same driver chip as the Pimoroni ScrollPhat HD board for the Raspberry Pi, which is another great board I have, but I wanted to drive it from an Arduino too, so set about looking to see if the Adafruit libraries would work for the Pimoroni board too.  Four connections are required, as usual for I2C – VCC, GND, SDA, SCL as defined in the pinout here.

In summary, yes, but the Pimoroni has an odd LED configuration, as can be seen in the provided Python library:

class ScrollPhatHD(Matrix):
    width = 17
    height = 7

    def _pixel_addr(self, x, y):
        if x > 8:
            x = x - 8
            y = 6 - (y + 8)
        else:
            x = 8 - x
        return x * 16 + y

So the key feature is getting this translation over into the Adafruit IS31FL3731 library in the correct place.  So, taking a copy of the Adafruit_IS31FL3731.cpp and Adafruit_IS31FL3731.h files there were a number of changes to make.

First of all, the Adafruit boards provide a matrix of 16×9 (total 144) leds, compared to the ScrollPhat’s 17×7 (119) leds, so everywhere there is a reference to a width of 16 and height of 9, that needs changing to 17 and 7 respectively.  Unfortunately, there were a number of hard-coded “16”s and “9”s that needed updating.

Then, the translation function is required as follows (added to the .cpp and defined in the .h files):

// ScrollPhat LED Mapping taken from:
// https://github.com/pimoroni/scroll-phat-hd/blob/master/library/scrollphathd/is31fl3731.py
uint8_t ScrollPhat_IS31FL3731::xy2led (uint8_t x, uint8_t y) {
  if (x>8) {
    x = x-8;
    y = 6-(y+8);
  } else {
    x = 8-x;
  }
  return x*16 + y;
}

This function is responsible for translating the x,y values into a serialised led offset number (0 to 144 in the case of a fully populated matrix like the Adafruit).  There is one place where this has to be called – in the function ScrollPhat_IS31FL3731::drawPixel the following line needs to be changed as indicated:

From:
  setLEDPWM(x + y*16, color, _frame);

To:
  setLEDPWM(xy2led(x,y), color, _frame);

Assuming all the 16×9 references have been updated correctly to 17×7, and no special rotations or anything were required (I’ve not tested all options in the Adafruit GFX libraries), then this largely seems to work, at least it works with the Adafruit Swirl and gfx demos (although there might be some sorting out still to do in terms of handling rotations).

Kevin

 

Permalink 2 Comments

8×7 LED Array and MCP23017

December 7, 2018 at 8:21 pm (maker) (, , , , , , )

I can’t resist playing with an LED array, especially a surface mount one, so when I stumbled across some cheap (<$2) surface mount 8×7 LED arrays, charlieplexed onto 8 IO pins on ebay, I had to grab some.

Now I should say, I can’t really imagine why anyone would bother doing what I’m about to describe, as you already have many other options, including:

But as I say, I can’t resist a surface mount LED board, so I started to play.  When these arrived and I started poking around, I soon found out they were actually a cheap knock-off of the Sparkfun 8×7 LED Array, something I didn’t even know existed!  Apologies to Sparkfun for not getting an official board, but many thanks to them for open sourcing the design.

Initially they are fairly easy to hook-up and drive.  I used an Arduino Uno for my first experiments, as they could be paired straight away with pins 2-9 and then driven directly using the Arduino Charlieplex library (the Sparkfun Tutorial uses the Chaplex library and a special Sparkfun library for the board, but I was just doing fairly simple things for now).

With the neat serial interface to the Pi-Lite in the back of my mind, I wanted a better way to connect to the board.  Ideally, something that could be soldered onto the back to make it a single unit.  Some options I explored were:

  • Using an IO expander – such as the MCP23017 (the subject of this post).
  • Using an Arduino Mini Pro – to provide a serial interface (bit more on that later).
  • Using an LED driver module.

For this first experiment, I thought having an I2C addressable LED module would be quite neat (I didn’t know about the IS31FL3731 used on the Adafruit and Pimoroni boards at this time – that is an experiment for another day), so I grabbed some cheap MCP23017 breakout boards and after breadboarding it, ended up simply soldering one on the back.  It overlaps ever so slightly, but I think I could still place a few of these side by side to chain them.

2018-12-01-16-06-19.jpg2018-12-01-16-04-34.jpg2018-12-01-16-04-20.jpg

Link-up wise, this ties the 8 IO pins of the matrix to port A pins 0 to 7 on the MCP23017.  The 7 pins with header connections are (in order top to bottom):

  • VCC
  • GND
  • SCL/SCK
  • SDA/SI
  • NC/CS
  • NC/SO
  • RESET

And the three connections with no header pins are the three address encoding pins.  As I’m using I2C I only need four connections: VCC, GND, SCL and SDA (I could have left off the other three header pins really).

In terms of the code, there are libraries for the MCP23017, Charlieplexing and even the aforementioned Sparkfun library for this module, but to link them all together is quite inefficient.  The simple approach would be to replace the low-level pin setting/clearing code in the charlieplex library with commands for the MCP23017.  But as every setting of a single LED, even when triggered as part of a ‘scan’ managing a display buffer, requires I2C commands to be sent over the bus, and each command requires bit manipulation to process the IO pins individually, this is massively inefficient.

However, the MCP23017 is really only be driven by two registers: GPIOA to set the IO pins HIGH or LOW, and IODIRA to set the pins to INPUT or OUTPUT.  Recall that for Charlieplexing, all three states of pins are significant: INPUT, OUTPUT+HIGH, OUTPUT+LOW.

To work out which pins do what, we need to refer to the wiring layout of the LEDs on the board, for which the Sparkfun schematic is key (my thanks again for the open source design).  Here is an annotated version showing which IO pins (numbered 1 to 8 on the schematic) are connected to which LED in the matrix.

2018-12-07-19-29-34.jpg

The key thing to notice is how for every column listed, there is, naturally, a gap in the numbering of the rows (you can’t have an LED connected with both leads to the same IO pin).

So a more efficient scanning algorithm would thus run something like this:

// IODIRA = INPUT (1) or OUTPUT (0)
// GPIOA  = HIGH (1) or LOW (0)

FOREACH col (0 to 7)  // scan one column at a time
  gpiomask = (1<<col) // only pin that is HIGH in the col pin
  dirmask = 0         // default to all OUTPUTS
  FOREACH iopin (0 to 7)
    led = iopin
    IF (iopin == col) SKIP
    IF (iopin > col) THEN
       // led we want is one less than iopin due to charlieplex mapping
    IF (led for col is OFF) THEN
       dirmask |= (1<<iopin)  // set this one to an INPUT i.e. OFF
  NEXT iopin
  IODIRA = dirmask
  GPIOA  = gpiomask
NEXT col

The basic principle being that for a single scan, set one pin HIGH/OUTPUT (for one column in the matrix) and then work out which other LEDs need to be active by setting the direction of the pins accordingly – LOW/OUTPUT will light the LED for that pin combination; INPUT will mean the led for that combination is off.  Then on the next scan, do the same for the next column.

The following is some basic code, based on a whole range of sources (and to be honest, not particularly well structured in terms of functional separation) to provide an I2C optimised scanning function for the MCP23017 and LED array combination.

Usual caveats apply – I’m not really a cpp person, use at your own risk, etc, etc.

Key gotchas from doing this:

  • You can set the I2C bus to run at a higher speed, which is well worth doing in this case.  Note that I don’t know what happens if you have lots of things on the bus – this was working with just this LED array and nothing else.  See Wire.SetClock() in the Arduino Wire library.
  • You can’t do I2C from an interrupt routine.  I wanted the scanning routine to run off a timer interrupt, but nothing works if you try to do that – in fact, everything actually completely locks up.

So that’s it for now.  It scans quite well and with not a bad refresh rate, but as I said right at the start, with so many options of LED array available, not quite sure why anyone would want to do this.

Next, I’ll see if I can get the Pi-Lite firmware onto an Arduino Pro Mini and solder that on the back of one of these too.  That will create a standalone, drivable over serial port, module similar to the original Pi-Lite (ish).  Not really sure why anyone would want to do that either.

Kevin

I2CCharlieExample.ino

/*
 * Charlieplex Example for the Sparkfun LED Array board connected
 * to an MCP23017 IO expander chip and accessed via I2C.
 */
#include "I2CCharlieplex.h"
#include "Wire.h" // required for I2CCharlieplex.h

#define MCPADDR  0   // 0 to 7 for 0x20 to 0x27 for MCP23017 expander

// Define the pins in the order you want to address them.
//
// Note: for the MCP23017, pin numbers are as follows:
//         Port A pins 0 to 7 = pins 0 to 7
//         Port B pins 0 to 7 = pins 8 to 15
//
#define NUMBER_OF_PINS 8
byte pins[] = {0,1,2,3,4,5,6,7};

I2CCharlieplex charlieplex = I2CCharlieplex(MCPADDR, pins, NUMBER_OF_PINS);

void setup(){
  charlieplex.init();
  charlieplex.clr();
  charlieplex.scan();
}

int x=0;
int y=0;
int scan=0;
int clr=0;

void loop(){
  delay(1);
  charlieplex.scan();

  // Update the LED pattern from time to time
  if (scan > 200) {
    scan = 0;

    if (clr) {
      charlieplex.clr();
      clr=0;
    } else {
      charlieplex.led (x, y, HIGH);
      x++;
      if (x>=8) {
        x=0;
        y++;
        if (y>=7) {
          y=0;
          clr=1;
        }
      }
    }
  }
  scan++;
}

I2CCharliePlex.cpp

/*
 * I2C MCP23017 I2C IO Expander Charlieplex
 * Based on elements of MCP23017 Library from Adafruit and
 * the Charlieplex library by Alexander Brevig
 *
 * Pins are numbered as follows:
 *   0-7  Port A 0-7
 *   8-15 Port B 0-7
 */

#include "I2CCharlieplex.h"
#include "Wire.h"

// Default address
#define MCP23017_ADDRESS 0x20

// registers (using same definitions as Adafruit_MCP23017.h)
// Note: MCP23017 can be configured for interleaving registers or
//       sequential, depending on the setting of IOCON[AB].BANK.
//       By default on power up IOCON.BANK = 0; i.e. interleaved
//       as defined below..
#define MCP23017_IODIRA 0x00
#define MCP23017_IPOLA 0x02
#define MCP23017_GPINTENA 0x04
#define MCP23017_DEFVALA 0x06
#define MCP23017_INTCONA 0x08
#define MCP23017_IOCONA 0x0A
#define MCP23017_GPPUA 0x0C
#define MCP23017_INTFA 0x0E
#define MCP23017_INTCAPA 0x10
#define MCP23017_GPIOA 0x12
#define MCP23017_OLATA 0x14

#define MCP23017_IODIRB 0x01
#define MCP23017_IPOLB 0x03
#define MCP23017_GPINTENB 0x05
#define MCP23017_DEFVALB 0x07
#define MCP23017_INTCONB 0x09
#define MCP23017_IOCONB 0x0B
#define MCP23017_GPPUB 0x0D
#define MCP23017_INTFB 0x0F
#define MCP23017_INTCAPB 0x11
#define MCP23017_GPIOB 0x13
#define MCP23017_OLATB 0x15

#define MCP23017_INT_ERR 255

// Address in range 0 to 7.  MCP23017 address set in the range
//  0x20 to 0x27 using the A0, A1, A2 pins
I2CCharlieplex::I2CCharlieplex(uint8_t address, byte* userPins, byte numberOfUserPins){
  pins = userPins;
  numberOfPins = numberOfUserPins;

  // Initialise the MCP23017 IO Expander using I2C
  if (address > 7) {
    addr = MCP23017_ADDRESS;  // default to first address if not sure
  } else {
    addr = MCP23017_ADDRESS + address;
  }
}

void I2CCharlieplex::init () {
  Wire.begin();  // We are the bus master

  // Note on I2C clock speed - as a synchronous comms, the clock is set
  // by the master and the slave will be triggered by it.
  // The default is 100kbit/s (standard); many devices will also support 400kbit/s (full speed).
  // Some might support 1Mbit/s (fast mode) or 3.2Mbit/s (high speed).
  // See https://www.i2c-bus.org/speed/
  //
  // 400000 bps is 400000/8 = 50 KB/s
  Wire.setClock(400000); // Use I2C in full speed mode

  // Clear all leds (set all pins to INPUT)
  mcpAllInputs();
}

// LED Buffer access routines
void I2CCharlieplex::led(uint8_t x, uint8_t y, bool state) {
  if ((x<NUMXLEDS) && (y<NUMYLEDS)) {
    if (state == HIGH) {
      leds[y] |= (1<<x);
    } else {
      leds[y] &= ~(1<<x);
    }
  }
}

void I2CCharlieplex::clr() {
  for (uint8_t i=0; i<NUMYLEDS; i++) {
    leds[i] = 0;
  }
}

// WARNING: This cannot be called from an ISR if it is using I2C
//          (everything locks up if you do)
void I2CCharlieplex::scan() {
  // Only scan one column at a time

  // Scan according to the following algorithm:
  //  IODIRA = INPUT (1) or OUTPUT (0)
  //  GPIOA  = HIGH (1) or LOW (0)
  //  
  //  FOREACH col (0 to 7)  // scan one column at a time
  //    gpiomask = (1<<col) // only pin that is HIGH in the col led
  //    dirmask = 0         // default to all OUTPUTS
  //    FOREACH iopin (0 to 7)
  //      IF (iopin == col) SKIP
  //      IF (iopin > col) THEN
  //         led we want is one less than iopin due to charlieplex mapping
  //      IF (led for col is OFF) THEN
  //         dirmask |= (1<<iopin)  // set this one to an INPUT i.e. OFF
  //    NEXT iopin
  //    IODIRA = dirmask
  //    GPIOA  = gpiomask
  //  NEXT col

  // First kill all LEDS
  mcpWrite(MCP23017_IODIRA,0xff);

  uint8_t ledmask = (1<<col);
  uint8_t dirmask = 0;
  for (uint8_t p=0; p<NUMPINS; p++) {
    uint8_t y = p;
    if (p == col) {
      // skip this one
      continue;
    } else if (p > col) {
      // LED index will be one less than pin value due to charlieplex pattern
      y--;
    }
    // check the 'col'th LED in each 'y' row to see if pin 'p' is IN or OUT
    if ((leds[y] & (1<<col)) == 0) {
      // Want IO pin to be low to illuminate the LED
      // So only set IO pin if LED is OFF
      dirmask |= (1<<p);
    }
  }
  // Always need "col" pin as an OUTPUT (low) though
  dirmask &= ~(1<<col);
  
  // Only High pin will be the col being scanned
  mcpWrite (MCP23017_GPIOA, ledmask);
  // All other pins are low, so direction will determine if they are
  // a low OUTPUT or INPUT (which will disable that LED)
  mcpWrite (MCP23017_IODIRA, dirmask);
  // next column
  col++;
  if (col >= NUMXLEDS) {
    col = 0;
  }
}

// I2C MCP23017 IO Handling
// Not: No DigitalRead as yet

void I2CCharlieplex::mcpPinMode (uint8_t p, uint8_t mode) {
  if (mode == INPUT) {
    // Set appropriate bit in register
    mcpBitUpdate(p, 1, pin2reg(p, MCP23017_IODIRA, MCP23017_IODIRB));
  } else {
    // Clear appropriate bit in register
    mcpBitUpdate(p, 0, pin2reg(p, MCP23017_IODIRA, MCP23017_IODIRB));
  }
}

void I2CCharlieplex::mcpAllInputs () {
    // Set all pins to INPUT at once
    // (makes a full clear much quicker than setting individual bits)
    mcpWrite(MCP23017_IODIRA,0xff);
    mcpWrite(MCP23017_IODIRB,0xff);
}

void I2CCharlieplex::mcpDigitalWrite (uint8_t p, uint8_t val) {
  // Need to read current I/O states from the latch,
  // set/clear the appropriate bit and
  // write it back to the GPIO register
  uint8_t io;
  io = mcpRead(pin2reg(p, MCP23017_OLATA, MCP23017_OLATB));
  bitWrite(io, pin2bit(p), val);
  mcpWrite(pin2reg(p, MCP23017_GPIOA, MCP23017_GPIOB), io);
}

//
// I2C MCP23017 Register Handling
//

void I2CCharlieplex::mcpWrite(uint8_t reg, uint8_t val) {
  // Write sequence:
  //    Send register address to write
  //    Send the byte of data
  Wire.beginTransmission(addr);
  Wire.write(reg);
  Wire.write(val);
  Wire.endTransmission();
}

uint8_t I2CCharlieplex::mcpRead(uint8_t reg) {
  // Read sequence:
  //    Send register address to read
  //    Request 1 byte of data from the device
  //    Read the byte of data
  Wire.beginTransmission(addr);
  Wire.write(reg);
  Wire.endTransmission();
  Wire.requestFrom(addr, (uint8_t)1);
  return Wire.read();
}

void I2CCharlieplex::mcpBitUpdate (uint8_t bit, uint8_t val, uint8_t reg) {
  uint8_t regval;
  regval = mcpRead(reg);
  bitWrite(regval,bit, val);
  mcpWrite(reg, regval);
}

// Register and pin helper functions
uint8_t I2CCharlieplex::pin2bit(uint8_t pin){
  // Returns bit 0 to 7 for range of pins 0 to 7 and pins 8 to 15
  return pin%8;
}
uint8_t I2CCharlieplex::pin2reg(uint8_t pin, uint8_t portAaddr, uint8_t portBaddr){
  if (pin < 8) {
    return portAaddr;
  } else {
    return portBaddr;
  }
}

I2CCharlieplex.h

#ifndef I2CCHARLIEPLEX_H
#define I2CCHARLIEPLEX_H

#include <Arduino.h>

class I2CCharlieplex {

// LED matrix is 8 across by 7 deep
// Wired up in a charlieplex mode to map to 8 IO pins
#define NUMXLEDS 8
#define NUMYLEDS 7
#define NUMPINS  8

public:
  I2CCharlieplex(uint8_t address, byte* userPins,byte numberOfUserPins);
  void init ();

  // LED buffer handler functions
  void led(uint8_t x, uint8_t y, bool state);
  void clr();
  void scan();

  // MCP23017 handler functions
  void    mcpPinMode(uint8_t p, uint8_t mode);
  void    mcpAllInputs();
  void    mcpDigitalWrite(uint8_t p, uint8_t val);
  void    mcpWrite(uint8_t reg, uint8_t val);
  uint8_t mcpRead(uint8_t reg);
  void    mcpBitUpdate (uint8_t bit, uint8_t val, uint8_t reg);
  uint8_t pin2bit(uint8_t pin);
  uint8_t pin2reg(uint8_t pin, uint8_t portAaddr, uint8_t portBaddr);

private:
  byte    numberOfPins;
  byte*   pins;
  uint8_t addr;
  uint8_t leds[NUMYLEDS];
  uint8_t col;
};

#endif

Permalink 2 Comments

Arduino, ATtiny85, and Timers

April 29, 2018 at 2:57 pm (maker) (, )

I’m still playing around with using the ATtiny85 as the basis for a synthesizer, using a range of code and circuits from the Internet, but had an irritating problem today with some open code.  The author describes complete build instructions for their code and circuit for v1.5.7 of the Arduino environment and the arduino-tiny library, which as far as I can see was last updated in 2013 from its google code repository.

But I have v1.8.5 and the now easy to use, built-in support for the ATtiny85 from David Mellis (https://github.com/damellis/attiny).

So when it comes to build it on my system I get the following error:

wiring.c.o (symbol from plugin): In function `delayMicroseconds':

(.text+0x0): multiple definition of `__vector_5'

Which is obviously a linker error, but it has proven quite difficult to find a detailed hint as to what the actual problem is.  It says that it has redefined in my .ino file, but wasn’t immediately obvious this related to interrupt routines (although the word vector should have been a clue I guess).

Well it turns out that this is a problem you get if you attempt to defined an interrupt service routine twice.  The code in question had defined

ISR(TIMER0_OVF_vect)

And in any modern Arduino core timer 0 is used for the millisecond timer, as defined in hardware/arduino/avr/cores/arduino/wiring.c.  This is indeed vector 5 (see http://ee-classes.usc.edu/ee459/library/documents/avr_intr_vectors/).  This is defined in wiring.c, but not directly related to the delayMicroseconds function (oh the joys of tracing C linker errors).

I’m skipping over the part where I was attempting to work out where the actual source code being built was stored – not in <program files>\Arduino; not in my own Arduino source area; no it was finding mention of <user>\AppData\Local\Arduino15 that found any ATtiny support in my installation at all.

There seems quite a lot of confusion online (at least from the searching I was doing) about timers on the ATtiny85 and the Arduino environment.  It looks like an earlier version of the Arduino core (although not obviously in the v1.5.7 suggested by the author of the code I was using, so that is still a puzzle) had a method for changing the timer usage for different microcontrollers.

The arduino-tiny library uses a core_build_options.h options file and uses it to set the following:

#if defined( __AVR_ATtiny25__ ) || defined( __AVR_ATtiny45__ ) || defined( __AVR_ATtiny85__ )
#define __AVR_ATtinyX5__
#endif

#if defined( __AVR_ATtinyX5__ )

/*
 For various reasons, Timer 1 is a better choice for the millis timer on the
 '85 processor.
*/
#define TIMER_TO_USE_FOR_MILLIS 1

However, this isn’t in the latest builds of the core or in the version of the ATtiny core support I’m using, which doesn’t seem to have the option to change which timer is used for the delay functions.  In fact, I couldn’t quite pin down when the use of this header file disappeared from the Arduino builds, but to be honest I didn’t spend ages looking.

The code I’m trying to use needs the use of both timers, and as there are only two timers on the attiny85, hence the clash.  I’m not totally clear why it builds when the delay timer is swapped to use timer1 (as in the older arduino-tiny core), but I guess the code isn’t hanging an ISR of the other timer.

Interestingly in other code by the same author, does build ok, but in that case, even though it is installing an ISR for timer0, it is using a different vector, so it doesn’t seem to clash:

ISR(TIMER0_COMPA_vect)

So whilst you can completely mess up the functioning of the timers in your own sketch, by changing the control registers and so on directly, I haven’t found a way to clear and attach a new ISR to the interrupt.

I need to dig around a bit more now into the internals of the ATtiny timers to see how the code might be modified to support timer 1 instead of timer 0, but that will have to be a job for another day now.

Some possible options might include forgoing the use of ‘setup’ and ‘loop’ in the sketch; integrating it better alongside its use with delay; attempting to port over from triggering on overflow to triggering on compare; or I may end up trying to reverse the timer usage in the sketch (but I read somewhere that the two ATtiny85 timers are quite different, so that might not be possible).   I may end up with a special ‘hacked’ core board definition to re-specify the use of timer1 rather than 0 as per the older library, but that would be a bit of a mess…

Anyway, the upshot of all this is that this took quite a lot of untangling and googling and following dead-ends, so if you know of a definitive resource or document that details the history of ATtiny85 support within Arduino and when this changed, I’d like to hear about it!

Update: In my case it turned out that I was pretty much able to replace the use of the Timer 0 overflow interrupt with the Timer 0 compare A interrupt and get largely the same thing.  I don’t know if the two use of the different timers needs to be swapped though, but as far as I can tell right now, changing interrupt does remove the clash.

So in my case, I did this:

#ifdef ORIGINAL_CODE_
 TIMSK = (1 << TOIE0); // Interrupt on overflow
#else
 // Set compare value to same that would trigger overflow
 // of the 8-bit counter (pretty much)
 OCR0A = 0xff;
 TIMSK = (1 << OCIE0A); // Interrupt on compare with OCR0A
#endif

and then later on, when defining the ISR:

#ifdef ORIGINAL_CODE_
ISR(TIMER0_OVF_vect) {
#else
ISR(TIMER0_COMPA_vect) {
#endif

Of course there may still be other side effects, but I need to dig into the details to see.

Kevin

Permalink 1 Comment

ArduBlockly and the Arduino Nano

January 2, 2016 at 4:33 pm (maker) (, , )

I’ve been wanting to find a scratch style interface for Arduino to see if I could do something simple Arduino and Lego wise for the kids.  We have a CodeBug (which is pretty good for learning basics of programming for LEDs and I/O – maybe the topic of another block post, but see http://codebug.org.uk/ if you are interested) which is programmed using a web-based environment based on Google Blockly.  We’ve also used Scratch, so these were my two starting points.

After some googling, I found ArduBlockly, ArduBlock BlocklyDuinoS4A (Scratch for Arduino) and Snap.  As far as I can see, ArduBlock doesn’t seem to be maintained at the moment, Snap looks like an enhancement on S4A and ArduBlockly looks inspired by BlocklyDuino.

Snap looks particularly interesting and I’ll take a look at that at some point, but I went with ArduBlockly as it has a ‘download and just run all-in-one’ installation.  As far as it goes, this largely worked quite well – the only problem is that at present, it doesn’t support the Arduino Nano, which is what I was hoping to use.

However, seeing as this is basically using a Python web server to serve the Blockly interface to a browser, and then using the Arduino IDE (at least v1.6) directly to interface with the hardware, I had a poke around to see if the Nano could be slotted in.  The answer is yes and no.

The ‘all in one’ nature of the beast means that the Python is compiled into something that just runs, so isn’t editable anymore.  However, if I was happy to install Python and use a browser directly, I could hack it about.

Note: the following will hopefully become redundant at some point as support for the Nano I’m sure will be forthcoming, but it is documented here for my own reference right now.

In order to add the Nano enough for me to start playing, from some googling and searching around on github, there are three files that appear to require editing:

ardublockly/classic/settings.html

In the ‘Arduino Board’ selection form, a new <option> is required whose value is ‘nano’.

ardublocklyserver/compilersettings.py

There is a __Arduino_type array which needs to include

'Nano': 'arduino:avr:nano'

as an option.

blockly/generators/arduino/boards.js

This defines the properties for the different support boards, so an entry for the Nano is required.  This is largely the same as the ‘uno’ entry, but the Nano has two additional analogue pins.  This is unverified, as I’m not an Arduino expert (to use at your own risk), but I believe all that is required is to create an entry as follows:

Blockly.Arduino.Boards.nano = {
  name: 'Arduino Nano',
  description: 'Arduino Nano with ATmega328p board',
  analogPins: Blockly.Arduino.Boards.generateAnalogIo(0, 7),
  digitalPins: Blockly.Arduino.Boards.generateDigitalIo(0, 13).concat(
                   Blockly.Arduino.Boards.generateAnalogIo(0, 7)),
  pwmPins: Blockly.Arduino.Boards.uno.pwmPins,
  serial: Blockly.Arduino.Boards.uno.serial,
  serialPins: Blockly.Arduino.Boards.uno.serialPins,
  serialSpeed: Blockly.Arduino.Boards.uno.serialSpeed,
  spi: Blockly.Arduino.Boards.uno.spi,
  spiPins: Blockly.Arduino.Boards.uno.spiPins,
  spiClockDivide: Blockly.Arduino.Boards.uno.spiClockDivide,
  i2c: Blockly.Arduino.Boards.uno.i2c,
  i2cPins: Blockly.Arduino.Boards.uno.i2cPins,
  i2cSpeed: Blockly.Arduino.Boards.uno.i2cSpeed,
  builtinLed: Blockly.Arduino.Boards.uno.builtinLed,
  interrupt: Blockly.Arduino.Boards.uno.interrupt
};

Then running the ArduBlockly application using the ‘start.py’ script rather than the stand-alone ‘ardublockly_run’ batch file seems to allow me to use it with my Nano.

I was getting ‘Arduino Exit Code: 259’ as an error though, and something somewhere online suggested that the arduino_debug.exe should be used for the diagnostics from the command line, rather than your arduino.exe, so I updated the ArduBlockly preferences to use arduino_debug.exe and now I get a successful build and download.

Aside – I couldn’t get ArduBlockly to work in MS new browser (Edge), so I use it with Chrome, connecting to the local URL generated by the running Python script of http://localhost:8000/ardublockly/

(If I ever get around to getting GitHub going properly and assuming this is verified as the right way to add the board, I’ll submit it back).

I look forward to see how ArduBlockly develops, and do wish to try Snap at some point too (especially as at present, with the above hack for the Nano, it is no longer the simple ‘all in one’ application for installing on a PC that the kids could use).  However, it is early days for ArduBlockly development, and so far the signs are looking pretty good to me!

Kevin

 

Permalink Leave a Comment

icStation 4x4x4 LED Cube Shield for Arduino – Reprise

August 18, 2015 at 9:26 pm (maker) (, , )

I’ve been playing a little more with my icStation 4x4x4 LED Cube Shield (I described the details of the build and my code previously).  First, a little hardware mod.

Eventually I’d like to use this with some kind of network connectivity and most of the add-ons I have utilise the UART on pins 0 and 1, so I wanted to free these up from being used on the shield.  Thankfully this was fairly straight forward – I simply removed the connecting pins from the shield for pins 0 and 1 and re-patched them across to pins 9 and 10.  (I avoided pin 8 as this too is used with one of the radios I might use, the Ciseco SRF modules, in the future)

This means that the pin definitions in my code now look something like this:

int HC595_clockPin=9;   // SH_CP of 74HC595 
int HC595_latchPin=10;  // ST_CP of 74HC595 
int HC595_dataPin=3;    // DS of 74HC595 
int HC595_enablePin=2;  // Not OE of 74HC595
int LED_Pin16= 4;
int LED_Pin17= 5;
int LED_Pin18= 6;
int LED_Pin19= 7;

You can see this simple mod in the pictures below.

icstation4x4x4-nouarthack

The other change I wanted to make was to make the cube more easily programmable, rather than just loading in pre-set patterns, and to make the refreshing of the cube more independent of the main code.

To do the former, I added a few functions to set and clear the appropriate bits in an array that I can simply load into the cube when convenient.

unsigned int display[4];

void setpixel (int x, int y, int z) {
  // z defines the plane
  // within the plane, x + y*4 defines the bit
  display[z] = display[z] | (1<<(x+y*4)); 
}

void clrpixel (int x, int y, int z) {
  display[z] = display[z] & (~(1<<(x+y*4))); 
}

void clrdisplay () {
  display[0] = 0;
  display[1] = 0;
  display[2] = 0;
  display[3] = 0;
}

To improve the scanning of the cube, I decided to use the hardware timer interrupt available on timer 1 in the arduino.  After initially thinking about setting the registers directly, I decided the TimerOne library is actually so simple to use, I may as well just use that – so I did.

To initialise the timer:

// Use Timer1 on the Ardunio to trigger the update scan in the background 
Timer1.initialize(1000);
Timer1.attachInterrupt (ics444_display_scan);

And the scan routine looks like this:

int ics444_scan_count=0;
void ics444_display_scan () {
  if (ics444_scan_count == 0) {
    digitalWrite(LED_Plane[0], HIGH);
    digitalWrite(LED_Plane[1], HIGH);
    digitalWrite(LED_Plane[2], HIGH);
    digitalWrite(LED_Plane[3], HIGH);
    write_74HC595 (HC595_display[0]);
    digitalWrite(LED_Plane[0], LOW);
    ics444_scan_count++;
  }
  else if (ics444_scan_count == 1) {
    digitalWrite(LED_Plane[0], HIGH);
    digitalWrite(LED_Plane[1], HIGH);
    digitalWrite(LED_Plane[2], HIGH);
    digitalWrite(LED_Plane[3], HIGH);
    write_74HC595 (HC595_display[1]);
    digitalWrite(LED_Plane[1], LOW);
    ics444_scan_count++;
  }
  else if (ics444_scan_count == 2) {
    digitalWrite(LED_Plane[0], HIGH);
    digitalWrite(LED_Plane[1], HIGH);
    digitalWrite(LED_Plane[2], HIGH);
    digitalWrite(LED_Plane[3], HIGH);
    write_74HC595 (HC595_display[2]);
    digitalWrite(LED_Plane[2], LOW);
    ics444_scan_count++;
  }
  else {  
    digitalWrite(LED_Plane[0], HIGH);
    digitalWrite(LED_Plane[1], HIGH);
    digitalWrite(LED_Plane[2], HIGH);
    digitalWrite(LED_Plane[3], HIGH);
    write_74HC595 (HC595_display[3]);
    digitalWrite(LED_Plane[3], LOW);
    ics444_scan_count = 0;
  }
}

Note that for each tick of the timer I display one plane then move onto the next one for the next tick. Initially I had it setting each plane in sequence, but then found I needed a short delay between each plane to actually allow the LEDs to illuminate without bleeding into each other, hence splitting it up. I also found that if I don’t pre-set all four planes to HIGH (i.e. turning them off) before selecting the pattern I wanted, I’d also get some bleeding of values across planes, hence the sequence: a) turn all planes off; write the 16 bits to the plane as data; turn on the plane to be illuminated; wait before doing the next plane.

This seems to create a nice scanning persistence of vision effect without having to worry about when to trigger the scanning from the main code.  The last bits of glue are something to update a buffer containing the pattern to display (stored in LED_Plane[0-3] in the above code) and pretty much the same code as before for the actual writing to the registers of the 74HC595.

One gotcha – I set all my icstation4x4x4 code into a separate cpp and header file, so when I tried to #include <TimeOne.h> in my .cpp file, I kept getting:

icstation4x4x4.cpp:1:22: fatal error: TimerOne.h: No such file or directory
 #include <TimerOne.h>

Which was starting to drive me crazy as I could see the library was installed correctly, etc. After some Googling, eventually searching for “Arduino use of libraries from other libraries” or something like that, I found out that the compiler won’t include paths to libraries unless they are included in the main sketch file.  Consequently to use <TimerOne.h> in my .cpp I also need to #include <TimerOne.h> in my main sketch file too.  A quirk of the “C++ but not quite C++” nature of the Arduino IDE I guess.

Full code for my icstation4x4x4 included below.  Note: This is not written to be particularly good code (I don’t use portable definitions for 16-bit values, and there is minimal error checking, etc – this is just my hacking about, not meant for real use anywhere – I might tidy I up one day – maybe).  If you want to do it all properly, I suggest you take a look at the rather fine library described here: https://arduinoplusplus.wordpress.com/2015/08/13/device-independent-control-for-led-cubes/

Kevin.

Main Sketch:

#include <TimerOne.h>
#include "icstation4x4x4.h"

unsigned int display[4];

void setpixel (int x, int y, int z) {
  // z defines the plane
  // within the plane, x + y*4 defines the bit
  display[z] = display[z] | (1<<(x+y*4)); 
}

void clrpixel (int x, int y, int z) {
  display[z] = display[z] & (~(1<<(x+y*4))); 
}

void clrdisplay () {
  display[0] = 0;
  display[1] = 0;
  display[2] = 0;
  display[3] = 0;
}

void setup() {
  // put your setup code here, to run once:
  ics444_setup();
}

int x=0;
int y=0;
int z=0;
void loop() {
  // put your main code here, to run repeatedly:
  clrdisplay();
  int i;
  for (i=0; i<32; i++)
  {
    setpixel (random(4), random(4), random(4));
  }
  ics444_display(&display[0]);
  delay (2000);
}

icstation4x4x4.cpp:

#include <TimerOne.h>
#include "icstation4x4x4.h"

// Note: Original shield was wired to use pins 0-7, plus GND and +5V.
//       This has been re-wired to use pins 9 and 10 instead of 0 and 1
//       in order to free up 0/1 (RX/TX) for use as a serial port and 8 for use
//       with the Ciseco SRF radios (0/1 is the serial connection to the
//       radio and 8 is the radio 'enable' pin).
//
int HC595_clockPin=9;   // SH_CP of 74HC595 
int HC595_latchPin=10;  // ST_CP of 74HC595 
int HC595_dataPin=3;    // DS of 74HC595 
int HC595_enablePin=2;  // Not OE of 74HC595
int LED_Pin16= 4;
int LED_Pin17= 5;
int LED_Pin18= 6;
int LED_Pin19= 7;
int LED_Plane[] = {LED_Pin16, LED_Pin17, LED_Pin18, LED_Pin19};
unsigned int HC595_display[4];

// Each line (8 bytes) is an entire cube, with two consecutive bytes per plane of LEDS,
// and 16 LEDS per plane. LEDs are encoded in the following order:
//    Lowest plane byte 1, lowest plane byte 2, second lowest plane 1, then 2,
//    second from top plane 1, then 2, highest plane 1, highest plane 2.
//
//    Each plane is encoded looking at the Arduino oriented with the USB/power
//    designated by 'south' by started 'north west' as follows:
//        D0    D1    D2    D3
//        D4    D5    D6    D7
//        D8    D9    D10   D11
//        D12   D13   D14   D15
//
//        D16   D17   D18   D19
//          (USB)      (Power)
//    With D16 being the lowest plane, through to D19 being the highest plane
//    Of course, if you wire the planes up differently, that is up to you!
//
//    Each two bytes of the pattern are therefore:
//        B00000000, B00000000 -> D0-7, D8-15
//    with D0 = msb of the first value, D7 being the lsb of the first value,
//    and  D8 = msb of the second value, D15 being the lsb of the second value.
//
//    So the entire pattern is:
//    B10010000,B00001001,B00000000,B00000000,B00000000,B00000000,B10010000,B00001001,
//     |      |  |     ||                                          |      |  |     ||
//     |      |  |     |\ D15 bottom plane                         |      |  |     |\ D15 top plane
//     |      |  |     \ D14 bottom plane                          |      |  |     \ D14 top plane
//     |      |  \ D8 bottom plane                                 |      |  \ D8 top plane
//     |      \ D7 bottom plane                                    |      \ D7 top plane
//     \ D0 bottom plane                                           \ D0 top plane
//
// Comment following in or out to switch patterns in or out
//#define SWAP   1
//#define SNAKE  1
//#define BURST  1
//#define SPIRAL 1
//#define ALT    1
unsigned char pattern[] = {
  B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,
#ifdef SWAP
  B10010000,B00001001,B00000000,B00000000,B00000000,B00000000,B10010000,B00001001,
  B00000000,B00000000,B10010000,B00001001,B10010000,B00001001,B00000000,B00000000,
  B00000000,B00000000,B01100000,B00000110,B01100000,B00000110,B00000000,B00000000,
  B01100000,B00000110,B00000000,B00000000,B00000000,B00000000,B01100000,B00000110,
  B00001001,B10010000,B00000000,B00000000,B00000000,B00000000,B00001001,B10010000,
  B00000000,B00000000,B00001001,B10010000,B00001001,B10010000,B00000000,B00000000,
  B00000000,B00000000,B00000110,B01100000,B00000110,B01100000,B00000000,B00000000,
  B00000110,B01100000,B00000000,B00000000,B00000000,B00000000,B00000110,B01100000,
#endif
#ifdef SNAKE
  B11001100,B00000000,B11001100,B00000000,B00000000,B00000000,B00000000,B00000000,
  B00000000,B00000000,B11001100,B00000000,B11001100,B00000000,B00000000,B00000000,
  B00000000,B00000000,B00000000,B00000000,B11001100,B00000000,B11001100,B00000000,
  B00000000,B00000000,B00000000,B00000000,B00001100,B11000000,B00001100,B11000000,
  B00000000,B00000000,B00000000,B00000000,B00000000,B11001100,B00000000,B11001100,
  B00000000,B00000000,B00000000,B00000000,B00000000,B01100110,B00000000,B01100110,
  B00000000,B00000000,B00000000,B00000000,B00000000,B00110011,B00000000,B00110011,
  B00000000,B00000000,B00000000,B00110011,B00000000,B00110011,B00000000,B00000000,
  B00000000,B00110011,B00000000,B00110011,B00000000,B00000000,B00000000,B00000000,
  B00000011,B00110000,B00000011,B00110000,B00000000,B00000000,B00000000,B00000000,
  B00110011,B00000000,B00110011,B00000000,B00000000,B00000000,B00000000,B00000000,
  B01100110,B00000000,B01100110,B00000000,B00000000,B00000000,B00000000,B00000000,
#endif
#ifdef BURST
  B00000000,B00000000,B00000110,B01100000,B00000110,B01100000,B00000000,B00000000,
  B00000110,B01100000,B01101001,B10010110,B01101001,B10010110,B00000110,B01100000,
  B01101001,B10010110,B10010000,B00001001,B10010000,B00001001,B01101001,B10010110,
  B10010000,B00001001,B00000000,B00000000,B00000000,B00000000,B10010000,B00001001,
  B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,
#endif
#ifdef SPIRAL
  B11001100,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,
  B01100110,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,
  B00110011,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,
  B00000011,B00110000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,
  B00000000,B00110011,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,
  B00000000,B01100110,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,
  B00000000,B11001100,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,
  B00001100,B11000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,
  B11001100,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,
  B00000000,B00000000,B11001100,B00000000,B00000000,B00000000,B00000000,B00000000,
  B00000000,B00000000,B01100110,B00000000,B00000000,B00000000,B00000000,B00000000,
  B00000000,B00000000,B00110011,B00000000,B00000000,B00000000,B00000000,B00000000,
  B00000000,B00000000,B00000011,B00110000,B00000000,B00000000,B00000000,B00000000,
  B00000000,B00000000,B00000000,B00110011,B00000000,B00000000,B00000000,B00000000,
  B00000000,B00000000,B00000000,B01100110,B00000000,B00000000,B00000000,B00000000,
  B00000000,B00000000,B00000000,B11001100,B00000000,B00000000,B00000000,B00000000,
  B00000000,B00000000,B00001100,B11000000,B00000000,B00000000,B00000000,B00000000,
  B00000000,B00000000,B11001100,B00000000,B00000000,B00000000,B00000000,B00000000,
  B00000000,B00000000,B00000000,B00000000,B11001100,B00000000,B00000000,B00000000,
  B00000000,B00000000,B00000000,B00000000,B01100110,B00000000,B00000000,B00000000,
  B00000000,B00000000,B00000000,B00000000,B00110011,B00000000,B00000000,B00000000,
  B00000000,B00000000,B00000000,B00000000,B00000011,B00110000,B00000000,B00000000,
  B00000000,B00000000,B00000000,B00000000,B00000000,B00110011,B00000000,B00000000,
  B00000000,B00000000,B00000000,B00000000,B00000000,B01100110,B00000000,B00000000,
  B00000000,B00000000,B00000000,B00000000,B00000000,B11001100,B00000000,B00000000,
  B00000000,B00000000,B00000000,B00000000,B00001100,B11000000,B00000000,B00000000,
  B00000000,B00000000,B00000000,B00000000,B11001100,B00000000,B00000000,B00000000,
  B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B11001100,B00000000,
  B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B01100110,B00000000,
  B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00110011,B00000000,
  B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000011,B00110000,
  B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00110011,
  B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B01100110,
  B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B11001100,
  B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B00001100,B11000000,
  B00000000,B00000000,B00000000,B00000000,B00000000,B00000000,B11001100,B00000000,
#endif
#ifdef ALT
  B11111001,B10011111,B10010000,B00001001,B10010000,B00001001,B11111001,B10011111,
  B00000110,B01100000,B01101001,B10010110,B01101001,B10010110,B00000110,B01100000,
  B00000000,B00000000,B00000110,B01100000,B00000110,B01100000,B00000000,B00000000,
  B00000110,B01100000,B01101001,B10010110,B01101001,B10010110,B00000110,B01100000,
#endif
};
int patternNumber=0;
int numPatterns=sizeof(pattern)/8;
int tickCount=0;
int tickCountMax=50;      // How many times to loop before changing the pattern
unsigned int currentPattern[4];

/*
  Protocol for sending the data to the hc595 is as follows:
   (see: http://www.arduino.cc/en/Tutorial/ShiftOut)
   
   "when the clock pin goes from low to high, the shift register
    reads the state of the data pin ... when the latch pin goes
    from low to high the sent data gets moved from the shift
    registers ... to the output pins"
   
   As we have two HC595s chained together, we use a 16 bit input value
*/
void write_74HC595 (unsigned int hc595value) { 
   digitalWrite(HC595_latchPin, LOW);   // ensures LEDs don't light whilst changing values
//   digitalWrite(HC595_enablePin, HIGH); // OE is negative logic
   
   // Shift each 8 bit value in sequence - the two chained HC595s automatically grab
   // the right bits - the first 8 to the first chip, second 8 to the second chip
   shiftOut(HC595_dataPin, HC595_clockPin, LSBFIRST, hc595value);  
   shiftOut(HC595_dataPin, HC595_clockPin, LSBFIRST, (hc595value >> 8));
   
   digitalWrite(HC595_latchPin, HIGH);  // data transferred from shift register to outputs when latch goes LOW->HIGH
//   digitalWrite(HC595_enablePin, LOW);  // re-enable (negative logic again)
}

/*
  Inputs: Array of 4 16-bit integers - one for each plane
*/
void ics444_display (unsigned int *pPattern) {
    HC595_display[0]=pPattern[0];
    HC595_display[1]=pPattern[1];
    HC595_display[2]=pPattern[2];
    HC595_display[3]=pPattern[3];
}

int ics444_scan_count=0;
void ics444_display_scan () {
  if (ics444_scan_count == 0) {
    digitalWrite(LED_Plane[0], HIGH);
    digitalWrite(LED_Plane[1], HIGH);
    digitalWrite(LED_Plane[2], HIGH);
    digitalWrite(LED_Plane[3], HIGH);
    write_74HC595 (HC595_display[0]);
    digitalWrite(LED_Plane[0], LOW);
    ics444_scan_count++;
  }
  else if (ics444_scan_count == 1) {
    digitalWrite(LED_Plane[0], HIGH);
    digitalWrite(LED_Plane[1], HIGH);
    digitalWrite(LED_Plane[2], HIGH);
    digitalWrite(LED_Plane[3], HIGH);
    write_74HC595 (HC595_display[1]);
    digitalWrite(LED_Plane[1], LOW);
    ics444_scan_count++;
  }
  else if (ics444_scan_count == 2) {
    digitalWrite(LED_Plane[0], HIGH);
    digitalWrite(LED_Plane[1], HIGH);
    digitalWrite(LED_Plane[2], HIGH);
    digitalWrite(LED_Plane[3], HIGH);
    write_74HC595 (HC595_display[2]);
    digitalWrite(LED_Plane[2], LOW);
    ics444_scan_count++;
  }
  else {  
    digitalWrite(LED_Plane[0], HIGH);
    digitalWrite(LED_Plane[1], HIGH);
    digitalWrite(LED_Plane[2], HIGH);
    digitalWrite(LED_Plane[3], HIGH);
    write_74HC595 (HC595_display[3]);
    digitalWrite(LED_Plane[3], LOW);
    ics444_scan_count = 0;
  }
}

/*
  Inputs: Array of 8 8-bit integers - two for each plane
*/
void ics444_displayBytes (byte *pPattern)
{
    unsigned int pattern[4];
    pattern[0] = pPattern[0]*256 + pPattern[1];
    pattern[1] = pPattern[2]*256 + pPattern[3];
    pattern[2] = pPattern[4]*256 + pPattern[5];
    pattern[3] = pPattern[6]*256 + pPattern[7];
    ics444_display (&pattern[0]);    
}

void ics444_setup() {
  // put your setup code here, to run once:
  pinMode( HC595_latchPin,  OUTPUT );
  pinMode( HC595_clockPin,  OUTPUT );
  pinMode( HC595_dataPin,   OUTPUT );
  pinMode( HC595_enablePin, OUTPUT );
  
  pinMode( LED_Pin16, OUTPUT );
  pinMode( LED_Pin17, OUTPUT );
  pinMode( LED_Pin18, OUTPUT );
  pinMode( LED_Pin19, OUTPUT );
  
  digitalWrite(LED_Pin16,HIGH);
  digitalWrite(LED_Pin17,HIGH);
  digitalWrite(LED_Pin18,HIGH);
  digitalWrite(LED_Pin19,HIGH);
//  digitalWrite(HC595_enablePin, LOW);  // Enable Not OE (negative logic)

  HC595_display[0]=0;
  HC595_display[1]=0;
  HC595_display[2]=0;
  HC595_display[3]=0;

  // Use Timer1 on the Ardunio to trigger the update scan in the background 
  Timer1.initialize(1000);
  Timer1.attachInterrupt (ics444_display_scan);

  patternNumber=0;
  tickCount = tickCountMax;
}

// To be called from the loop()
void ics444_demo ()
{
  int i;
  // only update it every tick otherwise just display as is
  tickCount--;
  if (tickCount <= 0)
  {
    tickCount = tickCountMax;
    for (i=0; i<4; i++)
    {
      currentPattern[i] = pattern[i*2 + patternNumber*8] * 256 + pattern[i*2 + 1 + patternNumber*8];
    }
    patternNumber++;
    if (patternNumber >= numPatterns)
    {
      patternNumber = 0;
    }
  }
  ics444_display(&currentPattern[0]);
}

icstation4x4x4.h:

#ifndef ICS444_H
#define ICS444_H
#include <arduino.h>

// To be called from the setup() routine
void ics444_setup(void);

// Perform one scan of the cube to display a complete pattern
//    Inputs: Four 16 bit integers, one for each plane of the cube
//    Order: Bottom plane to top plane, D0 to D15
void ics444_display (unsigned int *pPattern);

// As above, but takes the input as eight 8 bit values instead
// that is two per plane (ordered bottom to top once again)
void ics444_displayBytes (byte *pPattern);

// Displays the built-in patterns
// To be called from the loop() routine
// NB: Need to make sure the patterns are not commented out
//        in icstation4x4x4.cpp otherwise, none will be included
void ics444_demo (void);
#endif

Permalink 5 Comments

Cheap Max7219 Chainable LED Matrix

August 13, 2015 at 10:53 pm (maker) (, , , , )

I can’t resist a cheap LED matrix, so when I stumbled across these 8×8 LED matrix displays with a Max7219 driver LED in this chainable form-factor for, get this, less than £1.50 each from electrodragon.com … well, I had to give them a go.  It is a relatively simple circuit board to build, so there are very minimal instructions, but there are still a couple of gotchas that might catch out a beginner, so I’ve put together these notes whilst putting them together.  By the way, I ordered 9 so I could eventually form a 24×24 LED square (3×3 of the matrices).

2015-08-07 13.06.582015-08-07 13.07.22

I started with the headers, then the discrete components, finally the chip.  The only thing to note is the polarity of the electrolytic capacitor (of course – look for the + on the circuit board) and the orientation of the chip itself.  Also note that ‘pin 1’ of the LED matrix sockets are indicated by a square pad in the top right of the circuit board (as seen from the top, with the writing the right way up).  It is worth fiddling with the electrolytic prior to soldering to try to ensure it doesn’t poke out over the top edge of the circuit board – although if it does, if physically mounting boards next to each other, it will quite happily overlap into the next board.

The design suggests that all the header pins face upwards and that the jumpers are used on the top of the board to chain them together.  however, I didn’t really want to have to take off the LED matrix every time I wanted to change how it was linked, so I opted to solder the connecting header pins to the underside of the board as shown.  It also gets around the issue they describe on the product webpage about the LED matrix not really fitting snugly on the board.  Mine fits nice and tight.

2015-08-07 17.44.28-sm

So all that remains is to add the LED matrix.  As I said, pin 1 should be indicated on the matrix itself and is indicated on the circuit board by the square pad near the electrolytic capacitor.

In terms of making the thing work, it is relatively simple to connect up:

  • CLK – D2
  • LD – D3
  • DIN – D4
  • VCC – VCC
  • GND – GND

Of course when chaining with jumpers DOUT goes to the next LED DIN.  The other pins pair up.

There is a lot of arduino code for these types of driver chips – start here – http://playground.arduino.cc/Main/LEDMatrix.

I used the code from here to test my setup – http://playground.arduino.cc/LEDMatrix/Max7219 – as written this assumes the same pinouts as I describe above (i.e. CLK, LD, DIN on digital pins 2, 3 and 4).

You just need to set the number of chained displays at the top:

int maxInUse = 9;

(in my case) and get to work playing.  The routines in the library provide a simple interface to setting rows on a single or all of the chained displays.  maxSingle is meant for when there is just one display.  maxAll displays the same value on all displays in the chain.  maxOne will target a specific display (starting with display number 1 up to your last – 9 in my case).

2015-08-08 16.02.16-sm

As you can perhaps see, this is using an Ardunio nano.  With 9 boards cascaded, getting the PC to recognise the nano was plugged in was sometimes a problem – it often gave me a ‘there is a problem with your USB device’ error on Windows 7.  It was fine with lesser numbers of matrices, so I guess there is a power issue with the nano struggling with the USB setup and initialising all 9 LED matrices at the same time.  Temporarily disconnecting VCC from the LEDs when plugging in the USB seems to solve the issue for me.

As I eventually want to be setting an entire row of LEDs in a larger grid, the maxOne function is a little wasteful as it has to shunt null values to all of the LED displays you are not targeting – so calling it 9 times means writing 81 bytes out across the DIN pin just to actually set 9 bytes.  Consequently it is possible to optimise it a little if you want to write an entire row to all displays in the same transaction.

Of course, if you refer back to the LedMatrix page, there are many other libraries that will do most of this for you, including Marco’s very complete library for scrolling text displays – http://parola.codeplex.com/ – but I quite like being able to see what the low-level code is actually doing to make things work.

I’ve therefore added a maxRow function as follows:

// Note: Sloppy code warning!
// There is no checking here that *col is an array of
// the correct length - i.e. maxInUse
//
// It should be defined and used as follows:
//    byte row[maxInUse];
//    // fill each byte of row with your data - row[0], row[1], row[2], etc.
//    // using one byte for each matrix in sequence
//    maxRow (1, &row[0]);
//
void maxRow (byte reg, byte *col) {
  int c=0;
  digitalWrite(load,LOW);
  for (c=maxInUse; c>=1; c--) {
    putByte(reg);
    putByte(col[c-1]);
  }
  digitalWrite(load,LOW);
  digitalWrite(load,HIGH);
}

But I haven’t mentioned the absolutely best feature of these little boards yet.  And that is that they are almost exactly the same dimension as a 4-stud Lego brick.  This means it was trivial to make a simple enclosure to hold my 3×3 grid and the nano.

2015-08-10 21.12.11 2015-08-10 21.12.04

I now have a really cool game-of-life running on my 24×24 LED grid.  At this price, I have another 8 on order so I can take it to a 4×4 grid (with one spare).

Kevin

Permalink Leave a Comment

Next page »