Jump to content

Search the Community

Showing results for tags 'FT232RL'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • News
    • Announcements
    • Suggestions
    • New users say Hi!
  • Spotlight!
    • Sponsor Spotlight
    • Sponsor Giveaways
  • Energia
    • Energia - MSP
    • Energia - TivaC/CC3XXX
    • Energia - C2000
    • Energia Libraries
  • MSP Technical Forums
    • General
    • Compilers and IDEs
    • Development Kits
    • Programmers and Debuggers
    • Code vault
    • Projects
    • Booster Packs
    • Energia
  • Tiva-C, Hercules, CCXXXX ARM Technical Forums
    • General
    • SensorTag
    • Tiva-C, Hercules, CC3XXX Launchpad Booster Packs
    • Code Vault
    • Projects
    • Compilers and IDEs
    • Development Kits and Custom Boards
  • Beagle ARM Cortex A8 Technical Forums
    • General
    • Code Snippets and Scripts
    • Cases, Capes and Plugin Boards
    • Projects
  • General Electronics Forum
    • General Electronics
    • Other Microcontrollers
  • Connect
    • Embedded Systems/Test Equipment Deals
    • Buy, Trade and Sell
    • The 43oh Store
    • Community Projects
    • Fireside Chat
  • C2000 Technical Forums
    • General
    • Development Kits
    • Code Vault
    • Projects
    • BoosterPacks


There are no results to display.

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL





Found 2 results

  1. In this tutorial we will interface a 7 Segment LED display serially using FT232 USB to serial converter chip and D2XX library from FTDI. D2XX is a library released by FTDI international,makers of FT232 and other FT series chip to access the advanced functions of the FT232 chip. The control program is written in standard C using D2XX library and is compiled using opensource GCC compiler on a windows 7 machine. Please note that this tutorial is specific to FT232 chip and will not work with USB to serial converter chips manufactured by other companies( like TUSB3410 from TI). Full Tutorial is available here
  2. Hello, Lastly I have whipped up a state machine based protocol for sending small frames using 9-bit address mode. Ft232rl, wrapped up in the MMusb232rl board, doesn't support this mode directly, so I am leaning on changing the parity bit to mark or space to simulate the address bit on the PC side. Everything works as a charm when I single step the program on the PC. Just on a sidenote, this program is coded in Qt using QtSerialPort. However, when I let the program run as it normally would in a production environment, the uC only receives several bytes out of the whole packet. I have observed the following happen. After reset, the uC receives 4 bytes out of 7. Then, I send the packet again, the uC gets 2/7. After that only 1/7th of every packet makes it to the uC, so only an address byte is being received and the state machine waits in the next state, which is 'wait for the number of parameters'. I think the most simple causes like incorrect wiring or voltage level mismatch can be ruled out right away, because single-stepping the PC program makes all the bytes come through successfully. That might suggest a baudrate mismatch, but I have checked hundreds of times and 9600 is used on both ends. That leaves, among others, a broken driver in the field. Right now I am using Linux kernel 3.9.9. I have also tried replacing literally every element of the system, including the 232 chip, the launchpad and moving the 232 chip over a breadboard to no avail. Unfortunately, I don't have access to neither a logic analyzer nor an oscilloscope. Has any of you encountered a similar problem? Below are the most important code snippets: static inline void HW_UARTinit(void) { //---- Select and initialize pin to control RS485 transceiver direction ---------------- P1DIR |= BIT0; P1OUT &= ~BIT0; // Set RS485 transceiver to receive. //assign P1.1 and P1.2 to be used as Rx and Tx P1SEL |= BIT1 + BIT2; P1SEL2 |= BIT1 + BIT2; //no parity, //LSB first, //8-bit data, //one stop bit, //address-bit multiprocessor mode, //async mode UCA0CTL0 |= UCMODE_2; //select clock source - SMCLK, //erroneous characters rejected and UCAxRXIFG is not set, UCA0CTL1 |= UCSSEL_2; //example prescaler settings: //minimal error rate without external oscillator //BRCLK == SMCLK == 1MHz //baud == 9600 //UCBRx == 104 //UCBRSx == 1 //UCBRFx == 0 UCA0BR0 = 104; UCA0BR1 = 0; UCA0MCTL = UCBRS_1; //release USCI for operation UCA0CTL1 &= ~UCSWRST; //enable Rx interrupt IE2 |= UCA0RXIE; } #pragma vector=USCIAB0RX_VECTOR __interrupt void USCIAB0RX_ISR(void){ //ISR(USART_RXC_vect) stateTransition(); } void stateTransition(void){ uint8_t receivedByte = 0; if (HW_UARTaddress()){ vars.state = AWAIT_REQUEST_FETCH_ADDRESS; } // When TXC interrupt it may cause some problems and delays if(vars.state < VALIDITY_CHECK){ receivedByte = HW_UARTget(); lumpBytesRcvd++; } ... } inline static void _INIT(void) { ... //DCO 1MHz if (CALDCO_1MHZ == 0xFF || CALBC1_1MHZ == 0xFF) { //calibration data was erased! we can't proceed while (true); } else { BCSCTL1 = CALBC1_1MHZ; DCOCTL = CALDCO_1MHZ; } //MCLK - default DCO/1 //SMCLK - default DCO/1 } HW_UARTaddress() returns true if a last received byte has the address bit set, otherwise returns false. My last idea is that the internal RC oscillator is not stable enough to allow error-free reception of a few subsequent bytes, but that's not so likely. Thanks to everyone who has taken time read this post. Any help will be much appreciated.
  • Create New...