But it poses the question to me: If you have the 4 "transistors" to switch things - with the stated problem - you can build it your self.
So to "reduce" the problem, that chip was used.
If you watch the clipi about 15 minutes in he shows the code. There are 4 outputs used to control the one motor. But! It is poorly explained. There is an "enable" and two direction control lines. You can see how he "enables" the motor, the using the two direction control lines, control the motor's direction.
But these lines are NOT going to the mosfets/transistors. They go to the CHIP. L298N
Therefore: If they made the chip "better" they could do it with 2 lines: "Enable" and "Direction" You send signals to the CHIP and it works out which mosfets to turn on/off.
That way: You can't have the wrong combination to allow the magic smoke to escape.
"Goldfish brain" posting, so I am sorry for the way this is posted.
The other day I was looking at DC motor control for the RPi. Granted that is not an Arduino, but hey, that isn't the important part.
The control board has the ability to control 2 motors controlled by an H Bridge.
What confuses me is the complexity of it.
Basically there are 8 inputs to the board, and 4 output points for the motors. (2 for each motor).
The power has THREE inputs: An "external power", Ground, and +5 volts. The Ground and +5 are from the PI/Arduino. The External power is the one used to control the motor.
So: Each motor has 4 input pins and that is where I get confused.
The board has a big CHIP on it which is a motor controller kind of thing.
Sorry I can't post the link - goldfish brain, remember.
But it is pretty "simple" to control. You have a sort of "activate" pin, and two to control the direction.
So it goes something like: Set the two control lines high, then use the other two to control the direction of the motor. BUT! It doesn't explain why you need two "enable" pins? The direction examples are forward, 2 seconds, pause 2 seconds, reverse 2 seconds, pause 2 seconds, repeat. So the "direction" pins go something like: LOW, HIGH HIGH, LOW LOW, LOW
But there again, it doesn't say what happens if you put both lines HIGH!!
Ok, I need to research, but I am putting the question out there.
maybe not the right place, but here is my sketch so far.
Granted it is a bit more "convoluted" than just a timer.
What I am now having problems with is the TYPEs: Errors show here: V2a.ino: In function 'int timer(int)': V2a:284: error: request for member 'outlet' in 'runTime', which is of non-class type 'long int ' V2a:284: error: request for member 'outlet' in 'lastTime', which is of non-class type 'long int ' Yeah, LONG INT don't go together.
Quick walk through: This is WORK IN PROGRESS so things will change.
Originally I was writing the code as complete, individual routines. So to deal with the 4 buttons I would write 4 blocks of code. To deal with the outlets, I would write..... 4 blocks of code. And to deal with the timers I was going to write 4 blocks of code.
Then I remembered I can do this "trick" where I can have "arrays", or from the errors above: CLASSES. So I started to re-write the code with CLASSES, or as I would like to call them: arrays (for now, anyway).
And I got the error above.
*** NOTE *** I have left in a lot of "old code" to show how I have changed things. Why? Well to help show/explain how I am learning and how the code is being changed.
Question: "button" is returned early in the piece to show which button is pressed. 1 - 4 is an outlet. 5 - 8 is to edit the outlet's run time. As only 1 - 4 would ever be passed to the outlet parts, I use button as a variable and call routines with it. But as it is a GLOBAL variable, do I need to send it to the routines or could I just get the name in the routine? Maybe it is good practice to do it this way, but I am wanting to hear any possible problems I may have before I re-enforce them too much.
Oh, and the MENU part is being written in another block for now, as the pins have conflicts. So for now I just picked pins for the I/O and shall change them when I have the display/menu stuff working.
I am wanting to make a bit of code which can be run concurrently with multiple iterances
that is a complicated thing to do.
Were you able to figure out the "delay_without_delaying()" code that a posted a while back?
Pretty well. Thanks.
I think my problem is understanding the routine and how it works.
That is why I have "cut back" and hacked the code so much.
There is an example sketch with "clickbutton" and I have taken a lot of the code from that and put it in mine now. It still doesn't work. I found one big problem that my delay(500) was kind of killing it a bit, so I dropped it to 200. Now I am seeing the values change depending on the switch presses, etc. But the routine still doesn't seem to turn the LED off - the LED on pin 13.