AVR programming directly through pi?

[arahasya]

Is it possible to tweak the driver board according to this pin out and program the avr directly from pi?

This will save the cost of external programmer and allow dynamic changes to the avr code

https://learn.adafruit.com/program-an-avr-or-arduino-using-raspberry-pi-gpio-pins/configuration

[rjrouquette]

The DPI port consumes all of the GPIO pins. It's not possible to safely mux the pins without additional hardware and it would require a jumper that would need to be manually set to toggle programming mode.

It's also important to note that your link is for the older ATMega processors. The XMega series is only programmable via the PDI interface. I use the JTAGICE3, which is fairly expensive but I bought it when Atmel was still independent and it works with all of the Atmel parts.

I think the least expensive PDI programmer I've seen uses a USBASP and a media converter along with a patch for avrdude to emulate the PDI interface. https://community.atmel.com/projects/atxmega-programmer-050

[arahasya]

My company is under process to get this driver pcb manufactured in decent numbers I am adding the power connector so that the pi can be power from the shield and changing the 40-pin connections so that it can be connected directly on the pi instead of the 40-pin wire Do you have any other suggestions? Also I need your permission to manufacture (for our own product) and possibly put it on sale for others. Thanks!

[rjrouquette]

You have my permission to manufacture, distribute, and sell your own revision of the hardware and software. The project repo does not include a license, but I never intended to restrict the use of the hardware or software.

Please be aware, though, that since you are now developing a commercial product, I cannot offer you free support on your modifications to the hardware or software.

Upstream feature and bug support requests for the original hardware are still welcome.

[arahasya]

just to clear a doubt, except CLK every other o/p pin can be configured right? OE, LAT, A,B,C,D,E can be edited through avr and RGB sequence can be changed from MatrixDriver.cpp right?

[rjrouquette]

You are correct. The panel control lines (OE, LAT, A, B, C, D, E) are generated by the XMega. The panel data bits (R0, G0, B0, etc.) are tied directly to the 24-bit RGB lines on the DPI output and can be re-arranged in the MatrixDriver pin mappings. It's the first array of octal numbers. The second array of octal numbers is the input mapping for the XMega 8-bit port. The panel shift register clock is generated by the AND gate on the CLK and DEN DPI pins.

[arahasya]

I saw this video and was intrigued by the first comment on BCM

https://www.youtube.com/watch?v=h6NH_3KpWe8

How does this library work? With PWM or BCM?

[rjrouquette]

My code combines both PWM and BCM, it's why the bit plane multiplier is larger than the number of PWM bits. The more significant bits are repeated according to their magnitude to increase effective on-time for each pwm bit. With 11 PWM bits and 15 bit planes, the maximum pixel duty-cycle with a color channel set to 255 and brightness at 100% value is about 49% of the row scan time. The maximum duty cycle can be increased by increasing the number of bit planes, but doing so significantly reduces the refresh rate.

[rjrouquette]

To be more specific, the 11-bit PWM using 15 bit planes is actually 9-bits for PWM and 2-bits for BCM. The lower 9-bits set the PWM width from 1 to 256 out of 256. The upper 2-bits are repeated twice and four times respectively with a pulse width of 256.

[arahasya]

Woah! So this solution using Xmega for refreshing seems like a very good substitute for a FGPA. The cost difference is huge. Will using a FGPA over this solution really have any other advantage?

[rjrouquette]

Using an FPGA allows for driving more chains as well using more standard display interfaces like VGA, and HDMI for the data source. The FPGA effectively replaces the raspberry pi.

[arahasya]

But something like a raspberry pi is still needed to feed the data. So I think your solution is pretty good if 4 parallel chains are enough

[daveythacher]

FPGA has advantages. What is the max clock of the PCLK before AVR struggles?

You are effectively bit banging on DPI. So there is a performance tradeoff. FPGA would allow more chains and can support different LED drivers just like the bit banging can. However the GPU issue still remains, as the CPU is required to convert frames. CPU can restrict framerate.

IO processing and CPU processing conflict. This will not appear on panel which is what makes this worth doing versus that other pi led matrix project. DMA will back the transfer so long as the memory interface which is shared for GPU, CPU, DMA, etc. holds.

You can increase the panel size with different drivers. However the max clock for the panels in terms of HUB75 and/or LED panel is not known. DPI takes all the pins which means this will only be recommended for compute modules. Remember GPU can push to DPI which allows FPGA to do things bit banging will never be capable of.

I thought your memory mapped trick was interesting. However there was a performance hit with that. There are other ways you could have done that. The thing is if you use FPGA you can do a lot of different things depending on resource count. Although if you have FPGA you technically do not need DPI.