Post by thread:[EE] Another source of USB-UART chips. SPI

Dave VanHorn wrote: > > At 11:57 AM 11/10/2004, Ian Smith-Heisters wrote: > > >Shawn Tan Ser Ngiap wrote: > > > >>It has the same performance as the old 232BM FTDI chips.. Hey, I'm > >>interested to find out if anyone knows if we can use the newer FT2232C to > >>effectively double our bandwidth?? > >> > >If a chip like this converts from the PIC UART to USB, how can you > >increase the bandwidth? It would seem to me that it would still be limited > >by the speed of the UART. Would you just output on more pins than the > >PIC's default TX/RX? > > Nothing's going to speed up the pic uart. Well, with 16Mhz and set SPBRG to 0 you get 1000 kbaud. Pick a nice crystal rate (19.6608Mhz), and you can get nice standard baud rates with bigger SPBRG values. > All it can affect is speed on the USB bus, or the baud rates that the USB > chip is capable of. > > What would be REALLY nice, is a clocked serial or SPI version, so you don't > have to wait around for the uart to beedle the data out. You mean like this? http://www.ftdichip.com/FTProduct.htm "The FT2232C is the 3rd generation of FTDI’s popular USB UART / FIFO I.C. family. This device features two Multi-Purpose UART / FIFO controllers which can be configured individually in several different modes. As well as a UART interface, FIFO interface and Bit-Bang IO modes of the 2nd generation FT232BM and FT245BM devices, the FT2232C offers a variety of additional new modes of operation, including a Multi-Protocol Synchronous Serial Engine interface which is designed specifically for synchronous serial protocols such as JTAG and SPI ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ bus. " > Uarts are not well suited for on-board inter-processor communication. They cerainly are not, but they can be pushed. Robert ___________________________________________

On Wed, 10 Nov 2004 18:30:08 -0700, you wrote: {Quote hidden}>Dave VanHorn wrote: >> >> At 11:57 AM 11/10/2004, Ian Smith-Heisters wrote: >> >> >Shawn Tan Ser Ngiap wrote: >> > >> >>It has the same performance as the old 232BM FTDI chips.. Hey, I'm >> >>interested to find out if anyone knows if we can use the newer FT2232C to >> >>effectively double our bandwidth?? >> >> >> >If a chip like this converts from the PIC UART to USB, how can you >> >increase the bandwidth? It would seem to me that it would still be limited >> >by the speed of the UART. Would you just output on more pins than the >> >PIC's default TX/RX? >> >> Nothing's going to speed up the pic uart. > >Well, with 16Mhz and set SPBRG to 0 you get 1000 kbaud. >Pick a nice crystal rate (19.6608Mhz), and you can get >nice standard baud rates with bigger SPBRG values. If you mainly need speed _out_ of the PIC you can do faster than using the UART You can actually get a baudrate equal to the instruction rate if you have a whole port to spare : ; output on PB0 bcf portb,0 ; start bit movwf portb ; bit 0 rrf portb ; bit 1 rrf portb rrf portb rrf portb rrf portb rrf portb rrf portb ; bit 7 bsf portb,0 ; stopbit If the SPI is set up to auto-generate the clock on each read (can't remember if the PIC will do this), and you only need handshaking on blocks, you could get a download rate approaching 450 kbytes/sec at 20MHz The 'wasted' port pins could often be shared when not transmitting, e.g. as inputs or for LCD module data/address lines. If you can't spare a whole port, you could get half instruction rate baudrate, e.g. use port E on a F874, using RE0 as output and RE1/2 as inputs : rrf datareg rlf porte etc.... You could even get some input functionality at this rate , e.g. using input capture and carefully chosen data values (single consecutive '0' bits), which would be more than adequate for simple 'dump a big flash chip as fast as possible' type of applications. Another thing you could do is use an external small PLD to convert the SPI stream into async in hardware - if you're really clever you could arrange the SPI byte rate to be 10x the bit rate so all the extarnal hardware has to so is insert start/stopbits - a 16V8 ought to be able to do this. ..or just have the PLD generate the SPI clock for transfers, again this would not need a huge amount of logic to implement. ____________________________________________

On Thu, 11 Nov 2004 22:12:33 -0500, you wrote: > >> >>Well, with 16Mhz and set SPBRG to 0 you get 1000 kbaud. >>Pick a nice crystal rate (19.6608Mhz), and you can get >>nice standard baud rates with bigger SPBRG values. > >With problems. >Can you really run the uart with a divisor of zero? >Can you handle EVERY byte as it comes in at that rate? >Hw HS can be implemented, but that's more and more code. For large transfers - e.g. read/writing a flash chip, you can usually do it in blocks with handshaking only between blocks - this greatly simplifies the software and has little impact on throughput. You could also use a half-duplex protocol to avoid the need for explicit handshaking altogether - ISTR the FDTI chip has a sizeable buffer so half-duplex would not impact overall speed too much. ____________________________________________