Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow using both bme280 addresses simultaneously #3124

Closed
wants to merge 77 commits into from

Conversation

heikomat
Copy link

@heikomat heikomat commented May 24, 2020

Fixes #2241

  • This PR is for the dev branch rather than for master.
  • This PR is compliant with the other contributing guidelines as well (if not, please describe why).
  • I have thoroughly tested my contribution.
  • The code changes are reflected in the documentation at docs/*.

This adds an optional use-alternate-address-parameter to all read-methods of the bme280
module.
if not set, the behaviour is unchanged and the first available device will be used.
If set to true, the device at address 0x77 will be used.

This module is also used for the nearly identical bmp280 (seems to be the same, but without the humidity sensor), and it has an internal flag for that.
I adjusted the code, so that it should work with a bme280 and bmp280 on the same bus, but i only own some bme280, no bmp280, so i couldn't test that.

I tested:

  • A single bme280 on address 0x76 without the new option
  • A single bme280 on address 0x77 without the new option
  • A single bme280 on address 0x77 with the new option
  • One bme280 on address 0x76 and one on address 0x77, with and without the new option

This is the code i used for testing:

i2c.setup(0, 7, 6, i2c.SLOW)
bme280.setup()

tmr.create():alarm(350 , tmr.ALARM_AUTO, function(timer)
  temp1, pressure1, humidity1 = bme280.read()
  temp2, pressure2, humidity2 = bme280.read(nil, true)
  print(temp1, temp2, pressure1, pressure2, humidity1, humidity2)
end)

TerryE and others added 30 commits July 23, 2019 19:16
Lua 5.1 to 5.3 realignement phase 1
The internal implementation already preferentially forwards to the
encoder module, so we should just remove these functions as they confuse
people into thinking that we don't have their inverses (see the feature
request nodemcu#2907).

Update the docs to refer to the encoder version and add deprecation
warnings to the runtime implementations.
* clean effects library
* Fix several issues in ws2812 and effects
* Implement working way of calling shift from callback
* Remove app/include/netif/wlan_lwip_if.h

This file appears to be unused in our tree.

* New `net.if.info` call to show LwIP information

This is a generalization of `wifi.sta`'s and `wifi.ap`'s `getip` and
`getmac` calls.  I don't propose to deprecate those, but perhaps we
should, in the documentation, point users at this function instead.

The direct motivation is to permit continued use of DHCP-provided NTP
servers in a future where
nodemcu#2819 has landed, now
that nodemcu#2709 is in the
tree.  But rather than exposing just that information, a more general
interface seems useful.
* Remove stale putative MD2 support

This hasn't worked in a while, presumably since one of our upstream
merges.  Don't bother making it work, since MD2 is generally considered
insecure.

* Land mbedtls 2.16.3-77-gf02988e57

* TLS: remove some dead code from espconn_mbedtls

There was some... frankly kind of scary buffer and data shuffling if
ESP8266_PLATFORM was defined.  Since we don't, in fact, define that
preprocessor symbol, just drop the code lest anyone (possibly future-me)
be scared.

* TLS: espconn_mbedtls: run through astyle

No functional changes

* TLS: espconn_mbedtls: put the file_params on the stack

There's no need to malloc a structure that's used only locally.

* TLS: Further minor tidying of mbedtls glue

What an absolute shitshow this is.  mbedtls should absolutely not
be mentioned inside sys/socket.h and app/mbedtls/app/lwIPSocket.c is not
so much glue as it as a complete copy of a random subset of lwIP; it
should go, but we aren't there yet.

Get rid of the mysterious "mbedlts_record" struct, which housed merely a
length of bytes sent solely for gating the "record sent" callback.

Remove spurious __attribute__((weak)) from symbols not otherwise
defined and rename them to emphasize that they are not actually part of
mbedtls proper.

* TLS: Rampage esp mbedtls glue and delete unused code

This at least makes the shitshow smaller

* TLS: lwip: fix some memp definitions

I presume these also need the new arguments

* TLS: Remove more non-NodeMCU code from our mbedtls

* TLS: drop support for 1.1

Depending on who you ask it's either EOL already or EOL soon, so
we may as well get rid of it now.
* Add missing globals from luacheck config

* Fix luacheck warnings in all lua files

* Re-enable luacheck in Travis

* Speed up Travis by using preinstalled LuaRocks

* Fix more luacheck warnings in httpserver lua module

* Fix DCC module and add appropriate definitions to luacheck config.

* Change inline comments from ignoring block to only ignore specific line

* Add Luacheck for Windows and enable it for both Windows and Linux

* Change luacheck exceptions and fix errors from 1st round of polishing

* Add retry and timeout params to wget
Also clean-up a nasty `ow` module example.
HHHartmann and others added 11 commits April 30, 2020 03:37
* fix build

* poor mans link which also works on docker under windows

* Delete espconn.h

* resurecting it as regular file

* Add missing newline

Co-authored-by: Marcel Stör <[email protected]>
Correct typo in Lua export from updateDispla() to updateDisplay()
* Net_info module exposing ping function initial commit
* Ping as a part of net module
* Sent callback implemented
* Add NET_PING_ENABLE macro

Authored-by: vsky <[email protected]> with support from TerryE
This adds an optional use-alternate-address-
parameter to all read-methods of the bme280
module. if not set, the behaviour is unchanged
and first available device will be used.
If set to true, the device at address 0x77 will
be used.

This fixes nodemcu#2241
@nwf
Copy link
Member

nwf commented May 24, 2020

These changes seem sensible, but I wonder if you'd be willing to do some more invasive work and help us dig the project out of technical debt we've accumulated. Specifically, I don't think this needs as much C as it currently uses, and I think splitting the module the way I envision would also solve your problem and let things work with multiple I2C busses or I2C bridge devices. While I am not categorically opposed to C modules, this one strikes me as just begging to be rewritten in Lua+C much as my sntppkt rewrote sntp. (See the in-progress #2819.)

Specifically, I wonder if you could...

  • in Lua, do all the I2C transactions with the device: do just enough of the protocol to get the message as a mostly uninterpreted Lua string.
  • pass that message down to a C module to do the requisite math and bit fiddling, which is, admittedly, generally easier in C than Lua.
  • have C return back a Lua table.

In sntppkt, it was necessary to hold on to multiple response messages, and these became Lua userdata structures. I don't believe that's requisite here, but if it is the same kind of "Lua string -> userdata -> combine/merge/process many userdata -> Lua table" flow seems like a viable strategy.

The upshot of all this is that the C code doesn't need to know about I2C device addresses or busses or platform communication layers or anything like that, it just needs to know how to process sensor reports.

@nwf
Copy link
Member

nwf commented May 24, 2020

Speaking of digging us out of technical debt, it would also be phenomenal (but not required) if you could propose a test plan for bme280 devices. Something that doesn't depend too much on the actual environment, but is enough to walk the device and our driver through the wire protocol. Something like:

  • Put a BME280 on the I2C bus, at 0x76.
  • Initialize it, using bme280.init(...).
  • Verify initialization successful, by reading back the mumbledefrotz configuration register, using bme280.foobar(...) == 0x123456.
  • Ask it to take a reading and verify that the result is within plausibility for a developer's desk on Earth. That looks like bme280.quux(...) and bme280.frotz(...)...

@heikomat
Copy link
Author

heikomat commented May 24, 2020

@nwf I'd be willing to help here, though i'm not sure how long that would take.

I'm neither a Lua, nor a C developer, and am not very familiar with the codebase.
I have worked with both superficially, have years of development experience in general and am a quick learner though.
This means i'm pretty sure that i would be able to do it, but it also means that i'd need a significant amount of (free-)time to learn the codebase, make myself familier with all aspects of the bme280 module and protocol, create a clear plan of what a debt-free implementation would look like and get it right.

I'd suggest the following:

  • I do this, but without any promises on when it will be ready, as spending free-time on this would often not be of top priority
  • It would be done on a different branch, as the refactor would be out if the scope of this one
  • Planning would happen in a separate issue
  • In that Issue, you could describe your plan and ideas in detail, and with that as a base, the target architecture and structure can be discussed

@nwf
Copy link
Member

nwf commented May 24, 2020

👍 SGTM. I see no reason to hold up this PR for that longer-term work. SWIM should probably give things a once-over, tho'; @TerryE?

@nwf
Copy link
Member

nwf commented May 24, 2020

I've landed a proposal in #3126; commentary would be more than welcome.

And... Looking more at bme280.c for that writeup, I worry that this PR's (forgive me) somewhat "quick-and-dirty" support for two devices is not going to work out well; static variables like bme280_h and bme280_hc appear to persist between measurements and will therefore cross-contaminate the two devices. (We really, really should abolish the word static from non-functions in our codebase. This is terrible.)

@heikomat
Copy link
Author

heikomat commented May 24, 2020

@nwf it's ok, i know that this PR is not a very clean solution -> Because i don't know the codebase very well, it is meant to introduce as few changes as possible, and therefore works with what is there. There is definitely no offense taken here on my part :)

it's now midnight where i live, and i gotta work tomorrow, so i'll probably be able to read through your proposal tomorrow evening

@vsky279 vsky279 mentioned this pull request May 29, 2020
4 tasks
@vsky279
Copy link
Contributor

vsky279 commented May 29, 2020

#3132 should properly fix this issue. @heikomat can you please check? I don't have two BME280 sensors with me.

@heikomat
Copy link
Author

@vsky279 that was quick! :o
I can't test it today, but will be able to test it tomorrow!

@marcelstoer
Copy link
Member

This needs a make over. Why do we see 77 commits? Did you start from the wrong base branch?

@nwf
Copy link
Member

nwf commented Aug 30, 2020

The needed rebasing might be fallout from our dev branch shenanigans a while back.

@vsky279
Copy link
Contributor

vsky279 commented Oct 2, 2020

Shouldn't we close this one when there's PR #3132. I'm running this one in some application without any issues.

@nwf
Copy link
Member

nwf commented Oct 6, 2020

@heikomat Does @vsky279's new module work for your use case? If so, I think we can close this as overtaken by events; if not, we should rebase and merge this as an interim fix and it would be very good to know why the new module doesn't.

@heikomat
Copy link
Author

heikomat commented Oct 6, 2020

@nwf I haven't worked on my project in months, as it is working fine and not a priority. I understand that having an additional test-case to make sure everything works is beneficial, but I suggest just moving on with the module from @vsky279 :)

@nwf nwf added the obsolescence The inevitable march of time gets us all label Oct 6, 2020
@nwf nwf closed this Oct 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
obsolescence The inevitable march of time gets us all
Projects
None yet
Development

Successfully merging this pull request may close these issues.