Picaxe programing

Rickg1

New Member
Please forgive an old man but please explain again how x77 ( for an bme280) is $ec in code examples here on the forum. I using i2c to talk to a bme280 . Address is 77. What is the conversion process when writing code for a picaxe . No matter what I use for i2c setup I get all o's back. I only want to get ruff reading from the chip ( no math routines needed )
Thanks to anyone who can answer this.
 

AllyCat

Senior Member
Hi,

The I2C Bus uses a 7-bit Address, with a Read / Write bit added to complete an 8-bit byte. For convenient programming (e.g. using INC / DEC instructions) the R/W bit is the Least Significant Bit (i.e. a value/weight of "1") so all the Address bits must be multiplied by 2. PICaxe Basic automatically sets (or clears) the R/W bit, so the user/programmer should always set the LSB to zero, but the "7-bit Address" must still be multiplied by 2. Therefore, if the I2C address is "officially" quoted as an ODD number, then it definitely needs to be multiplied by 2 for a PICaxe. The problem arises if the address is quoted as an even number, but less than 127 ($7F).

The 0x or $ prefixes are just different ways to indicate the "Hexadecimal" number system (base 16). The PICaxe Editor will accept either (and upper-case or lower-case letters), but the $ is generally preferred (at least by me :) ). Numbers presented without any prefix or suffix are usually assumed to be to base 10 ("decimal" or "denary") and of course there are other symbols to indicate binary (%) and Octal, etc..

However, $77 multiplied by 2 is $EE , not $EC The reason is that the BME280 can be arranged to use either address $EC or $EE, depending whether one of it's pins is connected to 0 or 1 (i.e. that pin selects the LSB of the Address). Thus you may need to examine the "Breakout" board (or just try both addresses ;) ).

BTW, It's more usual to read 255 ($FF) back from a Slave which isn't responding, so you may have something else that needs to be fixed (perhaps no pull-up resistors ? ).

Cheers, Alan.
 
Last edited:

Rickg1

New Member
Thank you so much Sir. Makes more sense now but I will still have to sleep on it to get it in my head. Thanks
 

Rickg1

New Member
Second thought, what about reading and writing to registers inside a chip or project? Is the hex value "true" or is it x2 like the address in i2c setup? If the data sheet reads address XX does hi2out or in become xx too?
 

AllyCat

Senior Member
Hi,

The PIC(axe) is basically an "8-bit Microcontroller" which means that nearly all "numbers" (including everything on the I2C Bus) can be represented by one of the 256 possible permutations of 8-bits (i.e. a Byte). However, those values can be represented in various ways, e.g. "0 to 255" (decimal), "%00000000 to %11111111" (8 binary digits) or "$00 to $FF" (Hexadecimal pairs), etc., whichever is more convenient for the user/programmer.

Hexadecimal (16 possible "symbols") is often the most useful because it needs only two symbols to specify all the possible Byte values, and is easy to convert/visualise as binary (4-bits) "nibbles". The Hex number sequence (with the $ prefixes omitted) is : 0 1 2 3 4 5 6 7 8 9 A B C D E F which is easy to double (multiply by 2) to : 0 2 4 6 8 A C E ...... (then 10 12 14, etc.) , so it is easy to see that doubling the address $77 becomes $EE (although doubling $78 to $F0 might not be quite as "obvious").

The I2C bus always works with bytes and in my view the Slave Address range is best considered as all of the "Even-Numbered Bytes only" (which are then incremented by 1 to signal a "Data Read"), but some Data Sheets (and the Ard***o) insist on "throwing away" the LSbit and calling it a 7-bit address (causing needless confusion). :( If in doubt, try to find the Slave Address specified in Binary representation (or maybe even a data/pulse waveform) which should look something like: % s t u v s t u r/w where s, t, u and v are Slave Address bits which have decimal "weights" of 8 , 4, 2 and 1 and r/w is the Read/Write Flag.

Cheers, Alan.
 

Rickg1

New Member
I seem to have my chip from SPARKFUN working? I get an ID of 96 instead of 60.
I use your code:

hi2csetup i2cmaster,$ee ,i2cslow, i2cbyte ; BMP180 address
pause 20
hi2cin $D0,(b0) ; read sensor id
sertxd(cr,lf,"BME280 ID= ",#b0,cr,lf)
Question does this line read 6 registers from F& to FC? hi2cin $F7,(b1,b0,b4,b3,b2,b5)? If this is true cant I dothis: hi2cin $F7,(b1,b0,b4,b3,b2,b5,b11,b10) to read temp,pres and hum?
I dont understand the "data" that Im getting back ( T=33088, P =20018, H=32768 )

Am I doing something wrong or do i have a bad chip from SPARKFUN? Any thoughts??
 

AllyCat

Senior Member
Hi,

The Chip ID is NOT "60" it is Hex: $60 which has a Decimal value of 96 (which #b0 sends). So that appears to be working correctly.

Yes, it looks as if that instruction will probably read registers $F7 to $FE into your list of Bytes, BUT:

1) You don't appear to have sent any instructions to initialise and instruct the BME280 to make any measurement(s).

2) The bytes returned represent two 24-bit numbers and a 16-bit number from the Analogue-Digital Converter(s). First they need to be "interpreted" as values that can be displayed within PICaxe's 16-bit (Word) system, and then they need to be calibrated, either by reference to "known" values, or by using the formulae in the BME280 data sheet.

A search of the forum will find a number of "BME Code Examples", particularly in the Code snippets section, by myself, marks and others, for example HERE. They should include examples of code to initialise the BME280 (and then the maths to calibrate the data values).

The actual 20-bit or 16-bit ADC values are as follows, but if you just want simple "numbers", you can ignore the "X-Low bytes" (B4 and B5) and work directly with the basic Word values (W0 , W1 and W5).

Pressure = W0 * 16 + (B4 / 16)
Temperature = W1 * 16 + (B5 / 16)
Humidity = W5

So the values for T and P might be correct (it's impossible to say until you calculate/calibrate the values) but the Humidity is "suspicious" because it's exactly 32768 or $8000 , which is the maximum negative value of a "signed" 16-bit word.

Your "problem" is that the BME280 is a particularly "complex" (or one might say "lazy") chip, which relies on an enormously complex calibration procedure, usually "hidden" inside an Arduino/C-code "Library" or "API" routine. There are far easier devices to use, particularly for Temperature and Humidity, such as the SHT30/31 or AHT21, etc..

Cheers, Alan.
 
Last edited:
Top