next topic »

[Reply #195 on:]

The code is just whats in the "examples" folder of the library.

Compare compiling this code

Code:

#include <ht1632c.h>
void setup(){}
void loop(){}

which gives you 466 bytes versus

Code:

#include <ht1632c.h>

ht1632c dotmatrix = ht1632c(PORTD, 7, 6, 4, 5, GEOM_32x16, 2);
void setup(){}
void loop(){}

which compiles to 13,796 bytes. I don't know how you're getting away with under that value...

[Reply #196 on:]

Very strange.  Here's my entire code for 3 displays using the old code (not the library)

http://pastebin.com/ipQQtUqC


See what that compiles into on your machine

[Reply #197 on:]

This is the video with framesize = 64 that works as I expected it to.

http://youtu.be/sViM6mhcrPE


This is the video with framesize - 32 that doesn't work.

http://youtu.be/5OoX3bAvwdg

and here's the source code I'm using which is just an adaptation of the geometry sketch.

Code:

#include <ht1632c.h>

ht1632c dotmatrix = ht1632c(PORTD, 7, 6, 4, 5, GEOM_32x16, 1);

void setup ()
{
  dotmatrix.setup();
  dotmatrix.clear();
//  dotmatrix.pwm(10);
//  Serial.begin(9600);
}

void loop ()
{
  dotmatrix.pwm(15);
  dotmatrix.line(0,0,31,0,RED);
  displayit();
  dotmatrix.line(31,0,31,15,RED);
  displayit();
  dotmatrix.line(31,15,0,15,RED);
  displayit();
  dotmatrix.line(0,15,0,0,RED);
  displayit();
  dotmatrix.line(0,0,31,15,RED);
  displayit();
  dotmatrix.line(31,0,0,15,RED);
  displayit();
  dotmatrix.line(0,0,31,0,GREEN);
  dotmatrix.line(31,0,31,15,GREEN);
  dotmatrix.line(31,15,0,15,GREEN);
  dotmatrix.line(0,15,0,0,GREEN);
  dotmatrix.line(0,0,31,15,GREEN);
  dotmatrix.line(31,0,0,15,GREEN);
  displayit();
 dotmatrix.circle(15,8,4,RED);
  displayit();
  dotmatrix.ellipse(32-32,0,63-32,15,GREEN);
  displayit();
  dotmatrix.rect(40-32,3,55-32,12,RED);
  displayit();
  dotmatrix.rect(40-32,3,55-32,12,ORANGE);
  dotmatrix.fill(16,7,ORANGE);
  displayit();
  dotmatrix.bezier(8, 14, 27, 14, 30, 1, GREEN);
  displayit();
  dotmatrix.setfont(FONT_5x7);
  dotmatrix.putchar(2,5,'S',RED);
  dotmatrix.putchar(6,5,'I');
  dotmatrix.putchar(11,5,'N',ORANGE);
  dotmatrix.putchar(16,5,'G',RED);
  dotmatrix.putchar(21,5,'E');
  dotmatrix.putchar(26,5,'R',ORANGE);
  displayit();


}

void displayit(void)
{
  dotmatrix.sendframe();
  delay(1000);
  dotmatrix.clear();
}

[Reply #198 on:]

This is the video with framesize = 64 that works as I expected it to.

http://youtu.be/sViM6mhcrPE


This is the video with framesize - 32 that doesn't work.

http://youtu.be/5OoX3bAvwdg

and here's the source code I'm using which is just an adaptation of the geometry sketch.

Code:

#include <ht1632c.h>

ht1632c dotmatrix = ht1632c(PORTD, 7, 6, 4, 5, GEOM_32x16, 1);

void setup ()
{
  dotmatrix.setup();
  dotmatrix.clear();
//  dotmatrix.pwm(10);
//  Serial.begin(9600);
}

void loop ()
{
  dotmatrix.pwm(15);
  dotmatrix.line(0,0,31,0,RED);
  displayit();
  dotmatrix.line(31,0,31,15,RED);
  displayit();
  dotmatrix.line(31,15,0,15,RED);
  displayit();
  dotmatrix.line(0,15,0,0,RED);
  displayit();
  dotmatrix.line(0,0,31,15,RED);
  displayit();
  dotmatrix.line(31,0,0,15,RED);
  displayit();
  dotmatrix.line(0,0,31,0,GREEN);
  dotmatrix.line(31,0,31,15,GREEN);
  dotmatrix.line(31,15,0,15,GREEN);
  dotmatrix.line(0,15,0,0,GREEN);
  dotmatrix.line(0,0,31,15,GREEN);
  dotmatrix.line(31,0,0,15,GREEN);
  displayit();
 dotmatrix.circle(15,8,4,RED);
  displayit();
  dotmatrix.ellipse(32-32,0,63-32,15,GREEN);
  displayit();
  dotmatrix.rect(40-32,3,55-32,12,RED);
  displayit();
  dotmatrix.rect(40-32,3,55-32,12,ORANGE);
  dotmatrix.fill(16,7,ORANGE);
  displayit();
  dotmatrix.bezier(8, 14, 27, 14, 30, 1, GREEN);
  displayit();
  dotmatrix.setfont(FONT_5x7);
  dotmatrix.putchar(2,5,'S',RED);
  dotmatrix.putchar(6,5,'I');
  dotmatrix.putchar(11,5,'N',ORANGE);
  dotmatrix.putchar(16,5,'G',RED);
  dotmatrix.putchar(21,5,'E');
  dotmatrix.putchar(26,5,'R',ORANGE);
  displayit();


}

void displayit(void)
{
  dotmatrix.sendframe();
  delay(1000);
  dotmatrix.clear();
}

do not quote me on this, but I think frame buffer has to be 64, because each 8x8 matrix needs 32 bits, and each HT1632C chip can only address 2 8x8 squares, so 32x2=64.   If you're only going with 32, then you're only addressing 0-15 (green) on each matrix.

Again, I'm not sure, but I believe thats the reason why.  If oyu look up the Sure 3216 Board PDF, theres a photo illustrating the way the LEDs are illuminated, OUT0-15 for green, OuT16-31 for red. = 32 addressable lines, 8 rows, = 1 byte per column = 64 total for 2 squares.

I could be wrong though.

[Reply #199 on:]

Doubledaffy

If you just compiled the examples as is, you will have every font loaded into the program space.  To make the executable smaller you need to comment out the ones you don't require.

Martyn.

[Reply #200 on:]

Great call martyn! I had commented out a bunch of them, but apparently not enough. It went down to 4K when I only used the font needed to compile. Thanks a bunch.

[Reply #201 on:]

Excuse me for the long absence, but I've no so much free time anymore. Moreover, I've to be honest... I'm in need, here in Italy there is a terrible situation due to temporary employment and job devaluation... and I wrote this library because I believe in opensource, and as an advertising of my skills too... but it doesn't interest to any company, so it's wasted time for me  Anyway I can see many interested persons here so I decided to support the project, at least to fix major issues

I updated the repository with a minor fix for compiling the library under Arduino 1.0. In relation to issues with > 2 displays, I'm thinking about... without a third display it's a bit difficult for me to debug the code...
Regarding the RIGHT scrolling direction, can somebody show me a video displaying the issue?
For replying to doubledaffy about the program size, ht1632c() actually is a macro that defines various functions. At now I don't find a better solution (I wish to avoid using macros).

[Reply #202 on:]

but it doesn't interest to any company, so it's wasted time for me

It's a hobby, it's time well-wasted

[Reply #203 on:]

I realized the cause of the issues with 1 and 3 displays I think to debug and solve in days...

I discovered that, in sendframe():

Code:

addr = cs + (cs & 2) - 2*!!(cs & 4);

...suits for two display, but with 1 it address memory beyond the framebuffer size (that is why with a doubled framebuffer size it works). So I modified to:

Code:

addr = cs + (cs & 2) - 2*!!(cs & cs_max/2);

...and, consequently:

Code:

_writebits(framebuffer[addr+offs+128], HT1632_DATA_LEN);

changed to:

Code:

_writebits(framebuffer[addr+offs+64], HT1632_DATA_LEN);

I'm doing various other major changes, eg. in plot():

Code:

addr = (x & 63) + 8*(y & ~7);

to:

Code:

addr = (x & 63) + cs_max*(y & ~7);

...and:

Code:

update_framebuffer(addr+128, (color & RED), bitval);

to:

Code:

update_framebuffer(addr+64, (color & RED), bitval);

Moreover I'm studying the feasibility of using SPI instead of bit banging (for datas only, so MOSI-->DATA, CLK--->WR, while CS and CLK are still to be managed with bit banging). I'm looking for somebody among  my colleagues lending me an oscilloscope...

And I'm looking for a better solution for managing cs_max variable: at now it's managed as a memory location to be read everytime it's used... so it's terribly slow... I wish to use a register...

[Reply #204 on:]

Hi lonewolf many thanks for this great library,

Can I propose another couple of changes to getpixel that follow the ones you made to the plot function.

Without the following changes the fill function stops working.

Code:

 word addr = (x & 63) + 8*(y & ~7);

to

Code:

 word addr = (x & 63) + cs_max*(y & ~7);

and

Code:

 byte r = framebuffer[addr+128];

to

Code:

 byte r = framebuffer[addr+64];

Martyn.

[Reply #205 on:]

lonewolf.

First, thank you for coming back and offering to help improve the library.  I for one always appreciate anyone who is willing to take their time to help others free of charge, to better a community.   

Second,  while others may be using this for personal use, I've already thought about trying to use this in a product (see my github page).  I've got working android code as well as .NET code for sending messages to these displays, and your code has been instrumental in developing the entire design.  If you're interested, I encourage you to take a look, follow, take, comment, whatever to any part of the design there.   I'm working on trying to make these things as inexpensive as possible, currently I've got a plug-in board for the 3216 3mm Displays down to around 30$ or so in cost per board (much less if I ordered more than say, 20).   If there was enough interest, I'd be more than happy to send some of the proceeds your way if anyone is ever interested in buying them (or I find an outlet to sell them through)

Third,  I'm sorry to hear about the job situation in Italy,  it's the same way here in the US (at least in California).  While unfortunately I can't offer you a job, I, and I'd hope others who have benefited from the library would be more than happy to send you a donation via paypal for your time, just give me your address and I'll send you a gift in thanks.

I've also offered extra displays to help you out, all I'm waiting on is for you to give me an address and I'll ship one or two out to you (as well as some 3208 boards as well) if you want them to help troubleshoot/develop your library.

send me a PM or email me if you're interested.

Thanks again for your assistance/contribution.

[Reply #206 on:]

Thank you very much, Evanrich. An additional 3216 would be really useful to debug issues with > 2 displays, and with a 3208 I'll will be able to add support for these displays too. I'll send you a pm.

I'm cleaning/fixing up the code of the library, and I finally succeed to use hardware SPI instead of bitbanging DATA/WR to displays. I expected to make sendframe() faster... but there is an insuperable obstacle: hardware SPI works only 8 bits with aligned datas... HT1632C expect 3/9/4/12 bits datas. I have to widely use bit shifting, so using SPI or bit banging the resulting speed is comparable. The code I'm testing:

Code:

void ht1632c::sendcmd(byte cs, byte command)
{
  _chipselect(cs);
  register word val = HT1632_ID_CMD16 + command << 5;
  SPI.transfer(val >> 8);
  SPI.transfer(val & 0xFF);
  _chipselect(HT1632_CS_NONE);
}

void ht1632c::sendframe()
{
  register byte offs, cs, val, csm, head, tail;
  register word addr;
  csm = cs_max;

  noInterrupts();
  for (cs = 0; cs < csm; cs++)
  {
    _chipselect(cs+1);
    SPI.transfer(HT1632_ID_WR << 5);
    addr = cs + (cs & 2) - 2*!!(cs & csm >> 1);
    addr <<= 4;
    head = framebuffer[addr] >> 2;
    tail = framebuffer[addr + csm * 16] >> 2;
    SPI.transfer(head);
    for (offs = 0; offs < 16; offs++) {
        val = framebuffer[addr++] << 6;
        val |= ((offs < 15) ? framebuffer[addr] >> 2 : tail);
        SPI.transfer(val);
    }
    addr -= 16;
    addr += csm * 16;
    for (offs = 0; offs < 16; offs++) {
        val = framebuffer[addr++] << 6;
        val |= ((offs < 15) ? framebuffer[addr] >> 2 : head);
        SPI.transfer(val);
    }
    _chipselect(HT1632_CS_NONE);
  }
  interrupts();
}

void ht1632c::setup()
{
  SPI.setClockDivider(SPI_CLOCK_DIV2);
  SPI.setBitOrder(MSBFIRST);
  SPI.setDataMode(SPI_MODE3);
  SPI.begin();
  noInterrupts();
  sendcmd(HT1632_CS_ALL, HT1632_CMD_SYSDIS);
  sendcmd(HT1632_CS_ALL, HT1632_CMD_COMS00);
  sendcmd(HT1632_CS_ALL, HT1632_CMD_MSTMD);
  sendcmd(HT1632_CS_ALL, HT1632_CMD_RCCLK);
  sendcmd(HT1632_CS_ALL, HT1632_CMD_SYSON);
  sendcmd(HT1632_CS_ALL, HT1632_CMD_LEDON);
  sendcmd(HT1632_CS_ALL, HT1632_CMD_PWM);
  interrupts();
}

As you can see, I have to SPI transmit entire framebuffer shifted left of 6 bits (MSBs). Luckily, it seems that the buffer aboard the HT1632C is a circular buffer, so I managed extra bits sending first bits ("head") again. Variables "head" and "tail" contains the first 6 bits (LSBs) of the start of framebuffer segment (green) to be sent to HT1632C buffer and the start of framebuffer segment (red) to be sent, respectively.

[Reply #207 on:]

I just submitted major updates to the repository. The library contains fixes and optimizations to the "old" code, and the alpha hw SPI code (to be tested, optimized, documented).
The "demo" now run a more accurate benchmark (method profile(), attribute fps)... unfortunaly the older benchmark code overestimated the fps speed  Now I can reach 99fps with newest optimizations, using 2 x 3216 boards. The good news is that the new benchmark is really precise, you can see changes of 1 fps inserting some asm ("nop") in the code.

[Reply #208 on:]

lonewolf,

Do you know if the code will scale linearly scale with frequency?  if you run an arduino at 20mhz, would you get 25% more fps out of the displays?  I'm looking to run my project at 20mhz to get the text as smooth as possible, as with 2+ displays and a large font it slows down a tiny bit

Will get the 3rd display mailed out to you tomorrow!

[Reply #209 on:]

lonewolf,

Do you know if the code will scale linearly scale with frequency?  if you run an arduino at 20mhz, would you get 25% more fps out of the displays?  I'm looking to run my project at 20mhz to get the text as smooth as possible, as with 2+ displays and a large font it slows down a tiny bit

Will get the 3rd display mailed out to you tomorrow!

Yep, the code will scale linearly. But don't worry: tomorrow I found a way to gain further 15% speed. Using two separate framebuffers for green and red planes is possibile to avoid some math with addresses in sendframe() and plot(). I'm deeply testing the code, then I'll release it on the repository.

Thank for the display