Elektronik mit digitalen und analogen I/O und Display u.ä.

**Matze**

Langfristig gesehen könnte ich mir vorstellen, dass bei meinem Arbeitgeber einzusetzen, aber das weiß ich noch nicht.

Klar könnte ich das mit einer SPS lösen, aber ein eigenständiges Gerät, dem ich per SPS dann einen Start gebe etc. ist sinnvoller. So kann sich die SPS um den Automatikbetrieb der Anlage kümmern und mein Gerät z.B. über die serielle Schnittstelle ansteuern.

Zu teuer soll das nicht sein.
Ich dachte so an ca. 200€, falls das realistisch ist. (80€ Display, 20€ MC, 20€ Tastatur und dann noch die ICs und sonstige Kleinteile). Aber vielleicht ist meine Preisvorstellung auch komplett daneben.
Nur dann wird es schwer, das privat zu finanzieren, da ich nicht weiß, ob das überhaupt alles klappt. Und da wäre es schade ums Geld (ja, ich bin Schwabe *g*).

Ob ich das industriell einsetzen werde steht momentan noch nicht fest. Das ist mehr eine Art Voruntersuchung auf privater Basis mit dem Nebeneffekt, dass ich was dazu lerne.

Vielleicht gibt's auch eine Art Linux-Controller, über den man das lösen kann. Nur ein richtiger Industrie-PC wäre zu teuer.

Hm, ein leistungsfähiger Microcontroller ist in der Regel ein empfindliches SMD-Bauteil. Eine Platine dafür baut ein Laie sicher nicht mal einfach so.

Und an ein Demoboard müsste man noch die zusätzliche Hardware dranbauen und die Abmessungen sind sicher nicht so, wie man sie haben will.

Und mit solchen Boards hier kommt man sicher auch in den Preisbereich einer SPS:

http://www.phytec.de/de/produkte.html

**Alloc**

Hi Matthias,

ein paar Gedanken zu dem Ganzen:
- Wenn die externen Anschlüsse aus dem Gerät herausgehen sollten diese definitiv gut geschützt sein. Sprich Aus/Eingänge galvanisch entkoppelt, zB über Optokoppler oder bei den digitalen Ausgängen Relais (alles auch eine Frage der Verwendung der IOs). Die Trenner und eventuelle ICs auf externer Seite bieten sich (wenn der Platz vorhanden ist) in einer sockelbaren Bauform an, dadurch kann man, wenn wirklich mal was zerschossen wird, die betroffenen Teile leicht tauschen.
- Digitale Aus/Eingänge sind davon abgesehen natürlich kein Problem
- Stromaus/eingänge sollten mit externen ICs auch realisierbar sein, für galvanische Trennung würde sich hier etwas mit digitaler Schnittstelle anbieten, die kann man dann meist recht gut galvanisch trennen.
- Festspeicher: Billigstes bei >1 MB dürfte wohl fast ne SD-Karte sein, die kosten ja quasi nix und das prinzipielle Ansteuern ist über SPI auch nicht weiter problematisch. Nur wenn man dann noch ein Dateisystem nutzen wollen würde bräuchte man auch hier wieder nen Stück mehr an Rechnerleistung.
- RS232 bekommt man eigentlich immer
- Ethernet ist schon von der Rechnerleistung wieder nen gutes Stück aufwändiger, wenn man keine Controller mit internem Protokollhandling für wenigstens Ethernet+IP+UDP oder TCP (oder beides) nutzt, aber auch realisierbar. (ohne Protokolle zB einfach den Microchip ENC28J60, mit Protokollen gibt es diverses).
- USB als Host wird dann wieder nen großer Brocken. Da musst du ja einiges an Protokollen unterstützen, oder eben wiederum einen Host-Controller, der geeignete Protokolle mitbringt (glaub der FTDI Vinculum kann sowas zb, soweit ich das noch im Kopf habe).
- Display mit 80*4/5? Kenn ich als Alpha-Numerisches Display gar nicht (was das 4/5 Zeilen ja impliziert (zumindest in meinen Augen

) ), da wohl eher nen vollgraphisches. Da bekommt man aber meist eher so 128x64, also 21*8 Zeichen. 256x64 wären immerhin 42*8 Zeichen. Aber gerade Displays gehen auch schnell in die Kosten.
- Folientastaturen sind kein Problem, man muss nur eine passende finden

- 50 Hz Verarbeitungsrate für alles? Könnte eng werden, insbesondere mit den Skripten.

- Komponenten die man in ein paar Jahren noch bekommt: Auch die Elektronik wird immer kurzlebiger, solange man nicht echte Industrieteile verwendet. Also ATmegas zB bekommt man in 10 Jahren wohl nur noch pinkompatible, in 20 sicher gar keine kompatiblen mehr

- Skripte im Controller: Da gäbe es zwei Möglichkeiten: Interpreter auf dem Controller: Von der Technik her überall realisierbar, allerdings langsam und braucht auch entsprechend Speicher. Alternativ "Compiler" (für die genutzte Skriptsprache) auf dem uC: Wesentlich bessere Performanz, allerdings solltest du in dem Fall darauf achten, dass du einen Controller hast, der keinen getrennten Code/Daten-Adressraum hat, damit du die Skripte aus dem RAM ausführen kannst. Sonst musst du nach jeder Parameteränderung selber neu flashen, was dann Speicherplatzmäßig auch wieder eng wird.

Controller die ich mal als Empfehlung in den Raum werfen könnte, da gutes Stück leistungsfähiger aber auch nicht viel teurer als nen AVR8: Fujitsu 16FX. 16 bitter, je nach Ausführung viel Flash/RAM, viele IOs und Schnittstellen, Programmierung und On-Chip-Debugging über USART (also zB auch über nen FTDI-Chip, ich selber hab das mal so realisiert dass ich über nen FT2232H einen Kanal Daten normal austausche und den zweiten Kanal für Programming/Debugging nutze). Die gibt es sicher auch noch ne ganze Weile.

Grüße,
Chris

PS: Linux-"fähige" Mikrocontroller gibts natürlich auch. Mehr oder weniger jedes lesitungsfähige Kleingerät hat sowas ja heutzutage (zB Router, Access-Points, NAS, Handhelds ...). Die sind aber vom Schaltungsaufbau her wesentlich komplexer. Beispiele: AVR32, ARM, Marvell ...

Zitat von Alloc:

PS: Linux-"fähige" Mikrocontroller gibts natürlich auch.

Ja, mein Link auf Phytec war ja sowas.

Zitat von Alloc:

Die sind aber vom Schaltungsaufbau her wesentlich komplexer. Beispiele: AVR32, ARM, Marvell ...

Ich arbeite gerade mit einem Embedded Rechner mit einem Renesas SH7780 (32 Bit, 400 MHz, 128 MB Ram), da wäre das mit dem Scripting kein Problem, nur das mit den 200 Euro passt nicht.

**Matze**

Vielen Dank für die Antworten.

Boah das klingt ganz schön heftig. Auf Ethernet und USB kann ich auch vorerst mal verzichten. Es wäre nur schön, wenn es nachträglich realisiert werden könnte (ohne alles über den Haufen zu werfen).
Und stimmt, das Display könnte auch ein Vollgrafisches sein und nur für alphanumerische Zeichen verwendet wird.

Dass 50 Hz eng werden ist schlecht. Wenn ich an einige Messkarten denke, die 300€ kosten, aber mit 200 kHz Daten erfassen und digital filtern können, müsste das doch in dem günstigen Preissegment mit 50 Hz gehen.

Ich mache mir heute ein paar Gedanken zu dem Vorhaben. Vielleicht ist das auch zu komplex, wobei es eine nette Herausforderun wäre ...

Erst gestern habe ich gelesen, dass man sich für 200€ einen Quadrocopter bauen kann (inkl. 4 Motoren + Motorregler, gyro etc). Und dagegen ist meines eine eher "einfache" Anwendung.

**Alloc**

Naja, die 50 Hz an sich sind sicher in dem Preissegment machbar. Aber der konkret genannte µC ATmega32 (bzw. generell die AVR8) sind halt mit deinen Anforderungen zumindest nach meiner Einschätzung überfordert, *insbesondere* durch die Skript-Sache. Ohne dies wäre es sicher locker machbar

Nachträgliches anbringen von USB/Ethernet etc ist natürlich machbar, dann muss man dies aber dennoch vorab schon relativ konkret einplanen, damit man die entsprechenden Schnittstellen rausführt und nicht später feststellt, dass man für die parallele Busanbindung des Ethernetcontrollers ja noch die IOs 33-48 vom µC bräuchte (alles Beispielhaft)

Grüße,
Chris

**jfheins**

Zitat von Matze:

Vielen Dank für die Antworten.
Boah das klingt ganz schön heftig. Auf Ethernet und USB kann ich auch vorerst mal verzichten. Es wäre nur schön, wenn es nachträglich realisiert werden könnte (ohne alles über den Haufen zu werfen).

Dann kannst du es auch direkt einbauen statt nur die Möglichkeit dafür vorzuhalten

Wenn du z.B. die COM-Ports nicht magst, kannst du auch einen USB-zu-RS232 Chip auf die Platine löten, dann ists nach außen hin ein schicker Mini-USB Port - nur am PC wird dann spezielle Software nötig, um zu kommunizieren. (z.B. HyperTerminal, irgendwas was mit inem COM Port kommunizieren kann)

Zitat:

Dass 50 Hz eng werden ist schlecht. Wenn ich an einige Messkarten denke, die 300€ kosten, aber mit 200 kHz Daten erfassen und digital filtern können, müsste das doch in dem günstigen Preissegment mit 50 Hz gehen.

Diese Messkarten haben auch nur einen speziellen Einsatzzweck, auf den sie optimiert wurden. Du möchtest ja aber so eine Art Interpreter da rein integrieren:

Zitat:

Später möchte ich Abläufe über die Tastatur und das Display eingeben können. Also etwas wie "Ausgang x auf 10 mA setzen, warten bis der Eingang y auf 15 mA steigt, dann digitale Ausgänge a, b und c schalten ...". Diese müssen gespeichert und wieder geladen werden können.

Das ist einfach mehr Rechenaufwand als 200000 mal in der Sekunde einen Wert zu wandeln und abzuspeichern. (A/D Wandler sind bei viele Mikrocontrollern ja schon auf dem Chip integriert)

Idee:
Wenn du den Anschluss der zum flashen des µC verwendet wird, rausführst kannst du das Skript am PC zu Quellcode verarbeiten, den Quellcode dann mit dem avr-gcc (oder so) kompilieren und das Ergebnis flashen

Die Kompilate ließen sich dann auch am PC verwalten und jederzeit wieder auf den µC aufspielen.
Dann brauchst du aber noch einen PC in der Nähe

**Alloc**

Zitat von Matze:

Boah das klingt ganz schön heftig. Auf Ethernet und USB kann ich auch vorerst mal verzichten. Es wäre nur schön, wenn es nachträglich realisiert werden könnte (ohne alles über den Haufen zu werfen).

Achja, gäbe natürlich noch nen Mittelweg: Schaltung konkret auf bestimmte Bauteile für diese Aufgaben Auslegen, aber die Bauteile auf der Platine erst mal noch nicht bestücken. Oder zwar bestücken, aber noch nicht nutzen

**Matze**

Kurz zu der Skriptsprache:
Vielleicht geht das auch anders.

Ein einfacheres Beispiel wäre ein Akkuladegerät. Bei den besseren kann man verschiedene Akku-Programme anlegen (NiMH, LiPo, LiIo, ...). Zu jedem Akku kann man Daten wie die Zellenanzahl, Kapazität etc. einstellen und entsprechend wird das Ladeprogramm gestaltet.

D.h. es gibt ein paar Parameter, die als Programm anzuspeichern sind. Diese müssen natürlich auch wieder geladen (interpretiert) werden können.
Mit einer Skriptsprache geht das sicher, aber vielleicht geht's auch anders.

**Alloc**

Zitat von Matze:

Ein einfacheres Beispiel wäre ein Akkuladegerät. Bei den besseren kann man verschiedene Akku-Programme anlegen (NiMH, LiPo, LiIo, ...). Zu jedem Akku kann man Daten wie die Zellenanzahl, Kapazität etc. einstellen und entsprechend wird das Ladeprogramm gestaltet.

Naja, hier wird halt kein Programm verändert. Das Ladegerät hat hier fest einprogrammierte Programme, du änderst lediglich einzelne Parameter, die dann zB die Variable "Vout" oder so ändern würden, damit das Programm die Ausgangsspannung der Zellenzahl anpasst. Das ändert aber nichts am eigentlichen Programm.