Outputs on at boot
#1
Posted 14 September 2011 - 09:53 PM
#2
Posted 14 September 2011 - 10:30 PM
#3
Posted 15 September 2011 - 05:58 AM
You'd need to add an external pull-down resistor to make sure the output is logic low during Netduino startup.It seems that all the discrete outs are energized at boot up. Is there any way to avoid (or configure) this?
#5
Posted 16 September 2011 - 11:38 AM
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.You'd need to add an external pull-down resistor to make sure the output is logic low during Netduino startup.
A good practice would to use negative-logic, where "zero" is "false" and means "active".
Cheers
#6
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
Posted 16 September 2011 - 05:30 PM
The Atmel's choice is the best.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?
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?
#8
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!
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
Posted 17 September 2011 - 07:48 AM
Attached Files
#10
Posted 17 September 2011 - 09:28 AM
#11
Posted 17 September 2011 - 05:21 PM
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
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
Posted 18 September 2011 - 06:02 AM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users