 |
 |
| View previous topic :: View next topic |
| Author |
Message |
towpew
Joined: 25 Sep 2015
Posts: 24
Location: sweden
|
|
 Posted: Sun Jan 03, 2021 1:34 pm |
 |
|
| Ttelmah wrote: | | What are your pull up resistor values?. |
They are on the sensor board and is 4K7. I have also other boards with 10K.
Both works on the PIC18 version.
I have noticed so far 1 difference with the init setup that are sent to the bme280 chip at start and there are 2 regs that differ.
0xF4 and 0xF5 ctrlMeas.val and crtl_config.val
On PIC18 F4 is 24 and F5 is 40
On PIC24 F4 is 3C and F5 is 70
Strange that they can differ on same BME board.
Not sure yet if that values are OK, must check datasheet.
I will investigate further tomorrow.
// |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9243
Location: Greensville,Ontario
|
|
| Posted: Sun Jan 03, 2021 5:54 pm |
|
|
While I don't use those PICs or the sensor I have to ask why the difference in the 'init setup' ? That should not be PIC dependent, the driver for the sensor should be the same and it's the same sensor.....
Say we (PIC18 and PIC24) are at the front door, one doorbell push button (driver) and the actual doorbell. It doesn't matter WHO presses the button, the doorbell rings.
One thing occurs to me though....are PIC24 default defines for variable types different than PIC18s ? 'int' in a PIC18 is 8 bit, for a PIC24 it might be 16 ? or ...'int' in PIC18 is UNsigned while PIC24 it's signed ?? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Mon Jan 04, 2021 2:45 am |
|
|
Those resistors are too large.
4K7, is an 'OK' resistor for a 5V I2C bus, going just to a local device. So
ideal for example to connect to a clock chip or something similar, on a 5v
PIC. The resistor sizes have to drop when the supply voltage drops. So on a
3.3v PIC, the equivalent to 4K7, is 3K1R. However for reliable operation with
a 'fast' bus, and especially if the bus gets longer, the resistor value needs to
drop further.
!0K is not rated to work with a fast mode bus at all on 3.3v.
Now the reason I jumped onto this, is the PIC24, has a very slightly higher
Vih than the PIC18. As such it'll show problems with Rp not being small
enough quicker than the PIC18.....
Rp(min), for a 3.3v bus running standard I2C drives, is just 900R.
Halve your resistor values. |
|
|
towpew
Joined: 25 Sep 2015
Posts: 24
Location: sweden
|
|
| Posted: Mon Jan 04, 2021 7:19 am |
|
|
| Ttelmah wrote: | Those resistors are too large.
4K7, is an 'OK' resistor for a 5V I2C bus, going just to a local device. So
ideal for example to connect to a clock chip or something similar, on a 5v
PIC. The resistor sizes have to drop when the supply voltage drops. So on a
3.3v PIC, the equivalent to 4K7, is 3K1R. However for reliable operation with
a 'fast' bus, and especially if the bus gets longer, the resistor value needs to
drop further.
!0K is not rated to work with a fast mode bus at all on 3.3v.
Now the reason I jumped onto this, is the PIC24, has a very slightly higher
Vih than the PIC18. As such it'll show problems with Rp not being small
enough quicker than the PIC18.....
Rp(min), for a 3.3v bus running standard I2C drives, is just 900R.
Halve your resistor values. |
I have now changed Pullup to 1K8 but no change.
Howe ever I have done some debug output compare and find a strange value maybe temtronic is on something right ??
The compensation value for pressure , and Pressure is the value i have had most problem with is on negeative value on PIC24 and positive on PIC18
DEBUG OUTPUT
PIC24
_bme280_compensate_P_int32(-524288) 10190
PIC18
_bme280_compensate_P_int32(305648) 101931
You can se that compensate value is negative and the last number is 1 digit short on PIC24
this debug output is from the same BME280 chip so it should be nearly equal
i think.
I cannot post the driver here but, it is mention in the driver that this
_bme280_compensate_P_int32 is written by BOSH from their datasheet.
Can someone who has this latest driver take a look into this function
I have try to change some variables to unsigned but all I got gives an
compile error. lots of Expecting declaration and parentheses error.
Update !
I noticed an even more error on the compensation calculation
the compensation is recalculate for every reading that's why I can get error data when some variables change. here I rise the humidity and temp
all data crash it is the comp_t that holds variables that goes wild
_comp_t -61547 0 -123763 -6188150
_bme280_compensate_T_int32(-523636) 9246 473412 473789 -377
_bme280_compensate_P_int32(-524288) 12347
right before I rised humidity and temp comp_t was all positive values
_comp_t 3790 0 3506 175300
_bme280_compensate_T_int32(521767) 1953 99974 99964 10
_bme280_compensate_P_int32(-524288) 10201
_bme280_compensate_H_int32(30087) 46547
 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Mon Jan 04, 2021 7:57 am |
|
|
There is a critical thing.
You need to make a point of using unsigned on the PIC24.
On PIC12/16/18, the default 'int', is a unsigned int8. In the PIC24/33, it is a
signed int16. Now this affects all integer types. So an 'int32' on the PIC24,
is a signed int32. If you look at my driver for the SSD1306 in the code library,
you will see that this was modified for the PIC24. The critical thing that
had to change was the int8's had to be changed to be unsigned int8's.
Since switching to the PIC24/33's I've made it a 'point' to use the stdint
include library, and use uint8_t, etc., for types. It is worth doing this on all
code, since it increases enormously the portability to other compilers. |
|
|
towpew
Joined: 25 Sep 2015
Posts: 24
Location: sweden
|
|
| Posted: Mon Jan 04, 2021 10:13 am |
|
|
| Ttelmah wrote: | There is a critical thing.
You need to make a point of using unsigned on the PIC24.
On PIC12/16/18, the default 'int', is a unsigned int8. In the PIC24/33, it is a
signed int16. Now this affects all integer types. So an 'int32' on the PIC24,
is a signed int32. If you look at my driver for the SSD1306 in the code library,
you will see that this was modified for the PIC24. The critical thing that
had to change was the int8's had to be changed to be unsigned int8's.
Since switching to the PIC24/33's I've made it a 'point' to use the stdint
include library, and use uint8_t, etc., for types. It is worth doing this on all
code, since it increases enormously the portability to other compilers. |
Ok
There are only 32 bits signed and unsigned in the function we talk about
other places with int8 in the driver is already set to unsigned int8 or signed
all variables seem to have unsigned or signed stated already by CCS
Do you think that the driver is the problem for PIC24
//PW |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Mon Jan 04, 2021 11:25 am |
|
|
No, the driver is recent enough that it was almost certainly written to support
the 16bt PIC's as well. There is nothing in it that looks as if it'd cause issues
on these chips.
Post what you are actually calling to get the 'transactions' you have posted. |
|
|
towpew
Joined: 25 Sep 2015
Posts: 24
Location: sweden
|
|
| Posted: Mon Jan 04, 2021 11:40 am |
|
|
| Ttelmah wrote: | No, the driver is recent enough that it was almost certainly written to support
the 16bt PIC's as well. There is nothing in it that looks as if it'd cause issues
on these chips.
Post what you are actually calling to get the 'transactions' you have posted. |
it´s nearly the same as in the driver example
shrinked for test purpose
I2C is setup in the driver with pin_select and stream
| Code: |
#include <24FJ256GB406.h>
#device ICSP=1
#device ADC=10
#use delay(internal=8000000) //
#FUSES NOWDT //No Watch Dog Timer
#FUSES NOJTAG //JTAG disabled
#FUSES CKSFSM //Clock Switching is enabled, fail Safe clock monitor is enabled
#FUSES FRC
#pin_select U3TX=PIN_D4
#pin_select U3RX=PIN_D5
#use rs232(UART3, baud=19200, stream=DEBUG) //DEBUG
//#define debug_bme280 printf
//#define debug2_bme280 printf
void debug_putc(char c)
{
fputc(c, DEBUG);
}
#include "bme280.c"
unsigned int32 press;
signed int32 temp;
unsigned int32 hum;
int1 ok = 0;
void initbme280()
{
ok = bme280_init();
bme280_set_mode(BM280_MODE_NORMAL);
delay_ms(1000);
if(!ok)
{
debug << "error init" << endl;
}
else
{
debug << "Ok init" << endl;
}
}
void readinbme280()
{
output_toggle(PIN_G9);
ok = bme280_get_humidity(&temp, &press, &hum);
if(!ok)
{
debug << "error reading" << endl;
}
else
{
// debug << "Ok Read" << endl;
}
debug << press << " " << temp << " " << hum << endl;
}
void main()
{
initbme280();
delay_ms(1000);
do {
readinbme280();
delay_ms(1000);
debug << endl;
}
while(1);
}
|
I will test the driver soon on a dsPIC30F4011 |
|
|
towpew
Joined: 25 Sep 2015
Posts: 24
Location: sweden
|
| Tested on dsPIC30F4011 now |
| Posted: Mon Jan 04, 2021 12:55 pm |
|
|
Tested on dsPIC30F4011 now with the same error
DEBUG data
bme280_get_humidity() 80 0 0 81 17 A0 77 68
_comp_t -61010 0 -139830 -6991500
_bme280_compensate_T_int32(-519814) 9410 481807 482233 -426
_bme280_compensate_P_int32(-524288) 11446
_bme280_compensate_H_int32(30568) 45437
114 94 44
Pres Temp Hum
| Code: |
#include <30F4011.h>
#device ICSP=1
#use delay(internal=7373000)
#FUSES NOWDT //No Watch Dog Timer
#FUSES CKSFSM //Clock Switching is enabled, fail Safe clock monitor is enabled
#FUSES NOBROWNOUT //No brownout reset
#use rs232(UART2, baud=19200, stream=DEBUG)
#include <main.h>
#include <ios.h>
#define debug_bme280 printf
//#define debug2_bme280 printf
void debug_putc(char c)
{
fputc(c, DEBUG);
}
#include "bme280.c"
signed int32 temp;
unsigned int32 press;
unsigned int32 hum;
int1 ok;
void main()
{
debug << "starting 4011 MCU" << endl;
ok = bme280_init();
if(ok == 1)
{
DEBUG << " Success Init BME280" << endl;
}
else
DEBUG << " No BME280 found " << endl;
delay_ms(1000);
bme280_set_mode(BM280_MODE_NORMAL);
if(bme280_ok() == 1)
{
DEBUG << " Ok communicate BME280" << endl;
}
else
DEBUG << " Error communicate to BME280" << endl;
delay_ms(1000);
while(TRUE)
{
output_toggle(PIN_F0);
ok = bme280_get_humidity(&temp, &press, &hum);
if (!ok)
DEBUG << "Error reading BME280 sensor!" << endl;
delay_ms(1500);
temp = temp / 100;
press = press / 100;
hum = hum / 1024;
DEBUG << press << " " << temp << " " << hum << endl;
}
}
|
Same code as above works perfectly on PIC18LF2550 |
|
|
towpew
Joined: 25 Sep 2015
Posts: 24
Location: sweden
|
|
| Posted: Mon Jan 04, 2021 2:05 pm |
|
|
I am on to this now with CCS
BR
PW |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Jan 04, 2021 2:53 pm |
|
|
Here is a test program for the signed/unsigned problem. The code below
has a routine from bme280.c that has 'char' in it. If I compile and run
the test program for PCH, I get this result:
Test program for PCH:
| Code: | #include <18F46K22.h>
#fuses NOWDT
#use delay(internal=4M)
#use rs232(UART1, baud=9600, ERRORS)
static unsigned int32 _bme280_get20bits(char *p)
{
unsigned int32 ret = 0;
char c;
ret += *p++;
ret *= 256;
ret += *p++;
ret *= 16;
c = *p;
c >>= 4;
c &= 0xF;
ret += c;
return(ret);
}
unsigned int8 read[8] = {0x80, 0x00, 0x00, 0x81, 0x17, 0xA0, 0x77, 0x68};
//=================================
void main()
{
unsigned int32 scr32;
scr32 = _bme280_get20bits(&read[3]);
printf("scr32 = %lu \r", scr32);
while(TRUE);
}
|
I don't have PCD but I can emulate its 'char' data type by putting
'signed' in front of 'char', as shown in bold in the test program below.
Then I get this result:
| Quote: | scr32 = 4294447482
|
Test program emulates PCD's signed char data type:
| Quote: | #include <18F46K22.h>
#fuses NOWDT
#use delay(internal=4M)
#use rs232(UART1, baud=9600, ERRORS)
static unsigned int32 _bme280_get20bits(signed char *p)
{
unsigned int32 ret = 0;
signed char c;
ret += *p++;
ret *= 256;
ret += *p++;
ret *= 16;
c = *p;
c >>= 4;
c &= 0xF;
ret += c;
return(ret);
}
unsigned int8 read[8] = {0x80, 0x00, 0x00, 0x81, 0x17, 0xA0, 0x77, 0x68};
//=================================
void main()
{
unsigned int32 scr32;
scr32 = _bme280_get20bits(&read[3]);
printf("scr32 = %lu \r", scr32);
while(TRUE);
}
|
To make the program run the same way in PCD as it does in PCH, add
'unsigned' in front of the declarations of both 'char' variables in that routine.
Example:
| Quote: |
static unsigned int32 _bme280_get20bits(unsigned char *p)
{
unsigned int32 ret = 0;
unsigned char c;
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Tue Jan 05, 2021 4:43 am |
|
|
Personally I'd just change all references to 'char' to 'byte'. I've found this
to be the simplest thing. Only use 'char'' for things that are text. For all
things that want a 8bit integer and to work the same on PCB/PCM/PCH/PCD,
the byte data type is the easiest thing to use.  |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9243
Location: Greensville,Ontario
|
|
| Posted: Tue Jan 05, 2021 6:36 am |
|
|
Sigh, this variable 'type' problem that spans different PIC families reminds me of coding in FORTRAN a long, long time ago. Back then I learned real quick to define / assign 'integer' to variables beginning with 'I' to 'N'.
I think the 'problem' is that CCS doesn't have a common standard for what variable types are and you can change the 'default' as well ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19539
|
|
| Posted: Tue Jan 05, 2021 7:15 am |
|
|
That flexibility is inherent in C. Not really a CCS problem.
However (of course), it is 'tightened up' somewhat if you use the ANSII
directive. Char though is the one type where this still remains. ANSII
C allows the char type to be signed or unsigned. Intel based C's have
the char as signed, while the ARM processors have it as unsigned.
The page below is very right, saying that you should always explicitly use
signed or unsigned to ensure predictable results:
https://wiki.sei.cmu.edu/confluence/display/c/INT07-C.+Use+only+explicitly+signed+or+unsigned+char+type+for+numeric+values |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9243
Location: Greensville,Ontario
|
|
| Posted: Tue Jan 05, 2021 10:40 am |
|
|
and here I thought computers were supposed to be logical..
dbl sigh... |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
