Hallo Mich nervt immer mehr, das ich für neue Projekte immer neue Platinen entwerfen und neue Software schreiben muß obwohl 80% der Funktionen im Prinzip immer die gleichen sind (z.B. IO, serielles interface, etc.). Desshalb werde ich ein modulares Stecksystem auf der Basis von ATMEL Tiny MUC aufbauen. Ich habe dabei eine Reihe sehr kleiner Platinen (so ca 5*3cm) im Sinn, die jeweils über einen 8PIN Tiny MUC verfügen und über einen I2C/TWI-Bus miteinander Verbunden sind. Diese Platinen können dann beliebig ineinandergesteckt werden. (Spielt also keine Rolle ob ich 10 oder 100 IO-Kanäle brauchen - solang die Bandbreite mitmacht) Das Initalwerk besteht aus folgendem: - Grundmodule Layouten (das mache ich sobald ich mal wieder ein Bischen Zeit habe - in meinem Kopf sind die schon fertig) - Ein einfaches und flexibles high-level Protokoll entwickeln da I2C soviel ich weiß keine Fehlerkorrektur/Parity funktionen anbietet. - Die entsprechende Software fuer die Module schreiben. Folgende Module werde ich als erste Implementieren (auch als Evaluierungsplattform Gedacht: - IO Modul mit 2*8 IO Kanälen. - Stromversorgungs Modul - bestehend aus einem Festspannungsregeler und ein bischen Stabilisierungskram - Eine "general purpose" Modul: die verbleibenden 6 PINS des AVR werden auf eine Steckerleise führt (kann dann alles mögliche sein - von Display interface bis I2C HUB - ja nach Software). Ich hoffe das es ein paar Leute interessiert! Als Fernziel soll ein pool von Modulen (USB, IRDA, RS232, Relaismodule, Displaytreiber Graphisch/Alphanumerisch...) inclusive Software entstehen aus dem einfach jeder schöpfen kann. Dann bestehen auch aufwendige Projekte aus dem Anpassen von wenigen Softwareteilen und Zusammenstecken von ein paar Modulen. Was ich mir von diesem Forum erwarte ist eine sachliche Diskussion über Mögliche highlevel Protokoll um einen I2C Dynamisch adressierbar und mit Fehlerkorrektur zu bekommen sowie am besten einen Haufen Hardwaredesigner die Berge von Modulen entwickeln und Software dafür schreiben soweit die Spezifikationen stehen. Gruß Dom P.S.: Ich will keine standard I2C IO Bausteine verwenden, da diese extern ihre Adresse angelegt haben wollen - ich will den Bus jedoch mit Dynamischen adressen.
An so etwas ähnlichem bastle ich schon eine Weile - leider z.Zt. eingestellt wegen zeitmangels. Meine Idee basiert auf einem Interface für Funktionsmodelle (fischertechnik), auch vernetzt mit I²C. Da es Probleme mit der Bandbreite gibt, wenn man viele Zähleingänge für Positionsgeber verwendet, soll jedes Modul diese Zähleingänge selbst verwalten, d.h. es werden nur die Soll-Positionen per I²C gesendet, das Modul macht den Rest (Motorsteuerung + Impulse zählen). Die Module bauen auf den Mega-8 auf und stellen 4 Motor-Ausgänge + 8 Eingänge zur Verfügung.
Hallo, was soll so ein system denn an effektiven nutzen bringen? wenn ich einen µC irgendwo einsetzten will dann hat das ding eine aufgabe und die passenden schittstellen in die realität. Um die ganze geschichte für den endverbraucher so günstig wie möglich zu machen wird halt ein kleines PC entwickelt wo je nach anwendungsfall auch nur das oben ist was man braucht. In spezialfällen habe ich schon paltinen mit 2 bestückungsvarianten gemacht, aber ein modulares system ist doch totaler overkill. Man hätte dann 2 mal einrichtungskosten für eine maschiene beim bestücker, 2mal test und verpackung 2x pcb .... und dann der mehrauffwand bei der SW. So kann man je nach andendungsfall eine passende MCU auswählen. MfG Sebastian
Hi Also der Sinn besteht darin kleine Steueraufgaben kostengünstig und einfach zu implemtieren. Beispiel: ich will ein 8 Füßigen Laufrobotter bauen. Ergibt beispielsweise ein IO Modul für generelles Zeug wie kollisonsmelder etc und 16 PWM kanäle für die Aktoren (2 Achsen pro Bein), ein Display als userinterface und dann noch n paar Tasen zum interagieren. Natürlich kannst Du das alles auf eine Platine bauen - ist aber höchst unflexibel. Wenn Du es modular aufbaust ist es nachher Wurscht ob Dir noch einfällt das Du ja eigentlich noch nen Gelenkt an jedem Fuß haben willst - dann steckst Du halt nochmal n paar PWM -Kanäle drauf. Zu den Kosten: Ich gehe mal davon aus das ich ca. 15 Module auf eine Europlatine bekomme. Wenn ich die bei PCB pool äzen lasse kostet das 50EUR - selbst wenn ich alle Module für ein Projekt brauche (was relativ unrealistisch ist) ist das mit Bauteilen immer noch 2-4 mal billiger als nen PC zu nehmen (und viel kleiner). Ich stell mir das so vor das eben später der Nutzer eine Palette von Layouts im Internet angeboten bekommt und einfach die die er braucht auf eine Platine packt und diese zum Äzen bringt (so a la cut n paste). Ich gehe übrigens von einem Preis von 5-8 EUR (je nach Modul) aus - teurer darf das nicht werden. Gruß Dom
wenn du schreibst du willst ein modul für ca 5-8 euo anbieten wäre das ja in der summe auch nicht viel günstiger wenn man 4 karten baucht. ich gehe mal davon aus wenn ich platz für 1/2 eurokarte habe bekomme ich problemlos 2 Mega128 inkl. 2x uart 4-8 analog in mit jumper 0-10V oder 4-20mA. Spannungsregler und pegelwandler. und aller noch benötiger perepherie. man kann ja ein PCB von oben und unten mit Smds bestücken, und ich habe dann immer noch ein flexibles Board, eventuel igendwann benötigte HW kann ich per Uart, SPI und I2C anbinden. Und selbst in diesem fall braucht man auf dieses Board nur das bestücken was man wirklich braucht. Was nützt es wenn ich 5 leiterplatten habe mit den ich alles machen kann, es aber viel overzize in der SW kostet und dann noch mechanisch zum problem wird. Sebastian
dazu kann ich nur sagen das ich einfach die Erfahrung gemacht habe das ein Monolithischer Ansatz wie Du ihn favorisierst funktioniert aber eben einfach unfelxibel ist. Du kannst unmöglich alle eventualitäten auf Deinem Board im Voraus einplanen. Was passiert wenn Du mit dem PC drauf zugreifen willst und eine RS232 Schnittstelle implementierst und dann doch USB oder IRDA willst - dann kannst Du Dein Board schlicht wegschmeißen. Natürlich haben modulare Konzepte einen overhead (schau Dir den Linux Kernel an). Der Vorteil ist aber das sie immer genau so groß sind wie man sie braucht und erweiterbar sind. Ich möchte die Diskussion über dieses Thema hier eigentlich beenden - wenn Du mit Deinem Ansatz glücklich bist freut mich das - ich bin es nicht und ich werde diese Hardware genau so entwickeln - mir geht es eigentlich nur um Input/Feedback zum Thema Protokoll und Leute die Software für die Module schreiben wollen. Gruß Dom
Ich arbeite auch an so etwas (was'n dingen) habe aber bisher noch keinen passenden Bus dazu gefunden. Einen seriellen Bus zu verwenden finde ich schon gut. In der Regel benötigt man keine besonders große Geschwindigkeit für die Module untereinander. Aber I2C finde ich nicht so witzig da ich das ganze recht variabel halten möchte (auch mal 2 oder 3 gleiche Komponenten anschließbar) und die I2C IDs ja nicht unbegrenzt zur vefügung stehen. Man möchte ja auch einmal einen simplen LM75 anschliessen können ohne sich mit seinen eigenen Komponenten in die Quere zu kommen. Bei mir wirds aber wohl kein Amtel sondern ein PIC system, aber bei gleichen Bus macht das ja gar nichts. Gruß Martin
Ich sehe es auch so, das haarigste an der Sache ist die Vernetzungssoftware. Ich kann aus eigener Erfahrung sagen, das ist nichts für Anfänger. Ehe du also umsonst viele Module entwickelst, würde ich empfehlen, erstmal ein paar Chips auf eine Lochrasterplatine draufpappen und die Software zum Laufen zu bringen. Die 8-Pinner sind außerdem ware Einzelkämpfer, sie haben einfach zu wenig Ressourcen, um nebenher noch ein Protokoll zu fahren. Das Minimum für eine einigermaßen stabile Vernetzung dürfte der Mega8 sein. Als Hardware entweder I2C oder die UART. Um mit der UART das Protokoll einfach zu halten, bietet sich die Ringschaltung an (TXD an RXD des nächsten usw.), dann gibts keine Kollisionen. Peter
Hallo Danke Martin und Peter für die Anregungen Zu Martin: Der i2c adressraum ist 7 (bzw. 11) Bit - das sollte meinermeinung nach völlig ausreichen - die Bandbreite wird warscheinlich viel früher einen Strich durch dir Rechnung machen. Standard ics kannst Du natürlich noch anschließen - Du must eben nur drauf achten das sich die Adressen nicht beißen. (Das high level Protokoll das ich angesprochen habe ist ja nicht zwingend - es dient nur dazu eine Fehlerkorrektur anzubieten (wenn man sie braucht) und die Adresse abzuändern bei den Devices die es unterstützen. Wenn Du das ganze auf PIC basis machen willst ist das kein Problem (ist eher von vorteil - wird das ganze vielseitiger). Wir sollten uns dann über das BUS-System (ich favorisiere klar I2C), Protokoll und Stecksystem klar werden - dann sollten PICs und AVRs problemlos zusammenarbeiten. Zu Peter: Du hast recht - ich hab gerade nochmal ne weile gelesen und es sieht so aus als ob ein Tiny ohne großen codeoverhead nicht als I2C slave functioniert ( http://www.avrfreaks.net/Tools/showtools.php?ToolID=77 ) -> also megaavr (ich hab mir da mal den Mega8 angeschaut). Das sollte von größe (tiny *2) + preis( 3EUR) her immernoch akzeptabel sein. Zu der Software: Ich bin kein Anfänger (keine Angst ;-) und ich hab mir auch schon grob ein paar protokolle überlegt - ich will hier nur eine fruchtbare Diskussion anzetteln um solches nette feedback wie von Euch zu bekommen. Gruß Dom
Hi. Also ich find die Idee interessant!! Mich nervt es auch, wenn ich ne Schaltung bauen will und ich muss ständig irgendwo auf Lochraster oder Steckboard meine Peripherieschaltung aufbauen, weil auf dem Mikrocontroller Board das Zeug einfach nicht drauf ist. Find also die Idee super - vorallem im Entwicklungsstadium von Projekten sollte sowas hilfreich sein! Was mich ein bisschen "beunruhigt" ist, dass manche Module (z.B. USB) ja wesentlich schneller sein werden, als der I²C Bus das erlauben wird. Bei anderen Modulen (z.B. IO Modul) wäre das natürlich wieder was anderes. Hier werden hohe Geschwindigkeiten meist nicht gebraucht -> also ohne weiteres I²C möglich. Als zentralen uC würde ich demnach einen nehmen, der ein externes SRAM erlaubt - irgendeinen in Richtung Mega162, oder so! Dann könntest neben deinem I²C BUS System auch den externen Memory Bus verwenden und per Memory Mapped Mode einige Module implementieren. Der Vorteil daran liegt, dass du Module mit höherer Geschwindigkeit (USB, Compact Flash, ...) auch einfach dranstecken kannst und keinen Geschwindigkeitsverlust durch das Protokoll hast! mfg Andreas -- Andreas Auer aauer1 (at) sbox.tugraz.at Student of Telematics http://home.pages.at/aauer1 Graz, University of Technology
Hallo Andreas Also da bin ich völlig offen. Der Bus ist als reiner Kommandobus gedacht (ein MP3 player beispielsweise wird dann zwangsweise noch zusätzlich einen schnellen Datenbus benötigen) das userinterface und konfiguration von decoder etc. kann man aber problemlos so managen. Was den MCU angeht steht es jedem völlig frei jeden erdenklichen kontroller zu verwenden - solange er I2C spricht. Mir geht drum mal eine guideline zu entwickeln wie das Stecksystem aussehen muß und eben ein einfaches Protokoll mit fehlerkorrektur und dynamischen adressen. Gruß Dom P.S.: Ich hoffe das ich am Wochenende dazu komme mal ein paar designs zu machen das Ihr mal ne Idee bekommt wie das Stecksystem für mich aussehen sollte.
"...Tiny ohne großen codeoverhead nicht als I2C slave functioniert..." Als nur Slave müßte auch der Tiny26 gehen (habs nicht probiert), der hat ja Start-Stop-Erkennung und ein Byte-Schieberegister. Als Master geht der Tiny26 nicht bzw. dann wieder zu Fuß, jede Taktflanke in Software. @Martin, welchen PIC hast Du denn für die Slaves geplant ? Peter
@Dominic: <Zitat> Zu Martin: Der i2c adressraum ist 7 (bzw. 11) Bit - das sollte meinermeinung nach völlig ausreichen - die Bandbreite wird warscheinlich viel früher einen Strich durch dir Rechnung machen. Standard ics kannst Du natürlich noch anschließen - Du must eben nur drauf achten das sich die Adressen nicht beißen </Zitat> Genau bei dem "Adressen nicht beißen" habe ich bei i2c ja das Problem wenn ich mit vorgefertigten Bausteinen arbeiten will. Nehmen wir einmal an das ich mit einem DIP8 PIC eine kleine Platine mit 4 PWM Ausgängen baue (der PIC im DIL8 Gehäuse hat max 6 I/O Leitungen frei, 4 PWM + 2 Bus passt also), dann soll das Ding einmal komplett fertig gemacht werden. Mit Programm und allem gedöns. bei i2c wird dessen slave Adresse also im Programm stehen müssen und ich kann nicht mehr einfach einmal 2 Module anschliessen (z.B. weil ich nun doch mehr PWMs brauche) sondern muß den Modulen unterschiedliche Programme geben (wegen den adressen) oder irgendwie aufwendig eine Hardwarlösung auf jedem Modul haben mit dem ich die gewünschte Adresse vorwählen kann und welche sich das Modul beim start zieht. Und genau da suche ich etwas schöneres! Any Ideas? @peter: egal, was gerade anliegt oder was für die Funktion des Modules notwendig erscheint. Ich habe keine Probleme damit viele PICs zu vernetzen, im Gegenteil sehe ich das oft sogar als eine saubere Lösung an. Es ist manchmal sinnvoller fertige Funktionen in MCs auszulagern als fertige Routinen so zusammen zu kopieren das sie ein einem größeren PIC laufen. Wer weis immer welche seiteneffekte oder Zeitprobleme man sich da einhandelt. Der einzelne PIC wird seine Funktion immer sauber durchführen können und lässt sich von anderen nicht beeindrucken. Gruß Martin
"bei i2c wird dessen slave Adresse also im Programm stehen müssen und ich kann nicht mehr einfach einmal 2 Module anschliessen" -> serielles eprom
Hi Martin Zum Thema Adressen. Wie ich oben schon geschrieben habe muß jedes Modul eine Funktion bieten (am besten im high level Protokoll verankern) die interne Adresse zu verändern. Das ist im einfachsten Fall eifach ein if I2C eingangsregister = 00000000 (Befehl) dann lese nächstet Byte vom bus und schreibe eingangsregister nach i2c addressregister und EEPROM. Ich verstehe das so das jedes Modul beim reset erst mal seine Adresse aus dem EEPROM liest und dieser EEPROM inhalt eben per Kommando verädert werden kann. Beim Flashen setzt Du das auf einen Initialwert und "buchst" dann Deinen Baustein in Dein System ein. Was natürlich am schönsten wäre wenn sich jede Komponente eine freie ID sucht und sich dann irgendwo registiert - das ist aber der totale overkill für den Zweck - dann können wir schon fast mit TCP und DNS anfangen (also bitte keine Dikussion darüber - ich weiß das man TCP auch über I2C fahren kann - dann ist der Effektive Datendurchsatz dann wohl bei 5Kbit oder so). Gruß Dom
@Hallo Martin "Ich habe keine Probleme damit viele PICs zu vernetzen, im Gegenteil sehe ich das oft sogar als eine saubere Lösung an." Vor einiger Zeit habe ich hier mal eine komplette Schaltung für ein Digitalscope mit 12 Bit Auflösung vorgestellt (allerdings mit dem 68HC811E). Das Gerät wird hier im Institut (5 Stück) eingesetzt und arbeitet auch zu Aller Zufriedenheit. Deine Idee mit den vernetzten PIC's habe ich in Entwicklung für die Aufbereitung der verschiedenartigen analogen Daten der 8 Eingangskanäle (momentan hat jeder Kanal nur einen ordinären Abschwächer mit Lageregelung). Um hier sehr flexibel zu sein und extrem kleine Platinchen (ausgelegt als aktive Tastköpfchen) zu bekommen, werde ich die neuen 5 poligen SOT23 PIC'S einsetzen. Auf solch kleine Teile warte ich schon lange, für solche kleinen Aufgaben sind die prima geeignet. Zu Deinem eigentlichen Entwicklungsvorschlag kann ich nur sagen, daß eine modulare Konstruktion nur für Grosserien (aus Fertigungsgründen) lohnt. In meiner langjährigen Praxis ist selten etwas so entwickelt worden, daß es mit einfachen Umbaumaßnahmen zu übernehmen gewesen währe. Mit einer Neuentwicklung ging es meistens schneller. Man fängt ja nicht wirklich ganz neu an (jedenfalls nicht im Kopf, dort baut man doch auf dem letzten Wissensstand auf). Module machen Sinn wenn sie immer wiederkehrende Funktionen übernehmen können und das läßt sich ja auch über einen der seriellen Daten/Adressbusse erledigen. Trotzdem viel Erfolg für Dein Projekt, ich werde das sicher weiterverfolgen. MfG Manfred Glahe MfG Manfred Glahe
"eine modulare Konstruktion nur für Grosserien (aus Fertigungsgründen) lohnt." Da kann ich Manfred nur zustimmen. Ich habe die Modulbauweise nur deshalb gewählt, weil unsere Geräte sehr kundenspezifisch angepaßt werden und weil ich mir damals noch nicht über den nötigen Softwareentwicklungsaufwand im Klaren war. Im Nachhinein hat es sich aber doch gelohnt, die Kundenanpassungen gehen nun sehr schnell. Um die Busauslastung gering zu halten, habe ich auch die Multimastermethode gewählt. D.h. die Bedien-CPU schickt eine Anfrage an ein Modul und das startet dann z.B. die AD-Wandlung und schickt das Ergebnis zurück, sobald sie fertig ist. Es enstehen also keine unnützen Wartezeiten. Auch können die Module selber Statusänderungen senden, d.h. die Bedien-CPU muß nicht ständig alle Module abfragen. Rein von der CPU-Auslastung habe ich noch nie eine Modularisierung als nötig angesehen. Und zum Verdrahtung sparen und als Porterweiterung sind die guten alten 74HC595 und 74HC165 bestens geeignet, da beliebig kaskadierbar. Es ist immer wieder erstaunlich wieviele Sachen ein einzelner MC parallel ausführen kann. Man muß bloß erstmal den geeigneten Programmierstil finden, z.B. alle Wartezeiten gnadenlos ausmerzen und wieder dem Hauptprogramm als Rechenzeit zur Verfügung stellen. Man sieht aber leider viele Programme, die zu 99%..99,9% nur Nichts tun und dann wird gemeckert, die CPU sei zu langsam. Peter
@Peter, "Man sieht aber leider viele Programme, die zu 99%..99,9% nur Nichts tun und dann wird gemeckert, die CPU sei zu langsam." das sehe ich auch so! Aber um externe Hardware wie AD/DA oder RAM'S usw. mit maximaler Geschwindigkeit ansteuern zu können würde ich mir auch bei den "relativ" langsamen µP's folgende hardwaremäßig implementierte Funktion wünschen: Einen setzbaren Zähler der vom Prog den Startpunkt, den Endpunkt oder die Anzahl der Takte liefert und diese dann mit ebenfalls setzbarer Taktrate, bis rauf zum Quarztakt, ausführt. Wenn ich also einen seriellen 12 Bit ADW betreibe, dann wird dieser mit 12 Takten/Anweisung in Oszillatorgeschwindigkeit ausgeführt. Viele Applikationen (solch eine Forderung ist heute ja in fast allen Anwendungen drin) müssen das in externer Logik unterbringen (nicht immer sind CPLD's mit ihrer schieren Pinzahl die bessere Lösung). Damit ließe sich auch der SPI Bus erheblich beschleunigen. Jedenfalls währe mir solche Zusatzfunktion willkommener als irgendein zusätzlicher exotischer Bus im µP.
Ich will ja auch die die CPU Auslastung durch Verwendung von mehreren CPUs Modularisieren sondern Module mit verschiedenen Funktionen erstellen. Egal ob die nun eigene CPUs haben oder nicht. @Dominic An den Einsatz des EEProms für die Moduladresse hab ich noch gar nicht gedacht :-o Für einen seriellen Lowspeedbus könnte ich mir auch so etwas vorstellen wie Maxim das bei dem MAX7219 LED Driver macht. Jedes Modul hat ein Data/Clk und CS Signal, dazu noch einen CS Ausgang der immer um eins verzögert das CS weiter gibt. Hat man mehrere von den Dingern werden Data und clk parallel angeschlossen und cs des einen chips kommt an den cs-ausgang des vorgängers. Jeder Chip kennt einen NOP Befehl damit man den "überspringen" kann. Damit kann man die Chips hintereinander beschreiben (fast) egal wie viele da sind. Gruß Martin
Hallo Dominic, gibt's denn schon erste Ergebnisse? Würde mich interessieren. Stefan
Thread beobachten
Seitenaufteilung abschaltenBitte 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.