digitalRead not working | TrackerSOM

Edge Systems
1

Hi,
I’m working on a project using the TrackeSOM Eval Board. I’m performing an action when a certain pin goes HIGH or true… This code I’m writing will work fine with the Gen3 devices but is not responsive with the TrackerSOM. Anybody else dealing with a similar issue.

You can see what I’m working on in GitHub (GitHub - heat-injector/HISmonitor2.0: Second Iteration to HISmonitor. A Tracker that will be installed on our Portable Heating Equipment.) Line 65&66 is the boolean I’m talking about.

Thanks in advance!
-Kevin

2

Not addressing your issue but you should stick with your chosen pin names and not flip back and forth between pin labels (e.g. D5) and your names (e.g. isPoweredOn).

You should also not rely on the pins being initialized correctly by default (i.e. no pinMode() for neither A4 nor A5)).

BTW, when defining your own pin “variables” it’s safer to have them defined as const.

3 Likes
3

The problem is most likely in tracker.cpp in the Tracker Edge firmware. Around line 446, comment out this line:

SPI.begin(PIN_INVALID);

All of the internal SPI peripherals like GNSS and ESP32 use SPI1, so this won’t break anything. The problem is that D4 and D5 are used for SPI (primary interface), so if you call SPI.begin() you can’t use those pins for GPIO anymore.

4

Instead of modifying tracker.cpp would SPI.end() not release the pins again?

5

SPI.end would work to release the pins for GPIO use again, but temporarily enabling SPI could cause the pins to change state. Because of the way Tracker Edge is built in Workbench, you can edit tracker.cpp without needing to fork anything so it seemed like the safer option, but both would probably work.

2 Likes
6

I’ve submitted several commits recently related to SPI initialization and D5 pin usage in tracker-edge that addresses several of these comments.

2 Likes