Show Posts
Pages: [1] 2 3
1  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: March 17, 2012, 02:47:31 pm
you could do what I'm about to do, make an oscilloscope out of an arduino smiley
https://code.google.com/p/arduinoscope/


Interesting  smiley-cool I have to try!
2  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: March 13, 2012, 05:05:43 pm
Take a look at the ht1632c.h file for the #'s,  for example, FONT_4x6 is #1, 8x8 is 16, etc... so if you wanted a 4x6 font, type dotmatrix.setfont(1);


...or you can use
Code:
dotmatrix.setfont(FONT_5x7);
directly, the compiler will translate into the corresponding number for you  smiley-wink
3  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: March 13, 2012, 05:03:18 pm
good news!   Tested your code, and it works for 3 displays.   I can't really tell a speed increase or not, but with 3 panels it scrolls across all 3 in the correct order, and the issue with the dots trailing the text when scrolling right is gone as well!  Congrats!

This is a really good news for me  smiley-lol I cannot get rid of the issue with 3 panels. It doesn't seems to be an hardware problem: the same code perfectly works with 3 display in ChipKIT Uno32!  smiley-eek
Nobody here lent me an oscilloscope... the thing I should try is to add pullup resistors at least on CS and CLK (the issues w/ > 2 panels is related to chip selection thru 74164, not the ht1632c themselves).
4  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: March 06, 2012, 06:52:27 pm
With the last commit of the library code I done an ultimate cleanup of the code. And some speedup. Moreover I found a middle way between don't using cpp macros anymore with complicated definitions in ht1632.h and an acceptable loss of performance. Now the benchmark can reach 136 fps (leaving the define USE_NLFB and USE_ASM in ht1632.h).
As you can see in ht1632.cpp I wrote some assembler code from low level bit banging. Respect to C code, you can avoid some repetitive operations (I analyzed the compiled assembler code with avr-objdump).
My concern is make the library working with > 2 displays. Thanks to Evanrich, I have got a third 3216 display. But I'm noticing enigmatic issues: maybe hardware problems with > 2 displays cascades... (just connecting the third display, the second display stop working  smiley-roll-sweat I'm waiting for someone here lending me a logic analyzer or an oscilloscope...)

NB: There is a little change in instantiang the class ht1632c(): the first parameter now is a pointer to port address. eg:
Code:
ht1632c dotmatrix = ht1632c(&PORTD, 7, 6, 4, 5, GEOM_32x16, 2);

Can you test the actual code with 3-4 displays to confirm or to controvert what it's occurring to me?

As promised long time ago, I have the fancy to port the library to other "Arduinos"... I have a ChipKit Uno32 (PIC32) and already done a test with a scratch code (absolutly not optimized) and reached the astonishing speed of 480fps with two displays smiley-eek Due to weird hardware design pin numbers, pin bitmasks and pin<--->port correspondence aren't consistent as in the original AVR Arduino... so the low level code is really difficult to optimize... (...after I leaned AVR assembler, it will be an opportunity to learn PIC32 assembler too!  smiley-grin)

5  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: February 17, 2012, 02:58:13 pm
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  smiley-mr-green



6  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: February 16, 2012, 08:35:14 am
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  smiley-roll-sweat 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.
7  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: February 15, 2012, 10:46:50 am
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.
8  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: February 14, 2012, 09:58:37 am
I realized the cause of the issues with 1 and 3 displays smiley-cool 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...

9  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: February 13, 2012, 06:46:55 pm
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  smiley-sad Anyway I can see many interested persons here so I decided to support the project, at least to fix major issues smiley

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).
10  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: July 11, 2011, 03:38:03 pm
I've tried hooking up a 3208 display, but it doesn't seem to work yet.  I changed the GEOM to 32x8, used a 5x7 font, but nothing shows on the display when i upload the code.


GEOM_32x8 is defined code is not ready yet: 3208 uses HT1632C but CS isn't managed thru a shift register... _chipselect() routine need to be adapted/rewritten (I think it's enough to )... moreover I need to understand if HT1632C initialization and memory addressing is the same for 32x16 displays (COMS00).

arduino->display
2->7
3->5
4->6(READ Clock according to 3208 data sheet)
5->3(CS1, I flipped CS1 switch on board)

4->6 no, leave NC

Moreover you could try this scratch code (it might work only for one 3208 since only one CS is managed) instead original _chipselect() defined in ht1632c.h:

Code:
void _chipselect(register byte cs)
{
  if (cs == HT1632_CS_ALL) {
    _cs_clr();
  } else if (cs == HT1632_CS_NONE) {
    _cs_set();
  } else {
    _cs_clr();
  }
}

...and another major change to be applied on ht1632.cpp:

Code:
ht1632c::ht1632c(const byte geometry, const byte number)
{
  if (geometry == GEOM_32x16)
  {
    bicolor = true;
    x_max = (32 * number) - 1;
    y_max = 15;
    cs_max = 4 * number;
    framesize = 32 * cs_max;
  }
  if (geometry == GEOM_32x8)
  {
    bicolor = true;
    x_max = (32 * number) - 1;
    y_max = 7;
    cs_max = 1 * number;
    framesize = 8 * cs_max;
  }
  framebuffer = (byte*) malloc(framesize);
  setfont(FONT_5x7W);
  x_cur = 0;
  y_cur = 0;

  _data_out();
  _wr_out();
  _clk_out();
  _cs_out();
  setup();
}

Sorry, I haven't displays other then 3216 to try...
11  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: June 29, 2011, 02:43:19 pm
Some days ago I made and documented a procedure to generate ASCII printable fonts. They are relatively simple to export into a C array that fits for out library if you start from pre-existing BDF fonts. I wrote a simple (and rough!) Perl script that I used to generate last fonts provided with tha last update of the library.

http://code.google.com/p/dotmatrix-editor/wiki/FontGeneration

That procedure works only with fixed size bitmap fonts (es. X11 "misc-fixed" fonts that you can download from here http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html).

For cyrillic fonts the script bdf2c.pl might be modified to imports 0x20 -> 0xff characters instead of 0x20 -> 0x7f... and use misc-fixed KOI8-R fonts... I just done a try with this font set:  http://koi8.pp.ru/dist/xrus-2.3.1-xf4-bdf.tgz and with some manual adjustments of the output I can see/edit some russian letters with the dotmatrix editor. Unfortunately the BDF set I found is "fixed" in a manner of speaking, becaused there are variable size characters. If you find coherent fixed size BDF fonts I can help you to import them.

As an alternative, you might use the dotmatrix editor: http://code.google.com/p/dotmatrix-editor/ but I think it would be extremely laborious to design letter by letter...

PS: With ASCII + KOI8-R lenght of the font arrays increases from 95 to 223 characters (140% size increase).
12  Using Arduino / LEDs and Multiplexing / Re: Dotmatrix editor on: June 29, 2011, 01:54:47 pm
Google Code project: http://code.google.com/p/dotmatrix-editor/ ---> Source ---> Browse (or checkout, if you have a Mercurial client)

Direct link to editor.pl: http://dotmatrix-editor.googlecode.com/hg/editor.pl

Manual (a sort of): http://code.google.com/p/dotmatrix-editor/wiki/Documentation

About procedures and required libraries to install, try and let me know if you notice some issues... My copy is working under a Debian 5.0 Linux, but install procedures for Windows, OSX and Linux distros different from Debian/Ubuntu have to be verified...




13  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: June 25, 2011, 07:51:42 am
I updated the repository with major changes: supports for vertical scrolling, and support for fonts other then 5x7 and 8x8.
About fonts... you can change fonts before calling putchar o scrolling functions with set_font(). There are 21 prefedined fonts (and more will came because I find a relatively simple procedure to generate fonts from X11 BDF fonts) and you can choose betweend FONT_5x7, FONT_8x8, FONT_9x15 and so on... look into ht1632c.h. NB: You cannot compile all of provided fonts because they will fill ~28KiB, so choose your favorite fonts and comment out the #define line in ht1632c.h.
(there is also a prelimary and bugged support for proportional fonts... blank spaces between thin charactes, eg. "i", "1", "!" are removed...)

Note: there are two major changes... scrolltextxcolor is gone and now there are two scrolling functions: hscrolltext and vscrolltext... moreover putchar() doesn't write anymore to display so it requires sendframe().

Can somebody tests scrolling with big fonts and say me something about performance? Big font and proportional support compelled me to return to pixel by pixel drawing of characters instead of memcpy  smiley-sad

14  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: June 20, 2011, 03:51:46 pm
I suspect that two displays with a lot of LEDs lit might be even pushing it for a powered hub.

I hadn't any problem up until now... anyway I work with pwm set to 0~2. In the worst case I'll burn the power supply and/or the hub  smiley-sweat
15  Using Arduino / LEDs and Multiplexing / Re: Sure Electronics new 32x16 bi-color display: 3216 RG -Cont. from read only forum on: June 20, 2011, 02:51:38 pm
Beeker, I power my Arduino and two 32x16 displays thru the USB port. However I don't use directly an USB port but I use a powered USB hub.
I think your dimming issue might relate to low current available on USB port (...but I wan't try myself because I fear to burn the port  smiley-roll-sweat). Cannot you use a power supply? (or a powered hub?)
Pages: [1] 2 3