Hallo zusammen, ich suche Mitstreiter bzw. Projektpartner. Für Bastelprojekte mit Mikrocontrollern gibt es viele gute Ausgangsbasen (Andrunio, C-Control, Open-Micro, Raspberry-Pi usw.). Alle Systeme haben Vor- und Nachteile. Ich persönlich habe mich in meinem aktuellen Projekt Ultimatives Aquariumsteuergerät für das MSP430 LaunchPad entschieden. Ich möchte aus den 5 bis 10 Euro das Maximum herausholen. Gerade war ich dabei, bei Digikey I²C-Bus-Expander heraus zu suchen. Es gibt in dem Bereich feine Sachen, z.B. den SX1506 für ca. 0,80€ mit 16 GPIOs und Bit-maskierbaren Interrupts, wahlweise auf der steigenden oder der fallenden Flanke. Andererseits sind dem LaunchPad zwei Prozessoren beigefügt. Statt solcher I²C-Bus-Expander kann man also auch den zweiten Prozessor nutzen. Auch im Nachkauf sind die MSP430-Controller kaum teurer als ein I²C-Bus-Expander, sie sind aber deutlich flexibler. Beide Prozessoren können sich z.B. über I²C unterhalten, gern auch im Multi-Master-Mode. Ziel des Projektes wäre - auf den ersten Blick - Bibliotheken zu entwickeln, damit man Multi-Prozessor-Systeme mit diesen beiden Prozessoren effektiv in C entwickeln kann. Aktuell bin ich dabei, für das o.g. Projekt einen HAL (Hardware- Abstraction-Layer) und einen Service-Layer und natürlich die Applikation zu programmieren. Im HAL ist aktuell eine (Interrupt-)-Flag-gesteuerte API für den UART, die I²C-Schnittstelle sowie eine 1Wire-API enthalten. Im Service-Layer habe ich Dienste, wie "I²C-Bus-Expander ansteuern", "Temperatur aus einem DS18B20 auslesen", "LED blinken", "PWM erzeugen" und (mit dem Uhrenquarz) eine RTC implementiert. Es gibt nun Dienste, die könnte man auf mehrere Mikrocontroller verteilen. Eine Bibliothek dafür würde ich gern programmieren, aber es wäre das erste mal, dass ich sowas mache. Gibt es außer mir noch mehr Leute, die das Thema interessiert? VG Torsten
Angehängte Dateien:
-
LauchpadDualDsc5962a.jpg
67 KB
Bei so kleinen Prozessoren ist es kaum sinnvoll, die Arbeit auf einzelne Chips zu verteilen, erst recht wenn sie nah beieinander angeordnet sind (worauf die Verwendung von I²C hindeutet). Die Verwendung eines größeren Controllers, der die gesamte gewünschte Funktionalität bietet, ist einfacher, effizienter, billiger. Es gibt Controller mit so vielen Pins dass man nie wieder Portextender braucht, Controller die so viel Rechenleistung haben dass man Rechenaufwand nicht verteilen zu braucht, etc. Und mehr kosten als einzelne Controller tun die auch nicht, erst recht nicht wenn man den sonst benötigten Platinenplatz,Lötaufwand,Verkabelung dazurechnet. Man nehme einen größeren Controller aus der verwendeten Reihe, oder gleich eine größere Familie, wie zB STM32F4: http://www.watterott.com/de/STM32F4Discovery
Hans schrieb: > Bei so kleinen Prozessoren ist es kaum sinnvoll, die Arbeit auf einzelne > Chips zu verteilen, erst recht wenn sie nah beieinander angeordnet sind > (worauf die Verwendung von I²C hindeutet). Also "nah beieinander" können auch mehrere 100 Meter sein. ;-) Wenn nicht per I²C (das ist nur ein Beispiel) gern auch per LIN oder 1Wire. Es geht mir nicht darum, den Rechenaufwand zu verteilen. Eher darum, die Anzahl der Stecker und Leitungen zu minimieren. Beispiel: 1. Ein Prozessor am Aquarium für die Steuerung von Temperatur, Licht usw. 2. Prozessor in einer Anzeige- und Bedieneinheit mit LCD und Dreh-Drückgeber 3. Prozessor in einer 230V-Schaltbox, galvanisch getrennt zur Triac-Ansteuerunjg Leuchtstofflampen-Dimmung und Steuerung der übrigen 230V-Verbraucher (Blubberblasen-Pumpe, Wasserpunpe usw.) > Die Verwendung eines größeren > Controllers, der die gesamte gewünschte Funktionalität bietet, ist > einfacher, effizienter, billiger. Ich mag solche "Sparringspartner-Diskussionen" (habe ich das nicht heute schon mal geschrieben?). Grundsätzlich kann man System-Architekturen nach verschiedenen Kriterien optimerien. Eines davon ist die Summe der Leitungslängen. In vielen Fällen magst Du Recht haben, aber nicht grundsätzlich. > Man nehme einen größeren Controller aus der verwendeten Reihe, oder > gleich eine größere Familie, wie zB STM32F4: > http://www.watterott.com/de/STM32F4Discovery Danke für den Hinweis, sieht interessant aus. Habe ich mir bestellt, da ich mir das gern mal aus der Nähe anschaue.
Torsten C. schrieb: > Also "nah beieinander" können auch mehrere 100 Meter sein. ;-) Wenn > nicht per I²C (das ist nur ein Beispiel) gern auch per LIN oder 1Wire. > > Es geht mir nicht darum, den Rechenaufwand zu verteilen. Eher darum, die > Anzahl der Stecker und Leitungen zu minimieren. Achso war das gemeint, ja wenn die einzelnen Controller an jeweils ihren eigenen "Einsatzorten" sitzen ist das etwas anderes. Mehrere Controller direkt nebeneinander auf eine Platine zu setzen um mehr I/O zu haben wäre aber weniger sinnvoll...
Hans schrieb: > oder gleich eine größere Familie, wie zB STM32F4: Hans, welche Toolkette nutzt man da am besten? Im Datenblatt stehen: ● Altium, TASKING™ VX-Toolset ● Atollic, TrueSTUDIO ● IAR, EWARM ● Keil™, MDK-ARM Das sieht teuer aus ... Sorry, wegen "Off-Topic".
Torsten C. schrieb: > Das sieht teuer aus ... Es gäbe da noch die CooCox CoIDE, die ist gratis. Alternativ https://launchpad.net/gcc-arm-embedded (opensource & frei) verwenden und manuell konfigurieren & aufrufen, oder auch per Eclipse & CDT. Zu allen diesen Möglichkeiten gibts hier einige Infos im Wiki & Forum, musst mal suchen. Ich verwende letzteres, das klappt sehr gut auch mit C++, erfordert aber etwas Einarbeitung & Fummelei... Von den kommerziellen Toolchains gibts auch teilweise beschränkte Freeware-Versionen (hatte selber mit dem Atollic Studio angefangen). Der STM32F4 zB hat sehr viel Rechenleistung und eine Menge I/O, da lässt sich alles mit einem Controller erschlagen, es sei denn natürlich die einzelnen Controller sollen räumlich voneinander getrennt sein. Außerdem natürlich noch Ethernet-Interface und USB-Interface, also einfach mit PC's verbindbar :-) PS: CAN eignet sich auch ganz gut um die einzelnen Stationen zu verbinden.
@Hans: Danke für die Hinweise auf die Toolketten. :-) Hans schrieb: > Der STM32F4 zB hat ... eine Menge I/O, da lässt > sich alles mit einem Controller erschlagen, es sei denn natürlich die > einzelnen Controller sollen räumlich voneinander getrennt sein. Hmmm, im Moment fehlt mir vielleicht etwas die Phantasie, sorry. Aber wann braucht man einen Controller mit so vielen Pins auf einer Platine? Man kann natürlich breite Flachband-Kabel nehmen, um mehrere Platinen miteinander zu verbinden, so wie z.B. hier: http://www.mikrocontroller.net/attachment/148880/IMG_6997.JPG Aber ist es das, was Du meintest? Z.B. ein Display kann man über 9 .. 12 Leitungen anschließen, oder über LIN oder 1Wire, mit drei Leitungen - nur mal wegen der Extreme. Und wenn dann noch Tasten oder z.B. ein Dreh-Drückgeber dazu kommen, braucht man entweder noch mehr Leitungen oder eben einen zweiten µC, so wie er dem LaunchPad beigefügt ist. … oder eben einen geeigneten I²C-Expander.
Bei unabhängigen Aufgaben ist den Ansatz mit mehreren Mikrocontrollern durchaus sinnvoll. Schau dir moderne Autos an.
> Hmmm, im Moment fehlt mir vielleicht etwas die Phantasie, sorry. Aber > wann braucht man einen Controller mit so vielen Pins auf einer Platine? Ach klar braucht man das; LCD, Sensoren, Eingabegeräte, LED's, ... wenn das alles an einer Platine hängt :-) > Man kann natürlich breite Flachband-Kabel nehmen, um mehrere Platinen > miteinander zu verbinden, so wie z.B. hier: Das ist eher suboptimal wegen Störungen und unflexiblen Kabeln... Da dann lieber mehrere Controller und über ein wenig-adriges Protokoll :-) > Z.B. ein Display kann man über 9 .. 12 Leitungen anschließen, oder über > LIN oder 1Wire, mit drei Leitungen - nur mal wegen der Extreme. Naja LCD's mit 1Wire-Anschluss gibts wohl nicht so viele, die meisten werden wohl nen vielpinnigen parallel-Anschluss haben ;-) > Und wenn dann noch Tasten oder z.B. ein Dreh-Drückgeber dazu kommen, > braucht man entweder noch mehr Leitungen oder eben einen zweiten µC, so > wie er dem LaunchPad beigefügt ist. … oder eben einen geeigneten > I²C-Expander. Ja, es sei denn, dieser Drehgeber ist direkt neben dem Haupt-µC auf die Platine gebaut, weil dann kann man für diesen µC einen größeren nehmen und spart sich die Fummelei mit mehreren Controllern. Ich wollte ja nur sagen, dass es wenig Sinn macht mehrere kleine µC diret nebeneinander anzuordnen um an einer Stelle viel I/O zu haben, weil man da besser einen großen µC nimmt; wenn die I/O Anschlüsse an räumlich getrennten Stellen benötigt werden nimmt man besser mehrere kleine µC die über ein serielles Protokoll verbunden werden.
Angehängte Dateien:
-
abschneiden.jpg
48 KB
Hallo zusammen, ich möchte nochmal die beiden Themen trennen, denn: Torsten C. schrieb: > ich suche Mitstreiter bzw. Projektpartner. 1. Thema: Bibliotheken entwickeln: ---------------------------------- Torsten C. schrieb: > Im HAL ist aktuell eine (Interrupt-)-Flag-gesteuerte API für den UART, > die I²C-Schnittstelle sowie eine 1Wire-API enthalten. BTW: Nennt man das eher "API" oder "Stack"? Bei PCs würde man wohl "Treiber" sagen. Das könnte man noch um SPI und/oder LIN erweitern, aber die brauche ich gerade nicht. Der I²C-Stack ist aktuell für das UCSI (Universal Serial Communication Interface) fertig, man könnte ihn noch für das USI (Universal Serial Interface) umsetzen. > Im Service-Layer habe ich Dienste, wie "I²C-Bus-Expander ansteuern", > "Temperatur aus einem DS18B20 auslesen", "LED blinken", "PWM erzeugen" > und (mit dem Uhrenquarz) eine RTC implementiert. Als nächstes würde ein Stack für das LCD-Modul C0802-04 (Pollin) dazu kommen und für eine Tastaturmatrix. Für das Display und die Tasten könnten wir uns am BAP (Bedien- und Anzeigeprotokoll) orientieren, unabhängig davon, ob 1wire, I²C, CAN oder sonstwas verwendet wird. Auch hierfür könnten wir gemeinsam einen Stack programmieren. "BAP" im Online-Lexikon "IT-Wissen": http://www.itwissen.info/definition/lexikon/Bedien-und-Anzeigeprotokoll-BAP.html 2. Thema: Mehrere Prozessoren auf einer Platine ----------------------------------------------- Dr. Sommer schrieb: > Ich wollte ja nur sagen, dass es wenig Sinn macht mehrere kleine µC > diret nebeneinander anzuordnen um an einer Stelle viel I/O zu haben, > weil man da besser einen großen µC nimmt; Stimmt natürlich - eigentlich. Ich habe mir daher gerade überlegt, wie meine Platine mit einer 28PIN-Version des MSP430 (TSSOP-Gehäuse) aussehen würde: Ich würde meine Platine mit Hukepack-Buchsenleisten für das Launchpad versehen, um mein System für 5€ um "In-Circuit-Debugging" und eine "USB-COM-Schnittstelle" zu erweitern. Klar, kann ich dann den Sockel des Launchpads unbesückt lassen. Ich kann dann ja auch den Emulator absägen, damit das Launchpad nicht so viel Platz auf der Platine wegnimmt. ;-) Siehe Foto. Sorry, aber das zweite war schon wieder Off-Topic.
Ich muss mich nun entscheiden. Ich beginne mit der Programmierung des Bedienteils und habe zwei Möglichkeiten: 1. Die Bedienlogik im "Bedienteil" => Es werden Daten wie "Neue Ist-Temperatur", "Schalte Pumpe ein" oder "Neue Soll-Temperatur" usw. vom bzw. zum Bedienteil übertragen. 2. Bedienlogik in der Applikations-Software => Es werden Daten wie "Taste gedrückt", "Dregheber gedreht" oder "schreibe 'Hallo Welt' an Position 2,2" vom bzw. zum Bedienteil übertragen. Torsten C. schrieb: > Als nächstes würde ein Stack für das LCD-Modul C0802-04 (Pollin) dazu > kommen und für eine Tastaturmatrix. > Für das Display und die Tasten könnten wir uns am BAP (Bedien- und > Anzeigeprotokoll) orientieren, ... Vielleicht hätte ich den Thread besser "Protokolle zwischen Controllern" nennen sollen. Naja, vielleicht schauen ja trotzdem doch noch ein paar hier rein und können mir bei der Entscheidung helfen. Statt eines Bedienzeils könnte in einer anderen Version auch ein Sensor/Aktor-Controller separat über ein Protokoll angesprochen werden, da stellen sich dann die gleichen Fragen. Zurück zur Frage: 1 oder 2, was ist besser?
Will man mehrere MCs verbinden, sollte man nur welche mit CAN nehmen. RS-485 ist von der SW her zu aufwendig, SPI/I2C zu störempfindlich und USB/Ethernet nicht echtzeitfähig.
Peter Dannegger schrieb: > Will man mehrere MCs verbinden, sollte man nur welche mit CAN nehmen. Danke, hat sicher auch seine Vorteile. Ich hab' nix gegen CAN. Ich kann mich nur nicht entscheiden: Zurück zur Frage: 1 oder 2, was ist besser? ^^ Bei CAN stellt sich die gleiche Frage. Es geht mir um die Schicht 6: "Umwandlung der systemabhängigen Daten in ein unabhängiges Format" Was wandel ich um: Z.B. Tastendrücke "Taste B7" oder funktionale Ereignisse "Start-Knopf gedrückt"?
Torsten C. schrieb: > Ich hab' nix gegen CAN. Dann nimm es. Oder nimm zumindest gleich MCs mit CAN, ansonsten wirst Du es bereuen. CAN hat den Vorteil, daß es einem einen riesen Rucksack an Protokollsoftware schon abnimmt. Einfacher und sicherer als mit CAN gehts nicht. Für Dein LCD/Touch kannst Du mal das Protokoll des EA eDIPTFT43-A als Anregung nehmen. So ähnlich würde ich es auch machen. Allgemein sollten die Slaves keine applikations spezifischen Routinen beinhalten. D.h. bei Änderung der Applikation sollte nur der Master neu programmiert werden müssen. Ansonsten artet das in Arbeit aus und man verliert den Überblick.
Peter Dannegger schrieb: > Für Dein LCD/Touch kannst Du mal das Protokoll des EA eDIPTFT43-A als > Anregung nehmen. So ähnlich würde ich es auch machen. Das ist wirklich eine gute Anregung. Sieht zwar erstmal sehr sehr mächtig aus, aber das kann man ja Stück für Stück umsetzen, wie man's braucht. Hammer! 142€ aufwärts. > Allgemein sollten die Slaves keine applikations spezifischen Routinen > beinhalten. D.h. bei Änderung der Applikation sollte nur der Master neu > programmiert werden müssen. Danke für Deine Meinung. Gibt es noch andere Meinungen? Bei den EA eDIPs ist das offenbar nicht so. Dort werden den Tastendrücken Macros hinterlegt und die Bedienlogik ist damit im "Slave". Übrigens fehlt mir da die Anschlussmöglichkeit für einen Dreh-Drück-Geber. Bei ebay 300900930164 habe ich gerade welche für unter 50ct gesehen. Die Bedienlogik ist im "Slave" hat folgenden Vorteil: man kann unterschiedliche Bedienschnittstellen (Touchscreen, Grafik, Text, Softkeys, Joystick-Taster (wie im Beitrag "[S] Joystick Taster") usw. realisieren und alle nutzen die gleiche Schnittstelle zur Applikation im Master. Wenn man später z.B. eine neue (alternative) "High-End-Bedienung" entwickelt, braucht also die Applikation im Master nicht neu programmiert werden. Peter Dannegger schrieb: > CAN hat den Vorteil, daß es einem einen riesen Rucksack an > Protokollsoftware schon abnimmt. Bei den EA eDIPs werden ja immer unterschiedlich lange Byte-/Zeichen-folgen gesendet. Z.B. * ESC D L = Displayinhalt löschen oder * ESC Z L xx1 yy1 Text ... NUL = Eine Zeichenkette (...) an xx1,yy1 ausgegeben Bei CAN könnte jeder Befehl eine eigene CAN-ID (Adresse) bekommen, meinst Du das so? Oder wie ist das mit dem "Rucksack an Protokollsoftware" gemeint? Da einige Befehle mehr als 8 Byte lang sind, müsste man auch bei CAN ein "Transportprotokoll" nutzen, z.B. ISO-TP: http://de.wikipedia.org/wiki/ISO_15765-2 In dieser Beziehung sehe ich noch nicht den Vorteil von CAN gegenüber I²C oder 1wire. CAN ist elektrisch - ohne Frage - sicher die "sauberste" Lösung.
Torsten C. schrieb: > Oder wie ist das mit dem "Rucksack an > Protokollsoftware" gemeint? Wenn der Sender seinen Interrupt erhält, ist die Warscheinlichkeit sehr groß, daß der Empfänger das Paket auch fehlerfrei empfangen hat. Auch haben viele CAN großzügige Puffer (MOBs) und können z.B. 15 Pakete hintereinander senden oder empfangen, ehe die CPU den Interrupt anspringen muß. Bei I2C muß der Master bei Fehlern händisch ein Retry starten und einen CRC-Fehler kriegt nur der Empfänger mit. Der Master sieht nur das ACK und freut sich (zu früh). Auch habe ich schlechte Erfahrungen mit den Atmel I2C (AVR,8051) gemacht. Deren Statemaschine ist sehr komplex (sehr langer Interrupthandler) und buggy (Timerinterrupt mit Disable I2C bei Timeout nötig). CAN wird oft in der Industrie eingesetzt. Die Gefahr, daß das CAN nicht dokumentierte Bugs hat, ist daher sehr gering.
Peter Dannegger schrieb: > Deren Statemaschine ist sehr komplex Also wohl auch nicht besser als die vom MSP430. :-( Dort gibt es keinen Interrupt, um die "stop condition" zu setzen; man solle in einer While-Schleife pollen, bis das Bit "start condition" gelöscht sei, so das Datenblatt. :-( In der Firma arbeite ich mit einem Steuergerät mit 6 CANs und CANoe, damit kenne ich mich aus. ;-) Unentschlossen bin ich nun noch immer, ob die Bedienlogik in den Slave soll oder nicht. Beides hat Vor- und Nachteile. Oder man versucht, durch geeignete SW-Architektur wahlweise beides zu unterstützen.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.