No dejes las entradas al aire, haz un división de tensión a las entradas, también puedes colocarlo un TOF para que el rele que tienes no se encienda hasta pasar el tiempo. tienes que tener en cuenta que segun que funciones necesites tienes que usar 2.4.
yo tengo PIC que no funcionan según con que versión

to DanielH

thanks for your reply, no i haven´t set them as output and LOW i am going to try that, about the 0x81 is for disabling pull up resistors:

https://github.com/LDmicro/LDmicro/wiki/Disable-Pull-up-resistors

here DFX said for disabling pull up resistor for pic

https://cq.cx/ladder-forum.pl?...;parent=6110&tt=1489408801

@Alex:

I think that the first problem (LED blinking when tranferring the .hex file) is related to the uploading process.

I have not any Pickit(2|3) programmer, but I use an USBPICPROG, Open Hardware + Free Software programmer, through hole version builded by myself [1].
I think that all PIC programmers must comply with at least the first three stages of this process, so I supose that I have "catched" the entire issue by its "tail".

Stage1: at startup of the programmer's software, or at the very beginning of PIC connection through ICSP, the programmer's firmware will retrieve de PIC ID and show that in software GUI interface.

Stage2: previous to upload the machine code (.hex converted in binary code, allocated following .hex static addresses), the programmer will reset the PIC and then will ERASE the memory content: FLASH area (program), CONFIGURATION FLAGS, and EEPROM area (data).
At this stage, OPTION register (0x81) becomes cleared = 0x00 (all bits are 0) in PIC16F877/A (EOL) and PIC16F887 (its sucessor), so pull-up weak resistors (bit 7, !RBPU) in all pins of PORT B become ENABLED.

Stage3: the programmer uploads the machine code (program, configuration words, data).
At this stage, OPTION register (0x81) is still cleared.

Stage4 (optional): the programmer will verify the correctness of the code, configuration and data now allocated in PIC.
At this stage, OPTION register (0x81) is still cleared.

Stage5: the programmer resets the microcontroller again, PIC configuration flags are honored
At this stage, OPTION register (0x81) is still cleared.

Stage6: microcontroller beguins to execute the new program.
Of course, if the first instruction (executed only one time as setup) changes the OPTION register (0x81) content, this new value will be used thereafter.

RESULT:

From Stage2 OPTION register (0x81) cleared to 0x00, to the beginning of program execution at Stage6 (changing OPTION register (0x81) to disable pull-up resistors), all PORT B pins are inputs with GROUND reference.

If the PIC and peripheral circuits are externally powered, LEDs connected to those pins will glow dimmed.

If the uploading process is very short (a bunch of Ladder instructions), and Verify code, configuration and/or data has been not enabled in the programmer software options, LEDs glow will be see as a "blink".

But if the code to be uploaded is long, and verify options are enabled, upload process will take much more time (perhaps tens of seconds) and so the LEDS will bright during all that time.

Of course, if you delete your first instruction (MOV 0xff #0x81), LEDs will glow permanently (see my previous reply).

@Greg:
I agree with you, but I think that this pb is not a bug; and it can be "ironed" by a careful hardware design and smart programming technics.

@Alex, @Calubert:
I'm argentinian and speak spanish, of course; but I prefer to write to this forum in english, for the benefit of all the users.
As Jonathan Westhues stated: "Please post in English if possible; this will maximize your chances of a good response".

Best regards,
DanielH

Since we have the possibility to change that with #xxxx it might be better to bring that back as it used to be, pullups default off.
Gilles must be addressed for that ;)

ERRATA:

My friends, I fear that I've commited an error in my explanation on why loading .hex to PIC makes blink the LEDs connected at unused pins on Port B, as Alex observed.

Reading Microchip docs, I discovered that when erasing program memory, OPTION_REG will be writed with 0xFF value (all bits set to 1) on all kind of Reset signals (POR, BOR, MCLR and others).

Bit 7 of 0x81 OPTION_REG value that controls Port B pull-up resistors, after Stage2 (ERASE PIC memory) will be !RBPU = 1.
Thus, DISABLING pull-up resistors, and remaining at that state until a new value will be writed, during uploading process or by means program code execution.

From docs:
!RBPU bit 7: PORTB Pull-up Enable bit
1 = PORTB pull-ups are disabled
0 = PORTB pull-ups are enabled by individual PORT latch values

So, what is the cause of the "blinking phenomena"?

I think now that is a more complex process:

1. Stage2: ERASE process writes 0xFF value (all bits set to 1) at all TRISx registers, so all I/O pins at PORTx are Inputs; and 0xFF at 0x81 register, so PORTB inputs have pull-ups resistors DISABLED due bit 7 of 0x81 OPTION_REG, !RBPU = 1.

2. So, LEDS are NOT glowing DURING programming process.

3. LDmicro defaults in version > 3.X.X (4.4.x; 5.0.x), when code is uploaded, writes !RBPU = 0, ENABLING pull-up resistors; LEDS are NOT glowing yet.

4. Stage6: After final PIC reset performed by programmer, program execution beggins; LEDS are NOT glowing yet.

5. When PC (program counter) reaches 0x81 OPTION_REG, LDmicro default !RBPU = 0 ENABLES pull-up resistors at PORTB; thus, LEDs beggin to glow.

6. After a very little time, when PC reaches MOV 0xff #0x81 USER instruction, !RBPU = 1 DISABLES again pull-up resistors at PORTB; thus, LEDS ends to glow and remains in this state, THIS is the "QUICK BLINK" that Alex video shows (first part).

7. Of course, if MOV 0xff #0x81 user instruction is deleted, LEDs will glow permanently (Alex video, second part), due 0x81 OPTION_REG remains at LDmicro defaults, !RBPU = 0.

I don't know nothing about internals in LDmicro, so I don't know when 0x81 OPTION_REG is accessed for the first time by execution of LDmicro compiled programs; perhaps by a setup routine (only one time executed at the beginning of the program, using GOTO or similar instruction).

BTW: Neither, I don't know when TRISX.x = 0 instructions are executed, having user declared a pin as an OUTPUT.
I think that, as in LDmicro Inputs and Outputs are static (no change during program execution is allowed), perhaps TRIS operations are in a setup routine at the beginning of the program, too.

@MGP

I agree with you that changing LDmicro defaults in OPTION_REG to !RBPU = 1, and thus disabling pull-ups resistors at PORTB, will avoid this "blink" problem.

@José Gilles

PIC Configurations Bits in LDmicro are NOT related with 0x81 OPTION_REG (pull-up resistors and other options).

This field writes PICs Configuration Words (CONFIG1; CONFIG2 if it exists in the device).

In PIC16F887, the Configuration bits can be programmed (read as ‘0’), or left unprogrammed (read as ‘1’) to select various device configurations. These bits are mapped in program memory location 2007h and 2008h, respectively.

Address 2007h and 2008h are beyond the user program memory space. It belongs to the special configuration memory space (2000h-3FFFh), which can be accessed only during programming.

Configuration bits at 2007h in 16F87X and 16F88X manages In Circuit Debugger Mode, Low Voltage Programming, Fail-Safe Clock Monitor, Internal External Switchover, Brown Out Reset Selection, Data Code Protection, Code Protection, Master Clear Enable, Power-up Timer Enable, Watchdog Timer Enable, FOSC Oscilator Selection.

Plus, Configuration bits at 2008h in 16F88X manages Flash Program Memory Self Write Enable and Brown Out Voltage Selection.

For example, default Configurations Words for PIC16F887 in LDmicro are 0x2007 = 23E2 and
0x2008 = 0600:
In Circuit Debugger DISABLED
Low Voltage Programming DISABLED
Fail-Safe Clock Monitor DISABLED
Internal External Switchover (Two Speed Startup) DISABLED
Brown Out Reset ENABLED
Data Code Protection DISABLED
Code Protection DISABLED
Master Clear Reset ENABLED
Power-up Timer ENABLED
Watchdog Timer DISABLED
FOSC Oscilator HS (High-speed crystal/resonator)
Flash Program Memory Self Write Protection DISABLED
Brown Out Reset at 2.1V

If user wants to protect his program and data code for reading, must change PIC Configurations bits in LDmicro to 0x06002322 (note that 0x2008 value precedes 0x2007 value), or the Configurations Flags or similar feature in the programmer software, before to upload the machine code.

Also, note that Flash Program Memory Self Write Protection is DISABLED in LDmicro defaults, allowing to use a bootloader to easy and quick programming through UART.
I habitually use TinyBootloaderLin (lcgamboa fork), a GPLv2 application based on TinyPicBootloader by Claudiu Chiculita; the bootloader occupies only 100 words in PIC code memory, and is the smallest for now.

Best regards,
DanielH

i don´t undestand about the source code but as long as pull up resistors are disabled by default as i think it should be like that, comparing with other compilers, even arduino IDE, would be a good idea to try.

Maybe an extra checkbox in the menu "Settings" and default on, or is that too much work?

Personally, I prefer to use them as default 'ON' with pic's

sorry i used this (diactivate coil):

|-----------------------------------------(R)--|

@Alex

First:

My apologies for my delayed reply, I haven't see your news on this topic.

Second:

I fear that stating unused pins as outputs and drive them LOW doesn't solve the "blinking phenomena", due this issue is LDmicro v>3.x related (default settings enabling pull-up resistors on PORTB).

As stated in my ERRATA, from the beginning of execution of user program after uploading the new code to the PC (program counter) reaching your first program instruction disabling pull-ups, pull-ups on not declared pins in PORTB (inputs by default) are enabled by LDmicro defaults.

Microchip docs stated that on all kind of resets (after programming, on Power On, on Brown Out, on MCLR reset), OPTION_REG (0x81) = 0xFF (all bits set) -> !RBPU = 1, so disabling pull-ups resistors on PORTB.

IMHO (I don't know LDmicro internals), at the very beginning of program execution, LDmicro performs a kind of one shot SETUP subroutine, PREVIOUSLY to the execution of the first instruction in user program; that SETUP have an instruction clearing OPTION_REG (0x81) bit 7 -> !RBPU = 0 , so enabling pull-ups resistors.

Thus, the "blinking phenomena" theoretically must be observed at every startup, i.e. powering on the PIC and related circuit.
Perhaps it has a very short duration on power on, and only can be observed using an oscilloscope or a digital signal analyzer.

Third:

I don't know why you have different results when uploading more than one time an user program that have direct inverted coils declared.

Theoretically, previouly to upload a new code, the programmer will ERASE all code and data memories; but this behavior perhaps is optional in your programmer software (i.e. USBPICPROG have Erase before programming option, along with options to write or not Code memory, Config memory, Data memory and others).
Please, verify if your programmer is erasing the code memory before uploading a new code, perhaps some code memory addresses remains unchanged between uploads, if ERASE process is not performed.

Soon, I will test this phenomena, by ICSP using USBPICPROG, and by serial programming using a bootloader (tinybldlin).
If I can reproduce your issue again, first I will inform you, and then I will burn my brain trying to find why ;-)

Fourth:

Declaring an UNUSED and UNCONNECTED pin as an OUTPUT and driving it LOW do NOT solve the "blink issue".
It is only a safety precaution recommended by Microchip and others, for ALL KIND OF I/O UNUSED PINS (not only for ports that have pull-up resistors).

Of course, if an UNUSED PIN in any user program is PHISICALLY CONNECTED in hardware to any kind of circuit, the status that will be written to this pin as output must be carefully evaluated.

I don't know how you have connected the LEDs on your unused pins: it can be do in two ways: anode to pin, or cathode to pin, of course using it in series with a limiting resistor (R=?).
If the first is used (anode to pin (I guess that is your circuit on PORTB LEDs), configuring pin as output and driving it LOW, LED will NOT bright.
On the opposite (cathode to pin), configuring pin as output and driving it LOW again, LED WILL bright.
So, output status to be written depends on circuit, as I stated before.

NOTE: in LDmicro, RE3/¡MCLR is configured as MCLR with pull-up resistor enabled by default, Configuration Word CONFIG1 (0x2007 = 0x23E2 in PIC16F87x/88x).
If you don't use !MCLR as a Reset and/or ICSP signal (with corresponding circuit), is very convenient to use an external pull-up resistor to avoid unexpected resets.
If you want to use RE3 as input, you must modify Configuration Bits in LDmicro, or using your programmer software, BEFORE to upload your program.

Best regards,
DanielH