Forum: Mikrocontroller und Digitale Elektronik Einstieg ARM


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 ARM Einsteiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nachdem ich mich schon seit einiger Zeit mit AVRs beschäftigte, möchte 
ich mich auf privater Basis in ARM Controller einarbeiten.

Im Gegensatz zu den AVRs bin ich aber noch komplett überfordert mit den 
Möglichkeiten. Daher die konkrete Fragen:

1) Was ist ein preiswertes Einsteiger-Evaluation Board?
Ich habe an das https://www.olimex.com/Products/ARM/Atmel/SAM7-EX256/ 
gedacht oder https://www.olimex.com/Products/ARM/Atmel/SAM3-P256/


2) allerdings ist mir nicht klar, welches ICE ich dann dazu benötige. 
Olimex hat ja den 
https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-COOCOX/, welcher 
angeblich mit dem CooCox CoIDE harmoniert...

3) Ein IDE mit Debuggingmöglichkeit (Breakpoints, etc,...) möchte ich 
schon verwenden, ich habe eben dieses CooCox als Freeware gesehen. Dann 
gäbe es ja auch das ATMEL Studio, welches aber wiederum nicht alle SAM 
Modelle unterstützt...

Ich hätte am liebsten etwas, das zusammenpasst; ungern würde ich mir ein 
Board kaufen, zu dem ich dann keinen einwandfrei funktionierenden ICE 
finde...

Also:

* preisgünstig **lach **
* IDE + Toolchain
* es soll funktionieren, und nicht frustrieren (insbesondere der ICE)

Danke !

von Linüx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ARM + günstig = STM32F1DISCOVERY oder STM32F3DISCOVERY oder 
STM32F4DISCOVERY alles Starterboards incl. Debugger etc. an Bord (ST 
Link V2). Kostenlose Umgebung CooCox mit allem Pipapo was man braucht.

ARM Einsteiger schrieb im Beitrag #3151466:
> * es soll funktionieren, und nicht frustrieren (insbesondere der ICE)

Dann darfst du dir ARM nicht nehmen. AVR ist ein Witz dagegen. Sind halt 
32bit und da ist alles einen ordentlichen Haken komplexer. Dafür hast 
halt Möglichkeiten und Power ohne Ende. Wie gesagt kein Vergleich mit 
8bit aber einfach nur geil. Nach ner Woche bist gut drin. Wenn du mit 
AVR Probleme hast dann würde ich das aber eher vergessen.

AVR 8bit = kleines Einmaleins
ARM 32bit Cortex M3,M4 = rechnen mit komplexen Zahlen

von ARM Einsteiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Linüx schrieb:
> AVR ist ein Witz dagegen.

Weiß ich ;-)

Jedoch will ich es lernen, da ARM Controller in Firmen sehr verbreitet 
sind.
Mit den AVRs hab ich ja übrigens kein (echtes) Problem.

Mit "es soll funktionieren und nicht frustrieren" meinte ich weniger die 
Lernhürde, sondern die Qualität der Entwicklungstools, inclusive ICE. 
Wenn ich nicht zuverlässig debuggen kann, hat es keinen Sinn. Mit printf 
Ausgaben wird man bei dem Kaliber nicht weit kommen...

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
ARM Einsteiger schrieb im Beitrag #3151466:
> Nachdem ich mich schon seit einiger Zeit mit AVRs beschäftigte, möchte
> ich mich auf privater Basis in ARM Controller einarbeiten.
>
> Im Gegensatz zu den AVRs bin ich aber noch komplett überfordert mit den
> Möglichkeiten. Daher die konkrete Fragen:
>
> 1) Was ist ein preiswertes Einsteiger-Evaluation Board?
> Ich habe an das https://www.olimex.com/Products/ARM/Atmel/SAM7-EX256/
> gedacht oder https://www.olimex.com/Products/ARM/Atmel/SAM3-P256/

ARM ist nicht gleich ARM. Die alten ARM7-Teile solltest Du da lassen, wo 
sie sind: beim Händler. Die neueren Cortex M0/M3/M4 sind 
leistungsfähiger und gleichzeitig einfacher zu handhaben.

Die Debugschnittstelle ist bei allen Cortex M standardisiert. Diese 
haben zum einen das althergebrachte JTAG sowie das neuere SWD, das 
deutlich weniger Pins braucht. Nimm eine Debug Probe, die auch SWD kann, 
auch wenn das dann etwas teurer wird. (zB Segger J-Link)

Und: Du darfst nicht davon ausgehen, dass Du Software für Controller A 
so problemlos auf Controller B portiert bekommst. Der CPU-Kern ist immer 
der gleiche, der Interrupt-Controller auch, aber der gesamte Rest an 
Peripherie ist von Hersteller zu Hersteller völlig anders. Die 
Unterschiede sind ähnlich groß wie zwischen AVR und PIC. So viel zum 
Thema Herstellerneutralität.

> * preisgünstig **lach **
> * IDE + Toolchain
> * es soll funktionieren, und nicht frustrieren (insbesondere der ICE)

Ei ei ei, das sind ja schon drei Wünsche auf einmal. Keil MDK plus 
ULINK2 plus irgendein Keil Demoboard funktioniert garantiert, und der 
Keil/ARM Compiler erzeugt zweifelsohne hervorragenden Code (Keil gehört 
zu ARM), aber preisgünstig geht anders.

fchk

von Faust (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Linüx schrieb:
> AVR 8bit = kleines Einmaleins
> ARM 32bit Cortex M3,M4 = rechnen mit komplexen Zahlen

Uaaah, "rechnen mit komplexen Zahlen" - meine Güte, da bekomme ich aber 
Angst, dass ist ja sooooooooo schwer!

Echt Kollege, wenn man im vierten Semester mal Funktionentheorie hatte, 
dann ist das "rechnen mit komplexen Zahlen" das kleine Einmaleins - 
also, wie schon Einstein feststellte: "alles relativ".


Auch ARM ist kein Buch mit 7 Siegeln.

von ARM Einsteiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Linüx schrieb:
> ARM + günstig = STM32F1DISCOVERY oder STM32F3DISCOVERY oder
> STM32F4DISCOVERY alles Starterboards incl. Debugger etc. an Bord (ST
> Link V2). Kostenlose Umgebung CooCox mit allem Pipapo was man braucht.

und wo kann man das beziehen?
Gibt es andere Erfahrungsträger mit diesen Boards?

von ARM Einsteiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Oder noch andere "Komplettlösungen"...?

von Christoph S. (mixer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
ARM Einsteiger schrieb im Beitrag #3151513:
> Linüx schrieb:
>> ARM + günstig = STM32F1DISCOVERY oder STM32F3DISCOVERY oder
>> STM32F4DISCOVERY alles Starterboards incl. Debugger etc. an Bord (ST
>> Link V2). Kostenlose Umgebung CooCox mit allem Pipapo was man braucht.
>
> und wo kann man das beziehen?
> Gibt es andere Erfahrungsträger mit diesen Boards?

Embedded World, kaeuflich z.B. bei Watterott
Wenn du Erfahrungstraeger suchst bemueh doch mal die Forumssuche. 
Teilweise gibt es auch hilfreiche Artikel in der Artikelsammlung.

Zu erwaehnen waeren auch noch die LPCXpresso Boards - sind aehnlich nur 
hald mit NXP Controllern.

Gruss

von Philipp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe das STM32VL Discovery Board mit der Attolic True Studio IDE 
Freeware (begrenzt auf 32 Byte Code) im Einsatz und bin sehr zufrieden 
damit.
Beziehen kann man die Boards bei Franell, RS, direkt bei ST oder auf 
Messen.
Viel Spaß beim Einstieg in ARM.
Es lohnt sich auf jedenfall und macht richtig viel Spaß

von holger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Ich habe das STM32VL Discovery Board mit der Attolic True Studio IDE
>Freeware (begrenzt auf 32 Byte Code) im Einsatz und bin sehr zufrieden
>damit.

Das sollte wohl 32kB Code heissen;)
Und was ist wenn du mehr als 32kB Code hast?
IDE wechseln oder den teuren Kram kaufen?
Im Prinzip also Zeitverschwendung.

Ich debugge immer noch bevorzugt über printf.
Bei Langzeittests bleibt auch kaum was anderes übrig.
Oder wenn eine USB Verbindung im Spiel ist, dann
meldet sich das Teil am USB ab wenn man an einem
Breakpoint anhält. Der Host bekommt dann ja auch keine
Antwort mehr. Debugger werden oft hoffnungslos überschätzt.
Es gibt Dinge die man per JTAG nicht debuggen kann weil
sonst die externe Hardware abdreht.

von ARM Einsteiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb im Beitrag #3151556:
> Bloß drauf warten, daß die gebratenen
> Tauben dir in den offenen Mund fliegen?

Sehr hilfreich sind solche Aussagen nicht. Wie bist du denn 
eingestiegen? Oder hast du das ARM Wissen mit der Muttermilch 
aufgesogen. Nicht bös sein, aber du bist schon sehr "überheblich", mit 
dem was du da schreibst.

Ich mochte eine vernünftige und bereits erprobte Lösung im Zusammenspiel 
von Board und Programmier/Debug Adapter und nicht erst 500€ ausgeben, 
bevor ich draufkomme dass es nicht funktioniert.

von Geert H. (geerth)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe in der Urzeit angefangen mit AVR + STK200. Mit Studio-Assembler 
und und heute mit Bascom.
Meine erste ARM Erfahrungen habe ich gemacht mit MbedLPC1768, es ist bis 
heute die beste Mbed. Das schwerste für mich ist C/C++ zu lernen. Mbed 
(Merkmal ist der Online-Compiler) hat viele sofort laufende Programme. 
Mann kann auch ganz einfach von der Online-Compiler aus Programme 
exportieren nach Keil (zur nutzung der CMSIS-debugger) oder Codered.
Du brauchst eigentlich kein weitere Hardware, ausser vielleicht ein 
Steckbrett um mit LCD oder anderes Spielzeug zu experimentieren.

Ich kann MbedLPC1768 empfehlen als ARM-lernsystem für AVR-erfahrene 
Leute.
Das Modul ist nicht gerade billig, aber komplett, kompakt und 
ausgereift. Kommt mit viele Softwarebeispiele, und es gibt eine 
hilfreiche Forum/Community.
(Es gibt auch noch andere billige Mbed Module.)

Und die Software/Programmierumgebung funktioniert einfach!

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Das sollte wohl 32kB Code heissen;)
> Und was ist wenn du mehr als 32kB Code hast?
> IDE wechseln oder den teuren Kram kaufen?

Welche uC SW braucht mehr als 32k? Und Daten oder Bilder kann man direkt 
flashen. Allerdings hatte ich kürzlich tatsächlich eine LCD-Touch-Demo 
für LPC1788, da war alles im main mit so 60k, sowas trenne ich aber 
schon aus Prinzip in User Code und Library.

von Fritz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Debugger werden oft hoffnungslos überschätzt.
> Es gibt Dinge die man per JTAG nicht debuggen kann weil
> sonst die externe Hardware abdreht.

Es könnte natürlich auch sein, dass du Debugger hoffnungslos 
unterschätzt!

Ich arbeite mit einem STM32F4..discovery board und der IDE CrossStudio 
für Arm von Rowley. Die gibt es relativ preisgünstig für Hobbyisten. 
Gibt dafür zwar nicht so viele fertige Beispielprojekte, aber wenn man 
die Starthürden überwunden hat, ist die IDE sehr komfortabel.
CooCox verwende ich manchmal alternativ dazu, ist nicht ganz so 
komfortabel wie CrossStudio, aber dafür kostenlos und funktioniert auch.

von Joachim .. (joachim_01)


Bewertung
0 lesenswert
nicht lesenswert
Ich schildere mal kurz meine subjektive Sicht:
Ich war in ner ähnliche Situation wie du, mit AVR+PIC hab ich jeweils ne 
handvoll Projekte hinbekommen, hatte aber Null Ahnung von ARM. Ich hab 
nen Arduino DUE (SAM3X8E mit 84MHz, Cortex M3, Watterott::46EUR) gekauft 
- DUE deshalb, weil es der gleiche uC wie auf den Atmel-Eval-Boards ist. 
Für Routinekram wie Upload hab ich dann noch AVR-Studio angepasst.
Wenn man nicht gerade wildes Zeug wie Bilderkennung + Kalman-Filter 
programmiert, liegt das Prob mMn nicht in der Komplexität des 
Rechenkerns M3 (das macht nach wie vor alles gcc, g++ or whatever) 
sondern fast Ausschließlich in der Anpassung des Codes an die knackige 
Peripherie. Die Timer-Module zB. sind erheblich komplexer als 'früher', 
und auch schon ein sauberes "Hello World" mit Timer-Isr anstatt 
NOP-Einschieben bei 84MHz erfordert viel Nachlesen. In der Atmel-ASF hat 
es viele gute Code-Beispiele die zT. sofort oder mit ein bisschen 
Anpassung laufen.

Und printf ist jetzt auch nicht soooo schlimm. Als Anfänger zwicken dich 
da ganz andere Dinge. Im grunde genommen hat JTag nur einen Vorteil: 
Zeitersparnis. Gemessen am Gesamt-Zeitaufwand für ein Projekt ist er 
aber gering.

Und es stimmt was ein Vorredner schrieb: Diese dicken Biester machen 
wirklich einen Heidenspaß.

von Ralph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Oder sieh dir mal die TI Teile an,

http://www.ti.com/tool/ek-tm4c123gxl

Das ist jetzt das aktuellste, und auch alles dabei was man brauch.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
Der vermutlich preiswerteste Einstieg ist immer noch das 
STM32F4Discovery Board. Ich hab mir 2 von den STM32VLDiscovery Boards 
mit dem F1 zugelegt, der F4 ist aber dagegen viel leistungsfähiger und 
kostet genauso wenig. Ausserdem hat das Board mit den Digital Audio 
Komponenten eine spassige Peripherie dabei, die mal interessant werden 
kann.

Ich verwende im Moment die letzte unbegrenzte Version von Atollic 
(mittlerweile ist die ja auch begrenzt oder teuer), werde aber bald mal 
CooCox probieren, angeblich ist dort alles mittlerweile ohne Haare 
raufen zu installieren.
Lediglich die Dokumentation von STM zu den MC ist unübersichtlich und 
man muss die meisten Abschnitte über Timer usw. mindestens dreimal 
lesen.

Du brauchst sonst nur ST-Link V2 von STM zum flashen des Boards und 
kannst sofort loslegen.

von Markus M. (mmvisual)


Bewertung
0 lesenswert
nicht lesenswert
@ARM Einsteiger

Lese am besten den Artikel: STM32
Da steht über alles mögliche drin, auch Bezugsquellen und 
Entwicklungsumgebungen und Tipps für Umsteiger.

STM32F4DISCOVERY ist auch meine Empfehlung. Alles drin und dran und 
kostet nur 12..20 EUR.

Wenn Du später mehr machst und eigene Boards baust, dann empfehle ich 
den J-LINK EDU von Segger als JTAG Adapter (ist einfach verdammt 
schnell). Man kann aber auch den vom Discovery Board mit anderen eigenen 
Boards verwenden.


>Linüx schrieb:
>> AVR ist ein Witz dagegen.
Ja, ja, wer bei einem AVR die Doku nicht liest wird den auch nie 
programmieren können. Somit: wer lesen kann ist klar im Vorteil und der 
STM32 hat nun mal ein paar Seiten mehr. Es gibt jede Menge 
Code-Beispiele von ST und im WWW.
Dass der STM32 jetzt so viel schwerer ist kann ich beim besten willen 
nicht nachvollziehen. Meist gibt es die Lösung mit ein wenig Suchen bei 
Google auf dem Silbertablett serviert.

von ARM Einsteiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus Müller schrieb:
> STM32F4DISCOVERY ist auch meine Empfehlung.

Hab das Ding nun bestellt. 15€ inklusive integriertem ICE ist 
unschlagbar. Ich hoffe es funktioniert wirklich so gut, wie alle sagen.

Danke für die Entscheidungshilfe ;-)

von C3PO (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn du dich für den STM32 entschieden hast hier noch zwei Tipps meiner 
persönlichen Favoriten:

http://diller-technologies.de/stm32.html

und

http://mystm32.de/doku.php


Gruß

von ARM Einsteiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

das ging ja schnell - ich habe das STM32F4 Discovery Board schon am 
Tisch liegen und bereits die CooCox IDE samt ARM-GCC installiert.

Ein Beispielprogramm "blinky" konnte ich bereits erfolgreich übersetzen 
und laden.

Im Gegensatz zur AVR Welt ist mir aber noch nicht so ganz klar, wo man 
sich die C-Umgebung zusammensucht bzw. darin zurechtfindet. Bei AVR war 
es sehr überschaubar und kompakt, jetzt sehe ich den Wald vor lauter 
Bäumen nicht. Daher die Frage:

* wo finde ich die Header Files und Macros, um auf Register zuzugreifen

oder tut man das nicht, sondern

* geht über Standard libraries (zB STM32F40xx/41xx/427x/437x DSP and 
Standard Peripherals Library


Kurz gesagt: wo lerne ich, wie man praktisch programmiert?
Die CoIDE erstellt viel automatisch generierten Code (Handler, etc, 
...), aber wo finde ich das dokumentiert?

Danke!

von ARM Einsteiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich komme zum Schluss, dass die STM Library von ST wohl nur für Leute 
geeignet ist, die auch bei ST arbeiten ...

Ich habe nur mal versucht, zu verstehen, wie die System Clock 
eingestellt wird:

* In der "blinky" Anwendung Beitrag "CooCox CoIDE mit STM32F4-Discovery Board" 
wird auf die Compileroption -DHSE_VALUE verwiesen, und dass das richtig 
eingestellt sein muss. Diese wird aber nirgends verwendet; ändere ich 
den Wert, blinken die LEDS genau so wie vorher. --? wozu gibt es das 
dann??

* Es gibt zwar eine Funktion SetSysClock, die aber unzureichend 
dokumentiert ist. Sicher kann ich nun nachsehen, was da im Detail 
passiert und die Zeilen, wo auf Register geschrieben wird entsprechend 
anpassen. Dann brauche ich aber keine Library, sondern kann gleich alles 
selbst machen. Ich würde mir eine Funktion erwarten, der ich sage, wie 
die Frequenz des externen Oszilators ist, welche Taktfrequenz ich 
letztlich haben möchte, usw. und erwarte mir dann, dass die PLL 
Einstellung richtig vorgenommen wird. So eine Funktion habe ich nicht 
gefunden - oder hab ich etwas übersehen?

* Es kann ja nicht sein, dass man sein ganzes Wissen nur aus unendlich 
vielen Beispielen im Web zusammendröselt; das mag zwar funktionieren, 
ist aber nicht die Vorgehensweise, die ich als Entwickler gewohnt bin. 
So gibt es die gut gemeinte Seite 
http://diller-technologies.de/stm32.html die mir aber nicht wirklich 
weiterhilft, da hier nur Beispiele gezeigt werden, ohne zu sagen, woher 
der utor seinerseits die Infos bekommen hat.

DIE FRAGE:

Wie geht es den anderen? Wie kann ich mich systematisch in die Materie 
einarbeiten, ohne nur mit Beispielen zu arbeiten, die ich mir irgendwo 
zusammensuche? Bitte jetzt nicht sagen "du möchtest alles am goldenen 
Servierteller bekommen", etc, ich bin nur nicht gewillt, eine 
umfangreiche Library ohne jegliche brauchbare Doku hinzumehmen...

von Daniel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Linüx schrieb:
> AVR 8bit = kleines Einmaleins

und was ist mit AVR 32 bit? Die gibt es ja auch. Um zwei Sachen 
miteinander zu vergleichen darf man nur einen Parameter ändern, 
Architektur oder Anzahl der bits (wie nennt man das richtig?)

von Uwe B. (derexponent)


Bewertung
0 lesenswert
nicht lesenswert
Hi ARM Einsteiger,

es ist einfach so, das der ARM um ein vielfaches komplexer ist,
als z.B. ein ATMega128

ich versuche mir zu jedem Thema (bei dir jetzt z.B. der Sysclock)
das Kapitel vom Referenz-Manual durchzulesen (auch wenn es noch so lang 
ist)

das gibt dann zumindest einen Einblick wie, wo, was zusammenhängt
und "warum" die Beispiele von STM so sind, wie sie sind

aber sei beruhigt, du bist nicht der einzigste der
damit probleme hat (mir geht es genauso)

P.S. die CoIDE zeigt dir zu jedem Modul (z.B. GPIO)
vom C-File auf der rechten Seite alle Funktionen an,
die man benutzen kann und da steht meist auch ein Text
dabei welche Parameter die Funktionen erwarten

Gruss Uwe

von ARM Einsteiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Daniel schrieb:
> und was ist mit AVR 32 bit? Die gibt es ja auch.

und was willst du nun damit sagen? Meine Frage bezog sich nicht auf AVR, 
weder auf 8, noch 32 Bit...

von tom57 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
mache Dich doch mal bei IAR schlau.
Die Entwicklungsumgebung ist sehr gut, unterstützt viele verschiedene 
Hersteller von Prozessoren und deren Typen.
Früher hatten die auch mal Eval-Boards mit im Angebot.
Ich arbeite seit Jahren mit damit, hatte früher mit Keil und Realview 
gearbeitet - die aber - meiner Meinung nach - nicht so komfortabel waren 
wie IAR.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uwe B. schrieb:
> es ist einfach so, das der ARM um ein vielfaches komplexer ist, als z.B. ein 
ATMega128

Immer dasselbe ... Auf dem ARM nur mit den Registern eine LED blinken zu 
lassen ist total banal:

int main (void)
{
  FIO1DIR_bit.P1_25 = 1;        // output on pin 1.25

  while(1)
  {
      FIO1PIN_bit.P1_25 ^= 1;   // toggle pin 1.25
      Delay(100000);
  }
  return 0;
}

void Delay(volatile unsigned long i) { while (i!=0) i--; }

Und ja, es ist natürlich empfehlenswert, die CMSIS Library zu nutzen, 
damit der Code nicht portiert werden muss, aber diese Funktionen machen 
auch nichts anderes.

Tutorial für den STM Einstieg z.B.:

http://www.hitex.com/index.php?id=download-insiders-guides

von Uwe B. (derexponent)


Bewertung
0 lesenswert
nicht lesenswert
>ist total banal:

bei einem GPIO zugriff geb ich dir recht
aber ich dachte da eher an die Clock-Logik
oder die Benutzung vom DMA
(wobei es den beim ATMega ja gar nicht gibt)

oder z.B. die Interrupt-Programmierung
(im Vergleich zum ATMega)

mann muss sich wie gesagt erst mal einlesen
ist ja aber im Grunde bei jeder CPU so.

von Patrick W. (pawi777)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

tut mir leid das ich den Thread mal kurz missbrauche, aber kennt jemand 
gute ARM tutorials in Englisch? Am besten solche für STM Controller, das 
höchste der Gefühle wäre natürlich wenn es auf das STM 23F100 Discovery 
abgestimmt wäre. Das vom vorletzten Post sehe ich mir noch an.

Grüsse,

pawi777

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Uwe B. schrieb:
> Interrupt-Programmierung (im Vergleich zum ATMega)

Auch kein Problem: der Compiler definiert ja eine Vektortabelle, da 
steht dann z.B. DCD TMR0_IRQHandler, also mache ich eine Funktion die 
genau so heisst:

void TMR0_IRQHandler(void)
{
  FIO1PIN_bit.P1_25 ^= 1;       // toggle

  T0IR_bit.MR0INT = 1;          // clear pending irq in timer
  NVIC_ClrPend(NVIC_TIMER0);    // clear pending irq in queue
}

Zum Löschen des Interrupts wird hier eine CMSIS Funktion verwendet, weil 
man ansonsten nachsehen müsste, welches Bit zum Timer 0 Interrupt 
gehört, und das dann im CLRPEND Register setzen müsste.

DMA ist auch nicht anders: ich sage ich möchte den einen Speicherbereich 
in den anderen kopiert haben, z.B. USB FIFO ins RAM, dann macht der das, 
und wenn fertig gibt es einen Interrupt: DCD GPDMA_IRQHandler

Die Clock ist tatsächlich ein Kapitel für sich, aber üblicherweise macht 
man es so: entweder reicht der interne RC-Oszillator (meist 12 MHz), 
dann macht man gar nichts. Oder man ruft das CMSIS System_Init() auf, 
dann bekommt man einen für den Chip üblichen Takt (z.B. 96 MHz) und noch 
den USB Takt (48 MHz). Wenn man jetzt eine UART Baudrate braucht, die 
genau damit nicht erreichbar ist, gibt es für jeden Chip ein Excel-Sheet 
zum Download, wo man die Baudrate einträgt, und dann wirft es die ganzen 
PLL Register raus. Die meisten Chips haben mehere PLL, das heisst man 
lässt den CPU und USB Takt sein, und nimmt PLL1 für die krumme Baudrate.

von ARM Einsteiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die guten Tipps!

Ich habe mich bereits etwas eingearbeitet und komme mit dem Coox IDE gut 
zurecht. Es funktioniert wirklich (bis jetzt zumindest...) einwandfrei. 
Die CMSIS Library von ST ist zwar nicht wirklich gut dokumentiert, aber 
zusammen mit dem Reference Manual bleibt eigentlich kein Geheimnis 
offen.

Ich muss zugeben, dass die Ref etwas umfangreicher ausfällt als bei 
8-Bit AVRs, aber es ist auch kein "Buch mit sieben Siegeln": Der 
Cortex-4 kann halt wirklich einiges, was ich mir von einer MCU nicht 
hätte träumen lassen, und das muss natürlich auch alles in die Doku 
rein...

Wenn ich denke, was ich vor ein paar Jahren für einen Olimex Atmega32 + 
JTAG ICE ausgegeben habe, und was mich das Discovery Board gekostet hat 
(23€ incl. Versandkosten), ... Letzteres ist wirklich super, alles 
funktioniert soweit, das Laden und Debuggen funktionierte auf Anhieb und 
einwandfrei, ... all dies konnte ich vom damaligen AVR Studio 4 nicht 
behaupten!

Das Tutorial
http://www.hitex.com/index.php?id=download-insiders-guides
ist übrigens fast der perfekte Einstieg, bevor man die Details im 
Refence Manual nachliest. Danke für den Tip!

von xeliH v. (xileh)


Bewertung
0 lesenswert
nicht lesenswert
N'Abend "Arm Einsteiger"!


Bei Coocox gibt es noch n Add-On namens "CoSmart" damit kann man die 
diversen Funktionen pro Pin einfach zuweisen.
Die Unterstützung für die STM's wurde zwar für April angedroht, aber bis 
jetzt steht's noch aus. (Bei ner komplett kostenlosen IDE will ich aber 
nicht maulen!) Wenn die STM's unterstützt werden, ist eine große Hürde 
genommen, weil CoSmart dann den kompletten Start-Up-Code generiert.

Also immer mal bei CoSmart reinschauen.


Gruss - xileH

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ARM Einsteiger schrieb im Beitrag #3151565:
> Sehr hilfreich sind solche Aussagen nicht. Wie bist du denn
> eingestiegen? Oder hast du das ARM Wissen mit der Muttermilch
> aufgesogen. Nicht bös sein, aber du bist schon sehr "überheblich", mit
> dem was du da schreibst.

Du irrst dich auch hier - und das gleich mehrere Male.

Zunächst denke ich, daß ein paar deutliche Worte zumindest für dich 
sehr hilfreich sind. Wenn ich die letzten Beiträge hier lese, bestätigt 
mich das. Der Ansatz der Coocox-IDE ist ja ganz nett, aber bedenke, daß 
du dort zu einem erheblichen Teil quasi blindlings den Code benutzt, den 
Andere zur Verwendung in genau dieser IDE geschrieben haben. Für mich 
ist das wie das Spielen mit Bauklötzern.

Als nächstes sei dir gesagt, daß man das "ARM-Wissen" durch Lesen und 
selber Machen erwirbt - ganz ohne Muttermilch. Und zu dem "Machen" 
gehört bei uC's eben auch Hardware-Entwicklung, denn ein uC ist (anders 
als ein PC) kein Selbstzweck, sondern ein Teil einer 
Maschine/Gerät/Apparat, kurzum er hat eine Funktion zu erfüllen, die 
außerhalb des uC liegt.

Obendrein bin ich nicht überheblich, sondern nur offen und präzise. 
Aber ich verstehe es schon, daß du dir in deinem zu hoch angesetzten 
Selbsgefühl gekränkt vorkommst. Ich meine das aber bitterernst. Wir 
haben in der Szene schon genug Leute, die sich großartig vorkommen, bloß 
weil sie es gelernt haben, in einer bestimmten IDE die richtigen Knöpfe 
zu drücken. Aber das ist noch nicht das Fachwissen, was den Könner 
ausmacht. Nochmal mein extrem ernster Rat: werde gründlich oder laß es 
bleiben.


ARM Einsteiger schrieb im Beitrag #3156635:
> Wie geht es den anderen? Wie kann ich mich systematisch in die Materie
> einarbeiten, ohne nur mit Beispielen zu arbeiten, die ich mir irgendwo
> zusammensuche? Bitte jetzt nicht sagen "du möchtest alles am goldenen
> Servierteller bekommen", etc, ich bin nur nicht gewillt, eine
> umfangreiche Library ohne jegliche brauchbare Doku hinzumehmen...

Du bist "nicht gewillt".. die Arbeitsergebnisse Anderer 
"hinzunehmen...".
Schon wieder der falsche Grundton deinerseits. Deine Ansprüche sind 
maßlos im Vergleich zu deinem Können. Schreib dir deine Libraries 
selber, dann weißt du, was du hast, welchen Aufwand das macht und was 
man selber können sollte.

Wie es anderen geht?
Nun, am Anfang steht ein Konzept dessen, was man realisieren will, dann 
das Suchen nach dem geeigneten uC, dann das Lesen der Doku dazu, dann 
ggf. ne Revision aller bisherigen Gedanken und Neuanfang, dann ein zum 
Projekt passendes selbstentworfenes Evalboard, mit dem man alle 
wichtigen Details erstmal ausprobiert und dann die eigentliche 
Realisierung.

Sei froh, daß es das Internet gibt, wo man gute und schlechte, passende 
und unpassende Beispiele findet. Lies sie, abstrahiere davon, verstehe 
das Prinzip und schreib dir dann deinen eigenen Code. So herum geht es.

W.S.

von Mystik (Gast)


Bewertung
0 lesenswert
nicht lesenswert
....autsch, die Predigt hat gesessen, aber so ist es 
schlüssig!....Interessiere mich gerade für die selbe Thematik und hoffe 
das sich W.S. Hier im Forum anmeldet,oder immer mal drüber schaut ;-)

von xeliH v. (xileh)


Bewertung
0 lesenswert
nicht lesenswert
@W.S.

Nun entspann Dich doch bitte mal etwas.
"ARM Einsteiger" und auch ich sind in Sachen ARM-Welt eben Anfänger.
Ich persönlich komme z.B. von der Hardware-Seite. Eine 
Horizonterweiterung finde ich sehr erquickend.

Aber es gibt halt verschiedene Wege etwas zu lernen.

Möglichkeit 1:
Absolut alles von Grund auf, Micro-Schritt für Micro-Schritt, durch 
arbeiten.
(Das scheint Dein Weg zu sein.)
- dauert seeeeehr lange (ähnlich Feuersteinklinge zum Akku-Rasierer)
- Erfolgserlebnisse sind dünn gestreut
- Ergebnis aber allumfassend
- Programmieren nur mit Texteditor zwar möglich, aber ... naja

Möglichkeit 2:
Als Quereinsteiger, wie z.B. für mich, ist es einfacher sich mit einer 
funktionierenden Lösung auseinander zusetzen um zu schauen, wie und 
warum es funktioniert. "Was passiert, wenn ich das hier ändere?" Eine 
IDE, die einem die Teils enorm langen Zeichenkollonen schon vorgibt bzw. 
automatisch auf Fehler hinweist ist da sehr hilfreich.
- Zeitaufwand erheblicher geringer und somit auch für Arbeitende und 
Hobbylogen machbar
- Grundfunktion können am lebenden Objekt erkundet werden
- Lernen der Schreibweise, Reihenfolge und Zusammenhänge quasi parallel
- Erfolgserlebnisse stellen sich erheblich schneller ein und damit 
bleibt man am Ball

Möglichkeit 3:
Alles nur zusammenklicken und fluchen + weglegen wenn's nicht klappt.
Diese oberflächlichen "Programmier" entsprechen wohl eher Deinem 
Feindbild.

"ARM Einsteiger" gehört aber definitiv (also in meinen Augen) nicht zu 
der letzten Gruppe. Warum trifft man sich denn hier im Forum? Um 95% 
durch reines Lesen zu lernen und wenn man nix passendes, zuviel oder 
widersprüchliches gefunden hat, dann fragt man halt.
Wenn dann im Namen schon "Einsteiger" enthalten ist, dann sollte doch 
eher Gnade vor Recht gelten. Das Forum ist doch nicht da um Anderen mit 
der großen Gott-Keule die Rübe zu spalten. Wissensaustausch und 
Hilfestellung, darum geht es doch. Wenn einem Anfänger, Um- oder 
Einsteiger jegliche Freude am Experimentieren genommen wird, dann ist 
das Schei... ähm Stuhl!

Oder sehe ich das etwa vollkommen falsch?



Gruss - xileH

von M. N. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
xeliH v2 schrieb:
> Oder sehe ich das etwa vollkommen falsch?

Nein, das siehst Du genau richtig!
Ich hatte mir zum STM32F4-Discovery die IAR Kickstart Version 
angeworfen. Zum einen ist mir IAR ein wenig vertraut, zum anderen ist 
die Transparenz der vorgefertigen Demos akzeptabel. Meine 2. Wahl wäre 
die (gratis) Lösung von Keil gewesen.
Für Coocox usw. bin ich zu schlicht gestrickt.

ARM Einsteiger schrieb im Beitrag #3159446:
> Die CMSIS Library von ST ist zwar nicht wirklich gut dokumentiert, aber
> zusammen mit dem Reference Manual bleibt eigentlich kein Geheimnis
> offen.

Viele Demos nutzen diese CMSIS. Eigene Programmteile würde ich aber 
zunächst ohne diese "Erleichterung" schreiben. Dann weiß man besser, was 
man tatsächlich macht und merkt auch, wie vergurkt teilweise die 
Anordnung der Register und deren Inhalt ist.
Später greift man dann selbst zu CMSIS, da diese einem dieses Gegurke 
etwas transparenter macht :-)

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
xeliH v2 schrieb:
> Aber es gibt halt verschiedene Wege etwas zu lernen.

Nö.
Eigentlich gibt es nur einen Weg, um es zu lernen, nämlich ES zu 
lernen. Alles Andere ist "Nicht-wirklich-gelernt-haben". Aber du meinst 
wahrscheinlich was anderes, nämlich sich irgendeinen Arbeitsstil 
anzugewöhnen. Das ist häufig Geschmackssache, aber nicht immer. Als 
schlechtes Beispiel nenn ich hier mal das Gewese um angeblich neue und 
vieeel bessere Integerdeklarationen in C, die in der reealen Welt dann 
von jedem Compiler wieder in die altbekannten Worte zurückübersetzt 
werden - also alles nur heiße Luft gewesen, man hätte gleich bei char, 
int und long bleiben können - allerdings wäre es dann besser gewesen, 
wenigstens etwas von der jeweiligen zugrunde liegenden Hardware zu 
verstehen. Dann ist das Ganze nämlich plötzlich gar kein Problem mehr.

Selbst bei den für ihre Ähnlichkeit gerühmten ARM-Controllern ist es so, 
daß sich die Produkte verschiedener Hersteller an einigen Stellen doch 
gar sehr unterscheiden, was zumeist den System-Setup betrifft. Genau 
deshalb ist es wirklich nötig, sich das jeweilige Usermanual 
reinzuziehen.

Mit Überfliegen und deinem Vorschlag, sich ein blinkendes "Blinky" 
anzuschauen und dann ein bissel zu modifizieren, ist eigentlich nichts 
gewonnen, denn es fehlt dabei an der Grundlage und auch an der eigenen 
Strategie. Vielleicht würde es dich nerven, wenn ich jetzt von mir und 
meiner Herangehensweise zu schwafeln beginnen würde, also laß ich das.

Aber wenn du schon dir ein funktionables Beispiel anschauen willst, um 
daraus was zu lernen, dann lade dir hier aus der Codesammlung die 
"Lernbetty" herunter, kauf dir für stolze 4 Euro bei Pollin ne 
"Swissbetty"-Fernbedienung und lerne an diesem Beispiel. Dafür ist das 
nämlich gemacht - und die dortige Herangehensweise kann man problemlos 
auch auf Cortex-Controllern anwenden. Einige der dortigen Module kann 
man sogar völlig unverändert auf anderen Architekturen benutzen. Auf 
diese Weise kann man sich mit der Zeit ne Sammlung wirklich 
wiederverwendbarer Codes zulegen - wenn man will. Aber sowas wie den 
Startupcode verstehen und die prinzipiellen Funktionsweisen sich anlesen 
muß man trotzdem, sonst bleibt man im Grunde unwissend.

W.S.

von BesserAVR (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi, bin gerade beim Einstieg in die ARM-Welt eines Beaglebone Black und 
was ich da erlebe macht mich einfach nur fassungslos. Mit dem 
unschuldigen Anliegen einfach nur mal was auf den ersten UART-Port 
auszugeben (und dafür den entsprechenden Pad Mux-Mode setzen zu müssen) 
führt der Weg über ein vor Komplexität nur so strotzendes >4000 seitiges 
(!) AM335x Cortex-A8 (ohne eine Antwort darin zu finden) hin zu einem 
Steinzeit-Linux Betriebssystem, das einen Riesen-Popanz um die paar 
nutzbaren Hardware-Ressourcen aufbaut dass einem die Haare nur so zu 
Berge stehen. Problemloser Hardware-Zugriff: Fehlanzeige. Anbei der 
Versuch eines Programmierers, einen UART-Port zu aktivieren...
Also diese teils abartig aufgeblasene Komplexität sollte der angehende 
ARM-Programmierer kennen, finde ich. Im Zweifelsfall also besser bei AVR 
& Co. bleiben, das lässt noch Zeit für andere Dinge im Leben!

von Balin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi schau dir mal das Kickstarterprojekt 
(http://www.kickstarter.com/projects/digistump/digix-the-ultimate-arduino-compatible-board-with-w) 
an ist zwar quasi nen Arduino Due Clone aber mit:
32-bit ARM Processor (AT91SAM3X8E)
On board 802.11b/g/n WiFi Module (FCC/CE Approved)
On board nRF24L01+ wireless module (removable)

und man kanns ja auch ohne Arduino einfach als normales Board benutzen.

Mfg

Balin

von Armi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ Besser AVR,

also ich bin von AVR auf CortexM3/4 umgestiegen und will niemals wieder 
zurück. Da die Teile genauso günstig oder günstiger wie die ATMEGAS 
sind, benutze ich selbst dann einen ARM wenn es sich um triale Aufgaben 
handelt. Mittlerweile gibts sogar schon Cortexe für unter 1 Euro. Und 
kostenlose IDEs die einem viel Arbeit abnehmen sowiso (ich nutze Coocox)

Vielleicht hast du einfach den falschen Einstieg erwischt. Lass dich 
nicht unterkriegen!

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
BesserAVR schrieb:
> Anbei der
> Versuch eines Programmierers, einen UART-Port zu aktivieren...

Naja, das was du da gepostet hast, hat mit Quellcode nix zu tun. Daß so 
ein Zeugs jedermann abschreckt, kann ich dir nachfühlen.

Allerdings sind die Cortex A8 nicht eben grad ein wirkliches 
Einsteigersystem. In dieser Riege sollte es m.E. schon wenigstens 32 MB 
RAM und ein Windows CE oder sowas ähnliches drauf haben, aber dessen 
programmierung hat wiederum nix mit Mikrocontrollern zu tun, sondern 
eher mit PC-Programmierung, also Visual Studio oder Free Pascal für Arm 
mit Lazarus (falls das schon auf den Cortex A8 portiert ist..)

Zum EInstieg sind allemal die LPC2XXX oder LPC1XXX oder STM32XXX mit 
Taktfrequenzen im Bereich 30..150MHz gut. Dort findest du dann auch die 
Hardwarenähe, nach der du suchst.

Naja, ich komm mir mittlerweile bissel wie ne tibetanische Gebetsmühle 
vor, wenn ich wieder mal hier die billige und einfache Lernbetty hier 
in der Codesammlung erwähne. Als Einstiegsgerät in die ARM-Szene allemal 
geeignet. Ist schon seltsam: Die meisten Leute hier schielen nach 
Cortexen, am liebsten A8 oder höher, aber mit was billigem an der Basis 
anfangen, das ist ihnen zu poplig.

W.S.

von Christian K. (christian_rx7) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich bin auch gerade am lernen.
Habe bereits jahrelange Hobby-Erfahrung mit AVR und will mich nun in die 
Welt der ARM begeben. Genauer gesagt die NXP LPC11Cxx wegen dem 
integrierten CANopen. Nach dem lesen der Hardware Manuals war ich erst 
mal etwas erschlagen und gleichzeitig verblüfft, was die Teile können.
Für die CMSIS hab ich nichts brauchbares im Internet gefunden, somit 
begonnen "Blinky" Zeile für Zeile analysiert und so einen Überblick 
bekommen, was es mit CMSIS aufsich hat. An lebenden Beispielen lernen 
ist nie verkehrt, aber man muss immer versuchen sie zu verstehen.
Ich bin jedenfalls guter Dinge, dass ich die ARM-Geschichte zum Laufen 
bekomme, auch wenn mich der fehlende EEPROM irsinnig stört.

Christian_RX7

von u8glib (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerade am überlegen, ob ich meine Graphic Lib auf ARM portieren 
soll. Meine Erfahrungen mit dem LPC1114 habe ich hier dokumentiert: 
http://code.google.com/p/u8glib/wiki/arm

Ausser dem USB - RS232 Konverter und einem LPC1114 braucht man nicht 
wirklich viel.

Den Hype um die CMSIS kann ich mir nicht erklären: Das gemeinsame Subset 
aller ARMs beschränkt sich scheinbar im wesentlichen auf ein paar 
Interrupts und den System-Takt. Insofern nicht verwunderlich, dass man 
nicht viel darüber lesen kann.

Das ZIP Archiv mit dem spezifischen CMSIS Code, den man für den LPC11xx 
ganz gut gebrauchen kann, ist auf der oben angegebenen Seite verlinkt.

Oliver

von Michael D. (joegi)


Bewertung
0 lesenswert
nicht lesenswert
...versuchs doch mal mit 'nem "Teensy 3.0" (MK20DX128 32 bit ARM 
Cortex-M4 48 MHz; 18€ bei WATTEROTT)! Läßt sich mit 'ner modifizierten 
Arduino-IDE ("Teensyduino") programmieren!
- Einfacher geht's nicht!

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christian Kreuzer schrieb:
> NXP LPC11Cxx wegen dem integrierten CANopen

Hier gibt's eine CANopen Demo damit:

https://www.olimex.com/Products/ARM/NXP/LPC-P11C24/
LPC-P11C24 CAN communication example

von Maler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wieder und wieder: STM32F4 Discovery & Coocox. Kosten 12.-€ 
200Mhz(übertaktet) machen einfach nur Spaß. Wenns wilder wird: Raspberry 
(B Vers. ca 28.-€). Lasst euch von den Atmels (so gerne ich sie mag) 
nicht
die Weitsicht nehmen! Andere Väter haben auch schöne Töchter ;-)

Gutes Gelingen!

von EntwicklerPaul (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Da stimme ich dir zwar zu, aber man darf sich auch nicht von denen 
täuschen lassen.
Das Entwicklungsboard kostet 12 euro, wenn du aber später eigene 
Entwicklungen machen möchtest, dann kostet der einzelne Chip auch 12 
Euro und damit sogar mehr als bei den Atmels ein SAM4S. Bei höheren 
Stückzahlen wird der Unterschied sogar noch extremer, in meinen Augen 
ein Pluspunkt für Atmel.

von BesserAVR (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die gut gemeinten Ratschläge. Den brandneuen Beaglebone Black 
hatte ich gewählt weil ich ein GUI + den HDMI-Ausgang benötige.
Nach meinen jetzigen Erfahrungen hätte ich wohl besser den deutlich 
ausgereifteren Raspberry gewählt (sagt auch die aktuelle c't).
Einsteigen wollte ich erstmal mit Python.

W.S. schrieb:
> Naja, ich komm mir mittlerweile bissel wie ne tibetanische Gebetsmühle
> vor, wenn ich wieder mal hier die billige und einfache Lernbetty hier
> in der Codesammlung erwähne. Als Einstiegsgerät in die ARM-Szene allemal
> geeignet. Ist schon seltsam: Die meisten Leute hier schielen nach
> Cortexen, am liebsten A8 oder höher, aber mit was billigem an der Basis
> anfangen, das ist ihnen zu poplig.

Einfach nur köstlich :-))

von Christian K. (christian_rx7) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Den CANopen Demo hab ich mir schon angesehen, DANKE für den Tip.
Derzeit warte ich noch auf einen CAN USB Adapter damit ich auch was 
sehe.
Ganz so weit bin ich aber auch noch nicht, da ich derzeit mit 
verschiedensten Einstellungen herumspiele und LEDs blinken lasse.

Christian_RX7

von temp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Armi schrieb:
> also ich bin von AVR auf CortexM3/4 umgestiegen und will niemals wieder
> zurück. Da die Teile genauso günstig oder günstiger wie die ATMEGAS
> sind, benutze ich selbst dann einen ARM wenn es sich um triale Aufgaben
> handelt.

Das kann ich so auch bestätigen. Man will nicht mehr zurück. Aber 
manchmal ist die Phereferie in den Cortexen aber weit hinter dem was 
z.b. ein dsPic kann zurück. Versuch mal einen Cortex zu finden mit dem 
man eine 2 Kanal/ 4Ausgänge Phase-Shift PWM ohne Interrupts nutzen zu 
müssen hinbekommt und der nicht mehr als 48 Beine hat. Mit STM32 und 
LPC1x habe ich das ergebnislos versucht. Ein dsPic im 28poligen DIP 
Gehäuse geht dafür gut, und CAN kann er auch. Aber Mplab hasse ich wie 
die Pest und der ICD3 ist auch nicht mit einem JLink zu vergleichen. 
Leider wie immer, alles Gute ist nie beieinander.

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christian Kreuzer schrieb:
> Den CANopen Demo hab ich mir schon angesehen, DANKE für den Tip.
> Derzeit warte ich noch auf einen CAN USB Adapter damit ich auch was
> sehe.

Also in der Demo ist auch der UART damit siehst Du die CAN-Messages im 
Terminal. Natürlich ist ein CAN USB Adapter komfortabler.

https://www.olimex.com/Products/ARM/NXP/LPC-P11C24/
LPC-P11C24 CAN communication example

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.