Cypress EZ-USB help

Cypress or no Cypress, it's still an 8051. And 8051s do NOT program well in C.

My guess is that you will need to do what every 8051 programmer has done when they have run out of space: Re-code in assembly, and manually optimize it.

Luckily, there are a number of web sites about this process. Google is your friend.

G.

It sounds like the I2C library includes the kitchen sink -- is the EZUSB_InitI2C 500 bytes, or does it pull in the whole library along with it?

The suggestion to write your own material in assembly is a good one. To that I would add that if it's not too late in the development cycle, you should get yourself a bigger chip. If you can't c'est la vie -- but your code is only going to get bigger.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

I looked at the actual code sizes from my link and found the following (in the M51 file):

000DH EZUSB_INITI2C 00F9H I2C_ISR 004AH _EZUSB_RESULT 0038H _EZUSB_WAITFOREEPROMWRITE 0033H _EZUSB_READI2C_ 0031H _EZUSB_WRITEI2C_ 000DH _EZUSB_READI2C 000DH _EZUSB_WRITEI2C

Of course, it is possible your I2C code may be pulling in something esle, perhaps the printf() functions even.

And there are known errors in the I2C code, in case you are doing serious work.

Rgds, Bill

Thanks Bill. I believe it's pulling in those functions, because it throws me warnings about unused functions whenever I don't use all the functions(eg when I readi2c but don't writei2c).

What known errors are you talking about btw?

a) In EZUSB_WriteI2C_() and EZUSB_ReadI2C_(), set up I2CPckt before setting bmSTART or it is possible that an I2C interrupt will occur before I2CPckt is set up.

BOOL EZUSB_WriteI2C_(BYTE addr, BYTE length, BYTE xdata *dat) { #ifndef TNG // if in progress, wait for STOP to complete while (I2CS & bmSTOP) ; #endif

if(I2CPckt.status == I2C_IDLE) {

I2CPckt.length = length; I2CPckt.dat = dat; I2CPckt.count = 0; I2CPckt.status = I2C_SENDING;

// // 17 September, 2007 // XXX of Cypress says these should be after the I2CPckt structure is set up. // I2CS |= bmSTART; I2DAT = addr

Thanks Bill,

Just wondering, how did you manage to obtain the actual code for these library functions. Do you have the code for the other i2c functions too? Also, is the code you show already modified or awaiting modification? Lastly how can i modify the code? Do I have to write new functions w/a different name and use these? What about the isr?

The code is in C:\Cypress\USB\Target\Lib\Ezusb (i2c.c and i2c_rw.c) on my machine and that included the I2C ISR.

There is also EZUSBLIB.h somewhere. I do think some of the function declarations are wrong (for example, EZUSB_ReadI2C() really returns a BYTE not a BOOL).

The code above is already patched (compare with the originals when you find them).

It would probably result in smaller code if I2C_OK had the value zero.

I should probably not have posted the source code above, but it is hard to describe the changes otherwise.

Hope this helps, Bill

Thanks again Bill. I'm able to find the i2c.c and i2c_rw.c. Would it be possible to make the changes in these files and expect the library to be updated? I don't have EZUSBLIB.h, but instead I find a EZUSB.LIB which I assume is precompiled already.

No idea, sorry. I just build the source files (like H:\Husky\Cypress\EZUSB_LIB\i2c.c which I have edited) into my project. The linker drops out unused functions. Good luck. Bill

OK, thanks anyway Bill. You've been of great help. Now if I can only figure out how to squeeze more code into the memory...

Well worth looking at the assembly code produced from your C code as a first step. There can be some surprises (nice and nasty) and it is a way to learn the assembly code too.

I'm new here, but this looks like a bug to me (it's in a sample not library):

void TD_Init(void) // Called once at startup { // Enable the SOF and USB Reset interrupts USBIEN |= bmSOF + bmURES;

// Enable the ISO IN endpoints INISOVAL = bmEP8;

// Set up the addresses for the ISO buffers IN8ADDR = 0x00;

}

Problem is re-enabling the interrupts before setting up to handl interrupt if it occurs .... bug? Or am I missing something?

Riley

Perhaps the assumption is that interrupts are masked globally during system initialization.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
"Already Gone" by Jack Tempchin (recorded by The Eagles)

The Beatles were wrong: 1 & 1 & 1 is 1