(PIC) 16F887 - strange behavior

[p***@pp5ms.com]

Hi everyone,

I am developing in assembly in PIC16F887 an automation equipment for amateur radio stations. I've already done a lot of the firmware, currently occupying near 3K.
I have as practice, go doing and write on the hardware to do tests and after everything okay go ahead writing new routines.
Sometimes these tests are done 5 or 6 times a day as the firmware evolves.
I had to explain how I'm working so I can tell what's going on.
During these tests and new firmware versions, the hardware virtually stays on all the time, or when I turn off and on to test the system startup, it is a few minutes without power.
Five days have passed that something happened that I only noticed later.
Everything works perfectly, however if I turn off the power and leave it off overnight, when I turn on it is not boot.
Even if I re-write the program in the PIC it does not work anymore. However (and this is where I do not understand what happens) if I write a firmware from 5 days ago, it works. From that point on, I can re-write the latest version and it's still okay. Only if I turn power off for a long time does not work anymore when I turn on again. With the 5-day program, I can leave the power off that always comes back working at power on.
I think about some problem with the hardware, but I have several prototypes (10 actually) and they all exhibit exactly the same problem.
The impression I have is that it has some initialization that stays in RAM and it takes a long time to erase on power off and when this happens, comes the problem.
My question is: Has anyone ever had any kind of similar problem?
I'm really stuck and I think about going back to the program 5 days ago and going re-writing the program I've done again, this time doing tests closer to each new change. Maybe even the routines will be a little different end up getting a bit different and it may be that the problem does not happen anymore. But I would not be very relieved to resover in this way without knowing what actually happens.
Thanks for any feedback.
Marcus - PP5MS

[Jason White]

I would recommend writing a short loop into the start of your program that
writes zeros into user ram, general purpose/working registers, and if
applicable "certain" peripheral registers that could affect the operation
of the device.

What you describe sounds like a (lack of) initialization issue.

Post by p***@pp5ms.com
Hi everyone,
I am developing in assembly in PIC16F887 an automation equipment for
amateur radio stations. I've already done a lot of the firmware, currently
occupying near 3K.
I have as practice, go doing and write on the hardware to do tests and
after everything okay go ahead writing new routines.
Sometimes these tests are done 5 or 6 times a day as the firmware evolves.
I had to explain how I'm working so I can tell what's going on.
During these tests and new firmware versions, the hardware virtually stays
on all the time, or when I turn off and on to test the system startup, it
is a few minutes without power.
Five days have passed that something happened that I only noticed later.
Everything works perfectly, however if I turn off the power and leave it
off overnight, when I turn on it is not boot.
Even if I re-write the program in the PIC it does not work anymore.
However (and this is where I do not understand what happens) if I write a
firmware from 5 days ago, it works. From that point on, I can re-write the
latest version and it's still okay. Only if I turn power off for a long
time does not work anymore when I turn on again. With the 5-day program, I
can leave the power off that always comes back working at power on.
I think about some problem with the hardware, but I have several
prototypes (10 actually) and they all exhibit exactly the same problem.
The impression I have is that it has some initialization that stays in RAM
and it takes a long time to erase on power off and when this happens, comes
the problem.
My question is: Has anyone ever had any kind of similar problem?
I'm really stuck and I think about going back to the program 5 days ago
and going re-writing the program I've done again, this time doing tests
closer to each new change. Maybe even the routines will be a little
different end up getting a bit different and it may be that the problem
does not happen anymore. But I would not be very relieved to resover in
this way without knowing what actually happens.
Thanks for any feedback.
Marcus - PP5MS
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[smplx]

Post by Jason White
I would recommend writing a short loop into the start of your program that
writes zeros into user ram, general purpose/working registers, and if
applicable "certain" peripheral registers that could affect the operation
of the device.
What you describe sounds like a (lack of) initialization issue.

I'm 100% with Jason on this. When you power up RAM tends to contain random
stuff ***BUT*** from cold it tends to power up with the same random stuff.

Initalising to zero should help. Otherwise try 0xff and see if that helps.

Regards
Sergio Masci

[PP5MS - Marcus]

Hi Sergio,
Yes, I will do with 0x00 and 0xFF
Thank you for the suggestion to do with these two numbers.
I will return to tell the results
Marcus

-----Mensagem original-----
De: piclist-***@mit.edu [mailto:piclist-***@mit.edu] Em nome de
smplx
Enviada em: quinta-feira, 22 de novembro de 2018 01:20
Para: Microcontroller discussion list - Public.
Assunto: Re: (PIC) 16F887 - strange behavior

Post by Jason White
I would recommend writing a short loop into the start of your program
that writes zeros into user ram, general purpose/working registers,
and if applicable "certain" peripheral registers that could affect the
operation of the device.
What you describe sounds like a (lack of) initialization issue.

I'm 100% with Jason on this. When you power up RAM tends to contain random
stuff ***BUT*** from cold it tends to power up with the same random stuff.

Initalising to zero should help. Otherwise try 0xff and see if that helps.

Regards
Sergio Masci
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change
your membership options at http://mailman.mit.edu/mailman/listinfo/piclist

[PP5MS - Marcus]

Hi Jason,
Thank you for the suggestion.
I will do this today and will came back here to tell the results.
Marcus

-----Mensagem original-----
De: piclist-***@mit.edu [mailto:piclist-***@mit.edu] Em nome de
Jason White
Enviada em: quarta-feira, 21 de novembro de 2018 22:24
Para: Microcontroller discussion list - Public.
Assunto: Re: (PIC) 16F887 - strange behavior

I would recommend writing a short loop into the start of your program that
writes zeros into user ram, general purpose/working registers, and if
applicable "certain" peripheral registers that could affect the operation of
the device.

What you describe sounds like a (lack of) initialization issue.

Post by p***@pp5ms.com
Hi everyone,
I am developing in assembly in PIC16F887 an automation equipment for
amateur radio stations. I've already done a lot of the firmware,
currently occupying near 3K.
I have as practice, go doing and write on the hardware to do tests and
after everything okay go ahead writing new routines.
Sometimes these tests are done 5 or 6 times a day as the firmware evolves.
I had to explain how I'm working so I can tell what's going on.
During these tests and new firmware versions, the hardware virtually
stays on all the time, or when I turn off and on to test the system
startup, it is a few minutes without power.
Five days have passed that something happened that I only noticed later.
Everything works perfectly, however if I turn off the power and leave
it off overnight, when I turn on it is not boot.
Even if I re-write the program in the PIC it does not work anymore.
However (and this is where I do not understand what happens) if I
write a firmware from 5 days ago, it works. From that point on, I can
re-write the latest version and it's still okay. Only if I turn power
off for a long time does not work anymore when I turn on again. With
the 5-day program, I can leave the power off that always comes back

working at power on.

Post by p***@pp5ms.com
I think about some problem with the hardware, but I have several
prototypes (10 actually) and they all exhibit exactly the same problem.
The impression I have is that it has some initialization that stays in
RAM and it takes a long time to erase on power off and when this
happens, comes the problem.
My question is: Has anyone ever had any kind of similar problem?
I'm really stuck and I think about going back to the program 5 days
ago and going re-writing the program I've done again, this time doing
tests closer to each new change. Maybe even the routines will be a
little different end up getting a bit different and it may be that the
problem does not happen anymore. But I would not be very relieved to
resover in this way without knowing what actually happens.
Thanks for any feedback.
Marcus - PP5MS
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--
Jason White
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change
your membership options at http://mailman.mit.edu/mailman/listinfo/piclist

[Brent Brown]

It certainly sounds like something that could be due to (non) initialization. Worth
looking hard into that, but in the interest of checking things methodically it would be
useful to have confidence that the hardware is ok first.

The symptom of only a very long power off (hours vs minutes) making a difference
is something that raises one eyebrow. The question is what is different in that case?
Is Vdd somehow not completely discharging in the shorter off times? Is it
temperature related i.e. something cools down if turned off long enough. Do you
have an effective and trust worthy power on reset scheme? E.g. firmware
mis-behaviour might be observed if CPU starts from address 0 vs executing random
instructions before stumbling into the reset vector (the suggestion here is this might
explain why different versions of firmware matter - not because of how they initialize
registers but how they corrupt registers if code runs errantly). Brown out enabled?
Power up timer enabled? Watchdog enabled? Supply stable? Oscillator starting up
reliably?

More questions than answers, sorry.

Post by p***@pp5ms.com
Hi everyone,
I am developing in assembly in PIC16F887 an automation equipment for
amateur radio stations. I've already done a lot of the firmware,
currently occupying near 3K.
I have as practice, go doing and write on the hardware to do tests
and after everything okay go ahead writing new routines.
Sometimes these tests are done 5 or 6 times a day as the firmware evolves.
I had to explain how I'm working so I can tell what's going on.
During these tests and new firmware versions, the hrdware virtually
stays on all the time, or when I turn off and on to test the system
startup, it is a few minutes without power.
Five days have passed that something happened that I only noticed later.
Everything works perfectly, however if I turn off the power and
leave it off overnight, when I turn on it is not boot.
Even if I re-write the program in the PIC it does not work anymore.
However (and this is where I do not understand what happens) if I
write a firmware from 5 days ago, it works. From that point on, I
can re-write the latest version and it's still okay. Only if I turn
power off for a long time does not work anymore when I turn on
again. With the 5-day program, I can leave the power off that always
comes back working at power on.
I think about some problem with the hardware, but I have several
prototypes (10 actually) and they all exhibit exactly the same
problem.
The impression I have is that it has some initialization that stays
in RAM and it takes a long time to erase on power off and when this
happens, comes the problem.
My question is: Has anyone ever had any kind of similar problem?
I'm really stuck and I think about going back to the program 5 days
ago and going re-writing the program I've done again, this time
doing tests closer to each new change. Maybe even the routines will
be a little different end up getting a bit different and it may be
that the problem does not happen anymore. But I would not be very
relieved to resover in this way without knowing what actually
happens.
Thanks for any feedback.
Marcus - PP5MS
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[PP5MS - Marcus]

Hi Brent,
Yes, I think that really are one problem in non initialization.
I think that there are no hardware problem, but I can only be sure of this
after solving this problem.
I had not mentioned before but I placed two bay pass capacitors exactly on
top of the two VSS / VDD pins but I did not notice any change.
I'm using 887 in the TQFP version.
I will check carefully about the discharging of VDD.
Temperature, I had not thought of that ... I'll try to warm up with hot air
and look if the effect changes.
Yes, the power supply are a good one, HP-6236B but even so, I will try to
connect another one eliminating this possibility.
Yes, Brown out is enable as well as the Power up timer.
No, Whatdog is disable, I usually configure the Whathdog only after
everything is finished so it does not mask any problems.
Oscillator is the on chip internal one, running 8MHz.

Thank you so much for the ideas. Now I have a lot of tests to do!
Marcus

-----Mensagem original-----
De: piclist-***@mit.edu [mailto:piclist-***@mit.edu] Em nome de
Brent Brown
Enviada em: quarta-feira, 21 de novembro de 2018 23:45
Para: Microcontroller discussion list - Public.
Assunto: Re: (PIC) 16F887 - strange behavior

It certainly sounds like something that could be due to (non)
initialization. Worth looking hard into that, but in the interest of
checking things methodically it would be useful to have confidence that the
hardware is ok first.

The symptom of only a very long power off (hours vs minutes) making a
difference is something that raises one eyebrow. The question is what is
different in that case?
Is Vdd somehow not completely discharging in the shorter off times? Is it
temperature related i.e. something cools down if turned off long enough. Do
you have an effective and trust worthy power on reset scheme? E.g. firmware
mis-behaviour might be observed if CPU starts from address 0 vs executing
random instructions before stumbling into the reset vector (the suggestion
here is this might explain why different versions of firmware matter - not
because of how they initialize registers but how they corrupt registers if
code runs errantly). Brown out enabled?
Power up timer enabled? Watchdog enabled? Supply stable? Oscillator starting
up reliably?

More questions than answers, sorry.

Post by p***@pp5ms.com
Hi everyone,
I am developing in assembly in PIC16F887 an automation equipment for
amateur radio stations. I've already done a lot of the firmware,
currently occupying near 3K.
I have as practice, go doing and write on the hardware to do tests and
after everything okay go ahead writing new routines.
Sometimes these tests are done 5 or 6 times a day as the firmware evolves.
I had to explain how I'm working so I can tell what's going on.
During these tests and new firmware versions, the hrdware virtually
stays on all the time, or when I turn off and on to test the system
startup, it is a few minutes without power.
Five days have passed that something happened that I only noticed later.
Everything works perfectly, however if I turn off the power and leave
it off overnight, when I turn on it is not boot.
Even if I re-write the program in the PIC it does not work anymore.
However (and this is where I do not understand what happens) if I
write a firmware from 5 days ago, it works. From that point on, I can
re-write the latest version and it's still okay. Only if I turn power
off for a long time does not work anymore when I turn on again. With
the 5-day program, I can leave the power off that always comes back
working at power on.
I think about some problem with the hardware, but I have several
prototypes (10 actually) and they all exhibit exactly the same
problem.
The impression I have is that it has some initialization that stays in
RAM and it takes a long time to erase on power off and when this
happens, comes the problem.
My question is: Has anyone ever had any kind of similar problem?
I'm really stuck and I think about going back to the program 5 days
ago and going re-writing the program I've done again, this time doing
tests closer to each new change. Maybe even the routines will be a
little different end up getting a bit different and it may be that the
problem does not happen anymore. But I would not be very relieved to
resover in this way without knowing what actually happens.
Thanks for any feedback.
Marcus - PP5MS
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change
your membership options at http://mailman.mit.edu/mailman/listinfo/piclist

[Bob Blick]

Does the '887 have LVP, and is that pin floating?


________________________________________
From: piclist-***@mit.edu <piclist-***@mit.edu> on behalf of pp5ms
Sent: Wednesday, November 21, 2018 3:14 PM
To: ***@mit.edu
Subject: (PIC) 16F887 - strange behavior

Hi everyone,

I am developing in assembly in PIC16F887 an automation equipment for amateur radio stations. I've already done a lot of the firmware, currently occupying near 3K.
I have as practice, go doing and write on the hardware to do tests and after everything okay go ahead writing new routines.
Sometimes these tests are done 5 or 6 times a day as the firmware evolves.
I had to explain how I'm working so I can tell what's going on.
During these tests and new firmware versions, the hardware virtually stays on all the time, or when I turn off and on to test the system startup, it is a few minutes without power.
Five days have passed that something happened that I only noticed later.
Everything works perfectly, however if I turn off the power and leave it off overnight, when I turn on it is not boot.
Even if I re-write the program in the PIC it does not work anymore. However (and this is where I do not understand what happens) if I write a firmware from 5 days ago, it works. From that point on, I can re-write the latest version and it's still okay. Only if I turn power off for a long time does not work anymore when I turn on again. With the 5-day program, I can leave the power off that always comes back working at power on.
I think about some problem with the hardware, but I have several prototypes (10 actually) and they all exhibit exactly the same problem.
The impression I have is that it has some initialization that stays in RAM and it takes a long time to erase on power off and when this happens, comes the problem.
My question is: Has anyone ever had any kind of similar problem?
I'm really stuck and I think about going back to the program 5 days ago and going re-writing the program I've done again, this time doing tests closer to each new change. Maybe even the routines will be a little different end up getting a bit different and it may be that the problem does not happen anymore. But I would not be very relieved to resover in this way without knowing what actually happens.
Thanks for any feedback.
Marcus - PP5MS

[RussellMc]

Post by Bob Blick
Sent: Wednesday, November 21, 2018 3:14 PM
Subject: (PIC) 16F887 - strange behavior
During these tests and new firmware versions, the hardware virtually stays
on all the time, or when I turn off and on to test the system startup, it
is a few minutes without power.
Five days have passed that something happened that I only noticed later.
This MAY be due to an internal node being charged via invalid pin voltages

during shutdown. eg several pins may be held at 5V initially and decay to
zero over different periods. As one decays faster than the other an
internal junction is forward biased and stores charge in an insulated node
that causes havoc. Unusual but not unknown.

Test: With power off in the fault state, short all pins to ground with a
conducting bar. If you can short many or all at once to ground it's good,
but even running van earthed wire along the pins can help.

*IF* this works, look at the circuit for conditions where pins may be
illegally biased during shutdown or startup. I have seen this and similar
happen on a number of occasions.



Russell McMahon

[RussellMc]

From: pp5ms
Sent: Wednesday, November 21, 2018 3:14 PM
... During these tests and new firmware versions, the hardware virtually
stays on all the time, or when I turn off and on to test the system
startup, it is a few minutes without power.
Five days have passed that something happened that I only noticed later.
...
This MAY be due to an internal node being charged via invalid pin voltages

during shutdown. eg several pins may be held at 5V initially and decay to
zero over different periods. As one decays faster than the other an
internal junction is forward biased and stores charge in an insulated node
that causes havoc. Unusual but not unknown.

Test: With power off in the fault state, short all pins to ground with a
conducting bar. If you can short many or all at once to ground it's good,
but even running an earthed wire along the pins can help.

*IF* this works, look at the circuit for conditions where pins may be
illegally biased during shutdown or startup. I have seen this and similar
happen on a number of applications.



Russell McMahon

[PP5MS - Marcus]

Hi Russell,
I had not thought about doing that.
In a few moments, I will try to ground all the pins as your suggestion and
return here to tell the result.
Marcus

-----Mensagem original-----
De: piclist-***@mit.edu [mailto:piclist-***@mit.edu] Em nome de
RussellMc
Enviada em: quinta-feira, 22 de novembro de 2018 05:34
Para: Microcontroller discussion list - Public.
Assunto: Re: [PIC) 16F887 - strange behavior

Post by Bob Blick
Sent: Wednesday, November 21, 2018 3:14 PM
Subject: (PIC) 16F887 - strange behavior
During these tests and new firmware versions, the hardware virtually
stays on all the time, or when I turn off and on to test the system
startup, it is a few minutes without power.
Five days have passed that something happened that I only noticed later.
This MAY be due to an internal node being charged via invalid pin voltages

during shutdown. eg several pins may be held at 5V initially and decay to
zero over different periods. As one decays faster than the other an internal
junction is forward biased and stores charge in an insulated node that
causes havoc. Unusual but not unknown.

Test: With power off in the fault state, short all pins to ground with a
conducting bar. If you can short many or all at once to ground it's good,
but even running van earthed wire along the pins can help.

*IF* this works, look at the circuit for conditions where pins may be
illegally biased during shutdown or startup. I have seen this and similar
happen on a number of occasions.



Russell McMahon
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change
your membership options at http://mailman.mit.edu/mailman/listinfo/piclist

[PP5MS - Marcus]

Hi Bob,
The LVP is disabled in the configuration and the RB3 pin is being used as
digital I/O.
You made me curious because there could be an involuntary change in the
firmware.
I read the firmware of the PIC that crashed and compared what I read when it
works and they are the same.
It should be something that I don´t initialize RAM...
Thank you for remembering this!
Marcus

-----Mensagem original-----
De: piclist-***@mit.edu [mailto:piclist-***@mit.edu] Em nome de Bob
Blick
Enviada em: quinta-feira, 22 de novembro de 2018 02:41
Para: Microcontroller discussion list - Public.
Assunto: Re: [PIC) 16F887 - strange behavior

Does the '887 have LVP, and is that pin floating?


________________________________________
From: piclist-***@mit.edu <piclist-***@mit.edu> on behalf of pp5ms
Sent: Wednesday, November 21, 2018 3:14 PM
To: ***@mit.edu
Subject: (PIC) 16F887 - strange behavior

Hi everyone,

I am developing in assembly in PIC16F887 an automation equipment for amateur
radio stations. I've already done a lot of the firmware, currently occupying
near 3K.
I have as practice, go doing and write on the hardware to do tests and after
everything okay go ahead writing new routines.
Sometimes these tests are done 5 or 6 times a day as the firmware evolves.
I had to explain how I'm working so I can tell what's going on.
During these tests and new firmware versions, the hardware virtually stays
on all the time, or when I turn off and on to test the system startup, it is
a few minutes without power.
Five days have passed that something happened that I only noticed later.
Everything works perfectly, however if I turn off the power and leave it off
overnight, when I turn on it is not boot.
Even if I re-write the program in the PIC it does not work anymore. However
(and this is where I do not understand what happens) if I write a firmware
from 5 days ago, it works. From that point on, I can re-write the latest
version and it's still okay. Only if I turn power off for a long time does
not work anymore when I turn on again. With the 5-day program, I can leave
the power off that always comes back working at power on.
I think about some problem with the hardware, but I have several prototypes
(10 actually) and they all exhibit exactly the same problem.
The impression I have is that it has some initialization that stays in RAM
and it takes a long time to erase on power off and when this happens, comes
the problem.
My question is: Has anyone ever had any kind of similar problem?
I'm really stuck and I think about going back to the program 5 days ago and
going re-writing the program I've done again, this time doing tests closer
to each new change. Maybe even the routines will be a little different end
up getting a bit different and it may be that the problem does not happen
anymore. But I would not be very relieved to resover in this way without
knowing what actually happens.
Thanks for any feedback.
Marcus - PP5MS
-
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change
your membership options at http://mailman.mit.edu/mailman/listinfo/piclist

[PP5MS - Marcus]

Hello guys,
I want to thank´s here again, everyone who gave me information and tips
about the problem I was having.
Using the information and suggestions I received, I ended up finding the
problem.
To not make this text too long, I mean that the cause was really the lack of
initialization of some positions in RAM.
The fact that RAM stays with the pattern after turning off the power for
some long time has left me really confused.
I use interruption with the timer0 for multiplex three 7 segment displays
that show the direction in degrees of the pointing of an antenna.
The problem was that I enabled the interrupt before having the value to show
already ready.
I have a table with several "retlw" that returns me the segments I need to
turn on to show the numbers.
When the interruption took effect, the value was not yet established and
instead of matching the "retlw" ended up going to a program address with
unpredictable results ... I learned a lot from this error ... Fortunately
everything is working as it should and without bug I may have noticed.
Many thanks to everyone who gave their suggestions on how to find out what
was going on.
Certainly this list is invaluable, and I hope one day I can give some help
as well.
Just to complement ...
As I was given the suggestion, at the beginning of the program I did a
routine that wrote 0x00 in all RAM and the problem disappeared.
Then I tried with 0xFF and locked ...

From this point I could know that the problem was the lack of initialization

of some RAM position.
As my table would have to be index between 0x00 and 0x0F I finally
understood what was happening and I was able to correct it.
Thank you for all guys that send me some suggestion, and apologize my
English since my first language are Portuguese...
Marcus - PP5MS

[Jason White]

Glad to hear that we were of some help!

Your project sounds cool, do you think you could share a link to some
pictures it on the list?

-Jason White

[PP5MS - Marcus]

Hi Jason,
Sure!
I can upload a PDF file of the diagram and some pictures as well.
Since I never do this before, can you point me how to upload here on the
piclist?
If someone like to see my asm source file, no problem, I can put this on the
list also.
The bad part is that the remarks are in Portuguese ...
Marcus

-----Mensagem original-----
De: piclist-***@mit.edu [mailto:piclist-***@mit.edu] Em nome de
Jason White
Enviada em: sábado, 24 de novembro de 2018 00:41
Para: Microcontroller discussion list - Public.
Assunto: Re: [PIC) 16F887 - strange behavior - SOLVED!!

Glad to hear that we were of some help!

Your project sounds cool, do you think you could share a link to some
pictures it on the list?

-Jason White
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change
your membership options at http://mailman.mit.edu/mailman/listinfo/piclist

[Jason White]

I honestly never figured out how to do that. Perhaps somebody else on the
list knows how?

Nowadays people typically upload stuff to other services (google, dropbox,
etc.) and link to it.

Post by PP5MS - Marcus
Hi Jason,
Sure!
I can upload a PDF file of the diagram and some pictures as well.
Since I never do this before, can you point me how to upload here on the
piclist?
If someone like to see my asm source file, no problem, I can put this on the
list also.
The bad part is that the remarks are in Portuguese ...
Marcus
-----Mensagem original-----
Jason White
Enviada em: sábado, 24 de novembro de 2018 00:41
Para: Microcontroller discussion list - Public.
Assunto: Re: [PIC) 16F887 - strange behavior - SOLVED!!
Glad to hear that we were of some help!
Your project sounds cool, do you think you could share a link to some
pictures it on the list?
-Jason White
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change
your membership options at http://mailman.mit.edu/mailman/listinfo/piclist
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Isaac M. Bavaresco]

Anyone can create a personal page in piclist.com.
You can add your source code directly to the pages.
Binary files and images can be sent to James Newton so he uploads to some
directory and supply you with a link that you can place in your pages.

<http://www.piclist.com>

My personal page: <
http://www.piclist.com/techref/member/IMB-yahoo-J86/index.htm>

Cheers,
Isaac

Em seg, 26 de nov de 2018 12:06, Jason White <

Post by Jason White
I honestly never figured out how to do that. Perhaps somebody else on the
list knows how?
Nowadays people typically upload stuff to other services (google, dropbox,
etc.) and link to it.

Post by PP5MS - Marcus
Hi Jason,
Sure!
I can upload a PDF file of the diagram and some pictures as well.
Since I never do this before, can you point me how to upload here on the
piclist?
If someone like to see my asm source file, no problem, I can put this on the
list also.
The bad part is that the remarks are in Portuguese ...
Marcus
-----Mensagem original-----
Jason White
Enviada em: sábado, 24 de novembro de 2018 00:41
Para: Microcontroller discussion list - Public.
Assunto: Re: [PIC) 16F887 - strange behavior - SOLVED!!
Glad to hear that we were of some help!
Your project sounds cool, do you think you could share a link to some
pictures it on the list?
-Jason White
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change
your membership options at

http://mailman.mit.edu/mailman/listinfo/piclist

Post by PP5MS - Marcus
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--
Jason White
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Bob LeDoux]

So much to be thankful on this day:

1. A (PIC) reference on the Piclist
2. Use of a classic 16F887 chip
3. Assembler in action

It takes me back to the heyday of this list.

[Neil]

I still use a PIC16F887, with code written in assembly. I don't use
enough of them to warrant porting to something newer.
This was ported over from a F877A several years ago.

Cheers,
-Neil.

Post by Bob LeDoux
1. A (PIC) reference on the Piclist
2. Use of a classic 16F887 chip
3. Assembler in action
It takes me back to the heyday of this list.