I just wanted to ask if it's possible to program a PICKIT2 or 3(to program a PIC microcontroller from Microchip) with Atmel Studio 7?
Nope not yet.
Clearly there's a move afoot to combine Atmel's Studio 7 and Microchip's MPLAB (I think it's all moving into MPLAB rather than the other way round) at which point there may be a composite tool that can be used for both AVR and PIC development. But that is way off in the future right now.
I guess it depends what you mean by, "program" ... ?
You could use AS just as glorified editor to write the source text.
You might be able to configure AS to call the microchip command-line utilities to load the executable into the chip.
You might even be able to configure AS to use the microchip toolchain as an "external" toolchain ...
hardly likely to be worth the effort, though?
I want to use AS instead of MPLAB. Means that I want the same source code, which I would have in MPLAB, in AS and then use a PICKIT2 for example and run a PIC.
Such a tool/ add-on would be really great! :-(
Well, as Cliff said, now that the Atmel absorption into Microchip is continuing apace, there will clearly be an amalgamation of the tools in due course - so we will just have to wait and see what happens.
It seems highly likely unlikely that anyone's going to be doing any "quick-fix" stuff in the meantime ...
"unlikely"; not "likely" - see #6
It seems highly likely that anyone's going to be doing any "quick-fix" stuff in the meantime ...
Did you mean un-likely?
As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here.
No guarantees, but if we don't report problems they won't get much of a chance to be fixed! Details/discussions at link given just above.
"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]
"same source code" is an interesting goal. Things like IO, UART, ADC, Timer, etc in AVR are going to be quite different from those in PIC so to use "same" code you are going to have to write in a very modular way to isolate the high level architecture agnostic code from the very CPU specific low level code in what most would call a "Hardware Abstraction Layer" or "HAL". The FatFs code for reading SD/MMC cards from micros is a good example of this. All the high level stuff is architecture agnostic then the micro specific disk_*() functions provide the HAL.
But you have to be very dedicated to make the split between the two levels and at the end of the day in 1/2/4K micros you have to ask yourself if it's worth the effort. Just rewriting the general "idea" for each new micro may be easier and provide a better solution than trying to engineer "one size fits all".
Getting a compiler ecosystem for PICs shouldn't be too difficult. A Web search shows several people have made progress on that. The work is going to be getting the debugger going.
'This forum helps those who help themselves.'
pragmatic ► adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.
"same source code" is an interesting goal..
SAME is the wrong word... Similar is better, but this would just be a goody.
The syntax of the IDE's can be different. There shoud just be an EASY way to write some code in AS and then load everything in a PIC.
I certainly did!
will update the OP
The syntax of the IDE's can be different
The syntax of the source code is 'C' - so any departure from that will only be for proprietary, compiler-specific stuff.
If you want your code to be portable, then you clearly can't go relying upon proprietary, compiler-specific stuff!
Again, as clawson already said, if you really do need to use proprietary, compiler-specific stuff, then you will have to find some way to isolate that.
A common approach is to use conditional compilation.
There shoud just be an EASY way to write some code in AS and then load everything in a PIC.
Atmel Studio was created by Atmel at a time when Microchip was a competitor - why on earth would they make it easy to use their tool to write code for a competitor's products?!?!
Clearly, as already noted, things are different now - and so this will change ...
If you want a common IDE then explore Eclipse, Netbeans, Code::Blocks or similar as they give a common working environment that can be adapted to most micros.
EDIT: I believe recent MPLAB is Netbeans based.
And, of course, Atmel Studio is just MS Visual Studio tweaked to use the AVR & ARM toolchains - so you could tweak it further to add the PIC toolchain(s), if you want ...
A Web search shows several people have made progress on that.
The work is going to be getting the debugger going.
OpenOCD has PIC32 flash and MIPS target.
PlatformIO has a toolchain, Arduino framework, and a PIC32 programmer.
If PlatformIO, Microsoft Visual Studio Code with the Native Debug extension would likely meet one's requirements versus the "heavy"-weight Visual Studio.
"Dare to be naïve." - Buckminster Fuller
©2015 Atmel Corporation