Author Topic: Creating controller for LED display, help / review needed  (Read 7551 times)

0 Members and 1 Guest are viewing this topic.

Offline Lt_Flash

  • Regular Contributor
  • *
  • Posts: 78
  • Country: au
Re: Creating controller for LED display, help / review needed
« Reply #50 on: July 28, 2018, 04:42:45 pm »
Sorry, of course not on ALL pins, on all power pins :) It's just often you can see a ferrite bead and a cap on VDDIO or other pins, sometimes - 2.2uF + 100nF caps for decoupling and some energy storage on VDDIO pin or VDD pin and so on. Even if you're using a 64-pin version it still worth a look at power supply lines, in a datasheet to your MCU it's pages 47-51, they recommend to use an inductor if you'd like to use switching power regulator for VDDCORE - it's much more efficient in switching mode, as I tested in my designs.

In regards to caps - you don't need electrolytic ones, tantalum or ceramic ones are just fine. You can put two 10uF ones next to each other to have 20uF and that's usually enough to keep power rail smooth and provide enough of 'fast' current in case when MCU needs it as voltage regulator might not be fast enough to react on a sudden change of current draw.

In regards to slow display scrolling - yes, I've had that before, but usually that's because of non-optimized display library and usually SPI still will not work on a speeds above 20MHz so no point in having a serial display and 120MHz MCU, have a look into datasheet for the top speed of I2C/SPI buses. If you're using a parallel display driver - that's when it all starts to work really fast. Also, you can use older SAM4L MCUs if you want high CPU frequency, FPU and other things but combined with low-power features.
 

Offline Lt_Flash

  • Regular Contributor
  • *
  • Posts: 78
  • Country: au
Re: Creating controller for LED display, help / review needed
« Reply #51 on: July 28, 2018, 04:45:29 pm »
Also have a look at pages 2100-2102, see, there's a ferrite bead and multiple decoupling caps in the reference design. They have a 4.7uF + 100nF ones on VDDCORE pin, that's to ensure MCU has enough 'fast' current available if needed and to decouple, of course. Usually, though, I see a 2.2uF in XPlained Pro boards instead of 4.7uF ones for some reason. And there are two 10uF caps and 1uF one on VDDANA and VDDIOA/VDDIOB pins.
« Last Edit: July 28, 2018, 04:49:16 pm by Lt_Flash »
 

Offline muktupavelsTopic starter

  • Contributor
  • Posts: 19
  • Country: lv
    • muktupavels.id.lv
Re: Creating controller for LED display, help / review needed
« Reply #52 on: July 28, 2018, 07:07:19 pm »
Sorry, of course not on ALL pins, on all power pins :) It's just often you can see a ferrite bead and a cap on VDDIO or other pins, sometimes - 2.2uF + 100nF caps for decoupling and some energy storage on VDDIO pin or VDD pin and so on. Even if you're using a 64-pin version it still worth a look at power supply lines, in a datasheet to your MCU it's pages 47-51, they recommend to use an inductor if you'd like to use switching power regulator for VDDCORE - it's much more efficient in switching mode, as I tested in my designs.

I am not planing to use "Switching mode".

In xplained board 10uf capacitors is placed only on one vddana pin and one vddio pin, all other pins have only 100nf capacitors... So how can I decide on which pin to add extra capacitor? Randomly?

Anyway, I don't have 2.2uf and/or 4.7uf capacitors and I would prefer if I would not have to buy new things unless that is absolutely required. I found that I do have 10uf ceramic capacitors (1206 size). I don't have much free place without starting modifying layout. I could place one 10uf capacitor near C6...

In regards to caps - you don't need electrolytic ones, tantalum or ceramic ones are just fine. You can put two 10uF ones next to each other to have 20uF and that's usually enough to keep power rail smooth and provide enough of 'fast' current in case when MCU needs it as voltage regulator might not be fast enough to react on a sudden change of current draw.

I already have those. So can I place one 100uf electrolytic instead of two 10uf ceramic capacitors?

In regards to slow display scrolling - yes, I've had that before, but usually that's because of non-optimized display library and usually SPI still will not work on a speeds above 20MHz so no point in having a serial display and 120MHz MCU, have a look into datasheet for the top speed of I2C/SPI buses. If you're using a parallel display driver - that's when it all starts to work really fast. Also, you can use older SAM4L MCUs if you want high CPU frequency, FPU and other things but combined with low-power features.

I don't use existing libraries... :) So, yes, most likely it can be optimized, but I doubt doing that I would make it at least 2x faster.

SPI is not problem here, it correctly send data to display. Scroll speed is limited to how fast mcu can update content in back buffer and then move it to front buffer. With xmega I was using DMA to show content on display from front buffer.

Parallel display driver? I think you might be thinking about different displays... Display in this case is built from many P10 led modules (32x16).
 

Offline Lt_Flash

  • Regular Contributor
  • *
  • Posts: 78
  • Country: au
Re: Creating controller for LED display, help / review needed
« Reply #53 on: July 28, 2018, 07:25:25 pm »
If you're not using switching mode - then Figure 56-2 applies to your design. Your package is 64-pin one, it has 3 VDDIO pins, each of them should have 100nF bypass cap plus VDDCORE should have a 2.2-10uF (you can use 10uF, shouldn't be an issue, instead of 4.7uF shown) cap + 100nF bypass one, plus VDDIO should have some 'energy storage' cap, shown as 1uF in Fig 56-2, ferrite bead is usually required with its caps. Have a look at table 56-1 - it describes everything in details. Yes, you can omit most of these caps, just use 100nF ones for decoupling and one bigger on 3V3 rail. As for me - 100uF is of a too high value, it will take time to charge it and may cause issues as it will be draining a lot of current to get charged. Here's what ferrite bead is for:

A ferrite bead has better filtering performance compared to standard inductor at high frequencies. A
ferrite bead can be added between the main power supply (VDD) and VDDANA to prevent digital
noise from entering the analog power domain. The bead should provide enough impedance (e.g.,
50Ω at 20 MHz and 220Ω at 100 MHz) to separate the digital and analog power domains. Make
sure to select a ferrite bead designed for filtering applications with a low DC resistance to avoid a
large voltage drop across the ferrite bead.

In regards to display driver - yes, I thought you're using a graphic matrix one, something like 320x240, there's a lot of popular display now, using both SPI and I2C and they're quite slow in serial mode. But you can easily get such display with a parallel connection mode utilising 16-bit mode and they're much faster. But this doesn't apply to your case, of course.
 

Offline Eka

  • Regular Contributor
  • *
  • Posts: 162
  • Country: us
Re: Creating controller for LED display, help / review needed
« Reply #54 on: July 29, 2018, 10:53:28 pm »
What you are doing in the software may be of vital importance. I don't know the layout of the panels you have. I'd guess serpentine. That is first row one direction, then second row goes the opposite direction. It makes manufacture easier. That unfortunately messes up just using a double length buffer, and moving the start point in the buffer.

Next idea: Drawing buffer is like a ring buffer, but both in X and Y directions. To scroll, you change the start X/Y pointer, and only draw the part between the old and new location of the start point.  A routine will need to be written to copy from the start point to the output buffer. It will need to wrap around to the beginning of the physical buffer when it reaches the end of the physical buffer. I'd also look into double buffering the output buffer. That way one can be displayed from using DMA while the other is being copied to.

A few notes:
* The drawing buffer can be larger than the display.
* Having the drawing buffer larger than the display may make it so the area being redrawn can be outside the currently actively displayed area.
* With the drawing buffer as an X/Y array, it should be possible to scroll up and down and left and right.
* If you want to have both fixed and scrolling areas, they can be implemented with separate drawing buffers. The copy to output buffer routine then selects which one to grab pixels from based on where it is writing into the output buffer.
* I've heard of this technique being done decades ago when computers were much slower. XWindows has routines to handle this. I know it existed before XWindows did.

In regards to slow display scrolling - yes, I've had that before, but usually that's because of non-optimized display library and usually SPI still will not work on a speeds above 20MHz so no point in having a serial display and 120MHz MCU, have a look into datasheet for the top speed of I2C/SPI buses. If you're using a parallel display driver - that's when it all starts to work really fast. Also, you can use older SAM4L MCUs if you want high CPU frequency, FPU and other things but combined with low-power features.
I'll second all of this. My setup is much different, and has much fewer LEDs. I'm not familiar with the drive requirements for your display panels, but I'm assuming an array of the panels you mentioned. My MCU dev board is a Teensy 3.6 which has a MK66FX1M0VMD18 Cortex-M4F ARM MCU at 180 MHz. On a 288 APA102 LED array I get free running almost 1000 calculate, and display cycles when using a simple integer math and very simple display calculations. Half my display is written at 8 MHz and the other half is at 4 MHz by the FastLED library. They are on two different SPI busses. I normally use floats to do all my arithmetic for HSV selection, and conversion to RGB, and my displayed images are much more complex than the simple integer test. It slows the update rate down to around 400 updates per second when free running. Normally I use a 120Hz update cycle. Most off my newer drawing objects are defined by mathematical functions, so I do a lot of floating point work. For them I just calculate the function values for HSV at the point on the display. No mixing of adjacent pixels for those objects, except at their edges. I need to work on the display speed, and make sure DMA is being used.

For hooking multiple APA102 strings to one SPI port I use TI 74HCT125 quad buffer chips. At 5 VDC they accept 3.3 VDC logic levels. Check the specs on them. I do think it is the HCT line.

For larger displays I'm thinking of dedicating 2 CPU cores to calculating the display on a multi core ARM chip like used in the Raspberry Pi. I'll have another core that handles the updating of the display, and gives the marching orders to the calculation cores. The last core will be left for running raspbian, reading the GPS, syncing time with time servers on the net, etc. Raspberry Pis have a nice fast SPI port that can drive up to 32MHz. I just wish I could get a 4 core one in a Pi Zero form factor. The normal format is to large for some of my artwork.
 
The following users thanked this post: muktupavels

Offline muktupavelsTopic starter

  • Contributor
  • Posts: 19
  • Country: lv
    • muktupavels.id.lv
Re: Creating controller for LED display, help / review needed
« Reply #55 on: July 30, 2018, 10:53:01 am »
What you are doing in the software may be of vital importance. I don't know the layout of the panels you have. I'd guess serpentine. That is first row one direction, then second row goes the opposite direction. It makes manufacture easier. That unfortunately messes up just using a double length buffer, and moving the start point in the buffer.

Display is built from 72 P10 modules that are placed in two rows. Each row is connected to controller and modules in row are daisy chained. Total display size in diodes is 1152 x 32. Module is divided in 4 groups and only one group is displayed - 1/4 scan rate or whatever is proper name for it...

Next idea: Drawing buffer is like a ring buffer, but both in X and Y directions. To scroll, you change the start X/Y pointer, and only draw the part between the old and new location of the start point.  A routine will need to be written to copy from the start point to the output buffer. It will need to wrap around to the beginning of the physical buffer when it reaches the end of the physical buffer. I'd also look into double buffering the output buffer. That way one can be displayed from using DMA while the other is being copied to.

Hmm, sounds like something I could try. :) Right now existing content is moved left and new content appended...

So you suggest to use 3 buffers? One that is used for drawing and two for output? That can be problematic, xmega has 16 kb sram and one buffer needs 4.5 kb...

A few notes:
* The drawing buffer can be larger than the display.
* Having the drawing buffer larger than the display may make it so the area being redrawn can be outside the currently actively displayed area.

I was thinking about having buffer that could contain all content, but then sram is my problem.

* With the drawing buffer as an X/Y array, it should be possible to scroll up and down and left and right.
* If you want to have both fixed and scrolling areas, they can be implemented with separate drawing buffers. The copy to output buffer routine then selects which one to grab pixels from based on where it is writing into the output buffer.

Text just moves from right to left. Different areas are not needed. :) I am creating this controller because of two reasons/problems with controllers that was used with display:
- existing controllers could not scroll text fast enough.
- multiple things require separate areas. you can place temperature in one area, text in other, but client wants that all content scrolls as one big text. so one area with temperature, text, time...

Anyway I think that I will try to finish new pcb. I have updated it to add 4.7uF capacitor (c19) for VDDCORE. Added also 10uF (c20) capacitor and ferrite bead (l1) for VDDANA, and 47uF (C21) for 3V3.
 

Offline Lt_Flash

  • Regular Contributor
  • *
  • Posts: 78
  • Country: au
Re: Creating controller for LED display, help / review needed
« Reply #56 on: July 30, 2018, 11:01:29 am »
Anyway I think that I will try to finish new pcb. I have updated it to add 4.7uF capacitor (c19) for VDDCORE. Added also 10uF (c20) capacitor and ferrite bead (l1) for VDDANA, and 47uF (C21) for 3V3.

Sounds and looks good to me, should be much more stable now even in an environment with high noise!
 
The following users thanked this post: muktupavels


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf