PICSTART Plus Inquiry

Status
Not open for further replies.
Y

YAN-1

New Member
Hello everyone. I am about to purchase the PICSTART Plus programmer (Part Number: DV003001) to use in my projects. The devices I mainly use are the 16F877(A) and the 16F628(A). This programmer supports these devices, right? Also I would like to inquire about the programming language. I use HITECH C under MPLAB environment. The PICSTART Plus can be used to program devices with programs developed with this language toolsuit, right? Not just MPASM. Your help is much appreciated.



Nichola V. Abdo
 

To give a simple answer to all your questions. Yes! I've never used that programmer, but I've heard its very reliable (I got the PICkit 2). Whatever language you use, as long as MPLAB compiles it to a .hex file, then the programmer will dump it into the PIC. Both devices are listed by the programmers documentation, and they're quote possibly the most common ones used, so I'd be shocked if it didn't work.

Good Luck, and enjoy the speed and wonder of development with a decent PIC programmer

Blueteeth
 
I've got both a PICStart Plus and a ICD2 clone (inchworm). Depending on your needs I haven't used my PICStart in ages. Plus you get a debugger for your 16F877A.
Plus the PICStart is a slow programmer (last time I used it).
 
I agree with Bill, you're far better off with an ICD2 (or a clone like the InchWorm), the PICStart Plus is (or at least was?) very slow and doesn't offer debugging facilities - and it's also rather expensive!.
 
Agree on that

Much to my regret I agree with you both.

For my budget, PicstartPlus costed dearly. It's painfully slow in spite of being able to select the portion of memory to write to.

I hate the idea to condemn it to gather dust. For the moment I managed to debug complex projects in a breadboard with no extra help but I feel I will move to something able to assist you in that.

BTW, isn't the ICD2 criticized because it has only one breakpoint and requires some resources from the micro itself? (Please don't ask me to Google...)
 
atferrari said:
BTW, isn't the ICD2 criticized because it has only one breakpoint and requires some resources from the micro itself? (Please don't ask me to Google...)
Click to expand...

It's a simple cheap debugger - as such it does require some resources from the micro itself - the only other option is an EXTREMELY expensive 'breakout' chip, which has added connections for the debugger (you can get these devices for PIC's that don't have internal debugging).
 
atferrari said:
BTW, isn't the ICD2 criticized because it has only one breakpoint and requires some resources from the micro itself? (Please don't ask me to Google...)
Click to expand...

It does use some upper memory 1/4K, a couple bytes of user RAM and can be a little slow in debug mode. But that not withstanding it's better than no debugger at all. I think the only real drawback is the three I/O pins you require. If you must have it all buy an ICE $2000+
The Inchworm was the first kit I designed that I actually use to design all my new kits. an ICD is a great tool, used properly (DO use watch windows, DON'T view all SFRs at once every open SFR adds about 1 second to the single step time) and you'll have your programs running in record time.
 
I purchased a European PICSTART PLUS clone a long time ago and it worked well but as others have mentioned, it was very slow. I was fortunate to find someone to sell it to as I "upgraded" to a homemade serial ICD2 clone.

Good luck. Regards, Mike
 
Thanks everyone. There's just one thing I'm not sure I get. What do you mean by debugging? How can the programmer help you debug? Doesn't MPLAB have simulation tools for running programs step by step and isn't the programmer's only job to place the HEX file onto the PIC? Thanks again.
 
The ICD2 is an In Circuit Debugger - which means that with suitable PIC's (look for a debug option in the config fuses) you can debug in the actual PIC via the ICD2.

This may, or may not, be helpful to you - but it's obviously an advantageous option, and the InchWorm is cheap anyway.
 
When you debug, you know of how you can attach a few LEDs and have certain parts of your program light them up so you know where the mistake happened?

A debugger is similar except you get to tap directly into the values within the PIC's memory while it's running- so you can tell when things are wrong directly. As far as software simulations go, simulating code doesn't allow you to test the code with the periphreals that are actually attached to the PIC. Not to mention that when it's reality vs simulation, reality always ALWAYS wins.
 
Status
Not open for further replies.

Similar threads

  • Question
Can Oshonsoft use 'byref' in a FUNCTION? (Plus examples of CHAR MATCHING CODE)
3 4 5
Replies
92
Views
16K
camerart
C
LCD display on PICDEM 2 Plus board
Replies
3
Views
2K
christinescoms
C
head aches! plus
Replies
5
Views
2K
MrDEB
PIC plus-5110 LCD-GPS-BMP280-HMC5983
27 28 29
Replies
567
Views
82K
camerart
GSM module inquiry
Replies
2
Views
1K
Vizier87
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…