Issues Building Spark Core Thermostat with Photon

General
1

I have/had 3 major issues and have resolved one of them so far (EEPROM write). Issue number 3 is a killer and the one that is holding me up.

I began with the published Spark core thermostat library from github. The hardware is all wired up according to this image on a breadboard intended to be used (not sparkfun):

I can provide code upon request if it will help. I’m not sure needed yet because if I cannot resolve #3 below I may as well shelve the project.

  1. Compiler did not like sFLASH. I replaced with built-in EEPROM functions. This was very straightforward to fix and I have not yet posted code how to do that.
  2. Adafruit_LEDbackup functions do not compile. The compiler complaints are nonsense and when I try the #pragma fixes I get more nonsense. I commented those out for now just to move ahead. The hardware is still riding on the board
  3. I2C bus status 3 and zero values returned from the HIH temperature sensor. I believe the I2C bus lines need pull-up resistors. The original schematic does not show any. I wonder if the Core had them built in and Photon does not?

So you can see that the I2C issue is a deal breaker. I plan to add pull-up resistors to see it that works.

2

the indented “1.” is really issue “3.”

3

ad 3)
This is for definite - you need pull-up resistors on the I2C bus and the Particle devices don't bring them.
But your shields, sensors or such might bring them, so you need to make sure there are not multiple sets of them in parallel.
https://docs.particle.io/reference/firmware/core/#wire-i2c-

ad 2)
Need to see the error messages for that

ad 1)
What's sFLASH? :wink: It's recommended to use EEPROM since it also takes care of wear-leveling and other features.

Have you got a link to the original library?
Is it this one?
GitHub - particle-iot/thermostat: A place for all things related to ye olde Spark Thermostat Hackathon

What dev env are you using?
If you're using Web IDE try adding #pragma NO_SPARK_PREPROCESSOR as first line in your .INO
Are you using these two?

  EEPROM.put(DESIRED_TEMP_FLASH_ADDRESS, desiredTemperature);
  EEPROM.get(DESIRED_TEMP_FLASH_ADDRESS, desiredTemperature);

Fixed the "3.".

You can always edit your own posts when taping the pencil symbol near the reply button.

3 Likes
4

Thanks.

I have link to original library. It includes the hardware schematic.

I’m using the Web IDE. I also built the source code repository locally in Windows 8.1 with exact same result. I like using the Web IDE. What a cool concept. Flashing remotely is doubly cool.

I tried the pragma, same result. Also note I got the same result building locally.

Next is to add the pull-up resistor. Wish I had used the prototype board. I thought that having a tried and true design would be trouble free. Duh. I never learn. :astonished:

Don’t expect an update for about 10 days. I’m going to go enjoy the fall weather. Thanks again.

5

One error message I get without #pragma SPARK_NO_PREPROCESSOR is this

error: variable or field 'setupMatrix' declared void

and it goes away with it.

Next I noticed that you are not allowed to import Adafruit_GFX library since the Adafruit_LEDBackpack library brings its own causing errors due to double declarations.

6

Ditto on your findings. We will need to clone the Adafruit_LEDBackpack library and just start working them one by one. I plan to do this once I get the hardware working. The library may need #ifndef _Adafruit_GFX and #define _Adafruit_GFX at the top of Adafruit_GFX.h. I guess the port wasn’t tested totally.

7

I’d rather guess that things have changed drastically since this project was originally developed and it wasn’t adapted since.

And as I said, with the above alterations the project builds without errors without any actual changes on the Adafruit_LEDBackPack library.
So no immediate need to fork that lib.

BTW: #ifndef (which is there anyway) or #pragma once would not solve the problem since you got several (two of each) source files .CPP containing multiple implementations for prototypes.
By not importing (or removing from your project, if already imported) Adafruit_GFX library you’ll solve that issue quite easily :wink:

8

Here’s the working code:

  1. Compiler did not like sFLASH. I replaced with built-in EEPROM functions. This was very straightforward to fix and I have not yet posted code how to do that. ******See the above link for details. Do not use sFLASH for photon right now.
  2. Adafruit_LEDbackup functions do not compile. The compiler complaints are nonsense and when I try the #pragma fixes I get more nonsense. I commented those out for now just to move ahead. The hardware is still riding on the board. *****Use the library #include “adafruit-led-backpack/adafruit-led-backpack.h”
  3. I2C bus status 3 and zero values returned from the HIH temperature sensor. I believe the I2C bus lines need pull-up resistors. The original schematic does not show any. I wonder if the Core had them built in and Photon does not?********The I2C status cleared up using the new adafruit header file. The temperature sensor started working when I fixed a bad solder joint.

I added pull-up resistors but I’m not sure their lack was causing any problem. Before I fixed the temp sensor solder joint and added the resistors I made the led header change and the leds worked. The led matrix definitely worked without pull-up resistors. There is some confusion out here in “user land” where there is a notion that the core and photon “include pull-up resistors.” Reading between the lines I deduce that the core prototype board has pull-up resistors built into it. It is less clear that the core and photon themselves have them. I have had unterminated RS485 buses work ok under some conditions then adding slightly longer lines introduced bad line dynamics. Perhaps I2C is similar which may explain why my led worked without the resistors. I don’t know.

1 Like
9

I guess there is a misconception at work.
The GPIO pins can be programmed to have internal pull-up/pull-down resistors attached - namely along with being set as INPUT.
But for the pinMode used for the I2C interface there are no internal pull-resistors and their value would be too weak anyhow.

I2C needs pull-ups since this is the way how the HIGH level gets generated. The devices - master and slaves - only pull the lines LOW and let go of the lines allowing the pull-ups to return back to HIGH.
Due to this you need to make sure that resistance, capacitance and inductance of your external circuitry done cause negative effects on the fall-rise-time of your signals.

10

Thank you. I added the resistors. I bought some carbon ones that turned out to be about the size of a firecracker. Hah! Keep learning… I will always terminate buses properly as long as I am alive (pull-up resistors in the case of an I2C) since I wasted an entire week chasing an RS485 bus problem caused by a missing terminating resistor.

1 Like