Moin, die Frage wurde sicher schonmal gestellt, aber ich habe nichts konkretes dazu gefunden (wie ich mich kenne, finde ich was, nachdem ich das Thema erstellt habe…) Im Moment überlege ich, auch mal in Richtung 32-Bit zu gehen. Also Segger J-Link und zum Beispiel STM. Funktioniert das genauso einfach wie beim AVR, besonders auf der Hardwareseite? Beim AVR schließt man (A)VCC und (A)GND and, eventuell noch Quarz oder Oszillator und die sechs Pole des ISP-Steckers und man hat ein einsatzbereites System. Funktioniert das bei STM und anderen 'Standard'-ARM-Controllern genauso einfach oder muss man irgendwas besonderes beachten?
Dussel schrieb: > Moin, > > die Frage wurde sicher schonmal gestellt, aber ich habe nichts konkretes > dazu gefunden (wie ich mich kenne, finde ich was, nachdem ich das Thema > erstellt habe…) > > Im Moment überlege ich, auch mal in Richtung 32-Bit zu gehen. Also > Segger J-Link und zum Beispiel STM. > Funktioniert das genauso einfach wie beim AVR, besonders auf der > Hardwareseite? > Beim AVR schließt man (A)VCC und (A)GND and, eventuell noch Quarz oder > Oszillator und die sechs Pole des ISP-Steckers und man hat ein > einsatzbereites System. Funktioniert das bei STM und anderen > 'Standard'-ARM-Controllern genauso einfach oder muss man irgendwas > besonderes beachten? Das kommt ganz auf den Controller darauf an. Ich habe z.B. einen STM32F030F4 auf einem Breakout board mit nur einem 100nF Kondensator an der Versorgung und einem Pull-up am Reset. Dazu die Pins vom Programmer und es geht ohne Probleme. Bei größeren Chips kann es sein, dass mehr Ansprüche an die Versorgung gestellt werden. Für die STM32 gibts auch die sehr günstigen Nucleo dev-boards, die haben schon einen Programmer drauf, den man per Stiftleiste als externen Programmer benutzen kann. Segger bietet auch ein Programm an den on-board STLink auf J-Link zu flashen, darf dann halt nur für nicht-kommerzielle Zwecke eingesetzt werden.
Die ARMs brauchen ein paar mehr Stützkondensatoren und können (bis auf wenige Ausnahmen) keine 5V. Die Beschaltung steht im Datenblatt. Die neue STM32G0 Serie soll in dieser Hinsicht besonders einfach sein. Am sinnvollsten ist es aber sicherlich, sich einfach ein fertiges Breakout Board zu kaufen, wie z.B. die "Blue Pill" Boards.
Dussel schrieb: > oder muss man irgendwas > besonderes beachten? Mal bei STM in die Appnotes geschaut? Da gibt es Hardware Design Richtlinien und Guides. Die braucht man bei SMD Designs. Dr. Sommer schrieb: > Die ARMs brauchen ein paar mehr Stützkondensatoren und können (bis auf > wenige Ausnahmen) keine 5V. Das ist eins der Probleme: Weil die Betriebsspannung klein ist (Kernspannung oft um 1,2V bei neueren Designs) bleibt wenig Raum für Designfehler. Daher will man sich ein Devel-Board zulegen, dort ist wenigstens klar dass die Hardware so funktioniert wie gedacht. Ist oft sogar billiger als ein einzelner SEGGER J-Link.
Es geht darum, die Controller auf eigenen Platinen einzusetzen. Stützkondensatoren sind natürlich selbstverständlich und 5 V sind ja auch nicht fest vorgegeben. Die Frage ging eher in die Richtung, ob man die ohne weitere spezielle Bauteile und ohne übermäßige Komplexität der Platine einsetzen kann.
Für dich werden sich unterscheiden: -Nur 2 leitungen zum flashen und Debuggen -Einige pins brauchen definierte Pegel beim start, um den Bootmodus auszuwählen
Jim M. schrieb: > Dussel schrieb: >> oder muss man irgendwas >> besonderes beachten? > > Mal bei STM in die Appnotes geschaut? Da gibt es Hardware Design > Richtlinien und Guides. Die braucht man bei SMD Designs. Meh, also jetzt bleiben wir mal auf dem Teppich. Für den durchschnittlichen ARM Cortex M4-Controller kabelt man halt irgendwie die Versorgungsspannung an und klebt ein paar Stützkondensatoren daneben, dann tut das schon. Das ist jetzt wirklich kein Hexenwerk.
Bei PIC32 ist das genauso wie bei den kleineren PICs: 100nF an jedes GND-VCC und AGND-AVCC Paar, 10k zwischen MCLR (Reset-Pin) und VCC, 10uF keramisch zwischen VCAP und GND, und schon läuft die Kiste. fchk
Dussel schrieb: > Funktioniert das genauso einfach wie beim AVR, besonders auf der > Hardwareseite? Ja. > muss man irgendwas besonderes beachten? Nur, dass er mehr Versorgungs-Pins hat, als AVR. Jedes päärchen soll einen eigenen Stützkondensator bekommen. > ob man die ohne weitere spezielle Bauteile und ohne übermäßige > Komplexität der Platine einsetzen kann. Es sind keine weiteren speziellen Bauteile nötig. Was für dich "übermäßig" wäre, weiss ich nicht.
Und der Analog VDD/VSS muss immer angeschlossen werden sonst läuft die interne Taktdomäne nicht. (RC Schwinger, PLL, etc.)
Sven B. schrieb: > Für den > durchschnittlichen ARM Cortex M4-Controller kabelt man halt irgendwie > die Versorgungsspannung an und klebt ein paar Stützkondensatoren > daneben, dann tut das schon. Das sind ja sowieso die Grundlagen. Stefanus F. schrieb: > Was für dich "übermäßig" wäre, weiss ich nicht. Zum Beispiel haben FPGAs viele Versorgungsspannungspins und drei oder vier verschiedene Spannungen. Für Analog- und HF-Platinen muss man besondere Regeln einhalten, die man teilweise nur durch Erfahrung, Simulation oder Versuch herausfindet. An sowas habe ich gedacht. Wenn ich von etwas keine Ahnung habe, gehe ich davon aus, dass es etwas geben könnte, woran ich nicht gedacht habe. Deshalb frage ich nach. Danke für die Antworten. Dann werde ich mich mal drum kümmern. Noch eine Frage am Rande: Gibt es einen Grund dafür, dass die J-Link-Adapter so teuer sind? Der J-Link 9-pin Cortex-M Adapter kostet bei Segger 24€ für ein kleines Platinchen, einen Stecker und ein Kabel (https://www.segger.com/purchase/pricing/jlink-related/) Oder liegt das einfach an der Nachfrage?
Dussel schrieb: > Gibt es einen Grund dafür, dass die > J-Link-Adapter so teuer sind? Ja, sie sind der "Mercedes" unter den Programmieradaptern. Sie unterstützen besonders viele Mikrocontroller, Protokolle und sind die schnellsten. Mit dem "Dacia" komme ich aber auch gut zurecht: https://www.amazon.de/ST-Link-Programming-H¨¹lle-Emulator-Downloader/dp/B01F37YMJ4/ Ebenso komme ich auch mit dem Original von STM32 gut klar, das du von jedem beliebigen Nucleo-Board abtrennen kannst: https://www.amazon.de/stmicroelectronics-STM32-nucleo-64-Development-unterstützt-Arduino-Konnektivität/dp/B0121QTVV4
Stefanus F. schrieb: > Ja, sie sind der "Mercedes" unter den Programmieradaptern. Sie > unterstützen besonders viele Mikrocontroller, Protokolle und sind die > schnellsten. Es ging nicht um J-Link selber, sondern um die Pin-Adapter/Ausgangsadapter. 20-polig auf neunpolig oder 14-polig zum Beispiel.
Vielleicht werden die von Ingenieuren mit 20 Jahren Berufserfahrung in Handarbeit gebaut, persönlich gewidmet und von einem speziellen Kurierdienst der Firma gebracht. Wer Programmieradapter für hunderte Euros kauft, der hinterfragt solche Details nicht. Apple Kunden tun das auch nicht.
Nunja JLinks mit Apple vergleichen. Beim JLink bekommt man was ordentliches, bei crapple nur Hipsterkram ;) Die zugehörigen Segger Softwarepackete müssen auch mit in die Rechnung, beim stlink bekommste das nicht alles. Warum deren Adapterplainen so sackteuer sind weis ich auch nicht, aber sowas lötet man Daheim doch eh selbst? Der JLink Edu für seine 60€ ist sehr zu empfehlen. Währenddessen man beim STlink einschläft beim durchsteppen und 10 Variablen angucken geht das mit dem JLink ratzfatz. Lauterbach ist dann der Bentley?
Mw E. schrieb: > Beim JLink bekommt man was ordentliches, bei crapple nur Hipsterkram ;) Ja, das ist auch wieder wahr. Der Vergleich mit Mercedes passt eher. > Währenddessen man beim STlink einschläft beim durchsteppen und 10 > Variablen angucken geht das mit dem JLink ratzfatz. Dann hast du Debug Wire mit dem Atmel Dragon noch nicht erlebt. Da schläft man wirklich ein.
Mw E. schrieb: > Beim JLink bekommt man was ordentliches, bei crapple nur Hipsterkram ;) Mein MacBook, mit dem ich auch gerade den Beitrag schreibe, ist mein einziger Computer und über zehn Jahre alt. Zwei Laptops eines hochpreisigen Herstellers, die sich Freunde zur etwa gleichen Zeit gekauft haben, waren nach sechs Monaten kaputt. Mw E. schrieb: > Der JLink Edu für seine 60€ ist sehr zu empfehlen. Darum geht es mir. Das scheint mir am sinnvollsten zu sein.
Mw E. schrieb: > Nunja JLinks mit Apple vergleichen. > Beim JLink bekommt man was ordentliches, bei crapple nur Hipsterkram ;) In Wahrheit ist der JLink Schrott, der Support nur für Premium Kunden da und die Software (zumindest die Linux Version) ist alle 2-3 Releases derart hinüber dass man downgraden muss damit irgendwas geht. Das traurige daran is dass es trotz all dem immer noch einer der besten Adapter is...
@Dussel vor 10 Jahren waren die Dinger ja noch halbwegs braucbar. Aber die heutigen Crapbooks mit der fail by Design Tastatur? eher nicht. Mein billig Stinkpad SL510 von 2010 lebt aber auch noch ;)
Dussel schrieb: > Mein MacBook, mit dem ich auch gerade den Beitrag schreibe, ist mein > einziger Computer und über zehn Jahre alt. Ich kenne das Modell, war damals auch scharf drauf, hatte aber nicht das nötige Geld. Sei froh drum, denn du hast eines der letzten guten MacBooks vorliegen, mit dem man noch ernsthaft arbeiten kann. Bei einem Arbeitskollegen (mit einem Desktop Modell) funktionierte die maximale RAM Aufrüstung nicht. Er wollte sein Geld zurück, weil er das so brauchte. Hat Apple verweigert, da er das Gerät mit seinen Entwicklungs Tools missbraucht habe. Dafür sei es nicht gebaut. So viel zum "Pro" Suffix.
Stefanus F. schrieb: > Vielleicht werden die von Ingenieuren mit 20 Jahren > Berufserfahrung in > Handarbeit gebaut, persönlich gewidmet und von einem speziellen > Kurierdienst der Firma gebracht. > > Wer Programmieradapter für hunderte Euros kauft, der hinterfragt solche > Details nicht. Apple Kunden tun das auch nicht. Kann ich nicht zustimmen! Die ST-Link sind nicht schlecht, und auch schnell, aber sonderlich stabil waren sie bei mir nie. Als Bastler kann man damit arbeiten (sehr ordentlich sogar). Also bitte nicht falsch verstehen, die billigen (echten) Debugger sind eine der großen Stärken der STM32-Serie. Aber die J-Link sind erstens viel stabiler und zweitens schneller. Wir haben eine Zeitlang ST-Links in Testadapter verbaut (zum programmieren in der Produktion), und nach diversesn Problemen auf ST-Link umgestellt. Seit dem keine Probleme mehr. Außerdem können sie noch einiges mehr, wie tracen, und nicht nur STM32 sondern auch die anderen ARMs, die dicken PICs, FPGAs und dergleichen. Man bekommt schon etwas für sein Geld, und im professionellen Bereich sind die par hundert € oder was auch immer nicht so viel Geld. Bei den erwähnten Testadaptern wäre der J-Link viel billiger gekommen ;-) Der Vergleich mit Apple hinkt also. Einigen wir uns auf Mercedes Sprinter (J-Link) versus Fiat-500 mit Anhänger (ST-Link) versus Leiterwagen mit sechseckigen Rädern (AVR und PIC-programmer ohne Debugfunktion).
dingens schrieb: > Aber die J-Link sind erstens viel stabiler und zweitens schneller. Wir > haben eine Zeitlang ST-Links in Testadapter verbaut (zum programmieren > in der Produktion), und nach diversesn Problemen auf ST-Link umgestellt. > Seit dem keine Probleme mehr. Bah. Natürlich muss es heißen: "nach diversesen Problemen auf J-Link umgestellt." Leider kann man als Gast nicht korrigieren...
Da meine Frage ja beantwortet ist, kann man ja auch mal abschweifen. dingens schrieb: > versus Leiterwagen mit sechseckigen Rädern > (AVR und PIC-programmer ohne Debugfunktion). Dem stimme ich nicht zu. Sechseckige Räder sind ziemlich unbrauchbar, die Programmiergeräte aber ziemlich brauchbar. Sie tun, was sie sollen. Wenn, dann würde ich sie mit Handwagen vergleichen. Keine besondere Funktionalität, aber sie transportieren kleine Lasten.
Dussel schrieb: > Dem stimme ich nicht zu. Sechseckige Räder sind ziemlich unbrauchbar, > die Programmiergeräte aber ziemlich brauchbar. Sie tun, was sie sollen. > Wenn, dann würde ich sie mit Handwagen vergleichen. Keine besondere > Funktionalität, aber sie transportieren kleine Lasten. Mit einem reinen Programmer arbeiten hat wirklich etwas davon, einen Leiterwagen mit sechseckigen Rädern zu ziehen. Fehler suchen und Programme ordentlich testen ohne Debugfunktion ist furchbar holprig und zäh, und wenig produktiv. Aus meinser Sicht natürlich. Andere mögen das anders sehen. Aber wenn ich unsere Firmwerker frage, ist die Meinung ziemlich eindeutig (die arbeiten übrigens auch teils noch mit ATMEGAS...).
Die STM32G071 Serie hat auch bei 64 Pins nur ein VSS/VDD Pinpaar.
dingens schrieb: > Mit einem reinen Programmer arbeiten hat wirklich etwas davon, einen > Leiterwagen mit sechseckigen Rädern zu ziehen. Da kann ich nur nachdrücklich zustimmen. Hier im Forum wird öfters mal erläutert dass echte Männer(tm) keine Debugger brauchen, aber das ist Blödsinn. Man kann zwar auch ohne Debugger arbeiten, aber es wird einfach alles mühsamer und langwieriger. Mit Debugger kann man viele Probleme sehr viel schneller und schmerzloser finden. Im professionellen Umfeld, wo Zeit Geld ist, sollte das absolut Pflicht sein. Aber auch im Hobby-Bereich macht es so viel mehr Spaß. Vertrackte Probleme in komplexeren Programmen mit anspruchsvoller Peripherie (z.B. SDIO, DMA, USB) kann man sonst sehr lange suchen. Das ist einfach verschwendete Lebenszeit. Ob ST-Link oder J-link ist schon eher eine berechtigte Frage, seitdem die ST-Link besser geworden sind. Bei mir haben die nie stabil funktioniert, daher habe ich mir den J-link gegönnt, der macht nie Probleme. Interessant wäre mal ein objektiver Vergleich zu den Lauterbachs...
dingens schrieb: > Mit einem reinen Programmer arbeiten hat wirklich etwas davon, einen > Leiterwagen mit sechseckigen Rädern zu ziehen. Ach ja? Also, dann verrate uns doch mal, was du über das reine Brennen des Chips denn so benötigst. Laß mich raten: Du kannst zuwenig C, benutzt jedoch zuviele Hersteller-Libs und -Tools und mußt anschließend debuggen, um herauszufinden, was von deiner ursprünglichen Programm-Idee tatsächlich im Maschinencode angekommen ist. Gelle? W.S.
Dr. Sommer schrieb: > dingens schrieb: >> Mit einem reinen Programmer arbeiten hat wirklich etwas davon, einen >> Leiterwagen mit sechseckigen Rädern zu ziehen. > > Da kann ich nur nachdrücklich zustimmen. Hier im Forum wird öfters mal > erläutert dass echte Männer(tm) keine Debugger brauchen, aber das ist > Blödsinn. Psst nicht so laut, du hast eben W.S. angelockt.
Dr. Sommer schrieb: > Da kann ich nur nachdrücklich zustimmen. Hier im Forum wird öfters mal > erläutert dass echte Männer(tm) keine Debugger brauchen, aber das ist > Blödsinn. Bei den AVR hatte ich noch nie die Situation, dass ich mir einen Debugger gewünscht hätte. Das hat alles mit dem Simulator funktioniert. Dafür gab es ein Originales AVRIPS mk II für etwa 30€. Mit einem JTAGICE für 300€ hätte ich wahrscheinlich nie mit Mikrocontrollern angefangen. Grundsätzlich zu sagen, dass jemand, der der Meinung ist, dass ein Debugger unnötig ist, falsch liegt, ist falsch.
W.S. schrieb: > Du kannst zuwenig C, benutzt jedoch zuviele Hersteller-Libs und -Tools > und mußt anschließend debuggen, um herauszufinden, was von deiner > ursprünglichen Programm-Idee tatsächlich im Maschinencode angekommen > ist. Gelle? Vielleicht kennt man ja nicht alle undokumentierten Silizium-Bugs. Und die in externen Bibliotheken. Und vielleicht möchte man auch in sinnvoller Zeit fertig werden. Nur weil du keinen Debugger bedienen kannst, muss sich ja nicht jeder einschränken lassen. Mw E. schrieb: > Psst nicht so laut, du hast eben W.S. angelockt. Das kenn ich schon ? Dussel schrieb: > Das hat alles mit dem Simulator funktioniert Es gibt leider für die deutlich komplexeren ARMs keine vollständigen Simulatioren und erst recht keine bezahlbaren.
Bei manchen Prozessoren sind noch zusätzliche Kondensatoren nötig (ausser Entkoppel Cs an VCC). z.B. STM32F411 64 pin benötigt eine 5uF Cap an einem Pin. Da hängt der interne Spannungsregler dran. Ohne den geht nichts.
> Interessant wäre mal ein objektiver Vergleich zu den Lauterbachs... Kein Lauterbach aber ein Blackhawk: max. 50 MHz JTAG-Clock Tracebuffer Targetvoltage von 0.5 V - 5 V u.v.m. Der Aufwand ist nicht unerheblich: Ein 6000er TI DSP mit 2400 MIPS bei 300 MHz internem Clock. Ein zweiter 5510 DSP zur Kommunikation. Ein Altera ACEX zur JTAG-Pod-Anbindung. 32 MB SDRAM Ein SMSC fuers Ethernet (und das ohne bestückte RJ-45 Buchse.) Ein Xilinx-CPLD plus USB-Käfer für USB2 Dagegen nehmen sich die Innereien eines J-Link wirklich wie Spielzeug aus.
schlubbidu schrieb: > max. 50 MHz JTAG-Clock Können die J-Links auch schlubbidu schrieb: > Targetvoltage von 0.5 V - 5 V Die J-Links können 1.2V - 5V... Sollte für vieles reichen. schlubbidu schrieb: > Tracebuffer Hat der J-Trace auch. Danke Live-Übertragung kann der aber unbegrenzt tracen, während der Blackhawk XDS560 anscheinend auf 128MB begrenzt ist. schlubbidu schrieb: > Dagegen nehmen sich die Innereien eines J-Link wirklich > wie Spielzeug aus. Das heißt erstmal gar nix... Durch geschickte Komponenten-Wahl und clevere Programmierung kann man mit wenig Hardware auskommen. Insbesondere die Notwendigkeit mehrerer Prozessoren macht skeptisch; war man nicht dazu in der Lage, die Funktionalitäten durch entsprechendes Multitasking auf einen einzelnen (schnellen) Prozessor zu integrieren? Wie das Innere des J-Trace aussieht weiß ich aber auch nicht, das wird wohl auch mehr als nur ein Cortex-M3 sein wie beim J-Link.
Hallo, nach ATMEL (und Dragon) bin ich seit letztem Jahr mit STM32F030C8T und ST-Link unterwegs: Der selbstgebaute DIL-Adapter auf die billigen Steckboards funktioniert gut, aber der ST-Link benötigt > 3V Spannung am µC. Debuggen mit den Schlaf-Modi ist spannend: Liegt das am ST-Link?
Angehängte Dateien:
-
Untitled.png
370 KB
PS: Besonders interessant ist bei Blackhawk der fette Schreibfehler auf der Startseite; sollte es nicht vielleicht "Peace of mind" heißen?
Dr. Sommer schrieb: > Vielleicht kennt man ja nicht alle undokumentierten Silizium-Bugs. Zur Auffindung solcher Probleme ist ein Debugger tatsächlich nützlich. Der Punkt ist allerdings: das ist ein eher seltenes Problem. Um viele Größenordnungen häufiger schlägt man sich mit Fehlern im Code herum (eigenen oder fremden). Und da ist es oft so, dass der eigentliche Bug hunderttausende oder Millionen Instruktionen vor der Stelle sitzt, an der seine Auswirkungen dann offensichtlich werden. Und um sowas zu finden (also die eigentliche Ursache), ist ein Simulator sehr viel besser geeignet. Denn der bietet die Möglichkeit, die immer gleiche Situation beliebig oft zu wiederholen. So kann man sich sozusagen "rückwärts" zur Wurzel des Übels durchkämpfen. Das ist mit einem Debugger meist nicht oder nur sehr schwer möglich, jedenfalls bei den meisten µC-Anwendungen. > Es gibt leider für die deutlich komplexeren ARMs keine vollständigen > Simulatioren und erst recht keine bezahlbaren. Das erklärt, warum viele Bugs bei ARM-Code niemals wirklich gefixt werden, sondern man statt dessen auf teils sehr seltsame Stellen im Code trifft, die scheinbar keinen Sinn haben. Das sind dann oft workarounds, die die Unfähigkeit der Entwickler umschiffen, das eigentliche Problem zu finden und zu fixen...
c-hater schrieb: > Der Punkt ist allerdings: das ist ein eher seltenes Problem. Schön wärs :) c-hater schrieb: > Und da ist es oft so, dass der eigentliche > Bug hunderttausende oder Millionen Instruktionen vor der Stelle sitzt, > an der seine Auswirkungen dann offensichtlich werden. Ja. Daher ist es z.B. sehr praktisch, im Debugger Watchpoints zu setzen, welche anzeigen, wann (versehentlich/fehlerhaft) auf Daten zugegriffen wird. Für hartnäckigere Fälle gibt es die erwähnten Tracing-Debugger (wie J-Trace). c-hater schrieb: > ist ein Simulator sehr viel > besser geeignet Klar. Wenn's einen gibt der die ganze Peripherie (inkl. Silizium-Bugs) und externe Hardware (z.B. per USB angebundenen PC) mit simuliert. c-hater schrieb: > Das sind dann oft workarounds, > die die Unfähigkeit der Entwickler umschiffen, das eigentliche Problem > zu finden und zu fixen... Es ist halt nicht so leicht festzustellen, wo jetzt in der Bus-Struktur der eine Takt fehlt oder warum jetzt die Daten nicht aus dem Cache übernommen wurden usw. Das zu debuggen ist etwas schwieriger als das beliebte Rätsel warum beim AVR die Baudrate nicht stimmt.
> Insbesondere die Notwendigkeit mehrerer Prozessoren macht skeptisch; war > man nicht dazu in der Lage, die Funktionalitäten durch entsprechendes > Multitasking auf einen einzelnen (schnellen) Prozessor zu integrieren? Insbesondere das Fehlen weiterer Prozessoren im J-Link macht skeptisch, muss sich wirklich ein Prozessor um alles kümmern? Der zweite DSP (5510A) ist ohnehin eher aus preisgünstigen Riege. Warum soll man Topperfomance mit (nebensächlichen) Funktionalitäten stören wollen. Sowas könnte nur von einem BWLer kommen.
schlubbidu schrieb: > Insbesondere das Fehlen weiterer Prozessoren im J-Link macht skeptisch, > muss sich wirklich ein Prozessor um alles kümmern? Warum nicht? Hohe Systemintegration macht's billiger. Auf PCs hat auch lange Zeit ein einzelner Prozessor alles gemacht. Es entfällt der Aufwand für das Kommunikationsprotokoll zwischen den Prozessoren; ein leistungsfähiger Prozessor benötigt weniger Energie und Platinenplatz als mehrere einzelne. Die Aufteilung auf mehrere Prozessoren macht erst Sinn, wenn die Leistung eines Kerns kaum noch gesteigert werden kann (Moores Gesetz usw.). Davor kommt erst noch der Schritt auf Mehrkern-Prozessoren. schlubbidu schrieb: > Warum soll man Topperfomance mit (nebensächlichen) Funktionalitäten > stören wollen. Sowas könnte nur von einem BWLer kommen. Hä? Ist einer der Prozessoren zu "schade" für langweilige Tätigkeiten?
> Hä? Ist einer der Prozessoren zu "schade" für langweilige Tätigkeiten?
Man wird keinen 2400 MIPS-Boliden zum Spass verbauen.
Der wird sein Tun haben.
Auch wenn das vielleicht nicht in dein Informatikerhirn passt.
Ein M3 oder M4 wie im J-Link ist gegen einen 6202 wie ein
Hilfsmotor am Fahrrad.
schlubbidu schrieb: > Man wird keinen 2400 MIPS-Boliden zum Spass verbauen. > Der wird sein Tun haben. Und der ist wirklich zu 100% ausgelastet und es war kein bisschen Rechenleistung mehr übrig für die anderen Aufgaben? schlubbidu schrieb: > Auch wenn das vielleicht nicht in dein Informatikerhirn passt. Als Embedded-Informatiker hab ich natürlich keine Ahnung von Prozessoren. Du bist vermutlich als E-Techniker der große Experte?
> Auf PCs hat auch lange Zeit ein einzelner Prozessor alles gemacht.
Das ist so schlicht gesehen falsch.
Das ging schon beim Tastaturkontroller los, der später in
Super-IO-Käfern seine Reinkarnation fand.
Jede halbwegs leistungsfähige Peripheriekarte war und ist "aktiv".
D.h. eine eigene CPU werkelt dort.
Und in modernen PCs sind auch m.W. neben der eigentlichen CPU
noch für Managementzwecke weitere CPUs am wirken.
Du hast keine Ahnung!
> Du bist vermutlich als E-Techniker der große Experte?
Selbstverständlich!
schlubbidu schrieb: > Selbstverständlich! Hehe... Scheint mir ein Fall von Kompetenzüberschätzung zu sein. Wie viel lernt man denn im ET-Studium über Multithreading und Software-Integration?
> im ET-Studium über Multithreading und Software-Integration?
In meinem Studium habe ich Lochkarten für den Fortrancompiler gestanzt.
Fortran I um genau zu sein.
Das hat das Denken aber nicht behindert.
Daran scheint es den Informatikern zu mangeln.
Z.B. einem leistungsfähigen Hauptprozessor einen IO-Prozessor an
die Seite zu stellen, der sich mit besch.ssenen von Informatikern
ausgedachten Protokollen wie USB herumschlägt.
schlubbidu schrieb: > Z.B. einem leistungsfähigen Hauptprozessor einen IO-Prozessor an > die Seite zu stellen, der sich mit besch.ssenen von Informatikern > ausgedachten Protokollen wie USB herumschlägt. Au weia. Diskussion beendet.
Besser iss das wohl. Den Informatikern mangelt es halt an Diskussionskultur.
schlubbidu schrieb: > Z.B. einem leistungsfähigen Hauptprozessor einen IO-Prozessor an > die Seite zu stellen, der sich mit besch.ssenen von Informatikern > ausgedachten Protokollen wie USB herumschlägt. Das haben sich sicher nicht Informatiker alleine ausgedacht (die können zwar im Allgemeinen nicht wirklich programmieren, aber immerhin sehr logisch denken). Da waren mit Sicherheit auch Juristen und Marketingstrategen beteiligt, schon beim physical layer von USB1.0...
> Das haben sich sicher nicht Informatiker alleine ausgedacht
Ja, dann würde es nie fertig.
Andreas schrieb: > Debuggen mit den Schlaf-Modi ist spannend: Liegt das am ST-Link? Nein, am ARM Kern.
Stefanus F. schrieb: >> Debuggen mit den Schlaf-Modi ist spannend: Liegt das am ST-Link? > > Nein, am ARM Kern. Danke. Was ich mit meinem Post schreiben wollte: Die HW kann ich genauso einfach wie bei einem AVR-µC aufbauen, aber insb. nach dem Stromsparmodus habe ich als STM32-Beginner mit der richtigen Reaktivierung der Module gekämpft: Da konnte ich (ohne Umwege) im Debugger sehen, welche Register nicht / falsch gesetzt waren, um dann in den HAL-Bibliotheken usw. nach den passenden Macros zu suchen bzw. die richtige Verwendung zu verstehen (z.B. HAL_ADC_DeInit() must be called before HAL_ADC_Init()). Das war zwar bei AVR einfacher, habe ich dann allerdings bei jedem Prozessorwechsel von Hand angepasst.
Andreas schrieb: > Die HW kann ich genauso einfach wie bei einem AVR-µC aufbauen, aber > insb. nach dem Stromsparmodus habe ich als STM32-Beginner mit der > richtigen Reaktivierung der Module gekämpft: Da konnte ich (ohne Umwege) > im Debugger sehen, welche Register nicht / falsch gesetzt waren, um dann > in den HAL-Bibliotheken usw. nach den passenden Macros zu suchen bzw. > die richtige Verwendung zu verstehen (z.B. HAL_ADC_DeInit() must be > called before HAL_ADC_Init()). > Das war zwar bei AVR einfacher, habe ich dann allerdings bei jedem > Prozessorwechsel von Hand angepasst. Nachdem man das dann verstanden hat, hinterfragt man den Nutzen der HAL.
Den STM32 kannste auch wie den AVR ohne HAL, nur mit Registerklimpern, proggen. Danach verstehste auch die Hardware und rätselst nicht welche Hardware Obvuscation Layer Funktion jetzt welches enum braucht mits das macht was du willst. (ein echter HAL ist das nicht was da von ST kommt) @schlubbidu Du gibst hier echt ne Witzfigur ab. (mit deinem "Inhalt" muss man sich garnicht erst beschäftigen)
> Hardware Obvuscation Layer
Kauf dir erstmal eine Rechtschreibhilfe.
Mw E. schrieb: > @schlubbidu > Du gibst hier echt ne Witzfigur ab. > (mit deinem "Inhalt" muss man sich garnicht erst beschäftigen) Typischer Troll. Solange er stört, beschäftigt sich jemand mit ihm.
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.