I have a Hall Effect sensor that I have been using on an Arduino to calculate RPM with no issues. When I take the same sensor and plug it into a Particle Photon, there is no response. Move it back to the Arduino and it works fine which tells me I didn’t manage to kill it.
I’ve tried moving the sensor to different pins (D0, D2, D4, D5).
Tried triggering on rising and falling state.
Tried driving it from the 3.3v pin and from the vin pin through a 74HCT.
Code is stripped down to just toggle an LED and count ISR triggers.
Using Unisonic U18 sensor (data sheet) with 10k resistor across vcc and signal out (pins 1 & 3 on the U18).
Another set of eyes on this code would be greatly appreciated. Any obvious goofs? Anything else I should try?
#define LED D7
#define HALL_SENSOR D2
volatile int state = LOW;
volatile int trigger = 0;
int last_trigger = 0;
void setup()
{
pinMode(LED, OUTPUT);
pinMode(HALL_SENSOR, INPUT_PULLUP);
attachInterrupt(HALL_SENSOR, magnet_detect, FALLING);//Initialize the intterrupt pin (Arduino digital pin 2)
// Flash LED for a second to indicate setup
digitalWrite(LED, HIGH);
delay(1000);
digitalWrite(LED, LOW);
Serial.begin(9600); // open serial over USB
while(!Serial.isConnected()) Particle.process();
Serial.println("Hello World 12!");
magnet_detect(); // Call the ISR once so we know it isn't broken
}
void loop()
{
if (last_trigger != trigger) {
last_trigger = trigger;
Serial.print("detect ");
Serial.println(trigger);
}
digitalWrite(LED, state);
}
void magnet_detect()
{
state = !state;
trigger++;
}
You have connected to the Photon with a Serial Terminal program and sent some byte to the device to actually overcome this line of code?
Hmmm...I was just following the example in the reference docs and didn't know the implication that this is a blocking call. (The example code in the rightmost panel here says it's mandatory but no mention that it blocks waiting on imput. Does that need a tweak?) I do get the debug output after that line, though.
You can also add digitalWrite(LED, !digitalRead(LED)) to your ISR to see it being triggered even when the code is not executing any print statements.
I'll try these changes tomorrow. It's 01:15 here which under normal circumstances is prime coding time but I have an early meeting. :-/
It's still rather early hear, so I missed that this acctually said while(!Serial.isConnected()) - which only requires you to open the port - instead of the formerly commonly used while(!Serial.available()) - requiring you to actually send a byte.
But however, the while() will block as long the condition is true and hence will block the rest.
What does that mean? 74HCT is only the "family name" which member of the family?
And why?
The sensor can cope with up to 20V and the output is open-drain so you should be able to go direct from Vin to Vcc without any risk for the input pin (which are 5V tolerant without the internal pull resistors).
When using INPUT_PULLUP you need to have the external pull-up connected between 3v3 and the input pin. When you drive your sensor from Vin and have the external pull-up connected between Vin/Vcc and input you'll create a voltage divider from 5V to 3.3V via the internal and external pull-ups.
However when using an external pull-up you can/should avoid using the internal ones to avoid above problem and to prevent issues when you decide to change things either in code or in hardware. Also try a 4k7 instead of 10k (just to make sure ;-))
Got a chance to try the suggestions but first let me respond to...
The "why" I tried what may appear to be random scattershot approach is because much of this is still gibberish to me. I remember reading somewhere that the pins are 5v tolerant but I tried the level shifter in there and tried to the 3.3v pin because I do not know the limits of that tolerance. I have no idea what open drain means, along with much of the other electronic theory and design. Your comment about use of D0 is an example of one of those restrictions I was unaware of that my strategy of trying several pins was intended to work around. I'm still at the "connect the dots" stage and can generally make stuff work without necessarily understanding the theory or technical details behind it, and am trying to pick those up as I go.
Side note: I have the flip side of this problem in my own specialty. Lots of people doing IT security off a checklist and no idea how to diagnose or fix when it goes off-script. The opening up of deep specialties to non-specialists is both the wonder and the curse of the Maker age.
That said, based on your comments, I removed the external pullup in favor of the built-in one. The level shifter was already removed. (It was a 74HCT245N that I use to drive APA102 clock and data pins.)
I replaced the Particle.process() with a few milliseconds of delay but kept the while statement for now. I actually want it to block until the serial monitor is set up and plan to delete this once I get it working and disconnect from the PC. I assume that seeing the Hello World message means it's unblocked and I do in fact see that message every time.
Per your suggestion, I set the LED toggle in the ISR and removed the digitalWrite from the loop. I can see this fire when the ISR gets called and will leave it in there so I can get a visual clue that the interrupt is (or isn't) firing.
After all that, it works! W00t! Thanks for the advice. And, yes, I plan to go look up open-drain so your teachable moment won't go to waste.
I wasn't sure if I might have offended you or came across superior - if so, my appologies! That was not my intent.
This community is all about helping everybody from novice to pro and back and we want to keep this culture open. So if I sent the wrong signals: "Sorry!"
However, if we throw out tech jargon it's just because it comes all too natural for us, but if you have questions we should also be able to expain what we mean in simple terms.
Heh, heh, sorry. Perhaps that didn’t come out as intended. I wasn’t pushing back so much as explaining my approach and trying to reset expectations on your end a bit lower. If anything I’m a bit frustrated with my own lack of knowledge that some of this was over my head, not your approach in explaining it. Definitely no offense taken and the help much appreciated.
I did go look up open-drain and don’t understand entirely what it means but gather that because it floats I can control it with the internal pullup or an external one. (There were about 6 related terms linked to from the page I found and I didn’t have time to walk the links to all of them. Yet.) Getting there.
By the way, I was in the process of integrating the hall sensor into the FastLED code I already had working. I’ll have POV before too long.
I worked at the School Board of Pinellas County so long ago that the data terminals used by most schools were Teletype devices. Big, noisy printer/keyboard devices that consumed great quantities of greenbar paper. Every weekend the janitors would pull these away from the wall to clean behind and under them and every Monday we’d get at least 2 or 3 frantic calls to report “the Teletype is dead!” In almost all cases the problem was solved by instructing the caller to plug the device back in. As one might imagine, we had to approach the topic delicately to convince people to suspend their indignity long enough to actually check the plug. You can’t just break the ice asking “Is it plugged in?” and expect a productive response.
I mention this here because I just solved one of the major problems I’d been having up to now. It seems the + and - busses on the breadboard break in the middle. The lines clearly indicate this once you stop and consider why they are not continuous, but nonetheless, I somehow had been working under the assumption that I had power and ground at both ends of the board.
Which explains why when I went to integrate the APA102 code with the hall effect code, a process that entailed moving jumpers to make room for the 74HCT245N chip, everything stopped working. Like the janitors of so many years ago, I’d managed to unplug the device.
Looking at the photo I took before ripping out the APA102 circuits, this problem was extant when I first posted. If I’d gotten the buss wired correctly, I’d not have learned about the external/internal pullup, the voltage divider, or the behavior of the Particle.process and serial functions. Probably would have gotten it to work but probably unreliably or at least sub-optimally.
It’s a bit embarrassing but a lot less so than a lengthy thread eliminating one possible root cause after another, only to eventually post a photo with jumper wires not connected to anything. It’s also a bit amusing to think about whether you’d have taken the delicate or abrupt approach when breaking the news. “Uhhh…see those red and blue lines? See how they don’t meet in the middle? Well here’s a fun fact…”
