gnupic: PIC18F47J53


Previous by date: 12 Aug 2013 20:10:59 -0000 Re: PIC18F47J53, KHMan
Next by date: 12 Aug 2013 20:10:59 -0000 Re: PIC18F47J53, Luis de Arquer
Previous in thread: 12 Aug 2013 20:10:59 -0000 Re: PIC18F47J53, KHMan
Next in thread: 12 Aug 2013 20:10:59 -0000 Re: PIC18F47J53, Luis de Arquer

Subject: Re: PIC18F47J53
From: Luis de Arquer ####@####.####
Date: 12 Aug 2013 20:10:59 -0000
Message-Id: <CAD_DGvkFoSDmuV2NSP00qY4kPR2JjpcfKW2Nz07GnLoHmNZnWg@mail.gmail.com>

Thanks all of you for your help.

That was indeed the reason, I had completely overlooked the analog config :S

That's the good news, the bad news for me is that I had some hope that
fixing this would point me to the right direction to fix the
apparently more-complicated problems I was having.

I'll put them here as well in case you guys are so kind to keep giving
me a hand.

Problem number 1 is surely a C issue, which is the sleep function I made:

****************************

typedef unsigned char byte;

void sleep_a_while(byte c)              /* A */
{
  byte i,j;                                           /* B */

  for(i=0; i<200; i++)
    for(j=0; j<c; j++) ;
}


**************************

Changing "byte" for "int" in any of those lines changes the timing. It
makes the sleep time not only different -which makes sense since int
is translated to int16 apparently, with its overhead-, but independent
on c (the input parameter ! ).
Probably this is something to discuss in the SDCC maillist anyway,
though the asm code looked fine. I can post it if you think it's
worth, but I'm far more worried about...

Problem 2:

This is the scary one. In the gplink line, if I change "crt0.o" by
"crt0i.o", the clock settings go random on startup. Again, I'll
probably post it in the sdcc maillist, but the crt0i.c is almost
entirely written in asm (it comes bundled with sdcc in
"device/lib/pic16/startup/", but I can post it here if you want).
So basically, the blink frequency is different with every power on
reset; sometimes visible, sometimes you need the oscilloscope.
Obviously I am not asking for anyone to dig into crt0i.c (it seems to
be the same basic stack initialization than crt0.c plus data
initialization (.cinit), reading stuff from program memory and copying
to RAM). The question is, what sort of thing could cause a random
clock setting with every hard reset? -soft reset not tested yet.

It has to be electrical, hasn't it?

Regards,

Luis



On Mon, Aug 12, 2013 at 7:13 PM, KHMan ####@####.#### wrote:
> On 8/13/2013 1:52 AM, Luis de Arquer wrote:
>>
>> Hi Bob,
>>
>> Thanks for the info, since that was something I didn't know anyway.
>>
>> As you say, that may not be the problem after all. The 'sleep_a_while'
>> function that is called in between is defined as (in C code)
>>
>> void sleep_a_while(byte c)
>> {
>>    byte i,j;
>>
>>    for(i=0; i<200; i++)
>>      for(j=0; j<c; j++) ;
>> }
>>
>> so surely it has enough time to settle.
>>
>> I have seen some examples around using lots of config words for the
>> PIC, while I am only using these:
>>
>>      CONFIG    OSC=INTOSC,WDTEN=OFF
>>
>> I have read all of the other config words and thought I don't need any
>> more, but maybe I am missing shtg?
>
>
> Not much else to eliminate...  analog config, open drain settings, etc., but
> your first example works.
>
> What happens if you toggle LATB instead? Then the datapath would not need to
> sample PORTB. Or toggle the whole byte?
>
>> On Mon, Aug 12, 2013 at 6:27 PM, Bob Jacobsen wrote:
>>>
>>> On Aug 12, 2013, at 9:58 AM, Luis de Arquer wrote:
>>> [snipped all]
>
>
> --
> Cheers,
> Kein-Hong Man (esq.)
> Kuala Lumpur, Malaysia
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>

Previous by date: 12 Aug 2013 20:10:59 -0000 Re: PIC18F47J53, KHMan
Next by date: 12 Aug 2013 20:10:59 -0000 Re: PIC18F47J53, Luis de Arquer
Previous in thread: 12 Aug 2013 20:10:59 -0000 Re: PIC18F47J53, KHMan
Next in thread: 12 Aug 2013 20:10:59 -0000 Re: PIC18F47J53, Luis de Arquer


Powered by ezmlm-browse 0.20.