pic programmer why ???

[vsmvdd]

Unless your sending the pic into space or using it to control really sensative stuff that needs to be more robust
 
there is absolutly no need to buy any programmers for any pic
other than for in circuit debug purposes
 
if you need just to use in circuit programming
 
i made up a gif from info i found on the net
 
some refer to this method as quick and dirty
however i have never had my chip stop or crash etc using this method
even over a wide range of voltages and conditions....
 
just use comport 1  and set the software to use it

[sanf]

Hi,  vsmvdd
 
Usually this method is god,  but on some Laptop's the Power out of COM-port is not sufficient and this won't work!
 
Tanks for your contribution proteus models.
 
Cheers!

[vsmvdd]

if you downloaded and read the note you would see that i mentioned this
 
also it is worth pointing out while i am here
 
some pics {most later ones} have a pgm pin usualy on most it is pin RB5 or RB4 this needs to be grounded for high voltage flash as this method uses
 
 
Thanks sanf :p but click the picture to download the .gif :rolleyes:

[pama]

i also use this method. Could you please point out some starting point for playing with avr?
thanks, pama

[vsmvdd]

avr??
 
most mcu work the same way these days FAP flash and play
 
so... what do you need to know
 
i/o is i/o ~ o/i = o/i = (1) | ( !1)
 
most often avr are the same to program
 
expensive programmers arent needed mostly
 
unless its 'a product' then standards apply and its best
to program over a wide range of voltages to exacting constraints
 
using the programmers manufacturers use or recommend is always best
 
however for hobby stuff this kind of methods is cool
called bit banging ! and aok for hobby and semi product {development} grade
nothing more....
 
maybe avr is harder this way unless you add a boot block {you can use this method to add the boot block then the upper block via a serial connection
many freeware code does this for diverse mcu
 
sometimes buying a software you like and devoting time to it fully helps ...
 
any mcu makers actual software is old hat as soon as its made
and only good for learning c and writing function
and embeding functions to asm to quicken parts and an
assembler written 'embeded' mcu application with a c style shell
 
 
best look around im not an avr fan ... there mcu's arent as powerfull
in real terms as pic software is further on and easier to add in block macro form
 
 
avr is not slow infact it out perform's most stuff at the expence of complex functions
 
as it has less instuctions in some levels of core and external unitation as i used
is easy although avr are more expensive
maybe they are better ? but maybe not
 
most smart cards are pic84 there must be a reason
and the reason is security
 
pic c 84 is a very secure chip if its programmed the right way
pics can be exposed in one mode to check security of its pins then
 
reset to another mode to perform the tasking {the use of external eeprom in car radios}
 
avoid proteus vsm for this task its dosnt perform a static init
and its pic models are fully flawed by init ineptitude ...
if there pic model quality is anything to go by avoid there whole micro's systems
 
stick to free or shareware apps like avrsim and others
 
or pic simulator ide{harder to set up well not really just different}
 
 
 
so the likes of a pic 84 level on avr hasnt been extracted
to the likes of icprog freeware level
 
pic is more popular like many things one must eventualy die or both take equal share
 
there are many makers of mcu best to look to japanese mcu for the best least documented types
 
as they are far better at delicate tasks if quality is the need american mcu are slow and hobby
 
 
why everyone goes for proteus when its useless at protection is above me .... !!!

[pama]

thanks Vsmvdd for your time,
i was just thinking to swap my little appli. on avr (i'm just beginner, sorry from experts).
i'm using pic 16 f parts with bootloader, programmed with jdm and running on my dev. board. i'm debug with rs232/lcd (i know that is not a debugger, but it's enought in this time). So, without any professional tools.
and i'm wonder because this method can be used also for 18f parts (i tried just 18f2550).
i was thinking just on 8 bit avr mcu, on this starting point, and i suppose that is not big diffrence on this level. The 32 bit mcu, it's another question, but i don't like to start a new topic.
i have just to read, read and read.
thanks again and have a nice day!
pama

[sam_des]

Hi there,
   I read all the posts in this thread carefully. Thanks vsmvdd for your time. But i disagree with  you on some points. I am a professional embedded system designer working with 8051, Mototrola, PICs & AVRs for last 4 years.
   I agree with you that PICs are far more easier to understand than AVR, but I guess that is because far more people (mainly hobbiests) are involved with PICs than other ones.
   I 've some strong reservations when PICs are considered  -->

      1)  PICs which are cheaper have significantly lower RAM & ROM

      2) PICs have very bad interrupt vector structure when it comes to many interrupts with hard deadlines. It simply isn't easy to nest interrupts.

    3) A thing that haunts me still after 5-6 years with PICs, is their absence of data stack & stack maipulation instructions. Programming is a lot easier with of them & many optimization can be done leading to smaller, faster application

   4) ADCs of PIC needs "channel acquisition delay" whenever channel is changed while AVRs don't need such delays leading to faster conversions. There is no differertial ADC in PIC as far as I know.

  5) CCP module included with PIC is severely restricted compared to AVRs'

  6) USART & other comm. modules of AVR are much advanced.

  7) AVR-GCC is available & Atmel supports it.

  There are many other subtle differences such as interrupt flag clearing, advanced instruction set, c-lang compatiblity which can make your life much easier.

  Only drawback of AVRs are their 300-400 pages long datasheets with little boring language. But once you understand any one of them, AVRs are sweet. Here is a comparion of two MCUs which have nearly same cost around (2$ a chip)

 PIC16F73
  - 28 pin, pin Source/sink - 25mA, 4 K ROM, 192 Bytes RAM,  5 8-bit ADCs, 2 CCP
  - SPI, 1 USART
  - No bootloader capability
   - No stack manipulation
  - Only 1 interrupt vector for all
  - No sepearate "register" file
  - MAX clock - 20 MHz -> 200 nS instruction cycle -> 5 MIPS max
  - NO C-lang compatibilty

AVR ATmega8
  - 28 pin, pin source.sink- 40mA, 8 K ROM, 1K RAM, 6 10-bit ADC, 3 CCP, 1 USART
  - TWI, SPI
  - Bootloader capability
  - Stack manipulation
  - Seperate vector for each source
  - 32 1 byte sepearte "register" file for fast data access
  - MAX clock = 16 MHz -> 62.5nS instruction cycle, 16 MIPS max
  - C-lang compatible architecture

     That's why I think AVRs are a lot better than PICs. As far as code security is concerned I think Atmel is world leader in "sercure memory " chips.
    But in the end it depends on your test & application you are building. I prefer AVR to PIC any time.

  regards,

_Sam

[vsmvdd]

i think the original purpose of the thread was to describe an easy not very well known
method to flash pic mcu
 
not to discuss the merits of them :eek:
 
each to there own ic i use pics for small circuits
not to fly aeroplanes
or drive cars with brains as avr was designed to do ....
 
 
PIC16F73
- 28 pin, pin Source/sink - 25mA, 4 K ROM, 192 Bytes RAM, 5 8-bit ADCs, 2 CCP
- SPI, 1 USART  {but up to 16  added uarts thru software and can be interupt driven}
- No bootloader capability {rubbish}
- No stack manipulation {rubbish just build a stack }
- Only 1 interrupt vector for all {rubbish  pic are multivecter}
- No sepearate "register" file { later ic support adjustable registers}
- MAX clock - 20 MHz -> 200 nS instruction cycle -> 5 MIPS max  {hum  senix??? for high end}
- NO C-lang compatibilty {what? }
 
 
i think you must sell  avr  or  are american ??

[vsmvdd]

thanks Vsmvdd for your time,
i was just thinking to swap my little appli. on avr (i'm just beginner, sorry from experts).
i'm using pic 16 f parts with bootloader, programmed with jdm and running on my dev. board. i'm debug with rs232/lcd (i know that is not a debugger, but it's enought in this time). So, without any professional tools.
and i'm wonder because this method can be used also for 18f parts (i tried just 18f2550).
i was thinking just on 8 bit avr mcu, on this starting point, and i suppose that is not big diffrence on this level. The 32 bit mcu, it's another question, but i don't like to start a new topic.
i have just to read, read and read.
thanks again and have a nice day!
pama

hi
 
youll find the same three pins on any pic
 
the method this uses is high voltage programming
so remember to disable lvp mode low voltage programming mode in ic-prog
 
so sometimes with some pic you need to pull the pgm pin down
 
older pic 16c and f series will work in this method
and so does pic18 and dspic
 
i think a mix of the use of avr micro and pic and japanese ones are best
 
i use many HD types and there brilient at doing tasks
 
i have about 10 megas from mega 8 to 128
but i find them hard to work with as they are not supported in DIL format
so you need to use a DIL breakout adapter
further adding to the cost of developing for them
 
ive used a few different mcu and find that for prototyping pic is hard to beat
 
over 50 language suites are avalible and many many users to gain info from
lots more sources to gain insight
 
and used by many many companies for embeded security cards , alarm systems , digital tv decoders etc etc
 
and its cores fully used to build nural networks that are used for research
 
further i dont see why a rigid C framework is any different to assembler ... and compilers frameworks as they will perform the same tasks
 
other than it cant be repaired if it is wrong unless you throw the chip away