Hallo Zusammen, ich habe einen Projekt, der mit einem PIC18F4550 entwickelt wurde (vor meine Zeit). Das ganze Projekt ist ungefähr 10 Jahre alt. Bei diesem Projekt wurde sehr viel gebastelt und nicht wirklich sauber programmiert. Die Entscheidung für diese Prozessor war damals aufgrund die USB Kommunikation (HID). Der Entwurf bei der PIC18F ist basiert auf der Pollingsverfahren, was nicht unbedingt zu ende gedacht da der Prozessor dauerhaf unter Belastung ist. Um mit der PIC18F zu kommunizieren wurde einen Protokoll entworfen, der die Kommunikation zwischen PC bzw. PIC18F gliedert. Es ist die Zeitpunkt gekommen bei denen wir der Umstieg gewagt haben endlich mal von PIC18F wegzugehen. Die Idee ist einen STM32 zu benutzen und aus diesem Grund möchte ich euch fragen: 1)Wie schwer ist der Umstieg von (8 Bit) zu (32 Bit)? 2)Welche Protokoll soll es verwenden werden, damit es mit der Prozessor kommuniziert wird? 3)Wie wäre es mit C++ das STM32F3 zu programmieren? macht es überhaupt Sinn, damit es die Entwicklungszeit reduziert wird? 4)Was als alternative zu Pollingsverfahren? Auf einen konstruktive Feedback freue ich mich. Danke
Ich glaube nicht, dass der Umstieg schwer ist. Von den 32Bit bekommt man ja so gut wie nichts mit, wenn man in einer Hochsprache programmiert (c). Ich bin damals von den AVRs umgestiegen und es ging reibungslos. Es gibt zudem auch gut ausgebaute Librarys vom Hersteller, so dass man nur gelegentlich einen Blick ins Datenblatt werfen muss. Ich würde es an deiner Stelle einfach mal mit einem Evaluation-Board ausprobieren.
@stmler Das werde ich aufjedenfall tun. Was für einen Tools bei der 32 Bit benutzt du? Was denkst du über die weiteren Fragen, die ich vorher erstellt habe? danke
SimonBasel schrieb: > Es ist die Zeitpunkt gekommen bei denen wir der Umstieg gewagt haben > endlich mal von PIC18F wegzugehen. > > Die Idee ist einen STM32 zu benutzen und aus diesem Grund möchte ich > euch fragen: Warum nicht den PIC32? http://www.microchip.com/design-centers/32-bit
SimonBasel schrieb: > Grund: > STM32 ist mächtiger als PIC32 und viel billiger PIC32 gibt es bei DigiKey ab 1 Euro als Einzelstück. Wie kann da STM noch "viel billiger" sein? Ist aber eh müssig da der TE nach STM32 fragt. SimonBasel schrieb: > 1)Wie schwer ist der Umstieg von (8 Bit) zu (32 Bit)? Kommt auf die Compiler an mit denen du arbeitest. Bei PIC18 nach PIC32 war das für mich gar kein Problem. STM32 bin ich noch bei, wg. der Umstellung von MIPS auf den ARM Kern und den Unterschieden in der Peripherie. > 2)Welche Protokoll soll es verwenden werden, damit es mit der Prozessor > kommuniziert wird? Das gleiche, warum willst du die PC Seite neu schreiben? > 3)Wie wäre es mit C++ das STM32F3 zu programmieren? macht es überhaupt > Sinn, damit es die Entwicklungszeit reduziert wird? Das ist so nicht zu beantworten. Definiere besser welche Teile deiner Anwendung durch OO einfacher zu erstellen wären. > 4)Was als alternative zu Pollingsverfahren? Na Interrupt. USB hat aber keep alive Funktionen die du eh ständig bedienen musst.
SimonBasel schrieb: > @Tippgeber > > Grund: > STM32 ist mächtiger als PIC32 und viel billiger Da bist du dir so sicher? Ich bin ziemlich sicher, dass z.B. ein PIC32MX470 alle M0-Derivate des STM32 in die Tasche stecken. Erst mal hat der viel mehr MHz, dann hat der Kern auch ein paar sehr nette Features. Dann gibts noch die PIC32MZ mit FPU, und STM32 ohne FPU. Oder STM32 it FPU und PIC32 ohne FPU. Für den F7 mag deine Aussage auf alle Fälle stimmen (möglicherweise sogar für den F4), für F3 und darunter trifft das so eindeutig nicht immer zu. Um das Problem zu verdeutlichen: Nimm einen STM32F303ZE. Der hat bis zu 90 DMIPS Der PIC32MX470 hat dagegen 150. Dafür hat der STM32 aber eine FPU, der konkrete PIC nicht. Dafür ist der PIC32 aber billiger. Dafür hat der STM32 mehr und schnellere ADC. Dafür hat der PIC32MX aber doppelt soviel RAM. ... Du siehst das Problem mit solchen Vergleichen? Wenn du hergehst, und STM32 mit PIC18 vergleichst, ist das vielleicht wirklich so eindeutig wie du geschrieben hast. Bei PIC32 nicht. Da heißt es wirklich Features vergleichen, und pauschale Urteile steckenlassen.
Dingenskirchen schrieb: > Ich bin ziemlich sicher, dass z.B. ein ... Lass ihn doch. Die Gemeinde hier hat bisher immer zielsicher falsch gelegen wenn es um so was ging (z. B. Atmel -> Microchip / ARM -> Softbank ...). Das ganze rumargumentieren und lamentieren bringt nichts da die verfügbaren Chips letztlich alle sehr ähnlich sind. Ist mal ein Ungleichgewicht da wird es wieder ausgeglichen.
X4U schrieb: > Das gleiche, warum willst du die PC Seite neu schreiben? Wir wollen unbedingt weg von USB Kommunikation.
>X4U schrieb: >> Das gleiche, warum willst du die PC Seite neu schreiben? > >Wir wollen unbedingt weg von USB Kommunikation. Und auf was wechseln? Ethernet? Blauzahn? WîFi? NFC? CAN?
Tippgeber schrieb: > Warum nicht den PIC32? Der PIC32 hat mit den alten PICs nichts zu tun, weil er einen Mach-Kern verwendet. Logisch wäre, etwas zu benutzen, was auch viele andere benutzen.
Mike schrieb: > Und auf was wechseln? Ethernet? Blauzahn? WîFi? NFC? CAN? Ich weiss es wirklich nicht.Ich habe es in diesem Bereich keine Erfahrung. Was ist deine Meinung nach sinnvoll?
ManuelGast schrieb: > Ich weiss es wirklich nicht.Ich habe es in diesem Bereich keine > Erfahrung. > Was ist deine Meinung nach sinnvoll? Erstmal müsstest du dir darüber gedanken machen, ob es ein kabelgebundene Kommunikation sein soll oder per Funk. Dann solltest du dir überlegen, welche Schnittstelle am wenigsten Portierungsaufwand zu bestehenden Projekten wäre. Warum magst du kein USB?
Mampf F. schrieb: > Warum magst du kein USB? Bei der laufenden Projekt habe ich sehr viel Probleme was USB betrifft. Es lag vielleicht in der schlechte Programmierung und ... Ich kann das wirklich nicht zu 100% beurteilen. Was noch zu sagen ist: Jetzigen Projeckt ist basiert auf einen PIC18F45550, die selber HID Kommunikation unterstützt und vielleicht das ist das Problem.
ManuelGast schrieb: > Mampf F. schrieb: >> Warum magst du kein USB? > > Bei der laufenden Projekt habe ich sehr viel Probleme was USB betrifft. Erzähl mal ein bisschen mehr über die Probleme :) > Es lag vielleicht in der schlechte Programmierung und ... > Ich kann das wirklich nicht zu 100% beurteilen. Hmm, also "schlecht" kann man auf jedem µC programmieren :/ > Was noch zu sagen ist: > Jetzigen Projeckt ist basiert auf einen PIC18F45550, die selber HID > Kommunikation unterstützt und vielleicht das ist das Problem. Der Einsatzzweck wäre interessant ... HID ist für zB industrielle Maschinensteuerungen eigentlich nicht geeignet, weil HID den Transfer nicht garantiert ... D.h. es dürfen laut USB-Spezifikation Daten verloren gehen und das ist bei HID Devices in Ordnung. Was wäre denn zB mit USB-CDC (Virtuelle serielle Schnittstelle / Virtueller COM-Port)? Für STM32 (für andere sicher auch) gibt es gut funktionierende Libraries und das Ansprechen von Linux oder Windows aus ist nicht schwieriger als direkt eine serielle Schnittstelle zu verwenden. Polling kann man sich da auch sparen :)
Mampf F. schrieb: > Tippgeber schrieb: >> Warum nicht den PIC32? > > Der PIC32 hat mit den alten PICs nichts zu tun, weil er einen Mach-Kern > verwendet. Das trifft aber nur auf den Kern zu. Und von dem merkt man normalerwiese nicht so viel, Das Handling für den Entwickler ist sehr ähnlich zu z.B. den PIC18. Die Peripherie ist ähnlich, teils ist der Code sogar portierbar, die Toolchain ist die gleiche, die Datenblätter sind gleich und so weiter. Nur der Compiler unterscheidet sich, und man ist die alten Beschränkungen des z.B. PIC18 los. > Tippgeber schrieb: > Logisch wäre, etwas zu benutzen, was auch viele andere benutzen. PIC32 sind druchaus gängig. D.h. viele andere verwenden den auch. Nur vielleicht nicht hier im Forum. Aber das hat mit der gesamten Microcontrollerwelt auch wenig zu tun (man liest hier z.B. auch wenig von Cypress, Renesas, NXP oder Nuvoton - auch das sind keine Exoten). Erklär doch mal, was du mit der Aussage meinst. Was ich jetzt nicht sagen will: PIC32 sind besser als STM32. Das ist so pauschal nicht richtig (andersherum aber genausowenig). Mein Punkt ist einzig und alleine: Jemand, der PICs gut kennt, tut sich mit dem Einstieg bei PIC32 leichter, als bei ARMs. VIEL leichter.
ManuelGast schrieb: > Mike schrieb: >> Und auf was wechseln? Ethernet? Blauzahn? WîFi? NFC? CAN? > > Ich weiss es wirklich nicht.Ich habe es in diesem Bereich keine > Erfahrung. > Was ist deine Meinung nach sinnvoll? Und dann wählst Du eine konkrete Prozessorplattform, wenn Du nicht einmal das Ziel kennst? Idiot! Sorry. Man wählt erst das Ziel und sucht sich dann eine geeignete Plattform aus. USB funktioniert woanders millionenfach. + billig - begrenzte Kabellänge - galvanische Isolation ab High Speed schwierig CAN funktioniert auch millionenfach. + deterministisch - nur kleine Datenpakete (8 Byte) -> Echtzeit-Steuerungen Ethernet funktioniert auch millionenfach + gut für große Datenmengen geeignet - normal ohne spezielle Erweiterungen nicht deterministisch - nicht wirklich stromsparend Vorschlag zum Anschauen: http://www.ti.com/product/msp432e401y http://www.ti.com/tool/msp-exp432e401y Der hat den Ethernet PHY bereits eingebaut, auch ansonsten alle wichtigen Schnittstellen, und die Treiberbibliothek und der Bootloader sind im ROM. Wenn es um die Schmerzen beim Umstieg geht, ist der Schritt PIC18 nach PIC32 mit großem Abstand am einfachsten. Die Peripherie ist ähnlich, vieles wird Dir bekannt vorkommen, nur der Prozessor ist halt viel viel leistungsfähiger. fchk
Dingenskirchen schrieb: > Erklär doch mal, was du mit der Aussage meinst. Naja, ARM hat 85% Marktanteil im Embedded-Bereich und es gibt sehr viele ARM-optimierte Libraries. Evtl könnte man sogar Libs, die für den Raspi optimiert wurden, verwenden usw. Dadurch gibt es einen sehr großen Resource-Pool ... Da kann es bei PIC32 nur mau aussehen (auch wenn der "viel" benutzt wird). > Was ich jetzt nicht sagen will: > PIC32 sind besser als STM32. Das ist so pauschal nicht richtig > (andersherum aber genausowenig). Um das "besser" geht es nicht ... Es geht darum, Resourcen, Hilfe, Erfahrung zur Verfügung zu haben. Welcher Kern genau ist - wie du schon meintest - im Grunde egal ... Die können alle mehr oder weniger das gleiche. > Mein Punkt ist einzig und alleine: > Jemand, der PICs gut kennt, tut sich mit dem Einstieg bei PIC32 > leichter, als bei ARMs. VIEL leichter. Da hat die Lernkurve evtl eine andere Steigung ... Wenn man sich eingearbeitet hat, fällt das Argument aber weg.
Mampf F. schrieb: > Dingenskirchen schrieb: >> Erklär doch mal, was du mit der Aussage meinst. > > Naja, ARM hat 85% Marktanteil im Embedded-Bereich und es gibt sehr viele > ARM-optimierte Libraries. Evtl könnte man sogar Libs, die für den Raspi > optimiert wurden, verwenden usw. > > Dadurch gibt es einen sehr großen Resource-Pool ... Da kann es bei PIC32 > nur mau aussehen (auch wenn der "viel" benutzt wird). Es gibt nicht "den ARM". Die meisten Leute vergessen das. Die ganzen Controller haben wirklich nur den nackten Prozessorkern plus Debug gemein, bei Cortex M noch Interrupt-Controller und einen Timer, und selbst für das bisschen braucht es noch CMSIS, um das glattzubügeln. Der große Rest ist genauso zersplittert wie woanders auch. Der Vorteil ist also nur begrenzt, wenn nicht marginal. fchk
Frank K. schrieb: > Es gibt nicht "den ARM". Die meisten Leute vergessen das. Die ganzen > Controller haben wirklich nur den nackten Prozessorkern plus Debug > gemein Ja klar, die Peripherie ist überall anders ... Aber Beispiel: Ich hatte einen MP3-Player mit Helix-MP3-Dekoder für einen Cortex M4 gebastelt und den jetzt problemlos (mit ARM-Assembler-Optimierungen, die Helix schon drin hat) auf den Raspi portiert. Sowas meinte ich mit Libraries ... Die Peripherie zählt da natürlich nicht dazu, das ist klar :)
> Ich weiss es wirklich nicht.Ich habe es in diesem Bereich keine > Erfahrung. > Was ist deine Meinung nach sinnvoll? Ich hab gerade den Eindruck das dir die notwendige Expertise fehlt um selber eine USB-Verbindung im Mikrocontroller und den notwendigen Treiber auf der Gegenseite zu erstellen. Das muss dich im uebrigen nicht verwundern, so geht es vielen. Das ist auch der Grund warum die ganzen FTDI, Prolific und andere so beliebt sind. (Von so Sachen wie Zertifizierung ganz abgesehen) Also mach es wie alle anderen auch. Wenn es aber wirklich gute Gruende gibt das alles selber zu programmieren dann stell dich darauf ein erstmal ein paar Wochen Datenblaetter, Applikationen, Handbuecher usw zu lesen. Oh..und so nicht so dumm einen Mikrocontroller danach auszuwaehlen was gerade cool und billig ist. Nimm den der am besten dokumentiert ist. + Olaf
Mampf F. schrieb: > Frank K. schrieb: >> Es gibt nicht "den ARM". Die meisten Leute vergessen das. Die ganzen >> Controller haben wirklich nur den nackten Prozessorkern plus Debug >> gemein > > Ja klar, die Peripherie ist überall anders ... > > Aber Beispiel: Ich hatte einen MP3-Player mit Helix-MP3-Dekoder für > einen Cortex M4 gebastelt und den jetzt problemlos (mit > ARM-Assembler-Optimierungen, die Helix schon drin hat) auf den Raspi > portiert. An dieser Stelle profitierst du praktisch nur vom Compiler und von der Hardware-Abstraktion, die dir C bietet. Ein MP3-Decoder ist reines Numbercrunchen. Hier ein Buffer mit MP3, da ein Buffer für die Samples. Und ganz viel Rechnerei, um das eine in das andere umzuwandeln. Dabei gibt es praktisch keinerlei Abhängigkeiten vom CPU-Kern mehr. Ob der Compiler das für einen ARM, MIPS, x86 oder AVR übersetzt, ist am Ende vollkommen Wumpe. Der einzige Unterschied liegt in der Effizienz der C-Operationen (z.B. uint32_t + uint32_t) auf der jeweiligen Plattform. Die bestimmt dann, ob die Rechenpower reicht oder nicht. Und sogar das kann man in einem gewissen Rahmen noch mit einer simplen Erhöhung der Taktfrequenz kompensieren.
Axel S. schrieb: > Dabei gibt es praktisch keinerlei Abhängigkeiten vom CPU-Kern mehr. Hast du gelesen, was ich geschrieben habe? In dem Code sind Inline-Assembler-Schnippsel für ARM verbacken und davon profitiert man durchaus.
Mampf F. schrieb: > Erzähl mal ein bisschen mehr über die Probleme :) Bei der jetzigen Stand ist die USB verbindung gar nicht zuverlässig. Wir wollen zu Testzwecke mehreren Erweiterungen einbauen aber es ist unmöglich, da der Prozessor einen Last(Speicher) von 96 % hat. Mampf F. schrieb: > Was wäre denn zB mit USB-CDC (Virtuelle serielle Schnittstelle / > Virtueller COM-Port)? Dazu habe ich eine Frage: Wie zuverlässig ist das im verlgleich zu HID? Dingenskirchen schrieb: > Mein Punkt ist einzig und alleine: > Jemand, der PICs gut kennt, tut sich mit dem Einstieg bei PIC32 > leichter, als bei ARMs. VIEL leichter. Das stimmt aber die Idee ist, dass der STM32 bei anderen Projeckte eingesezt ist. Frank K. schrieb: > Und dann wählst Du eine konkrete Prozessorplattform, wenn Du nicht > einmal das Ziel kennst? Idiot! Sorry. Man wählt erst das Ziel und sucht > sich dann eine geeignete Plattform aus. Es ist mir schon klar, dass erst einen Ziel definiert sein muss aber ich bin immer noch unentschlossen, da ich nicht so viel Erfahrungen habe. Das ist der Grund: warum ich auch hier frage.
Eine sauber implementierte USB Ansteuerung sollte auch vernünftig funktionieren. Das sieht man ja auch an unzähligen Geräten. Polling macht da aber wohl weniger Sinn. Wenn USB an sich geeignet ist, könnt ihr auch dabei bleiben... Etwas Werbung: Hier ist ein Tutorial zur Umsetzung von USB Devices mit dem STM32, dank WinUSB+libusb komplett ohne Treiber Installation ohne sich auf HID beschränken zu müssen: USB-Tutorial mit STM32
Mampf F. schrieb: > Tippgeber schrieb: >> Warum nicht den PIC32? > > Der PIC32 hat mit den alten PICs nichts zu tun, weil er einen Mach-Kern > verwendet. Was ist denn ein Mach-Kern??
ManuelGast schrieb: > Dazu habe ich eine Frage: Wie zuverlässig ist das im verlgleich zu HID? Beide sollten wenn ordentlich umgesetzt zuverlässig funktionieren. Aber bei beiden schränkt man sich ein, das sollte bei Neu-Entwicklungen mMn nicht nötig sein - es ist sauberer und für den Anwender letztlich auch einfacher ein "richtiges" USB Gerät zu implementieren, welches über die entsprechenden APIs angesteuert wird (z.B. WinUSB). Ist auch nur unwesentlich komplizierter als der Zugriff auf einen COM Port.
Mampf F. schrieb: > Frank K. schrieb: >> Es gibt nicht "den ARM". Die meisten Leute vergessen das. Die ganzen >> Controller haben wirklich nur den nackten Prozessorkern plus Debug >> gemein > > Ja klar, die Peripherie ist überall anders ... > > Aber Beispiel: Ich hatte einen MP3-Player mit Helix-MP3-Dekoder für > einen Cortex M4 gebastelt und den jetzt problemlos (mit > ARM-Assembler-Optimierungen, die Helix schon drin hat) auf den Raspi > portiert. Ich hab EXAKT das auf einem PIC32MX470 umgesetzt. Das ging hervorragen. Schon wieder kein Argument, denn der Helix unterstützt ganz genauso den MIPS-Kern der PIC32MX, inklusive Assembler Schnippsel :-) Das Konzept profitierte enorm von der I2S-Schnittstelle, dem Referenzoszillator und dem DMA des PIC32. Es gibt sogar eine Application-Note von Microchip dazu: http://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en551513 --> Kein Argument für ARM.
Dingenskirchen schrieb: > --> Kein Argument für ARM. Zugegeben, das ist eigentlich schon ein extremes Beispiel, wenn man irgendwo inline-Assembler-Code hat und so gut wie nie hat man sowas. Okay, wenn man nur den CPU-Kern betrachtet ist es wohl egal, was man nimmt ... Da gebe ich euch allen recht.
:
Bearbeitet durch User
> Wir wollen zu Testzwecke mehreren Erweiterungen einbauen aber es ist unmöglich, da der Prozessor einen Last(Speicher) von 96 % hat. Ist sehr gut moeglich mit unpassender Programmierung. >> Was wäre denn zB mit USB-CDC (Virtuelle serielle Schnittstelle / >> Virtueller COM-Port)? >Dazu habe ich eine Frage: Wie zuverlässig ist das im verlgleich zu HID? HID ist fuer Human interfaces, wie Taststur & Mouse, um macht nur 64 Nachrichten pro sekunde. Waehrend ein Comport, zB von FTDI mit 1MBit spezifiziert ist. Alle meine Geraete werden mit USB2Serial mit einem FTDI Chip ausgestattet. Es gab noch nie Probleme, das meiste sind 24/7 Geraete, die laufen durch, waehrend Jahren.
Mampf F. schrieb: > Axel S. schrieb: >> Dabei gibt es praktisch keinerlei Abhängigkeiten vom CPU-Kern mehr. > > In dem Code sind Inline-Assembler-Schnippsel für ARM verbacken und davon > profitiert man durchaus. Das ist aber eine reine Optimierungsmaßnahme. Auf Plattformen, für die keine handgeschriebene Assembler-Implementierung vorhanden ist, verwenden solche Libs dann typisch eine C-Implementierung für die entsprechenden (zeitkritischen) Funktionen.
Sabberalot W. schrieb: > HID ist fuer Human interfaces, wie Taststur & Mouse, um macht nur 64 > Nachrichten pro sekunde. Falsch. Es sind 64 Byte pro Nachricht und 1000 Nachrichten pro Sekunde. Also max. 512 kBit/s. Und auch bei HID gibts automatisches Retry wenn eine Nachricht nicht ankommt - jedenfalls soweit ich weiss - ist schon länger her dass ich das genauer angesehen habe.
SimonBasel schrieb: > Bei diesem Projekt wurde sehr viel gebastelt und nicht wirklich sauber > programmiert. Daran kann eine andere CPU aber rein garnichts ändern. Ein schlechtes Programm läuft auf 32Bit genauso schlecht, wie auf 8Bit. Man muß dann erstmal den Programmablaufplan neu durchdenken und umstellen. SimonBasel schrieb: > Der Entwurf bei der PIC18F ist basiert auf der Pollingsverfahren, was > nicht unbedingt zu ende gedacht da der Prozessor dauerhaf unter > Belastung ist. Ein MC kann völlig problemlos mit 100% laufen, ohne sich nennenswert zu erwärmen. Er ist ja keine PC-CPU. Und abnutzen kann er sich auch nicht. Alle meine MC-Anwendungen laufen in einer Main-Loop mit Polling: Loop: - ist ein Remotebefehl eingetroffen? - wurde eine Taste gedrückt? - hat sich ein Status geändert? - goto Loop
ManuelGast schrieb: > Dingenskirchen schrieb: >> Mein Punkt ist einzig und alleine: >> Jemand, der PICs gut kennt, tut sich mit dem Einstieg bei PIC32 >> leichter, als bei ARMs. VIEL leichter. > Das stimmt aber die Idee ist, dass der STM32 bei anderen Projeckte > eingesezt ist. > > Frank K. schrieb: >> Und dann wählst Du eine konkrete Prozessorplattform, wenn Du nicht >> einmal das Ziel kennst? Idiot! Sorry. Man wählt erst das Ziel und sucht >> sich dann eine geeignete Plattform aus. > > Es ist mir schon klar, dass erst einen Ziel definiert sein muss aber ich > bin immer noch unentschlossen, da ich nicht so viel Erfahrungen habe. > Das ist der Grund: warum ich auch hier frage. Aber dann bitteschön erstmal ergebnisoffen fragen! USB funktioniert normalerweise problemlos. Egal ob HID, CDC-ACM, oder sonst was. Wenn bei Euch das ganze nicht funktioniert, habt Ihr Fehler bei der konkreten Umsetzung gemacht, sei es in der Hardware oder in der Software. Dafür braucht Ihr jetzt erstmal keine neue Plattform, sondern müsst Euch erstmal Know-How einkaufen, um die Ursache Eurer Probleme zu finden. Sonst macht Ihr die gleichen Fehler auf einer anderen PLattform wieder. PIC18 ist recht einfach und leicht zu überblicken. Ein STM32 macht das USB an sich nicht einfacher, sofern Ihr nicht sicher wisst, was Ihr da macht. fchk
@Frank K. Du hast vollkommen recht. Der PIC18F ist seit sehr lange bei diesem projekt eingesetzt. Bei der jetzigen Projekt können wir keine Erweiterungen mehr durchführen. Es hat einen Last von über 90% Prozent und das ist auch einen Problem. Hier im Hause wurde der STM32 stark eingesezt und deswegen war die Idee warum sollen wir eine neue Prozessor aussuchen, wenn wir diese Know-How hier im Hause haben. Das Problem mit der USB(HID) war lange einen Thema aber es lässt sich eigentlich lösen, wenn man vor vorne an einen richtige Konzept erstellt. Damals vor meine Zeit ging darum schnell schnell zu Ergebnis und am Anfang war das ganze einen Bastelboard und als halbsweg funktioniert hat bloß nicht anfassen und so ist geblieben. Mir geht darum mit euch auszutauschen und nach eure Meinungen fragen. Ich bin keinen experten was Embedded betrifft. Ich komme eigentlich aus der C++ Welt und habe einen 3 Jährige Erfahrung in Embedded bereich.
ManuelGast schrieb: > Hier im Hause wurde der STM32 stark eingesezt und deswegen war die Idee > warum sollen wir eine neue Prozessor aussuchen, wenn wir diese Know-How > hier im Hause haben. > > Das Problem mit der USB(HID) war lange einen Thema aber es lässt sich > eigentlich lösen, wenn man vor vorne an einen richtige Konzept erstellt. Dann liegt es nahe, USB mit STM32 zu verwenden. Einen virtuellen Com-Port kriegt man recht schnell zum Laufen :)
ManuelGast schrieb: > @Frank K. > Du hast vollkommen recht. > Der PIC18F ist seit sehr lange bei diesem projekt eingesetzt. > Bei der jetzigen Projekt können wir keine Erweiterungen mehr > durchführen. Es hat einen Last von über 90% Prozent und das ist auch > einen Problem. > > Hier im Hause wurde der STM32 stark eingesezt und deswegen war die Idee > warum sollen wir eine neue Prozessor aussuchen, wenn wir diese Know-How > hier im Hause haben. Wenn das auch den USB-Controller einschließt, dann nur zu. Ansonsten ist das hier ein schöner USB-ARM: https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/lpc-cortex-m-mcus/lpc1300-cortex-m3/entry-level-32-bit-microcontroller-mcu-based-on-arm-cortex-m3-core:LPC1343FBD48 Hat Treiber für USB-HID und USB Mass Storage im ROM, hat USB Mass Storage Bootloader im ROM. Sprich: Pin runterziehen, reset, und dann sieht man einen 32k USB Stick, auf den man seine Firmware kopiert, und damit ist sie dann drin. Ohne nähere Kenntnis der Applikation kann ich natürlich keine Empfehlung aussprechen. fchk
ManuelGast schrieb: > Hier im Hause wurde der STM32 stark eingesezt und deswegen war die Idee > warum sollen wir eine neue Prozessor aussuchen, wenn wir diese Know-How > hier im Hause haben. Aha! Du hast also doch einen echten Grund STM32 zu verwenden, nicht nur Bauchgefühl, Mode und dem äußerst agressivem STM32-Hype hier im Forum. In Fall vorhandener Expertiese gibt es natürlich keinen Grund, von den STM32 abzuweichen. Mich ärgert dieser Hype enorm, weil viele (für Bastler!) viel besser geeignete µC-Familien wie PIC32 oder Cypress PSOC permanent niedergebasht werden. Außerdem ist ST hinter Renesas und NXP nur die Nummer 3: https://www.eetimes.com/author.asp?section_id=36&doc_id=1328742 Von wegen "Standard" oder "Marktführer". Von Renesas werden die meisten hier noch nie etwas gehört haben :-) Bitte also zukünftig also keinen Quatsch wie "mächtiger als XY" behaupten, dann kommt auch kein Wiederspruch. Falls ihr die Expertiese habt, Windows-Treiber zu erstellen wäre eine echte USB-Kommunikation die beste Lösung. Falls nicht, ist USB CDC (Das gibts fertig von ST) oder USB HID vielleicht sinnvoller. Noch ein Hinweis: Laut unseren Firmwareentwicklern ist CUBE-MX relativ buggy, und einige Dinge sind seht schlecht umgesetzt. Sei also gewarnt. Aber es gibt ja noch die STM32-Peripheral-Lib. Die ist angeblich besser.
Dingenskirchen schrieb: > Von Renesas werden die meisten > hier noch nie etwas gehört haben :-) Renesas hat sich zumindest in der Vergangenheit den Ruf erworben, bezüglich Datenblätter und Informationen recht zugeknöpft zu sein. Heutzutage ist für die Verbreitung eines Produktes sehr wichtig, wie leicht man im WWW drauf zugreifen kann. Es ist doch ein erheblicher Zeitaufwand, wenn man nur mal zum Ausprobieren erstmal dem Hersteller ein Ohr abkauen muß. Da klickt man eben schnell weiter zum nächsten.
Peter D. schrieb: > Dingenskirchen schrieb: >> Von Renesas werden die meisten >> hier noch nie etwas gehört haben :-) > > Renesas hat sich zumindest in der Vergangenheit den Ruf erworben, > bezüglich Datenblätter und Informationen recht zugeknöpft zu sein. Hmm, ich war mal auf einer kostenlosen Schulung von Renesas, als die die ersten waren, die Cortex M3 anboten ... Zumindest hatte ich vorher noch nichts von Cortex M3 gehört. Ist schon ein paar Jahre her. Gibt es Renesas eigentlich noch? Dachte mich daran erinnern zu können, dass es die nicht mehr gibt. *edit*: "Im September 2016 gab Renesas die Übernahme von Intersil für 3,2 Mrd. US-Dollar bekannt" Ahja, dann wird es die noch geben ;-)
:
Bearbeitet durch User
Dingenskirchen schrieb: > Falls ihr die Expertiese habt, Windows-Treiber zu erstellen wäre eine > echte USB-Kommunikation die beste Lösung. > Falls nicht, ist USB CDC (Das gibts fertig von ST) oder USB HID > vielleicht sinnvoller. Warum sich auf CDC oder HID beschränken, man kann über WinUSB+libusb auch auf eigene Geräte zugreifen, das ist flexibler, immer noch recht einfach und braucht auch keine Treiber.
> Gibt es Renesas eigentlich noch? Dachte mich daran erinnern zu können, > dass es die nicht mehr gibt. Der groesste Microcontrollerhersteller der Welt? Du machst Witze. Renesas duerfte mehr unterschiedliche Controllerfamlien haben als drei andere Hersteller zusammen. Was bei der Geschichte von dem Laden auch logisch ist. Und was die Qualitaet der Datenblaette angeht. Sie war vor 15Jahren mal nicht so gut weil man denen angemerkt hat das die Uebersetzung aus dem japanischen ins Englische wenig gelungen wirkte. Das hat sich aber schon lange geaendert. Mittlerweile sind sie IMHO der Massstab was Qualitaet von Dokumentation angeht. Viel besser als ST, Silabs oder AVR. Negativ an Renesas ist das der Laden so gross ist das man manchmal Probleme hat etwas bei denen wieder zu finden. einfach weil sie soviel haben. Olaf
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.