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:> Grund:> STM32 ist mächtiger als PIC32 und viel billigerPIC32 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.
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/msp432e401yhttp://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.
> 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 ;-)
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
