Forum: Mikrocontroller und Digitale Elektronik Umstieg von PIC18F zu STM32F3


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 SimonBasel (Gast)


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

von stmler (Gast)


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

von SimonBasel (Gast)


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

von Tippgeber (Gast)


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

von SimonBasel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Tippgeber

Grund:
STM32 ist mächtiger als PIC32 und viel billiger

von X4U (Gast)


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

von Dingenskirchen (Gast)


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

von X4U (Gast)


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

von ManuelGast (Gast)


Bewertung
0 lesenswert
nicht lesenswert
X4U schrieb:
> Das gleiche, warum willst du die PC Seite neu schreiben?

Wir wollen unbedingt weg von USB Kommunikation.

von Mike (Gast)


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

von Mampf F. (mampf) Benutzerseite


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

von ManuelGast (Gast)


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

von Mampf F. (mampf) Benutzerseite


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

von ManuelGast (Gast)


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

von Mampf F. (mampf) Benutzerseite


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

von Dingenskirchen (Gast)


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

von Frank K. (fchk)


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

von Mampf F. (mampf) Benutzerseite


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

von Frank K. (fchk)


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

von Mampf F. (mampf) Benutzerseite


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

von Olaf (Gast)


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

von Axel S. (a-za-z0-9)


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

von Mampf F. (mampf) Benutzerseite


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

von ManuelGast (Gast)


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

von Niklas Gürtler (Gast)


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

von Mike Müller (Gast)


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

von Niklas Gürtler (Gast)


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

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Mike Müller schrieb:
> Was ist denn ein Mach-Kern??

Sorry, sorry ... Ich meinte natürlich MIPS.

von Dingenskirchen (Gast)


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

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Pandur S. (jetztnicht)


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

von Axel S. (a-za-z0-9)


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

von Mac G. (macgyver0815)


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

von Peter D. (peda)


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

von Frank K. (fchk)


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

von ManuelGast (Gast)


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

von Mampf F. (mampf) Benutzerseite


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

von Frank K. (fchk)


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

von Dingenskirchen (Gast)


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

von Peter D. (peda)


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

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Niklas Gürtler (Gast)


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

von Olaf (Gast)


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

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.