Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Outputs on at boot


  • Please log in to reply
12 replies to this topic

#1 SiggyTheViking

SiggyTheViking

    New Member

  • Members
  • Pip
  • 3 posts

Posted 14 September 2011 - 09:53 PM

It seems that all the discrete outs are energized at boot up. Is there any way to avoid (or configure) this? Siggy

#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 14 September 2011 - 10:30 PM

Hi Siggy, The digital/analog pins are all set up as inputs at boot--but the microcontroller enables their pullups by default. There is no way to disable that, although there are several ways to keep electronics from "glitching" during boot. Chris

#3 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 15 September 2011 - 05:58 AM

It seems that all the discrete outs are energized at boot up. Is there any way to avoid (or configure) this?

You'd need to add an external pull-down resistor to make sure the output is logic low during Netduino startup.

#4 georgejh

georgejh

    Advanced Member

  • Members
  • PipPipPip
  • 87 posts
  • LocationGlasgow, UK

Posted 16 September 2011 - 11:09 AM

Hi Siggy,

You may try approach shown in this tutorial.Soon I will publish how to replace the relay with SCR as I mentioned here.
Using this approach gives you more control on when to switch on/off subsequent schematics connected to Netduino.

#5 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 16 September 2011 - 11:38 AM

You'd need to add an external pull-down resistor to make sure the output is logic low during Netduino startup.

It may work, but it is awful. You should use a low-value resistor, and the resulting voltage will be close but not equal to zero.
A good practice would to use negative-logic, where "zero" is "false" and means "active".
Cheers
Biggest fault of Netduino? It runs by electricity.

#6 georgejh

georgejh

    Advanced Member

  • Members
  • PipPipPip
  • 87 posts
  • LocationGlasgow, UK

Posted 16 September 2011 - 02:49 PM

It may work, but it is awful. You should use a low-value resistor, and the resulting voltage will be close but not equal to zero.
A good practice would to use negative-logic, where "zero" is "false" and means "active".
Cheers


You are right Mario. Whatever pull-down resistor values I used, I ran in different problems. So I gave up and approached this problem differently (that's in shown in the tutorial I've written)..

Using negative logic is really good practise, but may be Chris Walker should think about integrating it on the board instead of every project doing itself.

May be tristate buffer controlled by firmware will be best. This way ports can be kept down until become in use. Firmware will enable the actual port output on port initialisation, keeping uninitialised ports down.
What do you think?

#7 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 16 September 2011 - 05:30 PM

You are right Mario. Whatever pull-down resistor values I used, I ran in different problems. So I gave up and approached this problem differently (that's in shown in the tutorial I've written)..

Using negative logic is really good practise, but may be Chris Walker should think about integrating it on the board instead of every project doing itself.

May be tristate buffer controlled by firmware will be best. This way ports can be kept down until become in use. Firmware will enable the actual port output on port initialisation, keeping uninitialised ports down.
What do you think?

The Atmel's choice is the best.
1) If they had chosen as default direction the "output", an external circuit connecting its output to the same pin, would have created a potential collision.
2) If they had chosen as default a 3-state output or an input without pullup (they are equivalent), an external circuit connecting its input to the same pin, would have an undefined state.
Both the choices are wrong.
However, the first one is the preferred when the hardware is well-known a-priori.
So, the only way is to set all the I/O as input with a pullup.

For a novice user the negative logic is un-intuitive, but is not different from the software logic.

Also, I may add a consideration about the initial state.
From the moment where the Netduino (or any other board) is powered, there should not any activity until the program has been initialized. The whole system should begin working actively only when the Netduino signals (by an OutputPort) to the external circuit the "ready" state.
Now, where's the difference from a normal application?
Biggest fault of Netduino? It runs by electricity.

#8 tel001

tel001

    Member

  • Members
  • PipPip
  • 13 posts
  • LocationVancouver BC

Posted 17 September 2011 - 01:38 AM

You are right Mario. Whatever pull-down resistor values I used, I ran in different problems. So I gave up and approached this problem differently (that's in shown in the tutorial I've written)..

Using negative logic is really good practise, but may be Chris Walker should think about integrating it on the board instead of every project doing itself.

May be tristate buffer controlled by firmware will be best. This way ports can be kept down until become in use. Firmware will enable the actual port output on port initialization, keeping uninitialised ports down.
What do you think?


It's almost deja-vu I remember using tri-state output buffers on the 6502 in 1980! Imagine the mess that will result if on boot up, both legs on a 50 amp motor "H' driver where on! :o

I almost did a motor controller as my 1st project...thankfully my first one was a 3 watt RGB LED spotlight using 3 PWM channels and saw the white light flash on boot for myself!

I can't believe I can control this tiny board on a network and run a server on it...at 60 bucks per!! I am having lots of fun learning new stuff...all you guys are awesome :) and inspirational :) I got a 5 buck WiFi router from Free Geek and there was room inside for the Netduino+ :)

#9 georgejh

georgejh

    Advanced Member

  • Members
  • PipPipPip
  • 87 posts
  • LocationGlasgow, UK

Posted 17 September 2011 - 07:48 AM

Well, seems nobody understood my idea. It was having it controlled by the firmware so to avoid having pin states visible for connected schematics until the pins are grammatically initialised. Ideally it will be this to happen for each pin separately but that's will make schematics complex. So, very first port initialisation inside the app will enable all outputs to be visible. For example: powering up/resetting Netduino - pin output is not producing any output. Later you initialising a port inside an app and at that point netduino firmware allows port(s) output to be visible. To achieve this, I was suggesting to use a commutation device that can be switched on/off by the firmaware, which stays between current N schematics and the actual board pins. See the attached image. I am not yet looked in ARM7 Microcontroller lines that can be used to control the "enable line" but I was hoping you guys know more details and can come with some idea which ones can be used. When I found some time I would think about details of eventual solution but I am sure Mario, Chris and Stefan can come with it quicker :) Cheers

Attached Files



#10 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 17 September 2011 - 09:28 AM

George, I don't think you would solve anything more than the current situation. First off, this "enable pin" should be driven by the c# app, not automatically, because the firmware itself can't know when the I/Os are completely initialized. This "enable pin" can be realized right now, with any of the I/Os (even being pullup-ed). Secondly, what should be the state/direction of the "decoupling stage"? I mean your "boxes" drawn on the attached picture, should be in a high-Z output state until enabled? If so, consider any logic input connected to (e.g. the clock of a 74HC595). It would be left "floating" during the initialization process: that is *NOT* a good practice, because it will be a good way for the noise to enter and pushes the logic toward a unexpected behavior. If not, there should be either a pull-down, or a pull-up (or even a push-pull). This will fall into the current Atmel's context. If you remember, there are the TTL logic which allows the inputs to be left open. That's because internally they embed a pullup resistor. Thus, most of the TTL-logic was a "negative-logic", considering as "active" the low-level. Unfortunately, there's no a general way to determine what is the proper setting for a general-purpose I/O. The best choice is considering it as an input, with a weak pullup, to prevent (or limit) the unavoidable noise getting into. Hope it helps. Cheers PS: Anyway, I really love your passion on this kind of problems! PPS: there would be a problem to solve out, that might be useful for many users. I mean about the ability to place a Netduino (or well the whole circuit using N) in a sleep state, then awaking it for a while. This task should be performed periodically. Now, if you take a look at the N schematic, there's no way to put it into a low-power state (via firmware), just because there are several components being sucking current anytime. An idea could be creating a small timer (NE555?), to trigger the N to waking up. After that, should be the N program itself that turns the circuit into a lo-power mode. What do you think?
Biggest fault of Netduino? It runs by electricity.

#11 georgejh

georgejh

    Advanced Member

  • Members
  • PipPipPip
  • 87 posts
  • LocationGlasgow, UK

Posted 17 September 2011 - 05:21 PM

1. Sorry, I didn't clarify that I didn't mean to use 3state buffer with high-impedance state (I know that's the source of the problem now) . What I mean is a total cut-off from the pins of the add-on schematic until it is signaled by the "enable line". It could be anyting that behaves this way - like relays for example. Of course relays are not practicle in this case so I was thinking you may suggest/know some IC that can be controlled such way. Think for those boxes in my image as a black box which function is to totally isolate Netduino pins from outside schematics until "enable" signal comes, then this black box conducts the output form Netduino pin to outside world. You are full time for full life electronics guru and I am just a bit more than hobbyist, so I know I can count on you:)

2. I will think on the problem you are suggesting but recently I accidentally discovered a strange behavior of C106D. I was doing a replacement of the relay from the schematics I used to power on/off subsequent schematics. I knew using thyristor will give me switching on and that I will lose switching off ability, which is still fine, as longer the subsequent schematics are not powered until I send a command from the application. I decide to use simple transistor not gate - see schematics here. Well, then I realisied that this also shuts down the thyristor because when transistor is on it sinks thyristors gate current and causes a reverse current that shuts the thyristor off. Obviously when transistor is off thyristor becomes open (as expected). Well, I have a thought that you could use this to cut off Netduino's power for a period of time set by 555 and then powered in on again. This of course my require different thyristor depending on the consumption.

By the way if you want we can discuss those matters through email, messages here, on my blog or Skype/Live Messenger . Whatever method is suitable for you. I think it is better to publish here more finalised and clarified solutions than speculations thus avoiding a confusion to more experienced members. If you agree, send me a private message through the forum and we can arange the further communications.

Thanks a lot!

#12 tel001

tel001

    Member

  • Members
  • PipPip
  • 13 posts
  • LocationVancouver BC

Posted 18 September 2011 - 02:16 AM

Well, seems nobody understood my idea. It was having it controlled by the firmware so to avoid having pin states visible for connected schematics until the pins are grammatically initialised. Ideally it will be this to happen for each pin separately but that's will make schematics complex. So, very first port initialisation inside the app will enable all outputs to be visible.

For example: powering up/resetting Netduino - pin output is not producing any output. Later you initialising a port inside an app and at that point netduino firmware allows port(s) output to be visible. To achieve this, I was suggesting to use a commutation device that can be switched on/off by the firmaware, which stays between current N schematics and the actual board pins. See the attached image. I am not yet looked in ARM7 Microcontroller lines that can be used to control the "enable line" but I was hoping you guys know more details and can come with some idea which ones can be used.

When I found some time I would think about details of eventual solution but I am sure Mario, Chris and Stefan can come with it quicker :)
Cheers


I've been using 4051 Cmos analogue multiplexers to switch between eeproms, I will be using them on my next motor control board.

#13 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 18 September 2011 - 06:02 AM

@George: I had search for your email, but I didn't find it. What's the difference between 3-state high-Z state and the pin left open?
Biggest fault of Netduino? It runs by electricity.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.