Remote pump control ideas.

[stj]

Re: Remote pump control ideas.

record speed compared to your AVR stuff then.

[Dannyx]

Re: Remote pump control ideas.

Another reason it went better this time is because I decided to re-write the whole code and it all became SO MUCH easier once you understand the program you write runs line by line. It makes it so much easier to understand all the whiles and DOs...it was like a stroke of genius Ok, it's unimpressive for any "real" programmer out there, but it helped clear some things out.

There's still stuff I haven't yet delved into, such as doing stuff simultaneously, which I think is called multithreading ??? This would be handy in my car window project where I have to monitor two switches independently. The way I did it works, but it's disastrous overall It only "feels" like it does stuff at the same time - it doesn't - just does it fast enough that it feels so...

[stj]

Re: Remote pump control ideas.

that's what multi-threading is, jumping between stuff so fast that nobody can tell

[Dannyx]

Re: Remote pump control ideas.

Yeah, but can Atmels "truly" do it ?

If I'm in a while loop for instance, I can't do anything else outside that, meaning if a button changes state outside that loop, it won't catch that....

[stj]

Re: Remote pump control ideas.

that's not how it's done,
you have a main loop that branches to each task.
tasks like checking buttons, checking sensors etc.
none of the tasks go into a closed loop.

[Curious.George]

Re: Remote pump control ideas.

that's not how it's done,
you have a main loop that branches to each task.
tasks like checking buttons, checking sensors etc.
none of the tasks go into a closed loop.

That's not the case with preemptive multitasking. And, many nonpreemptive systems can run "endless loops" as long as there is some transfer of control to the OS within that loop (i.e., any system call).

task_t winky(void)
{
  while (FOREVER) {
    LED = ON;
    sleep(1000ms);
    LED = OFF;
    sleep(1000ms)
  }
}

"works" because the sleep() traps to the OS -- which can take steps to transfer control to the next task while ensuring that THIS task "resumes" at the line after sleep() -- whichever happened to have been executed last -- when the sleep period has expired.

Preemptive tends to be more performant; non-preemptive tends to be safer (for newbies) as you can control when you relinquish control of the processor (to implicitly avoid atomic regions).

[stj]

Re: Remote pump control ideas.

i was avoiding interupt based stuff

[Curious.George]

Re: Remote pump control ideas.

i was avoiding interupt based stuff

You don't need interrupts. In my example, you LIKELY would have them to provide the timing information. But, you could also implement delays using a real timer.

The point is that you can write your code largely ignorant of the fact that other "programs" (tasks) are co-executing alongside you -- assuming you take precautions not to have two (or more) trying to use the same resource(s) at the same time.

The downside to the "super loop" approach is that you have to remember to EXPLICITLY "share" the processor with the other tasks. There's a tendency to want to "be greedy" with it as it often makes the current task's job easier (at the expense of other tasks)

[Dannyx]

Re: Remote pump control ideas.

Back to something slightly more hardware-related: it's a snippet of this project's schematic and I'm trying to "read" the status of the main contactor through one of its AUX contacts to signal it to the MCU, but I also want to turn on a 12v LED lamp with it. Would something like this work ? I used a schmitt-trigger there just because

Sticklers will probably point out immediately that I have a free set of contacts to the far right which I could use, but this is ASSUMING I only have the one N.O contact to work with and I need to both signal the MCU if the contactor is on/off AND turn on the green lamp. I'm not sure what happens when the switch opens...would the input of the schmitt trigger "float" and go ape$hit ?

Another idea was to use the base of a transistor there to drive the lamp (and use 5v on the AUX switch, instead of 12) but again: I'm not sure it would be "stable"...

[stj]

Re: Remote pump control ideas.

wtf?
use the relay to pull to ground,
out the led & resistor(2k2) to +12v or use 5v and 470ohm or higher
the microcontroller has internal pullups

btw - your circuit will blow the led to bits - literally!

[Dannyx]

Re: Remote pump control ideas.

btw - your circuit will blow the led to bits - literally!

No, it would not, because it's not actually a single plain LED. It's THIS...which also explains why I paid no mind to resistors for the LED - it's a standalone lamp you run on 12v. It does the stuff you mention inside of it.

I WAS thinking of going straight to the MCU/schmitt pin like this, but this sends 12v into the pin when the diode becomes forward-biased (switch open) if I see it right (even with a resistor inside the lamp). It MIGHT work if running on 5v, since it would simply "pull up" the pin of the MCU/schmitt which wouldn't care...

[stj]

Re: Remote pump control ideas.

i think if you put a 1n4148 diode between the mcu and relay you should be good.
it will block the 12v through the lamp from the mcu
if that even happens.

i have some led indicators that dont have polarity, i think they have a rectifier or multiple leds in them.

[Dannyx]

Re: Remote pump control ideas.

These lamps are not polarized either, so there's a rectifier in them, or two diodes. Still...

I thought of a simple diode but couldn't figure out where to put it. Assuming we're still switching to GND through the contact like in the schematic, should I put it with the cathode facing the contact and the anode at the the MCU pin (or input pin of schmitt trigger IC in my case) ?

[stj]

Re: Remote pump control ideas.

yes, anode to mcu input you can also use a series resistor to limit the current to the limit of the pin if you want.

[Dannyx]

Re: Remote pump control ideas.

I based my setup on THIS, so the schematic looks like so, adapted from the one the chap gave in the post (gotta love that artwork I did in MSPaint because my POS laptop at work won't run KiKad due to openGL or some $h!t ), so the resistor you mention is already in place I think (R2 in this case).

It seems to work fine this way: when "resting", the lamp if off and the output of the schmitt trigger is LOW, due to the pull-up resistor. You push the button, lamp comes on and output goes high (inverting action).

I seemed to notice a very short spike in excess of 20v when measuring the the output of the schmitt trigger when I push the button. It quickly stabilizes to 5v as expected and no smoke came out. It could be a fluke of my meter due to noise or something, since I moved the connections around a bit and the spikes seemed to go away too. I haven't killed anything yet, but I'm not sure I should overlook this issue and regard it as "solved"....

[stj]

Re: Remote pump control ideas.

what os you running on the laptop?

[Dannyx]

Re: Remote pump control ideas.

Win 7 x64, though it works at home. Also this is a VERY old laptop which I use strictly for messing around on. It's an Aspire 5920.....with a reflowed graphics card I might add

[Dannyx]

Re: Remote pump control ideas.

I'm having trouble following the port numbering of the F767. Specifically, I can't figure out which pin the red LED (LD3) is connected to. The example sketch for the Arduino environment, mind you, gives it as "LED_BUILTIN" which doesn't help. The datasheet of the board says it's connected to PB14 which would be physical pin 75, but it's not coming on if I set that to "OUTPUT"...The only "true" map of the pins which DOES work is on pages 38-42. If I use the numbers THERE, the pins work as expected, but get this: PB14 is not on there It makes sense, since those pages list the pinout of the unpopulated morpho connectors and the LED is not connected to those - it's straight off the STM.

I'm sure this would be "easier" in Eclipse, since it's designed specifically for these boards and I saw it even shows a map of the pins which you can click on and configure. The Arduino IDE does some hacky stuff in the background to get this to happen, so that's not helping either.....

Really should get started with Eclipse (or was it "Cube" ?) Sorry - there's so many pieces to it that I forgot what I needed

[Dannyx]

Re: Remote pump control ideas.

Call me an idiot after not realizing this after so long, but what is the operating voltage of these Nucleo boards ? It's only now I realized the digital pins put out 3.3v. I was afraid I messed something up somehow, so I tried the other board, set one of its pins to high and it too only puts out 3.3v...what gives ? HAS it been like this the whole time and I simply didn't notice ??? I could've sworn I saw 5v on one of its pins, and no, not just the 5v output...

I noticed my LED lamp, which ran perfectly fine till now, dims when the buzzer I have attached to another pin comes on....even if I disconnect the buzzer entirely ! I can see the buzz pattern in the LED lamp ! The lamp is driven via a 2n222a transistor with a 1k resistor, which worked perfectly on 5v on the Arduino and even on the Nucleo....until now ! What's going on ?

[stj]

Re: Remote pump control ideas.

???