mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Hardware-Designtipps des Monats: Das Systemdesign


Autor: Luky S. (luky)
Datum:
Angehängte Dateien:

Bewertung
-7 lesenswert
nicht lesenswert

Für den nun folgenden Vorgang gibt es eine Menge Namen und Bezeichnungen. Entwurf, Systemdesign, Archtekturentwurf, High-Level Design, einfach nur Design und noch viel mehr. Im Prinzip geht es darum, ein Blockschaltbild zu erstellen und sich zu überlegen, wie man die einzelnen Teilprobleme effektiv löst. Einfach mit dem Schaltplan anzufangen führt leider oft zu nicht optimalen Lösungen.

Um möglichst allgemein zu bleiben, gehen wir von einem Produkt mit einem Mikrocontroller (incl. Firmware), einer mixed Signal Schaltung und einem PC-basierten Konfigurations- oder Visualisierungstool aus.

Die folgenden Fragen können natürlich nicht alle Fälle abdecken und nicht immer sind alle Punkte notwendig.

  • Was erledigt man besser in Hardware und was effektiver in Software?
Die Beantwortung dieser Frage hängt in erster Linie von den vorhandenen Ressourcen, der möglichen Entwicklungszeit, den Kosten pro Gerät bzw. den (umgelegten) Entwicklungskosten, der technischen Machbarkeit und von der Erfahrung / Spezialisierung ab. Allgemein gültige Aussagen sind hier sehr schwierig zu treffen, da oft eine kleine Schaltung einen enormen Softwareaufwand einsparen kann, aber auch umgekehrt ein paar Zeilen Quellcode die Hardware massiv vereinfachen können. Ein gutes Beispiel sind Filterschaltungen.
  • Welcher Mikrocontroller bzw. welche Architektur?
Diese Frage wird allzu oft vernachlässigt und man nimmt einfach das, was immer schon verwendet wurde. Natürlich gibt es gute Gründe für diese Strategie, aber manchmal ist ein geschickt ausgewählter Mikrocontroller mit der richtigen Peripherie, ausreichend viel Leistung und guter Software vom Hersteller eine sehr elegante und effektive Lösung für ein Problem und rechtfertigt den Einarbeitungsaufwand.
  • Wie kommuniziert das Gerät mit dem PC / Smartphone / Tablet / etc.?
Hier muss man sich auch genau die Anforderungen überlegen. RS232 ist praktisch ausgestorben, für USB gibt es mehrere Möglichkeiten wie z.B. einen Mikrocontroller mit USB (für ein kommerzielles Produkt braucht man „offiziell“ eine USB ID…), einen der allseits bekannten Konverterchips (USB auf UART, SPI, I2C...) auf der Platine oder einen UART Pinheader in Kombination mit einem USB-Kabel mit integrierten Konverter). Ethernet ist schon aufgrund der galvanischen Trennung eine interessante Option, darf aber vom Aufwand her nicht unterschätzt werden. Kabellose Techniken, vor allem WLAN und Bluetooth Low Energy (BLE) finden immer weitere Verbreitung und haben sicherlich ihre Vorteile, man sollte die Sicherheit (im Sinne von Safety UND Security) aber nicht ganz vernachlässigen.
  • Wie kommuniziert das Gerät mit dem Menschen (Tasten, Display, Audio…)
Die Erfahrung zeigt, dass eine rote 7-Segment Anzeige und ein paar Taster im Zeitalter der Multitouch-Smartphones immer weniger akzeptiert werden. In ein gutes Benutzerinterface kann und muss daher oft eine Menge Zeit investiert werden. Hier ist Betriebsblindheit oft das größte Problem, da der Entwickler mit „seiner“ Oberfläche natürlich bestens zurechtkommt, ein neuer Benutzer aber nicht unbedingt dieselbe Erfahrung machen muss.
  • Gibt es eine räumliche Aufteilung der Komponenten?
Wenn die Einzelteile verteilt sind, sollte man sich die Verbindungen der Komponenten untereinander gut überlegen. Jeder (vermeidbare) Kabel und jeder Stecker ist eine Kosten- und Fehlerquelle und manche Interfaces mögen längere Übertragungsstrecken einfach nicht bzw. benötigen dann besondere Aufmerksamkeit und Zusatzbeschaltung. Diese Probleme kann man manchmal zumindest Teilweise mit einer geschickten Anordnung der Komponenten umgehen. An dieser Stelle kann man auch gleichzeitig versuchen, die Anzahl der Bauteile, die ungünstigen Umgebungsbedingungen (hohe und niedrige Temperaturen, Vibrationen, Schock, Feuchtigkeit, ….) ausgesetzt sind, zu minimieren.

Wenn man dann am Ende dieses Prozesses (ungefähr) weiß, welche Bauteile wo liegen und wie die Anforderungen ausschauen, kann man tatsächlich im nächsten Schritt mit dem Design der Schaltung anfangen.


: Verschoben durch Admin
Autor: Frankman (Gast)
Datum:

Bewertung
10 lesenswert
nicht lesenswert
Was möchtest Du uns mit diesem Post eigendlich mitteilen? Sorry, aber 
das hört sich alles nach einem Referat in der Schule an.

Autor: uint32_t clean_code = 0; (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Luky S. schrieb:
> RS232 ist praktisch ausgestorben

Das ist mal eine Aussage!

Autor: Edi. M. (Firma: Industrie 1.0) (elektromeister)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Wer behauptet sowas? Wir haben immer irgendwo 2 Pins, um mit RS232 
dranzukommen, der Kunde weiss nur nicht, wo.

Autor: nein, ist es nicht! (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Luky S. schrieb:
> Ethernet ist schon aufgrund der galvanischen Trennung eine interessante
> Option

aua

Autor: JoJo (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Warum sind denn eigentlich alle immer so kritisch. Ist doch eine nette 
Anregung. Danke für den Beitrag.

Vll. hat das nicht den Charakter einers Beitrags einer Fachzeitschrift, 
aber das Forum besteht auch nicht nur aus Spezialisten, würde ich mal 
behaupten.

Und nun änder ich den Nick, bevor es wieder Haue gibt;-)

Autor: Bastler (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Da fehlen mir die Schnittstellen aus der Industrie:
RS485 (Profibus/Modbus), CAN, LIN, IO-Link, ...

Beitrag #5137363 wurde von einem Moderator gelöscht.
Autor: Schreiber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uint32_t clean_code = 0; schrieb:
> Luky S. schrieb:
>> RS232 ist praktisch ausgestorben
>
> Das ist mal eine Aussage!

Stimmt schon, das hat heute kein normaler Computer.
Entweder man liefert einen (kompatiblen) externen RS232 auf 
was-auch-immer-Adapter mit oder man baut ihn gleich fest ein.
Alles andere fhrt nur zu Ärger beim Support und dummen nachfragen.

RS232 auf USB und RS232 auf Bluetooth sind die gängigsten Lösungen.

Autor: spess53 (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hi

>Stimmt schon, das hat heute kein normaler Computer.

???. Bei mir haben alle Rechner, egal ob daheim oder auf Arbeit, eine 
RS232-Schnittstelle. Vielleich solltest du mal im Handbuch zum 
Motherboard nachsehen. In den meisten Fällen reicht ein Slotblech mit 
Buchse und Kabel um die Schnittstelle nachzurüsten.

MfG Spess

Autor: Horst S. (hdc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> ???. Bei mir haben alle Rechner, egal ob daheim oder auf Arbeit, eine
> RS232-Schnittstelle. Vielleich solltest du mal im Handbuch zum
> Motherboard nachsehen. In den meisten Fällen reicht ein Slotblech mit
> Buchse und Kabel um die Schnittstelle nachzurüsten.

Wo schraube ich bei meinem Notebook das Slotblech an?

Autor: M.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Luky S. schrieb:
> Kabellose Techniken, vor allem WLAN und Bluetooth Low Energy (BLE)
> finden immer weitere Verbreitung und haben sicherlich ihre Vorteile, man
> sollte die Sicherheit (im Sinne von Safety UND Security) aber nicht ganz
> vernachlässigen.

Gerade bei Bluetooth sollten die Lizensierungskosten mit einkalkuliert 
werden, vorallem dann wenn man sein Produkt international vertreiben 
möchte.

Wenn es um die anschliessenden Messungen im EMV-Labor geht wird es 
ebenfalls noch einmal teurer. Außerdem sollte man sich im Vorfeld schlau 
machen, welche Normen dann zu beachten sind.

Autor: Falk Brunner (falk)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
@spess53 (Gast)

>>Stimmt schon, das hat heute kein normaler Computer.

Eben. Und auch keinerlei Konsumer-Produkt. Vielleicht noch ein paar 
alte, exotische Geräte oder Maschinensteuerungen. Aber auch dort schläft 
man nicht total, wenn gleich man nicht so hipp ist wie die Handies.

>???. Bei mir haben alle Rechner, egal ob daheim oder auf Arbeit, eine
>RS232-Schnittstelle. Vielleich solltest du mal im Handbuch zum
>Motherboard nachsehen. In den meisten Fällen reicht ein Slotblech mit
>Buchse und Kabel um die Schnittstelle nachzurüsten.

Und wen interessiert das? Wieviel ppm der Anwender werden das tun?
Hardwareentwickler wie du sind sehr kleine Randgruppen.

Autor: Feldkurat Katz (feldkurat)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Falk B. schrieb:
> Und wen interessiert das?

Das interessiert außer Dir so ziemlich Jeden, der eine betriebssichere 
Lösung für serielle Kommunikation braucht und sich nicht von 
Treiberupdates seinen USB/RS232 Wandler abschießen lassen will.

-Feldkurat-

Autor: Edi. M. (Firma: Industrie 1.0) (elektromeister)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist in der Tat ein ernstes Problem: Ich habe schon FTDI-Treiber im 
munteren Wechsel installiert und wieder deinstalliert, weil Ich den 
Programmer, der ISP-Debugger und einen USB/485 benötigte und der Treiber 
die Geräte nicht unterscheiden konnte. Also immer 2 Pins exter für ein 
schnuckeliges RS232

Autor: il Conte (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Luky S. schrieb:
> Für den nun folgenden Vorgang gibt es eine Menge Namen und
> Bezeichnungen.

Ich möchte dir in keinster Weise zu nahe treten, aber dein Beitrag ist 
für mich nur holes Gerede.

Warum?
Du stellst Fragen wie an Laien gerichtet:

Luky S. schrieb:
> Wie kommuniziert das Gerät mit dem PC  Smartphone  Tablet / etc.?


Und dann das als Antwort: der

Luky S. schrieb:
> Hier muss man sich auch genau die Anforderungen überlegen. RS232 ist
> praktisch ausgestorben, für USB gibt es mehrere Möglichkeiten wie z.B.
> einen Mikrocontroller mit USB (für ein kommerzielles Produkt braucht man
> „offiziell“ eine USB ID…), einen der allseits bekannten Konverterchips
> (USB auf UART, SPI, I2C...) auf der Platine oder einen UART Pinheader in
> Kombination mit einem USB-Kabel mit integrierten Konverter). Ethernet
> ist schon aufgrund der galvanischen Trennung eine interessante Option,
> darf aber vom Aufwand her nicht unterschätzt werden. Kabellose
> Techniken, vor allem WLAN und Bluetooth Low Energy (BLE) finden immer
> weitere Verbreitung und haben sicherlich ihre Vorteile, man sollte die
> Sicherheit (im Sinne von Safety UND Security) aber nicht ganz
> vernachlässigen.

Das ist nichts anderes als eine Tube Senf darüber auszudrücken über 
Sachen die hier e schon jeder kennt.

Autor: Edi. M. (Firma: Industrie 1.0) (elektromeister)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Na, jetzt mach mal nicht so ein großes Fass auf. Er hat nur die groben 
Züge des Bussysteme erklärt.

Andererseits frage mich mich bei DEM opening schon auch, wie man Tipss 
fürs Systemdesign in eines HTML Seite packen möchte.

Bei uns füllt das ein Handbuch!

Autor: il Conte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Edi M. schrieb:
> Bei uns füllt das ein Handbuch!

Wahrscheinlich die Langform dessen was der TO im sein Opening zum besten 
gibt. ;-)

Autor: Ralf Döblitz (doeblitz)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
il Conte schrieb:
> Das ist nichts anderes als eine Tube Senf darüber auszudrücken über
> Sachen die hier e schon jeder kennt.

Jein. Für alle hier, die auch nur ein wenig Erfahrung haben, magst du 
wohl Recht haben.

Aber hier schneien immer wieder Leute rein, die eben keinerlei 
einschlägige Ausbildung haben und denen eben genau diese Fragen nocht 
bewußt sind. Für diese Anfänger ist es ganz gut, ihnen mal die ersten 
Fragen zu zeigen, die sie sich stellen sollten.

: Bearbeitet durch User
Autor: il Conte (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ralf D. schrieb:
> Aber hier schneien immer wieder Leute rein, die eben keinerlei
> einschlägige Ausbildung haben und denen eben genau diese Fragen nocht
> bewußt sind.

Da frag ich mich allen Ernstes was auf unseren FH's, Meisterschulen und 
UNIs so gelehrt wird:-(
Lehrlinge werden sich wohl
kaum für sowas interessieren.

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf D. schrieb:
> Für diese Anfänger ist es ganz gut, ihnen mal die ersten
> Fragen zu zeigen, die sie sich stellen sollten.

Ja aber leider hat es der Designtippgeber es nicht bei den 5 Fragen 
belassen, sondern in der Erläuterung eher die wenig gescheiten Repliken 
gegeben.

Und ob es wirklich die wichtigstenen 5 Fragen sind oder einfach nur 
etwas was nach vermeindlich gescheite Gliederung in einer 
Abschlussarbeit ausschaut, ist auch noch zu hinterfragen.
Sinnvoller ist ein System-Design nach System-Eigenschaften/ 
-Leistungsmerkmalen. Also wie designt man ein zuverlässiges System, ein 
billiges, ein stromsparendes, einen schnellen Prototypen, ein mit 
kleinen µC, ein abwärtskompatibles, ... .

Zum Vergleich mal ein Paper der ETH zum Theme "embedded System Design" : 
http://www.artist-embedded.org/docs/Events/2006/Ch...

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> @spess53 (Gast)
>
>>>Stimmt schon, das hat heute kein normaler Computer.
>
> Eben. Und auch keinerlei Konsumer-Produkt. Vielleicht noch ein paar
> alte, exotische Geräte oder Maschinensteuerungen. Aber auch dort schläft
> man nicht total, wenn gleich man nicht so hipp ist wie die Handies.

Naja es hat nix mit Schlafen zu tun, wenn man sich auf altbewährte 
simple Lösungen setzt, statt sich aus den falschen Gründen (galvanische 
Trennung) für "leicht" überdimensionierte Lösungen wie einen IP-Stack 
auf einem µC entschliesst nur weil es gerade en vogue ist vom Internet 
of Things zu fabulieren.
Und nicht selten findet sich auch auf IoT-Geräten versteckt eine RS232 
o.ä. Schnittstelle um auch aus das Gerät zugreifen zu können wenn sich 
der IP-Stack wiedermal verheddert hat.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bitwurschtler (Gast)

>> Eben. Und auch keinerlei Konsumer-Produkt. Vielleicht noch ein paar
>> alte, exotische Geräte oder Maschinensteuerungen. Aber auch dort schläft
>> man nicht total, wenn gleich man nicht so hipp ist wie die Handies.

>Naja es hat nix mit Schlafen zu tun, wenn man sich auf altbewährte
>simple Lösungen setzt, statt sich aus den falschen Gründen (galvanische
>Trennung) für "leicht" überdimensionierte Lösungen wie einen IP-Stack
>auf einem µC entschliesst nur weil es gerade en vogue ist vom Internet
>of Things zu fabulieren.

Das weißt du doch gar nicht, denn der OP schrieb allgemein und nicht auf 
ein spezielles Produkt bezogen.

>Und nicht selten findet sich auch auf IoT-Geräten versteckt eine RS232
>o.ä. Schnittstelle um auch aus das Gerät zugreifen zu können wenn sich
>der IP-Stack wiedermal verheddert hat.

RS232 wird in virtueller Form über USB noch sehr lange leben, als 
Qick&Dirty Debugschnitstelle an einem uC als CMOS sowieso. Aber "echtes" 
RS232 mit seinen Steckern und Pegeln am Gerät hat in der Masse 
ausgedient. Ausnahmen bestätigen die Regel.

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Falk B. schrieb:
> RS232 wird in virtueller Form über USB noch sehr lange leben, als
> Qick&Dirty Debugschnitstelle an einem uC als CMOS sowieso. Aber "echtes"
> RS232 mit seinen Steckern und Pegeln am Gerät hat in der Masse
> ausgedient. Ausnahmen bestätigen die Regel.

Volle Zustimmung,
nur was heute als RS232 bezeichnet wird hat ausser getrennte Leitungen 
für TxD und RxD und dem Übertragungsprinzip konstante Bitlänge wenig mit 
dem +/- (15..3)V RS232 gemein wird aber trotzden als RS232 bezeichnet.
Und das ist noch lange nicht ausgestorben, weil es eben erheblich 
leichter zu implementieren als USB oder gar ein IP-Stack. Gerade bei 
"kleinen" µC Anwendungen wie Multimeter, Kaffemaschinen, 
Arduino-Prototypen die mit PunktzuPunkt abhandelbar sind die 
vorgeschlagenen Alternativen mehr Implementierungsaufwand als die 
eigentliche Applikation (Gelegentlich AD-Wert übertragen, Motore on/Off; 
I2C, SPI bedienen)
Und ich glaube in den Designtipps war nicht das RS232 über 25poligen 
Stecker der 60er Jahre gemeint, sondern ein dummes TxD/RxD-Protokoll was 
man schnell "per Hand" dekodieren kann.

>>Naja es hat nix mit Schlafen zu tun, wenn man sich auf altbewährte
>>simple Lösungen setzt, statt sich aus den falschen Gründen (galvanische
>>Trennung) für "leicht" überdimensionierte Lösungen wie einen IP-Stack
>>auf einem µC entschliesst nur weil es gerade en vogue ist vom Internet
>>of Things zu fabulieren.

>Das weißt du doch gar nicht, denn der OP schrieb allgemein und nicht auf
>ein spezielles Produkt bezogen.

??Egal um welches Produkt es geht, eine galvanische Trennung ist nicht 
an Ethernet mit seinem Overkill-Protokoll gebunden, galvanische Trennung 
kann man für jede Schnittstelle erreichen, auch für 232 
https://www.maximintegrated.com/en/products/interf...

Autor: Sapperlot W. (jetztnicht)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
RS232 wird es noch sehr lange geben. Speziell bei IoT. Denn man man kann 
es entgegen Ethernet sehr sparsam betreiben.  Ein nicht grad veralteter 
RS232 Treiber zieht vielleicht 200uA, bei Ethernet bin ich beim 1000 
fachen. Ich wuerd erst fuer bewegte Bilder auf ethernet gehen, und 
untendran auf RS232 bleiben. Allenfalls kann man auch etwas RS485 
basiertes Nehmen, wenn's in einer industriellen Umgebung, und grossen 
Laengen laufen muss.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sapperlot W. (jetztnicht)

>RS232 wird es noch sehr lange geben. Speziell bei IoT.

Wirklich? Wo gibt es denn so viele RS232-IP Gateways?

Unabhängig vom Sinn diverser IoT Geräte, nutzt man bei IoT 
sinnvollerweise schon einen fertigen uC mit IP Stack, z.B. die aktuellen 
ESPxxx. Da haben sich viele Leute schon viele Gedanken gemacht und man 
kann einfach und sparsam ins Internet. Das nachträglich über RS232 
hinzufrickeln wird nicht besser.

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> @Sapperlot W. (jetztnicht)
>
>>RS232 wird es noch sehr lange geben. Speziell bei IoT.
>
> Wirklich? Wo gibt es denn so viele RS232-IP Gateways?
>
> Unabhängig vom Sinn diverser IoT Geräte, nutzt man bei IoT
> sinnvollerweise schon einen fertigen uC mit IP Stack, z.B. die aktuellen
> ESPxxx. Da haben sich viele Leute schon viele Gedanken gemacht und man
> kann einfach und sparsam ins Internet. Das nachträglich über RS232
> hinzufrickeln wird nicht besser.

als für den ESP8266 steht bei 
https://www.mikrocontroller.net/articles/ESP8266
schon was von RS232, zumindest steht da das der einen UART was IMHO 
synonym ist (wenn man nicht nach den klassischen RS232 Pegel verlangt) 
mitbringt. Siehe auch: https://www.pgollor.de/cms/?p=1848

Autor: Falk Brunner (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@Bitwurschtler (Gast)

>> Unabhängig vom Sinn diverser IoT Geräte, nutzt man bei IoT
>> sinnvollerweise schon einen fertigen uC mit IP Stack, z.B. die aktuellen
>> ESPxxx. Da haben sich viele Leute schon viele Gedanken gemacht und man
>> kann einfach und sparsam ins Internet. Das nachträglich über RS232
>> hinzufrickeln wird nicht besser.

>als für den ESP8266 steht bei
>https://www.mikrocontroller.net/articles/ESP8266
>schon was von RS232, zumindest steht da das der einen UART was IMHO
>synonym ist

Mein Gott, kannst oder willst du mich nicht verstehen?
Zeig mit mal das Gerät, wo man per RS232 ins Internet kommt!
Darum geht es! Wenn ich ein IoT baue, will ich das DIREKT in Netz 
bekommen, sei es per WLAN, LAN oder 3G. Da geht keiner den Umweg über 
RS232.

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Mein Gott, kannst oder willst du mich nicht verstehen?
> Zeig mit mal das Gerät, wo man per RS232 ins Internet kommt!
> Darum geht es!

Nö, darum geht es nicht. Es geht bei dem Tipp darum wie man das zu 
entwerfende Gerät am besten mit dem PC verbindet
"Wie kommuniziert das Gerät mit dem PC  Smartphone  Tablet / etc."

und nicht mit dem Internet. Und für eine Punkt zu Punkt zu Verbindung 
aka Gerät zu PC  Smartphone  Tablet Verbindung wie oben in den Tipps 
erwahnt ist Ethernet und andere Netzprotokolle Overkill.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Bitwurschtler (Gast)

>> Mein Gott, kannst oder willst du mich nicht verstehen?
>> Zeig mit mal das Gerät, wo man per RS232 ins Internet kommt!
>> Darum geht es!

>Nö, darum geht es nicht. Es geht bei dem Tipp darum wie man das zu
>entwerfende Gerät am besten mit dem PC verbindet
>"Wie kommuniziert das Gerät mit dem PC  Smartphone  Tablet / etc."

>und nicht mit dem Internet.

Tja, hier liegt das Mißverständnis. Der OP sprach von PC-Gerät, 
sapperlot von IoT.

Beitrag "Re: Hardware-Designtipps des Monats: Das Systemdesign"

Und auch genau DARAUF bezog sich meine Antwort. IoT!

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:
> Und auch genau DARAUF bezog sich meine Antwort. IoT!

Hm, ist halt ne Frage was man als Ding im Netzwerk versteht, ein 
Netzwerk aus batteriegetriebenen oder energy Harvesting Sensoren wird 
man wohl erst über einen Sensor-Hub/knoten ins Netzwerk bringen. Wenn es 
um batteriegetriebenen Geräte geht neige ich schon eher zu sapperlot mit 
P2P verbindung über BT o.ä.

Wenn IoT dagegen erst bei Amazon Echo, Kühlschrank und anderen 
komplexeren und insbesonders Netzbetriebenen Geräten anfängt, dann kann 
man natürlich auch das volle Protokoll fahren.

Autor: Ralf Döblitz (doeblitz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitwurschtler schrieb:
> Falk B. schrieb:
>> Und auch genau DARAUF bezog sich meine Antwort. IoT!
>
> Hm, ist halt ne Frage was man als Ding im Netzwerk versteht,

Ahemm, es heißt Internet of Things, d.h. das Zeug ist nicht irgendiwe in 
irgendeinem Netz, sondern es ist über Internet erreichbar - ansonsten 
hats du irgendwas, aber nicht IoT.

> ein
> Netzwerk aus batteriegetriebenen oder energy Harvesting Sensoren wird
> man wohl erst über einen Sensor-Hub/knoten ins Netzwerk bringen. Wenn es
> um batteriegetriebenen Geräte geht neige ich schon eher zu sapperlot mit
> P2P verbindung über BT o.ä.

Da ist dann die IoT-Komponente aber der Hub, der für die Verbindugn der 
Sensoren ins Internet sorgt und nicht die einzelnen Sensoreinheiten, die 
keine Internetanbindung haben.

> Wenn IoT dagegen erst bei Amazon Echo, Kühlschrank und anderen
> komplexeren und insbesonders Netzbetriebenen Geräten anfängt, dann kann
> man natürlich auch das volle Protokoll fahren.

Ebent. Und dafür gibt es heute z.B. mit den ESPs schon nette Controller, 
die (fast) den ganzen Kram mitbringen, die nur als 
seriell<->Internet-Wandler zu verwenden (z.B. um einen Arduino via WLAN 
mit dem Internet zu verbinden) ist Verschwendung, die können viele 
Steuerungsanwendungen auch selbst fahren.

Autor: Peterchen Puter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klassisch sind doch Aufbauten, wo mehrere Mikrocontrollersysteme über 
eine Schnittstelle wie RS486 mit einem zentralen (Embedded-)PC verbunden 
sind, der dann Daten loggt, verarbeitet, vielleicht in eine SQL Tabelle 
schreibt und auf irgendeinen Server im Internet hochläd.

Im Systemdesign entwirft man ja typischerweise nicht den PC, der über 
TCP/IP mit dem Internet kommuniziert, sondern das Netzwerk aus 
Mikrocontrollersystemen. Beispielsweise zum Auslesen von Sensoren an 
verschiedenen Stellen in einem Gebäude und zum ansteuern von Aktoren.

Und z.B. RS485 hat für diesen Zweck dann große Vorteile: Bussystem mit 2 
Adern bis 1200m Leitungslänge, einfach umzusetzen, wenig anfällig auf 
elektromagnetische Störungen. Ethernet scheidet da allein aufgrund der 
stark eingegrenzten Länge von den entsprechenden Kupferverlegekabeln 
(max. 100m bis zum nächsten Switch, die dann auch nicht beliebig 
kaskadiert werden dürfen) und der komplizierten Infrastruktur aus.

Und Bluetooth / WLAN ist oft schon aufgrund der Zuverlässigkeit 
schwierig.

RS232 ist wohl veraltet... aber die moderneren Versionen dieser 
seriellen Schnittstelle und die entsprechenden Protokolle sind doch DIE 
wichtigen Werkzeuge zur Kommunikation in diesem Bereich.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also auch finde das diese "Tipps" nicht wirklich praktisch nutzbar sind, 
so undetailiert wie es jetzt niedergeschrieben ist, taugt es bestenfall 
als grobes Konzept was ein "HowTo Systemdesign" umfassen könnte. Fangen 
wir mal mit dem obersten Punkt an:


Luky S. schrieb:
> [[Image:header_block1.png|left|thumb|125px]]

> * Was erledigt man besser in Hardware und was effektiver in Software?
> Die Beantwortung dieser Frage hängt in erster Linie von den vorhandenen
> Ressourcen, der möglichen Entwicklungszeit, den Kosten pro Gerät bzw.
> den (umgelegten) Entwicklungskosten, der technischen Machbarkeit und von
> der Erfahrung / Spezialisierung ab. Allgemein gültige Aussagen sind hier
> sehr schwierig zu treffen, da oft eine kleine Schaltung einen enormen
> Softwareaufwand einsparen kann, aber auch umgekehrt ein paar Zeilen
> Quellcode die Hardware massiv vereinfachen können. Ein gutes Beispiel
> sind Filterschaltungen.

Die Frage stellt sich so formuliert (Hard- oder Software)  bei den 
meisten Forumsprojekten nicht, da wird eine Hardware ausgesucht 
(Mikrocontroller mit passenden Peripherals) und dann ist klar das die 
Applikation als Programm realisiert wird. Auch ist die Aufteilung ob 
hard-wired Logic oder Software nicht das Problem sondern die Auswahl der 
Hardwarecomponenten oder peripherals. Und bevor man daran geht das "was" 
zu verteilen, muss das "was" klar definiert sein. Meine Sicht auf dieser 
Phase des Systemdesigns wäre also:
*Zuordnung Funktion zur ausführenden Einheit
**Auflistung aller Funktionen der Anwendung mit Performanceangaben
**Auflistung möglicher Realisierungen mit Aufwand-abschätzung und 
Performance
**Entscheidung für jeden aufgelistete Funktion und
**Zusammenführun der Teillösungen zur Gesamtarchitektur

Beispiel: Positionierung einer Masse auf einer Gewindespindel:
-Funktionen:
*Antrieb (mechanische Energie aus elektrischer)
*Stellglieder Antrieb (AN/Aus)
*Positionsbestimmung
*Sicherheitsüberwachung (Überhitzung, Überschreiten mech. Anschläge)
*AnSteuerung (verknüpfung Stellglieder, Positionsbestimmung und 
Sollwertvorgabe)
*Sollwervorgabe

-Realisierungsmöglichkeiten:
Antrieb:
*DCMotor (billig,schnell, kräftiger,inherend unpräzise)
*Stepper (langsam,präzise)
Stellglied Antrieb (ich spar mir im weiteren die Performanceangaben)
 *SePerate H-Brücken, FET-Schalter, in controller integrierte Stufen
Positionsbestimmung
-Nutzung der inherenten Positionierung des Antriebs (Stepper - open 
loop)
-Referenzfahrt über Endlagenschalter(i.e. Lichtschranke, induktiv) und 
betimmung Zeit-Weg Relation
-mitschleifendes Poti
-absolutencoder unter der Spindel
-inkrementalencoder als Motoroption Variante optisch, magnetisch
Sicherheitsüberwachung:
-Temperatursensor(en) an Motor, Motorsteuerung, ..
-Strommessung, Sicherung, kein Strommessung nötig da robuste Auslegung
-Endlageschalter, Keine Endlagenabschaltung nötig da robuste Auslegung 
(Aufprallfedern)
Ansteuerung:
-FPGA
-uC  (mit/ohne PWM; interner ADU,...)
-FPGA-SoC
-externe ADU (Samplerate, genauigkeit, etc
-Arduino mit Shields
-PC mit Labview und IO-Karten
Sollwertvorgabe:
 spar ich mir hier, respektive wird im Punkt schnittstelle behandelt

Die Schritte Entscheidung über Teillösungen und Zusammenführung zur 
Architektur spar ich mir ebenfalls an diesem Beispiel.

Wie man am Beispiel sieht bedeutet hier Hardwareauswahl nicht allein 
Auswahl elektrischer Hardware, viele Funktion können auch mechanisch 
gelöst werden oder das System so ausgelegt werden das sie unnötig sind 
wie bei der Verwendung von Steppermotoren die Realisierung einer 
Positionbestimmung u.U. unnötig ist. Und in diesem Beispiel ist die m.E. 
einzige Stelle wo sich die Frage nach Hard- oder Software stellt, die ob 
man das PWM-modul eines uC nutzt (Hardware) oder die Zeitsteuerung in 
Software macht.

Wichtige Kriterien der Auswahl sind neben den genannten Verfügbarkeit, 
Entwicklungsaufwand und -Kosten:
 *Zuverlässigkeit über Umweltbedingungen (Tageslicht - Lichtschranke)
 *Performance (hier Positionierungsgenauigkeit,-geschwindigkeit),
 *Wartbarkeit (regelmäßige Kontrolle der Position der Endlageschalter)
 *Kontrollierbarkeit(hat der User immer Info über die korrekte Funktion, 
hier ist die Position erreicht worden)

So etwa koennte meines Erachtens die ersten Schritte des Systemdesigns 
(Systempartionierung, Funktion - Resourcen-Mapping) aussehen. Ich hoffe 
das kömmt nicht so "Senfig" und oberflächlich rüber wie der sog. "Tipp" 
oben.

Autor: spess53 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hi

>Und z.B. RS485 hat für diesen Zweck dann große Vorteile: Bussystem mit 2
>Adern bis 1200m Leitungslänge, ...

Du hast da praktische Erfahrungen? Oder ist das nur Hörensagen 
deinerseits?

Nur mal ein kurzer Auszug aus

AN-1057 Ten Ways to Bulletproof RS-485 Interfaces von TI
(http://www.ti.com/analog/docs/litabsmultiplefileli...

A typical mistake is to connect two nodes with only two wires.

MfG Spess

Autor: Falk Brunner (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@ spess53 (Gast)

>AN-1057 Ten Ways to Bulletproof RS-485 Interfaces von TI
>(http://www.ti.com/analog/docs/litabsmultiplefileli...

>A typical mistake is to connect two nodes with only two wires.

Das Thema hatten wir schon mal ausführlich. Ergebnis: 2 Ader 
funktionieren praktisch, wenn gleich es nicht empfohlen ist.

Beitrag "Kein GND auf RS485"

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
spess53 schrieb:

>>Und z.B. RS485 hat für diesen Zweck dann große Vorteile: Bussystem mit 2
>>Adern bis 1200m Leitungslänge, ...
>
> Du hast da praktische Erfahrungen? Oder ist das nur Hörensagen
> deinerseits?
>
> Nur mal ein kurzer Auszug aus
>
> AN-1057 Ten Ways to Bulletproof RS-485 Interfaces von TI
> 
(http://www.ti.com/analog/docs/litabsmultiplefileli...
>
> A typical mistake is to connect two nodes with only two wires.

Weiterlesen ...
Da geht es nur darum das ne ungeschirmte Zweidrahtleitung abstrahlt. 
Wenn die Leitung in einem blechernenen Kabelkanal verlegt ist, ist das 
nicht unbedingt problematisch. Verdrillen hilft auch schon mal, oder man 
nimmt geschirmte Leitung. Das ist dann immer noch noch ne 
zweidrahtleitung, die bis 1200m funzt. Steht so in dem von dir zitierten 
AN.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ C. A. Rotwang (Gast)

>Weiterlesen ...
>Da geht es nur darum das ne ungeschirmte Zweidrahtleitung abstrahlt.
>Wenn die Leitung in einem blechernenen Kabelkanal verlegt ist, ist das
>nicht unbedingt problematisch.

Grundlagen mein Lieber. Bei Gleichtaktstörungen/Abstahlungen hilft der 
Schirm an der Stelle wenig bis gar nicht, er kann sogar selber zu 
Antenne werden!

Autor: il Conte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Ich hoffe das kömmt nicht so "Senfig" und oberflächlich rüber wie der
> sog. "Tipp" oben.

O je,o je.
Wenn ich mir deine Ausführungen so durchlese, stelle ich mir analog dazu 
einen schwäbischen Häuslebauer vor,  der sich vor laute 'Gedanken' die 
er sich macht, Angst bekommt anfangen zu muessen weil er was falsch 
machen könnte.

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
il Conte schrieb:
> schwäbischen Häuslebauer vor,  der sich vor laute 'Gedanken' die
> er sich macht, Angst bekommt anfangen zu muessen weil er was falsch
> machen könnte

Na da kennste aber die falschen Schwaben, die die ich kenne sind schon 
Zupacker. Die machen sich auch am Anfang Gedanken, aber nicht aus Angst 
etwas falsch zu machen sondern aus Vorsicht mehr Aufwand/Kosten zu 
generieren als nötig.

Bei Hasenfüßigen Bedenkträger die aus Angst etwas falsch zu machen und 
statt einen mörderischen Anschiß von Boß zu riskieren lieber nichts 
machen, sondern nur abnicken, abwarten und hinten rum jammern, denkt man 
eher an andere Landesteile. Tipp: auch da wird kein Hochdeutsch 
gesprochen.

Autor: Schreiber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitwurschtler schrieb:
> ??Egal um welches Produkt es geht, eine galvanische Trennung ist nicht
> an Ethernet mit seinem Overkill-Protokoll gebunden, galvanische Trennung
> kann man für jede Schnittstelle erreichen, auch für 232
> https://www.maximintegrated.com/en/products/interf...

Mit 2 Optokopplern und etwas Hühnerfutter geht das noch billiger und mit 
einer höheren Isolationsspannung.
Zusammen mit einem Seriell-USB-Wandler hat man dann auch keine Probleme 
mit der Stromversorgung.
Das ganze ermöglicht Geräte mit USB-Schnittstelle (für 
Datenübertragung/debuggen) und Kondensatornetzteil.

Mit etwas Kreativität kann man meist sogar die Stromversorgung für den 
Optokoppler aus der seriellen Schnittstelle (egal ob echtes RS232 oder 
5V-TTL-Pegel) ziehen (nicht 100% Normgerecht). Billiger geht es wirklich 
nicht.

Autor: nein, ist es nicht! (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ethernet hat keine galvanische Trennung.

Autor: Falk Brunner (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@nein, ist es nicht! (Gast)

>Ethernet hat keine galvanische Trennung.

Ach nein? Und wozu sind dann auf jeder Seite Übertrager drin?

Autor: nein, ist es nicht! (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Die Fähigkeit, zwischen einer symmetrischen Datenverbindung und einer 
galvanischen Trennung zu unterscheiden kann den Unterschied zwischen 
Leben und Tod bedeuten.

Beispiel:

Falk Brunner jun. möchte an einer Motorsteuerung mit seinem Ozsi eine 
erdfreie Messung vornehmen. Das man den Schutzleiter nicht einfach 
trennen sollte, ist ihm bekannt. Er trifft alle Vorsichtsmassnahmen und 
die Messungen gelingen. Nun möchte Falk Brunner jun. Screenshots der 
tollen Messungen anfertigen, verbindet Oszi und PC mit einem 
Ethernetkabel und startet die Messung erneut. Rate mal, was passiert.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.