3 Replies Latest reply on Aug 9, 2012 2:29 PM by nick.vergunst

    Is this possible, and what is the best way to go about it? USB <-> I2C

    nick.vergunst

      Hello,

         

      Upfront, I have never worked with the Cypress parts (or ARM with an RTOS) but have lots of "regular" FPGA and MCU (PICs) experience. So I should be able to follow your advice, but currently I just don't know where to start or look to begin with to get me going. Or even if this is possible.

         

      My current hardware is the FX3 USB Developement Kit. I don't specifically need USB 3.0, but I do need high-speed 2.0 instead of the fullspeed 2.0 my project currently has.

         

      The first part of my need is a USB to I2C translator. I need to send a bulk transfer to the device, decode these bytes, and wiggle the I2C line. Then when things are received by the I2C line, re-encode, and send back through another bulk transfer endpoint. The second need is to monitor all edges of the I2C and decode all I2C traffic independently. Currently I have all this working and implemented in a standard PIC32 overclocked (120MHz/120MIPS). So I am hoping with the regular 200Mhz/200MIPS I can get something similar working even if the speed improvement is minimal. I am essentially maxed out with the PIC, hence the move.

         

      So architecturally, does this even work? Can I use the built in MCU to write my firmware? I would suspect so. How much slower is slower when the MCU interprets every USB data transfer? Using the standard stream demo I can get 8MB per second. Is the interrupt overhead large? On the PIC it is 12, so interrupting on every rising and falling edge of an IO pin was expensive, but doable. I am hoping to cut that down, but am unfamiliar with the interrupt scheme used, or if that is even required. If I can poll the signal fast enough, that should be OK (400KHz maximum).

         

      Or should I just be using the part as a passthrough and routing the packets to some large parallel bus and then another FPGA later in the stream? If possible, keeping it on one chip would be nice especially given the cost.