Searching \ for '[PIC] Problem getting PIC18 to work under C18' 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/microchip/devices.htm?key=pic
Search entire site for: 'Problem getting PIC18 to work under C18'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Problem getting PIC18 to work under C18'
2010\07\19@190245 by Andrew Wood

flavicon
face
 Ok Ive modified the code to address some of the problems.
Ive set port A as an output, Ive set port B pin 4 as an input and all
other pins as outputs, and Ive changed the line that tests port B pin 4
to check if PORTB==16 which by my reakoning should represent pin4 high
all others low? The complete code follows at the bottom

Now regarding the following:

"What pulls RB4 LOW when the switch is open? It looks like it will be

left floating (undefined)"


I cant figure out how I would wire this without using a changeover relay
as the switch?

The problem Im currently having is that closing the switch to bring port
B pin 4 high doesnt have the effect of bringing on the other two LED's
it instead seems to casue the PIC to reset.




#include <p18f13k50.h>


unsigned long int counter;
unsigned long int counter2;

void main (void)
{
             TRISA=0; //set portA as output for safety as we're not
using it at the moment
            TRISB=16; //use portB pin 4 as input, all other pins as
output for safety as we're not using them
            TRISC=0; //use portC as output
            LATC=0;
            ANSEL=0;
            ANSELH=0;

            while (1)
            {
                //turn on orange LED
                 LATCbits.LATC1 = 1;

                if (PORTB==16) //if go wire high
                 {

                      //turn on green LED
                       LATCbits.LATC0=1;

                    for (counter=0; counter < 100000; counter++)
                    {

                    }

                    //operate red LED
                    LATCbits.LATC2=1;

                    for (counter=0; counter < 100000; counter++)
                    {

                    }

                    //turn off red LED
                    LATCbits.LATC2=0;
                    //turn off green LED
                       LATCbits.LATC0=0;
                }
            }
}




2010\07\19@192450 by sergio masci

flavicon
face


On Tue, 20 Jul 2010, Andrew Wood wrote:

{Quote hidden}

With both these LEDs turned on you might be drawing too much current from
your power supply causing the voltage to dip and reset the PIC. Don't know
just a shot in the dark.

Try disconnecting one of the LEDs and see if that makes any difference.
Maybe try increasing the limit resisters.

Regards
Sergio Masci

2010\07\19@192833 by Oli Glaser

flavicon
face
Looking at the schematic, you still don't have a decoupling capacitor
between Vdd and Vss.
Also as mentioned there is no pull down on RB4, so it's floating till you
push the button.

Since the PIC you are using has weak pull ups available, it might be an idea
to enable the weak pull up on RB4 and wire the button to Vss instead. Or
just add a pull down resistor to Vss in your current circuit.

With your code, is that all of it? As there are no config bit settings - if
you are setting these in MPLAB make sure the "config bits set in code" is
not ticked and everything is set correctly.

--------------------------------------------------
From: "Andrew Wood" <spam_OUTajwoodTakeThisOuTspamtheiet.org>
Sent: Tuesday, July 20, 2010 12:02 AM
To: "Microcontroller discussion list - Public." <.....piclistKILLspamspam@spam@mit.edu>
Subject: Re: [PIC] Problem getting PIC18 to work under C18

{Quote hidden}

> --

2010\07\19@193052 by Jan-Erik Soderholm

face picon face


On 2010-07-20 01:02, Andrew Wood wrote:
>    Ok Ive modified the code to address some of the problems.
> Ive set port A as an output, Ive set port B pin 4 as an input and all
> other pins as outputs, and Ive changed the line that tests port B pin 4
> to check if PORTB==16

Would not "PORTCbits.PORTC2==1" be a more correct way to check that ?

I don't know, it just seems more in line with your previous
test on LATC. And I guess there must be some way to test on
a single pin, your test depends on all other pins beeing
at a know state.

Also note that your test "if (PORTB==16)" depends on all
other pins beeing "0". But you have no idea what state
they are in ! After a reset they are "undefined" and since
you never sets PORTB (or LATB) to anything you doesn't know.

It could work if you set PORTB = 0 somewhere, but it's much
better to only test the specific pin, not the whole port.

{Quote hidden}

No. You have one "pulldown" resistor keeping the pin at GND until
someone push the buttom (connecting the pin to 5V). That way the
pin will never be "floating", it will either be pulled to GND by
the resitor or be connected to 5V by the switch.

Note that a two-way switch (no matter if it's a manual switch or
a relay) will not work, there will still be a short time when the
pin will be floating between the two states. If not, the switch (or
relay) would short 5V to GND, and that is no good. :-)

>
> The problem Im currently having is that closing the switch to bring port
> B pin 4 high doesnt have the effect of bringing on the other two LED's
> it instead seems to casue the PIC to reset.

How is things connectet *now* ?

A few other minor notes...

> TRISB=16

Do use binary values !
It's damn hard to tell if you say "TRISB=79" which
pin is input and which is output ! This was also mentioned
in another reply. Please read all replies. If you insist to
do against some recomendation, please say why so you do not
have to get the same comment once again.




{Quote hidden}

2010\07\19@194121 by Bob Blick

face
flavicon
face

On Tue, 20 Jul 2010 00:02:51 +0100, "Andrew Wood" said:
>   Ok Ive modified the code to address some of the problems.
> Ive set port A as an output, Ive set port B pin 4 as an input and all
> other pins as outputs, and Ive changed the line that tests port B pin 4
> to check if PORTB==16 which by my reakoning should represent pin4 high
> all others low? The complete code follows at the bottom

Yes, but if all you care about is RB4 then you really should just test
that bit.

Either use standard "C" methods with bit operands
if (PORTB & 0x10)

or use compiler-specific ones that use bit-width representations of the
pin.

> Now regarding the following:
>
> "What pulls RB4 LOW when the switch is open? It looks like it will be
>
> left floating (undefined)"
>
>
> I cant figure out how I would wire this without using a changeover relay
> as the switch?

That's what a pulldown resistor would do. The switch pulls high, the
resistor pulls low.

You might want to get the schematic for a PIC demo board and see how
things tend to get wired up. The Microchip ones are all readily
available to download.

Cheers,

Bob

--
http://www.fastmail.fm - Email service worth paying for. Try it for free

2010\07\19@194404 by Oli Glaser

flavicon
face


--------------------------------------------------
From: "Jan-Erik Soderholm" <jan-erik.soderholmspamKILLspamtelia.com>
Sent: Tuesday, July 20, 2010 12:30 AM
To: "Microcontroller discussion list - Public." <.....piclistKILLspamspam.....mit.edu>
Subject: Re: [PIC] Problem getting PIC18 to work under C18

> Also note that your test "if (PORTB==16)" depends on all
> other pins beeing "0". But you have no idea what state
> they are in ! After a reset they are "undefined" and since
> you never sets PORTB (or LATB) to anything you doesn't know.
> A few other minor notes...

Good point here, just checking the individual bit is far more likely to work
properly.


> > TRISB=16
>
> Do use binary values !
> It's damn hard to tell if you say "TRISB=79" which
> pin is input and which is output ! This was also mentioned
> in another reply. Please read all replies. If you insist to
> do against some recomendation, please say why so you do not
> have to get the same comment once again.

Agreed here - I like to use something like TRISB = 0b00010000;
A lot easier to see which pins are set to what at a glance, without having
to visualise stuff mentally.


2010\07\19@195457 by ivp

face picon face
> PORTB==16 which by my reckoning should represent pin4 high

Yes, it does, if you're using decimal

'16' is ambiguous. b'00010000' is a numerical picture of the port
pins, or even 0x10 gives the reader more information

Joe

*
*
**********
Quality PIC programmers
http://www.embedinc.com/products/index.htm

2010\07\19@195903 by ivp

face picon face
> With your code, is that all of it? As there are no config bit settings -
> if you are setting these in MPLAB make sure the "config bits set in
> code" is not ticked and everything is set correctly

I've learned over the years that not setting the micro up properly,
even if it's tedious and holds you up getting to the fun stuff, is no
time-saver

Joe

*
*
**********
Quality PIC programmers
http://www.embedinc.com/products/index.htm


2010\07\19@205002 by ivp

face picon face
part 1 1273 bytes content-type:text/plain; format=flowed; charset="iso-8859-1"; (decoded 7bit)

> I cant figure out how I would wire this without using a changeover
> relay as the switch?

Andrew, attached are 3 ideas that apply to any mechanical input
such as switches, pushbuttons, relays, whatever

Fig1 shows a changeover toggle switch (single-pole double-throw, or
SPDT, 1P2T). Note that toggle switches come in make-before-break
and break-before-make varieties. M-b-b would caused a momentary
short of Vss to Vdd. B-b-m would cause a momentary float of the
input pin. Neither of those scenarios are best practice. And if the
switch fails, the pin could be left permanently floating

Fig2 includes an external resistor to ensure that the pin always has
at least one defined state, whether the switch is in transit or fails. I
think most people would chose something in the range 10k to 100k

Fig3, the same, using an internal pull-up

Parameter D070 in Section 27.4 of the 18F13K50 datasheet states
that the pull-up current is typically 250uA. This can be expressed as
an equivalent resistance at 5V supply

V = I * R
5 = 0.000250 * R
R = 20,000 ohms

Both Fig2 and Fig3 can use a single-pole single-throw (SPST)
switch or pushbutton

Joe

*
*
**********
Quality PIC programmers
http://www.embedinc.com/products/index.htm


part 2 884 bytes content-type:image/gif; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2010\07\20@074952 by Olin Lathrop

face picon face
Andrew Wood wrote:
>              TRISB=16; //use portB pin 4 as input, all other pins as

While this is technically correct it would be better to write:

 TRISB = 0b00010000;

to show the bits since the value is really a bit mask.  The fact that it
happens to be 16 when expressed as a binary integer is immaterial, and
therefore misleading to show it that way.


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

2010\07\20@100636 by Andrew Wood

flavicon
face
 On 20/07/2010 00:30, Jan-Erik Soderholm wrote:
> Would not "PORTCbits.PORTC2==1" be a more correct way to check that ?

Do you mean (PORTBbits.PORTB4==1) I want to test port b pin 4 not port c
pin 2, however the compiler doesnt like that.--  "unknown member 'PORTB4"

Ive added a decoupling cap across the power supply. The reason I didnt
have one before is because Im using a small plug in 5v PSU which I would
have expected to have a decoupling cap in it.  When the circuit is
finished it will be powered by a separate power board which will have a
7805 with decoupling caps on it, but Im still waiting for the 7805s to
arrive.

Ive modifed the input on port b pin 4 to match Fig 2 in Joes diagram so
that its normally connected to GND via a 10k resistor.

On 20/07/2010 00:43, Oli Glaser wrote:
> I like to use something like TRISB = 0b00010000;
> A lot easier to see which pins are set to what at a glance, without having
> to visualise stuff mentally."
>
Good idea I'll start doing that.

Just need to fix the code issue now about how to test port B pin 4.
Hadnt occured to me before that with the other pins floating I couldnt
guarantee they'd be 0


2010\07\20@102702 by Bob Blick

face
flavicon
face

On Tue, 20 Jul 2010 15:06:40 +0100, "Andrew Wood" said:

> Ive added a decoupling cap across the power supply. The reason I didnt
> have one before is because Im using a small plug in 5v PSU which I would
> have expected to have a decoupling cap in it.  When the circuit is
> finished it will be powered by a separate power board which will have a
> 7805 with decoupling caps on it, but Im still waiting for the 7805s to
> arrive.

Two inches is too far to go without a decoupling capacitor.

If you like to read I might suggest it's time for you to buy a copy of
The Art of Electronics or something similar, there are many gaps in your
electronics knowledge and you would find it useful to have read a
general text from cover to cover.

Best regards,

Bob

--
http://www.fastmail.fm - IMAP accessible web-mail

2010\07\20@104425 by Oli Glaser

flavicon
face


--------------------------------------------------
From: "Andrew Wood" <EraseMEajwoodspam_OUTspamTakeThisOuTtheiet.org>
Sent: Tuesday, July 20, 2010 3:06 PM
To: "Microcontroller discussion list - Public." <piclistspamspam_OUTmit.edu>
Subject: Re: [PIC] Problem getting PIC18 to work under C18

>  On 20/07/2010 00:30, Jan-Erik Soderholm wrote:
>> Would not "PORTCbits.PORTC2==1" be a more correct way to check that ?
>
> Do you mean (PORTBbits.PORTB4==1) I want to test port b pin 4 not port c
> pin 2, however the compiler doesnt like that.--  "unknown member 'PORTB4"

IIRC, with C18 it's probably something like PORTBbits.RB4. You can always
check in the header file for the processor to see how stuff is named.


> Ive added a decoupling cap across the power supply. The reason I didnt
> have one before is because Im using a small plug in 5v PSU which I would
> have expected to have a decoupling cap in it.  When the circuit is
> finished it will be powered by a separate power board which will have a
> 7805 with decoupling caps on it, but Im still waiting for the 7805s to
> arrive.

It's good practice to use decoupling caps as near to the PIC power pins as
possible regardless of any decoupling/power supply caps elsewhere in the
circuit, so I would get into the practice of putting them in as standard.
This is not particular to PICs, but with circuit design in
general(especially with digital switching and fast rise/fall times).
The caps near to the pins help to keep the immediate supply clean and also
stop any current draw coupling into other components supply(hence
decoupling)
There is plenty of decent info to be had with Google on the subject, as the
above explanation is not particularly detailed/exact.


{Quote hidden}

> --

2010\07\20@104530 by Jan-Erik Soderholm

face picon face


On 2010-07-20 16:06, Andrew Wood wrote:
>    On 20/07/2010 00:30, Jan-Erik Soderholm wrote:
>> Would not "PORTCbits.PORTC2==1" be a more correct way to check that ?
>
> Do you mean (PORTBbits.PORTB4==1) I want to test port b pin 4 not port c
> pin 2, however the compiler doesnt like that.--  "unknown member 'PORTB4"
>

Whatever...

My point was to read/test the actual pin instead of the whole port.
I've no idea how one do that. That is what the documentation is for.

2010\07\20@110048 by Herbert Graf

picon face
On Tue, 2010-07-20 at 07:50 -0400, Olin Lathrop wrote:
> Andrew Wood wrote:
> >              TRISB=16; //use portB pin 4 as input, all other pins as
>
> While this is technically correct it would be better to write:
>
>   TRISB = 0b00010000;
>
> to show the bits since the value is really a bit mask.  The fact that it
> happens to be 16 when expressed as a binary integer is immaterial, and
> therefore misleading to show it that way.

I agree.

Even worse, the =16 assumes base 10, which might be 100% correct for the
compiler you are using today, but isn't necessarily the case with
something you use tomorrow. Bug waiting to happen IMHO.

TTYL

2010\07\20@122652 by Isaac Marino Bavaresco

flavicon
face
Em 20/7/2010 12:00, Herbert Graf escreveu:
> On Tue, 2010-07-20 at 07:50 -0400, Olin Lathrop wrote:
>> Andrew Wood wrote:
>>>              TRISB=16; //use portB pin 4 as input, all other pins as
>> While this is technically correct it would be better to write:
>>
>>   TRISB = 0b00010000;
>>
>> to show the bits since the value is really a bit mask.  The fact that it
>> happens to be 16 when expressed as a binary integer is immaterial, and
>> therefore misleading to show it that way.
> I agree.
>
> Even worse, the =16 assumes base 10, which might be 100% correct for the
> compiler you are using today, but isn't necessarily the case with
> something you use tomorrow. Bug waiting to happen IMHO.
>
> TTYL

Only if he ports the code to another language, C always uses base 10
unless specific prefixes are added ( "0" for octal, "0x" for
hexadecimal. "0b" and "b'xxx'" are compiler specific extensions,
standard C doesn't support binary notation).

This may be a concern with Microchip's assembly, because the radix of a
non-prefixed number may be changed by the directives "radix" or "list".
It was a really stupid decision to make hexadecimal the default radix
and also use the '.' as a prefix for decimal numbers ( .10 is decimal
ten, not one tenth :p ). Why did they need to be different than
everybody else?

Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/

2010\07\20@130418 by Bob Ammerman

flavicon
face
>This may be a concern with Microchip's assembly, because the radix of a
>non-prefixed number may be changed by the directives "radix" or "list".
>It was a really stupid decision to make hexadecimal the default radix
>and also use the '.' as a prefix for decimal numbers ( .10 is decimal
>ten, not one tenth :p ). Why did they need to be different than
>everybody else?

Many early assemblers were very similar to the way MPASM works with radices.
For example Data General Nova assembler had a .RADIX pseudo-op that would
allow you to change the default radix to anything from 2 to 36. The amusing
thing is that the statement:

       .RADIX 10

was always a NOP because its argument was always evaluated in the current
radix, and 10 in any radix is the radix itself!

-- Bob Ammerman
RAm Systems

2010\07\20@143047 by Isaac Marino Bavaresco

flavicon
face
Em 20/7/2010 11:06, Andrew Wood escreveu:
>   On 20/07/2010 00:30, Jan-Erik Soderholm wrote:
>> Would not "PORTCbits.PORTC2==1" be a more correct way to check that ?
> Do you mean (PORTBbits.PORTB4==1) I want to test port b pin 4 not port c
> pin 2, however the compiler doesnt like that.--  "unknown member 'PORTB4"

Although "TRISBbits" fields are named "TRISBn", "PORTBbits" fields are
named "RBn".

Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/

2010\07\20@143710 by Isaac Marino Bavaresco

flavicon
face
Em 20/7/2010 11:06, Andrew Wood escreveu:
> Ive added a decoupling cap across the power supply. The reason I didnt
> have one before is because Im using a small plug in 5v PSU which I would
> have expected to have a decoupling cap in it.  When the circuit is
> finished it will be powered by a separate power board which will have a
> 7805 with decoupling caps on it, but Im still waiting for the 7805s to
> arrive.

The decoupling caps must be *very close* to the chip's power pins (not
only geometric distance but electric distance also, i.e.: short track
lengths), not in another board with wire between them.
If the chip has several VDD and VSS pairs, you must use one cap for each
pair.

Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/

2010\07\20@192212 by Andrew Wood

flavicon
face
Many thanks to all of you who have helped out. Its now working, thanks
to a decoupling cap on the reset wire which has stopped it spuriously
resetting.

Thank you for all the suggestions.  If any of you are ever in the
midlands, UK pop into our telecoms museum and have a look :)

Regards
Andrew





On 20/07/10 17:24, Isaac Marino Bavaresco wrote:
{Quote hidden}

2010\07\20@203659 by ivp

face picon face
part 1 900 bytes content-type:text/plain; format=flowed; charset="iso-8859-1"; (decoded 7bit)

> decoupling cap on the reset wire which has stopped it spuriously resetting

IIRC /mclr is tied to Vdd through a 10k resistor. If it was resetting
without a filter cap that suggests significant noise on Vdd. If so, it
might be a good idea to find the source of this noise to prevent any
future problems. Perhaps there is some mechanism (eg relay, solenoid,
bulbs) elsewhere causing this noise. The PIC Vdd can be isolated and
filtered with a diode and reservoir cap, as attached. For minimum voltage
drop use a Schottky. Even a small BATxx will pass a couple of hundred
mA. The reservoir cap could be 100uF +. The general rule is 1000uF
per amp for reasonable filtering and, from what I've seen, I don't think
the PIC part of your circuitry draws more than a few 10s of mA

Joe

*
*
**********
Quality PIC programmers
http://www.embedinc.com/products/index.htm

part 2 349 bytes content-type:image/gif; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

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