Two Issues with PICbasic's Efficiency

Printable View

- 12th October 2009, 06:21
hankshone

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?

Quote:

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!!!!
- 12th October 2009, 06:49
mackrackit

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...
- 13th October 2009, 14:44
hankshone

Quote:

Originally Posted by mackrackit

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....
- 13th October 2009, 17:04
Acetronics2

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
- 13th October 2009, 17:15
mackrackit

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.
- 13th October 2009, 19:03
Melanie

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.
- 14th October 2009, 04:10
Normnet

Quote:

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
- 14th October 2009, 04:49
Normnet

Quote:

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
- 21st December 2009, 23:02
hankshone

Quote:

Originally Posted by Acetronics

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
- 21st December 2009, 23:07
hankshone

Quote:

Originally Posted by mackrackit

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!~
- 21st December 2009, 23:09
hankshone

Quote:

Originally Posted by Melanie

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.
- 21st December 2009, 23:11
hankshone

Quote:

Originally Posted by Normnet

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.