I2C Driver Update on Firmware 3.05 and up

[GHI_Support]

I2C driver is completely updated on firmware version 3.05 and up. The new setup can run with 2 wires only and it is more solid.
Manual revision "3.05 B" address these changes.

[chile]

  Very good, I am impatient to reach my ualfat my country, now removed those wires, how many days delay in reaching chile?

[SupportAdmin]

We don't know how long it would take. Check the carrier on that

[M_Belanger]

Hi,

Our current firmware in the uALFAT is 2.15.  Moving to the version 3.XX should not have any impact on our design as I read into the documentation, but we are using the error code.  Is it possible to obtain the Error_code.h file to update us?

We have purchased recently the uALFAT chip for our design, and we would like to update the uALFAT firmware.  Sine we are using i2c, this update has a direct impact on our software implementation in our microcontroler.

So.. what should we know about what have change, obviously the following function could be change, but you are still providing the DATARDY_PIN signal.  Are the Ready and Busy pins going to be used in future released of the uALFAT, or should we eliminate them.  Is there any advantage of keeping them in?

char GHI_GetC(void)
{
//return 1 on success, 0 on failure.
char c;
   while(!GHI_DataIsReady());
    if(DATARDY_PIN)
   {
      // Start read transfer
       TWI_StartRx(DevRTC, (uint8_t*)&c, sizeof(c));
       // Wait until TWI transfer is complete    
       while(TWI_bBusy());
      rx_fifo[rx_fifo_in++]=c;
   }
   return rx_fifo[rx_fifo_out++];
}

Regards

[SupportAdmin]

The pins are and will always be used but now they are optional. What is not optional in the new version is using HDT and NDT (see manual)
(version 3.05 had a little bug still in I2C and 3.06 fixes it)
When you send data, nothing changed from before. You can get away by not checking BUSY if you follow the rules listed in manual
But when you receive, you have to check for NDT and HDT. Here is all the code you need

Code:

int8 __GHI_GetC(void);
int8 GHI_GetC(void)
{
int8 c,r;
do{
c=__GHI_GetC();
}while(c==0xff);/// we may need to add timeout here

// check for NDT and HDT
if(c == 0xfe)//NDT
{
do{
c=__GHI_GetC();
}while(c!=0xff);/// we may need to add timeout here

if(c == 0xFE)
return 0xfe;
else if(c == 0)
return 0xff;
else
{
// this should never happen!!!!
return 0;
}
}
return c;
}
//----------------------------------------------
int8 __GHI_GetC(void)
{
int8 c,r;

//do
{
StartI2C();
IdleI2C();
WriteI2C(ADDRESS+1);
r=SSPCON2bits.ACKSTAT;
}//while(r);// you may want to check this
IdleI2C();
c=ReadI2C();
IdleI2C();
StopI2C();
IdleI2C();

// return what we have
return c;
}

[M_Belanger]

Thank you for your example.

Do you have one that is using the Ready and the Busy pin?

And, is there any advantage of keeping those pin in our design?

[BCJKiwi]

Have reviewed the revised manual and decided to stay with sensing the DATARDY pin rather than via i2c.
Why?
Well with PICAXE which we use (which actually runs interpreted Basic from an interpreter in Flash Ram in the PIC), sensing the Pin status is much simpler, faster and cleaner in coding than reading, storing and interpreting the 0xFF code.

So, Please please please never take away the DATARDY functionality!

Thanks

[SupportAdmin]

DATARDY is there but you still have to process the HDT and NDT if you want to use version 3.xx
You can always use 2.xx to keep it the same

[M_Belanger]

What is the current version of uALFAT2?  Is it possible for you to insert the version on your web site besides the download area?

Regards

[SupportAdmin]

It is on the same page look again

[M_Belanger]

OK, I had to scroll down the page further.  Sorry.

[BCJKiwi]

Well I don't see the firmware versions etc "further down"

I don't see any way to go to a 'Downloads' page on your website.

So the only way I can get there is via
products,
uALFAT OEM with Transflash

The version panel does not exist!

I know we have been over this before but it really would be simpler for all concerned - including yourselves - to get this info in the file name and on the website where the file is, not somewhere else where it can get left off, or nobody looks. I'm really trying to help you here as well as as all your users.

[BCJKiwi]

"DATARDY is there but you still have to process the HDT and NDT if you want to use version 3.xx
You can always use 2.xx to keep it the same"

1.  Presumably this comment relates only to 3.05 and up and only for data reads.

2.  So shouldn't
"You can always use 2.xx to keep it the same"
really be,
You can always use 2.xx or 3xx up to and including 3.04 to keep it the same?

3.  If there are no data reads (Datalogging only), then does 3.06 work the same as 3.04?

Please confirm all three points,

Thanks

[SupportAdmin]

You will not find any version number on the "uALFAT-TF" page!!! This is for the OEM board and this doesn't have version. If you want the version number then go to "uALFAT" page.

1. You can use version 2 and it will be the same but version 3 should be used if you want to use the new features including I2C changes.
2. same as 1
3. you can't do datalogging only!! You still need to send commands

[BCJKiwi]

When we had our last discussion about version issues, (http://ghielectronics.com/forum/index.php?topic=1140.0) you advised in reply #18, "The pages link to the same file. If you need information about the current download version, you can find them at the bottom" and the update info was there at the time, now it's not there.

Just tried to find a "uALFAT" page and the only one is a sub page off any of the other product pages - the only obvious difference in relation to the uALFAT downloads being the version info. So why don't you put the version info at the foot of the product page and save an extra non-intuitive step.

I am sorry to keep raising this but you really need to do better with this update issue. The present setup is just causing a lot of frustration for a lot of your customers.

Why not put all these downloadable files on a single downloads page, subdivide if you need to for different products and make sure people can see what version the download is right there where the download button is.
Would save everyone a lot of time and frustration.

[BCJKiwi]

You have two different types of version 3.xx and you are not making any distinction between them.
up to and including 3.04 works one way, 3.06 a different way.

I currently run uALFAT-TF with fw 3.04
I use i2c
I set the time, initialise the file system and write to the file. Every write to the file is less than 100 bytes.
The only reading that is ever done is accepting all the responses whenever the DATARDY line is high.
I check for DATARDY being high after every command is sent and read in all the data as long as DATARDY remains high.
I never read from the files I write to.
This is what I mean by datalogging only.

If I upgrade to 3.06 firmware and make no changes to the program, will everything still work the same way?

[M_Belanger]

My question has been left unanswered:

Will you support version 2.xx, or should we switch our design to work with 3.06 and up?

[SupportAdmin]

I will answer both posts here.

I have answered this but will make clearer. No 3.06 is NOT compatible with 2.xx as far as I2C goes but it is an easy change and the code is listed in this port. Do NOT use older versions of version 3.xx because they were beta and had issues. 2.xx is already mature and tested everywhere. Version 3.xx is seem solid as far as 3.06 but not older versions and there are possibilities to have upgrades in the future. I hope I am clear this time.

About the second questions, the first post on version 3.xx said this in bold "Version 2 firmware will always be supported "
But, if you are looking for new features then use 3.xx as we are not going to add anything to 2.xx

[M_Belanger]

In the last release of the uALFAT user manual 3.05B, we can see a real improvement in the documentation.

However finding information on simple topics (http://ghielectronics.com/forum/index.php?topic=1125.msg5389#msg5389) requires us to look into several documents and in the forum, which should not be.  I am sure everybody is trying to make the best use of your product, so please be patient, and recognize that information on the uALFAT does required some work, but it is improving which shows that you are responsive to our comments.

Keep up the good work.

Best regards

[SupportAdmin]

I know, our products are the best but we need to make the manual more detailed.

[BCJKiwi]

Well you never said before that fw ver 3.04 was beta!!!

Since once again the question remains unanswered, I have to ask it again;

"I currently run uALFAT-TF with fw 3.04
I use i2c
I set the time, initialise the file system, [create the file,] and write to the file [repeatedly]. Every write to the file is less than 100 bytes.
The only reading that is ever done is accepting all the responses whenever the DATARDY line is high.
I check for DATARDY being high after every command is sent and read in all the data as long as DATARDY remains high.
I never read from the files I write to.
This is what I mean by datalogging only.

If I upgrade [from firmware 3.04] to 3.06 firmware and make no changes to the program, will everything still work the same way?

[SupportAdmin]

Actually I did answer it but I was thinking version 2 to version 3 update!!

Yes in your case, you would have to make no changes

[jackw]

Dear Support people,

Are there any known 'issues' with this new behaviour? I seem to detect something very odd. It almost looks like the µALFAT echoes the real byte after the HDT sequence.

I use the µALFAT to read back previously logged data from an SD-card. Perhaps I'd better give a simplified version of my code first. Note that the original code was written for firmware version 2.15/2.16, but our manufacturer mounted µALFATs with firmware 3.12 on the latest production batch, so I had to hurry to get my stuff up and running :-S
Also note that I bail out when the µALFAT does not have enough data. For fw 2.xx (and still), I used the DATARDY pin. I also implemented the new behaviour (byte 0xFF) for the sake of it :-)

Code:

int rcv_bytes(unsigned char *buffer, int len)
{
  int n = 0;

  while( len-- ) {
    unsigned char byte;

    // data ready?
    if( !DATARDY ) {
      // no data ready, wait until there is
      return n;
    }

    // read one byte from the I2C-bus
    read_i2c(&byte, 1);

    // change in the behaviour of the µALFAT
    if( ualfat_version > 3.05 ) {
      if( byte == 0xFE ) {
        read_i2c(&byte, 1);

        // translate byte
        if( byte == 0x00 ) byte = 0xFF;
      }
      else if( byte == 0xFF ) {
        // No Data Token - wait until data arrives
        return n;
      }
    }

    buffer[n++] = byte;
  }

  return n;
}

Now the strange behaviour. I noticed two things.
First of all, while debugging my microprocessor code, I noticed that my "rcv_bytes()" function returns when the file contains a byte 0xFF (and also at that point, surely). My 'buffer' also contains a byte 0xFF, which makes my conclude that the µALFAT sends the following byte sequence:

Code:

(µalfat) FE 00 FF

I noticed earlier that the µALFAT also sent an extra 0xFE in the sequence

Code:

(file) FE 59

The µALFAT sent the following sequence.

Code:

(µalfat) FE FE FE 59

But now I run into the next problem. My file contains two consecutive 0xFE bytes, but I see three of them in my 'buffer'! So apparently the µALFAT sends six 0xFE bytes. And this made me conclude that the µALFAT sends the original byte as well (please count with me:

• byte 1: HDT,
• byte 2: 0xFE to indicate that the HDT escapes an 0xFE byte and
• byte 3: repetition of the actual byte, not escaped;
• and this twice for the two bytes 0xFE in the input file).

Can you confirm on this behaviour?

Kind regards,
Jack Weeland
Core|Vision B.V., The Netherlands

[SupportAdmin]

There isn't any knows issues for uALFAT and it is already been used in hundreds/thousands of products.
What you are seeing is due to some broken communication.

Keep it simple to test your communication, try to read the version  number 100 times in a tight loop, does it work? Then try to enter and exit a directory 100 times in a tight loop, does it work? If all is well then start looking into the whole picture.

[jackw]

We've been using the µALFAT-chip for 3 years now and it is used in about 1000 products that are deployed in the field.
So the communication could be considered to be okay.
(I still miss a "chkdsk /f" function though, but that's another matter :-)

I don't have the time nor the opportuny to do the tests you suggested. However, I added a third read to my "rcv_bytes" function and it now runs perfectly. Moreover, I added a test to see if the third byte is different from the escaped byte (so I can trip a breakpoint on it) and the breakpoint hasn't tripped. In other words, my supposition in my earlier post appears to be true: the bytes 0xFE and 0xFF are escaped using a HDT sequence and they are sent normally.

Please do note that your suggestions (reading the banner/version/directory/whatever) only includes normal, human readable text. If doesn't prove anything in my case.
I have a binary log file, which I have to read back so it can be transmitted over GPRS to be stored in a database. I just searched the forum for "I2C" to see how other people use the µALFAT in combination with I2C, but no-one seems to be using it to read binary files (at least, not the people that post messages here)

Kind regards,
Jack