Guzunty Pi. New users start here.

[ptrav1956]

Derek,

that seems to have done the trick .. all 4 servo pins are now working and driving the servos as they should. At least when they are out of the arm ... all my remaining problems are mechanical and coding ones

Thanks very much for all your help.

Paul

[guzunty]

Hi Paul excellent news. You are most welcome.

May I ask which change got you going?

[ptrav1956]

Derek,

I think probably the key thing was changing the clock divisor; with the 9g micro servos I was using, a divisor of 80 was ok but with 50 the servo wouldn't respond or would only respond erratically. Taking the power from a separate supply and not from the Guzunty pins probably helped too. In the final design I had always envisaged a separate power rail for the servos but for test purposes I had it plugged into to 5V and Ground pins on the Guzunty.

On a separate note, do the input pins default to high? If I read from the pins all bits are set, so I would need to pull these low to register a signal? Is this correct?

Making progress!

Paul

[guzunty]

If I read from the pins all bits are set, so I would need to pull these low to register a signal?

Yes, I recommend using pull up resistors with a switch that connects to ground when closed. Something around 10K should be fine as a pull up. The CPLD has circuitry that will pull a floating value high by itself, but it is really there as a power saving method. Since you would be relying on an undriven input to float up into the undefined region, it might or might not work without a pull-up. Or it might work for a while and then one day stop working.

Better to fit the pull ups from the get-go.

HTH,

Derek

[jaybee007]

Hi Derek,
Just wondering if you have tried compression to boost the clock speed. I've seen someone doing it with the same cpld. Though im not sure how this was achieved. I'm running a 7" ssd1963 screen but the max speed I can get is 82MHz. This is fine for playing roms, but when I play a 720p video it struggles a bit. Here's a link to a video of the issue I'm describing : https://m.youtube.com/watch?v=CKDNqlizkQk.
Thanks in advance

[guzunty]

I have not tried compression.

It should improve the frame rate if the target LCD controller has built in decompression, but I am not aware of any that do.

Certainly if you're running the controller at or near its maximum resolution you can expect the frame rate to suffer. SPI simply can't go any faster.

In case you are wondering, the CPLD does not have enough capacity to implement decompression. Video decompression is very RAM intensive and RAM is not something a CPLD is able to provide much of at all. If you're looking around for programmable devices that might be able to implement decompression, I might suggest a Spartan 6. I'm not aware of any cores that do decompression, but there's a reasonable chance they exist.

HTH,

Derek

[guzunty]

Yes, they exist, here's one:

http://opencores.org/project,bluespec-h264

HTH,

Derek

[jaybee007]

Hi Derek,
Thanks for your reply. I do believe the guys over at hwlevel.com have achieved decompression using the same cpld as the guzunty.
http://www.hwlevel.com/hwlevel/RPiDispl ... plays.html
I'm just not sure how I would go about this. Also would it be worth it, Or is it possible to up the dma ? And would that help with anything ?
Thanks in advance

[guzunty]

Definitely not possible without some kind of external SRAM. Seriously, I'll eat my hat.

What makes you believe that they are decompressing the video with a CPLD? I followed the link and couldn't find any references to the use of a CPLD. Can you provide a more specific link please?

[jaybee007]

Hi Derek,
Sorry I should posted this link :
http://www.hwlevel.com/hwlevel/LCD-PI32/lcd-pi32.html
The cpld can be clearly made out in this image. I assume they use the same setup on all there models .
Also this link in they're forum :
http://www.hwlevel.com/phpBB3/viewtopic.php?f=8&t=1197

Not sure if I'm should post links to other forums. So if I have to take it down no problem

[guzunty]

I want to believe you, really I do

I did a google search of that whole site and got no hits on the keywords CPLD or XC9572XL or XC9500XL.

I do see where they have compression settings on the driver during modprobe, but as for the decompression mechanism I have no idea.

EDIT: Hmmm, that does look like a CPLD on the back there. They could be using that to read the buttons though, or using it with an external SRAM to do simple decompression.

[guzunty]

Reading between the lines some more, they say that the compression works best on monitor desktops.

I infer (or at least hypothesise) that this is because desktops tend to have large areas of flat colour. Going one step further, they may be doing simple run length encoding which might be squeezed into a CPLD without external RAM.

That wouldn't help with 720P video, since RLE would not compress much for most normal video content.

[jaybee007]

Hi Derek,
Thanks for the speedy reply.
This is what gave me the impression it was possible
Drivers for LCD-PI33, LCD-PI43 and LCD-PI50 also have a compress parameter. If compress is set to 1 the data transferred over SPI is compressed on the fly. Especially in GUIs this technique works very well. Some examples (that work on my RPi):
Code: Select all
modprobe d51 sclk=32000000 compress=1
modprobe d51 sclk=64000000 compress=0
modprobe ssd1963 sclk=48000000 compress=1

Higher SPI clocks are on RPi's limit and whether they work or not might depend on power supply quality and other factors.

The ssd1963 driver for LCD-PI43 and LCD-PI50 also has a rotation parameter which can be 0, 90, 180 or 270. It rotates the screen to desired orientation.

When I was trying get my 4.3 " ssd1963 screen going I stumbled on that image and the cpld is what lead me to your wiki
Thanks again

[jaybee007]

Hi Derek,
I have signed up over at opencores.
Do I just download the http://opencores.org/project,bluespec-h264 core and program the cpld ?
Sorry if it seems like your spoon feeding me
Thanks

[guzunty]

Hi there,

Don't worry, I don't feel like I'm spoon-feeding you. I do think you are in denial, though.

Much as both of us would like it to fit, there is absolutely no chance that a H264 decoding core will fit in a CPLD.

It's like trying to run Windows 8 in 64 kB of RAM.

[guzunty]

As for downloading the project, no I'm afraid you can't download it and program the CPLD.

The open core is a design that could be implemented in any one of several dozen programmable gate arrays from several manufacturers.

These are the steps you would need to do in summary:

- Download the core and compile the source files (either verilog or vhdl)
- Look at the top level entity definition. It defines the incoming and outgoing signals
- For each signal, map it to a pin on the actual chip you're targeting by filling out a user constraints file
- Pass the RTL files from the compile step and the user constraints file to the fitter. <-- This is the step that will definitely fail when you try it on a CPLD
- Convert the output from the fitter into a series of JTAG commands
- Result: an xsvf that can be loaded into the CPLD

It sounds a lot and it gets easier after a number of projects, but now you know why I provide ready compiled cores for you on the Guzunty website.

Don't let me put you off if you want to have a go. In fact quite the opposite, if you want to have a go I'll bend over backwards to help you out. Hardware design languages are just _so_ cool you'll be so glad you had a go (but I will encourage you to choose a simple example to start with ).


HTH,

Derek

[jaybee007]

Hi Derek,
Thanks for the kind words, I think I'm going to give this a go .
Which if any SRAM do you recommend ? I saw there are a few that run at a max speed of 64MHz . Do you think that would be fast enough ?. Anything over that is in a LQFP package .
Also I did look at the spartan 6 but without designing something this was the best I could find.
http://www.ebay.com/itm/XILINX-Spartan- ... 35ce356d28


http://www.ebay.com/itm/Mojo-V3-FPGA-De ... 2c7d0894da

Thanks again,

[guzunty]

Here is an alternative H264 decoder core: http://opencores.org/project,nova

It requires 169K logic gates while the XC9572XL has 1.6K logic gates, so even if you add SRAM the CPLD is ~100x too small.

Another board to consider is the Papilio. The core will likely fit in a Papilio One which is only $37 or so.

http://papilio.cc

Also check that the Xilinx Webpack ISE licence covers building cores that size.

[dgnabq]

Hi,

I have successfully built and tested the basic Guzunty. A very nice product, thanks! When I run the test program I get any where from a few to a few hundred cycles of 9 Hz and then the output stops. I tracked the problem down to the GCK1 on the Raspi stopping after a fraction of a second to a few seconds. This is very repeatable except for differences in the time the clock is on. Any thoughts of how I can determine why that is happening?

Thanks,

Dave

[guzunty]

Hmmm. I have never seen or heard of that happening before. Do you have a scope? If so, check that GPIO4 is oscillating or if that stops too after some time. I'd suggest checking that with the Guzunty removed from the GPIO connector.

If GPIO4 stops, then the problem is some other program or daemon you're running concurrently with the test program.

If GPIO4 does not stop oscillating, then you have some kind of intermittent break or short between the GPIO4 input to the Guzunty and the GCK1 input on the CPLD. To check for dry joints on the pins, on the component side of the PCB, you'll want the fourth pin up from the bottom on the inside row of pins on the GPIO header (J1). The pin you're looking for happens to lie very close to the silk screen label '3.3'. The other end of that trace is on the CPLD socket, on the solder side of the PCB, third pin in from the right, second to top row, right under the 'n' in 'Guzunty' on the silk screen. You should be able to follow the trace from this pin all the way to JP11 and then from JP11 to where it disappears under the header socket. Look for damage to this trace along its length. In all cases, top and bottom refer to the PCB held as described in the construction notes on the website. With the P1 connector running along the top of the PCB. It is also possible to use JP11 as a test point for a continuity check.

Finally check to see if the socket is making good contact with the CPLD itself.

Hope all that helps,

Derek

[dgnabq]

Hi Derek,

I should have been a little clearer. After I saw this behavior I closed JP19 and watched the signal on P2-15. It mirrored what was happening on the 9 Hz line. Both viewed with a scope.

Thanks,

Dave

[guzunty]

Hi Dave,

Yes closing JP19 will bring the clock signal out to P2. It won't change any other behaviour, assuming you're not driving pin 15 of P2 with anything else.

However, we need to establish if the clock signal is stopping as it comes out of the Pi or if it is intermittently being pulled low (or high) by a short on the Guzunty board. I suggest you remove the Guzunty and check the clock signal coming from the Pi on pin 7 of the GPIO connector. If it is steady and doesn't stop we can move on to look for other things. If it stops there, then you're likely looking at some kind of software issue.

HTH,

Derek

[karlitos]

Hello,

first of all thank you for the wonderfull guzunty project ! I am going to build the Guzunty on a stipboard with a XC9572XL and this adapter http://ebay.eu/1t8Hl45. I would like to use it to drive couple of the Sainsmart 3.2 LCDs on Raspberry Pi.

Although the schematic for the Guzunty board, provided on Gihub is well comprehensible I am having issues understanding the wiring of the Sainsmart 3.2 Lcd to the Guzunty. I was only able to find the schematic for the LCD daughter-board on github. I do not want to re-build the LCD daughter board, beside the fact, that my layout will differ from the Guzunty board. I am not yuite able to derive the propper wiring from the daughterboard schematic.

Is there some understandable schematic providing explanation, how to connect the Sainsmart 3.2 LCD to the Guzunty board ?

Thank you very much.

[guzunty]

Hi karlitos,

Its all open source, so the schematics contain everything you need. What is perhaps not obvious is how the connectors on the daughterboard schematic map onto the Pi and Guzunty connectors and the LCD module itself, so I hope this explanation helps:

• P3 connects to the LCD module.
  J1 maps onto the Pi GPIO connector.
  P1 maps onto the Guzunty P1 connector.
  P4 maps onto the Guzunty P2 connector. All these 4 connectors are pin for pin mappings i.e. pin 1 maps to pin1 on the mating connector.
  P2 carries spare IO lines from the RPi. It is not used to drive the LCD and could be ignored unless you need additional IO.
  P5 carries spare CPLD IO lines and again is not used to drive the LCD.

Also note that many of the connections go through the Guzunty board itself and so do not appear on the LCD schematic. Look at the gz_lcd/gz_lcd.rpt file. It lists all of the connections which pass through the CPLD and says which pins they are mapped to.

MOSI, MISO and SCLK go to both the CPLD and P3. This is so that the Pi can send data to the display on spi.0 and read the touchscreen on spi.1.

When you say you want to drive a couple of these modules, do you mean from the same Pi and showing different displays? If so, you should be aware that this will require customisation of the fbtft driver and will have frame rate consequences, since the two displays will share the same SPI bus. The Guzunty core would also have to be modified to output a selector to address the two displays. If both are to show the same image you can just wire up the modules in parallel.

[karlitos]

Hi guzunty,

thank you very much for answering me. I am aware of the fact, that the guzunty project is open source. I will dive in over the weekend and with your explanation will try to understand the wiring and schematic.

In my project I am planing to drive only one display on one R-Pi with one guzunty board. But I plan to build several items as as a christmas gift co I am trying to reduce the costs. This is the only reason I am trying to re-build the guzunty board instead of byuing it from you.

I will need only the necessary connectionss for driving the display and for a rotary encode and 1-2 buttons. I hope I can realize the eletronics on a stripboard with the XC9572XL and the TQFP44 adapter-board from ebay.