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.
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;-)
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.
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
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?
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.
@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.
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-
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
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.
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!
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.
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.
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/ChinaSchool/1_ESIntroduction.pdf
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.
@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.
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/interface/transceivers/MAX250.html
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.
@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.
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
@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.
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.
@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!
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.
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.
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.
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.
@ 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"
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/litabsmultiplefilelist.tsp?literatureNumber=snla049b&docCategoryId=1&familyId=361&keyMatch=Ten%20Ways%20to%20Bulletproof%20RS-485%20Interfaces&tisearch=Search-EN-Everything):
>> 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.
@ 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!
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.
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.
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/interface/transceivers/MAX250.html
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.
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.
Vorausgesetzt die Spannungen sind nicht so hoch daß die Isolation der
Übertrager durchschlagen wird, also intakt bleibt, ist es hilfreich zu
wissen wo die Schirmung anfängt und endet.
Irgendwie haben wir hier inen Tunnelblick. Kommunikation ist nur ein
Teilthema.
Da ist RS-232 für den "Privatanwender" gemessen an der Vergangenheit nur
noch von geringer Bedeutung. Geräteintern und bei Service und
Entwicklung haben derartige Schnittstellen durchaus noch ihre
Berechtigung. Wenn so etwas bei IoT-Geräten vorhanden ist, heißt es
nicht, daß man darüber zwangsläufig ins Internet kann, sondern einfach
nur, daß so eine Schnittstelle vorhanden ist, für welche zwecke auch
immer. Manchmal sind manche Funktionen und Zugänge bewußt nicht auf der
"öffentlichen" Schnittstlle. Bei der Serviceschnittstelle braucht man
dann nicht immer Internet.
Thread beobachten
Seitenaufteilung abschalten