Hallo, ich suche einen Bus um mehrere µC zu vernetzen. Die µCs sollen in einer langen Kette an den Bus angeschlossen werden. Es gibt einen Master und ca. 100 Slaves. Die Slaves haben einen Abstand von 10cm, so das der Bus ca. 10m lang sein muss. Zur Datenrate: Datenstrom Master -> Slaves: - 4 Byte pro Slave (inkl. Addressierung) - 60x pro Sekunde => 100 60 4 = 24.000 Byte/s = ca. 190 kbit/s Datenstrom Slaves -> Master: - 1 byte pro Sekunde => 100 Byte/s = ca. 1 kbit/s Lässt sich das noch mit I2C machen? Gibt es etwas das besser geeignet wäre?
Bastler würden das sicher mit I2C versuchen. Den halte ich hier aber aufgrund der hohen kapazitiven Last, der Länge des Busses und der Anzahl der Knoten für ungeeignet. RS422/485 wäre hier besser geeignet. fchk
ich würde da zu CAN tendieren, ein 4-Byte Telegramm ist ja nicht die Welt - brauchst halt einen extra CAN-Treiber (SO-8) und einen µC mit CAN-Controller. Du hast den Vorteil dass du Buskolisionen vermeiden kannst (Bitarbitrierung) und das CAN auch recht gutmütig mit Stichleitungen umgehen kann...
CAN wäre auch noch eine möglichkeit. Ausreichende Übertragungsraten und hohe Störsicherheit.
Vielen Dank schon mal für die Tipps. CAN klingt vernünftig. Gero schrieb: > brauchst halt einen extra CAN-Treiber (SO-8) und einen µC mit > CAN-Controller. Gibt es da was bezahlbares? Ich hatte vor für die Slaves möglichst kleine und günstige Atmel Tinys zu nehmen. Aber mit CAN ist da wohl nix :-( Was wäre eien CAN taugliche Alternative (muss ja nicht unbedingt Atmel sein)
definitiv CAN, da hast du die Kollisionsvermeidung und Fehlererkennung schon dabei. wenn die slaves zudem zumindest teilweise die selben daten bekommen dann hast du das bei CAN auch noch dabei.
Nimm doch CAN, der sollte Deine Anforderungen erfüllen und viele uC enthalten einen integriereten CAN-Controller, so dass sich das relativ preiswert aufbauen lässt. Und noch einmal RS422/485 sind erstmal nur Hardwarspezifikationen einer Schnittstelle, damit wird noch keine Aussage über das Protokll gemacht. Aber die Hardware des CAN-Busses sollte weitestgehend der RS485 ähnlich sein. Insofern stimme ich dem obigen Beitrag zu. Die Übertragungsgeschwindigkeit würde ich aber deutlich höher als 190kbps legen, damit es zu keiner 100%igen Buslast kommt. Aber das sollte aufgrund der Kürze des Busses selbst mit 1000kbps kein Problem sein (aus dem Bauch heraus). Bei I2C sollte man sich überlegen was das Kürzel bedeutet und wofür also I2C entwickelt wurde. (I2C = Inter-Integrated Circuit) I2C ist für die schlanke Verbindung von Schaltkreisen auf einer Leiterplatte entwickelt worden. Die Signalleitungen sind Masse bezogen, also sehr viel weniger störfest als eine RS485 Verbindung. Daher kommt für mich I2C leiterplattenübergreifend nicht in Frage. Und wenn es mal wirklich nicht anders geht, sollte man bei längeren Entfernungen I2C/RS485 Umsetzer benutzen.
Boris P. schrieb: > Gibt es da was bezahlbares? Der PCA82C251 kostet bei Reichelt 0,97€. Und der MCP 2515 kostet 1,70€ (wenn du keinen CAN-Atmel benutzen willst).
sorry, bei Atmel kenne ich mich nicht aus! Es gibt aber z.B. von ST viieeelle STM32 Derivate mit CAN-Controller, ich glaub die ganze 103er-Serie -> STM32F103rb, stm32F103c8... Kommt natürlich immer auf die restliche Peripherie an die Du im µC benötigst. Wieviel I/Os, welcher Takt, Flash, RAM... Ich könnte mir aber eventuell und unter Umständen vorstellen, dass es auch Tinys mit CAN-Controller gibt.. Ansonsten gibt es noch externe CAN-Controller z.B. von NXP den SJA1000, der ist aber "rießig" in der Bauform und kostet auch gut mal drei ganze Euros... als Treiber nimmst Du einen MCP2551 oder einen 82c251
Könntest z.B. einen ATmega32C1 nehmen, ist mit 4-5€ zwar recht teuer, aber schön kompakt, dann brauchst du nur noch einen Transceiver.
Bei 10cm Abstand und 200k Datendurchsatz kommst du sicher mit RS485 aus. Du musst aber Treiber nehmen, die in der Spec "1/4 bus-load" oder weniger können. Als Protokoll kannst du dir etwas an der Uart im 9Bit-Modus basteln. Da du Master-Slave Architektur hast, ist das ja nicht so wild. CAN-Transciever usw. finde ich für die Anwendung und die 10m mit 10cm-Abstand schon harte Geschütze... 9-Bit Betrieb: Nutze das 9te Bit zur Adressierung vom Master an den Slave und gönne ihnen dann ein Zeitfenster um zu antworten.
:
Bearbeitet durch User
Boris P. schrieb: > Es gibt einen Master und ca. 100 Slaves. Die Slaves haben einen Abstand > von 10cm, so das der Bus ca. 10m lang sein muss. Ich könnte mir vorstellen das irgendein Bus aus dem Automotivebereich das kann (CAN) Aus Wikipedia, zum CAN-Bus: "Die maximale (theoretische) Leitungslänge beträgt z. B. bei 1 Mbit/s 40 m, bei 500 kbit/s sind 100 m möglich und bei 125 kbit/s 500 m." Ansonsten dürfte es auch mit RS232 und ner Modifizierten Version des ccTalk-Protokolls gehen. Das orginal ccTalk sieht nur Baudraten von 4800/9600 vor. Aber es hält dich nichts davon ab, das zu ändern, da du ja Master/Slaves bereitstellst, und du damit festlegst wie schnell auf dem Bus beplaudert wird. Und du brauchst mit ccTalk nur eine Ader zur Datenübertragung. Bei nem ATmega mit 18,432MHz Quarz hast du bis 230,4K Baudrate sogar 0% Fehler. Grüße
Boris P. schrieb: > Vielen Dank schon mal für die Tipps. CAN klingt vernünftig. > > Gero schrieb: >> brauchst halt einen extra CAN-Treiber (SO-8) und einen µC mit >> CAN-Controller. > > Gibt es da was bezahlbares? Ich hatte vor für die Slaves möglichst > kleine und günstige Atmel Tinys zu nehmen. Aber mit CAN ist da wohl nix > :-( > > Was wäre eien CAN taugliche Alternative (muss ja nicht unbedingt Atmel > sein) PIC18F26K80 Und als Transceiver den MCP2551. Der kann maximal 112 Knoten treiben - das mal so als Warnung, dass Du Dich hier einer Grenze näherst. Das ist übrigens recht viel, es gibt auch Transceiver, die nur 32 Knoten treiben können. fchk
Im Automotive Bereich kommen immer mehrere Bussysteme zum Einsatz, z.B. kommuniziert jede Einheit in der Tür über einen sehr kostengünstigen BUS (=> LIN) mit einer Steuereinheit für die gesamte Tür, diese wiederrum hat die (teurere) CAN Peripherie und kommuniziert mit dem Rest des Fahrzeugs.
Hui, da kommt dann leider doch ganz schön was zusammen. Die Controller+Transceiver die ihr so vorgeschlagen habt kommen ja auf mehrere Euro das Stück. Bei 100 Slaves geht das ins Geld... Ich hatte ja ursprünglich gehofft, dass mit einem Tiny (<1€) hinzubekommen. Schade :-(
Ich würde auch am ehesten zu CAN neigen. Ganz hübsch und relativ billig ist der neue Cortex STM32F072: http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1574/LN1823/PF259608 Das Demoboard dazu gibt es schon für 8€. Allerdings gibt es den erst im LQFP64-Gehäuse mit 0,5mm Pitch, falls Du selbst löten willst, ist das grenzwertig. Der Controller ist bereits bei Rutronik mit ~ 2,00€ gelistet. Andere Gehäuse (STM32F042 im TSSOP20) wird es zwar demnächst geben, aber ein Liefertermin stht noch nirgends. Der eigendliche CAN-Bus-Treiber ist von der Technologie und vom Preis her ähnlich wie RS485-Treiber. Wenn Du wirklich nur Single-Master willst, dann ist RS485 auch möglich. Dann ist praktisch jeder Controller benutzbar. Aber dann musst Du wirklich alle Slave-Anfragen vom Master aus starten, mal kurz eine Info außer der Reihe von einem Slave aus verschicken ist nicht möglich. Multi-Master-Systeme mit RS485 sind zwar theoretisch möglich, aber nicht ganz einfach. Bei CAN dagegen kannst Du ganz ohne Master auskommen: jeder Knoten verschickt seine Daten dann, wenn diese vorliegen, ohne Rücksicht auf den Bus nehmen zu müssen. Gruß, Stefan
MCP2562 als Bus-Treiber (relativ günstig) und "Multi-Processor Communication Mode" z.B. mit ATtiny1634 oder ATtiny841 (Hardware-UART vorhanden)
Was sollen denn die Controller alles können bzw. wieviel Pins brauchst Du?
Boris P. schrieb: > Hui, da kommt dann leider doch ganz schön was zusammen. Die > Controller+Transceiver die ihr so vorgeschlagen habt kommen ja auf > mehrere Euro das Stück. Bei 100 Slaves geht das ins Geld... > > Ich hatte ja ursprünglich gehofft, dass mit einem Tiny (<1€) > hinzubekommen. Schade :-( bei digikey: PIC18F25K80-I/SS-ND: 1.746€ MCP2551-I/SN-ND: 0.6247€ Viel billiger wirds leider nicht. fchk
Stefan schrieb: > Was sollen denn die Controller alles können bzw. wieviel Pins brauchst > Du? Eigentlich nicht besonders viel: 3xPWM um eine RGB Led anzutreben.
Dann würde ich eher einen LED-Treiber nehmen, der neben der PWM auch die Konstant-Stromtreiber integriert hat. Meistens haben die einen seriellen Eingang (IIC oder SPI). Den würde ich zwar nicht über 10m verlegen, aber wenn Du nur noch einen Controller für 10-20 RGBs hast, dann ist das ja auch schon eine Ersparnis. Welche Leistung sollen die RGBs haben? Gruß Stefan
noch eine möglichkeit: daisy chain von mehreren Tinys, 10cm mit usart oder SPI sind ok. was hast du genau vor, dann können wir dir besser helfen? was soll der rückkanal?
Konrad S. schrieb: > MCP2562 als Bus-Treiber (relativ günstig) und "Multi-Processor > Communication Mode" z.B. mit ATtiny1634 oder ATtiny841 (Hardware-UART > vorhanden) So würde ich es auch angehen, wobei als Bustreiber ein PCA82C250 deutlich günstiger wäre und auch ein ATtiny2313 passen würde.
Du willst nur eine RGB LED ansteuern? Dann ganz klar kein CAN-Bus, das wäre mit wohl mit Kanonen oder eher Atomraketen auf Spatzen.
zoggl schrieb: > was hast du genau vor, dann können wir dir besser helfen? was soll der > rückkanal? Vor einigen Tagen bin ich über dieses ziemlich coole Bastelprojekt gestolpert: http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html Nun überlege ich, ob man sowas nicht auch etwas geschickter konstruieren könnte (vor allem nicht 20kg Kupfer in Form von Leitungen verlegen). Meine Idee war: alle Knoten (RGB LED + IR-Sensor) etwas intelligenter zu machen, so dass diese nur noch über eine einzige Leitung (Stromversorgung + Bus) als Kette verbunden werden müssen. Am Ende sitzt dann ein etwas dickerer Controller, der einzelnen Knoten auf dem Bus sagt, was sie anzuzeigen haben. Dieser nimmt dann auch die Touch-Events der Knoten entgegen und wertet diese aus.
Vielleicht wäre LIN für dich eine Alternative, nur ein Draht, LIN Transceiver gibt es locker weit unter 1€ wie Sand am Meer und meines Wissens kannst du das direkt über UART implementieren. Wie es mit der Knotenzahl aussieht weiß ich allerdings nicht.
Hi Boris, dafür würde ich für einen n*n-Tisch n WS2812 LedStripes mit jeweils n RGBs nehmen. Diese Stripes gibt es mit 30 oder 60 Leds, damit würden sich 33mm bzw. 16,5mm Kantenlänge der Quadrate ergeben. Bei 100Leds kannst Du die wohl noch in einer langen Reihe verschalten, dafür reicht Dir ein einziger Controller. Dieser Tisch sieht richtig cool aus, gute Idee! Gruß Stefan
Ich würde das einfach mit einer 485 machen. Ein ganz einfaches Protokoll. Die "LEDs" brachen ja noch nicht mal antworten. Jeder LEDcontroller reagiert auf zwei Adressen. Einmal eine eigene für jede LED zum Übertragen der RGB Werte, das währe das währe dann ja das 4 Byte Telegramm. Und ein weites Telegramm das nur aus einer broadcast Adresse besteht, zum gleichzeitigen Übernehmen der empfangenden RGB Werte zur Anzeige. Mit einem 9 Bit UART Mode macht man sich da das Leben einfach, das 9te Bit ist immer nur beim Adressbyte gesetzt. Da immer nur der Master sendet braucht da keine Richtungsumschaltung der 485 Treiber erfolgen. Auch keine Pause zwischen den Telegrammen, da kann alles in einen endlosen Strom übertragen werden. Bei den 485 Treiben, wie schon gesagt, auf die "1/4 bus-load" achten damit genug Bussteinehmer erreicht werden können. Oder beim Master einfach Sternförmig auf mehrere Treiber gehen die kürzere Busse treiben, ist einfach wenn der Master nichts empfangen muß.
Oh sorry das Teil hat ja noch Touch - das muss dann noch extra gelöst werden.
Bei solch moderaten Anforderungen sollte die Frage schon fast lauten: Welcher Bus kann das nicht? Gut, USB dürfte wohl hier an seine Reichweite gelangen, aber ab RS232 (12 - 15m) geht es wohl mit fast allen. Auch scheint das Datenvolumen recht gering zu sein, so dass auch dem "Drum prüfe wer ..." - bringt Overhead - nichts im Wege steht.
@Jürgen, der Master soll aber so wie ich das verstanden habe auch was empfangen, man soll nämlich auf die einzelnen kacheln auch drauf-touchen können
Mist mein Edit ist verloren gegangen :( Den Rückkanal habe ich erst später gelesen. Das würde ich mit einem zweiten Bus machen. Der Master stöst eine Abfrage mit einem Adresse 0 Telegramm an. Darauf wartet LED 1. Diese Antwortet mit ihrer Adresse und im 9ten Bit Daten über den Sensor. Darauf wartet LED2 die dann mit ihrer Adresse antwortet u.s.w Das geht deutlich schneller als alle LEDs zu pollen.
kevin schrieb: > Vielleicht wäre LIN für dich eine Alternative, nur ein Draht, LIN > Transceiver gibt es locker weit unter 1€ wie Sand am Meer und meines > Wissens kannst du das direkt über UART implementieren. So weit ich weiß kann LIN max 10 Slaves und bis 19 kbit/s. Das wäre also beides deutlich zu wenig. kevin schrieb: > @Jürgen, der Master soll aber so wie ich das verstanden habe auch was > empfangen, man soll nämlich auf die einzelnen kacheln auch drauf-touchen > können Genau, einen Rückkanal muss es auch geben. Der muss allerdings nicht viel übertragen (1x Touch an/aus pro Knoten).
Schon mal an den LPC11C24 von NXP gedacht? ARM Cortex M0 mit CAN-Controller und integriertem CAN-Treiber. Kostet z.B. bei Mouser 2,85€/Stk. @ 100Stk. mfg Thorsten
m.n. schrieb: > So würde ich es auch angehen, wobei als Bustreiber ein PCA82C250 > deutlich günstiger wäre und auch ein ATtiny2313 passen würde. Bei Mouser und Digikey ist der MCP2562 billiger als der PCA82C250. Zudem geht der MCP2562 auf der µC-Interface-Seite von 1.8V bis 5.5V Versorgungsspannung. Der ATtiny841 ist billiger als der ATtiny2313, hat mehr Speicher und deutlich bessere Peripherie. Unter Anderem hat er 4 16-Bit-PWM-Kanäle, was ihn für RGB-Ansteuerung sehr interessant macht.
Thorsten Krell schrieb: > Schon mal an den LPC11C24 von NXP gedacht? Schon mal an Schieberegister/SPI für den Rückkanal gedacht? Gut, bei einer 10x10 Matrix ist das nicht die tolle Bitanordnung, aber ein irgendein Dual-Core Prozessor wird die 13..20 Byte schon auseinander sortiert bekommen.
Ich frage mich gerade, auf welche Kosten man pro Knoten kommen kann. Bei 100 oder mehr Knoten kommt es ja quasi auf jeden Cent an. - Kleine Platine - µC - RGB LED - Transistoren zur LED Ansteuerung - IR LED und Sensor für die Touch-Funktionalität Ursprünglich hatte ich gehofft mit max 2€ hinzukommen, aber das wird wohl nix. Schade eigentlich :-(
kopfkratzer schrieb: > *kopfkratz* > Schonmal one-wire angesehen ? Kopflang - bei 190kbit/s?
:
Bearbeitet durch User
Boris P. schrieb: > Ursprünglich hatte ich gehofft mit max 2€ hinzukommen Also der kleinste LPC11C12 mit CAN-Controller+Transceiver kostet 2,50 16KB Flash sollte ja reichen ...
Boris P. schrieb: > Ursprünglich hatte ich gehofft mit max 2€ hinzukommen µC: ATtiny841 0.6007€@100 (DigiKey) CAN-Bus-Treiber: MCP2562 0.5446€@100 (DigiKey) RGB-LED: CLV1L-FKB 0.202€@100 (Mouser) Transistoren: nicht nötig Wird eng, könnte aber klappen.
Boris P. schrieb: > Ich frage mich gerade, auf welche Kosten man pro Knoten kommen kann. > Bei 100 oder mehr Knoten kommt es ja quasi auf jeden Cent an. > > - Kleine Platine > - µC > - RGB LED > - Transistoren zur LED Ansteuerung > - IR LED und Sensor für die Touch-Funktionalität > > Ursprünglich hatte ich gehofft mit max 2€ hinzukommen, aber das wird > wohl nix. Schade eigentlich :-( RGB-LED, Transistoren zur LED Ansteuerung mit Konstantstromquelle und µC für PWM gibt es als Meterware vom freundlichen Chinesen. Dazu braucht man von einem 5m-LED-Stripe (30 Stück WD2812B-LEDs pro Meter) die ersten 3,3 Meter. Die Kosten dürften unter 40€ liegen. Dazu kommt die lokale IR-Mimik und pro acht Felder ein Schieberegister für ein paar Cent, das die IR-Zustände per SPI von allen Feldern einsammelt und beim Master vorbei bringt - ganz ohne Adressierung. Da sollte doch was zu machen sein. Der Master muss sich dann ein bisschen um tun, um die WD2812-Ketten mit Daten zu versorgen.
A. K. schrieb: > kopfkratzer schrieb: >> *kopfkratz* >> Schonmal one-wire angesehen ? > > Kopflang - bei 190kbit/s? Es gibt den "Overdrive-Modus" da kommt man auf ca. 140kbit/s und man könnte den Master mit zwei Bussen bestücken ...
Boris P. schrieb: > Nun überlege ich, ob man sowas nicht auch etwas geschickter konstruieren > könnte (vor allem nicht 20kg Kupfer in Form von Leitungen verlegen). > Meine Idee war: alle Knoten (RGB LED + IR-Sensor) etwas intelligenter zu > machen, so dass diese nur noch über eine einzige Leitung > (Stromversorgung + Bus) als Kette verbunden werden müssen. Nutze die Topologie aus! Du hast dann nicht einen Bus mit 10m Länge, sondern 10 Busse mit 1m Länge und 11 Devices. Das sollte mit I2C noch machbar sein. Mit drei PCA9545(A|B|C) kannst Du die einzelnen Busse multiplexen und immer einen auf Deinen Controller schalten. Wenn Du auf PWM verzichtest, reicht für jede Kachel ein PCF8574(A) aus. Je ein Pin pro Grundfarbe plus ein Pin zum Zurücklesen des Touch-Signals. Zwei Pins pro Grundfarbe würden auch noch gehen, damit ließen sich dann insgesamt 64 Farben bei 4 Farbstufen pro Grundfarbe darstellen. Achtung! Du kannst maximal 8 PCF8574 an einen I2C hängen. Daher brauchst Du sowohl PCF8574 als auch PCF8574A (die haben eine andere I2C Basisadresse). Wenn Du die PCF8574(A) durch PCA9554(A) ersetzt, bekommst Du sogar einen Interrupt, wenn der Touch ausgelöst wird. Denke mal darüber nach. fchk
Lothar schrieb: > Boris P. schrieb: >> Ursprünglich hatte ich gehofft mit max 2€ hinzukommen > > Also der kleinste LPC11C12 mit CAN-Controller+Transceiver kostet 2,50 > > 16KB Flash sollte ja reichen ... 1,71 Euro. LPC11C22 Series 32 Bit ARM 32 Kb Flash Cortex-M0 Microcontroller - LQFP-48 -http://de.futureelectronics.com/de/technologies/semiconductors/microcontrollers/32-bit/Seiten/5006541-LPC11C24FBD48-301,.aspx?IM=0#sthash.yieImdI3.dpuf
Konrad S. schrieb: > Bei Mouser und Digikey ist der MCP2562 billiger als der PCA82C250. Bei meinem dt. Lieferanten kostet der PCA82C250 0,44ct@100. Der Tiny841 ist nicht schlecht, ein 2313 wäre (Konjunktiv) eine Option mit mehr Pins. Letztlich es aber egal. Den Hauptaufwand sehe ich eher bei den Platinen und der Software. Boris P. schrieb: > Ursprünglich hatte ich gehofft mit max 2€ hinzukommen, aber das wird > wohl nix. Schade eigentlich :-( Ich bin immer wieder verblüfft, was die Leute alles und viel haben wollen, was dann aber garnichts kosten darf! Mit Aufkommen der ersten PCs vor einigen Jahrzehnten hat man immer wieder Leute getroffen, die meinten: "Die Hardware war so teuer, die Software darf jetzt nichts mehr kosten." Das fällt mir immer wieder zum Thema 'billig' ein :-) Ich denke, die Realisierung wird an den mangelnden Erfahrungen mit Elketronik+µCs scheitern. Andernfalls wäre die Frage garnicht gestellt worden.
m.n. schrieb: > Ich bin immer wieder verblüfft, was die Leute alles und viel haben > wollen, was dann aber garnichts kosten darf! > Mit Aufkommen der ersten PCs vor einigen Jahrzehnten hat man immer > wieder Leute getroffen, die meinten: "Die Hardware war so teuer, die > Software darf jetzt nichts mehr kosten." Das fällt mir immer wieder zum > Thema 'billig' ein :-) Das Problem ist die Stückzahl. Bei mindestens 100 Knoten (könnten aber auch 200 werden), wäre ein preis von 1 bis 2 Euro noch akzeptabel. Wenn man den Knoten etwas großzügiger plant und mit 5€ rechnet, kostet der Spaß schon 1000€. -> Du siehst das Problem? m.n. schrieb: > Ich denke, die Realisierung wird an den mangelnden Erfahrungen mit > Elketronik+µCs scheitern. Andernfalls wäre die Frage garnicht gestellt > worden. So schlimm ist es garnicht. Ein bisschen Ahnung hab ich schon. Allerdings kenne ich mich eher auf der Softwareseite aus... Da das Projekt aber nicht sooo komplex ist und man hier im Forum immer Kompetente Hilfe bekommt, mache ich mir da keine Sorgen ;-)
Frank K. schrieb: > Bastler würden das sicher mit I2C versuchen. Den halte ich hier aber > aufgrund der hohen kapazitiven Last, der Länge des Busses und der Anzahl > der Knoten für ungeeignet. RS422/485 wäre hier besser geeignet. Mal nachgerechnet: * 100 Knoten, kapazitive Last je 5pF * 500ns Rise Time * Low Level 0V, High Level 3V Macht bei einer gesamten kapazitiven Last von 500pF insgesamt 1,5nC zum Umladen. Geteilt durch 500ns Rise time komme ich auf 3mA zum Treiben. Pullups also 1k. Ein LPC81xx kann mindestens 4mA am Pin nach Low treiben, Entladen geht also auch. Die Teile sind auch schön billig (deutlich unter 1 EUR) und lieferbar. Damit wäre ich für I2C oder (besser) SPI. Bei SPI kann man zwischendrin auch noch mal einen Treiber spendieren, falls es doch nicht reicht. Max
Boris P. schrieb: > Du siehst das Problem? Nein, das sehe ich nicht. Ich hätte ja auch gerne meinen Privat-Jet, der jedoch meine finanziellen Möglichkeiten übersteigt. Das ist aber kein Problem, ich kann auch ohne Flieger leben. Boris P. schrieb: > Da das Projekt aber nicht sooo komplex ist und man hier im Forum immer > Kompetente Hilfe bekommt, mache ich mir da keine Sorgen ;-) Du siehst doch, welch teilweise inkompetente Empfehlungen Du bekommen hast, die Deine Vorgaben einfach ignorieren. In der Praxis wirst Du sehen, dass Multibus auch 'Multi-Fehler' bedeutet. Das wird Dir nur Keiner sagen können, weil Keiner dies jemals zuvor gemacht hat. An anderer Stelle hatte ich dem TO empfohlen, zunächst eine einfach zu finanzierende Lösung für 5-10 Knoten umzusetzen. Dann kannst Du schon mal abschätzen, ob es überhaupt funktionieren kann und ob weitere finanzielle Ausgaben gerechtfertigt sind.
Boris P. schrieb: > Stefan schrieb: >> Was sollen denn die Controller alles können bzw. wieviel Pins brauchst >> Du? > > Eigentlich nicht besonders viel: 3xPWM um eine RGB Led anzutreben. Wie wärs dann mit DMX?
m.n. schrieb: > Nein, das sehe ich nicht. Ich hätte ja auch gerne meinen Privat-Jet, der > jedoch meine finanziellen Möglichkeiten übersteigt. Das ist aber kein > Problem, ich kann auch ohne Flieger leben. Du meinst also, man darf bei so einem Projekt nicht auf den Preis schauen? Und wenn es zu teuer wird, soll man es lieber gleich bleiben lassen? Sehe ich nicht so. Wenn man sich bei der Komponenten-Auswahl ein bisschen bemüht, kann man (gerade bei größeren Stückzahlen) viel Geld sparen. Daran sehe ich nichts Verwerfliches. Und so lässt sich das Projekt dann vielleicht doch realisieren... m.n. schrieb: > An anderer Stelle hatte ich dem TO empfohlen, zunächst eine einfach zu > finanzierende Lösung für 5-10 Knoten umzusetzen. Dann kannst Du schon > mal abschätzen, ob es überhaupt funktionieren kann und ob weitere > finanzielle Ausgaben gerechtfertigt sind. An sich natürlich ein sinnvolles Vorgehen. Nur sehe ich hier die Schwierigkeit, dass sich viele Probleme erst bei vollem Umfang (d.h. über 100 Knoten) zeigen werden. Was also mit wenigen Knoten noch wunderbar funktioniert hat, kann sich mit mehr Knoten als konzeptionelle Sackgasse erweisen.
:
Bearbeitet durch User
...diskutieren wir übrigens auch gerade hier zum gleichen Thema: http://www.mikrocontroller.net/topic/326455#new Die Frage ist auch, wie man das touch realisiert. Also IR oder kapazitiv? Und wenn IR mit was für einer Lösung (fertiger Proximity sensor? Eigene Schaltung mit Photodiode+OP+AD-Wandler)... Und das alles zu moderaten Kosten :-) Grüße Markus
Boris P. schrieb: > Du meinst also, man darf bei so einem Projekt nicht auf den Preis > schauen? Nein, man muß sehen, ob man sich seine Träume leisten kann oder nicht. > Was also mit wenigen Knoten noch > wunderbar funktioniert hat, kann sich mit mehr Knoten als konzeptionelle > Sackgasse erweisen. Anders herum: wenn es mit wenigen Knoten nicht funktioniert, hat man nicht eine Menge Material in den Sand gesetzt. Und wenn es funktioniert, hat man ein Muster, an dem sich einschätzen läßt, ob es erweiterbar ist. Es ist keine Funktionsgarantie, aber ein sinnvoller Ansatz zur Erprobung.
Boris P. schrieb: > m.n. schrieb: >> Nein, das sehe ich nicht. Ich hätte ja auch gerne meinen Privat-Jet, der >> jedoch meine finanziellen Möglichkeiten übersteigt. Das ist aber kein >> Problem, ich kann auch ohne Flieger leben. > > Du meinst also, man darf bei so einem Projekt nicht auf den Preis > schauen? Und wenn es zu teuer wird, soll man es lieber gleich bleiben > lassen? Sehe ich nicht so. Du kannst die Kosten reduzieren, wenn Du mehrere Kacheln zu einer Einheit zusammenfasst, zB 2x2, 3x3 oder 4x4. Letzteres ergibt nur 1/16 der Busteilnehmer, 1/16 der Controlleranzahl etc. Dazu kommt, dass zB die üblichen LED-Treiber meist 8 oder 16 oder teilweise auch 24 Ausgänge haben. Das kannst DU dann besser nutzen. fchk
Die Kommentare hier sind mal wieder zum Grausen. Der TO will seine Kosten im Rahmen halten (was jeder auch nur andeutungsweise vernünftige Ingenieur tut) und muss sich dafür blöd anmachen lassen. Der Ansatz, erst mal ein Dutzend LEDs laufen zu lassen und dann auf 100 hochzurüsten, erscheint allerdings vernünftig. Mit einem brauchbaren Oszi kann man ganz gut anschauen, wie die Signale mit mehr Busteilnehmern aussehen werden. Back to topic: du könntest auch den TLC5947 verwenden. Der kann 24 Kanäle PWM, du bräuchtest also 17 Stück davon. Allerdings wirst du dann in irgendeiner Form multiplexen müssen, der Baustein hat zwar eine serielle Anbindung, ist aber wohl nicht busfähig. Dafür hat er die Leistungsschalter an Bord, die du bei der µC-Lösung wohl extern spendieren müsstest. Es ist wie immer eine Abwägungsfrage. Nochmal zur SPI: ich finde es immer noch die sinnvollste Lösung. Du solltest dann aber die Adressierung über Bussignale statt CS-Leitungen machen, sonst wird es ein bisschen voll auf dem Board. Da du alle Bausteine selbst unter programmierst, ist das aber kein Problem. Es sollten nur nicht die MISO verschiedener µC gegeneinander treiben. Max
Markus M. schrieb: > ...diskutieren wir übrigens auch gerade hier zum gleichen Thema: > > http://www.mikrocontroller.net/topic/326455#new Das Thema scheint weg zu sein? Auch über die Suche komme ich nicht mehr dran...
Ja, keine Ahnung warum. Es gibt jetzt einen neuen Thread :-) Beitrag "LED Tisch mit Berührungs-/Gegenstandserkennung"
>ich suche einen Bus um mehrere µC zu vernetzen. Die µCs sollen in einer >langen Kette an den Bus angeschlossen werden. ......... >Gibt es da was bezahlbares? ......... Die kleinsten uCs mit UART kosten bloss 0,20..0,30eu, damit geht es schon. (Leitungstreiber optional)
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.