Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

writing to GPIO pins #82

Closed
rdpoor opened this issue Jan 17, 2018 · 4 comments
Closed

writing to GPIO pins #82

rdpoor opened this issue Jan 17, 2018 · 4 comments

Comments

@rdpoor
Copy link

rdpoor commented Jan 17, 2018

I'm able to get my FT232RQ into bitbang mode and read pins using ftdi.read_pins(), but I can't find documentation (nor even source code) that shows how to write to the pins. I thought maybe I should be using ftdi.write_data(), but that doesn't appear to be having the desired effect:

Here's what I tried and what I observed:

>>> from pyftdi.ftdi import Ftdi
>>> ftdi = Ftdi()
>>> ftdi.open_bitbang_from_url('ftdi:///1', direction=0xff)    # declare GPIO pins as outputs
>>> ftdi.read_pins()
2
>>> ftdi.write_data([0x0])
> (invalid output byte sequence)
1
>>> ftdi.read_pins()
255

Since read_pins() now returns 255, it appears that write_data([0x0]) had some effect (despite the error message), but it did not produce visible effects in my FT232RQ: there are LEDs on two of the GPIO pins and they did not light up as I would expect them to.

The fundamental question remains: how do I write to the GPIO port in bitbang mode?

update

I should make it clear that I'm trying to access the 4-bit CBUS rather than the 8-bit I/O bus.

@rdpoor
Copy link
Author

rdpoor commented Jan 17, 2018

To make it clear, here's a minimal working program written in C using the D2xx library calls. I'd like to replicate this functionality using pyftdi:

/**
 * Test CBUS bitbang interface on FT232 chip.
 *
 * Our goal is to wiggle CBUS bit 3, which in the FTDI USB-RS485 cable
 * controls the 5V drive circuitry on the output wires.
 *
 *   gcc -o bitbang bitbang.c -L. -lftd2xx -Wl,-rpath /usr/local/lib
 * cc bitbang.c -o bitbang -Wall -Wextra -lftd2xx -lpthread -lobjc -framework IOKit -framework CoreFoundation -Wl,-rpath /usr/local/lib -L/usr/local/lib
 */

#include "ftd2xx.h"
#include <WinTypes.h>
#include <stdio.h>
#include <unistd.h>

const UCHAR Drive03Hi=0x88;     /* CBUS03 configured as output, drive hi */
const UCHAR Drive03Lo=0x80;     /* CBUS03 configured as output, drive lo */

int main() {
  FT_HANDLE ftHandle;
  FT_STATUS ftStatus = FT_Open(0, &ftHandle);

  if(ftStatus != FT_OK) {
    fprintf(stderr, "FT_Open failed => %d\n", ftStatus);
    return 1;
  }
  // Repeatedly drive CBUS 03 high and then low
  while(ftStatus == FT_OK) {
    ftStatus = FT_SetBitMode(ftHandle, Drive03Hi, FT_BITMODE_CBUS_BITBANG);
    sleep(3);
    ftStatus = FT_SetBitMode(ftHandle, Drive03Lo, FT_BITMODE_CBUS_BITBANG);
    sleep(3);
  } 
  FT_Close(ftHandle);
}

@rdpoor
Copy link
Author

rdpoor commented Jan 17, 2018

Solved. But some documentation might help. Bitbang for CBUS is a bit strange, since the set_bitmode() mask argument defines the data direction and state of the bits -- there is no separate write function.

Working code example follows:

from pyftdi.ftdi import Ftdi
import time

ftdi = Ftdi()
ftdi.open_from_url('ftdi:///1')
while(True):
    ftdi.set_bitmode(0x88, Ftdi.BITMODE_CBUS)
    time.sleep(3)
    ftdi.set_bitmode(0x80, Ftdi.BITMODE_CBUS)
    time.sleep(3)
# never actually gets here...
ftdi.close()

@rdpoor rdpoor closed this as completed Jan 17, 2018
@Zibri
Copy link

Zibri commented Mar 14, 2022

@rdpoor I get: AttributeError: type object 'Ftdi' has no attribute 'BITMODE_CBUS' :(

@eblot
Copy link
Owner

eblot commented Mar 14, 2022

Please do not comment on tickets that are 4 years old, the code has evolved quite a bit since.

If there is an issue that is related to an existing ticket, open a new one and add a reference to it. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants