Hallo, Habe gerade folgendes gesehen: Es gibt jetzt ein PICkit 4: http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=PG164140 Zu erwerben bei digikey um €38,85. Also wie das PICkit3 ungefähr. Hat das schon mal jemand ausprobiert? Wie ist die Geschwindigkeit verglichen mit dem PICkit3? Lohnt die Anschaffung?
Habs auch gesehen. Ist damit auch noch günstiger als das Pickit3. Vielleicht werden jetzt demnächst massenhaft Pickit3 verkauft. ;)
Na wenn es jtag, serial wire und so können soll, dann wird das schon einen Grund haben.
Matthias S. schrieb: > Wäre ja cool, wenn man damit auch AVRs programmieren könnte... Geht das nicht schon mit dem PicKit3, oder war das nur Puscherrei. Volle AVR Kompatibilität, wäre natürlich nach der Übernahme sinnvoll!?
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.
Nils N. schrieb: > Kann man das nicht in Erfahrung bringen? Sorry aber mit VARs hab ich nichts am Hut, sonnst gerne.
>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...
PICianer schrieb: > Der Punkt 2 ist dringend nötig... 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. ;) Danke für die Infos, den Rest hät ich sicher übersehen.
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
Oliver J. schrieb: > Es dauert sage und schreibe 7 Sekunden Naja, deswegen sterbe ich auch nich früher. :) (oder doch?) Aber wenn man eh grad an nem nervigen Bug hängt, macht's das sicher nicht besser. Den Kaffee Konsum würde es bei mir sicher drosseln. Was sonnst in den ~30s machen, als ne neue Tasse holen.
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.
Widerstand schrieb: > Youtube-Video "Microchip Response to PICkit 3 Review from EEVblog #39" :D Der Hammer! Das hätte ich Microchip gar nicht zugetraut. Absolut geile Antwort. Grüße Oliver
Danke für die Info. Ich werde das im Auge behalten. Grade beim Debuggen habe ich mir immer mehr Geschwindigkeit gewünscht. Wäre mir auch ne Neuanschaffung wert. Aber jetzt werde ich doch noch etwas warten.
PICianer schrieb: > Ein Blick in die Release notes sagt: > Alle Devices haben nur Beta-Support. >Warten, bis das in den Release-Notes als "production tested" steht. Also das gleiche Problem das auch ICD4 hat. Auch nach Monaten sind bei diesem nahezu alle gängigen Chips als 'Beta' gelistet. Imerhin geht das Teil bei mir inzwischen so leidlich aber erst nachdem mehrfach die Firmware aktualisiert wurde. Für mich wieder mal ein Bananenprodukt das unfertig auf den Markt geworfen wird.
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.
Hallo, bin beim überlegen ob ich mir ein PicKit4 leisten soll. Mein einziges Problem ist das ich nicht weiß ob der PIC16F917 unterstützt wird, in der IDE wird angegeben das der Chip noch nicht auf kompatiblität getestet wurde (Beta-Support). Vielleicht hat ja jemand von euch schon Erfahrungen damit gesammelt, oder das jemand vielleicht die kompatibliät testen kann. Danke im voraus...
Nach meiner Erfahrung, bis alle verwendeten Prozessoren auf "production tested" Finger weg davon. Es kann bei 'Beta' funktionieren, muß aber nicht. Habe ja den ICD4, die Kompatibilitätsprobleme dürften aber ähnlich sein. Bin gespannt ob Microchip es schafft zum Jahrestag nach Einführung das endlich auch mal die verbreiteten Prozessoren auf 'grün'stehen. PIC 16 habe ich nicht also auch nicht probiert, mit den dsPIC30Fxx klappt es bisher nicht. Ich bin froh noch ein PicKit3 da zu haben, das geht jedenfalls problemlos.
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.
Ralf S. schrieb: > Das sind mistige > Chinesen-Klone, die nicht richtig funktionieren. Naja, man kann auch Spass mit dem Original haben. Ich habe meinen aus dem Microchip Shop (könnte also ein Original sein) und die Inbetriebnahme war unter XP ein Krampf und unter Windows 7 - ein Krampf. MPLab X ging gar nicht und nun bin ich unter MPLab 8. Da funktioniert das Ding meistens.
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.
Angehängte Dateien:
-
Pickit4_debugs_ATmeg328.png
150 KB
> 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.
Es scheint so, als das nun die AVR & SAM damit funktionieren: The MPLAB® PICkit™ 4 In-Circuit Debugger/Programmer allows fast and easy debugging and programming of PIC®, dsPIC®, AVR, SAM and CEC flash microcontrollers, using the powerful graphical user interface of MPLAB X Integrated Development Environment
tiny AVR schrieb im Beitrag #5908929: > Gibt es mittlerweile Erfahrungswerte, ob sich PICkit4 und AS7 vertragen? > Gerne würde ich damit die neueren ATtiny/mega mit UPDI programmieren. Ja, läuft bei mir z. Zt. mit verschiedenen ATtiny Series 0 und 1. Die Inbetriebnahme war aber lästig. Das Gerät (letzte Woche von Microchip geliefert!) benötigte ein Firmware-Update, um überhaupt von Atmel Studio erkannt zu werden. Dazu war es nötig, MPLAB zu installieren, dort ein Dummy-Projekt anzulegen, und beim Versuch, dieses Dummy-Projekt in den ATtiny zu flashen, erfolgte dann endlich das Firmware-Update. Danach ging es mit Atmel Studio. Vielleicht gibt es einen einfacheren Weg der Inbetriebnahme - aber anders habe ich es nicht hingekriegt. Bei Microchip habe ich auch keine Hinweise dazu entdeckt.
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?
Klaus schrieb: > Dieter R. schrieb: >> Dazu war es nötig, MPLAB zu installieren, > > Es reicht das IPE zu installieren, da kann man die Firmware auch > updaten. > > MfG Klaus Dumme Frage: was ist das IPE? ich kann mich nicht entsinnen, dass mir sowas angeboten wurde. Ich habe MPLABX-v5.20-windows-installer.exe heruntergeladen und installiert, 743 MByte. @tiny AVR (Gast): Geht auch Debugging problemlos? Jein. Genauer kann ich das aber nicht definieren. Ich habe auch mit Atmel ICE gelegentlich Probleme beim Debugging von C-Code und Single-Stepping. Ob das mit PICkit 4 mehr oder weniger geworden ist, kann ich nicht sagen. Grobe Vermutung, es ist unverändert. Manchmal hilft es, NOPs einzustreuen und dahin zu steppen. Es scheint mir nicht ein Problem der Debugging-Hardware zu sein.
Dieter R. schrieb: > Dumme Frage: was ist das IPE? ich kann mich nicht entsinnen, dass mir > sowas angeboten wurde. https://www.microchip.com/mplab/mplab-integrated-programming-environment
Teo D. schrieb: > Dieter R. schrieb: >> Dumme Frage: was ist das IPE? ich kann mich nicht entsinnen, dass mir >> sowas angeboten wurde. > > https://www.microchip.com/mplab/mplab-integrated-programming-environment Und wie/wo kriegt man das? Zum Download gibt es da nur den User Guide. Ist das eine der kostenpflichtigen Optionen zu MPLab? Dann kommt man da erstens nicht ran, ohne das ganze MPLab installiert zu haben, und zweitens hat mich MPLab sowieso damit genervt, dass es mehr wie eine Verkaufsplattform als eine Entwicklungsumgebung aussah. Alles sehr undurchsichtig.
Dieter R. schrieb: > Und wie/wo kriegt man das? Zum Download gibt es da nur den User Guide. Is mir auch grad (zum erstem mal aufgefallen). ServiceHeini (~2013) meint gibts nur zusammen mit der IDE, min. MPLAB X 1.2 -> "It is not possible to install IPE as a stand alone application. The IPE uses the MPLAB X IDE frame work, MDB database and hardware tool interfaces and respective drivers to provide programming capabilities to the end user. The following software must be installed on your PC to use the IPE application: • MPLAB X IDE v1.20 or greater. • The MPLAB IPE application (installed automatically with MPLAB X IDE)." (https://www.microchip.com/forums/m701336.aspx)
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
zu Gast schrieb: > 23.43€ bei Microchip Direct. Den gibt es beim Distributor günstiger. Erfahrung mit SAMs habe ich leider keine. Kommt vermutlich in naher Zukunft....
Das Snap Teil wurde mir auf der Embedded Messe vom Microchip Mitarbeiter empfohlen mit "Damit kann man alles Programmieren". Doch weit gefehlt, ältere Prozessoren (dsPIC30, PIC12 und PIC10) werden bis auf wenige Ausnahmen gar nicht unterstützt. PIC18 und PIC16 fast gar nicht nur einige 'Beta'. ATxmega geht gar nicht auch ATMega nicht alle ATSAML geht auch nicht. Ansonsten steht fast alles noch auf 'Beta', kann also gehen, muss aber nicht. Ist ja auch bei IDC4 und PICKit4 seit langem so, da hat sich nur wenig getan. Bin maßlos enttäuscht von den Teilen, groß angepriesen und nach über 1 Jahr immer noch eine Baustelle. Bevor man eines der Teile Anschafft einen Blick in die Kompatibilitätsliste https://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en600333 werfen um sich Enttäuschungen zu ersparen.
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
Okay, ich habe gerade mal nach dem Schema meinen SNAP mit dem SWG meiner ATSAMC21E18A Platine verbunden. Das erste was mir auffällt, MPLAB-X IPE v5.20 zeigt die Target-Spannung nicht an und auch sonst nichts was helfen würde wenn die Verbindung nicht klappt. Ich habe mal "Read" probiert. Das triggert erstmal ein Firmware-Update vom SNAP, so ungefragt und ohne Bestätigung. Danach ging erstmal gar nichts, vorgeblich nicht die richtige ID gefunden, Hinweis auf Problem mit dem Kabel. Also abgezogen, Kabel geprüft, keinen Fehler gefunden, wieder angesteckt, geht immer noch nicht. Dann habe ich meinen Atmel-ICE angeschlossen. Wird auch erstmal erkannt. Beim Read der gleiche Mist wie beim SNAP, es wird ungefragt direkt ein Firmware-Update durchgeführt. Zum Glück funktioniert der ICE aber noch im AS7, als Firmware Version wird jetzt 1.29 angezeigt. Ein Read führt aber nur zu einer Latte an Java Exceptions. Okay, MPLAB-X IPE beendet, neu gestartet. Siehe da, der Atmel-ICE lässt sich jetzt benutzen. Naja, nicht so wie man das aus dem AS7 gewöhnt ist, aber so in etwa. Die Target-Spannung wird nicht angezeigt, MPLAB-X IPE meldet nur "Target voltage detected". Das "Read" macht irgendwas, aber keine .hex irgendwohin schreiben. Die Fuses lassen sich in der MPLAB-X IPE nicht einstellen, man kann also zum Beispiel damit den Bootloader-Bereich nicht schützen. Die Buttons für "Verify" und "Blank Check" sind die ganze Zeit deaktiviert. Mit dem SNAP macht jetzt das "Read" zwar irgendwas, der Controller wird identifiziert und gelesen. Aber "Program" scheint überhaupt nicht zu funktionieren. ---- 2019-07-17 21:29:03 +0200 - Programming... Connecting to MPLAB Snap... Currently loaded versions: Application version............00.02.12 Boot version...................01.00.00 Script version.................00.02.97 Script build number............117b21ad10 Target device ATSAMC21E18A found. Device Id Revision = 0x4 ---- Das ist alles. Mit dem ICE sieht das so aus: ---- 2019-07-17 21:31:57 +0200 - Programming... Currently loaded versions: Application version...........1.41.137 (0x01.0x29.0x89) Target voltage detected Configuration memory will not be programmed because no configuration bits settings have been defined in your code. To program configuration memory, either define the settings in your code or use the Program Configuration Bits button on the configuration memory window. Erasing... The following memory area(s) will be programmed: program memory: start address = 0x0, end address = 0x31ff Programming complete 2019-07-17 21:32:01 +0200 - Programming complete ---- Nope, MPLAB-X 5.20 will ich auch nicht haben.
Rudolph R. schrieb: > Okay, MPLAB-X IPE beendet, neu gestartet. 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. :/
Rudolph R. schrieb: > Siehe da, der Atmel-ICE lässt sich jetzt benutzen. > Naja, nicht so wie man das aus dem AS7 gewöhnt ist, aber so in etwa. > Die Target-Spannung wird nicht angezeigt, MPLAB-X IPE meldet nur "Target > voltage detected". > Das "Read" macht irgendwas, aber keine .hex irgendwohin schreiben. Warum sollte es das? (File -> Export) > Die Fuses lassen sich in der MPLAB-X IPE nicht einstellen, man kann also > zum Beispiel damit den Bootloader-Bereich nicht schützen. Wieso sollte man die Fuses in der Programmiersoftware einstellen wollen? (Warum sind die nicht schon im HEX File?) Im Moment kommt eine Meldung, dass das Editieren der Configuration Bits für AVR deaktiviert ist. Vorstellbar, dass das irgendwann noch aktiviert wird. Jetzt wo ich das schon mit dem ICE und einem ATmega32U4 getestet habe, muss ich es wohl auch noch meinen SNAP ausprobieren... <edit>Der SNAP verhält sich auf den ersten Blick genau wie Atmel-ICE (keine Anzeige der detektierten Spannung und kein Editieren der Config-Bits) <edit2> Ok, SNAP schient nicht zu Programmieren (IPE v5.15) Mit dem PICkit4 sieht es besser aus
:
Bearbeitet durch User
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.
Rudolph schrieb: >> (Warum sind die nicht schon im HEX File?) > > Da ist das Programm drin, wenn überhaupt gehört das in die .elf Hmmm, bei mir sind die im hex mit drin. Vermutlich, weil sie ja auch im Code mit drin sind? Wenn man einen Controller ausließt, bekommt man doch auch nur eine hex und da sind die dann auch drin... Rudolph schrieb: > 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. Ansehen kann das in IPE auch. Muss man aber anscheinend in den "Advanced Mode" IPE ist als Basis nur so zum Importieren einer Datei, brennen und fertig. Den Rest macht man in der IDE. Im Advanced Mode (-> Settings) kann man dann schon mehr tun. Editieren aber (noch?) nicht. Wenn ich mich richtig erinnere kann man das bei PICs, ich verwende IPE nur sehr selten. (z.B zum Flashen eines von unseren Studies abgeschossenen Arduinos) Rudolph schrieb: > Das "Read" müsste direkt einen Datei-Dialog öffnen. Geschmackssache ;-) Rudolph schrieb: > Mit IPE 5.20 klappt nicht mal das Flashen der .hex per SNAP. > -> unbrauchbar. Da muss ich dir zustimmen. (((wird hoffentlich IRGENDWANN funktionieren)))
:
Bearbeitet durch User
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
Funktioniert der SNAP denn jetzt? Ich habe keinen Bock mehr das zu testen nachdem Microchip die Includes für die ATSAM komplett inkompatibel zu den alten Includes gemacht hat.
Keine Ahnung noch nicht getestet.. nutze aber auch nur Pics und hab noch ein pickit3 rumliegen..
> 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 ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.