int64 with PIC18F87J50

[ntrungtruc2003]

Dear Sir.

I have a problem when read dig_H4 in BME280 sensor
dig_4 return 29 = 11101
but the value true must be 285
0xE4 = 17 10001
0xE5= 13 1101

285 = 1001 1101 = 0XE4*16 + 0xE5
29 = 11101 = 0xE4 + 0xE5

BMEReadDig_H4 like this
unsigned int16 dig_H4;

[Ttelmah]

As a comment, it is pointless doing repeated byte reads of these registers. The whole point is that if you read one register, the internal counter increments and a second read without re-addressing will then read the next register. Far better to read the whole block of calibration registers in one operation.

Then you are misunderstanding how the registers have to combined.

The value needs to be put into a signed int16, with the top register rotated left by 4, and only the four bottom bits of the second register used.

So:

[ntrungtruc2003]

Dear Sir

The sensor works well with temperature and humidity, but with pressure's value i have a problem.

The pressure's value return is about 1646, it is greater than 1002 (1002 hpa is the true value).
All of dig_P is correct.

[Gabriel]

I'm having problems with the Humidity value (i don't trust it at least)..... but i got the pressure spot on....

I'll load up my driver later today and we can possibly make a viable driver merging code.

G.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[Ttelmah]

The most likely problem is the one I already pointed out about sign extending on the shifts.

Don't use the default shifts on the signed values.

K&R is quite specific that a shift on a signed number is 'implementation specific'. It is _not_ something that can be moved between processors reliably....
This is also stated in the ANSI C specifications as well.

It just happens that on the most common processors today, when dealing with signed numbers, most perform arithmetic shifts.

Replace the shifts yourself. Safest is to generate a macro to do the shifts:

[Gabriel]

[Gabriel]

I am almost certain my problem is with DIG_H4 and DIG_H5.
I agree with Ttelmah that the shifts may be responsible for the errors.


Please note this is most definitely trial an error code with a lot of "ill fix that once i get it working" - like int functions that i have voided etc... none existant return paths... and the likes...
_________________
CCS PCM 5.078 & CCS PCH 5.093

[ntrungtruc2003]

Thanks all of you so much

Thanks to Gabriel for your pressure calculating code.
BME280.c

All of sensors in BME280 work perfect for me.
PIC16F887
I2c software
D0------ SCL
D1------SDA
PIC16F

[viki2000]

I have tested the above code for BME280 and in my case works with a small problem.
I need your advices to track down the problem.

In my setup I use PIC16F1829 with internal clock instead of the PIC16f877A.
I sent the data to a small LCD 2x8 using flex_lcd driver.
I force the hardware communication for I2C instead of software.
I am interested only on temperature and humidity.
My BME280 sensor has the address 76 (EC) instead of 77 (EE) – that I have tested with Arduino Uno, when I tested the sensor first time and works fine.
The data shown on LCD is meaningful info compared with Arduino Uno code and setup and it seems that the setup with PIC16F1829 and above code works.
What is my actual problem?
In the main subroutine, in the while(1) loop I must include “BME280Begin();”.
If the “BME280Begin();” is outside of the while(1), before of it, then it reads the sensor data only once at start-up and shows the same value all the time. But that is not normal, it is supposed to do the “BME280Begin();” only once before while(1) loop and not all the time.
Maybe I mixed up or forgot to change an address related with I2C or sensor, I do not know what is it.
Can you help to track down this problem?
Why in my case I have to do the “BME280Begin();” always?
What did I miss to change when I ported to code to PIC16F1829 and sensor address 76 instead of 77?

Here is the code that I have used:

[temtronic]

you should run the I2C Scanner program that PCM P posted in the code library. it will find your sensors true address.

[Ttelmah]

You need also to understand I2C addresses.....

The address occupies the top 7 bits of the byte sent to the sensor. The eighth bit is the read/write bit (1/0). A device that is at address 0x76, will need to be sent 0x77 to read, and 0x76 to write....

[viki2000]

@ temtronic
But I have used the I2C Scanner with Ardunio setup environment and I know the address is 0x76, besides that the code works except repeat begin initialization.

@ Ttelmah
In the library code for BME280 here above, similar as in Arduino library, the address 0x77 is transformed into 0xEE and the address 0x76 is transformed into 0xEC. The initial code is written like that. No where appears 0x77 or 0x76, but the corresponding 0xEE or 0xEC. I see no problem here.

[Ttelmah]

The Arduino library is using the 7 bit address. The top seven bits of the address byte. This was the old 'Texas' standard but is used by almost nobody else.
The CCS code uses the 8bit address. 7bit address *2. The code then adds the read/write bit as needed. This is how most manufacturers address their chips.
A device with an Arduino address of 0x77, will need 0xEE for the PIC code, and will physically be at addresses 0xEE and 0xEF.
You have 'waffled' far too much in your post which is why Temtronic and I both thought you were having trouble addressing the chip.

You post could be summarised as:
"Using this library (point to the thread, don't repost the whole library).
Chip works, but requires me to use BME280Begin() every time I want to send a reading. Without this I only get the first reading."

The reason you are having to send 'begin', is that you are programming the chip to 'forced mode', in which it goes back to sleep after a single reading. The Begin code as well as reprogramming all the registers triggers a single conversion.
You can just trigger a single conversion by writing the CTRL_MEAS register. Alternatively change the settings to use 'normal mode'.

[viki2000]

I am sorry that I have 'waffled' far too much in my initial post and I created confusion.
I always thought that providing more info is always better than providing less, even if there is the risk that people do not read it because takes too much time.
Probably it would have been far better to summarize it as you did, but we do not all think and speak the same way.
Besides that, because I mentioned that I am able to read the BME280 parameters, that means automatically that I2C works fine and there is no problem with the address. That’s why your explanations with 7bit vs. 8bit make sense also for me because 0x76*2=0xEC and the following for read is 0xEC|0x01=0xED and these 2 addresses 0xEC and 0xED I have used in my code above.
I have posted the entire long code to see where I have done the modifications and maybe someone might say: hey, you forgot to change it there or there, at least this is what I had in mind to that moment. In top of that, for future users, is good to have full working code that is downloadable and applies without modification, just for a quick test without headaches. I thought a another PIC and another address for BME280 will diversify the options for other users, which is a good thing. Besides that many times when a question is asked, the people that are willing to help and answer ask almost always about the code used and in this case there are some places in the given code that must be modified in order to be adapted to the new PIC and new BME280. So I think is not a big deal that I posted the question in the way as I have done it.

Now, regarding your suggestions with “forced mode” and sleep and that I should change to “normal mode” or play with CTRL_MEAS register, they make logical sense to me at the first read, but I have some doubts when I think twice and here is why.
I suppose the initial provided code works fine.
If you look at the main subroutine, the “BME280Begin();” is called only once before the continuous “while(true)” and in that “while(true)” loop the reading of temperature and humidity is called regularly each approx. 1s and is then printed regularly.
It makes no sense to print regularly the temperature and humidity and other parameters, if it is not updated regularly with new data.
If what you say would be true, then it would be true also for initial code and here I have the doubts, because I suppose is working fine, of course not tested yet by me with PIC16F877A and BME280 address 0x77.
I think the “force mode” with sleeping is important, because consumes low current, which is good for portable application (nice explained here http://tinkerman.cat/low-power-weather-station-bme280-moteino/ ). I would like to maintain that low current state with sleeping and “forced trigger”.
But I also think the problem is somewhere else, why does not trigger a new reading. I have to look more into the code. Any other suggestions are appreciated.

[Ttelmah]

Big difference. Time.

The chip goes to sleep if it is not read for 250mSec. You delay 800mSec in your loop. The original code does not...

You have to simply trigger a reading. A read does not.