Forum: Mikrocontroller und Digitale Elektronik Grundbeschaltung ARM (z.B. STM) im Vergleich zu AVR


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Teddy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lies doch einfach das Datenblatt.

von Alex D. (daum)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Flip B. (frickelfreak)


Bewertung
0 lesenswert
nicht lesenswert
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

von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Und der Analog VDD/VSS muss immer angeschlossen werden sonst läuft die 
interne Taktdomäne nicht.
(RC Schwinger, PLL, etc.)

von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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

von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
-1 lesenswert
nicht lesenswert
@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 ;)

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von dingens (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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).

von dingens (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von dingens (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...).

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
Die STM32G071 Serie hat auch bei 64 Pins nur ein VSS/VDD Pinpaar.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von W.S. (Gast)


Bewertung
-8 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dr. Sommer (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Harry L. (mysth)


Bewertung
-1 lesenswert
nicht lesenswert

von Martin B. (ratazong)


Bewertung
0 lesenswert
nicht lesenswert
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.

von schlubbidu (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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.

von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Andreas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Dr. Sommer (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
PS: Besonders interessant ist bei Blackhawk der fette Schreibfehler auf 
der Startseite; sollte es nicht vielleicht "Peace of mind" heißen?

von c-hater (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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...

von Dr. Sommer (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von schlubbidu (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
> 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.

von Dr. Sommer (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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?

von schlubbidu (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
> 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.

von Dr. Sommer (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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?

von schlubbidu (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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!

von schlubbidu (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
> Du bist vermutlich als E-Techniker der große Experte?

Selbstverständlich!

von Dr. Sommer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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?

von schlubbidu (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
> 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.

von Dr. Sommer (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von schlubbidu (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Besser iss das wohl.

Den Informatikern mangelt es halt an Diskussionskultur.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von schlubbidu (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
> Das haben sich sicher nicht Informatiker alleine ausgedacht

Ja, dann würde es nie fertig.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:
> Debuggen mit den Schlaf-Modi ist spannend: Liegt das am ST-Link?

Nein, am ARM Kern.

von Andreas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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)

von schlubbidu (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
> Hardware Obvuscation Layer

Kauf dir erstmal eine Rechtschreibhilfe.

von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.