• AVR Freaks

Hot!Temperature sensor library in MCC

Page: 12 > Showing page 1 of 2
Author
Mysil
Super Member
  • Total Posts : 3486
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: online
2017/03/08 15:19:17 (permalink)
5 (1)

Temperature sensor library in MCC

Looking thru release notes and MCC webpage for the current release,
there seem to be a Temperature sensor library available.
 
While this is a admirable effort, and the functions may work as intended,
it is my opinion that there is considerable possibilities for improvement.
Following is some observations and suggestions:

The library package was not downloaded and installed together with the plugin,
it was available for download in the MCC webpage.
Downloaded and installed together with other:  mcc/libraries/*.jar  files,
added to the MCC plugin in MPLABX,
and created a new project in MPLAB X and MCC to see what it could do.

Unfortunately, I do not have a MCP9808 to test against,
instead, I have some MCP9801 temperature sensors.
but these are not supported by the library in it's present state.

Built the program anyway, to see how it would behave when calling a slave that isn't available.
Function
    MCP9808_GetTemperatureValue(...)
return the I2C driver status variable, which is a enumeration code, as a integer value,
with the documented interpretation that value 0 is successfull completion.
What other return values might mean, is not described.
This is a misuse of the enumeration type,
and the definition of the I2C status enumeration type with 0 as successfull completion is vulnerable.

When I rearrange the enumeration type I2C_MESSAGE_STATUS in connection with rewriting the I2C driver,
  I2C_MESSAGE_COMPLETE will get a different numeric value.
The temprature library should either document that it use I2C status enumeration values,
or set its return values according to comparision with enumeration symbols.

I2C is an addressable bus, and MCP9808 hardware is designed to be able to string together 8 devices on the same 2 wires.
Then, datasheet reveal that it is possible to ask the factory for devices with address code 0x48 + A,
making for up to 16 devices on the same bus.
None of the API routines in the library have sensor number or index as argument.
I2C Address of a single sensor is configured in MCC GUI, and hardcoded as a defined macro in the source code.

Coded as a macro, it could be possible to replace this with a variable,
but no API design for this purpose is indicated.

The plugin create a subdirectory under mcc_generated_files/MCP9808Drivers
why such a confining name, isn't the library intended to support any other devices?
I would suggest a more open directory name, like: /TemperatureLibrary,  or I2C_SensorLibrary.

Then, the code generated for the Temprature library, isn't much of a driver,
it is a collection of blocking hardware access primitives.
With the time needed to transfer data over I2C,
and even longer time used by the temperature sensor to perform conversion,
it would be really appropriate with a Non-Blocking state machine driver to
organise communication with one or several temperature sensors.     

Alternatively, it is possible to attach up to 8 MCP9801 devices to the same bus.
MCP9801 are pin compatible with MCP9808 which have got some more registers and some additional features,
and a register layout that is a complete mess.
Resolution setting have got a separate register although the steps are the same.
Temprature results register have got a jumbled layout with several status bits,
possibly to get both temperature results and status information in a single transfer.

There seem to be a mistake in Datasheet DS25095A for MCP9808:
Page 24 say that default resolution is 0.25 °C,
while page 29 Register 5-7: Resolution Register specification, state that power-up default resolution is 0.0625°C.
same on page 31.


Regards,
   Mysil
#1

20 Replies Related Threads

    Abraxas
    Super Member
    • Total Posts : 359
    • Reward points : 0
    • Joined: 2009/08/27 17:21:14
    • Location: 0
    • Status: offline
    Re: Temperature sensor library in MCC 2017/03/08 18:13:02 (permalink)
    0
    What temperature specs are you striving for ? Range ? Accuracy ? What are you measuring ? Ambient air ? Liquids ? I'm coming along fairly well with the Maxim/Dallas DS18B20 and it comes encapsulated in stainless steel. For higher temperatures there are of course K Type thermocouples with cheap chips that convert to I2C.
    post edited by Abraxas - 2017/03/08 18:18:16
    #2
    Mysil
    Super Member
    • Total Posts : 3486
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: online
    Re: Temperature sensor library in MCC 2017/03/08 21:34:29 (permalink)
    4 (1)
    Hi, Abraxas
    The subject I tried to raise was MCC library software for I2C sensors.
     
    As far as I understand, Maxim/Dallas DS18B20  is a device using Dallas 1-wire communication.
    If you are suggesting to integrate that in MCC library generated code, I think you are raising ambitions even more.
     
    The aim at present, is ambient temperature inside and outside, so performance of MCP9801 and MCP9808 is adequate. While specifications for  these devices are very similar as temperature sensors, and devices are pin compatible in MSOP package, I did complain that register layout in the improved device is messy,
    but this may be overcome in software.
     
    My main complaint, is the lack of ambition in design of API in the present library:
    No provision for more than 1 sensor, and no Non-Blocking implementation of driver.
     
    Even with these complaints, the Temperature sensor library is a step in the right direction, there is just more work needed.
     
    This bring up my next question:
    Is there a SDK, development support kit, and/or development guide  available for MCC?
    I may be able to correct some of the most annoying blunders in FTL scripts,
    but when I tried to put it back place, there seem to be some kind of checksum protection, causing the script in question to fail.
     
    Regards,
       Mysil
     
     
    post edited by Mysil - 2017/03/09 06:29:14
    #3
    cobusve
    Super Member
    • Total Posts : 495
    • Reward points : 0
    • Joined: 2012/04/02 16:15:40
    • Location: Chandler
    • Status: offline
    Re: Temperature sensor library in MCC 2017/03/09 11:01:05 (permalink)
    4.33 (3)
    Hi Mysil,
     
    There are many aspects to what you are saying. On a high level different people have different issues they are trying to solve in different contexts.

    We are in the process of releasing a set of libraries that are much more in line with what you are talking about here, including answering the second question you bring up about I2C drivers. We are releasing a collection of libraries called "Foundation Services" which includes things like I2C, SPI and Timer drivers and will soon also contain ADC, PWM and other abstractions. 

    This is going hand in hand with sensor libraries which we are releasing with MikroElektronika Click boards as examples, many of these click boards contain Microchip I2C based sensors.

    You can get the libraries and follow the first 50 drivers over the next 50 days from this landing page :
    http://microchip.com/50in50

    We can continue the discussion here if you want and we can tackle each of your observations, but since the intention of the temp sensor library is simply example code on how to use the sensor, while these other libraries are attending to your requirements much better, perhaps you should check them out first ?

    Cobus
    #4
    cobusve
    Super Member
    • Total Posts : 495
    • Reward points : 0
    • Joined: 2012/04/02 16:15:40
    • Location: Chandler
    • Status: offline
    Re: Temperature sensor library in MCC 2017/03/09 11:02:25 (permalink)
    4.5 (2)
    Oh, and we are also in the process of releasing an SDK to empower people like yourself to extend drivers and also make their own. If you contact me via PM I can perhaps sign you up to be a beta tester :)
     
    #5
    Mysil
    Super Member
    • Total Posts : 3486
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: online
    Re: Temperature sensor library in MCC 2017/03/27 01:01:53 (permalink)
    0
    It have taken some time. Attached here is my twist on Temperature sensor functions connected by I2C.
     
    The attached project have configurations for PIC18F26K22, PIC16F1718, PIC16F1938 and PIC16F886.
    The attached example program have code interfacing various I2C devices:
    MCP9801 temperature sensors,
    MPL3115A2 Barometer, Altimeter and Thermometer,
    CMPS03 Magnetometer compass is an assembly of sensors using a PIC18F2321 for transformations.
    LK204 is a Character LCD Display module by Matrix Orbital, using a ATMega8535 for communication and display.
    RLY08 is a board with 8 small relays, by Robot Electronics in England, controlled by a small PIC.
     
    Example code have various implementations, some blocking, that is waiting for transfer to complete, some non-blocking, and some non-blocking task service state machine implementations.
     
    There is a extensive rewrite of I2C interrupt driver, based on MCC's I2C driver. 
    The Driver code is: I2C_Master_SSP.c  and I2C_Master_SSP.h
    Major functions in driver API are:
        I2C_MasterWrite( WriteData, Length, I2C_Address, &WriteStat)
        I2C_MasterRead( ReadData, Length, I2C_Address, &ReadStat)
        I2C_MasterWriteRead( WriteData, Length, ReadData, Length, I2C_Address, &WRStat)
        I2C_MasterCommandWrite( Command, WriteData, Length, I2C_Address, &WriteStat)
        I2C_MasterCommandRead( Command, ReadData, Length, I2C_Address, &ReadStat)
     
    The following functions are supported for compatibility:
        I2C_MasterWriteTRBBuild ( *ptrb, *pdata, length, address),
        I2C_MasterReadTRBBuild ( *ptrb, *pdata, length, address),
    and    I2C_MasterTRBInsert ( count, *ptrb_list, *pflag);   
     
    All information needed to perform transfers are copied into transfer queue entries,
    and queue entry is kept intact until transfer is completed. TRB's are no longer used as part of the queue structure.
    On PIC16 and PIC18 devices, each Transfer queue Entry is 10 bytes.
     
    On PIC32, each Transfer queue entry will be 3 long words.
    I2C_MasterWriteRead(...) and similar functions will need 2 transfer queue entries.
     
    There are changes to I2C_MESSAGE_STATUS enumeration list, there are some additional status codes,
    and the list is reordered such that major status may be determined with just 2 tests:
        while (CMPS03_Wflag < I2C_MESSAGE_COMPLETE);    /* Wait for communication. */
        if (CMPS03_Wflag == I2C_MESSAGE_COMPLETE)       /* Transfer successfully completed. */
        { ... }
        else                                            /* Anything else is a problem of some kind
        { ... }

     
    Regards,
       Mysil
    post edited by Mysil - 2017/03/27 18:24:38
    #6
    Mysil
    Super Member
    • Total Posts : 3486
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: online
    Re: Temperature sensor library in MCC 2017/04/10 17:02:25 (permalink)
    0

    Voltage and Thermocouple temperature measurement.

    In the attached example code, there is driver code for MCP3428, MCP3427, MCP3426 and MCP3425 AD Converters with I2C interface.
    Code should also work with MCP3424, MCP3423, MCP3422 and MCP3421 AD Converters, but 18 bit resolution modes have not been tested.
    Code is able to scan multiple ADC channels in a task service function.
     
    A simple voltage to temperature transformation for Thermocouple type K, is also included.
    It is using piecewise linear interpolation. Cubic spline interpolation may come later.
     
    MPLAB X configurations include PIC16F1718, PIC16F1938 and PIC18F26K22.
    Example code is now too large for PIC16F886.
     
    I2C driver code, is the same as in the previous posting.
     
    Regards,
       Mysil
    #7
    Mysil
    Super Member
    • Total Posts : 3486
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: online
    Re: Temperature sensor library in MCC 2017/04/24 23:57:04 (permalink)
    5 (1)

    Voltage and Temperature example code for PIC32MX220, MX250 and MX130.

    Attachment have project configurations for some PIC32MX1 and MX2 devices,
    communicating with MCP9801 temprature sensor,
    and MCP3426 and MCP3428 ADC with I2C interface, for general Voltage and Thermocouple type K temperature measurement.
     
    Also EEPROM example code for reading MCHP24LC65  EEPROM.
     
    MasterI2C driver for PIC32MX with the same API as in previous posts.
     
    Regards,
       Mysil
     
     
    #8
    Mysil
    Super Member
    • Total Posts : 3486
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: online
    Re: Temperature sensor library in MCC 2017/05/03 13:09:05 (permalink)
    3 (1)

    I2C driver and temperature example code for PIC32MM

     
    I2C driver is a blocking bitbanging based on assembly code primitives published by Microchip in the PIC32MM product homepage. There are modifications to tighten up timing, and to handle Start condition properly with check for other activity on the bus. 
    There is a protocol driver in C, to provide Application Interface functions compatible with functions for other devices.
     
    There is a heap of example code following the same pattern as in previous postings. 
    Now, there is also a UART dump providing measurement listing on U2TX pin routed to RB8, Pin 17 on devices in 28 pin package. Serial signals are 38.4 kbit/s, 8 data bits, no parity and 1 stop bit.
     
    Regards,
       Mysil
    #9
    Mysil
    Super Member
    • Total Posts : 3486
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: online
    Re: Temperature sensor library in MCC 2017/05/29 02:56:43 (permalink)
    0

    I2C Temperature and Voltage example code with I2C driver for PIC24FJ and dsPIC33FJ

    Attached is I2C example project with configurations for PIC24FJ256GB110, PIC24FJ64GB002 and dsPIC33FJ128MC802.
     
    I2C driver is a extensively rewritten variant of the non-blocking interrupt I2C driver, that is part of ordinary MCC libraries, using the same API functions as in previous messages.
     
    The driver cannot be configured by MCC graphic user interface, yet. Driver configuration settings are available as definitions in the first part of the source file. It should be possible to configue the driver to use any I2C module in the chip by changing:
    #define  I2C_INSTANCE    1    /* This is Instance number used in API functions */
    #define  I2C_CHANNEL    1    /* This is Hardware peripheral module number. */
    in I2C_Master_FJ.c
    If more than one I2C peripheral is going to be used in the same program,
    the .c source file will need to be duplicated, and given a unique name.
    The header file is general, and do not need to be duplicated.
     
    In case of a stuck I2C bus, the driver have a check and recovery function to clock the SCL line.
    For this, the driver will bitbang the I2C signal lines, and will need macro names identifying I2C signal pins.
    For devices with dedicated I2C pins, signal definitions are predefined for some device types.
    If device with PPS for I2C signals is used, Pin names must be defined in MCC pin configuration.
     
    UART dump is available in the example program. For PIC24FJ256GB110, RD1 is used for UART TX signal.
    For PIC24FJ64GB002, RB7, or RB10 is used for TX output,
    for dsPIC33FJ128MC802, RB6 is used for TX. UART may be remapped, and example code in the main program file may be reconfigured at will.
     
    Regards,
       Mysil
     
     
    #10
    Wieschebrock
    Super Member
    • Total Posts : 213
    • Reward points : 0
    • Joined: 2005/01/22 07:57:44
    • Location: Germany
    • Status: offline
    Re: Temperature sensor library in MCC 2018/07/06 02:20:39 (permalink)
    0
    Hi Mysil,
     
    very interesting thread.
     
    I try to use the MCC I2Cx Library and the new EEPROM Library V1.00 on a DSPIC33EP512MC506 to get a non blocking code for MCHP24LC512. Normally not a big thing, but it is driving me nuts
    The code seems to be buggy: The write function seems to be ok after some changes to be sure that SLCK and SDA get's high again after STOP before starting the next  protocol. But seq. reading seems to be messed up. 
    Status is always  I2C1_MESSAGE_ADDRESS_NO_ACK or I2C1_DATA_NO_ACK.
    And obvious there is no way to reset the bus with >9 SCLKs
     
    So I am very interested in your code for accessing the EEPROM. Unfortunately the PIC24 package only has the header file included.
     
     
    Can you send me the code to access the EEPROM?
     
    Best regards from Germany
    DW
    #11
    Mysil
    Super Member
    • Total Posts : 3486
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: online
    Re: Temperature sensor library and EEPROM in MCC 2018/07/08 05:06:15 (permalink)
    0
    Hi Wieschebrock,
    Here is my latest iteration on external EEPROM read and write.
    It is a MPLAB X project for dsPIC33FJ128MC802. Configurations for PIC24 devices may come later.
     
    I2C code for datalogging to 24LC512 EEPROM  with  7 bit I2C address for the memory chip 0x57

    Program is reading from I2C Temperature sensor MCP9801 with 7 bit I2C address 0x4F

    Code is based on MCC,
    I2C driver with modifications as shown in this thread,
    and EEPROM "Library 1.00" also with a lot of modifications.

    EEPROM operations are still blocking.
    Most EEPROM operations are now done with 1 transfer request to I2C driver,
    so may be made non-blocking, just by returning to caller, and defer checking to a later time.

    Exceptions are when 24LC512 is busy with internal write operation.
    That is for Write operations that span from one EEPROM page into the next,
    or for Read operations  attempted too soon after Write is initiated.
    In these cases, there is need for a timed wait and retry,
    other than busy __delay_ms, for non-blocking operation to be implemented.
    Timer2 that is used for millisecond tick timing, may be useful in this case.

    Note, that EEPROM Write operations are done by direct transfer from application memory, so buffer used for Data to be written to EEPROM, must remain intact until I2C transfer is completed.

    Similarly for Read operations, Data buffer must be provided by application code,
    when transfer is initiated, but will have valid data when transfer is completed.

    Clock is Too fast.
    I2C bit time is 5.966 us:   10/6 is 1.6x  32MHz * is 53 MHz
    dsPIC33FJ128MC802 have FRC oscillator running at 7.37 MHz.
    Corrected FCY and _XTAL_FREQ.  

    For PIC24 and dsPIC33 devices,
    it is a question whether to use _XTAL_FREQ or FCY as timing macro definition.
    In the current code, both are defined and used, and may need to change for running on devices with different oscillator settings.
    I2C is not too picky, as long as frequency is not much too high. UART dump make garbage if frequency is wrong.
     
    There is some configuration macro definitions controlling what pins to use for I2C and UART TX.
    I2C pins are rerouted by #pragma config ALTI2C,
    UART  is rerouted by PPS.
    See: Configbits.h,   pin_manager.c, pin manager.h, main.h and uart2.c.
     
       Mysil
     
     
    post edited by Mysil - 2018/07/09 18:33:00
    #12
    Wieschebrock
    Super Member
    • Total Posts : 213
    • Reward points : 0
    • Joined: 2005/01/22 07:57:44
    • Location: Germany
    • Status: offline
    Re: Temperature sensor library and EEPROM in MCC 2018/07/09 07:06:09 (permalink)
    0
    Thanks a lot, I will give it a try.
     
    Some questions 
    1.
    in I2C_EEPROM_PageWrite 
    I2Cx_MasterWrite(Instance, eepromBuffer, 8+2, Instance->busAddress, &Instance->tstat);

    the size is fix (8+2), that might be ok in the mcc generated code where PAGESIZE is also 8
    but shouldn't it:
    I2Cx_MasterWrite(Instance, eepromBuffer, 2+I2C_EEPROM_PAGESIZE, Instance->busAddress, &Instance->tstat);

     
    2. 
     in I2C_EEPROM_SequentialRead the 
    I2Cx_MasterWrite(Instance,  eepromBuffer, 2, Instance->busAddress, &Instance->tstat); 
    stuff (before the read is performed) is disabled.
     
    I thought that was the acknowledge polling to be sure that the internal programming cycle of the last write command (milliseconds) was completed before trying to access the EEPROM again. 
     
    3.
    If 2. isn't the acknowledge polling, is there an acknowledge polling that I have missed?   
     
     
     
    post edited by Wieschebrock - 2018/07/09 07:15:06
    #13
    Mysil
    Super Member
    • Total Posts : 3486
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: online
    Re: Temperature sensor library and EEPROM in MCC 2018/07/09 17:57:11 (permalink)
    0
    Hi Wieschebrock,
     
    I have not studied the ..._PageWrite(...)  and  ..._PageRead(...)  functions any much, 
    and I have not seen any design documentation describing what is intended. 
    It may seem that i2c_eeprom_app   is intended to use one or more buffers
    with size that may be different from physical page size in the EEPROM hardware. 
    To make sense, such buffers should be part of:   I2C_EEPROM_T;     structure type,
    or at least have pointer and metadata there.
     
    As fas as I remember, I did generate the code with a buffer size selection larger than 8,
    but there is that hardcoded value 8, in source code
    and also a definition:    #define PAGESIZE (8)      // in the header file, that do not make much sense.
     
    2.
    In: I2C_EEPROM_SequentialRead (...)
    There are two complete and separate alternative implementations. You may try either alternative.
    I2Cx_MasterCommandRead(Instance, startAddress, data, size, Instance->busAddress, &Instance->tstat);
    and the driver interface function that is called:
        I2C1_MasterCommandRead( command, data, size, busAddress,((I2C_MESSAGE_STATUS *)pstatus));
    is able to do all that is needed for a memory read transfer: 
    Start, send I2C address, write memory address, repeat start signal, I2C address with read bit, read memory data, stop signal.
    The command part of transfer, may be from 1 to 4 bytes. In this case 2 bytes are used for the 16-bit EEPROM address.
     
    3.
    In the:  I2C_EEPROM_SequentialWrite(...);  function, I did introduce a delay 5 milliseconds between Retries.
    If there is no response from the EEPROM device, function will retry a limited number of times,
    up to I2C_EEPROM_GENERIC_RETRY_MAX     which is 5.
    This is acknowledge polling,  implied in the transfer procedure.
     
    In the corresponding:  I2C_EEPROM_SequentialRead(...);    there is no delay or other control of timing between retries.
    This will have the effect that if Read is tried directly after Write,
    acknowledge polling will reach maximum number of Retry attempts, before  EEPROM is ready to respond,
    and return a Failure status as function value.
    The status code reported from I2C driver will be available in:    eepromInstance->tstat
     
    A separate function to perform Acknowledge polling, would certainly make sense. 
    It would be much faster to only write EEPROM slave address with Write bit, 
    and return the status without any attempt to Retry.
    This would take about 150 microsecond in a blocking implementation,
    or you could make a non-blocking implementation by calling: 
        I2Cx_MasterWrite(Instance,  dummyBuffer, 0, Instance->busAddress, &Instance->tstat);
    the answer will appear in:   Instance->tstat;       when the query is complete.
    If       ( Instance->tstat <  EEPROM_MESSAGE_COMPLETE)      then question is not yet answered.
    If       (Instance->tstat ==  EEPROM_I2C_MESSAGE_ADDRESS_NO_ACK)    There was no response.
    If       (Instance->tstat ==  EEPROM_I2C_MESSAGE_COMPLETE)       then EEPROM is ready.
     
    Your questions about Acknovlledge polling, and some testing without a responding slave have revealed a weakness in the I2C driver. 
    Combined operations,
    I2C1_MasterCommandWrite(command, data, size, busAddress, pstatus );
    and
    I2C1_MasterCommandRead( command, data, size, busAddress, pstatus );
    perform 2  transfer operations that are linked together.
    When the first transfer is terminated with I2C_ERROR_ADDRESS_NACK,
    the linked transfer should also be canceled.
    Otherwise it could happen that EEPROM become ready after the memory address transfer have been aborted, 
    but Data transfer could succeed, possibly writing in wrong locations in memory.
    I will look into this.
     
    Regards,
       Mysil
     
    post edited by Mysil - 2018/07/09 19:58:36
    #14
    Wieschebrock
    Super Member
    • Total Posts : 213
    • Reward points : 0
    • Joined: 2005/01/22 07:57:44
    • Location: Germany
    • Status: offline
    Re: Temperature sensor library and EEPROM in MCC 2018/07/10 03:05:56 (permalink)
    0
    Hi Mysil,
    I have adapted the code to the DSPIC33EP512MC506 regarding the system speed.
     
    Starting in the morning I was able to write and read a page. grin: grin But after reconnecting the ICD3 (communication problem) 
    I run into the problem that I always got an I2C_Queue.full error. No code change.
     
    The transmission starts, but after a few SCLK it stops and the SDA remains low.
     
    post edited by Wieschebrock - 2018/07/10 03:55:44
    #15
    Mysil
    Super Member
    • Total Posts : 3486
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: online
    Re: Temperature sensor library and EEPROM in MCC 2018/07/10 13:09:24 (permalink)
    0
    Hi,
    EEPROM_I2C_QUEUE_FULL
    may be caused by the misguided attempt of Timeout checking in:   i2c_eeprom_app.c
    You may increase   I2C_EEPROM_GENERIC_DEVICE_TIMEOUT , 
    or remove the timeout logic.
    Running on dsPIC33EP... with higher clock frequency, will require a higher value for ..._TIMEOUT
     
    If there are errors that cause I2C driver to not return at all,
    then the problem must be detected and solved in driver code.
    Just trying again if there is a timeout, will not recover the queue entries, and will cause QUEUE_FULL.
     
    You may also introduce a 1 millisecond delay  before a retry.
    See how the 5 millisecond delay is done in:  I2C_EEPROM_SequentialWrite(...),
    or do a delay in all cases, after incrementing:  
                retryCount++;
            __delay_ms(1);    /* Delay before trying again. */
     
    5 millisecond delay may be longer than needed, may be reduced.
     
       Mysil
    #16
    Wieschebrock
    Super Member
    • Total Posts : 213
    • Reward points : 0
    • Joined: 2005/01/22 07:57:44
    • Location: Germany
    • Status: offline
    Re: Temperature sensor library and EEPROM in MCC 2018/07/11 00:13:07 (permalink)
    0
    Hi Mysil,
     
    thanks a lot for your help. I am getting closer after days stagnation.
     
    The QUEUE_FULL issue seems to be a dependence with my application. I've ported my hardware configuration and the relevant EEPROM code to your example and the reading/writing works fine now.
      
     
    Best regards,
    DW
     
    post edited by Wieschebrock - 2018/07/11 01:28:45
    #17
    Wieschebrock
    Super Member
    • Total Posts : 213
    • Reward points : 0
    • Joined: 2005/01/22 07:57:44
    • Location: Germany
    • Status: offline
    Re: Temperature sensor library and EEPROM in MCC 2018/09/04 02:41:37 (permalink)
    0
    Hi Mysil,
    just a feedback:
     
    Sometimes I got a EEPROM_I2C_MESSAGE_FAIL with your code, when reading from EEPROM (after a write).
     I had to add a delay in all cases, after incrementing:   I2C_EEPROM_SequentialWrite(...),


    if (retryCount == I2C_EEPROM_GENERIC_RETRY_MAX)
        return EEPROM_I2C_MESSAGE_FAIL;
    else{
        retryCount++;
        __delay_ms(1);
    }

     
    #18
    Wieschebrock
    Super Member
    • Total Posts : 213
    • Reward points : 0
    • Joined: 2005/01/22 07:57:44
    • Location: Germany
    • Status: offline
    Re: Temperature sensor library and EEPROM in MCC 2019/01/24 05:01:38 (permalink)
    0
    Hi Mysil, 
    all the read/write functions have a uint8_t parameter for the transfer length.
    Do you know why it is limited to maximum 255 bytes? 
     
     
     
    #19
    Mysil
    Super Member
    • Total Posts : 3486
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: online
    Re: Temperature sensor library and EEPROM in MCC 2019/01/24 09:32:22 (permalink)
    0
    Hi,
    The size argument is declared to be   uint8_t   type, which is a 8 bit value.
    then the argument may not represent any value larger than 255.
    The range from 0 thru 255, both ends inclusive, is 256 different values.
     
    EEPROM devices with I2C interface have a page size limitation which is typically smaller than 256, and different for device type. 
    Since transfer on the actual I2C bus must be broken down to page size chunks anyway, at least for writing,
    I cannot see a problem with changing the declaration of size argument, to a larger type,
    and test it.
    Check that internal variables in I2C_EEPROM_SequentialWrite(...);  have corresponding size declarations.
     
    In  I2C_EEPROM_SequentialRead(...); the entire transfer is performed by a single transfer, 
    so must test the entire driver, what size transfer can be performed,
    or introduce a loop, similar to the write routine.
     
    Transferring large records thru I2C will take a lot of time, especially for writing EEPROM.
    Even if the I2C driver itself operate in Non-Blocking mode,
    code in   i2c_eeprom_app.c   will wait until the transfer is complete.
    Depending on application requirements, this may be acceptable, or not. 
    It would be possible to introduce a non-blocking transfer service.
    This may be done by a polled transfer engine, a timed service loop, a timer interrupt service, or a callback service activated when I2C transfer is complete.
    Any of this will need some more complicated code,
    and read data will not be available until the transfer is completed anyway.
     
        Mysil
     
     
    post edited by Mysil - 2019/01/24 09:35:29
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5