Two Issues with PICbasic's Efficiency


Closed Thread
Results 1 to 12 of 12
  1. #1
    Join Date
    May 2009
    Posts
    21

    Default Two Issues with PICbasic's Efficiency

    I've been trying to build a vibration sensor with the PIC16F877. The sensor essentially has an tri-axis digital accelerometer using I2C or SPI, an serial EEPROM. The program works for fine for reading the accelerometer data and saving them into the EEPROM. So the most frequeny commands is I2CRead and I2CWrite. My problems is:

    1. The sampling rate is two low...only around 100Hz, with reading three axis's data(six bytes), and saving them into the EEPROM with the time(two bytes), the cycle nearly takes 10ms..., I know EEPROM needs around 3~4ms for each writing cycle, so the best, is getting close to 200Hz at least.. So what I was wondering why these I2CReads and I2Cwrites should take such a long time? Where I could find room for Bandwidth improvement if still using EEPROM?


    Sen_Re:
    PORTB=$FF

    while stop_f=0

    I2CREAD DPIN,CPIN,SAD_W,XOUT_H,[X.BYTE1] ' Read Sensor's Register
    I2CREAD DPIN,CPIN,SAD_W,XOUT_l,[X.BYTE0]
    I2CREAD DPIN,CPIN,SAD_W,YOUT_H,[Y.BYTE1]
    I2CREAD DPIN,CPIN,SAD_W,YOUT_L,[Y.BYTE0]
    I2CREAD DPIN,CPIN,SAD_W,ZOUT_H,[Z.BYTE1]
    I2CREAD DPIN,CPIN,SAD_W,ZOUT_L,[Z.BYTE0]


    IF X_F || Y_F || Z_F THEN ' If one channel overflows threshold value
    HIGH LED4 ' Flash LED4 for illustration
    GOSUB SAVE
    if add>64000 then stop_f=1

    wend

    return




    SAVE: ' Save data to a 8bytes array
    pointer=0
    BUFF2[POINTER]=X.BYTE1
    POINTER=POINTER+1
    BUFF2[POINTER]=X.BYTE0
    POINTER=POINTER+1
    BUFF2[POINTER]=Y.BYTE1
    POINTER=POINTER+1
    BUFF2[POINTER]=Y.BYTE0
    POINTER=POINTER+1
    BUFF2[POINTER]=Z.BYTE1
    POINTER=POINTER+1
    BUFF2[POINTER]=Z.BYTE0
    POINTER=POINTER+1
    BUFF2[POINTER]=MINUTE
    POINTER=POINTER+1
    BUFF2[POINTER]=SECOND
    I2CWRITE DPIN,CPIN,CON_B,ADD,[STR buff2\8] ' Write to EEPROM
    add=add+8
    RETURN

    2. The second questions is: How to provide the system with a clock includes a precision to 1/100 second. Using the timer interrupt will generate much error, but most RTC chips only provide best to the second, so how to build a clock, also without using much physical room? I mean on circuit board(Because I am trying to shrink PCB's size)?


    You comments and suggestions are greatly appreciated!!!!

  2. #2
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    Just thoughts...
    Can you do one I2CREAD in place of six or at least narrow it down to three?
    Code:
    I2CREAD DPIN,CPIN,SAD_W,ZOUT_H,[Z.BYTE1]
    I2CREAD DPIN,CPIN,SAD_W,ZOUT_L,[Z.BYTE0]
    becomes
    Code:
    I2CREAD DPIN,CPIN,SAD_W,ZOUT_H,[Z.BYTE1,Z.BYTE0]
    For the time thing you may want to look at this:
    http://www.picbasic.co.uk/forum/showthread.php?t=190
    and
    http://www.picbasic.co.uk/forum/showthread.php?t=3251

    Yep, they are interrupt based but...
    Dave
    Always wear safety glasses while programming.

  3. #3
    Join Date
    May 2009
    Posts
    21


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by mackrackit View Post
    Just thoughts...
    Can you do one I2CREAD in place of six or at least narrow it down to three?
    Code:
    I2CREAD DPIN,CPIN,SAD_W,ZOUT_H,[Z.BYTE1]
    I2CREAD DPIN,CPIN,SAD_W,ZOUT_L,[Z.BYTE0]
    becomes
    Code:
    I2CREAD DPIN,CPIN,SAD_W,ZOUT_H,[Z.BYTE1,Z.BYTE0]
    For the time thing you may want to look at this:
    http://www.picbasic.co.uk/forum/showthread.php?t=190
    and
    http://www.picbasic.co.uk/forum/showthread.php?t=3251

    Yep, they are interrupt based but...

    First, thanks a lot for your reply. While, it does work if I reduce the I2CRead commands. So, do you think it could be better, if I use assembly codes to perform the I2CReads and I2Cwrites? What am I wondering is whether the I2C commands themselves are taking too much time.

    The second part, I plan to use an RTC chip includes milisecond, you know, more hardware could enlarge the circuit a little bit....

  4. #4
    Join Date
    May 2004
    Location
    NW France
    Posts
    3,611


    Did you find this post helpful? Yes | No

    Talking the "Ferrari" with a Citroen 2CV engine ... ( Swiss speciality ...)

    Hi,

    Did you ever heard about FRAM memory ???

    FM25L256 ( ramtron )


    Or else, M25P32 from ST ...

    Surely NOT !!!

    Alain
    ************************************************** ***********************
    Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
    ************************************************** ***********************
    IF there is the word "Problem" in your question ...
    certainly the answer is " RTFM " or " RTFDataSheet " !!!
    *****************************************

  5. #5
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    I am not sure if doing the I2C in ASM will help much. PBP for the most part is pretty efficient, It just takes a lot of bit shifting to do I2C no matter what. Take a look at the ASM generated by PBP and see what you think.

    In your case I am thinking the fewer the I2C reads and writes no matter what language will be key. And that brings up adding the RTC... More I2C???

    Another thought.
    If the system has a few seconds of dead time now and then have more than on array to save the data in from the sensor. When ever there is time to spare write the oldest array to EEPROM and keep going. Kind of a home made interrupt.

    And like Alan Said about FRAM. Could be what you need.
    Dave
    Always wear safety glasses while programming.

  6. #6
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    It is a feature of SERIAL EEPROM like the internal PIC EEPROM or external EEPROM (like the 24LC64 and similar etc) that require (up to) 10mS for a WRITE operation (consult the Datasheet of the EEPROM you are using for the actual timing). All the worlds fastest Assembly routines will not help you. You must use a faster hardware product like Alain suggested.

  7. #7
    Join Date
    Oct 2004
    Posts
    440


    Did you find this post helpful? Yes | No

    Default

    Or else, M25P32 from ST ...
    I believe ST sold the M25P line to Numonyx and the line has been upgraded to the faster M25PE... series.
    See the M25PE80 for a sample data sheet.
    It's rated at writing 256 bytes in 11 ms.
    For M25P code example see M25P32 (warning other compiler).

    A full 256 byte per write is probably required however.
    Since only erase can convert 0 to 1's overwriting previous of new and following of new bytes with 1's can simulate a one byte write.
    Perhaps a low priority interrupt could do the 256 byte write in the background.


    Norm

  8. #8
    Join Date
    Oct 2004
    Posts
    440


    Did you find this post helpful? Yes | No

    Default

    M25PE80... The memory can be written or programmed 1 to 256 bytes at a time.
    Improved over old M25P series?
    I found with the previous M25P series after many 1 byte writes errors crept
    in thus a full 256 byte sector write was used.

    Norm

  9. #9
    Join Date
    May 2009
    Posts
    21


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Acetronics View Post
    Hi,

    Did you ever heard about FRAM memory ???

    FM25L256 ( ramtron )


    Or else, M25P32 from ST ...

    Surely NOT !!!

    Alain
    Thanks a lot!
    It has been long since my visit of this site here. Year, pretty much the chips you provided could solve the speed issue, also with a smaller package!
    I

  10. #10
    Join Date
    May 2009
    Posts
    21


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by mackrackit View Post
    I am not sure if doing the I2C in ASM will help much. PBP for the most part is pretty efficient, It just takes a lot of bit shifting to do I2C no matter what. Take a look at the ASM generated by PBP and see what you think.

    In your case I am thinking the fewer the I2C reads and writes no matter what language will be key. And that brings up adding the RTC... More I2C???

    Another thought.
    If the system has a few seconds of dead time now and then have more than on array to save the data in from the sensor. When ever there is time to spare write the oldest array to EEPROM and keep going. Kind of a home made interrupt.

    And like Alan Said about FRAM. Could be what you need.
    Yes, Alian is right and hardware is the core constrain. I did some revise for the previous codes like reading the accelerometer(six bytes register for three axes) in one I2C read, and the same pracitice for I2C write. The final speed improved to about 150Hz, and then later I started to work on something else for a long time... I think it is my time to crack this trick and will see what's the maximum I will get later. Thanks a lot!~

  11. #11
    Join Date
    May 2009
    Posts
    21


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Melanie View Post
    It is a feature of SERIAL EEPROM like the internal PIC EEPROM or external EEPROM (like the 24LC64 and similar etc) that require (up to) 10mS for a WRITE operation (consult the Datasheet of the EEPROM you are using for the actual timing). All the worlds fastest Assembly routines will not help you. You must use a faster hardware product like Alain suggested.
    Sounds good. The EEPROMs require a 5ms wirting circle typically from Microchips. While it can be reduced to about 3ms as I tried.

  12. #12
    Join Date
    May 2009
    Posts
    21


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Normnet View Post
    Improved over old M25P series?
    I found with the previous M25P series after many 1 byte writes errors crept
    in thus a full 256 byte sector write was used.

    Norm
    Thanks Norm the your suggestions and the sample codes. IN the manual it sounds like 1~256 is a flexiable range that can be written. Any way I will try it out later.

Similar Threads

  1. SERIN2 buffer issues...
    By cpayne in forum mel PIC BASIC Pro
    Replies: 9
    Last Post: - 16th October 2008, 04:49
  2. Solved: notes on annoying little issues
    By Probotics in forum mel PIC BASIC Pro
    Replies: 6
    Last Post: - 26th May 2008, 21:02
  3. Where should I discuss SD/MMC FAT issues?
    By JD123 in forum General
    Replies: 92
    Last Post: - 2nd April 2008, 22:41
  4. I2C Master Slave issues.
    By cpayne in forum mel PIC BASIC Pro
    Replies: 9
    Last Post: - 29th March 2008, 20:33
  5. Circuit reliability issues
    By hkpatrice in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 23rd November 2007, 15:55

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts