Hi zusammen, leider sind die normalen EDU's nicht mehr bei den deutschen Distributoren gelistet. Hat noch jemand einen abzugeben? Im besten Fall eine der neueren Hardwareversionen. Viele Grüße
Jonas schrieb: > Hat noch jemand einen abzugeben? Theoretisch ja. Jonas schrieb: > m besten Fall eine der neueren Hardwareversionen. Was wären die?
N. M. schrieb: > Jonas schrieb: >> Hat noch jemand einen abzugeben? > > Theoretisch ja. Super :) > Jonas schrieb: >> m besten Fall eine der neueren Hardwareversionen. > > Was wären die? z.B. V10 oder V11 mit RISC-V Unterstützung
Jonas schrieb: > z.B. V10 oder V11 mit RISC-V Unterstützung Ich sehe zwar dass du explizit nach einen J-Link gefragt hast aber vielleicht hast du Lust dir den Black Magic Probe anzusehen. Der scheint inzwischen auch RISC-V support zu haben wenn auch noch nicht offiziell gelistet. Hier im Forum wird es bestätigt: https://github.com/blackmagic-debug/blackmagic/discussions/1751 Hier ist die Liste der offiziell unterstützen Targets: https://black-magic.org/supported-targets.html Ist schon umfangreich. Ich habe mir den BMP auf ein STM32 Black Pill geflasht und es mit Raspberry Pi Pico und einem NRF52 gut benutzen können. Hat sauber funktioniert. Solch ein Board: https://stm32world.com/wiki/Black_Pill Man kann auch BMP HW kaufen, die ist aber teurer als der J-Link EDU :) Hier auf der Seite das abgebildete Board ist es. https://black-magic.org/index.html Bei dem EDU Mini hat Segger ja ordentlich abgespeckt gegenüber dem "alten" EDU, der ja auch ein Gehäuse hatte. Der Preis für den Mini entspricht aber dem alten EDU. Schade.
:
Bearbeitet durch User
Jonas schrieb: > Hi zusammen, > > leider sind die normalen EDU's nicht mehr bei den deutschen > Distributoren gelistet. > Hat noch jemand einen abzugeben? Im besten Fall eine der neueren > Hardwareversionen. > > Viele Grüße Ja der alte EDU wurde komplett eingestellt, es gibt nur noch den Mini. Was vor kurzen noch erhältlich war waren nur noch Restbestände. Beitrag "Re: Welchen SEGGER J-Link kaufen?"
Das BMP und BMP HW habe ich mir auch schon angesehen. Praktisch daran, ist, dass die offizielle Probe auch mit Targets von 1.7V bis 5V verbunden werden kann. Wäre mit einem J-Link EDU auch kein Problem, aber die noch erhältliche mini-Variante kann das leider nicht. Des Weiteren kann das BMP auch RTT was beim Debuggen eines nRF52 mit einem J-Link OB mich auch schon überzeugt hat, da möchte ich bei manchen Targets nicht mehr drauf verzichten. EDIT: Ich war auch schon mit AK MODUL-BUS in Kontakt und habe den letzten EDU um eine Woche verpasst. Da war wohl nicht nur ich am Restbestand interessiert :)
:
Bearbeitet durch User
Jonas schrieb: > Ich war auch schon mit AK MODUL-BUS in Kontakt Bei Segger gibt es evtl. auch noch Reste?
Jonas schrieb: > EDIT: Ich war auch schon mit AK MODUL-BUS in Kontakt und habe den > letzten EDU um eine Woche verpasst. Da war wohl nicht nur ich am > Restbestand interessiert :) Ich habe im November noch einen bekommen, aber ist schon ziemlich schade ich wollte mir auch noch einen zweiten großen holen damit ich nicht dauernd umstecken muss wenn ich zwischen meinen Projekten wechsel.
Angehängte Dateien:
Ich hätte ein abzugeben. Ist der eine neuere Version?
:
Bearbeitet durch User
Das sollte ein EDU der Version 11 aus 2020 KW 12. Den nehme ich :) Was möchtest du dafür?
Zero V. schrieb: > Ich hätte ein abzugeben. Ist der eine neuere Version? Meiner ist deutlich älter 😅 08.2015 Version 9.3
Mi N. schrieb: > https://www.antratek.de/j-link-edu-mini Genau der war nicht gefragt. Der alte EDU ist einfach besser, nicht nur weil er ein Gehäuse hat. Der Mini kann z.B. nur 3.3V Pegel.
900ss schrieb: > Genau der war nicht gefragt. Der alte EDU ist einfach besser, nicht nur > weil er ein Gehäuse hat. Der Mini kann z.B. nur 3.3V Pegel. Gut, das hatte ich überlesen. Allerdings sind mir 5 V Pegel bei neueren µCs nicht mehr begegnet. Alternativ hätte ich auch noch einen jLink-EDU mit Gehäuse abzugeben. Ein älteres Modell V 9.2, was ich kaum gebraucht hatte. Der eignet sich leider nicht für RP2040, aber man könnte ja das Gehäuse für einen EDU-mini verwenden ;-)
900ss schrieb: > Der Mini kann z.B. nur 3.3V Pegel. Das ist gut zu wissen. Nutze ihn regelmäßig an einem 5V Controller. Bisher ohne Probleme. Scheint also ziemlich robust zu sein das Teil.
Luca E. schrieb: > Das ist gut zu wissen. "EDU" Target interface voltage: 1.2V ... 5V (https://www.segger.com/products/debug-probes/j-link/models/j-link-edu/) "EDU mini" Target interface voltage: 3.3V (https://www.segger.com/products/debug-probes/j-link/models/j-link-edu-mini/) Siehe auch Vergleichstabelle https://www.segger.com/products/debug-probes/j-link/#c216543
> Allerdings sind mir 5 V Pegel bei neueren µCs nicht mehr begegnet.
5V sind vollkommen irrelevant. Aber was ist wenn der naechste
Controller in 3Jahren mit 1.8V daher kommt?
Ausserdem gibt es ja auch Leute die stromsparendes Zeug entwickeln
und dann laeuft der Controller vielleicht mit irgendeiner Spannung
in seinem weiten Arbeitsbereich. Wobei Debuggen in so einem Fall
eh kritisch ist weil die Stromaufnahme der Controller erheblich
ansteigt sobald der Debugger einmal die Macrozelle dafuer in
der MCU angeschaltet hat.
Andererseits koennte man ja den Pegelwandler vermutlich recht einfach
nachruesten wenn man den wirklich braucht.
Wobei das ganze aber auch einen Nachteil hat. Die EDUs brauchen
von dem Arbeitsboard noch eine weitere Leitung mit der dortigen
Betriebsspannung. ICh denke mal das man sich die bei den kleinen
Teilen sparen kann.
Ich sehe den Vorteil der EDUs aktuell hauptsaechlich darin das man eine
robuste Plastikkiste im allgemeinen Chaos auf dem Schreibtisch hat.
Aber dem koennte man bei den kleinen Teilen mit einem 3D-Druck
natuerlich abhelfen. .-)
Vanye
Vanye R. schrieb: > ICh denke mal das man sich die bei den kleinen > Teilen sparen kann. Leider falsch. Vtarget wird gebraucht. Wenngleich sie fix mit 3.3V angegeben wird.
:
Bearbeitet durch User
Vanye R. schrieb: >> Allerdings sind mir 5 V Pegel bei neueren µCs nicht mehr begegnet. > > 5V sind vollkommen irrelevant. Aber was ist wenn der naechste > Controller in 3Jahren mit 1.8V daher kommt? Wird heute wieder der Weltuntergang simuliert? Den RP2040 hatte ich schon genannt. Dessen Kerne laufen mit typisch 1,2 V. Erbarmen, zu spät, mit in 3 Jahren und 1,8 V ist also nichts mehr. "Vielleicht, könnte, vermutlich, ..." Deine Probleme sind voll konstruiert. Obwohl mein EDU ein Gehäuse hat und mit 1,8 - 5 V Pegeln umgehen kann, ist er heute teilweise nicht mehr brauchbar. Auf Verdacht zu kaufen ist unsinnig. Sollte sich in 10 Jahren tatsächlich der Bedarf geändert haben, kaufe ich mir ein anderes Teil: 100mal schneller und per Glasfaserverbindung auch gleich galvanisch getrennt ;-)
Vanye R. schrieb: > Ausserdem gibt es ja auch Leute die stromsparendes Zeug entwickeln > und dann laeuft der Controller vielleicht mit irgendeiner Spannung > in seinem weiten Arbeitsbereich. Das passiert auf jeder Platine, die eine eigene Stromversorgung hat. Die wird ja unabhängig vom Debugger ein- und ausgeschaltet und dadurch ergibt sich irgendeine Spannung, zumindest kurzzeitig. Eigentlich kann es ohne Pegelwandler garnicht funktionieren. > Die EDUs brauchen von dem Arbeitsboard noch eine weitere Leitung > mit der dortigen Betriebsspannung. ICh denke mal das man sich die > bei den kleinen Teilen sparen kann. Die Leitung ist für die Pegelwandler, die brauchen die Betriebsspannung, da kann man nicht sparen. Die BMP braucht diese Spannung auch, aber die hat sowieso den kleinen 10-poligen Stecker (ARM Cortex-M). Der kostet auf dem Target zwar 10 Bohrungen, aber eher weniger Fläche als jeder andere Stecker. Und man kann ein Flachkabel mit vernünftigen Steckern verwenden. Ohne Pegelwandler könnte man die Debug-Hardware vom Target aus versorgen. Aber das kostet auch eine Leitung und die Stromaufnahme ist ziemlich hoch. > Andererseits koennte man ja den Pegelwandler vermutlich recht > einfach nachruesten wenn man den wirklich braucht. Vielleicht. Der Pegelwandler für SWD braucht ein Direction-Signal. Und es kostet eine Platine. Wenn ich die Hardware selber bauen wollte, würde ich nicht nur Pegelwandler, sondern auch noch Potentialtrennung spendieren. Der Mehraufwand ist minimal. Mit der BMP-Firmware wäre das ein überaus attraktives Teil. Und vermutlich zukunftssicherer als kommerzielle Teile. > Ich sehe den Vorteil der EDUs aktuell hauptsaechlich darin das man > eine robuste Plastikkiste im allgemeinen Chaos auf dem Schreibtisch > hat. Aber dem koennte man bei den kleinen Teilen mit einem 3D-Druck > natuerlich abhelfen. .-) Oder mit einem fertigen Gehäuse von Reichelt. Die aktuelle BMP-Hardware passt z.B. da rein: https://www.reichelt.de/kunststoffgehaeuse-67-x-32-x-20-mm-5-stueck-rx2kl07-s-5-p292746.html?&nbc=1
Mi N. schrieb: > Den RP2040 hatte ich schon genannt. Dessen Kerne laufen mit typisch 1,2 > V. Erbarmen, zu spät, mit in 3 Jahren und 1,8 V ist also nichts mehr. Die Spannung der Kerne hat hier aber nichts mit den Pegeln der SWD Pins zu tun. Die sind an der IOVdd Power Domain angeschlossen und die geht bis max. 3.6V. Das bedeutet das du den EDU Mini wie auch den "reiner" Mini verwenden kannst für den RP2040 wenn IOVdd an 3.3V liegen. Siehe Datenblatt 5.5.2.2 und 5.5.3.1.
:
Bearbeitet durch User
900ss schrieb: > Die Spannung der Kerne hat hier aber nichts mit den Pegeln der SWD Pins > zu tun. Die sind an der IOVdd Power Domain angeschlossen und die geht > bis max. 3.6V. Mir mußt Du das nicht erklären.
Mi N. schrieb: > Mir mußt Du das nicht erklären. Das lass sich hier anders. Mi N. schrieb: > Vanye R. schrieb: >>> Allerdings sind mir 5 V Pegel bei neueren µCs nicht mehr begegnet. >> >> 5V sind vollkommen irrelevant. Aber was ist wenn der naechste >> Controller in 3Jahren mit 1.8V daher kommt? > > Wird heute wieder der Weltuntergang simuliert? > Den RP2040 hatte ich schon genannt. Dessen Kerne laufen mit typisch 1,2 > V. Erbarmen, zu spät, mit in 3 Jahren und 1,8 V ist also nichts mehr. Und sonst lies es zur Klarstellung für andere :)
:
Bearbeitet durch User
> Das bedeutet das du den EDU Mini wie auch den "reiner" Mini verwenden > kannst für den RP2040 wenn IOVdd an 3.3V liegen. Vielleicht noch was zur Klarstellung! Ich hatte einen der ersten EDUs als die damals rauskamen. Keine Ahnung wie lange das her ist, aber sicher mehr wie 10Jahre. Der funktioniert auch heute noch mit allem was man so begegnet bis auf den RP2040. Das war der erste Controller der von der alten Hardware nicht mehr unterstuetzt wurde und fuer mich ein Grund wieso ich mir letztes Jahr einen neuen EDU gekauft habe. Aber man kann natuerlich davon ausgehen das es in Zukunft mehr werden fuer denen man die neue Version braucht. Vanye
Nachtrag: Der JLink EDU hat noch einen großen Vorteil gegenüber dem Black Magic Probe. Er ist deutlich schneller als der BMP (auf einem Black Pill) z.B. beim Flashen per SWD. Gerade hab ich es bei einem Rapsberry Pi Pico als Target probiert. Siehe am Ende die Transfer rate. Und selbst bei diesem "kleinen" Programm macht das einen Unterschied von knapp 20 Sekunden. Das war mit der aktuellen BMP Firmware.
1 | Black Magic Probe: |
2 | |
3 | (gdb) load picoTest.elf |
4 | Loading section .boot2, size 0x100 lma 0x10000000 |
5 | Loading section .text, size 0x4688 lma 0x10000100 |
6 | Loading section .rodata, size 0xf44 lma 0x10004788 |
7 | Loading section .binary_info, size 0x28 lma 0x100056cc |
8 | Loading section .data, size 0x9754 lma 0x100056f4 |
9 | Start address 0x100001e8, load size 61000 |
10 | Transfer rate: 4 KB/sec, 938 bytes/write. |
11 | |
12 | Segger JLink EDU: |
13 | |
14 | (gdb) load picoTest.elf |
15 | Loading section .boot2, size 0x100 lma 0x10000000 |
16 | Loading section .text, size 0x4688 lma 0x10000100 |
17 | Loading section .rodata, size 0xf44 lma 0x10004788 |
18 | Loading section .binary_info, size 0x28 lma 0x100056cc |
19 | Loading section .data, size 0x9754 lma 0x100056f4 |
20 | Start address 0x100001e8, load size 61000 |
21 | Transfer rate: 4582 KB/sec, 7625 bytes/write. |
Dafür kann man sich unter Umständen "schnell" einen BMP bauen mit Teilen aus der Schublade wenn man keinen Jlink hat :)
900ss schrieb: > Transfer rate: 4 KB/sec, 938 bytes/write. Da wird bestimmt jedes Bit in veganes Geschenkpapier verpackt und CO2 neutral übertragen. Aber Faktor 1000 ist schon heftig! Mich hat am EDU immer der tagtägliche Hinweis genervt. ST-Link war genau so schnell und in der Handhabung völlig unauffällig.
> ST-Link war genau so schnell und in der Handhabung völlig unauffällig. Es gibt ja auch noch andere Hersteller von ARM basierten Controllern. ICh hab auch schon Nordic und NXP genutzt. Ausserdem ist Segger nicht nur unaufaellig sondern die bieten auch viel Zusatzkram. Ich hab mir damit z.B vollkommen problemlos ein Tool (unter Linux) geschrieben das aus dem laufenden Controller mich interessierende Variablenwerte ausliesst. Und auch der virtuelle serielle Port ist doch ganz nett. Die Anschaffung lohnt sich IMHO auch als privater Bastler und vor allem auch unter Linux. Alles entspannt funktionsfaehig. Und es ist in Extremfaellen auch schoen einfach direkt ein gdb-Fenster aufmachen zu koennen und dann wirklich das alle Befehle des gdb nutzen koennen. Vermutlich gibt es hier manche die garnicht wissen was damit alles geht. Schaut mal rein! Wenn ihr denkt das was Eclipse bietet sei bereits der Debugger, nein das sind 5% der Moeglichkeiten die gdb direkt kann. Wer unbedingt auf Geldsparen aus ist und nur ST verwendet kann auch ein Entwicklungskit von ST nehmen, dort den Debugger absaegen und das Teil auf Jlink umprogrammieren. Segger bietet dazu auf ihrer Homepage extra ein Tool an. Aber ehrlich gesagt bei den Moeglichkeiten eines EDUs schieb ich die Kohle mit Freude ueber den Tisch! Vanye
Mi N. schrieb: > Mich hat am EDU immer der tagtägliche Hinweis genervt. Na ja.... Mi N. schrieb: > ST-Link war genau so schnell und in der Handhabung völlig unauffällig. Mit welcher Firmware? Da kann man JLink draufspielen und auch Black Magic Probe. Aber ich glaube beim JLink kann man dann nur ST-Chips nutzen. Weiß es aber nicht genau.
Mi N. schrieb: > Aber Faktor 1000 ist schon heftig! Mit kommt das auch etwas arg wenig vor. Allerdings machen sie alles per Bit Banging. Vielleicht Frage ich mal nach ob das so sein muss bei einem Black Pill als BMP HW.
Vanye R. schrieb: > Vermutlich gibt es > hier manche die garnicht wissen was damit alles geht. Schaut mal rein! Da gehöre ich sicherlich dazu. Die Programmierteile benutze ich wie einen Lötkolben: einschalten und loslegen - ein Werkzeug eben. > Und auch der virtuelle serielle Port ist doch ganz nett. Ist bei ST-Link und bei den aktuellen ST-Entwicklungsboards doch auch dabei. Für mich als Bastler reicht das völlig aus. Ich hoffe, der TO hat mittlerweile etwas Passendes gefunden.
Probier mal, das Programm ins RAM zu laden statt ins Flash. Das geht bei mir sehr viel schneller. Eigentlich müsste doch zuerst ein kleines Hilfsprogramm ins RAM geladen werden. Das weiß, wie der spezielle Chip geflasht wird. Das eigentliche Programm wird dann auch erst ins RAM geladen, ggf. blockweise.
Bauform B. schrieb: > Probier mal, das Programm ins RAM zu laden statt ins Flash. Das geht bei > mir sehr viel schneller. Es geht auch ins Flash schnell wie der JLink zeigt. Mir gefällt der BMP aber trotzdem gut. Er bietet auch RTT, ein sehr hilfreiches Feature.
:
Bearbeitet durch User
> Probier mal, das Programm ins RAM zu laden statt ins Flash. Das geht bei > mir sehr viel schneller. Das ist in der Regel nicht sinnvoll weil du dann ein Programm anders uebersetzen musst und auch ein anderes Zeitverhalten hast. > Eigentlich müsste doch zuerst ein kleines Hilfsprogramm ins RAM geladen > werden. Das weiß, wie der spezielle Chip geflasht wird. Ueberraschung. So macht der J-Link das. Und der flasht wohl auch nur Teile die sich wirklich geaendert haben neu. Das duerfte mit zu seiner hohen Geschwindigkeit beitragen und nebenbei die Lebensdauer der MCU erhoehen. Vanye
Das mit den 4 kB/s kann nicht sein, da wäre ich schon lange an Koffein Überdosierung gestorben. Habe BMP auch lange Zeit benutzt, sogar auf dem F103 war der ordentlich schnell. Für meine modifizierte Variante mit F407 und Ethernet habe ich so an die 20 MB/s in Erinnerung. Da muss irgendwas faul sein.
Vanye R. schrieb: > Ueberraschung. So macht der J-Link das. Und der flasht wohl auch nur > Teile die sich wirklich geaendert haben neu. Das duerfte mit zu seiner > hohen Geschwindigkeit beitragen und nebenbei die Lebensdauer der MCU > erhoehen. Jetzt wird es wohl esoterisch ;-) Dem Controller ist das völlig schnuppe und der FLASH-Speicher läßt sich nur (mindestens) sektorweise löschen, was richtig Zeit (typ. 45 ms / 4KB Sektor) braucht, und neu beschreiben. Vielleicht schreibt BMP in zu kleinen Häppchen?
J. S. schrieb: > Da muss irgendwas faul sein. Den Verdacht habe ich auch. Aber ich habe gerade keine Idee, was ich falsch mache. Übersetzt wird nach deren Anweisung. Habe die letzte Version, also aktuell. Muss ich nochmal schauen.
hast du einen STM32 zum flashen da? Ob es beim RP2040 langsamer ist? Obwohl ich mir das auch nicht recht vorstellen kann.
Vanye R. schrieb: >> Probier mal, das Programm ins RAM zu laden statt ins Flash. Das geht bei >> mir sehr viel schneller. > > Das ist in der Regel nicht sinnvoll weil du dann ein Programm > anders uebersetzen musst und auch ein anderes Zeitverhalten hast. Ja, in der Regel, hier hast du die berühmte Ausnahme ;) Im Extremfall wurde die BMP durch eine zu niedrige Baudrate ausgebremst und die würde ins RAM genauso bremsen. Oder der SWC Takt ist zu langsam. Oder sowas.
J. S. schrieb: > hast du einen STM32 zum flashen da? Ja, ich könnte einen Black Pill mit einem Black Pill flashen ;) NRF52842 müsste hier auch noch rumdiffundieren :) ESP32 hat kein SWD wenn ich mich nicht irre. Ich glaube ich weiß zumindest weshalb der JLink soooo schnell war. Ich habe die gleiche SW geflasht die schon drin war %-) Ich hatte nicht mehr auf den Schirm dass der JLink das intelligent macht wie oben schon beschrieben. Er scheint nur für Blöcke zu schreiben die sich auch geändert haben. Das war mir vor 10+- Jahren schonmal aufgefallen aber die Gehirnzelle mit dem Wissen scheint tot. Ich probiere das wenn ich wieder an meiner Werkbank sitze.
:
Bearbeitet durch User
900ss schrieb: > Ja, ich könnte einen Black Pill mit einem Black Pill flashen Das hab ich jetzt gemacht. Sieht dann schon deutlich besser aus.
1 | (gdb) load project.elf |
2 | Loading section .text, size 0x2708 lma 0x8000000 |
3 | Loading section .rodata, size 0x70a30 lma 0x8002708 |
4 | Loading section .data, size 0x858 lma 0x8073138 |
5 | Start address 0x08000600, load size 473488 |
6 | Transfer rate: 54 KB/sec, 980 bytes/write. |
Aber an den JLink kommt er auch hier nicht ran. Den JLink hab ich nochmal laufen lassen und vorher das Flash gelöscht. Er bleibt so schnell. Wenn der Black Magic Probe den Rpi Pico flasht, muss er ja auch noch durch das QSPI Interface um an das Flash zu kommen. Wenn die das alles "zu Fuss" machen, dann dauert das natürlich. Ist zumindest meine Erklärung. Das Debuggen auf dem Pico mit BMP geht allerdings nicht langsam. Und das RTT beim BMP geht auch deutlich schneller als einen UART zu bemühen. Den NRF52 noch zu testen hab ich jetzt keine Lust ;) Nachtrag: Es gibt für den BMP noch den Befehl "mon frequency xxxk/M". Mit dem konnte ich die Rate noch etwas erhöhen (wiederholbar).
1 | Start address 0x08000600, load size 473488 |
2 | Transfer rate: 65 KB/sec, 980 bytes/write. |
:
Bearbeitet durch User
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.