fx2lib-devel — Mailing list for fx2lib development

Re: [Fx2lib-devel] First packets from FIFO repeating

[Dennis M. <de...@ub...>]

Eric Winsor wrote:
> What am I missing that is allowing the first use of the buffers to be 
> recommitted?
>   
You didn't include your entire TD_Poll function, so I'm wondering are 
you using EP2468STAT to check the buffer status before doing any writing?

I can't think of anything else off the top of my head.  Feel free to 
post more code.

As a rule of thumb, I usually check the buffer status in poll, then if a 
buffer is available, I write the entire buffer contents and commit the 
packet right then.

-Dennis

[Fx2lib-devel] First packets from FIFO repeating

[Eric W. <er...@wi...>]

Hi,

I have EP2IN set up as 512 bulk double buffered.  I am filling the 
EP2FIFOBUF manually and committing the packets with EP2BCH = 0x02; 
EP2BCL = 0x00;  I end up getting the first 0x0400 packets repeated like so:

Bulk IN Transfer
Bulk IN success.
Buffer Contents
0000  66 99 EE 33 66 99 00 00 10 10 00 00 10 10 00 00 // notice my start 
of data mark.  The code that writes this only happens once.
0010  10 10 00 00 10 10 00 00 10 10 00 00 10 10 00 00
0020  10 10 00 00 10 10 00 00 10 10 00 00 10 10 00 00
...
03E0  10 10 00 00 10 10 00 00 10 10 00 00 10 10 00 00
03F0  10 10 00 00 10 10 00 00 10 10 00 00 10 10 00 00
0400  66 99 EE 33 66 99 00 00 10 10 00 00 10 10 00 00 // Yet it is 
repeating.  I'm getting the two FIFOs of EP2IN resent.
0410  10 10 00 00 10 10 00 00 10 10 00 00 10 10 00 00
0420  10 10 00 00 10 10 00 00 10 10 00 00 10 10 00 00
...
07E0  10 10 00 00 10 10 00 00 10 10 00 00 10 10 00 00
07F0  10 10 00 00 10 10 00 00 10 10 00 00 10 10 00 00
0800  10 10 00 00 10 10 00 00 10 10 00 00 10 10 00 00 // Then all is 
fine there after.  No more resends
0810  10 10 00 00 10 10 00 00 10 10 00 00 10 10 00 00
0820  10 10 00 00 10 10 00 00 10 10 00 00 10 10 00 00

Note that I should get 0000 - 01FF as EP2FIFO buffer 0, 0200 - 003FF as 
EP2FIFO buffer 1, then back to buffer 0 for 0400 - 05FF and buffer 1 for 
0600 - 07FF, etc.  I should not see packets 0 and 1 repeated in packets 
2, and 3 of the sequence.  Also, notice that I am no longer repeating 
from packet 4 on.  I have tested this about with various bit patterns 
and I am repeating (recommitting) the first two packets.

I'm set up this way:

TD_Init()

    EP2CFG = 0xE2;                // EP2IN, bulk, size 512, 2x buffered 
b'1110 0010
    SYNCDELAY;
    EP2FIFOCFG = 0x04;            // manual mode, enable PKTEND zero 
length send, byte ops (b'0000 0100)
    SYNCDELAY;
    FIFORESET = 0x80;            // set NAKALL bit to NAK all transfers 
from host
    SYNCDELAY;
    FIFORESET = 0x02;            // reset EP2 FIFO
    SYNCDELAY;
    FIFORESET = 0x00;            // clear NAKALL bit to resume normal 
operation
    SYNCDELAY;

TD_Poll()
// My code to load EP2FIFOBUF[].  EP2FIFOBUF[Ai++] = AiCount; of 
AiCount/3 works great as a bit pattern to make the repeating visible.  
Where AiCount is incremented on each call of TD_Poll()

// Then I arm the packet for sending by the SIE like so:

        if(Ai == 512)                                    // When Ai = 
512 we have filled one of the EP 512 byte buffers
        {
            Ai = 0;                                            // Reset 
the counter so we can fill the next buffer
            SYNCDELAY;                                        // see TRM 
section 15.15, pg 315.  We are writing/reading a register within 
0xE600-0xE6FF                   
            EP2BCH = 0x02;                                    // Prepare 
to ARM the EP for an IN transaction (High byte must be first)
            SYNCDELAY;                                        // see TRM 
section 15.15, pg 315.  We are writing/reading a register within 
0xE600-0xE6FF                   
            EP2BCL = 0x00;                                    // Now arm 
the EP for transfer by loading the low byte of the byte count (512 bytes)
        }

What am I missing that is allowing the first use of the buffers to be 
recommitted?

Eric Winsor

[Fx2lib-devel] Optimizing throughput.

[Dennis M. <de...@ub...>]

Lately, I've been working on getting my firmware to transfer data a lot 
faster.  I've found the FX2 is just fast enough at 48 Mhz to commit data 
to the USB host at about 43-44 MBps IF (IF is big here), you don't do 
any extra processing until after you've committed a packet to the host.  
I originally did some calculations about how many bytes I needed to 
transfer, and then committed data.  Doing the math first can slow down 
the transfer speed as much as 50%.  Instead, you need to commit a packet 
and then do whatever other processing is required.  Hopefully, the USB 
transfer will be taking place in the time that you're doing the 
processing and you can finish and commit another packet without causing 
the host to pause.

Anyhow, I wrote up a blog post about all this and posted an SDCC/fx2lib 
port of the Cypress CyStream Application on my blog:
http://allmybrain.com/2009/04/14/fx2-cystream-throughput-test-with-sdcc-and-fx2lib/

Enjoy!

My next challenge is to get the GPIF to commit packets with AUTOIN=1 
with large transfer counts.  I can use the above method to transfer 
about 33MBps GPIF but I think I can boost that up to the Max of 43-44 if 
I get AUTOIN working right.  Any of you done this yet?  How about with 
fx2lib?

-Dennis

[Fx2lib-devel] Firmware Frameworks and IIC generation

[Dennis M. <de...@ub...>]

The examples in the fx2lib directory are fine and dandy for learning and 
getting started, but there is still quite a lot of code to get together 
when writing a real firmware.  I decided to go the same route the 
Cypress did with their Keil Uv2 frameworks and provide a framework 
example that one can easily extend to build their own firmware.

Today I committed a new directory: fx2lib/fw.  Therein, you'll find 
fw.c, which shouldn't need modification and device.c, which you add your 
own code to.  dscr.a51, which all you may or may not need to customize 
to get your own USB descriptors.

Features: 
 Sleep, Resume
 USB commands (config descritors, get/set feature etc)
 Easily add your own vendor commands.
 
I also added a python script for generating iic files for loading on 
eeprom images.  I originally borrowed the script from gnuradio but then 
enhanced it to be generic for any ihx file and also to compress the iic 
output the same way the Cypress utility does it.  (This makes a big 
difference if you want to fit your image on a smaller prom!).

Anyhow, enjoy.  I committed a number of other enhancements and minor 
changes in the last few days too.  You can look at the changelog on github:
http://github.com/mulicheng/fx2lib/commits/master

You can

Re: [Fx2lib-devel] Generating a clock with the GPIF

[Eric W. <er...@wi...>]

Yes I think that the GPIF could generate a high frequency clock.  You 
could even use the RDY0/1 pins to make is programmable, say 4 different 
frequencies.  This would however be limited to less than the FX2 CPU 
clock.  The single frequency clock and adjusting the blanking time seems 
like the better solution to me.

Eric Winsor

John Smithee wrote:
> To support different frame rates, I thought I would need a variable 
> clock. But probably adding blanking times to the lines will give me 
> enough flexibility to the frame rate so I can go with a single 
> oscillator.
>
> But I am curious: Wouldn't it be possible to create a waveform that 
> generates a high frequency clock?
>
>
> On Sun, Mar 22, 2009 at 6:20 PM, Eric Winsor <er...@wi... 
> <mailto:er...@wi...>> wrote:
>
>     There is no good way to make a programmable high frequency clock
>     on the
>     FX2.  You can make a low frequency clock using an internal timer
>     driving
>     a GPIO pin.  You will be limited to a resolution of 4 or 12 FX2 CPU
>     clock cycle periods.  Any thing high frequency will have the CPU
>     always
>     servicing the timer interrupt.  I would not do this for any thing
>     beyond
>     audio frequencies.  Why not just use a small clock oscillator.
>      The size
>     would likely be a fraction of the imager size.
>
>     Eric Winsor
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> ------------------------------------------------------------------------
>
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>   

Re: [Fx2lib-devel] Generating a clock with the GPIF

[John S. <joh...@go...>]

To support different frame rates, I thought I would need a variable clock.
But probably adding blanking times to the lines will give me enough
flexibility to the frame rate so I can go with a single oscillator.

But I am curious: Wouldn't it be possible to create a waveform that
generates a high frequency clock?


On Sun, Mar 22, 2009 at 6:20 PM, Eric Winsor <er...@wi...> wrote:

> There is no good way to make a programmable high frequency clock on the
> FX2.  You can make a low frequency clock using an internal timer driving
> a GPIO pin.  You will be limited to a resolution of 4 or 12 FX2 CPU
> clock cycle periods.  Any thing high frequency will have the CPU always
> servicing the timer interrupt.  I would not do this for any thing beyond
> audio frequencies.  Why not just use a small clock oscillator.  The size
> would likely be a fraction of the imager size.
>
> Eric Winsor
>
>
>

Re: [Fx2lib-devel] Generating a clock with the GPIF

[Eric W. <er...@wi...>]

There is no good way to make a programmable high frequency clock on the 
FX2.  You can make a low frequency clock using an internal timer driving 
a GPIO pin.  You will be limited to a resolution of 4 or 12 FX2 CPU 
clock cycle periods.  Any thing high frequency will have the CPU always 
servicing the timer interrupt.  I would not do this for any thing beyond 
audio frequencies.  Why not just use a small clock oscillator.  The size 
would likely be a fraction of the imager size.

Eric Winsor

John Smithee wrote:
> Hi All,
>
> I am new to the FX2 and I want to use it to interface a CMOS imager. 
> For this I am wondering if it is possible to generate a clock for the 
> image sensor with the FX2 also. Has anybody an idea whether this might 
> be possible? I know I could use a programmable clock chip for this but 
> space on the image board is very restricted so I would be happy if I 
> could do without.
>
>
> Thanks!
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> ------------------------------------------------------------------------
>
> _______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel
>   

Re: [Fx2lib-devel] Generating a clock with the GPIF

[Dennis M. <de...@ub...>]

The FX2 has an interface clock pin that you can drive at either 30 or  
48mhz with the FX2.  The GPIF can drive this pin or it can listen to  
an external clock on the same pin to communicate between it and an  
external device.  If 30 or 48mhz is fine for your external imager then  
I don't see you having any problem without a separate device to  
generate a clock.

-Dennis

On Mar 21, 2009, at 4:42 AM, John Smithee wrote:

> Hi All,
>
> I am new to the FX2 and I want to use it to interface a CMOS imager.  
> For this I am wondering if it is possible to generate a clock for  
> the image sensor with the FX2 also. Has anybody an idea whether this  
> might be possible? I know I could use a programmable clock chip for  
> this but space on the image board is very restricted so I would be  
> happy if I could do without.
>
>
> Thanks!
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM)  
> are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly  
> and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based  
> development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com_______________________________________________
> Fx2lib-devel mailing list
> Fx2...@li...
> https://lists.sourceforge.net/lists/listinfo/fx2lib-devel

[Fx2lib-devel] Generating a clock with the GPIF

[John S. <joh...@go...>]

Hi All,

I am new to the FX2 and I want to use it to interface a CMOS imager. For
this I am wondering if it is possible to generate a clock for the image
sensor with the FX2 also. Has anybody an idea whether this might be
possible? I know I could use a programmable clock chip for this but space on
the image board is very restricted so I would be happy if I could do
without.


Thanks!

Re: [Fx2lib-devel] Arming bulk end points early

[Dennis M. <de...@ub...>]

Dennis Muhlestein wrote:
>
> The fx2lib usbjt.h macros haven't defined a macro for IBN yet.  If I get 
> around to adding that, I'll make sure to keep this example in mind.
>
>   
Feel free to submit patches/enhancements to fx2lib as well!

-Dennis

Re: [Fx2lib-devel] Arming bulk end points early

[Dennis M. <de...@ub...>]

Eric Winsor wrote:
> Dennis Muhlestein wrote:
>   
>> If you find something, let us know!
>>   
>>     
> I earned my cheese!
>
> Here is how to arm packets shorter than the host is asking for.  First, 
> read all about IN-BULK-NAK in the EZ-USB technical reference manual.  
> There is a USB interrupt vector and registers that can be triggered on 
> and watched to catch that the host has asked for an IN packet and the 
> SIE is NAK'ing it.  In code built from the Cypress firmware frameworks 
> model here is code for periph.c to commit a short packet.

That's great Eric.  So in summary, you can tell when the host wants data 
by enabling the IBN interrupt.

I noticed a very important thing about their framework example.  You 
can't just clear the interrupt.  You have to disable it until you've 
handled the nak.  Otherwise your poll function or main loop will not be 
able to do what it needs to do to commit the packet because the 
interrupt will continuously fire.

The fx2lib usbjt.h macros haven't defined a macro for IBN yet.  If I get 
around to adding that, I'll make sure to keep this example in mind.

-Dennis

Re: [Fx2lib-devel] Arming bulk end points early

[Eric W. <er...@wi...>]

Dennis Muhlestein wrote:
> If you find something, let us know!
>   
I earned my cheese!

Here is how to arm packets shorter than the host is asking for.  First, 
read all about IN-BULK-NAK in the EZ-USB technical reference manual.  
There is a USB interrupt vector and registers that can be triggered on 
and watched to catch that the host has asked for an IN packet and the 
SIE is NAK'ing it.  In code built from the Cypress firmware frameworks 
model here is code for periph.c to commit a short packet.

// global variables, add this
BYTE    IbnFlag;                // Flag to track which interrupt bulk 
nak happened.
...
void TD_Init(void)                // Called once at startup
{
...
// After the FIFORESET commands insert this
// The following code initializes the interrupt bulk nak registers which 
enable getting short packets
    NAKIRQ = bmBIT0;            // clear the global IBN IRQ
    NAKIE |= bmBIT0;            // enable the global IBN IRQ
                               
    IbnFlag = 0x00;                // clear our IBN flag
    IBNIRQ = 0xFF;                // clear any pending IBN IRQ
    IBNIE |= bmEP4IBN;            // enable the IBN interrupt for EP6 
and EP8
...
}

void TD_Poll(void)                // Called repeatedly while the device 
is idle
{
...
// Add this type of code to manually arm your packets.  Note: my EP4IN 
is double buffered.
// I'm indexing the EP4FIFOBUF with IRi as I fill it with data above, 
i.e. EP4FIFOBUF[IRi++] = data;
        if(IRi == 512)                            // When IRi = 512 we 
have filled one of the EP 512 byte buffers
        {
            IRi = 0;                                // Reset the counter 
so we can fill the next buffer
            SYNCDELAY;                                // see TRM section 
15.15, pg 315.  We are writing/reading a register within 
0xE600-0xE6FF                   
            EP4BCH = 0x02;                            // Prepare to ARM 
the EP for an IN transaction (High byte must be first)
            SYNCDELAY;                                // see TRM section 
15.15, pg 315.  We are writing/reading a register within 
0xE600-0xE6FF                   
               EP4BCL = 0x00;                            // Now arm the 
EP for transfer by loading the low byte of the byte count (512 bytes)
        }

    // Now commit any short packet on EP4IN if the host asks for it
    if(IbnFlag & bmEP4IBN)                        // Check our flag for 
interrupt bulk nak and see if EP4IN was requested
    {
        EP4BCH = MSB(IRi);                            // Prepare to ARM 
the EP for an IN transaction using the high byte of the IR FIFO buffer 
index (High byte must be first)
        SYNCDELAY;                                    // see TRM section 
15.15, pg 315.  We are writing/reading a register within 0xE600-0xE6FF
        EP4BCL = LSB(IRi);                            // arm EP4IN for 
an IN transaction using the low byte of the IR FIFO buffer index.  The 
bulk packet will be < 512
        IRi = 0;                                    // Reset the IR 
index variable

        IbnFlag &= ~bmEP4IBN;                        // clear the IBN 
flag for the bit representing EP4IN
        IBNIRQ = bmEP4IBN;                            // clear the IBN 
IRQ for the bit representing EP4IN
        IBNIE |= bmEP4IBN;                            // enable the IBN 
IRQ for the bit representing EP4IN so that we are ready for next time
    }
...
}

// Then fill out the IBN interrupt vector code like so:
void ISR_Ibn(void) interrupt 0
{
//This code taken from the FX2LP example code IBN.C
    int i;

    // disable IBN for all endpoints
    IBNIE = 0x00;

    EZUSB_IRQ_CLEAR();        // clear the global USB IRQ

    // Find the EP with its IBN bit set
    for (i=0;i<8;i++)        // Incrementally check each bit to see 
which EP we're NAK'ing
    {
        if (IBNIRQ & (1 << i))    // If this bit is the NAK'ing EP then 
set our flag for it and clear the IRQ for it
        {
            IbnFlag |= (1 << i);    // set the appropriate IBN flag bit
            IBNIRQ |= (1 << i);        // clear the IBN IRQ for this 
endpoint
        }
    }

    NAKIRQ |= bmBIT0;        // clear the global IBN IRQ

    // re-enable IBN interrupt for any endpoints that don't already have
    // an IBN pending in IbnFlag
    IBNIE = (bmEP4IBN) & ~IbnFlag;

}


I took most of this code from the IBN example code in the FX2LP 
development kit.

The result of this is that I can have the host ask for a bulk IN of 512 
bytes and get either, the full 512 if my FIFO was full and the CPU is 
filling the other 512, or a short packet < 512 for what ever the CPU has 
filled to the FIFO to that moment.  This is cool because my data is very 
intermittent and may go days before happening.  I can have the host poll 
regularly and get zero length packets back for no data.  Also if there 
were a burst of data I could get a full 512 packet and then ask 
immediately for another to see if the data overflowed into the second FIFO.

Eric

Re: [Fx2lib-devel] Arming bulk end points early

[Dennis M. <de...@ub...>]

Eric Winsor wrote:
> Is there an EZ-USB register that gets set when a request happens?  Maybe 
> I could trigger on that.
>
>   
The only thing I know is the EPxCS registers tell you how many buffers 
are available (either for you to put stuff in for an IN ep or how many 
are available to read from for an OUT ep).  Those numbers will always be 
whatever your buffer size is though for an IN endpoint.  When the PC 
wants to read, it isn't going to change.

If you find something, let us know!

-Dennis

Re: [Fx2lib-devel] Arming bulk end points early

[Eric W. <er...@wi...>]

Dennis Muhlestein wrote:
> Eric Winsor wrote:
>   
>> Dennis Muhlestein wrote:
>>   
>>     
>>> Eric Winsor wrote:
>>>   
>>>     
>>>       
>>>> I have an application where I would like to ship a 512 byte bulk in 
>>>> endpoint whenever the host asks for a packet.  The host will not know 
>>>> what size the packet is so I am planning on the host asking for 512 
>>>> bytes.  I just want to give the host whatever has accumulated in the 
>>>> EP4FIFOBUF when the host requests the in packet of 512 bytes on EP4.
>>>>   
>>>>     
>>>>       
>>>>         
>>> I think you'll have to tell the fx2 via a vendor command or something 
>>> that you'll be wanting the packet.  The fx2 can then arm the endpoint, 
>>> and the PC can then read the data.  There is otherwise no notice given 
>>> across the USB bus to whatever microprocessor that your program wants to 
>>> read data.  The program will just timeout on the PC side if the endpoint 
>>> isn't armed.
>>>
>>> Is that what you were wanting to get at?
>>>   
>>>     
>>>       
>> Yes.  The data comes in very intermittently and may never be 512 bytes 
>> in size.  I want the host to be able to get it periodically and there 
>> may not be anything there at times.
>>   
>>     
> You could investigate interrupt endpoints instead of bulk maybe?  Or 
> possibly have a different vendor command that lets the PC know a 
> status.. like whether or not there is any data to get.
>   

Is there an EZ-USB register that gets set when a request happens?  Maybe 
I could trigger on that.

Eric

Re: [Fx2lib-devel] Arming bulk end points early

[Dennis M. <de...@ub...>]

Eric Winsor wrote:
> Dennis Muhlestein wrote:
>   
>> Eric Winsor wrote:
>>   
>>     
>>> I have an application where I would like to ship a 512 byte bulk in 
>>> endpoint whenever the host asks for a packet.  The host will not know 
>>> what size the packet is so I am planning on the host asking for 512 
>>> bytes.  I just want to give the host whatever has accumulated in the 
>>> EP4FIFOBUF when the host requests the in packet of 512 bytes on EP4.
>>>   
>>>     
>>>       
>> I think you'll have to tell the fx2 via a vendor command or something 
>> that you'll be wanting the packet.  The fx2 can then arm the endpoint, 
>> and the PC can then read the data.  There is otherwise no notice given 
>> across the USB bus to whatever microprocessor that your program wants to 
>> read data.  The program will just timeout on the PC side if the endpoint 
>> isn't armed.
>>
>> Is that what you were wanting to get at?
>>   
>>     
> Yes.  The data comes in very intermittently and may never be 512 bytes 
> in size.  I want the host to be able to get it periodically and there 
> may not be anything there at times.
>   
You could investigate interrupt endpoints instead of bulk maybe?  Or 
possibly have a different vendor command that lets the PC know a 
status.. like whether or not there is any data to get.

-Dennis

Re: [Fx2lib-devel] Arming bulk end points early

[Eric W. <er...@wi...>]

Dennis Muhlestein wrote:
> Eric Winsor wrote:
>   
>> I have an application where I would like to ship a 512 byte bulk in 
>> endpoint whenever the host asks for a packet.  The host will not know 
>> what size the packet is so I am planning on the host asking for 512 
>> bytes.  I just want to give the host whatever has accumulated in the 
>> EP4FIFOBUF when the host requests the in packet of 512 bytes on EP4.
>>   
>>     
> I think you'll have to tell the fx2 via a vendor command or something 
> that you'll be wanting the packet.  The fx2 can then arm the endpoint, 
> and the PC can then read the data.  There is otherwise no notice given 
> across the USB bus to whatever microprocessor that your program wants to 
> read data.  The program will just timeout on the PC side if the endpoint 
> isn't armed.
>
> Is that what you were wanting to get at?
>   
Yes.  The data comes in very intermittently and may never be 512 bytes 
in size.  I want the host to be able to get it periodically and there 
may not be anything there at times.

Eric

Re: [Fx2lib-devel] Arming bulk end points early

[Dennis M. <de...@ub...>]

Eric Winsor wrote:
> I have an application where I would like to ship a 512 byte bulk in 
> endpoint whenever the host asks for a packet.  The host will not know 
> what size the packet is so I am planning on the host asking for 512 
> bytes.  I just want to give the host whatever has accumulated in the 
> EP4FIFOBUF when the host requests the in packet of 512 bytes on EP4.
>   
I think you'll have to tell the fx2 via a vendor command or something 
that you'll be wanting the packet.  The fx2 can then arm the endpoint, 
and the PC can then read the data.  There is otherwise no notice given 
across the USB bus to whatever microprocessor that your program wants to 
read data.  The program will just timeout on the PC side if the endpoint 
isn't armed.

Is that what you were wanting to get at?

-Dennis

[Fx2lib-devel] Arming bulk end points early

[Eric W. <er...@wi...>]

I have an application where I would like to ship a 512 byte bulk in 
endpoint whenever the host asks for a packet.  The host will not know 
what size the packet is so I am planning on the host asking for 512 
bytes.  I just want to give the host whatever has accumulated in the 
EP4FIFOBUF when the host requests the in packet of 512 bytes on EP4.

Eric

Re: [Fx2lib-devel] Bad GPIF Code

[Eric W. <er...@wi...>]

OK, watch out for weak solder joints.  Turns out that the LV signal was 
floated high due to the wire of my cut and jump coming loose.  I found 
it when I went to solder some wires to test points to watch LV, FV, the 
pixel clock, and a data pin for debugging.

My code was good,  your suggestions to make S0 the capture state work too.

Eric

Re: [Fx2lib-devel] Bad GPIF Code

[Dennis M. <de...@ub...>]

Eric Winsor wrote:
> Hi,
>
> I have noticed that my GPIF code created by GPIF Designer is not 
> acting properly.  I'm getting data sampled when I should be getting 
> nothing.
>
>
> Attached is my GPIF designer file where I am trying to sample data 
> from an imager using the frame valid and line valid signals as 
> triggers.  Also attached is a sample of what the imager output is like 
> (ImageWaves.jpg).  I have PIXCLK feeding IFCLK, FRAME_VALID (FV) 
> feeding RDY0, LINE_VALID (LV) feeding RDY1, and the data attached to 
> FD[7:0].  I can get valid data sampled through the GPIF, but I am also 
> getting non-data sampled from when FV and or LV is not active.  Here 
> are two cuts of imager data from Cyconsole:
>
> 0180  10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
> 0190  10 10 10 10 10 10 10 10 10 10 10 FF 00 00 80 85
> 01A0  84 7D 84 85 83 7D 83 86 82 7E 82 86 83 7E 84 88
>
> And
>
> 00A0  7F 7E 85 7F 7F 7E 85 7E 80 7D 84 7E 80 7D 85 7C
> 00B0  81 7D 82 7E 80 7E FF 00 00 9D 10 10 10 10 10 10
> 00C0  10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
>
> The data following F0 00 00 80 and preceding F0 00 00 9D is valid 
> imager data, 10 is the default imager output when FV and or LV is not 
> active.  FF 00 00 80 is start of line, FF 00 00 9D is end of line.  No 
> matter what I have tried I keep getting data sampled when FV and or LV 
> is low.  I am working with the 56 pin CY7C68014A so I do not have 
> access to the GSTATE bits for debug.  I would appreciate it if anyone 
> could help me out.
>
Your state 0 reads data.  No matter if FV, LV is high or low, you read a 
byte when you enter the state machine.  I think you need to perhaps swap 
state 1 and state 0.
Another issue I see though, is what happens if FV, LV are high when you 
enter the state machine?  Don't you need to wait for them to go low 
again and then start transferring data when the next time FV, LV goes high?

I spent the last couple weeks working with my own Fifo Read issues.  I 
found a few things:

* Rdy0,1, txpire etc, are registered (The data 7:0 is too).  That means 
if Rdy0, rdy1 are true when the decision point tests them, that they 
were actually set during the previous clock cycle.
* When you enter a state, any control lines you set are registered out.  
That means if you set ctl0 high on state 2, that whatever you connect to 
the gpif receives the high a clock cycle later.

I started to develop a behavioral model for this.  It goes something 
like this if you are familiar with Verilog:

reg [2:0] state;
reg rdy0, rdy1;
reg ctl0,ctl1,ctl2;
reg data[7:0];
always @(posedge clk) begin
  rdy0 <= <input signal>;
  rdy1 <= <input signal>;
  data <= <input signals>;
  case (state)
    STATE0:
     begin
       ctl0 <= 1;
       // decision point logic
       if (rdy0) begin
          state <= STATE1;
       end
     end
    STATE1:
      ctl2 <= 1; // whatever you set the control lines to in state 1.
    // read state // do something with data
      someoutput <= data; // whatever
      if ( !rdy0) begin // decision point logic
       state <= STATE2;
     end
    STATE2:   
    // etc... I don't yet have code to dynamically read the gpif output 
so until then, I just coded the same as I did in the gpif designer.
  endcase
end

[Fx2lib-devel] Bad GPIF Code

[Eric W. <er...@wi...>]

Hi,

I have noticed that my GPIF code created by GPIF Designer is not acting 
properly.  I'm getting data sampled when I should be getting nothing.


Attached is my GPIF designer file where I am trying to sample data from 
an imager using the frame valid and line valid signals as triggers.  
Also attached is a sample of what the imager output is like 
(ImageWaves.jpg).  I have PIXCLK feeding IFCLK, FRAME_VALID (FV) feeding 
RDY0, LINE_VALID (LV) feeding RDY1, and the data attached to FD[7:0].  I 
can get valid data sampled through the GPIF, but I am also getting 
non-data sampled from when FV and or LV is not active.  Here are two 
cuts of imager data from Cyconsole:

0180  10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
0190  10 10 10 10 10 10 10 10 10 10 10 FF 00 00 80 85
01A0  84 7D 84 85 83 7D 83 86 82 7E 82 86 83 7E 84 88

 And

00A0  7F 7E 85 7F 7F 7E 85 7E 80 7D 84 7E 80 7D 85 7C
00B0  81 7D 82 7E 80 7E FF 00 00 9D 10 10 10 10 10 10
00C0  10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10

The data following F0 00 00 80 and preceding F0 00 00 9D is valid imager 
data, 10 is the default imager output when FV and or LV is not active.  
FF 00 00 80 is start of line, FF 00 00 9D is end of line.  No matter 
what I have tried I keep getting data sampled when FV and or LV is low.  
I am working with the 56 pin CY7C68014A so I do not have access to the 
GSTATE bits for debug.  I would appreciate it if anyone could help me out.

Thanks,

Eric Winsor

Re: [Fx2lib-devel] Upgrades to fx2lib and new eeprom example firmware.

[Dennis M. <de...@ub...>]

Eric Winsor wrote:
> The driving force behind loading the firmware after connection is that 
> my design only has a 128 bit EEPROM.  This keeps our hardware costs down 
> for the device.  The device only knows its VID, PID, DID on power up.  
> I'm doing a C0 load.  This is one of the cool features of the EZ-USB 
> family of parts.
>
>   
And it allows you to very easily upgrade firmware too.  I'm currently 
trying to be very sure that I don't brick the PCB we have, which doesn't 
have a cool eeprom on/off switch or multiple eeproms!

-Dennis

Re: [Fx2lib-devel] Upgrades to fx2lib and new eeprom example firmware.

[Eric W. <er...@wi...>]

Dennis Muhlestein wrote:
> I just pushed a number of changes to fx2lib.
>
> Of note, Eric just spent a while getting udev rules to automatically 
> load the firmware.  An alternative approach would be to use the Hex2Bix 
> program provided by Cypress to convert the ihx file into an iic file and 
> load the iic file onto the eeprom of the device.  You can use the eeprom 
> example firmware directly or you can copy the functionality in to your 
> own firmware.
>   
The driving force behind loading the firmware after connection is that 
my design only has a 128 bit EEPROM.  This keeps our hardware costs down 
for the device.  The device only knows its VID, PID, DID on power up.  
I'm doing a C0 load.  This is one of the cool features of the EZ-USB 
family of parts.

Eric

Re: [Fx2lib-devel] bulkloop example crashing FX2?

[Dennis M. <de...@ub...>]

Aric Marheine wrote:
> The problem comes down to the fact that the FX2 only has 8KByte RAM, and 
> the FX2LP(which you have) has 16KByte RAM.  So I've got it working as 
> long as I tweek the settings in the Makefile and keep things small.
>
> A bit of a noob question: How can I make use of the external RAM to 
> overcome this shortage?  I'm kind of at a loss as to the command line 
> options to use with SDCC in order to describe my hardware.  My board 
> currently has 0x0000-0x1FFF mapped to internal RAM and 0x2000-0xFFFF 
> mapped to external RAM.
> If I have:
> CC = sdcc -mmcs51 --code-size 0x1800 --xram-loc 0x2000 \
>      -Wl"-b DSCR_AREA = 0x1800" \
>      -Wl"-b INT2JT = 0x1A00"
>
> Then everything works fine, but that gives me little space for code.  
> How do I change this to put my code/data into the external RAM and 
> execute it from there?
>   
I try to create a firmware small enough to fit in the ram on the chip.
The development board has the nice 0x2000-0xffff area memory that you 
can stick a lot of stuff in, but you can then never run your firmware on 
the same chip on a real PCB. (Because it likely won't have the same 
external memory.)  Your approach so far is exactly the way I do it: 
--xram-loc --xram-size, --code-size etc.

Back to your question though, you might try the --codeseg option or the 
codeseg #pragma and then use the linker to place that segment at a 
certain memory location (same as you do with INT2JT).

Glad you found the issue.

-Dennis

[Fx2lib-devel] Upgrades to fx2lib and new eeprom example firmware.

[Dennis M. <de...@ub...>]

I just pushed a number of changes to fx2lib.

Of note, Eric just spent a while getting udev rules to automatically 
load the firmware.  An alternative approach would be to use the Hex2Bix 
program provided by Cypress to convert the ihx file into an iic file and 
load the iic file onto the eeprom of the device.  You can use the eeprom 
example firmware directly or you can copy the functionality in to your 
own firmware.

Here is how you'd use hex2bix and the example eeprom firmware.
1) build your ihx file.
2) Hex2Bix -I -M 10000 -F 0xc2 yourfirmware.ihx yourfirmware.iic
# (-M isn't too important as long as it is the memory size specified is 
big enough for your firmware)
3) I provided a python client in the examples/eeprom.
functions:
get_eeprom(addr,length) -> returns length iic bits at addr.
fetch_eeprom() -> dynamically reads iic file until entire iic from prom 
is fetched
set_eeprom(bits) -> load an iic file onto the eeprom.

You can use get/set eeprom to verify that you loaded the file correctly.

You'll want to be familiar with the reset example firmware if you play 
around with the eeprom data ;)

Additional NOTE:  I ported hex2bix to Unix/Linux (Cypress provides the 
code), but I haven't added it to the library because they have a Cypress 
copyright notice and I haven't taken the time to recreate the 
functionality from scratch.  Send me an email if you'd like the file though.

Here is the git log since the 0.1 tag:

commit f625bb39eec6251cd154f742c9b53d0c5e5f1093
Author: Dennis Muhlestein <de...@ub...>
Date:   Tue Mar 3 11:55:41 2009 -0700

    Additional macro in setupdat.h (SETUP_TYPE).
    Ignore iic files.

commit d317bb16ad3cabc73aa3c93483c2e3f45897d20c
Author: Dennis Muhlestein <de...@ub...>
Date:   Tue Mar 3 11:53:30 2009 -0700

    bix output in Makefile

commit 7eccd3c4b07c2c3161e0156d8ed8f9483a188914
Author: Dennis Muhlestein <de...@ub...>
Date:   Tue Mar 3 11:51:12 2009 -0700

    Modified the eeprom read/write routines to return FALSE if the i2c
    read/write commands didn't work.
    Also modified i2c_write to try again (similar to first implementation)
    if no ACK received after writing the address.  I found the eeprom on the
    development board sometimes does not ack the first time.  TRM says to
    try again in this case.  A side effect of this is you need to make sure
    you are writing to an address that exists or the command will block.

commit 8c975fa8241a82182fa0e357e0b6839821a96363
Author: Dennis Muhlestein <de...@ub...>
Date:   Tue Mar 3 11:46:58 2009 -0700

    Improvements to python bindings. (Allow vendor command variable
    timeout.)
    Added script fx2load to python package for convenience.
    Added eeprom loading example that can read/write iic files from the
    eeprom.

commit 6bca9c94dee103e153569ed1fc9f3da66ba3bb10
Author: Dennis Muhlestein <de...@ub...>
Date:   Tue Mar 3 09:01:10 2009 -0700

    Fixed forgotten import on python example.