Dangerous Prototypes

Update May 17 2014:
The SmartMatrix Shield is available for purchase, and is shipping now.  Click on the "shop" link in the header of SmartMatrix Docs (http://http://docs.pixelmatix.com/SmartMatrix/) (ships from China) or visit Adafruit (http://https://www.adafruit.com/products/1902) to purchase.

All source and the hardware design is up on GitHub, view the link at SmartMatrix Docs.  The board file for the shield is up as an OSH Park shared project, use google to find it.

-----------------

I’m working on a controller board for the 16x32 and 32x32 RGB LED Matrix Displays you may have seen at Adafruit and Sparkfun. 
http://www.adafruit.com/products/420 (http://www.adafruit.com/products/420)
https://www.sparkfun.com/products/12583 (https://www.sparkfun.com/products/12583)
http://www.adafruit.com/products/1484 (http://www.adafruit.com/products/1484)
https://www.sparkfun.com/products/12584 (https://www.sparkfun.com/products/12584)

After seeing Paul’s post on driving WS2811 LED strips with DMA on the Teensy 3.0 (http://www.pjrc.com/teensy/td_libs_OctoWS2811.html (http://www.pjrc.com/teensy/td_libs_OctoWS2811.html)), I looked into driving the Matrix displays with DMA and now have the basics of a driver working.  The Arduino really struggles to drive these displays, but the Teensy 3.0 with DMA is able to update them at a high frame rate with CPU left over to do other stuff.  I’m working on releasing an open source library for driving the displays, and want to release a open source breakout board as well.

The breakout board design is pretty simple.  It’s physically similar to the nootropic design Arduino-based kit http://nootropicdesign.com/matrixbackpack/index.html (http://nootropicdesign.com/matrixbackpack/index.html).  It will connect a Teensy 3.0 or 3.1 to either a 16x32 or 32x32 Matrix, supply power, and bring the unused pins of the Teensy out to headers.  I tried to leave enough useful IO free so the Teensy can connect to most external components.

Here’s what the board looks like so far:
[attachment=3]

Here’s a picture of the 10 free GPIO on the Teensy showing what they can be used for:
[attachment=2](picture from http://www.pjrc.com/teensy/pinout.html (http://www.pjrc.com/teensy/pinout.html))

Here’s crude pictures of how the board will mount to the displays:
[attachment=0][attachment=1](Matrix pictures from Sparkfun)

The board can also be connected to the display using male headers and a ribbon cable if that makes more sense for a particular project.  I didn’t add any mounting holes to the board as they are not practical when the board is installed directly on the display.  Let me know if you think mounting holes are a good idea for the ribbon cable connection option, and I can increase the board size a bit and add some.

Edit - Power supply options are explained clearly in a followup message below

Please let me know if you have any feedback on the board design before I route the board and order the first prototypes.  I’m hoping to have the library and tested board design ready to publish within a month, hopefully sooner.

---

I think I found a mistake in the Teensy schematic, and if Paul confirms I'm right, there's at least an option to connect up both power sources to the Teensy without losing the USB fuse.  I'll post back after I find out more.

Posted on the blog, didn't realise this was in the forum.  The Teensy3.1 is out now, which I would think would be handy here.

[quote author="Sleepwalker3"]Posted on the blog, didn't realise this was in the forum.  The Teensy3.1 is out now, which I would think would be handy here.[/quote]

Yes, I started the project just before the Teensy 3.1 came out.  I'll make sure the library and breakout board works with both Teensy 3.0 and 3.1.

Reset Pin is different, but most other things are compatible.

Nice work.
I created an implementation that extends the Teensy DMA method and does not use any software/interrupts beyond setting it up initially. 100% of the work is handled in the hardware by timers and DMA, outputting a buffer to the ports. This saves you from the timing critical aspects of the Teensy implementation and allows you to simply write to a framebuffer and have the framebuffer flush to DMA in the background.

I have a demo of the library on an STM32F3-Discovery board with ChibiOS on github - http://https://github.com/omriiluz/WS2812B-LED-Driver-ChibiOS
take a look at LEDDriver.c, should be easy to port to other architectures than the stm32.

I hope to find time and post on my blog a detailed description of how it works, you can look at the code, it's pretty self explanatory.
I'm happy to answer any questions.

[quote author="MrOI"]I created an implementation that extends the Teensy DMA method and does not use any software/interrupts beyond setting it up initially.[/quote]

I see you're using the STM32 processors.  I'd like to use them in a future project.  They have some inexpensive models with USB, and DMA is fairly common on the lower variants as well.  I'll bookmark your project for reference when I pick up my STM32 dev board again.

After thinking about the power supply options some more, I thought I should just simplify it:
1. Default: Teensy is powered from USB
2. Option: Teensy powered from External Power.  Requires cutting a trace on the Teensy to disconnect USB power.

I did some brief testing today, switching the display between driving no LEDs, and all LEDs on a row at full white.  I’m powering my display with a 5V 4A power supply, and the voltage was dropping by up to 700mV when driving white.  I don’t want that dramatic ripple going to the microcontroller's regulator, so I'm adding a cap to Vin, and a diode to separate Vin from the external 5V supply.

Here's what the board looks like after adding those items.  I'm going to route and order prototypes from OSH Park tomorrow hopefully.

[attachment=0]

---

It's been a week, I should probably post an update. 

I ordered boards from OSH Park last Saturday and they are due to arrive at the end of the month.

I've been working on the firmware, mostly behind the scenes stuff like tweaking how DMA is used to refresh the display so I can store data in a more efficient way.  Most of my work has been spending hours to get all the settings right across 4 DMA channels with the result of no visible change on the display, so not the most exciting work.

Tonight I finished a milestone which was updating the buffers and refreshing the display completely automatically using ISRs, without the user's loop() code needing to call anything.  Updating the buffers is done inside a software interrupt at the lowest priority so it won't interfere with any other interrupts.  With that done, I can finally spend all my time in the user loop drawing something to the display.  Here's a quick demo of drawing random rectangles to the screen, with a scrolling text overlay (scrolling text is handled in the background by the library).

https://www.dropbox.com/s/11bm3jpgcdrel ... .01.04.mov (https://www.dropbox.com/s/11bm3jpgcdrel6y/2014-01-24%2001.01.04.mov)

As usual with these things, it looks much better in real life than on camera.

Hi EmbeddedCreations

I was planning on doing this exact thing for a gift, do you have a git hub of your library? I am still waiting on my matrix to arrive but wanted to sink my teeth into some code before they show up.

Quick update for now, and I'll post more later.  I received boards from OSH Park last week, and they were quite functional, but I made a few tweaks, and just ordered what I expect will be the final version.

@Mika571: I don't have any code ready to share right now, and probably won't put anything on github until my kit is ready for ordering.  I'm looking for a limited number of people willing to beta test early code, email me (you can figure out my email address from my signature) if you're interested.

Here are some pictures of the first prototypes, showing different connector options:
Female header vs polarized male header and IDC cable
4-pin molex vs terminal block for power
Teensy plugged directly into board, vs adding female headers so the Teensy can be removed

[attachment=4]
[attachment=3]
[attachment=2]
[attachment=1]
I’m not the biggest fan of using the female header to attach directly to the display.  The board sticks out about 1.5cm above the display frame, and the female connector is significantly smaller than the polarized connector housing on the display.  It’s quite easy to misalign the connectors and plug the board in wrong.  There’s no easy way to secure the board to the display, though the connector does grip quite well.

[attachment=0]
The board looks significantly better with the Teensy soldered directly, instead of with the female headers, but I want to keep the option for people who want to remove their $20 Teensy board to use with another project.  I plan to ship the kit with connectors for all the above options.

I made some revisions to the board, significant ones are listed below:
- Replaced 3.5mm terminal block with 5.0mm terminal block that can accept larger gauge wire that may be required depending on the display power cable
- Adjusted shrouded header to fit properly on the board
- Added 3.0mm mounting hole to corner of board
- Removed capacitor - testing showed it wasn’t necessary to provide a clean power supply to the Teensy

This hopefully final version is due back from OSH Park the week of the 17th, but they might be early again.  I’m going to finish up the library functionality in the meantime, and will post more on that in a week.

---

The firmware is still far from done, though I made good progress in the last week.  I rewrote the code that does the scrolling text layer above the graphics layer to be much more readable and more efficient.  I wrote graphics functions that have a similar interface and feature set to the Adafruit Graphics library, doing everything except for the the setCursor() and print() support which I'll come back to later.  I tried running code on the Teensy 3.1 vs the 3.0 I've been developing on, and it worked without any issues.  I received a 32x32 display, and while my code does work after changing a couple definitions, there's an occasional flicker I need to track down.

The boards from OSH Park haven't shipped early like I was hoping they might.  If they don't ship tomorrow it will be a longer wait than I thought as Monday is a holiday in the US.  I have plenty to do on the firmware in the meantime.

Great work! Do you achieve 24bit color on the 32*32 panel?

My 32*32 panel is on its way, and I am really looking forward to trying your library.

Yes, my code was doing 24-bit color at 60Hz on the 32x32, with the occasional flicker.  I'm sure it's something I can fix.  I'm far from maxing out the RAM and CPU.

That's really awesome. The adafruit matrix library has just 12bit and even the FPGA approaches don't achieve 24bit. Great that a Teensy can beat that :)

Yeah, I've been really impressed by the Teensy 3, and the Freescale Kinetis family of CPUs after starting this project.  I'm going to keep using them in future projects for sure.

Hi Louis,

Great project! I'm very interested in following the progress on this one :)

I bought a 32x32 matrix and a 32x16 matrix that I took delivery of last week. I planned to use two Sparkfun ("Arduino") Pro Micro boards but found out the hard way that they are not suitable with the Adafruit library. I then switched to a Arduino Nano I had laying around but experienced strange problems with that one too (I later found out that I was maxing out on memory). I ended up using a Mega but can visually see the redrawing on the unbuffered plasma demo and it is definately not a speed demon...

I plan to use the 32x32 in a picture frame and display pixel art (and pixel art animations) but I'm slowly admitting to myself that using an Arduino might be to optimistic (at least with my lack of low level coding experience).

As an alternative I started looking into using the Teensy 3.1 I received a couple of weeks ago. And I'm really exited to read up on your project :)

I understand from the thread that you are planning to sell this as a kit. Are you able to estimate a sales price and would it be made available for shipping to Europe?

- Are you planning on publishing the PCB in the shared projects area on OSHPARK? I think that would be great.
- Will the library support chaining together several matrixes?
- Do you plan to add functions for loading color bitmaps and animations (e.g. GIFs) in your library?
- I think it would be great to add a micro SD card reader on the PCB.
- Would it make sense to make a 12Vin version of the board? The reason I ask is that it's much easier to purchase cheap 12V 2A power adapters than 5V 4A power adapters.

I'm very interested in following the progress on this one :)

Thanks for following!

I plan to use the 32x32 in a picture frame and display pixel art (and pixel art animations)

Sounds like a cool project.  I'm interested to see how pixel art looks at 24-bit color on the display.  Have you seen this on Kickstarter?  You could get some inspiration from that project:
https://www.kickstarter.com/projects/99 ... el-led-art (https://www.kickstarter.com/projects/996412530/pixel-led-art)

Are you able to estimate a sales price and would it be made available for shipping to Europe?

I don't have all the costs added up for packaging and shipping, so I can't set a price yet.  I'll be shipping worldwide.

Are you planning on publishing the PCB in the shared projects area on OSHPARK? I think that would be great.

Yes, I'll share the board on OSH Park after I'm ready to ship kits to customers.

Will the library support chaining together several matrixes?

There's just barely enough time to shift 32 pixels worth of data out to the display when outputting the smallest (1/256th) time division of 24-bit color.  Chaining multiple displays from the same controller board would require reducing the color depth at a minimum.  Driving multiple displays at 12-bit or 18-bit color is a possibility, but I haven't looked into it.

I'd like to add the ability for multiple displays to talk to each other over I2C (which is why I added the I2C pull-up resistors on the board), so they can sync what they're drawing to expand the display beyond just one matrix.  I'll look into this idea more for future revisions of the library.

Do you plan to add functions for loading color bitmaps and animations (e.g. GIFs) in your library?

When the library ships, it will support mono bitmaps (same as the Adafruit library).  I'll add support for full color bitmaps in a future release, but need to figure out the best way to store them and add them to a sketch.  Animations would follow after full color bitmaps. 

GIFs use LZW compression, which requires around 8-16kB RAM to decompress.  There's enough free RAM on the Teensy 3.1 to potentially do the decompression, but it might be significant work to port a LZW library to the Teensy 3.1.

I think it would be great to add a micro SD card reader on the PCB

There's an SPI port available on the board, and the Teensy 3.x has an SD card library, so adding a SD card is a good idea.  That's a good place to store bitmaps or animations.  The board features are locked down so it won't be a part of this kit, but there's probably an easy way to wire up an adapter.  I'd love to discuss this and the GIF/animation support more.

Would it make sense to make a 12Vin version of the board? The reason I ask is that it's much easier to purchase cheap 12V 2A power adapters than 5V 4A power adapters.

I wanted to keep this board as simple to assemble, and as low cost as possible, so adding a regulator that supports 4A wasn't a good fit.  Adafruit has a 5V 4A adapter for $15, which seems like a reasonable price to me.
http://www.adafruit.com/products/1466 (http://www.adafruit.com/products/1466)

Thanks for the quick reply!

Sounds like a cool project.  I'm interested to see how pixel art looks at 24-bit color on the display.  Have you seen this on Kickstarter?  You could get some inspiration from that project:

I looked into his V1 last year and V2 a couple of days ago. I love what he's been able to come up with but the pricing is sadly out of the range I'm comfortable spending on a pixel art frame. I believe I'm under $55 (delivered) for my 32x32 matrix, Teensy 3.1, SD card reader, 12V A adapter and step down converter (=inside wife approval range ;)).

Another great Kickstarter is the Game Frame (sadly I'm not allowed to include the URL due to being a new user on this forum). You should look into it :)

I don't have all the costs added up for packaging and shipping, so I can't set a price yet.  I'll be shipping worldwide.

Thanks for the info. I'll be looking out for it then :)

Yes, I'll share the board on OSH Park after I'm ready to ship kits to customers.

Great!

There's just barely enough time to shift 32 pixels worth of data out to the display when outputting the smallest (1/256th) time division of 24-bit color.  Chaining multiple displays from the same controller board would require reducing the color depth at a minimum.  Driving multiple displays at 12-bit or 18-bit color is a possibility, but I haven't looked into it.

LOL. I knew I was pushing it when I asked for it ;) But it would be great with the possibility even with reduced color depth/refresh rate.

I'd like to add the ability for multiple displays to talk to each other over I2C (which is why I added the I2C pull-up resistors on the board), so they can sync what they're drawing to expand the display beyond just one matrix.  I'll look into this idea more for future revisions of the library.

I2C chaining is definately a workaround to the problem.

When the library ships, it will support mono bitmaps (same as the Adafruit library).  I'll add support for full color bitmaps in a future release, but need to figure out the best way to store them and add them to a sketch.  Animations would follow after full color bitmaps. 
 
GIFs use LZW compression, which requires around 8-16kB RAM to decompress.  There's enough free RAM on the Teensy 3.1 to potentially do the decompression, but it might be significant work to port a LZW library to the Teensy 3.1.

I'm working on a Processing 2.0 script for converting GIF/PNG/JPG to a text file with the "raw" uint8_t based values used in the Adafruit Matrix buffer for "fast" loading of pixel art graphics. I'm using parts of the code from the drawPixel function but I need to look into some of the language differences between Arduino and Processing for the more advanced bit processing features in the Adafruit code that I'm unfamiliar with (my programming skills are rusty. It was more than 15 years since I had programmed C/C++ when I got into Arduino last year).

There's an SPI port available on the board, and the Teensy 3.x has an SD card library, so adding a SD card is a good idea.  That's a good place to store bitmaps or animations.  The board features are locked down so it won't be a part of this kit, but there's probably an easy way to wire up an adapter.  I'd love to discuss this and the GIF/animation support more.

Bitmaps/animation storage was my reasoning as well :) It should be really easy to hook up a SD card reader, but adding the needed hardware to the PCB in a later revision would not add a lot of complexity/cost and would add flexibility and look tidier.

A often used way to "fake" support for (GIF based) bitmap animations is to save each frames as separate bitmap files and include information about the frame rate used in the (GIF) animation. But it would be great if the Teensy has enough grunt to pull it of from the original GIF without any pre-conversion.

[code]I wanted to keep this board as simple to assemble, and as low cost as possible, so adding a regulator that supports 4A wasn't a good fit.  Adafruit has a 5V 4A adapter for $15, which seems like a reasonable price to me.[/quote]
That's fully understandable. 5V 4A adapters are not expensive. If one wants to use a 12v adapter a separate step down converter is both cheap and small (and I have one laying around waiting to be dropped into my build).

I love what he's been able to come up with but the pricing is sadly out of the range I'm comfortable spending on a pixel art frame. I believe I'm under $55 (delivered) for my 32x32 matrix, Teensy 3.1, SD card reader, 12V A adapter and step down converter

That's a great price, you must have a good source for the matrix display. Even at Sparkfun (cheaper displays than Adafruit), you couldn't get a display plus Teensy 3.1 for $55 before shipping.

Another great Kickstarter is the Game Frame

Cool, that's new to me.  I like the square pixels.  I don't like the cost.

Driving multiple displays at 12-bit or 18-bit color is a possibility, but I haven't looked into it.

But it would be great with the possibility even with reduced color depth/refresh rate.

I'll keep that in mind for future releases of the library.

I'm working on a Processing 2.0 script for converting GIF/PNG/JPG to a text file with the "raw" uint8_t based values used in the Adafruit Matrix buffer for "fast" loading of pixel art graphics.

Do you intend to compile these into a sketch, or send them via serial so the graphics can be changed without recompiling? 

I think Adafruit's library is using 5-6-5 color, so you have to do some shifting and masking to convert.  I'm using 3 bytes per pixel, one byte per color, so it should be easy to draw from an array of uint8_t RGB values.

typedef struct rgb24 {
  uint8_t red;
  uint8_t green;
  uint8_t blue;
} rgb24;

void drawPixel(int16_t x, int16_t y, rgb24 color);

adding the needed hardware to the PCB in a later revision would not add a lot of complexity/cost and would add flexibility and look tidier.

I'll keep this in mind for when I start work on a new version of the board (well after I ship the kit and library)

That's fully understandable. 5V 4A adapters are not expensive. If one wants to use a 12v adapter a separate step down converter is both cheap and small (and I have one laying around waiting to be dropped into my build)

Do you have a link to an example?  I did some searching and didn't find a small cheap step-down converter that can handle 4A output.

That's a great price, you must have a good source for the matrix display. Even at Sparkfun (cheaper displays than Adafruit), you couldn't get a display plus Teensy 3.1 for $55 before shipping.

I took a chance and got it through AliExpress.

Cool, that's new to me.  I like the square pixels.  I don't like the cost.

Me too to both. But at the same time he has spent a great deal of time and take a lot of pride in the quality of the finished product so it's understandable that the pricing gets high.

Do you intend to compile these into a sketch, or send them via serial so the graphics can be changed without recompiling?

I hadn't thought about sending the data through serial. Great input :) I thought about using the Mega and compile the files in the sketch or alternatively wire up a SD card reader and read the files from there for added flexibility. But I really don't want a bulky Mega sitting on the back of the display/frame and are uncertain how much I can push the Nano. Teensy and your library is looking like a much better solution if I want to go beyond mostly static frames.

I think Adafruit's library is using 5-6-5 color, so you have to do some shifting and masking to convert.  I'm using 3 bytes per pixel, one byte per color, so it should be easy to draw from an array of uint8_t RGB values.

The GFX library is using 565, but the matrix buffer is using 444. In addition the color bits in the buffer are shifted around in a strange way (to me) and handled differently between the bitplanes (you'll see it if you look into the drawPixel function). I'm starting to understand it now but it was a big leap for a rusty rookie like me.

Do you have a link to an example?  I did some searching and didn't find a small cheap step-down converter that can handle 4A output.

I think that the step down converter from eBay I have laying around actually can't handle the load come to think about it, but I have read that KIM-055L based step down converters are able to handle a high constant load (but I know little about the quality).

Good Stuff Louis,

My teensy turned up today but I am still waiting on my 16x32 panel, it should be here next week. Pretty excited to try out all your hard work!

I've been following this topic with great interest, and I will surely buy a few kits. Can't wait!

In the meanwhile, I've ordered a 16x32 and a 32x32 matrix from aliexpress /store/814152 (I'm a new user, can't post a proper URL) at very good prices just in case someone is interested. Still waiting for the Teensys...

lcunha: I bought my panels from the same store :) Very pleased with the panels.

Which of the models did you buy? P5 or P6?, are those the same as adafruit/sparkfun panels?

The P6s are the same as Adafruit's: 192mmx96mm (32x16) and 192mmx192mm (32x32) and 1/8 driving. Some (all?) P5s are 1/16 driving and I believe, please correct me if I'm wrong, that these would need changes in the library to work.

I bought the P6 versions. The 16x32 is 1/8 and the 32x32 is 1/16.

I'm finalizing my Processing script for converting GIF/PNG/JPG to the Adafruit matrix buffer format. I have images up and running but it seems like the 4/4/4 down conversion of colors are very harsh to some of the test images I'm using (or a bug or two might still be lurking in the code).

I plan on releasing the script as soon as I have managed to tidy it up a little bit (the code is not a pretty sight at the moment) and looked into the color down conversion issue.

I loaded another test image and quickly noticed that my problem with the colors where worse than I initially tought.

The culprit seems to be my adaption of the bit manipulation routines found in Adafruit's drawPixel function in the RGBMatrixPanel.cpp file. I believe it can be related to the way the original code uses pointers/references and the way I have converted the code to Processing and/or the way I handle binary data.

Here is the current Processing code:

PImage image;
String imageName = "test.gif";
String saveDir = "./imageFiles/";
PrintWriter outputMatrix;
int [][] matrixbuff= new int [3][32];

void setup() {
  selectInput("Select a file to process:", "imageName");
}

void imageName(File selection) {
  if (selection == null) {
    println("Window was closed or the user hit cancel.");
  } 
  else {
    println("User selected " + selection.getAbsolutePath());
    // Do note that the file used is from the hardcoded reference in the top of this file and not the file selection dialog - need more code to handle it correctly 
    image = loadImage(imageName);
    size(image.width, image.height);
    outputMatrix = createWriter(saveDir + "image.h");
    //    outputMatrix = createWriter(saveDir + imageName.substring(0, (imageName.length()-4)) + ".h");
    background(0, 0, 0);
    image(image, 0, 0);

    outputMatrix.println("// Generated by Processing script");
    outputMatrix.println("// Original file: " + imageName);
    outputMatrix.println("// Size: " + image.width + "x" + image.height + "px");
    outputMatrix.println("#include <avr/pgmspace.h>");
    outputMatrix.println("static const uint8_t PROGMEM image[] = {");

    //Convert all pixels from original color > 5/6/5 > 4/4/4 > matrix buffer format and save to file
    //Can be done much more elegantly but I'm to rusty/lazy to do it properly at the moment
    for (int y = 0; y < 16; y++) {
      println("y:" + y);
      for (int x = 0; x < 32; x++) {
        print("x:" + x + " y:");

        int limit;
        int nPlanes = 4;

        int c;
        int r;
        int g;
        int b;
        int c16;
        int r16;
        int g16;
        int b16;

        // Convert original color to 5/6/5 format
        color tempColor = image.get(x, y);
        int red = tempColor >> 16 & 0xFF;
        int green = tempColor >> 8 & 0xFF;
        int blue = tempColor & 0xFF;
        float alpha = alpha(tempColor);

        if (alpha == 255) {
          c = Color565(red, green, blue);
        } 
        else {
          c = Color565(0, 0, 0);
        }

        tempColor = image.get(x, y+16);
        red = tempColor >> 16 & 0xFF;
        green = tempColor >> 8 & 0xFF;
        blue = tempColor & 0xFF;
        alpha = alpha(tempColor);

        if (alpha == 255) {
          c16 = Color565(red, green, blue);
        } 
        else {
          c16 = Color565(0, 0, 0);
        }

        // Matrix needs 4/4/4. Pluck out relevant bits from 5/6/5 while separating into R,G,B:
        // Upper half

        r =  c >> 12;        // RRRRrggggggbbbbb
        g = (c >>  7) & 0xF; // rrrrrGGGGggbbbbb
        b = (c >>  1) & 0xF; // rrrrrggggggBBBBb

        //quick and dirty graytone gradient hack to figure out whats wrong with my adaption of the bit manipulation routines
        //r = g = b = y;

        println(y + " Color:" + c + ",B" + binary(r, 4) + binary(g, 4) + binary(b, 4) + ",0x" + hex(r, 1) + ",0x" + hex(g, 1) + ",0x" + hex(b, 1) + ",");

        // Matrix needs 4/4/4. Pluck out relevant bits from 5/6/5 while separating into R,G,B:
        // Lower half
        r16 =  c16 >> 12;        // RRRRrggggggbbbbb
        g16 = (c16 >>  7) & 0xF; // rrrrrGGGGggbbbbb
        b16 = (c16 >>  1) & 0xF; // rrrrrggggggBBBBb
        println("     y:" + (y + 16) + " Color:" + c16 + ",B" + binary(r16, 4) + binary(g16, 4) + binary(b16, 4) + ",0x" + hex(r16, 1) + ",0x" + hex(g16, 1) + ",0x" + hex(b16, 1) + ",");

        // Data for the upper half of the display is stored in the lower bits of each byte.
        // Plane 0 is a tricky case -- its data is spread about, stored in least two bits not used by the other planes.
        matrixbuff[2][x] &= ~unbinary("00000011");          // Plane 0 R,G mask out in one op
        if (boolean(r & 1)) matrixbuff[2][x] |= unbinary("00000001");  // Plane 0 R: 64 bytes ahead, bit 0
        if (boolean(g & 1)) matrixbuff[2][x] |= unbinary("00000010");  // Plane 0 G: 64 bytes ahead, bit 1
        if (boolean(b & 1)) { 
          matrixbuff[1][x] |= unbinary("00000001");  // Plane 0 B: 32 bytes ahead, bit 0
        }
        else { 
          matrixbuff[1][x] &= ~unbinary("00000001");  // Plane 0 B unset; mask out
        }

        // The remaining three image planes are more normal-ish.
        // Data is stored in the high 6 bits so it can be quickly
        // copied to the DATAPORT register w/6 output lines.

        // Loop counter stuff
        limit = 1 << nPlanes;
        for (int bit = 2; bit < limit; bit <<= 1) {
          matrixbuff[0][x] &= ~unbinary("00011100");             // Mask out R,G,B in one op
          if (boolean(r & bit)) matrixbuff[0][x] |= unbinary("00000100");  // Plane N R: bit 2
          if (boolean(g & bit)) matrixbuff[0][x] |= unbinary("00001000");  // Plane N G: bit 3
          if (boolean(b & bit)) matrixbuff[0][x] |= unbinary("00010000");  // Plane N B: bit 4
        }

        // Data for the lower half of the display is stored in the upper
        // bits, except for the plane 0 stuff, using 2 least bits.
        matrixbuff[0][x] &= ~unbinary("00000011");               // Plane 0 G,B mask out in one op
        if (boolean(r16 & 1)) { 
          matrixbuff[1][x] |= unbinary("00000010"); // Plane 0 R: 32 bytes ahead, bit 1
        }
        else { 
          matrixbuff[1][x] &= ~unbinary("00000010"); // Plane 0 R unset; mask out
        }
        if (boolean(g16 & 1)) matrixbuff[0][x] |=  unbinary("00000001"); // Plane 0 G: bit 0
        if (boolean(b16 & 1)) matrixbuff[0][x] |=  unbinary("00000010"); // Plane 0 B: bit 0

        // Loop counter stuff

        for (int bit = 2; bit < limit; bit <<= 1) {
          matrixbuff[0][x] &= ~unbinary("11100000");                         // Mask out R,G,B in one op
          if (boolean(r16 & bit)) matrixbuff[0][x] |= unbinary("00100000");  // Plane N R: bit 5
          if (boolean(g16 & bit)) matrixbuff[0][x] |= unbinary("01000000");  // Plane N G: bit 6
          if (boolean(b16 & bit)) matrixbuff[0][x] |= unbinary("10000000");  // Plane N B: bit 7
        }
        println("     Buffer0:0x" + hex(matrixbuff[0][x], 2) + " Buffer1:0x" + hex(matrixbuff[1][x], 2) + " Buffer2:0x" + hex(matrixbuff[2][x], 2));
      }
      for (int x = 0; x < image.width; x++) {
        outputMatrix.print("0x" + hex(matrixbuff[0][x], 2) + ",");
      }
      outputMatrix.println("");
      for (int x = 0; x < image.width; x++) {
        outputMatrix.print("0x" + hex(matrixbuff[1][x], 2) + ",");
      }
      outputMatrix.println("");
      for (int x = 0; x < image.width; x++) {
        outputMatrix.print("0x" + hex(matrixbuff[2][x], 2) + ",");
      }      
      outputMatrix.println("");
    }
    outputMatrix.println("};");  
    outputMatrix.flush();
    outputMatrix.close();
  }
}

int Color565(int r, int g, int b) {
  return ((r & 0xF8) << 8) | ((g & 0xFC) << 3) | (b >> 3);
}

Sorry I didn't jump in earlier, I stopped getting topic update notification emails, not sure why.

[quote author="lcunha"]The P6s are the same as Adafruit's: 192mmx96mm (32x16) and 192mmx192mm (32x32) and 1/8 driving.[/quote]

I see the 32x32 LED display listed as 1/8 scan.  I wouldn't trust that spec.
http://http://www.aliexpress.com/store/product/good-quality-led-module-p6-indoor-fullcolor-192-192-smd-led-module-in-alibaba/814152_1598164078.html

There's a good chance that it's just a mistake, though there are some 32x32 displays that have two separate input connectors, each with 1/8 scan driving half the display.  Hopefully it's not one of these displays.  Though there's a chance my library could support those displays - by chaining the two separate 16x32 display halves together through a ribbon cable - but it's not something I plan on supporting right away.  There's a picture of one of these displays here (first picture on the page):
http://http://learn.adafruit.com/32x16-32x32-rgb-led-matrix/wiring-the-32x32-matrix

The library will support 16x32 (1/8 scan) and 32x32 (1/16 scan) when I release it.

[quote author="EmbeddedCreations"]I wouldn't trust that spec.[/quote]
You're probably right. :)
[quote author="EmbeddedCreations"]The library will support 16x32 (1/8 scan) and 32x32 (1/16 scan) when I release it.[/quote]
Great! That means that a 32x32 P5 (160mm x 160mm) will also work.
On this one http://www.aliexpress.com/store/product ... 05806.html (http://www.aliexpress.com/store/product/P5-SMD-Led-Display-Module/814152_639105806.html) the "D" pin is clearly seen on one of the pictures.

The 32x32 P5 will likely work.  I informally tried P3, P4, and P5 displays with my board.  All worked but on one of them (a P4 in this case) blue and green were swapped.  The silkscreen showed the typical pinout, but the circuitry didn't match the pinout.  That's easily fixed with a header file change.

I see the 32x32 LED display listed as 1/8 scan. I wouldn't trust that spec.

I stand corrected.  I contacted the supplier and they do indeed offer displays of the same size in both 1/8 and 1/16 scan.  1/8 are slightly more expensive as there are more column driver chips on the board.  Unfortunately I wouldn't expect my library to support that display as is, though it might be possible to modify the code to get it to work.  The tricky thing would be making sure there's enough time to shift 64 updates in the smallest latch cycle.

So, your recommendation is we buy 16x32 (1/8 scan) or 32x32 (1/16 scan), correct?
BTW, thank you for all your efforts!

[quote author="lcunha"]your recommendation is we buy 16x32 (1/8 scan) or 32x32 (1/16 scan), correct?[/quote]

That's correct.  Those are the displays that Adafruit and Sparkfun stock, so that's what I assume most users will have, so I'm supporting just those displays (at least at first).

My 32x32 panel finally arrived. I plan to implement video streaming from a PC via USB or LAN to a Teensy and the panel.

Do you already have some code snippets of your library to share? I would love to test it.

Email me (put together the name and domain in my signature), I have a small group of people that I'll send the beta library to when its ready.  I like the video streaming idea.  Do you know how you might stream over USB?  The VideoDisplay example from the OctoWS2811 library is where I'd start.
http://https://www.pjrc.com/teensy/td_libs_OctoWS2811.html#videodisplay

[quote author="EmbeddedCreations"] I like the video streaming idea.  Do you know how you might stream over USB?  [/quote]

I finished the Arduino version http://http://forums.adafruit.com/viewtopic.php?f=47&t=50115, it allows live streaming from the PC screen. The Teensy version will probably be much cooler, because of the better color depth.

[quote author="MarkusL"]I finished the Arduino version[/quote]

That looks really cool!  I'll make sure to include the backBuffer function in my library.  I didn't realize that function existed until I saw your code.

Are you not using the double buffering to save memory?  The display might look a little better if each refresh contained a full frame.  The Teensy will have enough memory for sure, plus I didn't add a way to disable double buffering.  You'll just call matrix.swapBuffers(false) after receiving all the data for a frame.

An Arduino has barely enough memory for a single buffer. Therefore there is no double buffering. This should not be an issue with the Teensy, as it has 32 times the RAM.

I'm starting to put some actual graphics on the display now that I'm doing less coding and more testing of the library.  I grabbed a weather icon and overlaid a temperature on it, and thought the display driven with 24-bit color did a pretty good job of showing small variations in color on the yellow of the sun and the white fading to black of the clouds.  I loaded in the 12-bit color correction table from the Adafruit library to compare with what the AVR is capable of doing, and you can really see the difference with this sample image.  The camera washes out the white a bit, but you can see the difference along the edges, including part of the image in the upper left that just turns to black at 12-bit.

[attachment=0]

---

Nice, much smoother gradients!

In the meantime I have also implemented a 24bit version on the Teensy. So far without using DMA. The trick is to prepare correctly interleaved RGB-buffers in advance. Adding DMA should improve this further. The sourcecode is here: http://forums.adafruit.com/viewtopic.ph ... 54#p253154 (http://forums.adafruit.com/viewtopic.php?f=47&t=50115&p=253154#p253154)

I could use some feedback!

My "library" isn't a true library yet as the source is just a part of the Arduino sketch.  In packaging the code into an Arduino library, I need to figure out the best way to allocate memory for each display configuration (right now 16x32, 32x32, but in the future more options).  Right now I'm just changing definitions in a header file, but that won't work once it's a library.  Here are the options I can see:

1. User allocates the buffers and passes a pointer as part of the constructor, along with the display size.  PJRC's Octows2811 library is an example of a library that does this.

Here's the user code needed to initialize the library:

#include <OctoWS2811.h>
const int ledsPerStrip = 120;
DMAMEM int displayMemory[ledsPerStrip*6];
int drawingMemory[ledsPerStrip*6];
const int config = WS2811_GRB | WS2811_800kHz;
OctoWS2811 leds(ledsPerStrip, displayMemory, drawingMemory, config);

Pros: the user can see the RAM used by the sketch when compiling
Cons: "magic" code needed in the sketch, details that ideally would be tucked away inside the library e.g. "DMAMEM" and "ledsPerStrip*6"

2. Library uses malloc to allocate buffer from the heap inside the constructor.  Simplifying the Octows2811 example:

#include <OctoWS2811.h>
const int ledsPerStrip = 120;
const int config = WS2811_GRB | WS2811_800kHz;
OctoWS2811 leds(ledsPerStrip, config);

Pros: it's much easier for the user to initialize the library
Cons: the RAM usage displayed after compilation isn't complete: a significant amount of memory will be on the heap

3. Have a separate library for each configuration.  When packaging the library, create several .zip files like TeensyMatrix16x32.zip, TeensyMatrix32x32.zip that each have a unique header.  The user includes the correct header file in their sketch, matching their hardware.  The library will statically allocate memory based on definitions in the unique header file.  Using the Octows2811 example (configuration is now defined as part of the header file):

#include <OctoWS2811_120_GRB_800.h>
OctoWS2811 leds();

Pros: sketch is clean, and RAM usage is complete
Cons: as the library includes more configurations, the user may have to manage many matrix libraries, cluttering up the library list

I'm leaning toward option #3, which can be revisited later on as the number of library configurations increases.  Thoughts?

How about something like option 3, but using #define?
The user places a #define in the sketch and the library header file uses #if defined to branch.
*If* that works only one header file would be needed.

Generally, I'd keep it as simple as possible. Most users just want the RGB-Panel to work, and concentrate on other stuff. The few users who have very specific requirements or like to tweak every byte can just modify the library directly. I'd also keep it lean, just adding basic functions like drawPixel(), everything else like drawText() or drawLine() should be in a separate library.

I'd also choose variant 3. Normally it's great to have a library configurable, for example changing the number of pixels. However, in this specific case, there are only two possible options: 16x32 and 32x32. To my knowledge no others exist. And if there were others, they'd have a completely different interface anyway.

Regarding variant 2: I don't think you can guarantee that the memory allocated with malloc() is in the DMAMEM area, so probably this variant is not optimal.

Variant 1: This is great for LED-strips, because users can have a lot of different sizes. However, the panel only comes in two sizes, so this is not really necessary.

Regarding #define as proposed by lcunha: This would be great. However, I don't think that this is supported in  Teensyduino.

[quote author="lcunha"]How about something like option 3, but using #define?[/quote]

That would be ideal, but unfortunately as MarkusL said, it doesn't work.

[quote author="MarkusL"]in this specific case, there are only two possible options: 16x32 and 32x32[/quote]
Later on I think 16x64 (two 16x32 panels in series) will be supported.  There are 32x64 panels available from China.  Those and other configurations could be supported with a lower color depth in the future.  But you're right, I think just a few standard options should work for most people, and hackers can hack away on their libraries.

[quote author="MarkusL"]I'd also keep it lean, just adding basic functions like drawPixel(), everything else like drawText() or drawLine() should be in a separate library[/quote]
I have everything in one library right now, why do you think this is important?  I don't feel like there's any shortage of program memory on the Teensy 3.

Of course you can also put it in one library. I just like it when functionallity is seperated: Everything that is directly related to interfacing the panel in one, and helper functions like draw line in another, for example like the adafruit Adafruit_GFX and Matrix libraries. This can make reuse of the parts easier.

[quote author="MarkusL"]I just like it when functionality is separated[/quote]
Got it, I considered that, but given this library is my first C++ class (I'm used to writing software in plain old C), I didn't want to make it more complex than necessary.  The first version of the library was written in C, and I separated the source into modules for drawing, for the text layer, etc.  I had to add all the methods to the single matrix class when moving to C++, but kept the source files separate.  Maybe in the future I'll come back to pulling functionality out into separate classes.

Quick update: I packaged up the library using a unique header file name per configuration.  I finalized the features for the first release, and made an example program that does a demo of all the features.  A few beta testers have a copy of the library, but I still have some work to do before its stable.  I just moved to a new apartment this weekend and all my stuff is packed up, so I probably won't make any progress in the next few days while I get settled.  The kit is hopefully close to finished, and I'm getting samples of all the parts and the board from the company in China doing the sourcing, kitting, and direct fulfillment.  More updates at the end of the week, or early next week.

Wow, I'm surprised it's been two weeks since my last update.  I ordered 100 boards from one of the prototyping PCB services in China, and was not happy with the results.  The silkscreen was not very sharp, which is just a cosmetic issue but I want my customers to receive good quality parts.  More troubling was solder mask that was far away from the pads.

I assembled several boards, and one board had a short from power to ground, which I traced back to a solder bridge between a pad on the power connector and the ground plane surrounding the pad, which was barely exposed by the solder mask.  I made the mistake of leaving the default Isolate=0 parameter for the ground plane, which put the ground plane 6 mils away from the pads.  With my OSH Park boards this was not an issue, but with the sloppy solder mask, there was a a decent amount of exposed ground plane.

I made some board revisions, giving the ground plane a 12 mil isolation and also setting the DRC to a 9 mil minimum spacing for all features to give a little more cushion for fabrication errors.  I switched vendors for my next order of boards, going with HQPCB, a vendor I used last time I was in Shenzhen thanks to some Makers who posted instructions online:
http://http://www.transfabric.org/where-pcbs-are-made/
http://http://tempeto.com/?p=1

The HQPCB boards were finished yesterday and I have samples on their way via DHL.  Hopefully these boards will have no issues and I'll be able to have the kits assembled and ready to ship.
[attachment=0]

---

Thanks for the update and the links to the blog articles - great reading!

Are the PCBs in the photo from the first batch or from the HQPCB batch? The quality (at least in the photo) seemed nice enough.

Did you use Google Translate to communicate with HQPCB or was it done in English or Chinese? Did you go for HQPCB due to the quality and/or pricing? I hadn't heard about them before but it seems like they are a nice PCB fab.

The photos are from the HQPCB batch, I'm happy with the quality at least from the pictures.  I went with HQPCB first for the quick turnaround and ease of ordering without knowing Chinese.  I was getting boards in 48 hours for a reasonable price when I was in Shenzhen and needed to turn over prototypes quickly.  I ordered from them this time as I knew they had good quality at a reasonable price.

I used a combination of Google Translate and advice from those links I posted to order from HQPCB.  I could not figure out how to pay them myself without a Chinese bank account.  If I recall there used to be a way to add money to an Alipay account without having a Chinese bank account, but that didn't work when I tried (last year).  For this order I had a Chinese contact pay for me.

Holy cow, this looks AWESOME.

I am eagerly awaiting the day when I can order one of these suckers. I've bumped up against the limits of the poor Atmega328....

If you have a working prototype, even if it's cosmetically imperfect, I will happily pay $$ to buy it from you ;)

Any idea when you will make your software generally available. I've now collected all of my parts and just need the software to bring my project together.

Thanks in advance for all of your efforts.

Hi Craig,

Email me (put together the words in my signature), and I'll put you on the beta list.  I'll make the software generally available after I have a few people run through the next release.

I can't wait.. Great little project Louis!! I sent emails yesterday, and will wait for the release announcement!!

I'm very glad I found this thread.  I'll be ordering a board when they're ready!

Long time, no update...  I've been in China for the last two weeks, attending Ian's Hacker Camp, and meeting with partners for getting this kit made and distributed.  Good news is, the first 100 kits are all made, and are sitting with a company that will do order fulfillment.  I still need a few days to finish up travel and get back to a place that has decent internet so I can put a shopping cart up on the web and start taking orders.  I'll be putting up the board design and library source at the same time.

Yeah!!!! Great work Louis!!

Louis,

Is it possible to connect  the LED matrix and an SD card to the teensy 3.1 simultaneously? It would be nice to store patterns or bitmaps on the card and read them in to display them.

Probably not, but I thought I would ask.

It should be possible, though I haven't tried it myself. I specifically chose pins for the matrix to leave the spi (and other peripherals) pins available. There is only one spi chip select pin open. You can see the pins on the first page of this topic.

There are some others interested in loading images and animations from a sd card as well. It's something I may try to incorporate into the library, or at least provide some functions to make it easier to do.

The SD Card access is a must..!!

Just wanted to let everyone know that I have successfully connected an SD card interface to a Teensy 3.1 running the RGB Matrix display. Connections are simple and are shown below. No level shifters or pullup resistors are required.

 *      Hardware Connections
 *      Teensy 3.1 <------>  SD Card
 *      ------------------------
 *      3.3V output  ------  Vcc
 *        Gnd ------ Gnd
 *      pin 11 ------ MOSI or DI
 *      pin 12 ------ MISO or DO
 *      pin 13 ------ CLK
 *      pin 15 ------ CS
 *
 * NOTE: Pin 15 must be specified as the chip select in the SdFat initialization code (sd.begin statement) for the SdFat code to work

For a test I wrote two sketches. The first generated 100 unique plasma patterns on the LED matrix and saved them to individual files on the SD card. The second sketch read and displayed the 100 plasma patterns from the files.

NOTE: I had to move the readPixel method in SmartMatrix.h from the private declarations to the public declarations to make my code work.

The two sketches are available in a single zip file available at: craigandheather.net/misc/LEDMatrix_SDCard.zip if anyone is interested.

Again thanks to Louis for an incredible driver for the LED matrix

Hi Craig, that's great!  Thanks for sharing your code.

Hi Craig,

I was unaware of your plans/progress and have spent most of the day soldering up a temporary protoboard and started working on some code myself.

[attachment=0]
 I almost had it going and sent Louis an e-mail about the progress. Louis then informed me about your progress. LOL.

I'll look into your code asap :)

I'm also going to see if I can attach a CC3000 wifi module and get that going.

Kjetil

---

Hi Craig,

I was able to check out your sketches. Nice work :)

I made a couple of minor changes:

        delay(500); // was 2000
        
        fileNumber++;
        if (fileNumber == 100) {
            fileNumber = 1; // original code stopped after last file
        }

By removing the delay between each image I was also able to test the load speed. It seems like it's reaching around 20-25 frames/s on my setup (I didn't bother timing it accurately). Respectable :)

My quest has been to display BMP files both as still images (slideshows) and as animations (e.g. converted from GIF-anims). I have also spent a tiny bit on a possible config setup and planned to create a sketch in Processing to generate both the image files and config files.

You can read about my config thoughts on the Pixelmatix forum and I welcome input/critique.

Kjetil

PixelMatrix Forums??? URL??

Great work Craig.. It would be great to have net control over the display..  My aspirations for this would be a net and sd card enabled display controlled with a single rotary encoder as the selection control!

[quote author="KPR"]PixelMatrix Forums??? URL??[/quote]

http://http://www.pixelmatix.com/forum/

The Pixelmatix site is not published yet, but the forum is working.

Thanks Louis!!

Just a little update.

I have been able to work a little more on my code tonight and have BMP loading up and running for both "slideshow" and animation sequences.

Getting BMP files to load was a major hassle. I was able to look up example code on the net that I based my implementation on but the BMP files would not load. The problem turned out to be that BMP files exported from Photoshop where not valid. I found a large BMP (176x176 px) from Adafruit that loaded but when scaling it down in Photoshop or Preview (Mac) the file did not load. In the end I downloaded Gimp and was able to export the files properly.

At the moment I have hardcoded the frame sequences and delays in a multi-array in the code and I will look into loading the data properly from a config file as soon as time permits - hopefully tomorrow.

Fun fact: I changed SD card and load times dropped from around 64ms to 30ms for the BMP files. I'm satisfied with a 30+ frame rate ;)

Hi Kjetil, that's great progress!  30fps will make for some nice animations. 

Taking a look at BMP on Wikipedia (http://http://en.wikipedia.org/wiki/BMP_file_format) shows that Photoshop adds some undocumented headers to the format, I wonder if that's where things are going wrong.  I just assumed a BMP is a BMP, but it looks more complicated than that.

Yes, I got suspicious about Photoshop doing something funny when I noticed that the file size was 9KB…

I recorded a video of the current status on the animation/slideshow viewer: http://youtu.be/qpx4o4rUV-U (http://youtu.be/qpx4o4rUV-U)

Wow, you ran all those images through GIMP?  We're definitely going to need a scriptable commandline utility.  While I don't have time to start on this right now, you might take a look at ImageMagick (http://http://www.imagemagick.org/script/convert.php)

Yes, all images have been converted through Gimp :) Do note that the anim only consist of 6 images though with independent ms delays (frameSequence = 1,2,3,4,5,4,3,4,3,6,2).

My plan is to write a Processing sketch to create both BMP and config files but since Processing don't support BMP directly I have put it on the backburner for now.

I downloaded ImageMagick right after I downloaded Gimp, but actually havent't opened it yet ;) It sounds like I should!

Hey guys.  I finally got my Teensy 3.1 and SD adapter in and have it all wired up.  The 32x32 FeatureDemo and Craig's plasma code work perfectly.  Thanks for sharing those!  Now I'm trying to load BMP files off the SD card.  I've adapted the bitmap reading code from here:

http://forum.pjrc.com/attachment.php?at ... 1360704148 (http://forum.pjrc.com/attachment.php?attachmentid=239&d=1360704148)

But any time I use read32, I get back 209341762.  I've been staring at the code for far too long, trying to figure out what I'm doing wrong.  Any ideas?  Any chance you'd share the code you're using to read the bitmaps?  Thanks in advance!

btw, where do we buy this controller board?, if it is for sale?

@Pup05: It could be that the BMP files you are using are incompatible. I have it working and will try to upload files and procedures later today to get you going.

@neslekkim: I think Louis is almost ready to open the doors on his web shop.

Yeah, I read through the difficulty with the BMP format, and made sure to export from GIMP. I previously had the same BMP and similar code working on an Arduino Mega. I look forward to reviewing the code when you share it, thanks!

Current sketch (sorry for lousy programming skills ;)):

// This sketch is a "collage" of code snippets lifted from several examples all over the net. Sorry for no attributions :(

#include "SmartMatrix_32x32.h"
#include "SdFat.h"
#include "SdFatUtil.h"

SmartMatrix matrix;

const int defaultBrightness = 25*(255/100);
const int defaultScrollOffset = 6;
const rgb24 defaultBackgroundColor = {
  0, 0, 0};

// Teensy 3.0 has the LED on pin 13
const int ledPin = 13;

//------------------
#define SD_CS 15
SdFat sd; // set filesystem
SdFile bmpFile; // set filesystem

//for image processing
#define BUFFPIXEL 64

//------------------

// the setup() method runs once, when the sketch starts
void setup() {
  // initialize the digital pin as an output.
  pinMode(ledPin, OUTPUT);
  //    digitalWrite(ledPin, HIGH);
  Serial.begin(38400);

  matrix.begin();
  matrix.setBrightness(defaultBrightness);

  matrix.setScrollOffsetFromEdge(defaultScrollOffset);

  matrix.setColorCorrection(cc24);
}

#define DRAW_BMP                1
//#define DEMO_INTRO              1


// the loop() method runs over and over again,
// as long as the board has power
void loop() {
  int i, j;
  unsigned long currentMillis;

  // clear screen
  matrix.fillScreen(defaultBackgroundColor);
  matrix.swapBuffers(true);

#if (DRAW_BMP == 1) 
  Serial.print("Initializing SD card...");
  if (!sd.begin(SD_CS, SPI_FULL_SPEED)) {
    Serial.println("failed!");
    return;
  }
  Serial.println("SD OK!");

  bmpDraw("pm.bmp", 0, 0);
  delay(2000);

  char fileName[12];
  int frames = 11;
  char fileNam;
  unsigned long sequence[2][12] = { 
    {
      0,1,2,3,4,5,4,3,4,3,6,2                    }
    ,{
      0,1000,200,200,200,200,200,200,200,200,200,600                    } 
  } 
  ;
  for (int y=0; y<2; y++){
    for (int i=1; i<=frames; i++){
      sprintf(fileName, "lechuck%d.bmp", sequence[0][i]);
      bmpDraw(fileName, 0, 0);
      delay(sequence[1][i]);
    }
  }


  bmpDraw("pm.bmp", 0, 0);
  delay(1000);

  for (int i=1; i<=516; i++){
    sprintf(fileName, "pman%d.bmp", i);
    bmpDraw(fileName, 0, 0);
    delay(30);
  }

  bmpDraw("pm.bmp", 0, 0);
  delay(1000);

  for (int y=0; y<2; y++){
    for (int i=1; i<=52; i++){
      sprintf(fileName, "pong0%d.bmp", i);
      bmpDraw(fileName, 0, 0);
      delay(50);
    }
  }

  bmpDraw("pm.bmp", 0, 0);
  delay(1000);

  for (int y=0; y<2; y++){
    for (int i=1; i<=64; i++){
      sprintf(fileName, "boat%d.bmp", i);
      bmpDraw(fileName, 0, 0);
      delay(50);
    }
  }

  bmpDraw("pm.bmp", 0, 0);
  delay(1000);

  for (int y=0; y<2; y++){
    for (int i=1; i<=12; i++){
      sprintf(fileName, "lbrd%d.bmp", i);
      bmpDraw(fileName, 0, 0);
      delay(70);
    }
  }

  bmpDraw("pm.bmp", 0, 0);
  delay(1000);

  for (int i=0; i<21; i++){
    sprintf(fileName, "%d.bmp", i);
    bmpDraw(fileName, 0, 0);
    delay(5000);
  }
#endif

#if (DEMO_INTRO == 1)
  // "SmartMatrix Demo"
  matrix.setScrollColor({
    0xff, 0xff, 0xff                  }
  );
  matrix.setScrollMode(wrapForward);
  matrix.setScrollSpeed(40);
  matrix.setScrollFont(font6x10);
  matrix.scrollText("SmartMatrix Demo", 1);

  delay(5000);
#endif
}

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

  SdFile   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 >= matrix.getScreenWidth()) || (y >= matrix.getScreenHeight())) return;

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

  // Open requested file on SD card
  bmpFile.open(filename, O_READ);

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

        goodBmp = true; // Supported BMP format -- proceed!
        Serial.print("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) >= matrix.getScreenWidth())  w = matrix.getScreenWidth()  - x;
        if((y+h-1) >= matrix.getScreenHeight()) h = matrix.getScreenWidth() - y;

        for (row=0; row<h; row++) { // For each scanline...
          //          tft.goTo(x, y+row);


          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.curPosition() != pos) { // Need seek?
            bmpFile.seekSet(pos);
            buffidx = sizeof(sdbuffer); // Force buffer reload
          }

          // optimize by setting pins now
          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 Matrix format, push to display
            rgb24 color;
            color.blue = sdbuffer[buffidx++];
            color.green = sdbuffer[buffidx++];
            color.red = sdbuffer[buffidx++];

            matrix.drawPixel(x+col, y+row, color);
            /*
    Serial.print("X: ");
             Serial.print(col);
             Serial.print(" y: ");
             Serial.print(row);
             Serial.print(" Col: ");
             Serial.print(color.red);
             Serial.print(",");
             Serial.print(color.green);
             Serial.print(",");
             Serial.println(color.blue);
             */
          } // end pixel
        } // end scanline
        matrix.swapBuffers(true);
        Serial.print("Loaded in ");
        Serial.print(millis() - startTime);
        Serial.println(" ms");
      } // end goodBmp
    }
  }

  bmpFile.close();
  if(!goodBmp) Serial.println("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(SdFile& f) {
  uint16_t result;
  ((uint8_t *)&result)[0] = f.read(); // LSB
  ((uint8_t *)&result)[1] = f.read(); // MSB
  return result;
}

uint32_t read32(SdFile& 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;
}

Video of current sketch:
http://youtu.be/vs1PBkBcLlY (http://youtu.be/vs1PBkBcLlY)

@Pup05: If you copy the Read32 function from my sketch you should get your sketch going.

Some tips on how to create compatible BMPs
Gimp:
Ensure that image mode is RGB. (Image > Mode > RGB)
When exporting to Windows BMP: select "Do not write color space information" under "Compatibility options" and select 24 bit under "Advanced options" (this is vital).

ImageMagick:
Here is an example of the script I have used.

convert *.gif -scene 1 +adjoin +matte -compress none -type truecolor -alpha off -resize 32x32! -coalesce anim%d.bmp

Do note that this script do not work perfect with GIF anims that only update zones in the animation and not the whole frame. I will look more into better settings.

BMP files to get you going
I have included the BMP files I use in this sketch. The BMPs have been converted from graphics collected all over the net and sadly I'm unable to attribute the creators correctly :( Copy the BMP files to the root folder on your SD card.

Excellent, I got it working great now, thank you!  I obviously need to study up on my C.  :)  http://https://www.youtube.com/watch?v=t4OwVn9t3FU

Great to hear about your success! Did you end up using your code or the code I uploaded?

I love the animation! Care to share?

Found a worse performance problem than I had believed possible with loading BMPs from SD cards:
Load times will vary from 30ms to 400ms depending on placement in folder (i.e. sorting of filename)! Say good bye to long 25-30 frames/sec animations :( I'm uncertain if it's directly FAT related or physical properties of the storage memory. A solution might be to split longer anims into several folders or packing several frames per file to reduce amount of files in folder.

A 500-ish frames anim ranges from 44ms to 100ms. The next 2500-ish anim ranges from 100ms to 400ms…

Dump from Serial monitor:
Loading image 'sb2462.bmp'
File size: 3210
Image Offset: 138
Header size: 124
bmpDepth: 24
Image size: 32x32
Loaded in 400 ms

Loading image 'pm.bmp'
File size: 3126
Image Offset: 54
Header size: 40
bmpDepth: 24
Image size: 32x32
Loaded in 43 ms

Loading image '0.bmp'
File size: 3126
Image Offset: 54
Header size: 40
bmpDepth: 24
Image size: 32x32
Loaded in 30 ms

I was able to hide the problem with varying loading times by creating sub directories per 100 frames of animation. Some of the frames then loaded under 30ms. I might even achieve faster loading times by limiting frames per directory to 50 :)

To get consistent playback speed I need to vary the delay based on loading times. E.g. a 10fps video with a frame loading in 35ms would need a 65ms delay on top of the loading time.

A little quiz:
http://youtu.be/DiHsdo7m3sE (http://youtu.be/DiHsdo7m3sE)
Guess what Amiga demo I converted? The music is not the original :)

I've just started modifying the code you posted to change the images/sequences. I haven't bothered to go back and look why my code wasn't working. I hope to work on getting it to load up images dynamically, instead of hard-coding the sequences, but haven't had much time today.

I've attached the animation. As I mentioned in the video comments, it's from Tiny Barbarian (http://http://tinybarbarian.com), which is a great little old-school game with lots of character.  It reminds me of Rastan, Black Tiger, Rygar, Castlevania, etc.

I'm having problems with the first frame taking forever (several seconds) to load, but if I skip the first frame image it works fine.  I also started organizing the images into directories, but just to keep everything better organized. I haven't run into the performance issue you mentioned yet. That "State of the Art" animation is crazy long!  How many frames is that?

Please share your progress with us regarding dynamically loaded images. I'll also be looking into it when time permits.

Thanks for sharing the Tiny animation! I'll see if I experience the same problem with the first frame. How did you export it to BMP?

The "Spaceballs - State of the Art" anim is 2462 frames long :)

Tools used:
Airy - to export the video from Youtube to a 720p mp4 file.
Total video Converter Lite - to convert the video to GIF 320x240px (or thereabout) this resulted in a significant reduction in quality due to massive dithering
Image Magick - to convert to 32x32 BMPs

I have added a function to play back a sequence based on filename, a sequence array, a delay array and a playback times.

The function has a simple compensation for load time when delaying between frames to ensure that the playback rate is correct (as long as the files are loaded fast enough).

To get the load time easily I made a small change to the bmpDraw function. It now returns the load time in milliseconds.

The code is not finished yet, but working. I still need to determine the number of frames in the sequence based on the size of the sequence array (should be a quick fix). In addition I need to include error handling and improve/polish the code.

  uint32_t seq[14] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13};
  uint32_t del[14] = {100,100,100,100,1000,100,100,100,1000,100,100,100,100,1000};
  
  sequencePlay("/0t/Tiny", seq, del, 2);

//--------------------
void sequencePlay(char *filename, uint32_t sequence[], uint32_t delays[], int playbackTimes){
  uint32_t loadTime, waitTime;
  char outputFileName[32];
//  int frames = sizeof(sequence) / sizeof(int); //incorrect - needs to be fixed
  int frames = 14;
  Serial.print("Frames: ");
  Serial.print(frames);
  for (int y=0; y<playbackTimes; y++){
    for (int i=0; i<=frames; i++){
      sprintf(outputFileName, "%s%d.bmp", filename, sequence[i]);
      loadTime = bmpDraw(outputFileName, 0, 0);
      waitTime = delays[i];
      if (loadTime < waitTime) delay(waitTime - loadTime);
    }
  }
}

//--------------------
uint32_t bmpDraw(char *filename, uint8_t x, uint8_t y) {

  SdFile   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 >= matrix.getScreenWidth()) || (y >= matrix.getScreenHeight())) return 0;

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

  // Open requested file on SD card
  bmpFile.open(filename, O_READ);

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

        goodBmp = true; // Supported BMP format -- proceed!
        Serial.print("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) >= matrix.getScreenWidth())  w = matrix.getScreenWidth()  - x;
        if((y+h-1) >= matrix.getScreenHeight()) h = matrix.getScreenWidth() - y;

        for (row=0; row<h; row++) { // For each scanline...
          //          tft.goTo(x, y+row);


          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.curPosition() != pos) { // Need seek?
            bmpFile.seekSet(pos);
            buffidx = sizeof(sdbuffer); // Force buffer reload
          }

          // optimize by setting pins now
          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 Matrix format, push to display
            rgb24 color;
            color.blue = sdbuffer[buffidx++];
            color.green = sdbuffer[buffidx++];
            color.red = sdbuffer[buffidx++];

            matrix.drawPixel(x+col, y+row, color);

          } // end pixel
        } // end scanline
        matrix.swapBuffers(true);
        Serial.print("Loaded in ");
        Serial.print(millis() - startTime);
        Serial.println(" ms");
      } // end goodBmp
    }
  }

  bmpFile.close();
  if(!goodBmp) {
    Serial.println("BMP format not recognized.");
    return 0;
  }
  else {
  return millis() - startTime;
  }
}

Still haven't had a chance to work on dynamically loading images, but I did try out your sequencePlay function. Very nice.  Looks like the problem is trying to get the size of an array pointer.  According to http://http://stackoverflow.com/a/10349610 you have to get the length of the array and pass it to the function as another parameter. Just tried it and it worked.

I added a slight variation, for animations where each frame is shown only once, and each has the same duration:

sequencePlay2("/pman/pman", 1, 127, 30);

//--------------------
void sequencePlay2(char *filename, int playbackTimes, int frames, uint32_t waitTime) {
  uint32_t loadTime;
  char outputFileName[32];
  Serial.print("Frames: ");
  Serial.print(frames);
  for (int y=0; y<playbackTimes; y++){
    for (int i=0; i<frames; i++){
      sprintf(outputFileName, "%s%d.bmp", filename, i);
      loadTime = bmpDraw(outputFileName, 0, 0);
      if (loadTime < waitTime) delay(waitTime - loadTime);
    }
  }
}

Thanks for the input on the sizeof issue!

Lol. I had intended to create a similar function to your sequencePlay2 today :)

Right before I went to bed Yesterday I started on some code to handle frames stored in multiple directories. It's working great but I still need to convert it into a function. It would also be good to be able to specify the sequencing scheme (e.g. 1,2,3 vs 000,001,002) and starting frame number.

  int directory;
  int framesPerDirectory = 100;

  for (int i=1; i<=516; i++){
    directory = i/framesPerDirectory;
    sprintf(fileName, "/p%d/pman%d.bmp", directory, i);
    delay(100 - bmpDraw(fileName, 0, 0));
  }

Hello All

I have been having fun writing graphics routines for my LED Matrix using Louis' driver and I thought I would pass along what I have done. Attached to this note is a zip containing what I call the Contemplator sketch. I call it this because when this sketch runs I like to stop and just watch it for a while. All of the graphics routine are very colorful (probably over the top) and are real attention getters.

It would be easy to incorporate any graphics routine you have written and have the Contemplator run them as well.

People are free to use this code anyway they want as I place it in the public domain. Louis you could use it as another demo if you wish.

Anyway have fun and let me know what you think?

Very cool, Craig, thanks for sharing!

I finally got images and animations loading dynamically from the SD card, using a simple text format for controlling the animations.  Here's what I have so far: https://github.com/pup05/Teensy32x32MatrixSlideshow (https://github.com/pup05/Teensy32x32MatrixSlideshow)

edit: This is my first Arduino project, and really the first C code I've written (I code in C# professionally).  Please let me know if you find any bugs or have any suggestions, comments, etc you'd like to contribute.  Thanks to kjetilei for the modified bmpDraw function!

edit 2: I updated the project with support for a root index and nested indexed directories, giving you complete control of playback without recompiling.  You can keep all of your images/animations on the SD card, and just change the index files to control which images/animations are displayed and in which order.

@craiglindley: thanks for sharing the demo!

Pup05: Great progress! I finally got some spare time this evening and tested your code. I had to change the code somewhat since TextEdit on Mac did not add r, only n. I'm also in the progress of adding support for anims split up in sub folders without the need for index.txt files per sub folder. Its working at the moment with hard coded values since I'm not finished with parsing the special formatting. I might finish it tomorrow night if I get some spare time.

The format used in the index.txt file could be something like:
!,p,0,5,100,pman,1,100

! = identify function - should be replaced by something more meaningful
p = sub directory name
0 = sub directory start number
5 = number of sub folders (not really needed)
100 = number of frames per sub folder
pman = file name
1 = file start number
100 = milliseconds per frame

WIP building on Pup05's code:

  while ((c = indexFile.read()) > 0) {  
    //    Serial.print("char: ");
    character = (char)c;
    Serial.print(character);
    if(character == '!') {
      while ((c = indexFile.read()) > 0) {
        //insert code to extract anim config data
      }
      char fileName[256];
      char directoryName[] = "/06pacman/";
      char subDirectoryName[] = "p";
      int subDirectoryNo = 0;
      char imageName[] = "pman";
      int startNo = 0;
      int noOfFrames = 512;
      int delayAmount = 100;
      for (int imageNo=startNo; imageNo<=noOfFrames; imageNo++){
        subDirectoryNo = imageNo/100;
        sprintf(fileName, "%s%s%d/%s%d.bmp", directoryName, subDirectoryName, subDirectoryNo, imageName, imageNo);
        delay(delayAmount - bmpDraw(fileName, 0, 0));
      } 
    }
    if(character == ',') {
      //      Serial.println("");
      foundComma = true;
    } 
    else if(character == 'r') {
      //do nothing with it
    } 
    else if(character == 'n') {
      //      indexFile.read(); // throw away n
      Serial.println("found line ending");
      imageFilename.toCharArray(imageFilenameChar, sizeof(imageFilenameChar));

      if(delayString.length() < 1 && !imageFilename.endsWith(".bmp")) {
        imageFilename.concat("/");
        loadAnimation(imageFilename);
        foundComma = false;
        imageFilename = path;
        delayString = "";
        startTime = millis();
      } 
      else {
        waitTime = delayString.toInt();
        loadTime = millis() - startTime;
        loadTime += bmpDraw(imageFilenameChar, 0, 0);
        if(loadTime < waitTime) delay(waitTime - loadTime);
        foundComma = false;
        imageFilename = path;
        delayString = "";
        startTime = millis();
      }
    } 
    else if (isdigit(character) && foundComma) {
      //      Serial.println("found delay digit");
      delayString.concat(character);
    } 
    else {
      //      Serial.println("found image filename character");
      imageFilename.concat(character);      
    }
  }

Time for an update.  I haven't officially announced that the board is available or the code is published, but it's all online now, and I have a web shop that is accepting orders.  I just need to take a few nice photos and shoot a video of the FeatureDemo example sketch before I consider my site ready.  If you can't wait, I'll give you a hint: the SmartMatrix Shield is the first product from my new brand "Pixelmatix".

I've been working on some non-Arduino software/firmware for the display, and it's coming along nicely, I'll have a big announcement around Bay Area Maker Faire.  Please send me a message if you're going to the show and would like to help out with my booth either with setup on Friday, or during the show on the weekend.  In addition to SmartMatrix kits and samples of the enclosure, I'll have some extra passes that will also get you in to the Maker party on Friday afternoon/evening.

I've been working a lot on a simple (easy to manufacture) enclosure design for the 32x32 P5 display.  I'm cutting the enclosure out of transparent gray acrylic (1/8" 2064), that gives good contrast when there's both dark and light on the screen at the same time.  Behind is some thin white plastic to diffuse the light and hide the LEDs.  Simple machine screws and standoffs hold the front and back of the display together. 
[attachment=5]
[attachment=4]

I have to give credit to Al Linke's Pixel, which is where I got the idea for the dark acrylic, nice-looking screw heads, and standoffs combination for this case.
http://https://www.kickstarter.com/projects/alinke/pixel-led-art

The Shield can be soldered directly to the display input connector after removing the plastic shroud from the connector.  I haven't soldered it yet, but to keep the cables from sticking out the back, I'll remove the 4-pin power connector and solder power and ground wires between the shield and display.
[attachment=3]
[attachment=2]
The back of the display is left open for two reasons: to leave room to add more electronics, and to more efficiently use a sheet of acrylic.  The two small pieces for the back can be tiled next to the large front piece, using up space where a full square would not fit and would otherwise be wasted.

[attachment=1]

I want to tweak the design of the back pieces.  Instead of having the convex area following the plastic frame of the display, I want to fill that area with useful stuff: holes for hanging the display, mounting holes for adding more electronics, a hole for adding strain relief to the USB cable (the micro USB connector on the Teensy 3 is fragile - I've broken several already).

I could use some suggestions on exactly what holes to add.  Here's my plan so far, drawn in silver sharpie on the plastic:  three hanging holes with slots to support hanging in two directions, and a slot by itself to add a cable tie to provide strain relief for the USB cable.  The holes will be 8mm diameter, slots 4mm wide.

[attachment=0]

How far apart would you like the hanging holes to be?  I'm in the US so I was going to make the holes separated by a multiple of 1 inch if possible, or 1/2" if not.  Is a multiple of cm good if you're not in the US?  Does it matter?

What other mounting holes and what size would you like to see?  I'm thinking 3.5mm for M3 screws, which is what I'm using for the rest of the hardware in the enclosure.  A grid with 10mm spacing?  Larger?

Here's a PDF (that should open in Illustrator as well) with the current progress of the design.  This will be published under creative commons BY-SA just like the board when complete.

http://https://www.dropbox.com/s/las3ho5csioqn5w/SmartMatrixP5Cover-20140501.pdf

---

One Teensy drive only one matrix?, or can they be chained?

Since the board are sent from china, it's too bad the shop also doesn't sell the matrixes.

I guess for hanging holes, it doesn't matter?, make an sheet that can be used as an template for drilling where one want to hang it.
10mm spaced grid is nice for mounting on various things, and m3 is kinda standard on many board it seems?

Btw, very good site you set up there, very good documented project, like it!

That looks fantastic, Louis!  I had planned to use female headers so everything could easily be disassembled without desoldering, but that looks so good and low-profile, I'm rethinking...  :)

[quote author="neslekkim"]One Teensy drive only one matrix?, or can they be chained?[/quote]

As of now the SmartMatrix Library only supports one display, but an awesome beta tester modified it to support multiple displays.  You can use his modifications, and they will hopefully make it into the next major release of the library as well:
http://https://github.com/pixelmatix/SmartMatrix/pull/2

Since the board are sent from china, it's too bad the shop also doesn't sell the matrixes.

Agreed, I'm working on this.  Two major hangups: I don't have a power supply vendor yet, and there seem to be high minimums for a 5V 4A supply (1000 pieces).  Importing a Teensy 3.1 into China costs 17% VAT, so I could barely make anything off of selling the Teensy.  Would you buy a display and shield kit without a power supply and Teensy?  That seems incomplete to me.

Btw, very good site you set up there, very good documented project, like it!

Thanks!

[quote author="EmbeddedCreations"]

Since the board are sent from china, it's too bad the shop also doesn't sell the matrixes.

Agreed, I'm working on this.  Two major hangups: I don't have a power supply vendor yet, and there seem to be high minimums for a 5V 4A supply (1000 pieces).  Importing a Teensy 3.1 into China costs 17% VAT, so I could barely make anything off of selling the Teensy.  Would you buy a display and shield kit without a power supply and Teensy?  That seems incomplete to me.
[/quote]

Yes, I would.
Why?
Teensy ships cheaply and fast http://pjrc.com/teensy/ (http://pjrc.com/teensy/) (newer paid customs)
(And I already have lots of them, 3.0 and 3.1)

Adafruit sells display, shipping is fairly cheap, but must pay %25 tax (here in norway)

Powersupplies, I don't use chinese ones, they are always bad, don't trust them.
I either buy powersupplies here in norway, often in germany or in uk (when I find with detachable cord)

This is awesome, ordered a board and waiting eagerly for the mail saying it's shipped! :)

I've tried wiring up a 32x32 Sparkfun matrix directly to a Teeny 3.1 on a breadboard.  The test app gets stuck in the first call to swapBuffers() - "while (swapPending);" continues looping forever, which I think means an interrupt isn't happening or isn't being processed.  Any advice on how to debug?

The same panel works with the Adafruit library and an Arduino Uno (though it's painfully slow).  I've triple-checked the wiring between the panel and the Teensy, especially the two Teensy pins (3 and 8) that are connected to the display's latch pin; though it's entirely possible I've missed the same mistake several times, I wonder if there's anything I can do in code or with a multimeter to figure out what's wrong.

Thanks!

[quote author="koala"]The test app gets stuck in the first call to swapBuffers() - "while (swapPending);" continues looping forever, which I think means an interrupt isn't happening or isn't being processed.  Any advice on how to debug?[/quote]

Hmm, no one has had this issue before to my knowledge.  Can you simplify your app down to the basics and see if it works?

Try this extremely simple sketch:

#include "SmartMatrix_32x32.h"

SmartMatrix matrix;

void setup() {
    matrix.begin();
}

void loop() {
    rgb24 color = {random(255), random(255), random(255)};
    matrix.drawString(0,0, color, "Hello");
    matrix.swapBuffers();
    delay(1000);
}

How do you know swapPending is looping forever?

Hi Louis,

Thanks, I gave the minimal sketch a try.  Same result: it runs into swapBuffers and but never gets past "while (swapPending);".  I checked using Serial.print statements to pin down how far execution runs.

void loop() {
    rgb24 color = {random(255), random(255), random(255)};
    matrix.drawString(0,0, color, "Hello");

    Serial.print("Before swapBuffers()n");
    matrix.swapBuffers();
    Serial.print("After swapBuffers()n");

    delay(1000);
}

and in MatrixGraphics.cpp:

// waits until swap is complete before returning
void SmartMatrix::swapBuffers(bool copy) {
    swapPending = true;
    Serial.print("swapPending = true");

    int swapCounter = 0;
    while (swapPending)
	{
		Serial.print ("swap still pending: ");
		Serial.print (swapCounter, DEC);
		Serial.print ("n");
		swapCounter++;
	}

    Serial.print("swapPending = false");

    ...
}

I left it running for a few minutes and the swapPending loop kept counting.  Same thing without the counter, execution gets to the loop but not beyond.

Both the matrix and Teensy are brand new, perhaps I should spend some time testing them.

Hi Koala, can you run the same thing with nothing connected to the Teensy but USB?

I made updates to the enclosure as I discussed.  I couldn't find a good distance based on 0.5in spacing to space the mounting holes where they would be centered and have room for a screw to fit into the slots, but I found a 11cm spacing worked well.  I added two rows of 3.25mm diameter mounting holes, spaced 10mm apart for adding more electronics inside the display, and the slot for USB.

[attachment=1]

I increased the diameter of the holes used for screws to hold the enclosure to the display, and the standoffs to the back.  I used 4.5mm diameter to fit an M3 flathead screw with 5.5mm diameter head.  This will allow for even lower profile on the back of the display, but adds the risk of cracking the acrylic if tightening too hard, or with a screw off center.  I cracked one edge of the acrylic when testing with a 4.0mm diameter hole, but couldn't crack any of the 4.5mm with hand tightening and even flexing the standoff after attaching the screw.  4.5mm does allow the standoffs to slightly sink in to the hole, I'm not sure if this is going to be a problem.

[attachment=0]

I also soldered the shield inside the display, including removing the display's power connector and wiring jumper wires directly to keep a low profile.  The soldering required is a bit more advanced, as the power connector isn't easy to remove from the display without hot air, and there's not a lot of clearance when soldering directly to the displays data pins.

I'm going to build more of these and offer some for sale along with mounting hardware and plastic for diffusion, but I'll also post the design files if you want to get it cut yourself.  I'm not sure what services people use for laser cutting, I'm lucky enough to live close enough to NYC Resistor that I can head there and use the laser myself for a reasonable fee during their twice-weekly open houses.  Online I've looked at Pololu.com, and Ponoko.com.  Coincidentally, the size of the front panel fits into Ponoko's smallest panel with 1mm to spare.  If you have a favorite laser cutting service, let me know and I'll try to get some quotes for comparison.

---

[quote author="koala"] perhaps I should spend some time testing them.[/quote]

The (potential) solution came to me as I was trying to fall asleep. Do you have the latch line connected to two pins on the teensy as well as the display?  That line is an output on one pin, and an interrupt source on the other pin. That could explain the missing interrupt.

[quote author="EmbeddedCreations"]The (potential) solution came to me as I was trying to fall asleep. Do you have the latch line connected to two pins on the teensy as well as the display?  That line is an output on one pin, and an interrupt source on the other pin. That could explain the missing interrupt.[/quote]

Yes, Teensy pins 3 and 8 are tied together with the display's latch pin (14, the one labeled "STB" on the display PCB). Is that the correct way to hook it up?

This sounds like a great excuse to unpack my neglected oscilloscope :)

[quote author="koala"]Is that the correct way to hook it up?[/quote]

Yes, that's right.  Hmm, I'm out of ideas unfortunately.  Let me know what you see with the scope.

Any updates? I purchased 8 of the sparkfun panels and your project would greatly simplify wiring.

Hi Tim, it looks like you found my store and placed an order.  Kits are back in stock a week earlier than I expected, so your order will ship in a day or two.

 If anyone else wants to place an order before I fully announce the site later this week, just search google for "SmartMatrix Shield", and in a few clicks you'll get to a page with a "Shop" link in the header.

Last night I got the Teensy SD adaptor (http://https://www.pjrc.com/teensy/sd_adaptor.html) wired up to the SmartMatrix board, and it works great!  Anyone had any luck with any WiFi or Bluetooth boards?  I'm thinking about ordering a Bluefruit (http://http://www.adafruit.com/product/1588) or Bluefruit LE (http://http://www.adafruit.com/products/1697).  Looking at the pinouts, I think the Bluefruit might work, but not the Bluefruit LE.

Last night I got the Teensy SD adaptor wired up to the SmartMatrix board, and it works great

Very cool!  I left the back of the enclosure open and added mounting holes so people could add on to the SmartMatrix Shield with storage or connectivity modules, among other things.  Unfortunately I haven't seen any SD Card breakouts that have mounting holes yet, but there's always double-stick tape for that.

Looking at the pinouts, I think the Bluefruit might work, but not the Bluefruit LE

I've only glanced at the Bluefruit LE pinout, but I don't see an obvious reason why it wouldn't work.  Why do you think it's incompatible?

Yeah, the Teensy SD Adaptor doesn't have any mounting holes, but it's tiny.  Do you have the enclosure available for purchase?  Or the design files you used?  I know you're probably busy getting ready for the Bay Area Maker Faire.  I wish I was going or lived nearby, I'd love to help.

I'm pretty new to Arduino/Teensy dev, so if you think the Bluefruit LE will work, I trust you.  :)  I just looked at the wiring guide (http://https://learn.adafruit.com/getting-started-with-the-nrf8001-bluefruit-le-breakout/hooking-everything-up), and it looks like the Bluefruit LE needs pins 2 (interrupt), 9 (RST), and 10 (REQ) which are crossed out as used on the SmartMatrix pinout.  I also have the Teensy SD Adaptor (http://https://www.pjrc.com/teensy/sd_adaptor.html) wired up, which uses 11 (MOSI), 12 (MOSI), 13 (CLK), and 15 (CS), but I think those can be shared, right?

[quote author="Pup05"]Do you have the enclosure available for purchase?[/quote]

Not yet.  Yes, I'm busy prepping for Maker Faire right now, but plan to publish the laser designs next week.

[quote author="Pup05"]it looks like the Bluefruit LE needs pins 2 (interrupt), 9 (RST), and 10 (REQ) which are crossed out as used on the SmartMatrix pinout[/quote]

The pins in the wiring guide are for connecting to an Arduino, and the Arduino pin numbers don't apply to the Teensy 3.  You should be able the share some of the SPI signals, however, you are correct in that there is a conflict: if you're using the SD card plus the Bluefruit LE, you need two SPI chip selects, and there's only one accessible on the SmartMatrix Shield.  I'm not sure how difficult it would be to use a normal GPIO as a replacement for one of the chip selects.  I'm also not sure what libraries are needed to communicate with the Bluefruit LE, and if they are compatible with the Teensy 3 (probably not).

No worries, I know you're busy, totally understand.

Yeah, I thought it'd be simpler to use the regular Bluefruit, as it just uses UART hardware serial communication, using pins 0 and 1.  Bluefruit LE is cheaper, and would work with iOS, but it looks much more complicated to use.  I'm really only interested in PC and Android support anyway.

Just a quick update to let you know what I'm showing at the Bay Area Maker Faire.
Pixelmatix Blog - Fadecandy and the Aurora Display (http://http://blog.pixelmatix.com/2014/05/17/AuroraDisplay/)

The SmartMatrix Shield is available for purchase, and is shipping now.  Visit the "shop" link in the header of SmartMatrix Docs (http://http://docs.pixelmatix.com/SmartMatrix/) to purchase.

All source and the hardware design is up on GitHub, view the link at SmartMatrix Docs.  The board file for the shield is up as an OSH Park shared project, use google to find it.

In the coming weeks, I will provide a binary that adds Fadecandy compatibility to a Teensy 3.1 running on the SmartMatrix Shield (or wired up manually with the same pinout).  At first it will just be compatible with a 32x32 display, but 16x32 will come after, along with the full source (I'll explain why it's temporarily closed source later).  I'll put some video up after I get back from travel.

In doing some programming on the matrix, I found I needed to clear small areas of the display so I grabbed the code for the drawString function and modified it. I think a function like this would be a valuable addition to the API.


extern bitmap_font *font;

void clearString(int16_t x, int16_t y, rgb24 color, const char text[]) {
    int xcnt, ycnt, i = 0, offset = 0;
    char character;

    // limit text to 10 chars, why?
    for (i = 0; i < 10; i++) {
        character = text[offset++];
        if (character == '')
            return;

        for (ycnt = 0; ycnt < font->Height; ycnt++) {
            for (xcnt = 0; xcnt < font->Width; xcnt++) {
                matrix.drawPixel(x + xcnt, y + ycnt, color);
            }
        }
        x += font->Width;
    }
}

I got one of these at Maker Faire. Nice work!

When can we expect the Fadecandy firmware?

I purchased one of your 32x32 sparkfun kits last weekend at the Maker's Faire in SF.  I assembled the shield per the instructions on your site (great, detailed instructions by the way) and was able to hook it up and have the display working using the Teensy 3.1 that it came with.  I downloaded the 1.0.5 version of the Arduino app which is integrated with the 1.18 version of the Teensy app and downloaded the v 1.0 of SmartMatrix_32x32, set Toos | Board to Teensy 3.1, set Tools | CPU Speed to 96 MHz (overclocked) and selected the examples | SmartMatrix 32x32 Feature Demo.  For reference, I opted to drive the board from the USB power ( so I didn't cut trace or add diode), and decided to connect the shield directly to the input header on the display. Note: in this configuration the USB cable physically interferes with the power cable as it enters the display.

The problem that I am seeing is that only rows 1-8 and rows 17-25 are ever displayed.  Rows 7-16 and 26-32 stay dark.

I'm not sure if I have a defective display, am experiencing a software-related glitch or somehow messed up when assembling the shield.  It appears that the software is attempting to drive it correctly as a 32x32 display ( Given my symptoms would you have any pointers how to triage this issue further?  I suspect it might be a bad solder job and one of the connecting pins is not connected or is shorted. I have your basic multimeter but no oscilloscope to pursue this further.

I used my finger and when I touch pins that correspond to demux lines B,D -- I can get the lights in those unlit rows to light up (though not quite sure if they are  lighting up with correct content).  SO I suspect the issue lies with those two pins (which are referred to as ADX1, ADX3 on the SmartMatrix schematic and that since the capacitance of my finger is affecting those pins they might not be connected to the teensy.

[quote author="photonburst"]The problem that I am seeing is that only rows 1-8 and rows 17-25 are ever displayed.  Rows 7-16 and 26-32 stay dark.[/quote]

Hi Photonburst, I believe you have either unsoldered or a cold solder joint on one of the address pins.  I would use your soldering iron to heat up those pins again, and look to make sure it's a good solder joint with enough solder.  From your description it sounds like the issue is on the 2x8 header, not on the connection between the SmartMatrix Shield and the Teensy.

[quote author="tlr"]When can we expect the Fadecandy firmware?[/quote]

The Fadecandy server source and binaries are up now, if you've used Fadecandy with a Teensy 3.0 before you should be able to make it work using the server binaries and firmware binary that's up on a GitHub.  Instructions are coming today that will explain everything.  Watch this post for more details:

https://muut.com/pixelmatix#!/support:aurora-dispay

[quote author="craiglindley"]In doing some programming on the matrix, I found I needed to clear small areas of the display so I grabbed the code for the drawString function and modified it. I think a function like this would be a valuable addition to the API.[/quote]

Hi Craig, can you share a use case for this function?  I don't immediately understand why it would be used just from the code.  It looks like it's printing rectangles of the size of your font in the color you provide, up to the length of the string referenced.  If you give me some context I'm sure it will make sense, and I'll see about adding it to the library.

Hi Louis,

In the clock application I wrote using the LED Matrix I have text fields on the display where the user sets the time and date using an IR remote. The user can scroll the time up and down using keys on the remote before pressing a button to commit the minutes value, for example. This is taking place in a small portion of the matrix which has other stuff being displayed. Before writing the clearString function I had to clear the complete matrix (fill with background color) and redisplay all of the other info on the screen between each user change of the minute count. Using clearString I clear only the area occupied by the minutes display and the remainder of the screen is left untouched. In my first attempt at clearing a small area of the screen I tried to write a string of space characters in the background color over the text area but the library code writes nothing to the display when asked to write a space so that didn't work. Hence the clearString function.

I hope this makes sense.

Hi Craig, that makes perfect sense.  I think there's a different way to do it that might be more intuitive.  I thought I wrote this function already and just checked my code to make sure it wasn't there, I must have just planned to write it.

Instead of just

void drawString(int16_t x, int16_t y, rgb24 charColor, const char text[]);

Let's make an overloaded function that includes rgb24 backgroundColor in addition to charColor.  The drawing function will fill each pixel for each char with the backgroundColor and then put charColor on top.

Now you can update your clock digits with one function call.  If you want to clear the display completely, you can write a string of spaces like you suggested.  Sound good?

That would work perfect. Thanks Louis

My SmartMatrix shield arrived today.  Easy assembly (except for when I put the connector on the wrong side of the board and had to desolder it... grr...) and it worked perfectly on the first try.  Great work, Louis!

This is using the same 32x32 same panel which gave me trouble when wired up directly.  I never did figure out what wasn't properly connected.  The shield is so much easier and neater, though, that I recommend everyone just start with it if they can.

Hi Koala, thanks for the recommendation!  Putting the connector on the wrong side is such an easy mistake to make, but hard to fix, at least you were able to desolder.  I've done that at least once myself.

I can't wait to get my board and start playing.. Hurry up Mr. Mailman!!!! :)

What's the status of chaining? How hard would it be to get to work with Fadecandy? I'd love a 64x64 Fadecandy display...

Hi tlr,

I would love one as well. :-)  I will at least try to see if this is possible, but don't expect it for a couple months.  First I need to add support for a >32x32 pixel display in the SmartMatrix library.  Then I need to test to see if Fadecandy will still look good when driving that many pixels.  Assuming the test is promising, then I need to cleanly integrate Fadecandy and SmartMatrix with support for such a large display.  It will take time.

Just a heads up that in addition to the SmartMatrix Shield Kit being available through my website with shipping from China, it will be available from Adafruit shortly.  I'm not sure when they will be available for purchase, but they received a small quantity from me Tuesday this week, and the listing is up here:
http://https://www.adafruit.com/products/1902

Hello all,

Like many of you I've been interested in displaying animated GIFs on my Smart Matrix display. In reading this blog I've noticed that many people are using external tools to convert the GIFs to individual frames, then storing the frames on an SD card as BMP files and then reading the frame files back for display. As I've also read there are performance issues with this approach caused by having lots of files in directories on the SD card.

As an experiment I decided to not go that route but instead use the raw horse power of the teensy3.1 to decoded the animated GIF files in real time. Much to my surprise this techniques works beautifully with no need for the 100's of frame files on the SD card. I've attached a zip file to this note that has the code in it. Please note this code probably still has bugs in it but seems to work for the most part. I plan to optimize this code in the future but I seem to have fried my teensy3.1 and am waiting a replacement.

To use this code you must copy all of the animated GIF files to a "gifs" directory on the SD card. Please note that the GIF files must be in 8.3 filename format.

To change which animated GIF to display change the define in AnimatedGIFs.ino from

#define TEST_GIF_FILE "/gifs/ball.gif"

to say

#define TEST_GIF_FILE "/gifs/colors.gif"

I've also included code that caches the names of the GIF files found in the gifs directory and with a small change in the sketch can randomly pick a GIF file to display.

A request: does anyone have the original lechuck animated GIF file ? I would like to add it to my collection for display on my smart matrix. If you could email it to me at calhjh@gmail.com I would appreciate it.

Anyway, have fun with this. I certainly am.

Craig Lindley

Hi Craig,

This is awesome, I'm seriously impressed!  I'm going to get an SD card wired up to my SmartMatrix Shield as soon as I can to try this out.

One thing I forgot to mention. The animated GIF files must have a 32x32 resolution to work. Any other size and the program will malfunction magnificently.

Craig Lindley

I wired up a Micro SD card adapter to my SmartMatrix Shield today, and tried the gif decoder example, and it worked well, though I do see some flicker.  Craig, are you seeing that on your setup as well?  It seems to happen in just some parts of the image and repeats consistently when the animation repeats.  In the default ball.gif animation there was a lot of flicker, especially in the top row of the animation.  I did try two SD cards from different manufacturers to see if it was a slow SD card causing the flicker, but it looked the same on both.

Anyway, I'm not complaining, I'm just curious if this is specific to my setup or not.

Whoa! Great work Craig!

I just saw your post about the GIF progress but haven't been able to test the code yet.

Attached you will find the converted 32x32 LeChuck GIF anim I made based on this anim: http://www.neophilia.de/MonkeyIsland/lechuck_ani3.gif (http://www.neophilia.de/MonkeyIsland/lechuck_ani3.gif).

---

Louis,

I haven't seen any flickering. But if you notice in the code I clear the screen before each pass of the animation so that could be responsible.

kjetilei

Thanks for lechuck. I'll add it to my collection of animations.

Louis,

As soon as I get my new teensy3.1 and your shield I'll do more testing.

[quote author="craiglindley"]I haven't seen any flickering. But if you notice in the code I clear the screen before each pass of the animation so that could be responsible.[/quote]

I looked at that briefly, and I don't think the screen blanking is a problem, though I could be wrong.  I did see a bunch of warnings when compiling the sketch, but it did compile, so I didn't dig into why.  I attached a selection of the warnings.  Do you see these when you compile?

I upgraded Teensyduino to 1.19 and I'm using sdfatlib20131225, maybe I'm using different versions from you?

Louis,

Yes I saw those but only one is related to the code I wrote which I will eventually fix. Something somewhere is redefining PROGMEM stuff. It looks like the sdfat includes but its hard to tell. I wish I could look at this today but I don't expect my teensy 3.1 until Monday or Tuesday.

I traced the warnings back to SdBaseFile.h, which defines PROGMEM and some other things before including arduino.h, which in turn includes avr/pgmspace.h, which redefines PROGMEM, etc.  I moved #include "avr/arduino.h" to the top of the file and no more warnings.  No change in flicker on my display though.

Hello,

I've just updated my realtime GIF animation code to version 1.1, fixing numerous bugs and adding a bunch of 32x32 animated GIFs. Now the animations are smooth and flicker free. The code is too big to post here (> 1 MByte) so if you are interested in getting a copy for now, send me your email address (to calhjh@gmail.com) and I will send you a copy. Maybe Louis will include this code in his repository at some point.

Have fun,

Craig Lindley

I decided to post the new version of the code for realtime animated GIFs without the GIFs as it is small enough to be upload here.

Have fun,

Craig Lindley

Here is another application I wrote for the pixel matrix driver. Check out:

http://www.craigandheather.net/celelightappliance.html (http://www.craigandheather.net/celelightappliance.html)

I will document the hardware and software on this web page in a day or two.

Craig Lindley

Hi Craig,

That is a Realy nice implementation/package!

For the menu I would suggest that the scroll speed is bumped up a little bit, both for more fluent scrolling and faster reading/skipping to next element. It could also be an idea to start the text from the middle when changing to a new menu item instead of "outside" the right side - once again for faster reading/menu shuffling.

I haven't looked much into the RTC of the Teensy. How accurate is it? Some of the cheap eBay RTCs are pretty worthless in a clock "appliance" with way too much drifting and I ended up buying one of the better ones for an alarm radio I built in December.
Kjetil

Very nice, Craig!  I don't know why it never occurred to me to use an IR remote to control the board.  I've been investigating bluetooth/wifi, and currently have a Raspberry Pi hooked up as a FadeCandy controller and providing a web UI.  Your solution is way simpler, less bulky, requires less power, and less expensive.  I'm going to order an IR remote and give this a try.  Mind sharing your Teensy sketch?  Thanks!

I agree, an IR remote makes a lot of sense as when you're controlling the display, you more than likely have line-of-sight to the display.  Great work Craig!

Guys,

Attached is the Light Appliance sketch with supporting code. Note in the code there are defines which are currently all set to 1 indicating that the named hardware is present. If you don't have the real time clock (RTC), for example, change the 1 to a 0. This will prevent the code supporting the RTC from being compiled into the sketch and will remove the time and date modes from the menu system. Same is true for the temperature sensor and the SD card.

// Define the optional hardware. If missing hardware set value to 0
#define HAS_RTC         1
#define HAS_TEMP_SENSOR 1
#define HAS_SD_CARD     1

Note also the presence of an IR detector/receiver is mandatory.

I will try and draw up a schematic for the optional hardware in the next couple of days.

If anyone makes improvements to the code please send me a note so I can improve my code as well.

Craig Lindley

Attached is a schematic of how I connected the SD card, IR receiver/detector, temperature sensor and RTC battery. I used Louis' pixel matrix shield and wired these components to the expansion connector.

Craig Lindley

---

Hello,

I've now reworked the AnimatedGIF and Light Appliance sketches into hopefully their final form and I will stop spamming this list so often. If you go to craigandheather.net/misc you will find the following files:

Lindley_Animated_GIFs_Collection.zip which is a collection of GIFs used by both AnimatedGIF and LightAppliance sketches.
Lindley_AnimatedGIFS_V1.2.zip which is the new version of the AnimatedGIFs sketch
Lindley_LightAppliance_V1.1.zip which is the new version of the LightAppliance sketch.

The Light Appliance now has a general animations mode in addition to a Christmas mode, a Halloween mode, a Valentines mode and a 4th of July mode.

For anyone interested in more detail about the Light Appliance, I'm writing an article for (I believe) the Oct issue of Nuts and Volts magazine which will detail the hardware and software necessary to recreate the Light Appliance.

Hope you find this helpful. Cheers,

Craig Lindley

Hi Craig,

Thanks for the updates - downloaded :)

I hope you continue to post in this thread - I haven't seen any spamming ;)

If time permits I'll most likely implement IR control (and wifi?) to my setup in the autumn and your LightAppliance is a great starting point. Thanks.

Kjetil

I finally got my SmartMatrix mounted nicely.

[attachment=2]

I picked up a 8"x8" black shadow box from Michaels (http://http://www.michaels.com/shadowbox-with-signature-mat-black-8x8in/10223090.html).

[attachment=1]

The panel fits perfectly, just had to shim it with a little bit of folded card stock on each side.  There's plenty of room for the Teensy and SmartMatrix board, wiring, SD card, etc.  I cut out a piece of white printer paper to size, and placed it between the panel and the glass for a bit of diffusion.  The magnetic feet that came with my panel from Adafruit fit perfectly, and keep the panel pushed against the paper and glass.  I cut a notch in the bottom of the back, just big enough for the power cord, USB cable, and IR receiver.

[attachment=0]

I loaded up Craig's LightAppliance sketch and made a few minor modifications, loaded up my SD card with the animated GIFs I wanted, and everything works great.  Unfortunately, I already had my Teensy soldered on to the SmartMatrix board, and didn't feel like pulling it off to solder the RTC crystal on to the back.  I might do that later, and add the temperature sensor.

A huge thank you to Louis for the fantastic SmartMatrix board and library, Craig for the LightAppliance sketch, and everyone else who's contributed on this forum!

---

Pup05,

Nice job. Just wanted to mention you can solder the crystal to the top of the board as well so you wouldn't have to unsolder the teensy. I did that once and it worked fine.

Hi Pup05,

Great Build!  Printer paper does work great for a diffuser when you have glass and the display right behind it.  I still have an Ikea 9x9" frame I keep meaning to put a display in.

Hi Craig,

I agree with Kjetil, I don't see any spamming either.  Please post any updates you want to share, and definitely post when your article is in Nuts and Volts so we can look for it.

I've added a games menu to Craig's LightAppliance sketch. So far I have basic implementations of breakout, snake, and pac-man. They are all playable, but still need work (currently working on ghost AI in pac-man).  I'll add videos later when I get a chance.

Craig, do you mind if I upload the LightAppliance source to a github repository? I can upload your unmodified source, unless you'd prefer to. Either way, then I can fork it to include my changes.

Pup05,

That is cool. Now it will be able to play games to. I have another addition as well which I will be publishing in the next week or so.

I don't mind if you upload the code to a repository but I think that Louis might have already. I wouldn't do anything until Louis responds.

It would probably be best if there was a central repository for the code then we can all work on it.

Craig

Thanks Craig, looking forward to your addition.  Any hints what it is?  :)

Louis has published his SmartMatrix library on github, and has forked fadecandy to work on the teensy, but I don't see that he's published your LightAppliance sketch.  Here are his repositories: http://https://github.com/pixelmatix. I'll wait for word from him though.  Thanks!

I'll publish them on GitHub tonight if I have time.  It will be great to have people sharing changes in an easy way.

OK, I was able to put them up pretty quickly, adding the MIT license for Craig in the process.  I'll put up a README and product description with some links to Craig's site later, I'm out of time now.

http://https://github.com/pixelmatix/AnimatedGIFs
http://https://github.com/pixelmatix/LightAppliance

Hello, it's me again. Here is a new application for the SmartMatrix. Check out the documentation below. Code is attached.

Painter - SmartMatrix / Teensy 3.1 Application

*** Turns your SmartMatrix into a IR controlled paintable canvas ***

Hardware Requirements (just like the Light Appliance):
Must have a working SmartMatrix device
Must have the SD card chip select connected to Teensy 3.1 pin 15
Must have an IR Receiver/Detector connected to Teensy 3.1 pin 18
Must use the SparkFun IR remote control

Written by: Craig A. Lindley using some code written by Louis Beaudoin (Pixelmatrix)
Version: 1.0
Last Update: 07/11/2014

The Painter sketch has the following features:

* Able to paint using a palette of 36 colors
* Supplied with 8 painting tools for drawing:
  pixels, lines, circles, filled circles, rectangles, filled rectangles,
  triangles and filled triangles
* Able to save/load paintings to/from SD card

Using the PAINTER sketch

Once Painter.ino is downloaded to your Teensy 3.1/SmartMatrix you should see a
block cursor in the center of the screen. The color in the middle is the current
drawing color and the color of the surrounding pixels indicate which drawing tool
is selected. NOTE: the block cursor is never a part of drawings you create.
Think of it as floating above your drawing.

By default you should see a white pixel surrounded by four redish pixels.
White is the current drawing color and the redish pixels indicate the PIXEL
drawing tool is currently selected. Each drawing tools has an associated color.

You move the block cursor with the arrow keys on the remote. If you want
to color a pixel at the position of the block cursor click the select key in the middle
of the arrow keys. If you then move the block cursor you will see a white pixel
left behind.

Changing the Drawing Color

To change the drawing color, click the A button on the remote to bring up the color
palette. Use the arrow keys on the remote to move the white selection frame to the
color you want to use and then click the select key to select that color. After color
selection is performed, you will be transitioned back to the drawing screen with
the new drawing color in the middle of the block cursor. NOTE: you cannot see the
white color selection frame when it surrounds the white palette color. Select the
black drawing color to erase pixels in a drawing.

Changing the Drawing Tool

To change the current drawing tool, click the B button on the remote.
Ten icons representing the available drawing tools will be displayed. Upon
selection of a new drawing tool you will be immediately returned to the drawing
screen and able to use the new tool. You navigate to the tool of interest using the
arrow keys on the remote and you select the tool with the select key.

The tool in the upper left is the N or NEW tool which will erase the current
drawing allowing you to start a new one.

The F or FILL tool will fill the drawing screen with the current drawing color.

The single redish dot represents the PIXEL tool which allows you to set a single
pixel on the screen at a time to the current drawing color.

The LINE tool will draw a line between pairs of screen coordinates you choose.

The CIRCLE tool is used to draw circles on the screen.

The FILLED CIRCLE tool draws filled circles of the current drawing color on the screen.

The RECT tool draws a rectangle between pairs of screen coordinates you choose.

The FILLED RECT tool draws a filled rectangle on the screen.

The TRIANGLE tool draws a triangle between three screen coordinates you choose.

The FILLED TRIANGLE tools does the same but fills the triangle with the drawing
color.

Each drawing tool requires a specific number of parameters. To draw a line,
for example, requires two points to be defined in your drawing. When the LINE
tool is selected the first time you click the select button nothing will happen.
When you move the block cursor some where else and click the select button again,
a line will be drawn between the two points. Similarily two points are required
to define a rectangle but three points are required to define a triangle.

Saving / Loading Drawings

Clicking the C button on the remote brings up the Save/Load screen. Here you use
the remote’s arrow keys to select a filename (filenames are F1 thru F9) and then
use the A button to save the current drawing to the selected file or the B button
to load the selected file to the screen, over writing whatever drawing was there.
Clicking the C button exits this screen and returns you to the drawing screen.

As always, have fun with this SmartMatrix application. If you find bugs or add
new features, let me know. My email address is: calhjh@gmail.com

Craig Lindley

Wow, Craig, you've been busy!  I haven't had a chance to check out your new painter sketch yet, but I just finished forking the LightAppliance repository and merging my changes in.  I apologize for the whitespace differences in a few of your files. I got tired of the Arduino IDE and switched to Visual Studio which I'm much more comfortable in, but I think it automatically reformatted a few files.

I was able to get the games mostly finished, I really just need to implement the AI for the last two ghosts in pac-man. http://https://github.com/pup05/LightAppliance

I've got to get an IR remote ordered, you guys are making cool stuff I want to try.

Yeah, I really cannot overstate how great Craig's IR input and menu system has been. It's so much simpler than anything else I've thought about or tried.

I added a README.md to my LightAppliance (http://https://github.com/pup05/LightAppliance) fork with links to videos of the three different games in action.

Oh, I forgot to mention that I also added the ability to interrupt the playback of an animated GIF (which is handy as some of them are quite long).  You can use the left and right buttons on the remote to skip forward and backwards.

I've never used git/github for source code control before so I have been reading up on it this afternoon. I know I need to fork Louis' repository of my code so I can make changes to it. My question is, how do you guys setup your local repository ? Do you set it up inside the arduino directory so you can compile directly within it or do you set it off to the side and copy modified files into it after they have been debugged?

I just set it up in the sketch directory so no copying files is required.  Just check in your changes periodically for local source control, then push your changes to github for sharing/backup.

I'm fairly new to github myself, and there are likely multiple ways to handle it. Louis could make you a collaborator in his repository, or you could fork it, and we could use pull requests to pull changes between the forks.

Let me know if you have any questions on using git or github.  It takes a while to get used to, but it's so much easier for collaborating than any other method I've tried.

Pup05,

Are you going to do a pull request when you are done adding your games/enhancements to the Light Appliance code so that Louis can pull your changes back to his repository? I am hoping that is what you are planning so that I can then pull them down into my repository and merge in new code I have written.

Craig Lindley

I'm still fairly new to git, so someone please correct me if I'm wrong, but I think if Louis wants changes in his repository, he can do a pull request from our respective repository forks.  Same goes for you and yours.  You get to pick and choose which commits you'd like to pull into your repository, with much less (if any) coordination than with svn.  So, for a simple example, your fork can keep the RTC enabled, and I can keep it disabled in my fork (until I get around to wiring it up).

I just pulled the changes from your fork to mine.  I had to handle a couple of merge conflicts in the LightAppliance.ino, but otherwise it handled the merge automatically.  I'd be glad to handle the pull from mine to yours, if you'd like, just let me know.  Same goes for Louis's repo.

Thanks Pup05. I think it is starting to make sense. I'm out today but I will attempt to pull your changes into my repo tonight or tomorrow. I assume this is all handled on the web and that when the merge is complete I just resync my local repo.
Please correct me if I'm wrong. I don't want to mess anything up.

CL

No problem, glad to help.  Yeah, you create the pull request on the github site.  It'll likely start out as pulling from yours to Louis' (since that's the way you usually go, from the fork back to the base).  So you'll have to switch them around.  I think this link should get you started:

https://github.com/pup05/LightAppliance ... master?w=1 (https://github.com/pup05/LightAppliance/compare/CraigLindley:master...pup05:master?w=1)

Once you create the pull request, if there are any merge conflicts github can't automatically handle (cases where we both modified a line) it'll show you instructions on handling it.  You'll have to do it locally on your box, through the git command line.

Let me know if you have any questions or problems, or if you'd like me to create the pull request from my end.

Pup05

Would it be possible to get your email address so we can take this discussion off line until we get things worked out? My email address is calhjh@gmail.com.

Well, I happened to see Craig created a GitHub account and had a more complete LightAppliance repo that was a fork of mine.  It didn't make sense for me to keep my repo now that Craig has an account, so I deleted it to try to make Craig's repo the base.  Instead it made Pup05's repo the base.  I hope I didn't screw anything up.

No problem Louis, we can work it out.  Sorry for hijacking your thread...  :)  We've moved our discussion to email and github.

Hello all,

Now the official GITHUB repository for the light appliance and the painter applications is:

https://github.com/CraigLindley (https://github.com/CraigLindley)

NOTE: Pup05 has integrated all of his games into the source code base and I have recently added an analog clock display mode. So for this point forward we should all work from this repository.

I'm doing some experiments with the SmartMatrix that requires transparency. That is, the ability of the background to be seen through pixels drawn over it, with the colors mixed accordingly. I looked through Louis' driver code and found it trivial to add alpha mixing at the lowest level. Only three files in the driver required changes and those changes are simple. The most important thing to know to use transparency is to understand the rgb24 has been extended to include a byte of alpha. A color with an alpha value of 255 is totally opaque; an alpha value of 0 is transparent.

All of the changes to the driver code are listed in comments of the alpha mixing sketch attached. If you make these changes, the define USE_ALPHA_MIXING in SmartMatrix.h controls whether alpha mixing is utilized. If USE_ALPHA_MIXING equals 1, alpha mixing is used. If set to 0, alpha mixing is disabled.

The sketch itself creates a grid of red pixels and then divides the display into four quadrants, each with a different alpha value. When this sketch is run, you'll see the affect of differing alpha values. As the alpha value increases in the filled rectangles which draw over the quadrants the red pixels become less and less visible.

If you find a bug let me know.

Craig Lindley

Wow Craig, you continue to impress!  I had alpha blending in the back of my mind when I was writing the library, but it wasn't something I was going to get to until many releases later.

I've just created a couple of new repositories on GITHUB. Check out: https://github.com/CraigLindley (https://github.com/CraigLindley).

AlphaMixing is the code I posted earlier and Randomness puts the alpha mixing code through it paces by creating random shapes and colors. It make for some interesting watching to say the least.

Enjoy

I've added a few new things to my fork of Craig's LightAppliance (a quick clone of Aaron Steed's "Ending" game, Tetris, a way to browse directories and animations on the SD card, a maze generator pattern and game, a palette-shifting Sierpinski Triangle pattern, and Mandelbrot and Julia set fractal patterns and interactive viewer with pan/zoom) : http://https://github.com/pup05/LightAppliance.

I also added in a menu item for MarkusL's streaming app from here: http://www.pixelmatix.com/forum/#!/supp ... -streaming (http://www.pixelmatix.com/forum/#!/support:first-test-streaming)

Let me know if you have any questions, comments, suggestions, etc.

Louis

I have a corner case for you. I'm playing around with code that draws geometric shapes on the SmartMatrix using parameters that are randomly generated. If I generate a filled triangle with vertices at:

x1: 16
y1: 16
x2: 16
y2: 16
x3: 16
y3: 16

The triangle drawing code hangs and never comes back. I've attached a short sketch that illustrates the problem

FYI

Thanks for the heads up Craig.  I'll add this issue to GitHub Issues and make sure it's fixed before the next release.

I knew something was causing code in the random shapes section of the FeatureTest sketch to freeze but I couldn't narrow it down.

I need to order another batch of parts and boards for the SmartMatrix Shield in the next couple of week, and I'm considering taking the opportunity to get feedback and make a few improvements to the shield.  What would you guys like to see in the SmartMatrix Shield V2?

I may not be able to make all or any of these improvements in the short term, but it will be good at least to have a discussion about what people would like to see in the future.

At the top of my list based on the great work Craig has done is an SD card socket on the board to load GIF animations.  With the right connector like PJRC's Teensy 3 Audio Adapter (http://https://www.pjrc.com/store/teensy3_audio.html) uses, this could fit underneath the Teensy, and the card would be accessible when the USB cable is disconnected.  This is actually a rather big change as it means the shield is no longer purely a through-hole kit, and now there is some surface mount assembly that will need to be done by a factory, and testing to make sure the socket was soldered correctly.

[attachment=0]
Next on the list is more of a bug fix: a pull-up resistor is needed on the OE line so that the display doesn't show garbage when a sketch isn't running.  On some panels there is a pull-up resistor built into the display, but on most that I tried there isn't this resistor, so you get random bright lights on one line of the display during programming or if the sketch hangs.

What else should I add to the list?

---

You might want to add three pads/holes for connecting an IR detector.

I second Craig's suggestion.. IR Pads, and the CC3000 port would be amazing as well

Good suggestions guys.  I finally had time to add the IR detector to my shield and it was more difficult than I thought it would be as I had to make adapter cables to share the 3.3V and GND pins with the SD card.

Any other features?

I second the CC3300 setup too! I have to look how to even connect a CC3300 to the teensy. Ill be getting my first teeny in a few days!

If anyone that has wired up a CC3000 breakout wants to share what they did to hook it up and run a sketch, I'll add notes to the documentation.  I have a breakout but it will probably be some time before I get a chance to hook it up and share what I did.

Louis.. When I get a chance, I want to play with a rotary controller / switch for the menu system, which may be a substitute for the IR..

@KPR, Do you have a link to the part you are thinking about using?  I don't know what kind of inputs you need for that device.

The ones I have are like the following: http://http://mmreference.com/product/ky040-rotary-encoder-module/

I’ve been working on a new version of the SmartMatrix Shield, not meant to replace it, but to be an option for those that want to maximize the capabilities of the Teensy, while connecting to a matrix display.  Let’s call it the SmartMatrix Shield Pro.  This board will have the advantage of pinout/functionality, but the original shield will have advantages of size, cost, and ease of assembly.

[attachment=0]

I thought about all the things I might want to connect a Teensy to in combination with a matrix display, and made the most efficient use of the pins that I could, maximizing functionality.  The pinout uses the SMT connector that is on the bottom of the Teensy, and requires it to be installed, as some of the signals for driving the matrix are now on those pins.  All the pins not used for driving the matrix are bought out to the edge, and grouped by functionality with extra power and ground pins brought out to make wiring peripherals up very easy.  There will be a Micro SD card adapter on the board, and space for plugging in Adafruit's CC3000 module directly.

I played around with a couple layouts and this is my favorite.  The right side looks similar to V1 of the SmartMatrix Shield, but notice all the pins on the Teensy are brought out.  There is a longer row of pins for expansion on the bottom, and more pins on the top.  The Micro SD card slot is on the left edge, and the header for the CC3000 is placed so the module can sit on top of the card slot, with the antenna portion of the module extending out beyond the board, to avoid interference.

I spaced the expansion pins out into logical groups, but this isn’t the most efficient use of space on the board.  It’s possible to group them all together and to bring the left edge and SD card closer to the Teensy.  That saves some board space, but there is little advantage when using the CC3000 module as it will stick out just as far.  I’ll go over the pinout in another post, but there are connectors like a 3-pin IR detector connector with a GPIO plus 3.3V and GND. 

I’m least happy with the placement of the connector for the matrix ribbon cable.  Laid flat, the cable will either cover the CC3000 module, probably interfering with WiFi reception, or go back over the USB and power connectors which should probably be going away from the the matrix panel, not toward it.  I’d also prefer the connector to be at the edge of the board, to give the option to use a double-row right-angle male header instead of the shrouded header.  The ribbon cable plus the shrouded header makes for the tallest components on the board, limiting low-profile mounting options.

Regarding mounting the board, I’m not considering mounting the shield directly to the display using the female 2x8 connector with a board this large.  I do plan on adding several mounting holes, one next to the PWR OUT connectors, and another, possibly two near the Micro SD slot. 

Here’s a PDF of the design and Eagle BRD file.  I’d love some feedback if you’re interested in this design, especially on the ribbon cable connector placement.

---

This looks fantastic!  My only feedback is it seems the SD card might be hard to access under the WiFi module.  It'd be nice to have it on the same edge as the USB and power connectors, for exposing through an enclosure.

Do you know if it'd be possible to use a Bluetooth module instead of WiFi?  I need to order one and try it.

Hi Pup05, good comment, that's something I overlooked but that will be important for a lot of people.  Unfortunately I don't see an ideal way to add a card near the other connectors without just making the board massive.  If I put the card holder under the Teensy itself like in the photo about 10 posts above, but it would take away 2 ADC pins and the AREF pin.

To put some more context about the missing ADC pins, the two that would go missing I intended to be used with potentiometers for brightness or volume control as two possibilities (this shield will be compatible with the Teensy Audio Adapter, connected through jumper wires).  There are still two more dedicated ADC pins available from the Teensy, plus the ADC/DAC pin.  The two missing pins would still be accessible by soldering wires or pins directly to the Teensy itself, so this isn't a horrible loss.

Any thoughts on this?

[quote author="Pup05"]Do you know if it'd be possible to use a Bluetooth module instead of WiFi?  I need to order one and try it.[/quote]

I assume you mean Bluetooth LE, like this module: https://www.adafruit.com/products/1697 (https://www.adafruit.com/products/1697)

It would use the same pins as the CC3000 module, plus one more GPIO.  The pinouts don't match, so it would require a jumper cable.  If there's room on the board to make pinouts for both modules I'll do it.

Thanks, Louis.  I just ordered a Bluefruit LE from Adafruit, and a MSGEQ7 Spectrum Shield from Sparkfun.  Can't wait to try them out on my current board.  :)

By the time you add up a Teensy, A CC3000, and the SmartMatrix Shield shield - seems like might as well
use a CC3200 Launchpad (sorry, forum software won't let me post a link to it.)
Gives you the WiFi, an 80 MHz ARM processor, and a boosterpack connector.
Of course it might not be as compact, and have to arrange a connector for the RGB matrix.

I haven't looked at the CC3200 library, but it shouldn't be too hard to adapt drivers for it,
either from the Teensy SmartMatrix driver, or from the RGB matrix drivers for TI's Tiva Launchpad which I have been working on
(based on Adafruits RGBmatrix driver).

Had a couple of questions about the SmartMatrix driver:
How many refreshes/second can it do with 24 bit color?  I realize it is set for 120 refreshes, but is that about the limit?  Can it go faster on 73MHz Teensy 3.1?

About what percent of processor time is used by the display refresh (or conversely, what percent of time is available)?

Doesn't doing all the bit-rearrangement in loadMatrixBuffers take a lot of time?  Seems like might be more efficient to store the
pixels in a sliced up form (similar to what RGBmatrix driver does).  Takes more time to read/write a pixel, but refreshes
are more frequent than pixel read/writes.  I would be curious for your perspective.

Pretty neat figuring out how to do so much of it with DMA.

By the time you add up a Teensy, A CC3000, and the SmartMatrix Shield shield - seems like might as well
use a CC3200 Launchpad

True, but the advantage of using the Teensy is Arduino compatibility, so people can easily use the library to create something with it. 

The CC3200 looks pretty good, I knew it existed but didn't take a closer look until now.  The DMA engine seems capable of driving the matrix display.

I have briefly considered porting the library to the Spark Core, which contains a STM32 with DMA and the CC3000.  Figuring out the idiosyncrasies of another DMA engine isn't trivial though, and Spark's IDE is much further behind Arduino at least right now. 

I haven't benchmarked the driver in a while, but it was using roughly 10% of the CPU at 70Hz refresh I believe.  I've run it much higher than 120 Hz, but don't see a reason why that is necessary.

Storing pixels in a sliced up form takes more than double the amount of memory as storing it as a normal bitmap, as each 6-bit word on the bus is stored as two full bytes, with a pair of clock pulses high and low to get the GPIO to toggle the clock line using sequential DMA writes.

Thanks for your comments/questions!

[quote author="EmbeddedCreations"]

By the time you add up a Teensy, A CC3000, and the SmartMatrix Shield shield - seems like might as well
use a CC3200 Launchpad

True, but the advantage of using the Teensy is Arduino compatibility, so people can easily use the library to create something with it. 
[/quote]

Energia is the port of the Arduino environment and library for TI Launchpads.  The version for the CC3200 is in beta testing, so Arduino compatability should be available presently.

[quote author="EmbeddedCreations"]
I haven't benchmarked the driver in a while, but it was using roughly 10% of the CPU at 70Hz refresh I believe.  I've run it much higher than 120 Hz, but don't see a reason why that is necessary.
[/quote]

Thanks.  I was curious to see how it compared to the driver I have been working on.
I took the approach of directly adapting Adafruits RGBmatrix driver to work on other platforms -
i.e. adapt the Timer and PIO calls. 
I suspect this makes porting it a bit less tricky than using DMA (in addition to the TI Tiva,
which was my main/initial target, I have mostly done an adaptation for the Atmel SAM (Arduino Due)).

Can't do a really fair comparison at this point, since the AdafruitGFX interface limits my
driver to 5 bits per color.  But at 4/4/4 color the Tiva driver takes a bit over 3% CPU time at 70 Hz on an 80 MHz Stellaris processor.  I estimate it would be about 8% with 24 bit color.  (Assuming can keep the refresh reasonable. With 4/4/4 color can do 900 Hz refresh.)  So the CPU use looks at least roughly comparable.

If you can do much higher refresh rates you might be able to do more bits of color
(e.g. have you tried 9/9/9 color).

Another use for higher refresh rates - one can do fades between two immages by switching which immage is
displayed (gradually show more of the new and less of the old) and let the eye do the averaging.
(Only works with a prety high refresh rate.)

Since you extended the AdafruitGFX interface to handle higher color, figured I would adapt the
SmartMatrix to separate the interface from the processor specific implementation, and use it
as a high color interface for the Tiva RGBmatrix driver.


[quote author="EmbeddedCreations"]
Storing pixels in a sliced up form takes more than double the amount of memory as storing it as a normal bitmap, as each 6-bit word on the bus is stored as two full bytes, with a pair of clock pulses high and low to get the GPIO to toggle the clock line using sequential DMA writes.
[/quote]

I was thinking of storing them sliced, but without the doubling to handle the clock bits.
That way the space increase would be more modest.  (6 bytes for two pixels becomes 8 bytes for two pixels)
Then all you have to do to prepare for DMA is copy the byte to the DMA buffer, then combine the byte with a mask (to set or clear the clock bit) and save the combined byte in the DMA buffer.  Should be much faster than
all the bit slicing and combining.

Thanks.

New SmartMatrix Application

Hello all,

I've created another wild, crazy and colorful application for the SmartMatrix, unrelated (at this time) to the Light Appliance. I call it Randomness and it is available at: https://github.com/CraigLindley/Randomness (https://github.com/CraigLindley/Randomness). This application doesn't require any hardware modifications or additions. It runs on the stock SmartMatrix display.

It uses the alpha mixing changes I made to the SmartMatrix library, all of which are documented in the comments in the sketch. As I said in the repository readme:

"One might consider this an art piece; others might consider this junk. You choose (;>)"

This looks very abstract when used with diffusion on the SmartMatrix.

Have fun!

Just wanted to let people know that the October issue of Nuts and Volts magazine will have the Light Appliance article I wrote. Unfortunately, the Light Appliance did not make the cover of the magazine.

Craig Lindley

I'm working on a major update to the SmartMatrix Library, and the code is available from the master branch in GitHub now.  The draft release notes are below, but here's the major features:

36/48-bit color support - A lot of LED displays are limited to 24-bit color but I found a way to drive the displays with higher color depth.  This makes for better subtle color changes, and fades to and from black look really nice when using the default color (gamma) correction settings and 36-bit color.  48-bit color may be overkill, it's supported, but the difference from 36-bit color is minimal.

FastLED support - The FastLED library is a great library for working with LED strips, and there's a great community around the library and lots of examples of how to make cool looking LED effects.  FastLED's authors were very receptive to a user's request about adding support for SmartMatrix, and even made some efficiency improvements to SmartMatrix.  There are two examples of FastLED integration included in the SmartMatrix library showing how easy it is to make some cool effects.

Animated GIFs example - I added Craig Lindley's Animated GIFs sketch and added it as an example in SmartMatrix. 

Background Dimming - this is made possible by the 36/48-bit color support.  You can now set the background layer brightness so that it is dimmer than the foreground.  This is good for a clock display for example, so the time would be readable even with a bright background.  The dimming is done with a gamma correction lookup table stored in RAM with very little effect on performance.

Lots more in the release notes.  I'm hoping to push out an official release by the end of the week, please let me know if you try the code and see any issues.

Release Notes:
http://https://gist.github.com/pixelmatix/2f42350dae7841ef94c3

Louis,

I completely deleted my old version of your library and downloaded your new version along with the FastLED library.
My Light Appliance sketch runs perfect. I don't see any differences at all. However when I try to use the examples included in your library I get weird results.

1. The AnimatedGIFs example doesn't show up at all in the IDE and therefore cannot be selected
2. The FeatureDemo runs for a rather long time and then hangs completely. This happened 3 times in a row.
3. Neither of the FastLED demos will compile.

FastLED_Controller.ino Example
===========================

FastLED_Controller.ino: In function 'void setup()':
FastLED_Controller:74: error: 'SMART_MATRIX' was not declared in this scope
FastLED_Controller:74: error: no matching function for call to 'CFastLED::addLeds(CRGB [1024], int)'
FastLED_Controller.ino:74:43: note: candidates are:
In file included from FastLED_Controller.ino:10:0:
/Users/craiglindley/Documents/Arduino/libraries/FastLED/FastLED.h:52:88: note: template<ESPIChipsets CHIPSET, unsigned char DATA_PIN, unsigned char CLOCK_PIN> CLEDController* CFastLED::addLeds(const CRGB*, int, int)
/Users/craiglindley/Documents/Arduino/libraries/FastLED/FastLED.h:52:88: note:  template argument deduction/substitution failed:
FastLED_Controller:74: error: template argument 1 is invalid
In file included from FastLED_Controller.ino:10:0:
/Users/craiglindley/Documents/Arduino/libraries/FastLED/FastLED.h:60:106: note: template<ESPIChipsets CHIPSET, unsigned char DATA_PIN, unsigned char CLOCK_PIN, EOrder RGB_ORDER> CLEDController* CFastLED::addLeds(const CRGB*, int, int)
/Users/craiglindley/Documents/Arduino/libraries/FastLED/FastLED.h:60:106: note:  template argument deduction/substitution failed:
FastLED_Controller:74: error: template argument 1 is invalid
In file included from FastLED_Controller.ino:10:0:
/Users/craiglindley/Documents/Arduino/libraries/FastLED/FastLED.h:68:129: note: template<ESPIChipsets CHIPSET, unsigned char DATA_PIN, unsigned char CLOCK_PIN, EOrder RGB_ORDER, unsigned char SPI_DATA_RATE> CLEDController* CFastLED::addLeds(const CRGB*, int, int)
/Users/craiglindley/Documents/Arduino/libraries/FastLED/FastLED.h:68:129: note:  template argument deduction/substitution failed:
FastLED_Controller:74: error: template argument 1 is invalid
In file included from FastLED_Controller.ino:10:0:
/Users/craiglindley/Documents/Arduino/libraries/FastLED/FastLED.h:92:18: note: template<EClocklessChipsets CHIPSET, unsigned char DATA_PIN> CLEDController* CFastLED::addLeds(const CRGB*, int, int)
/Users/craiglindley/Documents/Arduino/libraries/FastLED/FastLED.h:92:18: note:  template argument deduction/substitution failed:
FastLED_Controller:74: error: template argument 1 is invalid
In file included from FastLED_Controller.ino:10:0:
/Users/craiglindley/Documents/Arduino/libraries/FastLED/FastLED.h:109:18: note: template<EClocklessChipsets CHIPSET, unsigned char DATA_PIN, EOrder RGB_ORDER> CLEDController* CFastLED::addLeds(const CRGB*, int, int)
/Users/craiglindley/Documents/Arduino/libraries/FastLED/FastLED.h:109:18: note:  template argument deduction/substitution failed:
FastLED_Controller:74: error: template argument 1 is invalid
FastLED_Controller:83: error: 'pSmartMatrix' was not declared in this scope
FastLED_Controller.ino: In function 'void fillnoise8()':
FastLED_Controller:105: error: 'inoise8' was not declared in this scope
FastLED_Controller.ino: In function 'void loop()':
FastLED_Controller:132: error: 'pSmartMatrix' was not declared in this scope
FastLED_Controller:136: error: 'class CFastLED' has no member named 'countFPS'

FastLED_Functions.ino Example
===========================

Arduino: 1.0.5 (Mac OS X), Board: "Teensy 3.1"
FastLED_Functions.ino: In function 'void fillnoise8()':
FastLED_Functions:72: error: 'inoise8' was not declared in this scope
FastLED_Functions.ino: In function 'void loop()':
FastLED_Functions:93: error: no match for 'operator=' in '*(buffer + ((sizetype)(((unsigned int)((j * 32) + i)) * 3u))) = CRGB((*(const CHSV*)(& CHSV(noise[j], 255u, noise[j]))))'
FastLED_Functions.ino:93:75: note: candidates are:
In file included from FastLED_Functions.ino:8:0:
/Users/craiglindley/Documents/Arduino/libraries/SmartMatrix/SmartMatrix.h:68:16: note: rgb24& rgb24::operator=(const rgb24&)
/Users/craiglindley/Documents/Arduino/libraries/SmartMatrix/SmartMatrix.h:68:16: note:  no known conversion for argument 1 from 'CRGB' to 'const rgb24&'
/Users/craiglindley/Documents/Arduino/libraries/SmartMatrix/SmartMatrix.h:68:16: note: rgb24& rgb24::operator=(rgb24&&)
/Users/craiglindley/Documents/Arduino/libraries/SmartMatrix/SmartMatrix.h:68:16: note:  no known conversion for argument 1 from 'CRGB' to 'rgb24&&'
FastLED_Functions:101: error: no matching function for call to 'SmartMatrix::fillCircle(int, int, int, CRGB)'
FastLED_Functions.ino:101:77: note: candidates are:
In file included from FastLED_Functions.ino:8:0:
/Users/craiglindley/Documents/Arduino/libraries/SmartMatrix/SmartMatrix.h:119:10: note: void SmartMatrix::fillCircle(int16_t, int16_t, uint16_t, const rgb24&, const rgb24&)
/Users/craiglindley/Documents/Arduino/libraries/SmartMatrix/SmartMatrix.h:119:10: note:  candidate expects 5 arguments, 4 provided
/Users/craiglindley/Documents/Arduino/libraries/SmartMatrix/SmartMatrix.h:120:10: note: void SmartMatrix::fillCircle(int16_t, int16_t, uint16_t, const rgb24&)
/Users/craiglindley/Documents/Arduino/libraries/SmartMatrix/SmartMatrix.h:120:10: note:  no known conversion for argument 4 from 'CRGB' to 'const rgb24&'
FastLED_Functions:105: error: 'class CFastLED' has no member named 'countFPS'

Maybe this has something to do with the version of FastLED I downloaded or is just something I am doing wrong.

Looks like you might need to checkout the FastLED2.1 branch and make sure to pull Daniel's latest changes.  He renamed an enum from SmartMatrix to SMART_MATRIX to fix a name collision.

Hi Craig,

Make sure you have the FastLED2.1 branch.  It's not the default branch for FastLED.

AnimatedGIFs has it's own repo on GitHub, and is added to SmartMatrix as a submodule.  If you check out SmartMatrix using a git tool, it will include the files for AnimatedGIFs.  Downloading as a zip from the repo overview doesn't include it though.  It will be included in the release zip.
Just download it separately here:
https://github.com/pixelmatix/AnimatedGIFs (https://github.com/pixelmatix/AnimatedGIFs)

Thanks for pointing out the issue with FeatureDemo.  It worked a few commits ago, I'll trace down why it's not working now.

The FeatureDemo runs for a rather long time and then hangs completely. This happened 3 times in a row.

Can you be more specific on "rather long time"?  Did it run through a loop and start repeating?  Where did it hang?

I just ran FeatureDemo again and I saw no issues and it continued past one loop.

Hi Louis,

Yes things are working better now. I initially followed the link in your release note for FastLED but didn't select the 2.1 release. Can you specify a link that goes directly to the 2.1 release? If not you might want to make a comment about selecting the 2.1 release in the github gui.

I downloaded AnimatedGIFs and it works fine.

The two FastLED demos now work. The FastLED stuff is rather amazing. I'll have to look into this.

The FeatureDemo still hangs every time at the Brightness demo. I don't see any message in the Serial Monitor. My display just goes dark and they two horizontal line are drawn in gold and that is all she wrote.

Craig

Hi Craig,

The 100% white of the brightness demo draws the most current from the power supply, around 3.5A max.  If you're using a 2A supply, maybe that's what is causing issues.  If you have a 4A supply, give that a try.  I've been running FeatureDemo on two of my displays for over an hour with no issues.

Take a look at the FastLED Google Plus community, there are people sharing a lot of cool stuff:
https://plus.google.com/communities/109 ... 4227823508 (https://plus.google.com/communities/109127054924227823508)

That is probably what the problem is. I actually back down the brightness on the Light Appliance to allow my 2Amp power supply to work.

Sorry for the noise

Craig

It's useful noise. :-)  This is the first report I've heard of the how the 2A supply can cause a sketch to fail, I'll keep it in mind for troubleshooting later.

Louis and I have started a community on Google+ if anyone is interested in joining us there.  It's much easier to share pictures and videos of your project on G+ than here.  http://www.pixl.mx/SmartMatrixUsers (http://www.pixl.mx/SmartMatrixUsers)

We've been busy working on Aurora: https://github.com/pixelmatix/aurora (https://github.com/pixelmatix/aurora)

It's similar to and inspired by Craig's Light Appliance sketch.  It's a menu system for the SmartMatrix display for playing procedurally generated patterns and animated GIFs (from SD).  It can display a digital clock in the foreground over the patterns/animations if you have an RTC module attached.  It has support for dynamically defined scrolling text messages, read from SD, in ini-style text or JSON formats.  It's relatively easy to add new patterns to the menu.  I've added a page to the wiki that outlines the process here: https://github.com/pixelmatix/aurora/wi ... g-Patterns (https://github.com/pixelmatix/aurora/wiki/Adding-Patterns)

It's been a long while since I posted, here are a few updates:

I created two guides on the Adafruit Learning System for projects using the SmartMatrix Shield, and I have a couple more guides planned.  Following both guides you can put together a display that runs the Aurora sketch Jason just shared.
https://learn.adafruit.com/users/Pixelmatix (https://learn.adafruit.com/users/Pixelmatix)

I made a new version of the SmartMatrix Shield, similar to what we started discussing about four months back (http://http://dangerousprototypes.com/forum/viewtopic.php?f=56&t=6125&start=180#p58844).  This has an SD card slot, and brings out more pins from the Teensy.  It has a rearranged expansion port that groups pins by functions for I2C, IR receiver, CC3000 module or SPI + UART.  I made up a small batch of these and sold most of them as part of a bundle at World Maker Faire in NYC, and have a handful left over I'm selling through a Tindie Store (http://https://www.tindie.com/products/Pixelmatix/smartmatrix-sd-shield/).  The shield is more expensive as it's not just a PCB and bag of parts, the board needs to be partially assembled and tested before shipping.

[attachment=0]

The latest Teensyduino includes PJRC's Audio Library (http://http://www.pjrc.com/teensy/td_libs_Audio.html), and I updated the SmartMatrix Library to support it.  Jason made a sketch that implements a basic spectrum analyzer (http://https://github.com/pup05/SmartMatrixSpectrumAnalyzerBasic) and that's included as an example in SmartMatrix Library v2.1 (http://https://github.com/pixelmatix/SmartMatrix/releases).

I've been posting more frequently at the Google+ Community (http://http://www.pixl.mx/SmartMatrixUsers) Jason mentioned.

---

I have a 32x32 LED panel, a Teensy 3.1 and installed it on the SmartShield. I can not compile due to Adafruit_GFX.h not being found by the Arduino 1.05r2 . I downloaded: and installed: RGB-matrix-Panel-master.zip. RGBmatrixPanel.h is in the library:C:Program Files (x86)ArduinolibrariesRGBmatrixPanel. where do I get all the SW tools?

RGB-matrix-Panel sounds like it is a library by Adafruit, not the SmartMatrix Library which was designed for the Teensy 3.1 and the SmartMatrix Shield.

You can get the latest version of the SmartMatrix Library here:
https://github.com/pixelmatix/SmartMatrix/releases (https://github.com/pixelmatix/SmartMatrix/releases)

There are more details on library installation here:
http://docs.pixelmatix.com/SmartMatrix/ ... ensy-setup (http://docs.pixelmatix.com/SmartMatrix/#software-and-teensy-setup)