PICkit 4 wird verkauft

Habs auch gesehen. Ist damit auch noch günstiger als das Pickit3. 
Vielleicht werden jetzt demnächst massenhaft Pickit3 verkauft. ;)

Also einen AVR/PIC Programmer und Debugger für so kleines Geld wäre echt 
cool

Kann man das nicht in Erfahrung bringen? Ich versuch mich mal schlau zu 
machen. Dann würde ich meine ganzen AVR Programmer nicht mehr brauchen.

EDIT: Offiziel scheinbar nicht, steht zumindest nur PIC und dsPIC in der 
Broschüre.

>Wie ist die Geschwindigkeit verglichen mit dem PICkit3?

PIC32 -> Start debugging bis zum ersten Breakpoint:

PICKIT3          23 Sekunden
PICKIT4          10 Sekunden


Und auch der Single Step (F7) geht flüssiger.

Da die PickitX ja schon immer 12 auf Reset konnten, ist es eigentlich 
nur eine Frage der Software, um UPDI zu sprechen. Irgendwo habe ich auch 
mal aufgeschnappt, dass das PK4 für die AVR angepasst wird. Würde mich 
freuen. Wenn dann MPLABXv5.x auch die AVR verarztet, kann ich endlich 
Windows wieder einpacken (Und sie ein paar der guten Features des VS bei 
MPLABX einbringen):

Nur einen kleinen Schönheitsfehler hat MPLABX. Dessen mchplinusbdevice 
crasht ganz gerne mit Rückgabewert -6 (timeout für bind/unbind?). Das 
bringt systemd-udevd durcheinander und man muss n * 2 Minuten warten, 
bis der PC erkennt, dass das Pickit nicht angesteckt ist. Und dieses 
Verhalten ist bedingt durch "loading firmware". Wenns klemmt, ist ein 
reboot schneller.

neuer PIC Freund schrieb im Beitrag #5340032:
>>Wie ist die Geschwindigkeit verglichen mit dem PICkit3?
>
> PIC32 -> Start debugging bis zum ersten Breakpoint:
>
> PICKIT3          23 Sekunden
> PICKIT4          10 Sekunden
>
>
> Und auch der Single Step (F7) geht flüssiger.

Das klingt gut.
Da demnächst eh eine Bestellung bei Microchip-direct dran ist, wird das 
möglicherweise gleich mitgehen. Dort kostet das USD 47,95.

Teo D. schrieb:
> Laut Aufmacher scheint es mir aber nichts wirklich neues dran zu geben?

Doch, zum Beispiel:
- 4-Wire-JTAG
- Mehr Geschwindigkeit
- Eine µSD-Karte für Firmware images.

Der Punkt 2 ist dringend nötig...

Habt ihr gesehen, dass der Pickit4 einen 8-poligen Stecker hat, statt 6? 
Reserved for fututre use.

Oliver J. schrieb:
> Teo D. schrieb:
>> Wollt ich eigentlich ignorieren, nich wichtig für mich. Aber... es Nervt
>> halt doch. Könnt durchaus sein, das es hier bald eine 3er Version zu
>> verschenken gibt. ;)
>
> Das Pickit 3 zusammen mit der Hostsoftware MPLAP-X ist eine pure
> Frechheit. Es dauert sage und schreibe 7 Sekunden, bis das Pickit 3 bei
> mir anfängt einen 18F2550 zu flashen (die 18F-Firmware ist da übrigens
> schon drinnen) und es braucht dann noch ca. 5 weitere Sekunden, um 100
> Byte zu flashen und das Kommandozeilen-Programm zu beenden. Das geht
> doch locker in unter einer Sekunde, wenn man es richtig macht. Wie
> konnte so etwas nur die Qualitätsabteilung bei Microchip verlassen? Das
> ist echt ein Armutszeugnis.
>
> Grüße Oliver

Wenn es nur 7 Sekunden wären ;-)

Mein letztes Projekt hatte einen PIC32MX370 und mehrere 24-Bit ADC. Ich 
hatte mehrere digitale Filter pro Kanal.
Wenn man jetzt mit dem PICkit3 ein paar kBytes Samples ziehen will, oder 
eine große Struktur im Watch hat, kann man sich nicht nur einen Kaffee 
holen gehen, man kann ihn schon fast selber rösten.

Da ist ein schnelleres PICkit4 eine zwingende Notwendigkeit. Schon wegen 
der Konkurrenz (ST hat das Problem nämlich nicht).

Ich hatte mit meinem ICD3 das Problem auch nicht. Ich habe einfach den 
1. Klasse Zuschlag gelöst, sozusagen.

fchk

So, habs heute überraschend schon geliefert bekommen.

Frisch von Microchip direct mit 60,64$ (47,95$ PICkit, 3,01$ freight 
charge, 9,68$ VAT) auf der Rechnung (das sind 48,9€).
Die EIGENTLICH bestellten Bauteile waren natürlich nicht dabei.

Ausprobiert hab ich das mit einem PIC32MX470F512H mit 2-Wire (ICSP). Das 
Projekt ist nicht sehr groß, etwa 22% Flash.

Positiv:
- Programmieren geht in ca. 1,5s statt so 7s
- Single-step ist sehr flott
- Man kann jetzt auch im laufenden Betrieb Breakpoints reinwerfen

Ich kann bestätigen: Das PICkit4 ist viel flotter. Vor allem das 
Debuggen ist sehr viel flüssiger.

Wie stabil das läuft, kann ich aber noch nicht sagen.
Wer Microchip kennt, ist erst mal skeptisch...

PICianer schrieb:

> Positiv:
> - Programmieren geht in ca. 1,5s statt so 7s
> - Single-step ist sehr flott
> - Man kann jetzt auch im laufenden Betrieb Breakpoints reinwerfen
>

Vielleicht wurde Mr. Head gefeuert. :)

https://www.youtube.com/watch?v=3YUvlrVlNao

(Über 8 Jahre ist das schon her, irre! Daher für die Jüngeren hier auch 
den Auslöser: https://www.youtube.com/watch?v=LjfIS65mwn8 EEVBlog #39 
von Oktober 2009.)

Master S. schrieb:
> Wie ist das PK4 im Vergleich zu einem ICD3 ?

Ich habe keinen ICD3, der war mir immer zu teuer (ich mach das als 
Hobby). Daher kann ich dazu nichts sagen.
Gefühlt kann man es vergleichen mit ST-Link bei den STM32.

Der Unterschied zum PICkit3 ist jedenfalls groß.

Widerstand schrieb:
> Vielleicht wurde Mr. Head gefeuert. :)
>
> https://www.youtube.com/watch?v=3YUvlrVlNao
>
> (Über 8 Jahre ist das schon her, irre! Daher für die Jüngeren hier auch
> den Auslöser: https://www.youtube.com/watch?v=LjfIS65mwn8 EEVBlog #39
> von Oktober 2009.)

Das kannte ich noch gar nicht.
Dave Jones hatte da ziemlich ins Schwarze getroffen.

Aber eine derartige Antwort von einer Firma wie Microchip hätte ich 
nicht erwartet. Viel besser als das übliche Manager-Gestammel :-)

Hab mir auch ein PK4 bestellt.
Welches Format an SD Karte (Micro Mini ...etc.) wird benötigt, um die 
ProgrammertoGo Funnktion zu nutzen ?

Gruß Dirk

Ich habe ein bischen mehr damit gearbeitet.

Stabilität und Geschwindigkeit sind zwar gut, aber es gibt Probleme:
Bei meinem Device (PIC32MX470) ist der gesamte Peripheral-Adressbereich 
nicht lesbar - ich bekomme überall 0x0000.
Das schränkt die Nutzbarkeit ein.

Ein Blick in die Release notes sagt:
Alle Devices haben nur Beta-Support.

Desweiteren:
"General debugging errors may occur while debugging at higher oscillator 
speeds. Changing to a slower oscillator speed like internal FRC without 
PLL may improve the debug experience."

Geht bei mir nicht, mein Projekt läuft auf 80MHz. Und USB mit FRC ohne 
PLL ist auch nicht möglich.

Meine Empfehlung lautet:
Warten, bis das in den Release-Notes als "production tested" steht.

Naja, Early adopter halt. Muss halt wieder das PICkit3 ran.

Habe mein PK4 bekommen.

PIC32MX795F512L  :  Noch nicht unterstützt

PIC18F46K20 :  Nach mehrmaligen FW Updates läuft er.
Programmieren und Debuggen geht recht schnell.

Positiv:
ER programmiert nur die benutzten Programmspeicher, ist so viel 
schneller.

Power from Target:  Geht. Nützt aber noch nichts, solange ProgrammertoGo 
nicht unterstützt wird.

Und was ist nun mit dem AVR Support?
Irgendwie untergegangen oder absurdes Wunschdenken?

Männo schrieb:
> Und was ist nun mit dem AVR Support?
Die Hoffnung stirbt zuletzt.
Wenn Microchip es nicht mal schafft (oder nicht will) die eigenen 
Chipfamilien zu supporten, da kann man sich an drei Fingern abzählen, 
wann die zugekauften Chipfamilien unterstüzt werden...

Bei Reichelt gibt's den pickit4 noch nicht. Merkwürdigerweise ist 
Reichelt da ziemlich teuer: pickit3: 57 euro

Was mir eben auch noch aufgefallen ist: Auf ebay gibt's einen Haufen 
pickit3 für 1 Euro 50! Finger weg sage ich da. Das sind mistige 
Chinesen-Klone, die nicht richtig funktionieren. Die originalen 
Programmierer haben das Microchip-Logo aufgedruckt.

Die Clone funktionieren prima

Geschwindigkeit ist aber nicht alles!
Habe das PICkit4 in der Firma gekauft in der Hoffnung auf mehr 
Zuverlässigkeit, brachte da aber nichts. Und es funktioniert nicht mehr 
mit so älteren PIC Basteltypen wie PIC16F886, PIC16F877. PIC16F1933 ist 
okay. Meldet da immer Invalid Device ID. Beim PIC16F886 wird ID 0x2060 
angezeigt und dann die Fehlermeldung.
Schade, das Original PICkit3 und das damit kompatible (mehr Strom) 
Olimex PICkit3 funktionieren einfach besser. Die paar Sekunden schneller 
bringens dann auch nicht. Zumal wie beim ICD3 beim PICkit4 auch der 
Controller nicht läuft, solange der Flasher gesteckt ist. Also kein 
Debuggen möglich! 10-20k sind hier immer an MCLR Pin1 gegen 5V. 
Blink-LED zur Kontrolle ist da Pflicht. Manchmal hilft PICkit mit Power 
On, aber auch nicht immer, das alte Problem mit den Microchip Flashern 
halt. Ständige trennen der USB Leitung und neu stecken hilft da auch 
nicht, wie sonst oft nötig. Mache ich schon mindestens 20x am Tag wegen 
Connect-Fehler usw. Manchmal hilft ein Wechsel des Flashers, dann wieder 
der Alte gesteckt und dann geht es. Damit kämpfe ich schon seit Jahren. 
Laut Mitarbeiter von Microchip soll man auch möglichst das lange rote 
USB Kabel am PICkit3 nicht verwenden, sondern ein Kürzeres. Leider haben 
die das mit dem PICkit4 alles nicht verbessert! Das PICkit3, leider ohne 
SW-Breakpoints, ist da immer noch am sichersten.

Die alten PICs soolten doch unterstütz werden. Die neuen kommen nach und 
nach. Die bei Dir nicht funktionieren, stehen die in der Supportliste?

Frage mich, wie MicroChip seine eigenen PIC flashed?

Steffen schrieb:
> Zumal wie beim ICD3 beim PICkit4 auch der
> Controller nicht läuft, solange der Flasher gesteckt ist. Also kein
> Debuggen möglich! 10-20k sind hier immer an MCLR Pin1 gegen 5V.
> Blink-LED zur Kontrolle ist da Pflicht.

Habe eben mit aktueller Firmware MPLABX 4.20 mit dem PICKIT4 einen 
12F1612 geflashed.
Stimmt, die MCU läuft nicht an, solange der PK4 gesteckt ist, obwohl 
MCLR Funktion am PIN per Config Bits deaktiviert ist.
Dann lässt der PK4 scheinbar die Programmiersppannung auf dem pin auch 
nach bendeter Programmierung anliegen.

Aber debuggen geht bei mir.....

Wer genau wissen möchte, welches Device wie gut untersützt wird, der 
nehme sich die Release Notes:
http://www.microchip.com/mplabx-ide-release-notes
Entpacke sich das und öffne "Readme for PICkit 4.htm". Dort kann man zu 
"Device-Support" und weiter zu "Device Support List" navigieren.

Und zum PIC16F886 heißt es beispielsweise:
"Beta Support".
Kann gehen, oder nicht.

Mein Rat wäre zu warten, bis die verwendeten Derivate in der Liste auf 
"grün" springen, bevor man sie mit dem PICkit4 verwendet.
Also ein paar Releases von MPLABX dürfte das noch dauern.

Microchip hätte das Teil einfach noch nicht auf den Markt bringen 
dürfen.

Ich hol das Teil aus dem Schrank, wenn "meine" Devices auf grün 
springen, vorher sicher nicht mehr.

> Wäre ja cool, wenn man damit auch AVRs programmieren könnte...

So langsam geht es los.

Pickit4 meets ATmega328P

Sogar die Umschaltung ISP/dW funktioniert; aber nicht zuverlässig. 
Manchmal klemmt es und ein Neustart von MPLABX wirkt wie Medizin.

Über "IO View" kann man die Bits in den SFR setzen wie beim Atmel 
Studio.

Nur der Speed ist noch typisch Pickit. Das Atmel ICE ist hier schneller.

Was sich nicht mit dem PICKIT2 programmieren lässt,
ist Teufelswerk und kommt nicht in mein Haus!

Gibt es mittlerweile Erfahrungswerte, ob sich PICkit4 und AS7 vertragen?
Gerne würde ich damit die neueren ATtiny/mega mit UPDI programmieren.

Dieter R. schrieb:
> Dazu war es nötig, MPLAB zu installieren,

Es reicht das IPE zu installieren, da kann man die Firmware auch 
updaten. MPLABX programmiert die PICKits (3 oder 4) immer passend zum 
Prozessor um. Da interessiert es nicht, was bei der Auslieferung drauf 
ist.

MfG Klaus

Dieter R. schrieb:
> Ja, läuft bei mir z. Zt. mit verschiedenen ATtiny Series 0 und 1.
>
> Die Inbetriebnahme war aber lästig.

Danke, ich lade mir gerade die notwendige SW herunter und hoffe, dabei 
keine Picel zu bekommen ;-)
Geht auch Debugging problemlos?

Es gibt noch den PG164100 - MPLAB(R) Snap In-Circuit Debugger, der 
kostet 13.25€ + Umsatzsteuer 3.74€ + Versand 6.44€ = 23.43€ bei 
Microchip Direct.

Hat damit jemand Erfahrung? z.B. die SAM-Mikrocontroller

Ich wollte auch gerade den SNAP in die Runde werfen, so als günstige 
Alternative. Das Teil ist dem PicKit4 sehr ähnlich, kommt aber bei dem 
Preis ohne Gehäuse.

Den SNAP habe ich auch schon lange rum liegen, nur hatte ich mit dem 
MPLAB-X bisher so gar keine Motivation die 2,54 mm Pin-Leiste auf SWD zu 
adaptieren.
Vielleicht mit 5.30 oder 5.40.

Inzwischen benutze ich neben dem ICE den J-Link Edu Mini mit dem AS7, 
der brennt mit 21,55€ bei Mouser auch nicht so ein tiefes Loch in die 
Tasche.

Falls noch wer die Pin-Belegung für den SNAP sucht, die steht in der 
Online-Hilfe vom MPLAB-X unter PicKit4.

PicKit4->Hardware Specification->Commnunication Interface->Pinout for 
Interfaces

SWD:
1 MCLR
2 VTG
3 GND
4 SWO
5 SWCLK
6 -
7 -
8 SWDIO

Teo D. schrieb:
> Sobald einem bei MPLAB-X ein "Häää" durch den Kopf geht, ist dies immer
> als Erstmastname DRINGENDST zu empfehlen! Ich vergess das nur leider
> allzu oft. :/

Ich weiss nicht, wie oft ich mir MPLAB schon angesehen habe, aber ich 
hatte noch nie den Eindruck, dass das richtig funktionieren würde.

Volker S. schrieb:
>> Das "Read" macht irgendwas, aber keine .hex irgendwohin schreiben.
>
> Warum sollte es das? (File -> Export)

Warum sollte ich File->Export zusätzlich machen müssen?
Software die auf der einen Seite so einen eingeschränkten 
Funktions-Umfang hat, sich auf der anderen Seite aber nicht intuitiv 
bedienen lässt, ist direkt für die Restbit-Tonne.
Das "Read" müsste direkt einen Datei-Dialog öffnen.

Volker S. schrieb:
> Wieso sollte man die Fuses in der Programmiersoftware einstellen wollen?

Wo denn sonst?
Genau für sowas ist die Programmiersoftware doch da.
Sowas wie "Verify" ist grundsätzlich auch nicht überflüssig.

> (Warum sind die nicht schon  im HEX File?)

Da ist das Programm drin, wenn überhaupt gehört das in die .elf.
Nur bräuchte man dann als erstes eine Schnittstelle das da rein zu 
bringen.
Und mit .elf kann IPE sowieso nicht umgehen.

Ich habe eine fertige .hex, die will ich brennen, das ist ein 
Bootloader.
Dann will ich noch die ersten 8kB schützen.
Mit AS7 ist das überhaupt kein Problem.
Ich kann mir die Fuses ansehen, was eingestellt ist, bekomme angezeigt 
was das alles bedeutet und kann das ändern.

Mit IPE 5.20 klappt nicht mal das Flashen der .hex per SNAP.
-> unbrauchbar.

Hallo, hat schon jemand das programming on go versucht? Ich wollte mit 
einer 16gb sd probieren formatiert als fat und ntfs aber dabei kam immer 
sd not supportet.

Lg

> Mit IPE 5.20 klappt nicht mal das Flashen der .hex per SNAP. -> unbrauchbar.

Nö. Habe ich schon geschafft. Kein Bock IDE laden. Also schnell IPE und 
hex gebrannt -> AVR läuft.

> Im Moment kommt eine Meldung, dass das Editieren der Configuration Bits für AVR 
deaktiviert ist. Vorstellbar, dass das irgendwann noch aktiviert wird.

Habe ich mit v5.20 geschafft. Dazu das Projekt, wie Empfohlen, temporär 
auf Simulator stellen. Dann klappt es Klicki-bunti-fuse-copy-paste.

neuer PIC Freund schrieb im Beitrag #5940882:
>> Mit IPE 5.20 klappt nicht mal das Flashen der .hex per SNAP. -> unbrauchbar.
>
> Nö. Habe ich schon geschafft. Kein Bock IDE laden. Also schnell IPE und
> hex gebrannt -> AVR läuft.

Du hast nur nicht mitbekommen, dass sich das auf das Flashen von 
ATSAMC21E18A bezog, mit AVR habe ich das nicht ausprobiert.

Man kann die IPE Stand Alone installieren, indem man bei der 
Installation von Mplabx einfach das Häkchen bei Mplabx entfernt ;)