PinHigh/PinLow do not seem to function as would be expected.

[GoogleCodeExporter]

What steps will reproduce the problem?
Using the following python:
from mpsse import *
a = MPSSE()
c = MPSSE()
a.Open(0x403, 0x6011, SPI0, ONE_MHZ, MSB, IFACE_A)
c.Open(0x403, 0x6011, GPIO, ONE_MHZ, MSB, IFACE_C)

c.Stop()
c.PinHigh(7)

What is the expected output? 
On my board, the GPIO of port C (pin 7 in this case) is hooked up to a chip 
select.  So I need to be able
to toggle this to access the SPI on port A (which will eventually be JTAG, but 
it starts of as SPI).  There is
an LED attached which goes on and off when you change the pin high and low.

What do you see instead? Nothing happens.

What version of the product are you using? Latest SVN (doesn't have the patch 
to clear errors when
you start.)

what operating system? Ubuntu 12.10 LTS

Please provide any additional information below.

I could be misusing the GPIO functionality, but it didn't seem to work.  I have 
a patch, which I attached, which adds "BITBANG".  I added this because I was 
afraid I was missing something when I looked at what GPIO was doing and did not 
want to change GPIO if I misunderstood it.  But it appears that if you use 
GPIO, it doesn't really do anything.  I traced why at one point, created the 
patch, and promptly forgot why.  At any rate, the BITBANG functionality seems 
to do what I needed to do (or at least make PinHigh/PinLow function as I 
expected they would).

Original issue reported on code.google.com by robokni...@gmail.com on 12 Jul 2012 at 2:07

Attachments:

• bitbang.patch

[GoogleCodeExporter]

One more thing.  The patch does have one issue:  When you first open a port in 
BITBANG mode, it turns all the pins on.  Then when you first set any pin, it 
changes all pins to low (except the one you changed).  From there on out it 
remembers the state, but at this point, I don't have a good way to set the 
state at start-up so this doesn't happen (well, I suppose I should correctly 
set the state of the other pins to HIGH instead of LOW, then you wouldn't 
really notice it I guess, except that when you turn on BITBANG, it will turn on 
all the pins)... There is probably some other way to do this, like maybe 
getting the state at startup or something.

Original comment by robokni...@gmail.com on 12 Jul 2012 at 2:21

[GoogleCodeExporter]

Submitting another patch because you were a few revisions ahead of me... you 
were at '104' and I was still on '97' ... Need to move my repository to another 
machine so it is easier to pull code.  At any rate, this should match rev 104.

Original comment by robokni...@gmail.com on 12 Jul 2012 at 7:31

Attachments:

• new_bitbang.patch

[GoogleCodeExporter]

So it is probably a good idea to include a general bitbang mode into libmpsse 
anyway, but the GPIO mode should work.

Looking at your patch, I think the issue might be that you are supplying the 
wrong pin number for the pin you want to turn on. For example, I have an 
FT232H, which has GPIOL0 mapped to the ADBUS4 pin. To turn this GPIO pin on in 
GPIO mode, you should do:

    gpio.PinHigh(0)

Whereas in your bitbang code, you would do:

    bitbang.PinHigh(4)

In other words, you need to provide the GPIO index number, not the physical pin 
number. This is my fault, as this is not well documented, if at all. The pin 
mappings for each of the GPIO pins are as follows:

    GPIOL0  -  0
    GPIOL1  -  1
    GPIOL2  -  2
    GPIOL3  -  3
    GPIOH0  -  4
    GPIOH1  -  5
    GPIOH2  -  6
    GPIOH3  -  7
    GPIOH4  -  8
    GPIOH5  -  9
    GPIOH6  -  10
    GPIOH7  -  11

So to turn on GPIOL0 you would do PinHigh(0), to turn on GPIOH7, you would do 
PinHigh(11), etc.

Original comment by heffne...@gmail.com on 13 Jul 2012 at 8:39

• Changed state: Started

[GoogleCodeExporter]

Just checked in new code with support for BITBANG mode, which allows you to 
both set and read pins. In BITBANG mode, you specify the absolute pin number 
just as your patch did.

I also added #defines for ease of use when in GPIO mode, so you don't have to 
remember the above pin mappings. For example, to set GPIOH4 high:

    gpio.PinHigh(GPIOH4)

FYI, you don't have to be in GPIO mode to set the GPIO pins high/low, you can 
call PinHigh/PinLow in SPI/I2C modes too and they will act the same as in GPIO 
mode.

Original comment by heffne...@gmail.com on 13 Jul 2012 at 9:54

[GoogleCodeExporter]

I did notice something.  The chip I'm using is an FT4232H (the old one was the 
2232D, no RTCK which was a problem).  This chip has 4 interfaces.  In MPSSE 
mode, two of them have GPIOL0-3 (A,B).  The other two (C,D) are either RS232 or 
bit bang.  They don't really have GPIO pins defined like the other two 
interfaces.  Maybe that is where I'm running into problems.  Because I think 
the chip you might be using is the 2232H?  This device has GPIOL0-3 on both 
A&B, and GPIOH0-7 on both A&B.  That would give you your 0-11, but it would 
also *NOT* work with C&D on the 4232H because it doesn't have a mode like this. 
 That, I think, is where my issue probably lies.  I do have the GPIO pins 
hooked up, so maybe I can try to set one low and one high and put an LED in 
between to see if its working (I don't have those pins hooked to an LED or 
anything, but they are flying leads so I can put something there).  Or maybe I 
can just ground the low side of the LED and try turning it on with one.

Original comment by robokni...@gmail.com on 13 Jul 2012 at 2:40

[GoogleCodeExporter]

PS: I did try all values (0-11) on IFACE_C before, with no luck.  Which, now 
that I'm paying more attention to my data sheet, might make sense.

Original comment by robokni...@gmail.com on 13 Jul 2012 at 2:43

[GoogleCodeExporter]

I'll have to take a closer look at the GPIO commands and see how the 4232H 
should respond.  Its GPIO pins aren't even working correctly.  At least it 
doesn't seem they are.  Let me download your new stuff.  The other thing I was 
thinking might be a problem is setting the direction.  I didn't see a way to 
set tris or trish, but maybe that is supposed to be set on read or write?

Btw, thanks for taking the time to look at the patches I submitted.  It 
certainly is a lot nicer to know the person who wrote the code in the first 
place is making sure the patches work and really make sense instead of 
wondering if I've missed something.

Original comment by robokni...@gmail.com on 13 Jul 2012 at 3:01

[GoogleCodeExporter]

Will have to try later.  I can't seem to pull the code.  Don't know exactly 
why.  Maybe something wrong with the google code servers.

Original comment by robokni...@gmail.com on 13 Jul 2012 at 3:08

[GoogleCodeExporter]

Ah yes, that would explain it. If interface C doesn't have any GPIO pins, then 
you will have to put that interface into bitbang mode in order to manually 
toggle the pins on and off. Or, since you are using interface A for your SPI 
bus anyway, you could use the GPIO pins on interface A to control your 
additional chip select lines.

P.S. - I just tried and was able to successfully check out the trunk, so 
hopefully it was just a momentary glitch.

Original comment by heffne...@gmail.com on 13 Jul 2012 at 3:20

[GoogleCodeExporter]

I still can't seem to check it out.  I suspect some dumbass is filtering my 
traffic for some reason and now I can't check things out, where I used to be 
able to... Really awesome when you need to get source code for things.  I might 
try one of your other projects just to make sure, but it seems I'm relegated to 
downloading the code by hand (i.e. web interface into the svn repository and 
"save as")... I can't seem to make curl do what I want it to... I'll have to 
work on that.

Original comment by robokni...@gmail.com on 13 Jul 2012 at 3:51

[GoogleCodeExporter]

Hmmm, have to retract my "dumbass" statement.  I just checked out the latest 
rev of binwalk (which I'd like to use at some point anyway).  So it is probably 
something with googlecode and this project.  I wish you used git instead of svn 
(I think their git repositories have less connections issues than svn... at 
least from a quick google search... plus I use git pretty regularly), but I'm 
not a zealot, so I understand if you don't.  At any rate, you might ping 
googlecode and ask them if their is a repository problem with libmpsse.

Original comment by robokni...@gmail.com on 13 Jul 2012 at 3:56

[GoogleCodeExporter]

Okay, I tried to "checkout"... checkout hangs.  I go into the resulting 
directory, do "svn cleanup" and "svn update ." ... now it checks out.  ???

Original comment by robokni...@gmail.com on 13 Jul 2012 at 4:02

[GoogleCodeExporter]

I did try an update about 30 minutes ago and it hung for me as well, but went 
through after maybe 20 seconds. Seems to be working fine now, maybe a short 
outage on Google's side.

Original comment by heffne...@gmail.com on 13 Jul 2012 at 4:11

[GoogleCodeExporter]

Tried out your new stuff.  Works beautifully, once I got my pin positions 
right... (I had my pins labelled wrong on my PCB layout... sheesh).  At any 
rate, GPIOL0 is RTCK on port A, the others, L1-L3 are "available" on my 
board... so I can now use them for things like NTRST, or emu0 and emu1, or even 
events if I want to read the pin state.  It seems like things are working well 
now.  Full duplex SPI, full bitbang, the works.  Basically we have built a dual 
JTAG board out of the 4232H (has 2 serial ports also).  It is capable of 
variable voltage in software (in case you can't get a reference voltage... 
which happens many times).  Now I've just got to go pound on openocd for a 
while till I can get all the dual jtag stuff working (I'm not sure they really 
support the dual JTAG of the 4232H.  Plus I would like to add some voltage 
select stuff so that I don't always have to run an external script.  Not that 
that is a bad thing.  Basically integrate libmpsse into openocd for stuff like 
this).

Original comment by robokni...@gmail.com on 13 Jul 2012 at 4:39

[GoogleCodeExporter]

Awesome! Sounds like a cool project, let me know how it goes. Also thanks for 
all the patches and testing! I'll be rolling out a new libmpsse release with 
all the new stuff soon.

Original comment by heffne...@gmail.com on 13 Jul 2012 at 5:46

• Changed state: Fixed

[GoogleCodeExporter]

Yeah, should be really neat.  We should also be able to use the PinRead stuff. 
Nice addition.

Thanks a lot for the additions.  libmpsse is a really nice piece of work.  
We'll see if ftdi doesn't point people to it.

Original comment by robokni...@gmail.com on 14 Jul 2012 at 2:46

[GoogleCodeExporter]

Thanks, glad you've found it useful. :)

I think the libftdi links page does list libmpsse along with a few other 
libftdi-based projects.

Original comment by heffne...@gmail.com on 14 Jul 2012 at 4:36