Revised I2C Eeprom Include File

Anonymous
2014-05-30
2014-08-25
  • Anonymous - 2014-05-30

    Hello all,

    This was a project I never intended! Originally, I just wanted to comment Anobium's code "24LCxxxx.h" just so I could learn more about I2C. As I eventually sorted it out, I noticed that it could be collapsed quite a bit, while adding to the generality. What evolved became different enough that I thought it might be best to give it a new name. But the original thrust is definitely Anobium's. You'll find the new include file attached to the next post. Here's what's new:

    • generalized with parameters to allow connection to multiple EEPROMs simultaneously
    • removed unneeded or redundant code
    • greatly condensed the array write command in particular
    • renamed page commands to reflect they are actually array/string commands (not page commands)
    • reduced local variables to only two bytes
    • commented the code throughout to make improvements easier
    • eliminated reliance on the "Utils.h" include file
    • renamed parameters to be consistent, but still not clash with user program variables

    Beginners will find explanations in the file as well. It's self-documenting, but if you really want some sample programs using it, I'll be glad to pass them on.

    I've tested this on the 24LC256 and AT24C32 which have page sizes of 64 and 32 bytes, respectively. I would surely appreciate it if others would test with other chips. The goal should eventually be to make this an all-inclusive package for I2C Eeproms, rather than have the Include folder keep exploding with all sorts of mini-files.

    Thomas Henry

     
  • Anobium

    Anobium - 2014-05-30

    I will test and let you know.

    What changed in terms of backwards compatibility? Backwards compatibility is very important as we change code.

     
  • Anobium

    Anobium - 2014-06-25

    I am porting the new GLCD routines to these new routines. Can you confirm the following is ok? I do not have time to test all these options. These were my test cases.

    1. Array write of less than 64 bytes @ address 0
    2. Array write of less than 64 bytes @ address 1
    3. Array write of less than 64 bytes @ start of a page address+1 = first byte of a page
    4. Array write of less than 64 bytes @ start of a page address+1

    5. Array write of 65 bytes @ address 0

    6. Array write of 65 bytes @ start of page address
    7. Array write of 65 bytes @ address 1
    8. Array write of 65 bytes @ start of page address+1

    A quick response would be great.

     
    • Anobium

      Anobium - 2014-07-04

      I tested. Looks great. All ok on the latest include file.

       
  • Anobium

    Anobium - 2014-06-28

    During testing of the GLCD Image code I have found a little error where one of the parameters may not be passed correctly. I have corrected.

    I have also added to references to call the same functions as strings.

    We now have:
    eeprom_wr_array
    eeprom_wr_string
    eeprom_rd_array
    eeprom_rd_string

     
  • Anobium

    Anobium - 2014-06-28

    Revised again.

    I have removed the variables that were defined. For some reason, I will figure out, if these variables were define then you cannot pass arrayelement(0) or a Constant as the length parameter.

     
  • Anobium

    Anobium - 2014-07-03

    Revised again but this time.... to support the hardware I2C module, the MSSP.

    The same .h file supports the software and hardware I2C methods.

    I have posted the latest file i2Ceeprom.h to the code section of SourceForge.

     
  • Anobium

    Anobium - 2014-07-03

    Just updated the front page of the CGB website with new of this driver.

    Thanks Thomas Henry.

     
  • Anobium

    Anobium - 2014-07-04

    Here is a question.

    Where does this go in the Help File?

    Under EEPROM? or SERIAL? or elsewhere?

     
  • Anonymous - 2014-07-06

    My vote would be for "elsewhere." In particular, anything that is devoted to specialized (external) hardware, and not in the low-level include file folder might be best as a separate category. For example, how about:

    --- External Devices
    - DS1307 Real Time Clock
    - DS18S20 Thermometer
    - Sony Remote Control
    - I2C Eeproms
    - DHT Humidity Sensors
    - SRF04 Range Finder
    - etc.

    In other words, anything that is not part of the normal innards of a PIC or AVR (timers, PWM. comparators, capture module, etc.) would be considered external and worthy of a separate category. Sort of like what the Arduino crowd does.

    But perhaps the main thing would be to have multiple eyes proofread all the Help files for consistency, accuracy and eye-appeal to beginners. As I see it, that's the main stumbling block right now. There is no doubt in my mind that Great Cow Basic is the premier compiler for microcontrollers, but until we document it properly no one will ever know and it will languish.

    Thomas Henry

     
  • Anobium

    Anobium - 2014-07-06

    Good idea. Will do.

    I have started another thread on the Help file improvements.

     
  • Anobium

    Anobium - 2014-07-12

    Revised again - discovered another issue this week when working on another I2C issue.

    I have added support to this library for Byte address EEPROMs. These are the smaller EEPROM devices that only require a BYTE address.

    Same parameters as before simple choose a byte or word for the address parameter for the type of device.

     
  • Anobium

    Anobium - 2014-08-25

    Uploaded to the released code section of SourceForge, see https://sourceforge.net/p/gcbasic/code/HEAD/tree/GCBASIC/trunk/include/I2CEEPROM.h

    I have updated header for copyright etc. This is now destined for general release. I will update the Help File as soon as practical.

    Now supports writing Array and Strings to EEPROM, this version handles EEPROMs that required word or byte addresses, supports GCB Software IC2 and GCB Hardware IC2.

    Thank you.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks