Electronics > Beginners
Creating controller for LED display, help / review needed
<< < (11/12) > >>
Lt_Flash:
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.
Lt_Flash:
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.
muktupavels:

--- Quote from: Lt_Flash 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.

--- End quote ---

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...


--- Quote from: Lt_Flash on July 28, 2018, 04:42:45 pm ---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.

--- End quote ---

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


--- Quote from: Lt_Flash on July 28, 2018, 04:42:45 pm ---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.

--- End quote ---

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).
Lt_Flash:
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.
Eka:
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.


--- Quote from: Lt_Flash on July 28, 2018, 04:42:45 pm ---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.

--- End quote ---
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.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod