Programming ultimatum

[AGCB]

Is there a way to program 18 pin chips without removing from the target (A PAIN) and also not sacrifice 2 or more pins as in ICSP (PINS ARE VALUABLE)? Would it be possible to switch in a programer and then swich it back out for use. This is for development experimenting only. I have Pickit 2 & 3. If so I will pursue it. I hate not having a full 8 bit port available. Thanks Aaron

 

[Nigel Goodwin]

Yes, of course you can switch pins in and out, a simple DPDT switch would make it completely transparent to the end application - if you're using MCLR as I/O you might need three poles instead of two.

 

[AGCB]

Thanks Nigel! I'm going to do that. Aaron

 

[Sceadwian]

You could alternately buy a ziff sockets for your chip, makes chip insertion a non-issue.

 

[jpanhalt]

This gives various ways to isolate the programming pins from their functional circuits during programming.

https://www.electro-tech-online.com/custompdfs/2011/09/30277d.pdf

John

 

[misterT]

Depends on the specific application, but I would use a bootloader.

 

[Sceadwian]

MIsterT a bootloader will not allow him to multipurpose the pins, it has to be a hardware solution.

 

[bryan1]

MIsterT a bootloader will not allow him to multipurpose the pins, it has to be a hardware solution.

By using a bootloader it WILL free up the ICSP pins for the circuit as the bootloader would use the USART or UARTfor programming.......

 

[Sceadwian]

So instead of the ICSP lines it would tie up the USART lines? Nigel's solution of simply switching out lines during programming with switches is very good, the rest require actualization of the specific method(s).

 

[AGCB]

I used Nigels recomendation and works good. I already have zif sockets. I don't know what a bootloader is. Thanks

 

[bryan1]

I don't know what a bootloader is.

Hi AGCB,
Just for your learning information a bootloader is a small program that generally resides in the upper most part of the pic's memory. By installing a bootloader the pic only needs to be programmed once using a pickit2/3 etc then after that, a switch or similar is used to put the pic into programming mode and a computer based program loads the pic with the new program. It does require the USART to be setup so the pic can talk with the computer then once a program is installed that say uses the USART then it is free to use in the said program.

is a good one to use and reading that website will give you an idea of how a bootloader is used.

Regards Bryan

 

[misterT]

MIsterT a bootloader will not allow him to multipurpose the pins, it has to be a hardware solution.

Bootloader is independent from the application program, it will allow the user to multipurpose all pins. You can even write your own communication protocol if you want.. parallel communication, bit-banging usart on any pin, I2C, SPI, etc..

... a bootloader is a small program that generally resides in the upper most part of the pic's memory. By installing a bootloader the pic only needs to be programmed once using a pickit2/3 etc then after that, a switch or similar is used to put the pic into programming mode and a computer based program loads the pic with the new program. It does require the USART to be setup so the pic can talk with the computer then once a program is installed that say uses the USART then it is free to use in the said program.

Is this true for PICs? Does it require the USART to be used for the communication?

Usually I set up my bootloaders so that they start every time the device is powered up, or after reset. That way there is no need for a "programming button". Then the bootloader sends a message through some communication bus, usually it is USART, but I have also used I2C and USB. If PC application (or another microcontroller) does not reply to this message the bootloader starts the application code, but if PC software replies, then a new application program is sent and written to the microcontroller program memory. Bootloader does the writing.. the chip is not exactly in programming mode.

 

[bryan1]

Hi Mister T,
With my projects using a bootloader I always put in a push button so if I do want to re-program the pic I push the button then apply power. That will put the pic into programming mode. Now if there is no response from the computer then the pic will time out and start the program already loaded. I have found using this method the best when using a bootloader.

Regards Bryan

 

[misterT]

Hi Mister T,
With my projects using a bootloader I always put in a push button so if I do want to re-program the pic when I push the button then apply power. That will put the pic into programming mode.

That is a good safe way, but not very handy if the device is in closed box or buried inside a robot. Many of my applications communicate with PC software, so I usually have a command that makes the application itself jump to the bootloader. That is one point why I suggested bootloader. They are incredibly flexible, but there is a big learning curve. Best thing I ever wasted my time on was a wireless bootloader on a mobile robot. Took me a while, but I didn't have to carry the robot around anymore just for programming.

 

[AGCB]

I guess I have more studying and learning to do. DUH

I always learn more than I bargained for on this forum. Thanks Aaron

 

[3v0]

I do not suggest using a bootloader during program development. Better to stick with the ICSP with its ability to do in circuit debugging with the PK2 PK3 or ICD. I feel this is the main drawback to using the arduino which uses a bootloader.

If you are the sort that does not use ICD it is not an issue.

 

[Sceadwian]

Bootloader is independent from the application program, it will allow the user to multipurpose all pins. You can even write your own communication protocol if you want.. parallel communication, bit-banging usart on any pin, I2C, SPI, etc..

It will allow you to multipurpose the pins in software, not in hardware, there are MANY loads that an I/O could be driving that will cause ICSP to fail. I've seen several posts here and dozens more on the AVR forums where a user couldn't figure out why they weren't able to program their chip anymore and it's because the load that the ICSP lines were connected to would make it unable to be used for ICSP programming. Usually something like an LED, or a high capacitance.

 

[Pommie]

I prefer to develop on a bigger chip and when fully debugged I port it to the target chip. So to develop for a 16F88 (18 pin) I would use a 16F886 (28 pin) etc.

Mike.

 

[misterT]

I do not suggest using a bootloader during program development. Better to stick with the ICSP with its ability to do in circuit debugging with the PK2 PK3 or ICD. I feel this is the main drawback to using the arduino which uses a bootloader.
If you are the sort that does not use ICD it is not an issue.

Bootloader is the main drawback of Arduino? Haha..

Anyway.. I agree. The ISP/ICSP programming works no matter how messed up your application is. When bootloader fails you will spend the rest of the day desoldering and resoldering and fixing stuff.

 

[AGCB]

I prefer to develop on a bigger chip and when fully debugged I port it to the target chip. So to develop for a 16F88 (18 pin) I would use a 16F886 (28 pin) etc.

Mike.

What are the advantages to this? Sounds like more work.