uALFAT USB using I2C

[gerald1945]

I've just verified thsat and after sending the W command I get back ! 00 cr
I then send the data and the response is the $ then the number of bytes I've written padded with leading zeroes (30's) and then  ! 00 cr
I then wait 1 second before issuing a close command but the response to it is always ! 36 38 cr

[gerald1945]

I using numbers I know.
I send 111 decimal bytes to a stick - this translates to 6F hex.
I send W sp 30 > 36 46 cr
I get ! 30 30 cr back
I then write the bytes to the module
The response is $ 30 30 30 30 30 30 36 46 cr then ! 30 30 cr  which agrees with what I've sent. So the response to the W command is all correct.
When I send a close ( or Flush) command as C sp 30 cr, the response is ! 36 38 cr
When I check the stick using a binary viewer, the is often zero bytes on it.

[gerald1945]

The problem seems to be that after sending the W command, I get back ! 30 30 cr ! 30 30 cr
But after sending the data I receive the correct responses. Any suggestions why I get the double acknowledge back.

[SupportAdmin]

After you send read/write command, you should wait for !00 before sending/receiving data. If you get back anything but !00 then you do not send/receive any more data

[gerald1945]

I am waiting but instead of !00 I get !00 twice.

[SupportAdmin]

you shouldn't get it twice. All problems you are describing are related to not having solid communication back and forth. One very important customer of our uses I2C with uALFAT on thousands of their units so I2C should be solid

[gerald1945]

I'm not really bothered that other mass users appear to have no problems _ I DO.
I've debugged my firmware completely and its bug free.
What I've found is if I send an odd number of bytes which is the norm for me, then I get problems but if I send an even number of bytes by padding and extra character, everything works fine.
For the I2C interface, I'm pulling both SDA and SCL high to +5 volts via 4K7 resistors.
I cannot get your module to acknowledge bytes but by reading bytes back seperately, it works. I'm using other I2C devices in my system , so my routines are pretty well bullet proof.
I certainly think there are bugs still in your I2C firmware.  I do note your responses are pretty much non technical and provide no detail at all about likely delay times, etc. I also note that a large number of people have logged into this blog - perhaps they are also experiencing similar problems. It looks like I've fixed mine mainly though trial and error until I've found a scheme which works. Pity your designers didn't study the Phillips standard before embarking on their I2C implementation.

[gerald1945]

One thing I've noticed is that if the leading character I send to the write command is non numeric, i.e. A to F, then more often than not, the module clags up and writes the wrong number of bytes to the stick. I've been supressing leading zeroes up to know but if I send them as well so the leading character is numeris, even 0 then the write is correct. As an example writing 220 bytes to a stick translates to D2 in hex. if I send 44 32 in the write command things go wrong but if I send 0d4 as 30 44 32 then all appears well.
The only problem I've now got is the time it's taking to write even a small number of bytes to a stick.  Typically it is taking between 7 to 8 seconds ?
I'm going to investigate where the major delay is coming in.

[SupportAdmin]

If you are doing things properly, you should be able to get about 50KBytes/sec with SPI, UART. I think similar rate is achievable with I2C....at a minimum, you should see 20,000 bytes per second

[gerald1945]

When I send a command, I get a reasonably rapid response. But is that just the uALFAT module rersponding to the command or that the command has actuallly been exectuted ?  For instance, when I send an Open command, the response is rapid but I presume it will take some time to actually execute as far as the USB stick is concerned.

Some times when I send data after a write command, even though the number of bytes sent correspond to those in the write command, the data ready line will jam low. It only seems to happen with certain numbers.  Is it better to poll a response until it's not 0xff and ignore the data ready line ?

I could send an extra byte but I know the number of bytes sent are the same as those specified in the write command.

[SupportAdmin]

You should not send any extra bytes. What you are seeing is a result of error in com or code

[gerald1945]

Are there any examples of low level routines for I2C in your library ?  I'm think of GetChar, etc

[gerald1945]

I've discovered the problem to be the time it takes the open command to execute.  I get a response to the command relatively quickly but the execution of the command takes time which depends upon how much data is already on the stick.  I'd have thought that the busy line would have been used to indicate that the module is busy while it actually executes the command but not so. There doesn't appear to be any way to determine when the open command has executed by which I mean having completed its transactions with the stick. Is this an undersight on your part ?

[SupportAdmin]

I told you it is a bug in your code;)

Writing takes undetermined time, even on a PC so all you have to do is follow the command/response scheme...if you read when you suppose to and not send command till you verify the last error code then you will not have any problems

There doesn't appear to be any way to determine when the open command has executed by which I mean having completed its transactions with the stick. Is this an undersight on your part ?

You will know when you get !00 back

[gerald1945]

I dont think there is a bug in my code. I run extensive tests now by checking for any unread responses before issuing a command. What I find is that before sending the open command, there are no unread responses. After sending the open command, I get the correct response back quickly. Before is send the write command, I find there is an unread response which i read. Now after the write command, I only get the single correct response whereas before I saw a double response.
What appears to happen is the commander sends a response back to the open command and repeats it after the command has executed.
The files I send all read back from a stick correctly when viewed with a binary viewer.
If as you suggest my code is wrong, then why do I get the correct results every time ?

[gerald1945]

I've trawled the forum and found others who have experienced exactly the same problem. Your manual is incorrect. The OPEN command gives a response but after execution sends an error code. if that error code is !00<cr> then all is fine  which is what I get. Your manual doesn't state this at all and I think you should amend so others are not led up the same blind alley as me.
Having amended my program to read back the error code everything works fine. I also note your C examples actually look for the error code.

[SupportAdmin]

Thanks for the feedback. We will look into this and fix any errors in manuals.

[gerald1945]

As a parting shot, could you get your designers to look at accepting an ACK when a character is read in line with I2C practice rather than having to read each character seperately.

[SupportAdmin]

No changes are planed or will be made to uALFAT. There are tens of thousands of chips out there in hundreds of products and any change can stop somebody's design.

Still, thanks for the advice and we already have plans for a major enhancement on I2C in future products

[gerald1945]

I suspect the only problem with reading back individual characters is speed of response. In my case it's not a problem and it's unlikely it will be for others.