Ich hoffe ich werde nicht gleich gesteinigt wenn ich die selbe Frage die schon so oft hier gestellt wurde ein weiteres Mal stelle, der Grund weshalb ich es trotzdem tue ist weil es mir schwer fällt die vielen gelesenen Informationen zusammen zu bringen. Mein Ziel ist es irgendwann einmal Ausgänge zu schalten, gesteuert über direkt angeschlossene Schalter und Taster oder via CAN, Sensoren auszulesen, Kommunikation mit anderen CAN Devices und Resultate auf Displays auszugeben. (Einfach gesagt ein Sicherungs, Relais Ersatzmodul das nebenbei auch noch Sensorwerte anzeigt und bei über- oder unterschreiten von Werten entsprechende Aktionen ausführt) Zu diesem Zweck bin ich auf der Suche nach dem passenden ARM Prozessor. Ich suche bewusst einen uC der alle Aufgaben erledigen kann auch wenn dieser für meine ersten Projekte überdimensioniert sein wird. Ich bin der Auffassung dass wenn ich einmal etwas mehr Durchblicke immer noch für einfachere Aufgaben auf kleinere uC's umsteigen kann, aber zum probieren und Tüfteln wäre es einfacher wenn alles zur Verfügung stehen würde was man allenfalls benötigen könnte. Zu guter letzt möchte ich einen uC einsetzen der die Automotiv Anforderungen erfüllt. Letztendlich bin ich bei ARM hängengeblieben weil diese CAN können, die Auswahl erschlägt mich aber ziemlich und die Tatsache dass es diese von unterschiedlichen Herstellern mit unterschiedlichen Entwicklungsumgebungen gibt macht die Auswahl für einen Anfänger nicht leichter. Dazu einige Fragen: - Welche uC Hersteller wären zu empfehlen, in Bezug auf Automotive Tauglichkeit? - Welche Modellreihen entsprechen den Anforderungen, ich meinte ein Cortex M4 würde meine Ansprüche erfüllen, liege ich damit richtig? - Gibt es Hersteller Unabhängige Entwicklungsplattformen mit denen ich alle ARM Prozessoren programieren könnte? - Gibt es einen passenden Prozessor in der Form eines Blue Pill Boards, also quasi eine Steckbrettversion des passenden Prozessor? - Ich tue mich schwer mit dem Einstieg in CAN. was mir Vorschwebt ist die Übertragung von Schalterstellungen und Sensorwerten. Vielleicht liege ich falsch, aber so aufwendig sollte dies ja eigentlich nicht sein. Irgendwie suche ich nach dem falschen und finde den Einstieg in diese Thematik nicht. Über entsprechende Links würde ich mich freuen. Btw. Ich habe gestern das neue Buch von StefanUs gelesen. Ich weiss nicht wie es auf 14 oder 15-jährige wirkt, aber für mich als 48-jährigen mit minimalen Vorkenntnissen war es mit etlichen Aha-Erlebnissen Verbunden. Vieles was ich bis anhin gelesen und nicht richtig Verstanden habe wurde auf einmal viel klarer. Bitte nicht falsch verstehen. Ich möchte das ganze langsam angehen, aber von Anfang an über die Infrastuktur verfügen die es zulässt alle meine Ideen zu Verwirklichen. Gleichzeitig bin ich auch daran meine Werkstatt aufzurüsten. Auch dies ist nicht einfach, da gibt es von diesen Osziloskopen Varianten mit 2, 4 und mehr Kanälen. Schweierig zu entscheiden was man braucht wenn man nur weiss dass man früher oder später eines braucht, aber noch gar nicht richtig weiss für was man es braucht. :-))
- fast jeder Hersteller bietet automotive Varianten an - M4 erfüllt deine Ansprüche eher als ein M3 oder M0, M0 könnte aber auch reichen... - gcc toolchain kann ARM Code erstellen, für fast alle Modelle. Eclipse als IDE drüber. Ist halt nicht so einfach, wie eine vom Hersteller (Controller oder IDE) gelieferte IDE. - direkt Steckbrett-kompatibel gibt es kaum noch. Aber ein LQFP48 auf DIP Adapterboard kost ein paar cent. - ein passender STM32 (z.B.) kann einen CAN Transceiver direkt ansprechen. Mach' einen CAN Monitor, der dir Daten eines vorhandenen CAN ausgibt, dann hast du eine Ahnung wie CAN funktioniert. Da gibt es einige Projekte. - Bis jetzt muss es nicht unbedingt ein Oszilloskop sein. Ein Logikanalyzer z.B. mit Pulseview hilft auch schon. (meist sogar besser, wenn man das Protokoll dekodieren lässt)
Pascal S. schrieb: > Ich tue mich schwer mit dem Einstieg in CAN Der ARM mit dem einfachsten CAN-Controller ist der LPC11C24 zu dem gibt es hier im Forum viele Beiträge. Größter Vorteil: ein ROM mit aufrufbaren CAN-Funktionen. Die kann man erst mal nutzen und später dann eigene machen. Hier ein Board - man braucht natürlich zwei davon. Demo-Software ist dabei: https://www.olimex.com/Products/ARM/NXP/LPC-P11C24/ > Automotive Tauglichkeit Das ist was ganz anderes. Es gibt soweit ich weiss immer noch keine für Automotive zertifizierte Cortex-M sondern nur Cortex-R die dann deutlich größer sind z.B. http://www.ti.com/microcontrollers/c2000-performance-mcus/safety/hercules-tms570/overview.html STM32 ist der aktivste Cortex-M hier im Forum, aber ST setzt in Automotive bislang auf 6502 und Power, die meisten anderen auf 8051 und Tricore. http://www.st.com/en/automotive-microcontrollers.html
Ich habe mit NXP,ST und Microchip ARM Prozessoren gearbeitet. NXP und MC auch als Automitive. NXP ist einfach furchtbar. Unverständliche Doku, komische IDE und absolut totes forum. ST und Microchip funktionieren beide sehr gut. Beide kann man mit einer IDE wie IAR (nicht zu empfehlen) oder Keil programmieren, wobei die Arbeit mit der jeweiligen Hersteller IDE deutlich einfacher und Bequemer ist. Wenn man seinen Code vernünftig kapselt, kann man den Code auch ohne große umschweife zwischen den beiden Platformen austauschen(Wenn man mit den hal-Treibern die Hardware von den IO-Zugriffen trennt). MC und ST haben beide ganz gute Code-Generatoren. Wenn du mit Displays arbeiten willst hängt es stark davon ab was du darstellen willst. Text und einfache Graphiken? Dann reicht ein Cortex M0 Graphiken in Farbe -> Eher M4 Wenn größere Busse wie z.B. bei Fahrzeugen oder CAN FD zum einsatz kommen, brauchts wohl eher einen M7. Wenn man keine Großen Stückzahlen hat, kann man aber auch einfach so einen M7 nehmen, dann muss man sich um Punkte wie RAM und ROM vermutlich nie Gedanken machen.
Automotive ist ein Feld, das noch eher wenig von ARM durchdrungen ist - aufgrund der speziellen Anforderungen und der riesigen Stückzahlen sind dort auch noch recht spezielle Architekturen verbreitet. Und die gibts nicht bei den üblichen Versendern, sondern nur direkt bei den Herstellern direkt. Die Hersteller werden mit Dir auch nicht reden, weil Du keine Umsätze machst. Im Klartext: Du bekommst das Zeug nicht zu kaufen. Nächster Punkt: Bei ARM musst Du Dir über eines im Klaren sein: standardisiert ist nur der eigentliche Prozessorkern und das Debuginterface. Es ist wesentlich einfacher, Code von einem Atmel AVR32 auf einen Atmel ARM zu portieren als von einem STM32 ARM auf einen Atmel ARM. Grund dafür: AVR32 und Atmel ARM haben sehr ähnliche Peripherie, und die ganz andere Prozessorarchitektur merkst Du unter C und C++ erstmal nicht so. ARM-Chips verschiedener Hersteller haben aber komplett andere Peripherie, hier darfst Du von UART über I2C bis hin zu CAN die unteren Schichten einmal komplett neu schreiben. Heißt also: Die Prozessorarchitektur ist für Dich erstmal nicht so wichtig. Meine Empfehlung für den Anfang lautet daher: DSPIC33FJ128GP802-I/SP http://www.microchip.com/wwwproducts/en/en532298 Der ist mit 40 MHz für Deine Zwecke hinreichend schnell, und die 128k Flash und 16k RAM reichen für das, was Du machen willst, auch vollkommen aus. Das Teil gibts im DIL-Gehäuse, ist für Dich also einfach zu verarbeiten. Inbetriebnahme ist völlig unkritisch - 100n jeweils zwischen VDD und VSS und AVDD und AVSS, 10u keramisch zwischen VCAP und GND, und 10k zwischen Reset (MCLR) und VDD. Damit startet das Ding erstmal. Du willst dann später einen 8 oder 16 MHz Quarz anklemmen wollen für CAN und UART, aber für den Anfang ist auch das noch nicht nötig. Es ist alles noch verhältnismäßig einfach für den Einstieg, und es kostet alles nicht viel und ist überall zu bekommen. Ein PICKIT3-Nachbau gibts beim Chinamann für 20€, die ganze Software bei Microchip. Alles aus einer Hand, alles passt zusammen. Wenn Du den durch hast und mehr brauchst, dann kannst Du Dir immer noch einen 200 MHz PIC32MZ holen. Oder irgendwas anderes. Und Deine eigenen Leiterplatten designen. Bis dahin reicht Lochraster für Dich, und Du bekommst erstmal überhaupt was gebacken. fchk
Lothar schrieb: >> Automotive Tauglichkeit > > Das ist was ganz anderes. Es gibt soweit ich weiss immer noch keine für > Automotive zertifizierte Cortex-M sondern nur Cortex-R die dann deutlich > größer sind z.B. Freilich gibts die. z.B. Cortex M0+ Microchip SAM DA1 Cortex M7 SAM V70/71
Alexander B. schrieb: > ein passender STM32 kann einen CAN Transceiver direkt ansprechen Mir ist kein STM32 Automotive Grade bekannt. Und der empfohlenen LPC11C24 ist der einzige der den CAN Transceiver bereits drauf hat. Ist aber auch nicht Automotive Grade. Fabian F. schrieb: > Cortex M7 SAM V70/71 Die waren mir noch nicht bekannt. Allerdings hat der M7 gegenüber dem R5 immer noch Probleme bei der Interrupt-Latenz und Lock-Step. Daher sollte der R5 die bessere Wahl sein. Ist zudem in Automotive weiter verbreitet.
Frank K. schrieb: > Meine Empfehlung für den Anfang lautet daher: > DSPIC33FJ128GP802-I/SP > http://www.microchip.com/wwwproducts/en/en532298 Das kommt mir vor wie vor 15 Jahren als ich RedHat aufsetzen wollte und dann von einem jungen Kollegen eine Debian Floppy hingeworfen bekommen habe. Zugegeben, die Lernkurve war steil ;-)
:
Bearbeitet durch User
Ich würde mich eigentlich gerne ein wenig mit dem DSPIC33 versuchen. So ganz ohne Beispielcode und Einführung wirds aber vermutlich zäh. Meine bisherigen Berührungen mit MCU's beschränken sich auf wenig Arduino Gebastel. Zum flashen geht ein J-Link Edu nicht wenn ich das richtig verstanden habe. Was für ein einfacher Programmer wäre empfehlenswert zum Einsteigen. Am liebsten ein Gerät dass auch ARM und den LPC11C24 unterstützt. Ich möchte mir auch noch ein Blue Pill Board und das obengenannte Board von Olimex anschaffen.
Ich nehme GCC und makefiles anstelle der Hersteller Toolchains. Dann kann ich den Buildprozess in automatische Builds auf Servern auslagern. Bei NXP und TI Prozessoren funktioniert das prima.
Sorry ich verstehe nur Bahnhof. Also, ich installiere GCC auf Windows oder besser Linux, dann schreibe ich den Code darin und dann find ich in GCC die Makefiles um meinen Code für die entsorechende Plattform zu Compilieren? Das wäre sicher ein guter Ansatz so anzufangen, ich würde sicher am ehesten Verstehen was ich tue und warum, aber hier besteht eben noch eine Riesen Wissenslücke und ich weiss grad nicht in welcher Richtung ich mich weiter belesen muss...
Pascal S. schrieb: > Was für ein einfacher Programmer wäre empfehlenswert zum Einsteigen. Am > liebsten ein Gerät dass auch ARM und den LPC11C24 unterstützt. Für das Olimex LPC11C24 würde ein USB-RS232 Kabel oder ein USB-UART Kabel zum Flashen reichen da ROM-Bootloader. Debuggen ist natürlich nicht verkehrt und ein J-Link EDU ist komfortabel. Ein billigerer LPC-Link geht aber auch. Das einzig blöde ist man braucht einen Adapter-Stecker von Micro auf Mini JTAG: http://www.embeddedartists.com/products/lpcxpresso/lpclink2.php http://www.embeddedartists.com/products/acc/acc_jtag_adapter_kit.php
Lothar schrieb: > Ein billigerer LPC-Link geht aber auch. Das einzig blöde > ist man braucht einen Adapter-Stecker von Micro auf Mini JTAG: und dann Kauf ich noch ein Labtool für 99€ dann hab ich meinen Logic Analizer, erstes Oszi und den Signakgenerator auch dabei?
Pascal S. schrieb: > Ich würde mich eigentlich gerne ein wenig mit dem DSPIC33 versuchen. So > ganz ohne Beispielcode und Einführung wirds aber vermutlich zäh. Meine > bisherigen Berührungen mit MCU's beschränken sich auf wenig Arduino > Gebastel. > > Zum flashen geht ein J-Link Edu nicht wenn ich das richtig verstanden > habe. > Was für ein einfacher Programmer wäre empfehlenswert zum Einsteigen. Am > liebsten ein Gerät dass auch ARM und den LPC11C24 unterstützt. > Ich möchte mir auch noch ein Blue Pill Board und das obengenannte Board > von Olimex anschaffen. Für die PICs brauchst Du ein PICKIT3 oder einen China-Nachbau davon. Genau den. Punkt. Kein PICKIT2 nehmen, das ist veraltet und unterstützt die dsPIC33 nicht mehr. Erst recht kein ICD2 - auch das findet man als Nachbau oft noch recht billig. Vorschlag: https://www.amazon.de/WINGONEER-PICKIT3-Simulator-Programmer-Emluator/dp/B012VP72XY/ref=sr_1_2 An den 24€ sollte das nicht scheitern. Die kleinen PICs haben kein JTAG, d.h. für ARM brauchst Du eh was ganz anderes. Aber eines nach dem anderen, sonst verzettelst Du Dich. Für CAN ist das hier die passende AppNote. http://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en539328 Als CAN-Transceiver nimmst Du den MCP2562-E/P. Diese Typennummer ist für die DIL8-Version, d.h. auch das ist problemlos für Dich lötbar. http://www.microchip.com/wwwproducts/en/MCP2562 Der MCP2562 ist explizit für den Betrieb mit 3.3V für die Logikseite (der dsPIC läuft nur mit 3.3V) und 5V für die Busseite (CAN ist ein 5V-Standard!) gedacht, und genau das brauchst Du. fchk
Pascal S. schrieb: > Sorry ich verstehe nur Bahnhof. Also, ich installiere GCC auf Windows > oder besser Linux, dann schreibe ich den Code darin und dann find ich in > GCC die Makefiles um meinen Code für die entsorechende Plattform zu > Compilieren? Ja, Bahnhof. Also: Wenn es denn der GCC sein soll, dann installierst du dir eine passende Distribution davon (z.B. Yagarto) - egal ob nun unter Windows oder Linux. Dann nimmst du deinen Lieblings-Texteditor zur hand und schreibst dir deine Quellfiles (also pascalslieblingscode.c und pascalslieblingscode.h). Dann schreibst du dir: - entweder eine Batchdatei (bzw. Shellscript) - oder ein Makefile wo du alles, was es zu übersetzen gilt, enthalten ist und rufst dieses dann auf, wodurch eben der Compiler, Assembler, Linker usw. gestartet wird, eine Weile vor sich herumrumpelt und schlußendlich eine Datei dabei herauskommt, die du in deinen µC brennen kannst. Also pascalslieblingscode.bin oder pascalslieblingscode.hex oder pascalslieblingscode.s19 oder so ähnlich (bin ist rein binär, hex ist Intel-Hex, s19 ist Motorola-Hex). Dann startest du dein Brennprogramm, schließt deinen µC an und brutzelst deinen Code in den Chip. Ich hatte das ganz Procedere vor Jahren mit der hier auffindbaren Lernbetty mal durchexerziert, sowohl mit dem Keil-Compiler als auch mit dem GCC. Was die Chips betrifft, so haben eigentlich alle LPCxxx und STM32Fxxx einen eingebauten Bootlader im ROM (nicht im Flash), mit welchem du die Dinger per serieller Strippe programmieren kannst. Für die LPC gibt's das FlashMagic Programm und für die STM32F... hab ich vor geraumer Zeit mal ein Brennprogramm hier gepostet. Ich bin durchaus ein Freund dieser Bootlader, denn das ist einfach, billig und zuverlässig - und es bietet für später einen netten seriellen Port zum Kommunizieren mit dem PC. Obendrein haben einige LPCxxx einen Bootlader, der per USB benutzbar ist: dort tut er so wie ein Speicherstick, wo man ganz einfach die Firmware draufkopieren kann. Echt easy! Mit einem JTAG/SWD-Geschirre hat man hingegen zum einen die Debugmöglichkeit und zum zweiten die Not, einen guten Adapter sowie die Software dazu zu kaufen. Der JLink von Segger ist da der Klassenprimus, aber die echte Vollversion ist nicht ganz billig und die Software dazu verweigert manche Funktionen bei den billigeren JLink-Edu und JLink-OB. Kurzum, Bootlader ist frei und billig, JTAG/SWD ist mit Lizenzauflagen verbunden - und nochwas: für JTAG/SWD und einen seriellen Port zum späteren Kommunizieren braucht man eben zwei Steckbuchsen auf dem Board. W.S.
ok, vielen Dank für Eure Tips, ich denke es ist an der Zeit irgendwo ins kalte Wasser zu springen. Früher oder später, vermutlich eher früher, werde ich mit Fragen zurück sein. Als guter Schweizer sag ich da nur: What else? ;-)
Pascal S. schrieb: > und dann Kauf ich noch ein Labtool für 99€ dann hab ich meinen Logic > Analizer, erstes Oszi und den Signakgenerator auch dabei? Nun ja der LPC-Link Debugger hat einen etwas überdimensionierten LPC4370 drauf und der hat einen 80 MSPS ADC also haben die diese Oszi Erweiterung drangebaut. Der LPC4370 ist zudem ein Tri-Core mit erheblicher Rechenleistung. Der frühere LPC-Link hatte nur einen LPC4330 drauf ohne das alles.
Anstatt Eclipse würde ich Embedded Studio empfehlen: https://www.segger.com/products/development-tools/embedded-studio/ Das ist für einen Einsteiger vielleicht einfacher. Um erstmal mit ARM rum spielen zu können reicht ein 15 Euro STM32F4 Discovery Board von z.B. Amazon. Diese haben einen ST-Link drauf, den man aber in einen J-Link umwandeln kann: https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ D.h. mit sehr geringen Kosten kann man mit professionellen Tools loslegen. Ein späteres Upgrade wäre dann, wie schon erwähnt wurde, ein J-Link EDU Mini, J-Link EDU und ein weiteres Evalboard mit CAN.
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ "Limitations The firmware making the ST-LINK on-board J-Link compatible has some limitations in contrast to an original, industry leading SEGGER J-Link: May be used with ARM based ST devices only Only debugging on evaluation boards is allowed. Debugging on custom hardware is not supported and not allowed" [Zitat gekürzt] Das schränkt es aber wieder deutlich ein. Ich kann also mein selbstgebautes_ Board mit einem _ATMEL Cortex-M o. ä. nicht debuggen, obwohl die free non-commercial Entwicklungsumgebung das könnte?!
Tippgeber schrieb: > J-Link compatible ... ATMEL Cortex-M Ich nehme mal an dass Atmel bzw. Microchip es nicht zulässt für ihre Debugger also z.B. ICE eine J-Link Software anzubieten. Denn für die Debugger anderer Hersteller gibt es das ja - nicht nur für ST - z.B. https://www.segger.com/products/debug-probes/j-link/models/other-j-links/lpc-link-2/ https://www.segger.com/products/debug-probes/j-link/models/other-j-links/j-link-ob-spansion/ Abgesehen davon gibt es aber noch CMSIS-DAP das funktioniert auch: http://www.embeddedartists.com/products/lpcxpresso/lpclink2.php
Lothar schrieb: > Ich nehme mal an dass Atmel bzw. Microchip es nicht zulässt für ihre > Debugger also z.B. ICE eine J-Link Software anzubieten. Der EDBG-Chip im Atmel ICE ist ein etwas spezieller AVR32. Es ist verständlich, dass Segger keine Arbeit in eine tote Architektur stecken wird. Und der ICD3 kann kein JTAG, sondern nur ICSP für die PICs. Für den eJTAG der MIPS-PIC32 (der auch ICSP hat) kannst Du direkt den JLINK verwenden. fchk
> Debugging on custom hardware is not supported and not allowed
Das ist natürlich quatsch. Wie soll der Programmieradapter erkennen,
welches BOARD angeschlossen ist? Natürlich kann man jeden ST-Link
Adapter z.B. auch mit den billigen Boards aus China verwenden.
Die wollen dafür nur keinen Support leisten.
Frank K. schrieb: > Und der ICD3 kann kein JTAG, sondern nur ICSP für die PICs ICSP mit PGD/PGC ist physikalisch ein SWD und J-Link könnte den genauso unterstützen wie das C2D/C2CK der 8051 - daher nehme ich an dass Microchip es nicht zulässt. https://www.segger.com/products/debug-probes/j-link/technology/cpus-and-devices/silabs-efm8-c8051-support/
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.