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.
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?
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...).
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?
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!
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.
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...
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)
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.
