guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Fri Nov 22, 2013 10:59 am

Hi Steve,

I am 99% sure you're never going to get touch working while there is need for JP15 to be linked. JP15 carries GPIO7/CE1 to FB4_MC5 of the CPLD. Now, CE1 is needed for touch operation and my understanding of your findings suggest that GPIO7 is currently needed for screen operation. The two cannot co-exist.

The fact that the display stops working when you unlink JP15, suggests a little more investigation is needed. I suspect you need to unlink it _and_ do some other adjustment to your wiring.

Here is my guess:
- You are connecting RD/CS on the display to FB3_MC16, and setting the driver to output CS to GPIO7.
- The CPLD is programmed to pass FB4_MC5 (fed from RPi GPIO7) through to FB3_MC16, so the display works with JP15 linked.
- When JP15 is unlinked, the CD signal no longer reaches the CPLD, so the display stops working.

If my guess is accurate, you need to:
- Unlink JP15 as I suggested.
- Disconnect FB3_MC16 and instead take the display RD/CS signal directly from pin 13 (GPIO27) of the Pi header.
- Change the driver startup argument from dc:7 to dc:27 (this assumes you have a recent Pi, if you have an older one, you may need it to be dc:21).

Only once Pi GPIO pin 26 is freed up will you have a chance of getting touch working. Leave the touch driver disabled until you have the display working in its new configuration.

Stick with it, you've done well. These displays are among the more challenging things you can expect to interface with your Pi. It is always easier to move forward one you have a configuration you know works. Make one coherent set of wiring and driver configuration changes at a time and check the display still works before moving on and you will be successful.

HTH,

Derek
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: Guzunty Pi. New users start here.

Fri Nov 22, 2013 2:25 pm

Just ordered one. Not really for the CPLD, ordered a pif-fpga to test that, but for the 4p8o8i, 24o1I and the buffering (MOST IMPORTANT as saves transistors for LED driving, 144 multiplexed, with null output power save transmission between plexes).

My question is, as the pif-fpga can pass through the SPI to the Guzunty, the LEDs should work, but what is the maximum number of 20mA LEDs that maybe lit, assuming the pif-fpga is not driving a load, but is running about 20MHz?

I'll likely put the Guzunty outside the case, so what are the minimum number of connections to the Pi?
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Fri Nov 22, 2013 3:10 pm

Hey Jackokring,

Thank you for your interest in the Guzunty. The answer to your questions vary depending on where you are deriving the I/O drive power for the Guzunty. The Guzunty I/O supply is passed through a jumper so that you can provide an alternate supply if it is needed. By default though, this is taken from the Pi's own 3.3v supply, so you are subject to the same total current limitations documented here:

http://elinux.org/RPi_Low-level_peripherals

See the section titled 'Power Pins'.

Using an alternate current source, the limiting factor is the CPLD's ability to handle current. The answer is somewhat complex, depending on what you have programmed into the core. Xilinx have a number of good documents on their website to help you to compute this, for example this one is specific to driving LEDs:

http://www.xilinx.com/support/documenta ... app805.pdf

This one covers the CPLD power topic generally:

http://www.xilinx.com/support/documenta ... app114.pdf

and for more general design tips:

http://www.xilinx.com/support/documenta ... app112.pdf

If you want to totally max out the CPLD current throughput, it is also possible to tweak the standard cores to build in a skew to prevent load surges.

HTH. Please let us know if you have any follow up questions.

best,

Derek
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

vmi
Posts: 13
Joined: Sat Nov 09, 2013 1:36 am

Re: Guzunty Pi. New users start here.

Sun Nov 24, 2013 2:06 am

Hi Derek,
What a difference a day makes. Yesterday I managed to cook the CPLD (it reached a burning hot temperature *), and despite many subsequent JP15 link/unlink attempts I could not get the screen back.

One last try today, I realised that I had "plugged" (pins taped) FB1_2 .. FB3_11 in backwards (unplugged for solding iron access to P2). The screen then, amazingly came good, as I thought that the "cooked" CPLD would be cactus. Your guzunty pi is a remarkably tough device.

I repeated JP15 unlink, and found that the direct CS connect from pin 13 will drive the screen. Thanks, for that advice.

That is as far as my luck went, since the touch screen still does not work.

My I ask what your lsmod shows for ads7846_device?

Code: Select all

[Rpi512:~]$ lsmod
Module                  Size  Used by
fb_ssd1289              4448  2 
fbtft_device           21220  0 
fbtft                  31181  2 fb_ssd1289,fbtft_device
syscopyarea             3028  1 fbtft
sysfillrect             3338  1 fbtft
sysimgblt               2143  1 fbtft
fb_sys_fops             1444  1 fbtft
ads7846_device          6046  0 
ads7846                 7819  0 
My setup gives the same dmesg as your listed output, but lsmod suggests that ads7846 is not in use.

Also, is it important to run the command:

Code: Select all

DISPLAY=:0 xinput --set-prop 'ADS7846 Touchscreen' 'Evdev Axis Inversion' 0 1
I have tried.

Steve.

(*) I think the cooking may have been due to an underboard short through sloppy mounting on the pi

vmi
Posts: 13
Joined: Sat Nov 09, 2013 1:36 am

Re: Guzunty Pi. New users start here.

Sun Nov 24, 2013 2:20 am

xinput may also list input devices:

Code: Select all

[Rpi512:~]$ DISPLAY=:0 xinput --list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ ADS7846 Touchscreen                     	id=6	[slave  pointer  (2)]
⎜   ↳ Riitek Micro Keyboard                   	id=8	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Riitek Micro Keyboard                   	id=7	[slave  keyboard (3)]
Actually, xinput has quite a few options. I will investigate.

Update: Touch is working, just in an odd way. If I hold my finger the cursor appears nearby. So the screen coordinates need modification.

Steve.

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Mon Nov 25, 2013 9:57 am

Delighted you got there in the end.

It sounds like the behaviour you're seeing is not too different from my experience. To improve the touch response from there, I think you'll need to consult with Notro. :-) It is very possible my settings are sub-optimal. Touch didn't matter to me for my application, so I did not spend much time with it. If you find better settings do please share, though.

I'm not sure what would have caused the CPLD to have gotten hot, we have not heard any reports of this before. For a time, I was concerned about possible shorting to the can of the main supply capacitor near the USB power socket on the Pi, but I checked with a multimeter and the case turned out to be non conductive. The build instructions suggest a piece of anti-static foam under there to provide mechanical support and you can always put Kapton tape on the underside to eliminate any possibility of a short.

I'm glad the CPLD survived, though. They do seem very tough little devices; we have only had one field failure out of the many hundreds shipped.
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

Pi-on
Posts: 1
Joined: Mon Nov 25, 2013 9:01 pm

Re: Guzunty Pi. New users start here.

Mon Nov 25, 2013 9:31 pm

Hi Derek,

Just wanted to let you know the Guzunty and LCD daughter board arrived, built, and working great with the sainsmart 3.2" touch.
Notro kernel patch for the spi helped...(used his new easy method using the update). I noticed the DMA seems to be working too. Hat's Off to you both...great job.
Cheers.
--... ...--
Scott

nrg-fv
Posts: 4
Joined: Tue Nov 26, 2013 9:48 pm

Re: Guzunty Pi. New users start here.

Tue Nov 26, 2013 10:10 pm

Hello, I have very little or better to say no knowledge about interfacing raspberry pi with anything using gpio. I would like to learn how to program and use a stepper motor. I have built guzunty from received kit and I think it is working fine. The stepper motor I have is bipolar motor took from an old DVDROM with 4 wires. Could anyone here please tell me how to connect it and program using raspberry pi, guzunty and whatever else needed. I'm assuming I will need additional power supply to run the motor and CPLD needs to be programmed with specific core. I'm looking for step by step, low level instructions as I really have not done any thing like this before. So my first challenge is to connect it to guzunty, I need to know which pins on guzunty needs to be connected and which core would be the most appropriate one (gz_4p8o8i?) . I would really appreciate any help.

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Wed Nov 27, 2013 12:39 pm

Hi,

I have interfaced two different steppers using a Guzunty in the past.

Here is one I've successfully used http://robocraft.ru/files/datasheet/28BYJ-48.pdf

Depending on the quality of your PSU, it is in my experience possible to drive motors like this directly from the Raspberry Pi 5v power. The Guzunty can drive several steppers simultaneously, I use one SN754410 quadruple Half-H driver for each motor.

It is possible to drive the motors using any core that provides outputs. You'll need 4 outputs for each motor. Doing this, we set the state of the control bits directly from a 'C' or Python program. Alternatively, it is also possible to build a custom core that controls the motors from the Guzunty, with the Pi just sending the required number of steps for each motor and receiving an interrupt when the movement (or possibly all movements) is complete. I think I have some prototype VHDL somewhere for that which I'd be happy to share.

As for exact wiring, that is difficult to help with without knowing more about the motor you are using. Look for any serial or part numbers on it. A photo or diagram of the wires it has may also prove helpful.

best,

Derek
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

nrg-fv
Posts: 4
Joined: Tue Nov 26, 2013 9:48 pm

Re: Guzunty Pi. New users start here.

Wed Nov 27, 2013 5:30 pm

Hi Derek,

Thank you for quick and informative reply. From what you are saying I understand that I can't connect the motor directly to guzunty but still need a driver. I've ordered the drver you have recommended from ebay so I have to wait for it now. The motor I have doesn't have any markings unfortunatelly but it looks exactly like this one https://lh5.googleusercontent.com/-9yw5 ... 699712.jpg

While waiting for the driver I would like to explore on the software side of how to controll the motor so could you please explain how should I start? I would be more than happy to try your experimental core once everything is connected together.

Thank you

Martin

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Wed Nov 27, 2013 5:46 pm

Hi Martin,

Thanks for the photo. Someone reading this may know what the connections are. I'm afraid I don't :-)

Do you need the worm drive mechanics along with the motor?

A quick Google found this:

http://www.youtube.com/watch?v=6PlBbOG8pbY

…. which shows an arduino doing what you want I think.

Doing the same with a Pi should be pretty straightforward. The link includes forward links to source code too.

HTH,

Derek
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

nrg-fv
Posts: 4
Joined: Tue Nov 26, 2013 9:48 pm

Re: Guzunty Pi. New users start here.

Thu Dec 05, 2013 10:17 pm

guzunty wrote:Hi Martin,

Thanks for the photo. Someone reading this may know what the connections are. I'm afraid I don't :-)

Do you need the worm drive mechanics along with the motor?

A quick Google found this:

http://www.youtube.com/watch?v=6PlBbOG8pbY

…. which shows an arduino doing what you want I think.

Doing the same with a Pi should be pretty straightforward. The link includes forward links to source code too.

HTH,

Derek
Hi Derek

Thank you for link, I would like to use worm drive mechanics for adjusting raspberry pi cam angle if I'm able to get all this working together :) So far I have finally all required elements: SN754410 driver, breadboard, connectors and I found how coils are wired inside the motor using ohmmeter. I found this tutorial http://www.raspberrypi.org/phpBB3/viewt ... 49&t=55580 which I find simple enough to understand but knowing guzunty is using SPI interface python program needs to be modified, could you help me with that? I'm just starting to learn how to program so this project is quite complicated to me.

When it comes to connecting the motor to guzunty I'm using the knowledge found on below links
http://roevalley.com/newsbrowser/pi_pro ... i-step.htm
http://www.ti.com/lit/ds/slrs007b/slrs007b.pdf
https://raw.github.com/Guzunty/Pi/maste ... 4p8o8i.rpt

My raspberry pi is an old version 1 but I understand that with guzanty as intermediary that doesn't matter?

Please correct me if I'm wrong. I will need 6 outputs as with that example from the tutorial I found. 2 outputs will be needed for pin 1 and 9 on SN754410 and the rest 4 for 2,7 and 10,15 to control the motor coils. Motor coils should be connected to pins 3, 6 and 11, 14 respectively. Ground 4,5,12,13 and VCC1 pin 16 and VCC2 pin 8 should be connected to the power output on guzunty (no jumpers section with 5V) or outside power source. Using the core gz_4p8o8i I can connect pin 1 on the driver to FB1_15, 9 to FB1_17 and outputs which control the coils 2,7 to FB2_2, FB2_5 and 10,15 to FB2_6, FB2_8. I hope I got all this right.

Thank you

Martin

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Fri Jan 03, 2014 2:30 pm

Happy New Year to all Pi users...

Got this question posted on GitHub and I thought maybe it would be of general interest.

"I asked santa claus to bring me one of these boards they look really great, however now I have a concern after reading all the details regarding set up, it appears that GPIO 4 is required to be used full time, is there any possibility to use some other pin, as my project needs gpio 4 to connect 6off DS18B20 temperature sensors and to my knowledge they will only work on this pin on the raspi, I would even consider purchasing say a RTC or something if this would make it possible to use both the Guzunty and one wire DS18B20 devices, unless of coarse it is possible to configure one of Guzunty pins to work with these temperature sensors? please advise thanks"

Thanks for the question Toshi, and welcome to the Guzunty community.

The answer is that GPIO4 does not have to be dedicated to a clock signal if you have another need for it. The reason it is set this way by default is that GPIO4 on the Pi can provide a hardware clock which many cores need. If you don't need a clocked core (and none of the simple IO cores do) you can easily repurpose GPIO4. If you do need a clocked core, you can still repurpose GPIO4 and add a little hardware to provide your own independent clock, you won't need anything as sophisticated as an RTC, just a simple crystal will do.

The Guzunty is highly reconfigurable using the solder pads on the underside, so there is more than one way to do this. Therefore, let me ask some questions before I suggest how to proceed:

- Have you built your Guzunty in the standard Compact configuration? (i.e. did you build it with the stock kit parts? see the "Standard build configurations" page for other possibilities).
- Do you need a clocked core ? (PWM, LED driver or something like that) or do you just need simple IO?

Finally, using Guzunty to interface to the DS18B20 sensors may be possible, but I don't have experience of using the 1-wire protocol to say without getting one and experimenting with it.
Last edited by guzunty on Fri Jan 03, 2014 2:45 pm, edited 1 time in total.
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Fri Jan 03, 2014 2:32 pm

nrg-fv wrote:
guzunty wrote:Hi Martin,

Thanks for the photo. Someone reading this may know what the connections are. I'm afraid I don't :-)

Do you need the worm drive mechanics along with the motor?

A quick Google found this:

http://www.youtube.com/watch?v=6PlBbOG8pbY

…. which shows an arduino doing what you want I think.

Doing the same with a Pi should be pretty straightforward. The link includes forward links to source code too.

HTH,

Derek
Hi Derek

Thank you for link, I would like to use worm drive mechanics for adjusting raspberry pi cam angle if I'm able to get all this working together :) So far I have finally all required elements: SN754410 driver, breadboard, connectors and I found how coils are wired inside the motor using ohmmeter. I found this tutorial http://www.raspberrypi.org/phpBB3/viewt ... 49&t=55580 which I find simple enough to understand but knowing guzunty is using SPI interface python program needs to be modified, could you help me with that? I'm just starting to learn how to program so this project is quite complicated to me.

When it comes to connecting the motor to guzunty I'm using the knowledge found on below links
http://roevalley.com/newsbrowser/pi_pro ... i-step.htm
http://www.ti.com/lit/ds/slrs007b/slrs007b.pdf
https://raw.github.com/Guzunty/Pi/maste ... 4p8o8i.rpt

My raspberry pi is an old version 1 but I understand that with guzanty as intermediary that doesn't matter?

Please correct me if I'm wrong. I will need 6 outputs as with that example from the tutorial I found. 2 outputs will be needed for pin 1 and 9 on SN754410 and the rest 4 for 2,7 and 10,15 to control the motor coils. Motor coils should be connected to pins 3, 6 and 11, 14 respectively. Ground 4,5,12,13 and VCC1 pin 16 and VCC2 pin 8 should be connected to the power output on guzunty (no jumpers section with 5V) or outside power source. Using the core gz_4p8o8i I can connect pin 1 on the driver to FB1_15, 9 to FB1_17 and outputs which control the coils 2,7 to FB2_2, FB2_5 and 10,15 to FB2_6, FB2_8. I hope I got all this right.

Thank you

Martin
Martin, did you get this working?
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

Toshibass
Posts: 18
Joined: Fri Jan 03, 2014 3:10 pm

Re: Guzunty Pi and one wire DS18B2

Fri Jan 03, 2014 4:20 pm

Hi and thanks for your response.

I will answer this here, and not on github as I am sure others could want to follow this.

Answers to your questions built Guzunty as Hybrid, like fitted a 2 by 13 female header with long pins.
I want to use gz_16o8i (initially), to test feasibility of replacing a couple of mcp23017 I am using on my project built using webiopi and python, no idea if this is a clocked core or not, if its not can I just connect my sensors to gpio 4 without any hardware/software modification?

Regarding my other question on github nothing is missing from gz_16o8i and I guessed I should strip away some of the existing stuff in gz_16o8i.py, my problem is just a fundamental understanding of what should being sent and how, to the spi bus to simply toggle one output from 0 to 1 like : if z == 1: set output 1 on guzunty to 1 else 0 and the same for an input like if guzunty input 1 == 0: x=0 else 1, this simple example would i think set me on my way, as everything else I can extrapolate from that example, so a small help would be appreciated.

So to sum up, for any noob like me I think the board is a great idea, great price, simple to build, easy to load and test the cores, so very flexible in its possible uses, it just needs an idiots guide to put it to work, for idiots like me hahaha.

Regards Toshi

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Sat Jan 04, 2014 8:49 pm

Answers to your questions built Guzunty as Hybrid
Great, then you have even more options.
I want to use gz_16o8i (initially), to test feasibility of replacing a couple of mcp23017
Yup, Guzunty will work fine for that purpose.
no idea if this is a clocked core or not
It's not a clocked core, so GPIO4 is available for your use. If you look at gz_16o8i.rpt near the end, you will see pin 5 (the CPLD pin assigned to GPIO4) has been assigned as KPR by the Xilinx fitter. KPR is short for 'Keeper'. What this means is that the CPLD output will flip flop between 0 and 1 as it was last driven by an external circuit. Consequently, you should not need to do any reconfiguration of the board. The CPLD pin should not affect the one-wire communication, so you should simply be able to continue to use the sensors connected on the stacking header on your Guzunty.
Regarding my other question on github nothing is missing from gz_16o8i and I guessed I should strip away some of the existing stuff in gz_16o8i.py, my problem is just a fundamental understanding of what should being sent and how, to the spi bus to simply toggle one output from 0 to 1 like : if z == 1: set output 1 on guzunty to 1 else 0 and the same for an input like if guzunty input 1 == 0: x=0 else 1, this simple example would i think set me on my way, as everything else I can extrapolate from that example, so a small help would be appreciated.
This should do the trick (though bear with me, Python is not my usual language and I haven't had a chance to test this):

Code: Select all

if (z==1):
  GZ.set_spi(1)
else:
  GZ.reset_spi(1)
There is no equivalent convenience function for reading; you have to use GZ.spi_read() which returns an integer containing the state of all the input bits. You would then use a mask to get the bit you are interested in. This is perhaps an oversight so I will look at adding a function to read a specific bit to the libraries. I will also add some tested examples of using these calls and let you know when they are available.

Hope this helps :-)
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

Toshibass
Posts: 18
Joined: Fri Jan 03, 2014 3:10 pm

Re: Guzunty Pi. New users start here.

Sat Jan 04, 2014 10:16 pm

SUPERB thank you so much, for sure thats saved me hours no weeks of trail and error, I am already liking this board even more now.

Best Regards Toshi

Toshibass
Posts: 18
Joined: Fri Jan 03, 2014 3:10 pm

Re: Guzunty Pi. New users start here.

Sun Jan 05, 2014 9:20 am

Hi Derek,

Just a quick note found that GZ.set_spi(1) should be GZ.spi_set(1) so this works great :

import curses
import GZ
import time

for x in range(0, 16):
GZ.spi_set(x)
time.sleep(0.1)
GZ.spi_reset(x)

so regarding you comment "adding a function to read a specific bit" being able to easily check the state of a individual output pins like if its currently 0 or 1 as well as checking state of an input pin would be great, I know this may seam a little basic to some, but for nooby me, bit hacks are a bit to advanced at the moment.

Also I have another question in the wiki it states:-
Can I use the Guzunty with 2.5v devices?
Yes. To do this, you must remove the IO voltage jumper on the power header (P3) and provide an external 2.5v power source onto pin 2.

I want to modify the 3v3 supply feeding the Guzunty board, to take the load off of the Pi's 3v3 supply, proposing to do as attachment, is this correct way?

Thanks for you help Toshi
Attachments
GZ 3v3.JPG
GZ 3v3.JPG (22.97 KiB) Viewed 5206 times

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Tue Jan 07, 2014 2:00 pm

Here's another question that might interest other Guzunty users. Thanks Paul.
Does an LCD panel really require hybrid mode? Looking at the wiki it says it is for reset and dc, but the vhd file implies these do pass through the Guzunty? And if they aren't through the Guzunty, could they be? Thanks for any help. Paul
No. It is possible to wire up one of the SPI based LCD modules without building a hybrid mode. The dc and reset signals are indeed routed through the Guzunty as you have noticed. It's always worth looking at the VHDL source and through the fitter report file when learning about a core you're going to use. If you look back though this thread, you will find a few people have successfully directly wired one of these displays. However, there is a caveat. There are insufficient signals to allow touch to work as well.

The LCD daughter card definitely requires hybrid mode to work, but provides touch support as well as spare bonus I/O.
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Tue Apr 29, 2014 5:14 pm

Here is a question that came on the Guzunty wiki, but which is of general interest:

Thanks for asking this, Toshi.
I can switch any of the output pins On or Off using the following :

# Switch output 1 On
GZ.spi_set(1) # 0 to 15
time.sleep(5)
# Switch output 1 Off
GZ spi_reset(1)

or

for x in range(0, 16):
GZ.spi_set(x)
time.sleep(0.1)
GZ.spi_reset(x)

Great so far

What I need to be able to do is read the state of an output pin if its 0 or 1 and same for the 8 input pins

I guess to do this involves GZ.spi_read() and if I say print GZ.spi_read() I get 65535 (but always no matter which pins are set to 0 or 1 which I didn't expect) I tried GZ.spi_read(1) but get a syntax error spi_read() takes no arguments (1 given)

Also I tried the following which I was trying to extrapolate from your python test file:
GZ.spi_set(4)
GZ.spi_set(7)

pins = int(GZ.spi_read())
mask = 0x01
for i in range(16):
if (pins & mask): # < and tried if (pins & mask)==1:
print (pins & mask)
print (i, mask,"1")
else:
print (i, mask, "0 FOUND")
mask = mask << 1

This tests address 1,2,4,8,16,32,64 128 256 512 1024 4096 8192 16384 32768 for 0 or 1 they all return 0 , I tried different values for mask and increasing the for loop to cover more addresses but in reality I have no idea if I am on the right track, I am just probing in the dark.

Thanks for any assistance you can give me

Best regards

Toshi
Well Toshi, you are almost on the right track. We really have two separate things here, reading input pins and reading the state set on an output pin.

First of all, the inputs. You mentioned that you have not yet tried driving the input pins yet. I suggest you give it a try! The code you listed above should work for sensing the state of the input pins. Please let me know if it does not and I'll take a closer look at what you're doing.

So that has dealt with the inputs. Why can't we read the state of the outputs? To answer this you need to understand a little bit about what the hardware is doing...

The vhdl for the core you are using is found here:

https://github.com/Guzunty/Pi/blob/mast ... _16o8i.vhd

The last few lines control what you read from the SPI device:

Code: Select all

  process (sel, bit_cnt) is
  begin
	 if (sel = '0') then
	   miso <= inputs(to_integer(unsigned(bit_cnt)));  // clock the inputs out on miso
	 else 
      miso <= 'Z';  // If not selected, miso should be high impedance to let other devices talk
	 end if;
  end process;
Now, bit_cnt is incremented for each time the SPI bus is clocked, and inputs is the array of input pins. From this, you can see that the only thing written to the SPI bus by this core is the state of the input pins.

In short, there is no way to read the state of the output pins from the SPI bus, not with the design of this core anyway. At first glance, this seems like a disaster, but its really not. It's easy to keep your own record of which pins are high and which pins are low instead. In fact, that is exactly what the gz_library source does to support the spi_set(int pin_number) and spi_reset() functions:

Code: Select all

   spi_cache[byte_cnt] |= (1 << (bit_to_set & 0x7));
    transfer(spi_cache, 0);
(https://github.com/Guzunty/Pi/blob/mast ... c/gz_spi.c line 54/55)

spi_cache is an array that is used to keep a record of what has previously been set so that when we next make a call to spi_set, we don't clear pins we had previously set high!

So, we have two choices to find out what outputs are high and low. We can either keep a record of what we previously set in our own program, or we can modify the library to add functions to read the state of the outputs from the internal library variable, spi_cache.

To do it in your own program, you just need an array of booleans and set and reset them at the same time as you call spi_set() and spi_reset(). I'll leave you to try that for yourself.

While you are trying that out, I will modify the 'C' and python libraries to allow you to read the previously set state of the output bits. Look for an update to gzlib on github over the next few days.
Last edited by guzunty on Wed Apr 30, 2014 10:17 am, edited 1 time in total.
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

Toshibass
Posts: 18
Joined: Fri Jan 03, 2014 3:10 pm

Re: Guzunty Pi. New users start here.

Tue Apr 29, 2014 7:35 pm

All of a sudden it becomes much clearer thanks to your clear response, In reality I had been thinking of a python array to store the values of the outputs, but only as a last resort if I couldn't solve the issue, I say last resort because using a python array has its problems in that if you stop the python script when you restart the variables will be reset to zero no matter what state the actual outputs are on the guzunty so its easy to get out of sinc, of coarse you could reset all the outputs of the guzunty to zero as well, but for my project this is undesirable, I thought of storing the array in a file (easy with say python "pickle ") and retrieving the file/array on start up but that creates the same same problem if you stop both the script and power down the guzunty the outputs will reset to zero on the chip, but when you retrieve the array from the file the output will be out of sinc again.
So the preferred option is to be able to get the state of the outputs and inputs directly from the guzunty itself, so if you get time to modify the 'C' and python libraries to allow reading of the previously set state of the output bits that would be brilliant and I am sure other users would put this enhancement to good use.

Thanks for your all of your help with this, I appreciate it, best regards

Toshi

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Wed Apr 30, 2014 10:14 am

Hi Toshi,

Your last reply contains a previously unstated requirement; that it should be possible to stop and restart the script and have the output state remembered. That functionality is not possible to support in a library because of the way libraries are bound in Linux (and Windows for that matter). When you restart the script, the library will be reinitialised and so would behave as if the outputs are all zero. In other words, on the next call to the spi_set(), all outputs except the specified one would be zeroed.

The library cannot write a file, because it is by definition shared by multiple applications and would not know where or when to write the data.

The best solution is therefore to write the current output settings to disk in the application, i.e. your script.

Here is what I suggest, look for the existence of the file and assume all zero values if it does not exist, and write that state to the file. Update the file each time the outputs are changed. This can all be hidden inside a function that you call rather than calling spi_set/spi_reset directly.

Finally, add a script to delete the file on shutdown. You can find out how to do that here:

http://unix.stackexchange.com/questions ... -in-debain

If the plug ever got pulled on the Pi without an orderly shutdown, you must expect glitches on the outputs, but then the Guzunty would have been depowered as well, so the outputs would have been lost in any case.

Unless you were planning on powering the Guzunty independently of the Pi? (this is possible, but would require some surgery to the board or its connecting cable).

HTH,

Derek
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

Toshibass
Posts: 18
Joined: Fri Jan 03, 2014 3:10 pm

Re: Guzunty Pi. New users start here.

Thu May 01, 2014 6:10 am

Hi Derek

I clearly shot myself in the foot with the previous post, it was not a requirement, just my clumsy way to try and explain why it was preferred to not to use an array internally in my python script, so let me try to explain it a different way hopefully without making matters worse.

Consider my simple stand alone python script

import time
import GZ

time.sleep(5)

a = 0

while 1:
if a==0:
print("Switch LED On")
GZ.spi_set(5)
a = 1
else:
print("Switch LED Off")
GZ.spi_reset(5)
a = 0

time.sleep(5)

If I run this script my LED on pin 5 will turn On in the first loop and turn Off in the second loop and so on, however if I stop the script when the LED is On the LED stays On, If I restart the script, because "a" is reset to 0 the script thinks the LED is Off, but its already On so its out of sync, so the first loop instead of switching the LED Off switches it On again, so no effect.

In this case I don't see "when you restart the script, the library will be reinitialised and so would behave as if the outputs are all zero.

The script I would like to work is this:
#!/usr/bin/env python
import time
import GZ

time.sleep(5)

while 1:
if Gz.spi_get(5)==1: #< enhanced command "Gz.spi_get" or whatever
print("Switch LED On")
GZ.spi_set(5)
else:
print("Switch LED Off")
GZ.spi_reset(5)

time.sleep(5)

In reality I don't want to keep stopping and starting my script but I do want to toggle the output based on its current state, like if in the above script, if the guzunty did get reinitilised for some reason then fine "Gz.spi_get" would see the Output is Off so would switch The LED On in the first loop (great it stays in sync)

I suppose the end result of all this is that "Gz.spi_get" would make programming states of the output pins on the guzunty in python so simple and accurate and I hope I have done enough to convince you to find the time to modify the 'C' and python libraries to allow you to read the previously set state of the output bits.

Best regards

Toshi

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Sat May 03, 2014 4:55 pm

I have added two new functions to the 'C' library API:

int gz_spi_get(int bit_to_read); // Read the state of the specified input bit
int gz_output_get(int bit_to_read); // Read the state of the cached output bit

All previous API is unaffected.

I have added the same functions to the Python library:

GZ.spi_get(bit_to_read)
GZ.output_get(bit_to_read)

I have also extended gz_16o8i.py with demonstration code that illustrates the use of these new bitwise functions

To use these, change directory into your Guzunty source folders and perform the git operation:

Code: Select all

git pull
Then build the C and Python libraries as described in the 'Get your Pi set up' wiki page on the Guzunty repository.

Toshi, hope that helps. :-)
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

guzunty
Posts: 276
Joined: Mon Jan 14, 2013 10:13 am

Re: Guzunty Pi. New users start here.

Mon May 05, 2014 6:11 pm

Hi Toshi,

Were you able to try the upgraded API? Does it meet your needs?

Please let me know so that I can close the GitHub issue.

best,

Derek
Guzunty: A fully programmable peripheral you build yourself! https://github.com/Guzunty/Pi/wiki

Return to “Other projects”