kjus,

Nice work on the code updates. I did run a test of your code with an Arduino with 2 displays and saw the 62 fps with a smoother faster scrolling. I then changes the number of boards from 2 to 4 and it changed (as expected) to 31 fps with a much slower but still 'ok' scroll.

I then used a Teensy++ 2.0 which has the DigitalWriteFastNoCheck and pinModeFast2 features built in as the normally listed digitalWrite and pinMode commands. I could not get it to work on the Teensy++ 2.0 using the digital WriteFastNoCheck and pinModeFast2 commands as seen from the digitalWriteFast.h file. What I saw using the digitalWrite and pinMode commands on the Teensy++ 2.0 was basically the same as the digitalWriteFastNoCheck and pinModeFast2 commands as seen on the Arduino (a speed of 31 fps with 4 displays).

So using the digitalWriteFast.h with an Arduino with your code is the same as not using it on the Teensy++ 2.0 with the expected frames per second being 62 fps for 2 displays and 31 fps for 4 displays.

Nice work.

Tim

Here is my latest modification which adds a PS2 Keyboard to the Teensy++ 2.0 and display.

http://forums.parallax.com/showthread.php?128037-Sure-Electronics-new-32x16-bi-color-display-3216-RG&p=978290#post978290

Something I don't like about it is after you Compile it, and press the Teensy++ 2.0 reset, you have to open the Arduino "Serial Monitor" before the PS2 keyboard entries will display correctly. However, I would like to get some help with the C coding to figure out how to change colors per letter, word, etc. and adding in PS2_BACKSPACE coding would be nice too. I got the PS2 information from here: http://www.pjrc.com/teensy/td_libs_PS2Keyboard.html

Let me know what you think.

Tim

Phoenix,

It looks like Sure Electronics has come out with a replacement board 3208 for their flatter display 0832. This code for this forum uses a different bi-color board called the 3216 RG. Although all 3 of these boards (3216 RG, 0832 and the new 3208) uses the HT1632C chip, the 3216 board has a chip select circuit (74HC164 chip) that is not on the 0832 nor the 3208 boards. It would be much easier to think of the 3208 as an 0832 board as there are lots of code examples for the 0832. You should probably first look at the Miles Burton Library which works well with the 0832 and Sure Electronics 2416 displays. Here is the link: http://milesburton.com/index.php/Arduino_&_the_Sure_2416_Information_Display

Good luck.

Florinc,

I see that I signed on before as tdg8934 which has an old email linked to it.

Anyway... I am using a 5vdc 20amp p/s I bought on eBay. I doubt I'm drawing that much current yet. However, I plan to ultimately use a much smaller power supply of 5vdc @ 25 amps (to be mounted inside the enclosure) that is inexpensive from Sure Electronics.

Tim

Florinc,

Im not a good C programmer yet and did not quite follow the example. However, I wanted to post my latest accomplishments of the 3216 RG with 8 displays running on a Teensy++2.0 (www.pjrc.com/teensy) with the code: http://forums.parallax.com/showthread.php?128037-Sure-Electronics-new-32x16-bi-color-display-3216-RG&p=976869#post976869

and YouTube video:

Now if I we can figure out how to clear all of those LEDs that turn back on after they have been cleared.

Thanks for all of your help and to everyone!

More to come...

I created another version of the program with the 'DigitalWriteFast' library routines commented out and used direct port access to digital pins 6,7,8,9 and it worked to see if this would caused the scrolling message to be any faster. Unfortunately, it was not any noticibly faster and the work based off of this link: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=706055  was used to figure out how to do the direct port access.

The new code is listed here:

http://forums.parallax.com/showthread.php?128037-Sure-Electronics-new-32x16-bi-color-display-3216-RG&p=974440#post974440

Since, it did not show much of an improvement, I think I may just go back to the easier to use 'DigitalWriteFast' library routines. We'll see.

Let me know what you think.

Thanks,

Tim

I was slightly mistaken about having no random pixels. The display first starts with a scrolling of text from right to left and then displays the multicolored larger sized "2011" in the first display. It then displays multicolored inidividual lettered static text message. This is pretty good other than I would like to see a faster scroll but it is not too bad.

The problem with the random pixels comes out when the program is looped and it runs again. First the scrolling message runs and no problems there. Then the display of the multicolored larger size "2011" causes some pixels to be off. Then the multicolored individual lettered static text message shows some letters to be missing some LEDs. It always has the same LEDs off everytime.

As a test, I ran the large "Arduino rocks" scroll across the 4 displays (and then the normal other scrolling message, 2011 message and colored text)... This time the "Arduino rocks" scroll (although somewhat slow but reasonably ok), is good until you see a couple of LEDs turn on on the 1st and 2nd display on the very top row. However, after this is done, the normal sized other scrolling message comes out fine with no pixel issues, and the 2011 message is GOOD this time as well as the colored text display (no missing LED pixels). I don't quite understand what is happening here but could be related to the shaddow ram.

[byte]

I also found a couple of small issues in the h1632_putchar routine that works much better now. Before I would have left over random colored LEDs in the last row of the text messages displayed. Now they are correct.

This

Code:

for (char row=0; row <7; row++) {

was changed to this:

Code:

for (char row=0; row <=7; row++) {

Also in the void line, it had byte declarations for x and y which caused displaying issues especially in the scrolling routine. However, changing it to integer fixed this (as changed previously in past coding).

However, I would like some assistance in cleaning up the coding for char c as my bitwise coding is lacking (as there has to be a cleaner way for this).

Code:

//void ht1632_putchar(byte x, byte y, char c, byte color=GREEN)
void ht1632_putchar(int x, int y, char c, byte color=GREEN)
{
  byte dots;
  //if (c >= 'A' && c <= 'Z' ||
  //  (c >= 'a' && c <= 'z') ) {
  //  c &= 0x1F;   // A-Z maps to 1-26
  //}
  //else if (c >= '0' && c <= '9') {
  //  c = (c - '0') + 27;
  //}
  //else if (c == ' ') {
  //  c = 0; // space
  //}
  
  if (c == ' ') {c = 0;}
  else if (c == '!') {c = 1;}
  else if (c == '"') {c = 2;}
  else if (c == '#') {c = 3;}
  else if (c == '$') {c = 4;}
  else if (c == '%') {c = 5;}
  else if (c == '&') {c = 6;}
  //else if (c == ''') {c = 7;}
  else if (c == '(') {c = 8;}
  else if (c == ')') {c = 9;}
  else if (c == '*') {c = 10;}
  else if (c == '+') {c = 11;}
  else if (c == ',') {c = 12;}
  else if (c == '-') {c = 13;}
  else if (c == '.') {c = 14;}
  else if (c == '/') {c = 15;}  
  
  else if (c >= '0' && c <= '9') {
    c = (c - '0') + 16;
  }
  
  else if (c == ':') {c = 26;}
  else if (c == ';') {c = 27;}
  else if (c == '<') {c = 28;}
  else if (c == '=') {c = 29;}
  else if (c == '>') {c = 30;}
  else if (c == '?') {c = 31;}
  else if (c == '@') {c = 32;}  
  
  else if (c >= 'A' && c <= 'Z') {
    c = (c - 'A') + 33;
  }
  
  else if (c == '[') {c = 59;}
  //else if (c == '\') {c = 60;}
  else if (c == ']') {c = 61;}
  else if (c == '^') {c = 62;}
  else if (c == '_') {c = 63;}
  else if (c == '`') {c = 64;}
  
  else if (c >= 'a' && c <= 'z') {
    c = (c - 'a') + 65;
  }
  
  else if (c == '{') {c = 91;}
  else if (c == '|') {c = 92;}
  else if (c == '}') {c = 93;}
  
  for (char col=0; col< 6; col++) {
    dots = pgm_read_byte_near(&my3font[c][col]);
    for (char row=0; row <=7; row++) {
      if (dots & (64>>row))       // only 7 rows.
        plot(x+col, y+row, color);
      else
        plot(x+col, y+row, 0);
    }
  }
}

Overall the coding is working very well (except for the scrolling is still a bit slow even with the digitalwritefast routines) now thanks to everyones help.

Here is the latest code for up to 4 working displays:

http://forums.parallax.com/showthread.php?128037-Sure-Electronics-new-32x16-bi-color-display-3216-RG&p=974131#post974131

Piticasgabriel,

The link I posted before was to show you the many types of displays that Sure Electronics have some in just 3 mm LEDs and others in both 3 mm LEDs and 5 mm LEDs.

Currently I have 4 working displays and hope to have 8 of them working together of their 5 mm type for the 3216 RG displays by Sure Electronics.

http://www.sureelectronics.net/goods.php?id=1122

You really want to utilize premade LED matrix modules with LED driver chips already installed and ready to just connect up to a micro-controller like an Arduino. If you must design your own LED display board with a custom printed circuit board and individual LEDs, it will be very time consuming and expensive.

Let us know if you have any other questions or require further details.

[which works now]

florinc,

Thanks so much for your help in this forum especially along with Wagner and others. So shadowram should be:

Code:

byte ht1632_shadowram[64][4][8] = {0};

because I think it should just be:

Code:

byte ht1632_shadowram[64][4*Number_of_Displays] = {0};

which works now with no random pixel errors (as modified from my last posted code).

[Number_of_Displays]

Wagner,

Thanks for your help on this. All I was saying about the shadowram was that their was an inconsistancy I saw if the value of Number_of_Displays gets changed from 2 to something else.

If Number_of_Displays was to stay at 2, then the following would occur:

Code:

#define Number_of_Displays 2
#define CHIP_MAX 4*Number_of_Displays //Four HT1632Cs on one board
#define X_MAX 32*Number_of_Displays -1
#define Y_MAX 15

CHIP_MAX would have a value of 4*Number_of_Displays being 8.

But later in the program Shadowram is a 2 dimensional array of [64][4*2].

Code:

byte ht1632_shadowram[64][4*2] = {0};

Further in the program in the HT1632_Clear routine, Shadowram is now set by the value of CHIP_MAX and if CHIP_MAX is 8 then the 2nd array [4*2] is ok but if CHIP_MAX gets changed to 16 because the Number_of_Displays get's is now 4, this will make CHIP_MAX's value 4*4 or 16. 16 does not match up to the original byte declaration of

Code:

byte ht1632_shadowram[64][4*2] = {0};

as seen below in CHIP_MAX. I hope this makes sense. So all I am saying is that in the HT1632_Clear routine, that it needs not to use the value of CHIP_MAX in the counter routine of 'i'.

Code:

void ht1632_clear()
{
  char i;
  //for (int i=1; i<=CHIP_MAX; i++) COMMENT OUT THIS LINE AND REPLACE WITH LINE BELOW SO i GOES to 8 and not the CHANGED VALUE OF CHIP_MAX WHICH COULD BE 16 NOW
  for (int i=1; i<=8; i++)
  {
    ChipSelect(-1);
    ht1632_writebits(HT1632_ID_WR, 1<<2);  // send ID: WRITE to RAM
    ht1632_writebits(0, 1<<6); // Send address
    for (i = 0; i < 96/2; i++) // Clear entire display
      ht1632_writebits(0, 1<<7); // send 8 bits of data
    ChipSelect(0);

    for (int j=0; j < 64; j++)
      ht1632_shadowram[j][i] = 0;
  }
}

Just a small point I wanted to make, thats is all.

Thanks.

My real issue with with the random pixels.

Tim.

Wagner and others,

I found another bug but this did not fix the random pixel issue but did somewhat clear up some clearing issues better than before.

When the Number_of_Displays was 2, it was ok but if Number_of_Displays increases then it affects the value of CHIP_MAX:

Code:

#define Number_of_Displays 4
#define CHIP_MAX 4*Number_of_Displays //Four HT1632Cs on one board
#define X_MAX 32*Number_of_Displays -1
#define Y_MAX 15

CHIP_MAX was used as a value of 8 (when you have 2 displays), but with 4 displays, then the value of CHIP_MAX increases to 16.

Code:

/*
 * ht1632_clear
 * clear the display, and the shadow memory, and the snapshot
 * memory.  This uses the "write multiple words" capability of
 * the chipset by writing all 96 words of memory without raising
 * the chipselect signal.
 */
void ht1632_clear()
{
  char i;
  //for (int i=1; i<=CHIP_MAX; i++)
  for (int i=1; i<=8; i++)
  {
    ChipSelect(-1);
    ht1632_writebits(HT1632_ID_WR, 1<<2);  // send ID: WRITE to RAM
    ht1632_writebits(0, 1<<6); // Send address
    for (i = 0; i < 96/2; i++) // Clear entire display
      ht1632_writebits(0, 1<<7); // send 8 bits of data
    ChipSelect(0);

    for (int j=0; j < 64; j++)
      ht1632_shadowram[j][i] = 0;
  }
}

However, Shadowram cant be higher than 64 x 8 but this would make it 64x16 causing issues.

Code:

byte ht1632_shadowram[64][4*2] = {0};

What do you think?

Wagner and others,

I have the code working for 3 and 4 displays EXCEPT I see some random pixels in the last collumn of the first quadrant of displays 3 and 4.

http://forums.parallax.com/showthread.php?128037-Sure-Electronics-new-32x16-bi-color-display-3216-RG&p=973708#post973708

Code:

#define Number_of_Displays 4
#define CHIP_MAX 4*Number_of_Displays //Four HT1632Cs on one board
#define X_MAX 32*Number_of_Displays -1
#define Y_MAX 15

Code:

//if (x>=32) {
//  nChip = 3 + x/16 + (y>7?2:0);
//} else {
//  nChip = 1 + x/16 + (y>7?2:0);
//}
 
  if (x>=96) {
    nChip = 7 + x/16 + (y>7?2:0);
  }
  else if (x>=64) {
    nChip = 5 + x/16 + (y>7?2:0);
  }   
   else if (x>=32) {
    nChip = 3 + x/16 + (y>7?2:0);
  } 
  else {
    nChip = 1 + x/16 + (y>7?2:0);
  }

Any ideass on what to do about the random pixels ?

[#define X_MAX 32*Number_of_Displays -1]

Wagner,

Can you look over the latest code again? As you stated earlier, I did make the change here: #define X_MAX 32*Number_of_Displays -1

I have added 2 additional displays (total of 4) and if I set #define Number_of_Displays 6 I can sort of see the display on all four of them but the scrolling routine is spliting the message in half. The bottom half of the message is scrolling across the top of the displays while the top half of the message is scrolling across the bottom of the displays. Something is wrong with the clocking or something and it is messed up with any displays more than 2 connected. If I use, #define Number_of_Displays 4 or #define Number_of_Displays 3 the 4th display is not even turned on.

Here is the non-working code for 4 displays: http://forums.parallax.com/showthread.php?128037-Sure-Electronics-new-32x16-bi-color-display-3216-RG&p=973058#post973058

I have a device I built that is basically a keypad and a Parallax Serial LCD in an enclosure. It uses a Db25 connection to a main board with a Parallax SX28 master micro-controller and SX28 slave chips to control multiple 7 segment sets of 4 LED displays. However, the Parallax SX28 is now obsolete and I am trying to redesign this with the Arduino which I have not too much experience with but still keep learning.

So far I have found information online to control the 7 segment sets of 4 LED displays with a bootloaded 328P chip (or Arduino board) with not too much problem. So that covers the "slave" driver aspect.

Now as far the master goes, It needs to control the keypad and the LCD and send the data to one of the slave bootloaded 328P chips controlling the 7 segment sets of 4 LED displays.  I have also found code that I have modified and is working with the Arduino. Since the Arduino (or 328P) doesn't have a ton of I/O, I have used a TI PCF8574N chip to take the 8 data lines from the keypad and convert them into I2C that the Arduino (or 328P) can understand. The Parallax Serial LCD only uses RX, Vcc, and Gnd so nothing was needed there. It works fine with the standard Arduino "Serial" commands.

I would like to first reduce the DB25 cable into a CAT5e cable which is certainly possible as the only lines I now have are: SDA, SCL, Vcc, Gnd and RX. The slave 328P chips and 7 segment sets of 4 LED displays are going to be run with ribbon cable to the master 328P on the main circuit board.
What I would really like to do is to have a wireless solution for the I2C Keypad and Serial LCD. But the Arduino only has 1 set of RX/TX unless I go with an Arduino Mega. Is there such as thing as wireless I2C or would I have to use a differnt chip to convert the keypad into Serial?

Any help would be greatly appreciated.

Thanks,

Tim Gilmore