Richard AplinA big chunk of NX4 Xilinx code (with precompiled binaries and python code to talk to the tile over UART) just posted: https://github.com/raplin/OpenNX4
Currently the code supports taking to a host over UART (e.g. loading images onto the NX4) and python code is provided to make it do stuff.
It's currently in an 'advanced user' state, there remains one vital thing to figure out on the NX4; how to get the row scanning working (i.e. how to get the CPLD on the LED driver board to play ball).
Once we get that sorted out we're fairly far towards a working, daisy-chainable video tile, controllable by a variety of hosts (Ardunio, embedded linux, etc) using a variety of protocols and doing a variety of 'intelligent display' tricks.
Goal
We should be able to end up with something you can flash onto a tile in a minute or two with a cheap JTAG adapter, and accepts further firmware updates over the wire
The blocker right now is the CPLD (not) doing row scan...
Here's a really, really bad photo where I'm moving the camera so you can see the scanned image (original inset). The tile itself seems high quality; you can get excellent intensity gradients on it, and the 1/6 scan rate w/12-bit CC drivers is a luxury.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
spacecoaster - probably you have an issue with the UART connection; edit the bottom of the python code to just run o.testFlashPowerLED(), should flash red led if working. The amber led (next to the green led) toggles every time it receives a UART message. The yellow LED (other side next to the OUT port) flickers always when it's running. There's a bunch of other test functions commented out e.g. dumpMainFlash that should show data tx/rx working. I am using an FT232R board, set to 3v3, with a 100-ohm resistor on the TX (from FTDI) line. UART RX (data from tile) is IN connector pin 5, TX (to tile) is IN connector 4. If you have a suitable capture device (analyzer, scope) you should see an ascii boot message sent on the UART tile output (at 960kbps) as soon as the FPGA is loaded
Are you sure? yes | no
Pins 5 for RX and 4 for TX was the missing info. I now have the images loaded and fading. The o.testFlashPowerLED() also works. I also see the "\nOpenNX4 V0.0.1\n" message on a logic analyzer. Thanks again.
Are you sure? yes | no
ah yes I typo'd the pinouts on github; fixed now
Are you sure? yes | no
The default UART speed is 960kbps now, which FTDI's do fine. If you don't have a uart that will do that, you'll need to recompile the xilinx - you can change the baud rate over the comms interface (write IOCTL register) but there's a catch-22 if you can't generate that write in the first place :-)
The faster FTDI's (FT2232H) will do 8mbps also, which is supported in the firmware. But UART is basically just a placeholder, SPI / I2S is the way to go. I implemented a streaming video source (ffmpeg -> raw pixels -> linux pipe -> python -> uart -> NX4) in the github repo which obviously would be optimized (pixel formatter as a C lib for the python code) and use hardware H264 decode in ffmpeg. FFMpeg does almost all the heavy lifting anyway...
Are you sure? yes | no
Junk psychedelic lights project zip is in files folder. It's basically garbage but it has some 'magic touch' that enables the leds. It may also be confusing the hell out of the cpld. I'm AFK for 10 days from tomorrow, hopefully you guys can figure out the mystery CPLD stuff! Ian I think I gave you admin rights on that github repo or anyone can fork it or whatever the kids do nowadays
Are you sure? yes | no
oh yeah video !
Are you sure? yes | no
You really wrote a *lot* of code - this is really cool. I was thinking about interposing between the FPGA and CPLD - trying to figure out a way to do this without making an interposer board. Also, a bit worried I may find that the CPLD row scanning isn't initialized until the display receives the right packets.
Are you sure? yes | no
I got carried away with playing with verilog (shiny new toy) there. The CPLD thing is annoying, it can't be hard. It looks like the Barco engineers also enjoyed their geekin' (I assume there's a soft cpu in their bitstream) so maybe they got fancy with the CPLD and it wants some specific conversation with the main fpga... but wtf it doesn't do much, it's a row driver and.. what? a mux for the return data streams from the led drivers for fault testing? Meh.
Are you sure? yes | no
Maybe it's also a watchdog - like it could expect a heartbeat from the FPGA or some sort of more complex back and forth constant handshake.
Are you sure? yes | no
I loaded up the test_pattern_boot.bit and the red status light turns on but I don't get any main panel output. When I load the toplevel.bit file, after the test_pattern_boot has been loaded, then the orange amber light flickers quickly but again no output. Thanks for the code!
Are you sure? yes | no
Hmmm. The test_pattern thing should give you a bunch of psychedelic bright led crap. It sounds like it's running ok tho - the toplevel.bit flickers the amber light once per frame.
Here's how mine boots. Errr maybe I uploaded the wrong .bit file (which required you to ground one of the input pins) - try the new "test_pattern_boot.bit" in github now
Are you sure? yes | no
That did it, thanks very much. Can you post the code for the psychedelic lights?
Are you sure? yes | no
Now the psychedelic lights happen but when I run NX4Comms.py it loads the two images but nothing is displayed. I get the following output and just the flickering amber light. I had pre-loaded the test_pattern_boot.bit.
921600 baud
Loaded pacman.png : 32x36
Loaded nyan_cat.png : 32x36
Are you sure? yes | no
update at top. Man it's stupid how this thing only allow 2-deep comments
Are you sure? yes | no