Searching \ for 'needed?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=needed
Search entire site for: 'needed?'.

No exact or substring matches. trying for part
PICList Thread
'FAQ maintainer still needed?'
1994\11\07@025932 by crocontroller discussion list

flavicon
face
I remember someone saying something about the faq person was ditching.
Do you still need someone to do this?   Sorry but I am setting up a WWW
page and that would be something I would be willing to slap on it.  And
upkeep and maintain of course.

later
       John
-----------------------------------------------------------------------------
John Johnson  Team OS/2 member | spam_OUTjohnsonjTakeThisOuTspambga.com | .....johnsonjKILLspamspam@spam@utdallas.edu
-----------------------------------------------------------------------------
And the Seventh version of OS/2 raised into the air its bow of blue steel and
cried," It. Is. Done."  Around him lay Bill Gates and Microsoft apps.  Their
evil in this world at an end.
                                       Revelations of InfoWorld, Oct 11 1994


'NOP's needed??'
1998\02\27@124629 by H.P.d.Vries
flavicon
face
I've created (yet another) 4x4 matrix keyboard decode-routine.
I've placed 4 NOP's in it, because in a similar routine, they also were
there (bad reason) , but I'm not sure if they are needed.
They are there to let the output-pins when the pattern on portb is
changed. But are they nescessary?

Scan_4x4        ****************        ;OK
       CLRF    Key                     ;Returns: key value in Key
       MOVLW   .4                      ;No keypress:   Key = b'00010000'
       MOVWF   Counter
Scan_loop
       MOVF    Mask,W                  ;Mask
       MOVWF   PORTB                   ;Put mask on port
       NOP                             ;Let pins settle
       NOP                             ;But is this nescessary??
       NOP
       NOP
       NOP
       NOP
       BTFSS   PORTB,0                 ;IS first bit clear?
       RETURN                          ;Yes, so that row was pressed
       INCF    Key
       BTFSS   PORTB,1
       RETURN
       INCF    Key
       BTFSS   PORTB,2
       RETURN
       INCF    Key
       BTFSS   PORTB,3
       RETURN
       INCF    Key
       RLF     Mask,F                  ;Check next column
       DECFSZ  Counter,F
       GOTO    Scan_loop
       RETURN                          ;No keypress: Bit 4 from Key = 1.

Hans

1998\02\27@152404 by sdattalo

face
flavicon
face
Hans de Vries wrote:
>
> I've created (yet another) 4x4 matrix keyboard decode-routine.
> I've placed 4 NOP's in it, because in a similar routine, they also were
> there (bad reason) , but I'm not sure if they are needed.
> They are there to let the output-pins when the pattern on portb is
> changed. But are they nescessary?


There are several factors that affect this decision, however just
to be safe I would leave them in but change them to goto's:

{Quote hidden}

         goto    $+1                     ;Let pins settle
         goto    $+1                     ;But is this nescessary??
         goto    $+1
>         BTFSS   PORTB,0                 ;IS first bit clear?
>         RETURN                          ;Yes, so that row was pressed

So you get the same delay for half the instructions. Another trick
to get the 6-cycle delay is to do this:

>         MOVWF   PORTB                   ;Put mask on port
         CALL    a_return                ;Let pins settle
         goto    $+1                     ;But is this nescessary??

>         BTFSS   PORTB,0                 ;IS first bit clear?
a_return: RETURN                          ;Yes, so that row was pressed


If you have other delays then they can be grouped together:

delay_6:  NOP
delay_5:  NOP
delay_4:  RETURN

And then if you need a delay of 6 cycles, just add a 'CALL delay_6'
>         MOVWF   PORTB                   ;Put mask on port
         CALL    delay_6                 ;Let pins settle
                                         ;But is this nescessary??

>         BTFSS   PORTB,0                 ;IS first bit clear?
>         RETURN                          ;Yes, so that row was pressed




Payson posted something similar to this a good while back. Perhaps
you care to elaborate John?

Scott


'[PIC]: External pull up needed?'
2001\11\21@160918 by Eoin Ross
flavicon
face
I am about to utilise a 16HV540 in a circuit, I will be using a supervisory circuit to check the battery level that pulls a pin low - this is to be placed on of the low voltage pins of the PIC.

From the data sheet it appears I need to pull up the pin with a resistor as these PICs don't have internal ones like the  16F8XX series - am I correct?

THe 16HV540 is basically a 16C54 with an internal regulator.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body



'[EE]: Cap needed?'
2004\07\02@094923 by Josh Koffman
face picon face
Hi all. I did something stupid. I'm building a little audio ADC, and I
have a 1uF cap inline with the output of an opamp that drives the ADC
chip. Problem is...I didn't order the 1uF SMT cap I need. I believe
this is just a DC blocking cap. Should I just short the pads on the
board (eliminating the cap), or should I substitute a .1uF cap, which
I do have on hand?

Thanks,

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\07\02@095338 by Robert B.

flavicon
face
I wouldn't short the pads, it will send any DC offset along to the ADC
thereby distorting the audio signal.  If you must, use a 0.1uf cap instead.
It will cut down the 3db point somewhat though, so replace it with a 1uf
when you get the part in.


{Original Message removed}

2004\07\02@223440 by Richard Graziano

picon face
Substitute the 0.1 uF cap.  Chances are that it will pass the entire audio
spectrum.  You can probably calculate the bandpass characteristic.  My guess
is that it will work just dandy.  I would appreciate your feedback one way
or another, just out of interest.
{Original Message removed}

2004\07\02@224100 by Richard Graziano

picon face
One other thing I forgot to mention.  When driving an ADC it is usually
important to drive it with as low an impedance as possible in order to avoid
alisaing.  Of course all ADC's are not the same so you should review the ADC
specs.  On rereading your application, I realized that it was coupling to
the ADC input.  I wonder what the input circuit is like.  It is possible, on
second thought, that you may need a larger value than the 0.1 uF, depending
on other input parameters.
{Original Message removed}

2004\07\02@225139 by Josh Koffman

face picon face
Sadly, I won't be able to report much. I managed to find some rather
small 1uF through hole caps and tacked them to the surface mount pads.
Not as clean looking as I'd like, but then, I'm likely the only one to
ever notice.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams


On Fri, 2 Jul 2004 22:34:41 -0400, Richard Graziano
<.....rgrazia1KILLspamspam.....rochester.rr.com> wrote:
> Substitute the 0.1 uF cap.  Chances are that it will pass the entire audio
> spectrum.  You can probably calculate the bandpass characteristic.  My guess
> is that it will work just dandy.  I would appreciate your feedback one way
> or another, just out of interest.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\07\02@234504 by Josh Koffman

face picon face
Well, at the moment, it's a moot point as it's not working heh. Guess
I'm going in to work tomorrow (as that's where my scope is). Ah well.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

On Fri, 2 Jul 2004 22:41:53 -0400, Richard Graziano
<EraseMErgrazia1spam_OUTspamTakeThisOuTrochester.rr.com> wrote:
> One other thing I forgot to mention.  When driving an ADC it is usually
> important to drive it with as low an impedance as possible in order to avoid
> alisaing.  Of course all ADC's are not the same so you should review the ADC
> specs.  On rereading your application, I realized that it was coupling to
> the ADC input.  I wonder what the input circuit is like.  It is possible, on
> second thought, that you may need a larger value than the 0.1 uF, depending
> on other input parameters.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


'[TECH] Software tag needed? <-- Re: EE Change CRC '
2008\07\14@190508 by Apptech
face
flavicon
face
Crosspost.
Change to [TECH] tag
New subject line.

_______________________

I suggest that this discussion should be being held in TECH

as it relates to whether material belongs in TECH or
elsewhere. AND the subject line needs changing.

What say any responses are posted there? I'll
dual post this and with a changed subject line.


> My issue is this:

> An EE doesn't have to deal with TECH: or OT: garbage if he
> doesn't want to.
> The poor SE has no choice. ...


Having carefully read that, my original comment applies.

Core:

{Quote hidden}

I generally agree with your arguments. There may well be
many others who agree. It seems likely that such material
will be migrating out of EE (not my choice except as 1 of N
members). Letting the new arrangement settle down and then
seeing how people feel.

James argued for years that a proliferation of tags would
lead to administrative nightmares AND a demand for still
more tags. He may or may not prove right on the first point.
He seems to be being proven right on the second.



           Russell


2008\07\14@194443 by Bob Blick

face
flavicon
face
Random thoughts. How can this be made into one coherent sentence?

If it's embedded related software engineering, it goes in [EE].

Discussions about a Delphi app you are writing to connect to your
embedded processor are definitely [EE] - you are writing a program.

Discussions about Bray's Terminal connecting to your embedded processor
are barely [EE] even though it's an application, but you are solving a
problem related to interfacing the two.

If you are writing a web app that interfaces to hardware you made, it's
[EE] if you are discussing the interfacing part (either hardware or
software).

If you are writing a web app for e-commerce, it's not [EE].

If it's about Visio or backup software, it's not [EE].

Adding a software engineering tag doesn't make sense to me. Non-embedded
software seems [OT] because it's incidental to the piclist - people who
do software engineering that isn't embedded related have other hangouts
for that stuff more suited to it than the piclist.


Cheerful regards,

Bob



On Tue, 15 Jul 2008 11:02:53 +1200, "Apptech" <apptechspamspam_OUTparadise.net.nz>
said:
{Quote hidden}

> --

2008\07\14@204114 by Bob Ammerman

picon face
> Adding a software engineering tag doesn't make sense to me. Non-embedded
> software seems [OT] because it's incidental to the piclist - people who
> do software engineering that isn't embedded related have other hangouts
> for that stuff more suited to it than the piclist.
>
>
> Cheerful regards,
>
> Bob

Sounds more than good to me.

I withdraw my (not really made as such) request for another tag :-)

I just got my dander up when it looked like the peripheral software topics
were going to be treated differently from the peripheral hardware topics.

So I read [EE] as 'embedded engineering', *NOT* 'electrical engineering'

--- Bob Ammerman
RAm Systems

2008\07\15@085751 by olin piclist

face picon face
Bob Ammerman wrote:
> So I read [EE] as 'embedded engineering', *NOT* 'electrical
> engineering'

Right, which is why I suggest the name be changed to EMB to avoid this
confusion.  The EE tag is now in its third definition.  Most people looking
at it casually would naturally assume Electrical Engineering, which is now
incorrect.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\07\15@092000 by Apptech

face
flavicon
face
> Bob Ammerman wrote:
>> So I read [EE] as 'embedded engineering', *NOT*
>> 'electrical
>> engineering'

> Right, which is why I suggest the name be changed to EMB
> to avoid this
> confusion.  The EE tag is now in its third definition.
> Most people looking
> at it casually would naturally assume Electrical
> Engineering, which is now
> incorrect.

I disagree, not surprisingly :-).
People can read it as embedded engineering if it fits their
paradigms better. Others as electrical engineering. Both
will tend to work OK when most people settle into knowing
what it is generally about. It's hardly rocket science. If
it has PICs it's PIC. If Bob doesn't like it it's TECH.
Sounds easy to me :-).

Slightly more seriously, "embedded engineering" is a
specialist term which may fit the mental filters of people
to whom embedded engineering is more natural than breathing,
BUT the term "electrical engineering" is liable to resonate
with a far wider crowd. If someone is plugging transistors
into a breadboard or soldering things on "vero" / vector /
strip board and want to talk about them then EE is where the
talking belongs. To call that embedded engineering is to
take an elitist approach and suggest that if it hasn't got a
processor in it then it doesn't belong.  Which MAY be what
eg Olin intends, but it's a rather greater jump than I
suspect most minds construed when it was suggested that EE
be "purified".


       Russell


'[PIC] interlocks needed?'
2008\10\15@203718 by Dr Skip
picon face
While I await my brand new shiny pickit2, I'm going over a design I have that's
a one-off project. I thought I'd tap the experience of the list on something.

One of the lines has to control a pair of lines for forward/reverse control of
a high torque, high speed motor (simplified version). Major damage would result
if both lines came on at the same time, or if it switched too fast (while in
motion). To prevent simultaneous 'on', it'll drive a SPDT relay - only one
state at a time. Power (through another relay) will only be applied after the
direction relay has been set (timed, not through feedback). Both power and
direction will be driven from a pic. Reversing while in motion will cause much
damage, but it isn't human injury. Direction and on/off are controlled by the pic.

If it were a human injury problem, I'd have to put in some sort of interlock to
prevent problems. The question is, given power glitches, pic issues, power up,
etc, what transients do I need to watch for on the pic outputs or what
experiences tell you that in this case, a secondary mechanism is needed? If the
failure mode of the outputs is to all turn off, no worries then. I'm more
concerned about a situation where power is on and it's running and some
condition causes the other (direction control line) output to change state,
even for a few mS. I'd like to foresee as many contingencies as possible.

I also need to know how outputs respond if power to the pic is lost. Are there
any pulses or transients that outputs have or do they just fall to 0 (in real
experience)?

Thanks,
Skip

2008\10\15@211353 by Xiaofan Chen

face picon face
On Thu, Oct 16, 2008 at 8:37 AM, Dr Skip <@spam@drskipKILLspamspamgmail.com> wrote:
> If it were a human injury problem, I'd have to put in some sort of interlock to
> prevent problems. The question is, given power glitches, pic issues, power up,
> etc, what transients do I need to watch for on the pic outputs or what
> experiences tell you that in this case, a secondary mechanism is needed?

You may have to look at much more than what you described.
This is so called a machine safety application and you may
have to go through certification like SIL 3. Not an easy task
for an small organization.

One link for you for the safety product.
http://www.ab.com/safety/
Disclaim: I am working for this company.

Xiaofan

2008\10\15@213334 by Jinx

face picon face
One fail-safe might be to use the PIC to drive one-shots with regular
pulses. Period between the pulses is shorter than the time-out period
of the one-shot. If the PIC fails, so do the pulses and the one-shot will
time out. There *shouldn't* be power-up glitches if PWRTE,  /mclr,
etc are used properly

You might want to measure the activity of the motor before switching
it. eg detect rpm or use some sort of sense element that you can measure
the voltage of or across

2008\10\15@213532 by Michael Algernon

flavicon
face
>
> On Oct 15, 2008, at 6:37 PM, Dr Skip wrote:
>
> While I await my brand new shiny pickit2, I'm going over a design I  
> have that's
> a one-off project. I thought I'd tap the experience of the list on  
> something.
>
> One of the lines has to control a pair of lines for forward/reverse  
> control of
> a high torque, high speed motor (simplified version). Major damage  
> would result
> --snip--
>
> Thanks,
> Skip
-- If this is one off and major damage could occur, I recommend a  
front end that is not associated with the PIC that prevents disallowed  
states for the motor.
for example:  You could have a  circuit that controls a relay or FET  
that disables power when a reversal command occurs.  It would disable  
power until the motor comes to a halt.  ( I am ignoring any braking  
circuitry you might have ).  If you are interested I could sketch up a  
non-microcontroller design that does this.
If your PIC design has a x% chance of failure and this front end  
circuit has a .01% chance of failure , your total failure rate would  
be approximately .0001x.
Michael

2008\10\16@010032 by Dr Skip

picon face
Thanks for the offer (and all for the replies). I can whip something up, since
it sounds like it's a generally good idea. I felt I should probably do
something like that, but wanted to verify that it just wasn't my mistrust of
the little chip. I've been doing hardware since the time when paper tape
readers were a 'fancy' peripheral (long before the PC) and CPUs were bit-sliced
ALUs in TTL, so I'm glad it wasn't just my Neanderthal, pre-pic bred worries... ;)

-Skip



Michael Algernon wrote:
{Quote hidden}

2008\10\16@100235 by Eoin Ross

flavicon
face
I recently made a 'system' where I had two pumps that could not run at the same time. It ended up with a mechanical interlock between the two contactors, and a delay-off timer that cut power to both start buttons.

In your case I'd still put an interlock in to prevent damage - downtime can cost more than the physical damage in some processes. Depending on what you are driving it might be cheap enough to change out the motor controls to provide the mechanical end.

12 Amp Contactors ~$50 each (With overloads added)
http://web1.automationdirect.com/adc/Shopping/Catalog/Motor_Controls/Fuji_Contactors_-z-_Overloads/9_to_25_Amp/SC-E04-24VAC

Mechanical interlock ~$11
http://web1.automationdirect.com/adc/Shopping/Catalog/Motor_Controls/Fuji_Contactors_-z-_Overloads/9_to_25_Amp/SZ-RM


>>> Dr Skip <KILLspamdrskipKILLspamspamgmail.com> 15 Oct 08 20:37:11 >>>
While I await my brand new shiny pickit2, I'm going over a design I have that's
a one-off project. I thought I'd tap the experience of the list on something.

One of the lines has to control a pair of lines for forward/reverse control of
a high torque, high speed motor (simplified version). Major damage would result
if both lines came on at the same time, or if it switched too fast (while in
motion). To prevent simultaneous 'on', it'll drive a SPDT relay - only one
state at a time. Power (through another relay) will only be applied after the
direction relay has been set (timed, not through feedback). Both power and
direction will be driven from a pic. Reversing while in motion will cause much
damage, but it isn't human injury. Direction and on/off are controlled by the pic.

If it were a human injury problem, I'd have to put in some sort of interlock to
prevent problems. The question is, given power glitches, pic issues, power up,
etc, what transients do I need to watch for on the pic outputs or what
experiences tell you that in this case, a secondary mechanism is needed? If the
failure mode of the outputs is to all turn off, no worries then. I'm more
concerned about a situation where power is on and it's running and some
condition causes the other (direction control line) output to change state,
even for a few mS. I'd like to foresee as many contingencies as possible.

I also need to know how outputs respond if power to the pic is lost. Are there
any pulses or transients that outputs have or do they just fall to 0 (in real
experience)?

Thanks,
Skip


More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...