MOSFET is always on

@davee Thank you so much for this informative answer! I'll keep this in mind going forward, and yes, I have indeed had those flashes happen! This explains why 😊

How would you ensure not writing the same value repeatedly? Just assign it to another variable and don't do anything if it has not changed using a simple if block?

Say I want to write 0 when a distance is above a certain value, and 255 when it is below. I of course check the distance, but that would still mean writing to the pin each loop. Should I also read the pin first and only write if there is a change? Or should I not even read it, rather store the last state in a variable as I mentioned above? Just trying to be efficient 😊

@tasan 

In my opinion (and experience) you will have a short and unhappy time with electronics if you don't learn to solder. It is the best way to connect wires together, breadboards (even the best of them) are unreliable and unless you want to use WAGO connectors for everything you're again going to be disappointed.

As for assembling and packaging a heap of parts into a pretty bundle and case, well, no - I don't know of any specific places to look. I'd suggest Googling similar projects to get an idea of what their version of the wiring and case looks like and go from there.

Also, unless you have access to a 3D printer, you may need to search for a suitable project box before you complete your circuitry. You'll need to balance your choice on whether your physical design will fit into the selected case 🙂

Posted by: @will

↑

Posted by: @robotbuilder

↑

Personally I avoid "guess what I have done wrong" questions.

But seriously, isn't that the underlying point of almost every question posed here ?

My bad. I should have added "without sufficient information as to what was done".  However you guys have done a great job helping resolve the issues.  You all seem to respond before I can even read the post 🙂

@davee Dave, this is the first I have heard of this. Can you cite a source, and/or elaborate as to what the board is doing so that the 'wrong' order of instructions can cause a 'flash'? I am somewhat taken aback that the pinmode does not set an initial value which I assume would be LOW for output, and ? for input, maybe HIGH if INPUT_PULLUP is expressed, maybe LOW if not?

Also, I would recommend the first digitalWrite to an output pin should normally occur before the corresponding pinMode, so that the level on the pin is predetermined when it starts to drive current as an output pin. If the operations happen in a reverse order, the pin may produce a short unwanted pulse. In your case, this would be a flash of light, but in more complex systems, such as when the pin is controlling another machine, this could cause a serious event.  

Hi @tasan,

  With only a few lines of code, and realising you are at the start of a personal journey, it is difficult to give definitive answers to your code questions .. the most important point is you are starting and that you carry on. As you proceed, you will meet new challenges and become aware of new methods, so it will gradually click into place. In the meantime, don't worry about it too much.

Hence, I'll just mention the kinds of tricks you might consider in the future:

Certainly, using decision instructions like 'if' so that you only do things that need to be done. As the task becomes more complex, you will want to break it into functions, and thus it wil be more natural to decide to only call a function when it is going to contribute something useful.

If power consumption becomes an issue (e.g. battery life), then there are instructions to put the processor to sleep for short periods, during which time it will only consume a fraction of the current required in 'normal full speed' mode. These approaches can be 'lifesavers' in some applications, but they are not always easy to implement. I would not advise looking into them yet, but bear them in mind as a possible specialist tool for the future.

--------

I'll also take the opportunity to back up @will's on the need to progress on from breadboards ... they are great for trying out ideas, making the early mistakes everyone makes, and in most cases continues to make in slightly changed forms, but they do not have any sense of stability. So prepare yourself to expand into more permanent structures. Of course, if you are only doing it for your 'amusement',  as against earning a living, then the rate at which you expand your interests is up to you.

Good luck, enjoy, whatever path you follow and stay safe. Best wishes, Dave

@tasan Save the current state in a variable called currentState then modify your if to then do another check, if currentState == HI write low else do nothing. Clear?

Say I want to write 0 when a distance is above a certain value, and 255 when it is below. I of course check the distance, but that would still mean writing to the pin each loop. Should I also read the pin first and only write if there is a change? Or should I not even read it, rather store the last state in a variable as I mentioned above? Just trying to be efficient 

Hi @robotbuilder,

  I agree that life would be a lot easier if every question was properly documented, etc, ... sadly, I don't think it is going to happen, so I go with 'guess back if I have a chance, request more info if there is nothing to work with.'

This particular case, whilst far from being a model of a good question, was made a bit easier because there were really only two or three components at the basic level. And the first thing to establish, was could the FET actually stop the current, so there were a number of paths to establish that point, before any of the more subtle problems.

Best wishes my friend, Dave

Hi Ron @zander,

  Re: pinmode does not set an initial value 

I confess I haven't checked the code recently, so I apologise if Arduino IDE bucks a trend, but I have come across this one before ... and it would sometimes be a real problem if it worked the way you suggest.

I expect the "Set pinMode (of specified pin) to output" instruction to do exactly what it says ... to turn that pin into an active output.

I do not expect it to dictate whether it is high or low when it becomes an output ... that is the job of the internal pin output register.

-----------------

PinMode changing to "input" can only disable any existing pin drives such as "output" or "Input PULLUP", thus leaving any external circuit to drive the pin to a new voltage level, with minimal hindrance - that is the input impedance is likely to be very high. If there is no external circuit, then pin voltage is likely to drift, weakly affected by leakage currents and stray capacitance. pinMode instruction cannot set set it high or low.

PinMode changing to "Input PULLUP" is similar to input, excepting it also connects an internal resistor of around 50kOhms (very wide tolerance), between the pin and the Vcc line, so that it is weakly pulled up to high. Consequently, in the absence of any external drive, it will subsequently read as high or 1. Note this 'high' or '1' is a result of enabling the internal pull up resistor ... the pinMode instruction itself does not influence the level in any other way.

-----------------

Many programs/systems are insensitive to this problem, as at worst, it is only likely to produce an extra pulse or transition, so many people have never seen the problem.

Systems tend to be upset by this, when the pin either activates something (launch a rocket?) or it is part of simple serial communications link that becomes confused with an extra 'data bit', causing it to lose synchronisation.

--------------------

To explain:

Each GPIO pin of a 'generic' microcontroller has a small circuit block, including registers, switches, pull-up resistors and so on. Which of these parts are active depends on the choices made by a 'pinMode' type of instruction.

One part is the output register, which is a simple 1-bit register that can be written to by the microcontroller, regardless of the current pinMode. If the current pinMode is something like "input", then the 'outside' world is at that time unaffected by changing the state of this register.

(If the pin was in an "output" state, then obviously any change to the register state would appear.)

But if the pinMode is subsequently changed to Output, then the state of that register is immediately used to set the new state of the pin.

The pinMode instruction does not change the state of the register ... it merely enables its state to be seen on the outside pin.

The reason for this is fairly simple. You want to give the programmer the choice of which level it will initially drive the pin to. If the pinMode instruction changed the register state, it would force that choice, which might be incompatible with anything being controlled by the pin.

It also simplifies the pin circuit block, because it means the change for input to output only requires the pin output buffer to be enabled ... everything else has been set up in previous instructions.

----------

As I said, I haven't proven the above description - the Arduino reference on 'pinMode'

https://www.arduino.cc/reference/en/language/functions/digital-io/pinmode/ does not elaborate.

Admittedly, the demo code in the reference sets the pin mode first, but since it is only producing a 1 second square wave, the effect will be negligible.

-----------------------

It is plausible that the output pin register is initialised by either the hardware reset and/or as part of the microcontroller code that the Arduino IDE that is run before calling setup(), so it might always behave the same way, if you set the pin to output before setting its value. However, I don't know which way that is, and I suspect it will be a hunt to find it.

Surely much better to set it explicitly in the main visible code.

Simple rule ... Always set pin output value, before enabling pin output.

---------

Just my thoughts. If I have any misconceptions, then please let me know and accept my apologies in advance.

Best wishes,

Dave

Hi @tasan,

Sorry, I forgot your question had two parts ....

Say I want to write 0 when a distance is above a certain value, and 255 when it is below. I of course check the distance, but that would still mean writing to the pin each loop. Should I also read the pin first and only write if there is a change? Or should I not even read it, rather store the last state in a variable as I mentioned above? Just trying to be efficient

Some microcontrollers will allow you read the state of an output pin, and if so you can consider that choice. If your uC is really short on RAM, then this might get free up an extra byte!

Hopefully, you won't have to spend too much of your life scraping at this level, in which case your last suggestion  of storing a value in RAM will probably be preferred. I am not sure about Arduinos, but larger/faster micros tend to be able to access memory faster than peripherals like GPIO pins, so avoiding an extra access to the pin register and only write to the GPIO pin when you need to, is worthwhile.

---------

So I have tried to answer your question, but more generally, try to relax about getting the last 1% of performance/efficiency. There will be times when it is important, but meanwhile try to think more about the overall task, and avoid getting bogged down in the fine print.

Best wishes, Dave

Thank you everyone in this thread! 😊

I will start a project thread so I can get more specific input. Now I don't think I am going to learn to solder for this one project, but its probably worthwhile to learn for the future!

@tasan There are plenty of Youtube videos about it, not hard at all.