GPIF master: different sources for DR_ADDR problem

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

 Hi,

   

I am trying to use FX3 in master mode to send/receive data to simple external bus. Bus has 8bit data (bidirectional), 7bit address (write-only from FX side) and WR/RD lines for simple toggle (also write-only from FX). FX will have 1 bulk endpoint for data writes, 1 bulk endpoint for data reads and 1 control endpoint for commands.

   

So I have created 2 START states, one for reading and another for writing (I plan to switch between them depending on command received). For writing I receive 2 bytes from PC via bulk endpoint in format <addr> <data> then put it to external bus using DR_ADDR (source: from thread socket), DR_DATA then toggle WR. For reading, after I receive command with address and number of bytes to read via control endpoint, I plan to manually program DATA_COUNT, then put desired address to bus using DR_ADDR (source: from register) then toggle RD then put received data to bulk endpoint via IN_DATA.

   

The problem is that when in read state I set DR_ADDR action to use register as a source, source in DR_ADDR action used in write state automatically changed too, but I need to use ThreadSocket as a source there. How can i solve this? Maybe I am on wrong way and different approach should be used? Thank you in advance.

0 Likes
1 Reply
Anonymous
Not applicable

 Hi,

   

    

   

    

          

   

Yes. You need to have only one source for address (DR_ADDR action) across all the states in a state machine.    

   

We have only two ways to avoid this problem:    

   

1. We need to use same address source (Regitser for both or socket)    

   

2. If you can not use a common source then you need to develop your two state machines as two separate GPIF II projects (one for Read and other for Write) and you need to re-load the GPIF II configuration when you are switching between Read and Write.    

   

    

          

   

Thanks,    

   

Sai Krishna.    

0 Likes