Thanks for checking on me! I think in addition to the library I was also having a hardware problem, as the I2C on this display stopped responding, so I’m trying to get a replacement from Adafruit currently.
I’m having some success with the 2.8 touchscreen TFT, though, so have been able to shift onto another display for the time being.
I am also trying to use the seesaw library - this time to get the Adafruit capacitive soil moisture sensor to work. I used the version of this library in the Particle library manager and with @m_m 's help can flash the Boron but, the device is not responding. Any advice on troubleshooting? Anyone have experience getting this to work?
Figured it out. In the example code, the i2c address for the device is wrong. Once I fixed that, it started working. If you are the one who maintains the library, you may want to change this line in the soilmoisture example so others don’t bang their heads against the wall like I did:
The following line in the in Adafruit_seesaw.h is causing a “Problem” warning in Particle Workbench on compile. Wonder if it could be removed for the Particle Library version though it clearly is not causing a functional issue:
Now, I need to figure out how the new Particle Workbench handles updates like this. I will ask elsewhere but, do I need to un / reinstall the library to get the updates?
If you run the Install Library command again, it should increment the version in your project.properties to v 0.0.5. If you see that, you should have the latest. LMK if it doesn’t work!
Brandon, could the (ARDUINO >= 100) be a side effect of these issues
There were no official responses to these issue reports but they should be addressed better sooner than later especially since they would be an easy fix.
Are these IntelliSense messages or actual build warnings?
If IntelliSense @m_m will keep scratching his head a bit more as that seems to be a rather picky feature to get right
@chipmc and i spent some time poking at this yesterday - the “Problems” panel will show both intellisense and build warnings / errors via what VSCode calls “problem matchers”. in this case, i’m not able to repro exactly what he’s seeing (on mac or windows 10) but it looks like an intellisense issue since they are errors yet he’s able to compile & flash. that said, when the “problems” appear would tell us definitively - if after compiling, they’re build “problems”, if before intellisense.
one thing to try: run the C/C++ Reset Intellisense Database command (View > Command Palette > type “reset database” and pick the command from the list).
@m_m, Thanks for continuing to look into this. I reset the database - and am now down to one - bogus - problem. The good news is that, when I click on this item, I no longer get that “problem exists in a file that is non-existent” message.
probably just more evidence of some underlying bug unfortunately.
are you seeing any green / red squiggles in your .ino source file? if so, where? if not, are you able to right-click on the .h file portion of #include "Adafruit_seesaw.h" line, select “Peek Definition”, and see the appropriate source reference?
another thing worth looking at is the C++ extension’s log output - add "C_Cpp.loggingLevel": "Debug", to your ./.vscode/settings.json file (or open File > Preferences > Settings and then type “logging level” and select “Debug” from the options list for the “C_Cpp: Logging Level” option).
that’ll produce a fairly verbose log so it’ll probably be easier to ping me via slack and we can poke at it together (plus, i’m getting off-topic here).