Hallo! Ich bin hier schon länger im Forum (passiv) tätig und zieh den Hut vor einigen Leuten hier! Wirklich Respekt für die Bemühungen und die tollen Ratschläge. Nun hab ich auch ein größeres Projekt vor und will mich mal erkundigen, ob mein Vorhaben überhaupt realisierbar ist. Also ich hab 3 Mikrocontroller und einen EEPROM. Einen für die USB Anbindung an den PC und für Schaltvörgänge direkt vom PC aus (wie eine Relaiskarte). Der zweite Pic ist für das weitere Steuern und der dritte Pic für das Überwachen einiger Signale verantwortlich. Die zwei letzteren sollen die aktuellen eingelesenen Werte (analog und digital) in den EEPROM schreiben und auch die Werte für das Steuern aus diesem beziehen. Ändern will ich die Steuerwerte über den PC mit dem USB Pic. Die drei Controller und der EEPROM sollten über I2C verbunden werden. Auch will ich die aktuell geschriebenen Werte via I2C vom USB Controller auslesen und am Pc anzeigen. Ist sowas prinzipiell möglich?? Die Einteilung am I2C Bus würde ich mir wie folgt vorstellen: USB Pic - Master Steueurungspic - Slave Überwachungspic - Slave EEPROM - Slave Nur kann ein Slave Pic aus dem EEPROM lesen und ihn auch beschreiben?? Hoffe hier bekomme ich mal Hilfe und es funktioniert dann irgendwie :) Freu mich schon auf Antworten. mfg Darkleon
Also es gibt da mehrere Möglichkeiten: 1. Du sendest alle Daten über den Master-Controller und der schreibt die dir dann ins EEPROM oder 2. Du nimmst PICs mit zwei I2C-Schnittstellen und definierst die EEprom-Schnittstelle als Multimaster. Ich würde die erstere Lösung bevorzugen (habe mit Multimaster keine Erfahrung). Hat allerdings den Nachteil, dass die EEprom-Daten über die doppelte Wegstrecke "geroutet" werden müssen.
Hi! Danke für deine schnelle Antwort. Ja die erste Möglichkeit klingt interessant, aber ich muss die Daten ja genau im EEPROM zuweisen, damit ich jederzeit weiß, welche Daten für was stehen. Wie mache ich das aber den Master klar, dass z.B.: die ersten Daten in die Speicheradresse x und die nächsten Daten in die Speicheradresse y kommen sollen? Und wie funktionert das dann mit Daten auslesen? Denn wenn der zweite PIC für das Ausführen von z.B.: einem PWM Signal die Werte vom EEPROM aus der Speicheradresse z auslesen muss, um das PWM Signal einstellen zu können muss die Anfrage ja an den Master gestellt werden, der muss das dann auslesen und an den betreffenden PIC weitergeben.... Da wäre dann der Code des Master PICs für alle Aufgaben ja riesengroß und wahrscheinlich sehr komplex... mfg Darkleon
Ich würde wohl auch die erstere Version vorziehen. Mit nur einem Master am Bus ist das Protokoll in meinen Augen einfacher. Achte aber auch darauf, dass manche PICs nur ein Slave Modul haben (z.Bsp. der 16F88). Solche PICs können nicht in den Mastermodus geschaltet haben, da bei Ihnen die Hardware für die I2C Takterzeugung fehlt. Und wenn die Daten sowieso zum USB-PIC laufen sollen, dann kann der die doch auch gleich ins EPROM schreiben. Frage wäre natürlich auch, ob ein größerer PIC mit einer höheren Taktrate nicht gleich alle deine Aufgaben bewältigen kann. Sven
Darkleon wrote: > Hi! > > Danke für deine schnelle Antwort. Ja die erste Möglichkeit klingt > interessant, aber ich muss die Daten ja genau im EEPROM zuweisen, damit > ich jederzeit weiß, welche Daten für was stehen. Wie mache ich das aber > den Master klar, dass z.B.: die ersten Daten in die Speicheradresse x > und die nächsten Daten in die Speicheradresse y kommen sollen? Du müsstest ein eigenes Protokoll definieren: so in etwa: fürs Schreiben: [ID für EEprom-Schreiben] [Ziel-Adresse] [Wert] [Prüfsumme] fürs Lesen: [ID für EEprom-Lesen] {Quell-Adresse] Anschließend sendet der Master ein Paket zurück, welches deine Daten enthält. Am besten auch wieder so wie oben: [ID für "von EEprom"] [Wert] [Prüfsumme]
@ Sven Stefan Ich wollte ja anfangs nicht, dass der USB PIC (Master) den ganzen Datenfluss übernehmen muss sondern die Daten die er am Pc anzeigen soll eben auch vom EEPROM bezieht, da aber die Slave PICs nicht in den EEPROM schreiben und lesen können muss dass wohl oder übel der Master übernehmen. Ein PIC allein kann das leider nicht übernehmen, da ich 14 analoge Eingänge, 22digitale Eingänge und 25 digitale Ausgänge benötige. Hinzu kommt noch PWM und solche Sachen.... @ Micha R. Das ist eine gute Idee. Aber hab ich das richtig verstanden? Also der Slave muss dem Master erklären, dass er in den EEprom mit der xyID den Wert z in den Speicher a schreiben soll. Wenn dann ein anderer Wert in eine andere Adresse gespeichert werden soll, dann eben mit geänderten Werten. Wie sieht so ein Protokoll aus?? In etwa so?? Slave sendet zum Master ein W für write. Master weiß jetzt, dass er was schreiben soll. Danach die ID des EEPROMS. Dann die Ziel Adresse und den Wert. Was ist aber die Prüfsumme?? Wird damit kontrolliert, ob die Daten richtig abgelegt wurden?? Wenn das alles geschehen ist gibt der Master den Bus wieder frei. Da ich eben durch meine ganzen Ein- und Ausgänge ein recht hohen Datenfluss hab bin ich mir nicht einmal sicher ob das funktioniert. Ich meine von der Geschwindikeit und der Abstimmung, vor allem sollte der USB Pic dann ja auch noch einige Daten vom EEPROM auch an den Pc senden, und dann noch für die Slaves lesen und beschreiben. Klingt ziemlich hektisch. Vorgestellt habe ich mir die Busgeschwindigkeit mit 400kHz. Ist das zuwenig oder kann man da keine Pauschalangaben machen. Die verwendeten Pics wären: USB - PIC 18F4550 Slave PICs 16F877A Noch eine kleine Frage zu EEPROM. Die Angaben sind ja meistens so. 256x8 (Speicherkonstruktion) ist das jetzt so, dass ich 256 Speicherzellen mit jeweils 8 bit Länge zur Verfügung habe? Wenn ja was mach ich mit 10-bit Werten...denn solche habe ich einige an den analogen Eingängen. Und kann man auch Werte mit Kommastellen speichern?? z.B.: 10,7?? Sorry, dass ich so viel Frage aber ich beschäftige mich erst seit einiger Zeit mit PICs und sowas mit I2C und EEPROM hab ich noch überhaupt mich gemacht. Bin für jede Antwort dankbar. mfg Darkleon
Darkleon wrote: > Das ist eine gute Idee. Aber hab ich das richtig verstanden? Mal schauen ... ;-) > Also der Slave muss dem Master erklären, dass er in den EEprom mit der > xyID den Wert z in den Speicher a schreiben soll. Wenn dann ein anderer > Wert in eine andere Adresse gespeichert werden soll, dann eben mit > geänderten Werten. Nicht ganz. Die "ID" ist so eine Art Paket-Kennzeichen. Du sendest ein Datenpaket (mit allen Daten: ID, Adresse, Wert, Prüfsumme). Die ID sagt dem Master, was er mit dem Paket machen soll; er soll nämlich die Daten des Paketes in die enthaltene Adresse schreiben. Eine weitere ID bräuchtest du z.B. um Messwerte auszutauschen. > Wie sieht so ein Protokoll aus?? Du musst hier erstmal eine stabile Übertragung zustande bringen. Also nach dem Motto: Device-Adresse+[r/w]|Byte1|Byte2|...|Byten Wenn das klappt, sendest du anstatt von Byte1-n deine "Paket-Bytes". Mit deinen Worten: 1. Master fragt Slave: Hast du was zu senden 2. Slave zu Master: sendet das Paket, ansonsten irgendwas anderes, (eine ID, die für "nichts" steht) (3. Master quittiert das ganze mit einem "okay"; oder auch nicht.) > Was ist aber die Prüfsumme?? Wird damit kontrolliert, ob die Daten > richtig abgelegt wurden?? Die Prüfsumme dient zur Übertragung. Es kann ja passieren, dass unterwegs mal ein Bit verloren geht. Angenommen du sendest |1|2|3|6| als Bytes. Also Prüfsumme nimmst du eine einfache Summenprüfung: ergibt 12. Der Master kann dann schauen, ob die Summe der Bytes mit dem Inhalt der Bytes zusammenpasst. > Wenn das alles geschehen ist gibt der Master den Bus wieder frei. So sollte es sein. > Da ich eben durch meine ganzen Ein- und Ausgänge ein recht hohen > Datenfluss hab bin ich mir nicht einmal sicher ob das funktioniert. Ich > meine von der Geschwindikeit und der Abstimmung, vor allem sollte der > USB Pic dann ja auch noch einige Daten vom EEPROM auch an den Pc senden, > und dann noch für die Slaves lesen und beschreiben. Klingt ziemlich > hektisch. Du weißt aber, wie oft man einen EEprom beschreiben kann? Und dass das unter Umständen auch paar ms dauert? > Vorgestellt habe ich mir die Busgeschwindigkeit mit 400kHz. Ist das > zuwenig oder kann man da keine Pauschalangaben machen. Kommt auf die Datenmenge und die Störfestigkeit deiner Schaltung an. > Noch eine kleine Frage zu EEPROM. Die Angaben sind ja meistens so. > 256x8 (Speicherkonstruktion) ist das jetzt so, dass ich 256 > Speicherzellen mit jeweils 8 bit Länge zur Verfügung habe? Wenn ja was > mach ich mit 10-bit Werten...denn solche habe ich einige an den analogen > Eingängen. Ja, so ist das. Für die 10bit-Werte nimmst du am besten zwei Byte und lässt die übrigen 6 mit Nullen füllen. Und kann man auch Werte mit Kommastellen speichern?? z.B.: 10,7?? Mit Komma vielleicht nicht. Aber du könntest ein Festkomma definieren. Also z.B. entspricht 1000 -> 10,00 > Sorry, dass ich so viel Frage aber ich beschäftige mich erst seit > einiger Zeit mit PICs und sowas mit I2C und EEPROM hab ich noch > überhaupt mich gemacht. Das wird dich auch noch lange beschäftigen ;-) Verlier nicht den Mut, wenn es ewig dauert, bis du was gängiges auf die Beine gestellt hast.
Darkleon wrote: > Ein PIC allein kann das leider nicht übernehmen, da ich 14 analoge > Eingänge, 22digitale Eingänge und 25 digitale Ausgänge benötige. Hinzu > kommt noch PWM und solche Sachen.... 16 analog in: 2 * 74HC4051 24 digital in: 3 * 74HC165 32 digital out: 4 * 74HC595 Benötigt vom MC: 5 dig. Out, 1 dig. In, 1 analog In Peter
Oder aber, da er ja schon I2C benutzen will und SPI und I2C auf den selben PINs liegen: 16 analog in: 1 * 74HC4067 24 digital in: 3 * PCF8574 32 digital out: 4 * PCF8574 Benötigt vom µC: 4 dig. Out + 1 analog in für den 4067 plus 2 Pins für I2C. Sven
Aber mal noch was zum Timing. Wie oft willst du denn die Ein- und Ausgänge pro Sekunde messen? Und wie oft sollen diese Werte in den EPROM geschrieben werden? Wie viel Daten soll der EPROM speichern können? Ich kenne derzeit I2C-EEPROMS nur bis 1024 kBit (das sind 128 kByte). Wenn du alle 14 analogen 10-Bit Werte einmal pro Sekunde abspeichern willst, dann sind das 28 Byte pro Sekunde plus die 3 Byte für die digitalen Eingänge, also 31. Sagen wir mal 32 wegen des Paging bei den Eproms. Du kannst also in einen 1024kBit Eprom 4096 solcher Datensätze schreiben, dann ist er voll. Macht rund 68 Minuten bei einer Messung pro Sekunde. Entsprechend mehr oder weniger, wenn du weniger oder häufiger messen willst. Reicht dir das? Falls du mehr willst müsstest du auf Flashspeicher ausweichen. Dann wird es aber wieder komplizierter... Sven
Hi! Wow, wirklich Respekt. Hier tut sich schnell einiges:) Also mal ein fettes Dankeschön für die Hilfe! Zu Peters Vorschlag: Zuest wusste ich ja nicht mal, dass es solche Multiplexer gibt, da ich neu auf diesem Gebiet bin. Trotzdem bleib ich wahrscheinlich bei meiner Variante mit den 3 PICs, da der Quellcode bei nur einem Pic sehr komplex wird und dieser sollte ja keinen Tastimpuls übersehen, oder erst zu spät die Motoren ausschalten, wenn diese z.B.: die Endschalter erreicht haben. @ Sven: Vielen Dank für Deine Bemühungen und ich denke das mit den Protokollen klingt logisch (obwohl ich noch nicht wirklich weiß, wie ich diese gestalten soll, da muss ich mich halt wieder einlesen ;)) Das mit dem EPROM ist so ne Sache. Also ich hab schon vor ca. jede Sekunde zu messen, nur sollten diese Daten nicht fortlaufend im Speicher abgelegt werden, sondern überschrieben werden. Also ich weiße den analogen Messwerten bestimmte Speicheradressen zu und genau dahin wird immer der aktuellste Wert der jeweiligen Messung geschrieben, denn die anderen Speicheradressen brauch ich um, z.b.: die PWM Geschwindigkeit, oder auch um festzulegen, ob der MikroC eine jeweilige Funktion ausführen soll oder nicht (aktivieren und deaktivieren). Diese würde ich dann per USB mit dem Masterpic festlegen und die Slavepics fragen diese dann über den Master ab, um zu wissen, was sie wann machen sollen und dürfen...Hoffe das war jetzt verständlich ;) Ich würde die Schreibzugriffe auf den EPROM insofern gering halten, als dass vorher vom Master überprüft wird, ob der im EEPROM gespeicherte Wert gleich ist wie der zu schreibende Wert, wenn ja dann müsste natürlich kein Schreibzugriff erfolgen. Da sollte der EPROM dann hoffentlich schon länger halten.. Wie definiere ich so ein Festkomma? Hab da nicht wirklich eine Idee. Nochmals Danke für die zahlreiche Hilfe :) mfg Darkleon
Also irgendwie klingt das für mich noch etwas unausgegoren. Das was du an Daten speichern willst und so wie du es beschreibst klingt für mich eher danach, als dass du deine Daten einfach im RAM des/der PICs ablegst. Warum willst du denn die ganzen Daten im EPROM ständig abrufen und speichern? Du hast doch in den PICs einige 100 Bytes frei, welche man normalerweise für solche Datenzugriffe benutzt. Du möchtest sicher bei einem Stromausfall die einzelnen aktuellen Messwerte sicher speichern. Dafür gibt es aber bessere Methoden. Z.Bsp. kannst du mit einer Diode und einem Elko den PIC dazu bringen, dass er im Falle eines Stromausfalles noch genug Zeit hat um die relevanten Bytes sicher in den EPROM zu schreiben. Das würde ich zumindest so machen. Während der Laufzeit deines Programmes werden die Daten im RAM gehalten und dort auch aktualisiert. Die sind dort genau so sicher aufgehoben wie im EPROM (zumindest solange Spannung anliegt). Und wenn du nur einige 100 Bytes Daten im EPROM sichern willst, dann reicht doch auch der interne EPROM des PICs. Dazu brauchst du doch keinen externen seriellen EPROM. Auch solltest du bedenken, dass der EPROM nur ca. 1Mio. mal beschrieben werden kann. Bei einem Schreibzyklus von einer Sekunde hättest du das nach ca. 14 Tagen erreicht und dein EPROM würde anfangen die Daten nicht mehr halten zu können. Vielleicht könntest du uns dein Projekt ja mal noch ein wenig näher beschreiben, dann könnten wir dir hier sicher noch bessere Hinweise geben. Aber nach dem was du bisher uns mitgeteilt hast, würde ich behaupten, dass dein Projekt mit nur einem PIC problemlos machbar ist und auch nicht allzu unübersichtlich wird. Ich glaube du unterschätzt die Leistungsfähigkeit der µC ein wenig. Und mehrere µC miteinender zu vertüddeln ist nicht unbedingt einfacher, da du für jeden ein Programm entwickeln musst und sich alle µC auch miteinender verstehen müssen. Das stelle ich mir echt schwieriger vor, wie ein paar duzend Messdaten zu erfassen und die Ausgänge zu schalten. Sven
Sven Stefan wrote: > Und mehrere µC miteinender zu > vertüddeln ist nicht unbedingt einfacher, da du für jeden ein Programm > entwickeln musst und sich alle µC auch miteinender verstehen müssen. Da muß ich zustimmen. Die Vernetzung mehrerer MC ist kein Anfängerprojekt. Und bei den PIC gibt es hinsichtlich des I2C eine erschwerende Besonderheit: Laut I2C-Standard muß ein Slave den SCL-Pin auf Low halten, bis er seinen I2C-Interrupt behandelt hat. Die Master-Hardware wartet automatisch solange, es kann also nie einen Datenverlust geben. Der I2C-Bus wartet immer auf den langsamsten Teilnehmer. Z.B. die 8051, AVR, ARM7 (Atmel, NXP) machen das. Aber die PIC haben den I2C-Standard nicht vollständig implementiert, d.h. wenn nicht innerhalb 90µs (100kHz Bustakt) der Interrupt ausgeführt wurde, sind die Daten im Eimer. Peter
Hi! Konnte mich leider in letzter Zeit nicht melden, da ich einfach keine Zeit dazu hatte. Also meine Steuerung wird in einem PKW verbaut und solle folgende Sachen überwachen und steuern: PIC 16F877A für die Überwachung: • Bordnetzspannung • PC Schaltzustand (Pc im Auto) • PC Temperatur • Lüfterbetrieb (3 Lüfter, die bei einstellbaren Temperaturen einschalten, falls der Lüfter 1 bei erreichen der Temp. 1 nicht einschaltet, wird der nächste Lüfter eingeschaltet. • Zündung • LIMA • Umgebungslicht (2 Sensoren) • Endstufe • TFT (Einschaltung) • Rückfahrsignal • TFT Schwenkbewegung • Handysteuerung • Zustand der Zentralverriegelung (gesperrt – geöffnet) PIC 16F877A für die Steuerung: • PC Schaltung • Lüftersteuerung • LED Taster • Taster • TFT Fahrbewegung • TFT Schwenkbewegung • TFT Betrieb • Rollo Fahrbewegung • Heckkamera (AV-Modus TFT) • Heckklappe • Taster Spannungsversorgung • Endstufe • Fahrlicht • Standlicht • Comming Home Funktion • Going Home Funktion • Handysteuerung Diese Werte möchte ich per USB und dem Master PIC 18F4550 verändern • Ansprechen der Spannungsüberwachung • Temperaturen der Lüftereinschaltung • Maximale Temperatur des Systems (Danach wird das System ausgeschaltet) • Ausfahrgeschwindigkeit TFT • Einfahrgeschwindigkeit TFT • Hochfahrgeschwindigkeit Rollo • Senkgeschwindigkeit Rollo • Öffnungsgeschwindigkeit Heckklappe • Blinkgeschwindigkeit (PWM) LED Taster • Anzahl der Blinkhäufigkeit des Tasters bei Fahrbetrieb • Anzahl der Blinkhäufigkeit des Tasters nach Zündungsbetrieb • Ansprechwert des Lichtsensors • Überwachung der Endstufe • Steuerung der Endstufe • Aktivität des Lichtmodus • Anzahl der Lüfter • Anzahl der Einschaltversuche PC • Aktivität der Einschaltversuche PC • Hard OFF Zeit des PCs • Tasterzuweisung • Wie der Pc ein – und ausgeschaltet werden soll, ( mit Taster-Taster, Taster-Zündung, Zündung - Zündung, Taster-Absperren, Zündung-Absperren, Aufsperren-Absperren, Aufsperren-Zündung, Aufsperren-Taster, usw..) • Aktivierung des TFT • Anzahl der Schwenkversuche des TFT • Aktivität der Handysteuerung • Aktivität der autom. Sperrfunktion des Autos • Zeitbegrenzung bis die Sperrfuktion aktiv wird • Aktivität der Comming Home Funktion • Verwendete Lampen für die Comming Home Funktion (Fahrlicht oder NSW) • Wann die Comming Home Funktion aktiv werden soll (jedes Mal oder nur wenn es dunkel ist) • Aktivität der Going Home Funktion • Verwendete Lampen der Going Home Funktion (Fahrlicht oder NSW) • Wann die Going Home Funktion aktiv werden soll (jedes Mal oder nur wenn es dunkel ist) Diese Werte sollen nach Verfügbarkeit ausgelesen und am Pc angezeigt werden • Temperatur des PCs • Bordnetzspannung • Anzahl der aktiven Lüfter • Aktiver Zustand des TFT • Aktiver Zustand der Endstufe • Aktiver Zustand des PC • Aktiver Zustand der Heckklappe • Aktiver Zustand der Heckkamera • Aktiver Zustand der Endschalter des TFT • Aktiver Zustand der Endschalter des Rollos • Wert des Lichtsensors • Aktiver Wert des Fahrlichts • Aktiver Wert der Zündung • Aktiver Wert der LIMA • Geöffnete Türen So ungefähr hab ich mir das vorgestellt und kann mir jetzt schwer vorstellen, dass das ein PIC übernehmen kann. Zwecks EPROM hab ich mir gedacht, dass dieser eigentlich nur die Werte (Z.B.: PWM geschwindigkeit speichern soll): Diese Werte verändere ich ja gegebenenfalls via Pc und dann müsste der PIC nur nochmal die aktuellen Werte einlesen, danach natürlich erst wieder bei der nächsten Veränderung (PICs bekommen jedesmal einfach einen Reset...kommt ja nicht so of vor) Nur wollte ich eben z.B.: wenn der 1. PIC (Überwachung) eine Unterspannung feststellt sollte dieser dies im EPROM in der Speicheradresse x mit einer 1 speichern, wenn alles in Orndung ist, dann steht in dieser Speicherzelle eine 0. Der 2. PIC (Steuerung) liest dies aus und wird in diesem Punkt aktiv. So hab ich mir das vorgestellt, nur eben für jede Funktion, damit ich dies auch mit dem Pc auslesen und den aktuellen Status der jeweiligen Funktionen betrachten kann. Nur bräuchte ich jetzt eben einen Speicher, der mir diese ganzen "Laufdaten" aufzeichnet und man über I2C darauf zugreifen kann. Und der natürlich länger als 14 Tage funktioniert ;) (Danke für den TIPP) Hoffe das war jetzt nicht allzu lang und ihr versteht was ich meine. Bin über jede Hilfestellung oder auch Kritik dankbar. Danke schon im Voraus. mfg Darkleon
Darkleon wrote: > Nur bräuchte ich jetzt eben einen Speicher, der mir diese ganzen > "Laufdaten" aufzeichnet und man über I2C darauf zugreifen kann. Und der > natürlich länger als 14 Tage funktioniert ;) (Danke für den TIPP) Hierfür gibts meherere Möglichkeiten. Entweder du verbaust nen externen RAM und eine Pufferbatterie oder aber du nimmst statt dem EEprom einen sogenannten FRAM. Ist zwar teurer aber dafür kannst du den viel öfter beschreiben. Und das ohne ein Delay wie bei den I2C-Eeproms. Die Dinger sind pin-kompatibel zum EEprom.
Danke für die schnelle Antwort :) Wie oft kann man so einen externen RAM beschreiben? Und braucht man unbedingt eine Pufferbatterie? die 12V Bordnetzspannung wär sowieso immer auf der Platine. Und zum FRAM: Wie kann man diesen denn beschreiben? Auch über I2C, weil du eben geschrieben hast, dass es kein Delay gibt?!? Wie oft kann man denn diese Dinger beschreiben?? Hab noch nie was davon gehört (zumindest vom FRAM). Hoffe ich frag nicht allzu "dumm" in der Gegend herum, aber ich muss mich erst mit all den elekrtonischen Bauteilen und ICs vertraut machen, da ich kein gelernter Elektroniker oder sonst was in der Richtung bin, mich aber seit einiger Zeit damit beschäftige und auch das Projekt über die Bühne bringen will :) Danke nochmals. mfg Darkleon
Darkleon wrote: > Wie oft kann man so einen externen RAM beschreiben? Und braucht man > unbedingt eine Pufferbatterie? die 12V Bordnetzspannung wär sowieso > immer auf der Platine. Ein Ram verliert seine Daten bei Spannungsausfall. Deshalb die Pufferbatterie. > Und zum FRAM: Wie kann man diesen denn beschreiben? Auch über I2C, weil > du eben geschrieben hast, dass es kein Delay gibt?!? Ist exakt gleich vom Protokoll her wie die EEproms. Nur dass der Vorgang schneller abgeschlossen ist. > Wie oft kann man denn diese Dinger beschreiben?? bis zu 10 Billionen mal.
WOW, danke für die Antwort. Das mit dem Spannungsabfall beim RAM wäre nicht so schlimm, da sich die PICs ja sowieso das selbst wieder beschreiben und ein Spannungsabfall erst eintreten würde, wenn ich die Batterie vom Auto ausbaue ;) Die sind aber sicher billiger als so nen FRAM!?? Beschreibt man einen externen RAM auch über I2C ?? und gibts da auch eine Einschränlung oder sind die immerwieder beschreib und löschbar?? Nochmals Danke für den wirklich guten TIPP :) mfg Darkleon
Darkleon wrote: > WOW, danke für die Antwort. > > Das mit dem Spannungsabfall beim RAM wäre nicht so schlimm, da sich die > PICs ja sowieso das selbst wieder beschreiben und ein Spannungsabfall > erst eintreten würde, wenn ich die Batterie vom Auto ausbaue ;) > > Die sind aber sicher billiger als so nen FRAM!?? > > Beschreibt man einen externen RAM auch über I2C ?? und gibts da auch > eine Einschränlung oder sind die immerwieder beschreib und löschbar?? > > Nochmals Danke für den wirklich guten TIPP :) > > mfg Darkleon Also für externe Rams habe ich keine Empfehlung. Allerdings bringen einige Pics (PIC18) einen Port zur Verwendung eines ext. Speicherinterface mit (8/16 Bit). Beschreiben kannst du einen RAM sooft du lustig bist. Ein FRAM kostet glaube so um die 10 €. Kannst auch probieren, ob du bei R.A.M.T.R.O.N ein Sample bekommst. Gruß Michael
Also nur weil da jetzt viel steht, heißt das noch lange nicht, dass das dein 18F4550 nicht auch alleine schafft. Der hat schließlich 32kByte Flash und 2kByte RAM (wobei davon einiges für USB verbraucht wird). Mit den schon genannten Hinweisen für das analoge Multiplexen und die digitalen Busexpander sollte die Signalverarbeitung kein Problem darstellen, da es sich zeitlich auch alles im Rahmen bewegt. Ich sehe allerdings bei dieser Anwendung ein ganz anderes Problem: Du wirst dir viel mehr Gedanken über die Signalgewinnung an den beschriebenen Einheiten machen müssen als über die Signalverarbeitung im PIC. Außerdem wirst du enorme Probleme mit der Filterung der Boardspannung haben, da die Spannung in einem PKW alles andere als stabil und EMV verträglich ist. Mit unerwünschten Nebeneffekten solltest du also von Anfang an rechnen und diese bei der Schaltungsplanung mit einbeziehen. Und um noch mal auf den Speicher zurück zu kommen. Wir haben ja schon festgestellt, dass für die reine Speicherung der Messwerte 32 Bytes völlig reichen. Wenn du nun noch einmal 100 Bytes für die Programmausführung dazu rechnest und du deine Konfigurationswerte (welche du nur bei einer Änderung deiner Einstellungen) im EEPROM des PICs ablegst, dann hast du immer noch genügend Luft im 4550. Hast du denn mal überschlagen wie viel Bytes du tatsächlich für dein Vorhaben benötigst? Und möchtest du die Daten nun mitloggen oder geht es dir nur um die Speicherung eines momentanen Zustands? Das solltest du von Anfang an trennen. Laufzeitvariablen gehören in den RAM des PICs und Logdaten auf einen externen EEPROM oder Flash. Konfigurationsdaten die auch nach Spannungsausfall benötigt werden kannst du im EPROM des PICs ablegen. Aus meiner Sicht ist das Projekt mit einem 4550 bei 20 MHz problemlos machbar auch wenn es dir im Moment anders erscheinen mag. Sven
@ Micha R. Danke für deinen tollen TIPP, das ist wirklich eine tolle Alternative und wahrscheinlich auch die einzig (für mich) umsetzbare Lösung. @ Sven Mir gefällt dein Optimismus gut, vor allem auch die Aussage, dass das der 18F4550 auch alleine schafft, da ich mir auch dadurch einiges an Geld und "I2C-Nerven" sparen würde :) Also die Signalgewinnung hab ich schon hinter mir, da ich alle relevanten Kabel im Auto schon verlegt und angeschlossen habe. Nur wie ich diese auf mikroC Pegel "transformiere" mache ich mir derzeit noch Gedanken. Das mit der Spannungsversorgung ist eigentlich auch kein Problem, da für den Pc-Betrieb ein eigenes Netzteil in Auto kommt, das mir ein absolut geregeltes und gefiltertes Output gibt mit 12V, 5V und 3,3V. An diesem habe ich noch genug Reserven, sodass ich die mikroC Steuerung auch versorgen kann. Eine Berechnung des Speichers hab ich noch nicht gemacht, da ich immer von einem externen Speicher mit genug Reserven ausgegangen bin, um eventuelle Erweiterungen später noch hinzuzufügen. Ich kann mir aber wirklich schwer vorstellen, wie das der 18F schaffen soll. Immerhin betreibe ich für das TFT, das Rollo und die Heckklappe 5 Servomotoren aus dem Modellbau. Diese müssen immer exakt auf deren Endschalter stehenbleiben. gleichzeitig darf der mikroC keinen Tastimpuls von 5 Tastern "übersehen" und sollte bei den jeweiligen Inputs auch so schnell wie möglich reagieren...z.B.: Umgebungslicht Zusätzlich will ich ja die veränderbaren Werte über ein Menü, das ja auch der 18F aufbereiten muss am Pc eingeben können und auch im laufenden Betrieb soll der ja immerwieder die Laufzeitdaten an den Pc übermitteln. Mittloggen will ich mal zur Zeit nichts, sondern nur die Variablen für den jeweiligen Zustand eines Signals oder einer Komponente speichern. So eine Software für nur einen PIC trau ich mir (momentan) nicht zu. Ach ja und eine Art Relaikarte, will ich auch noch realisieren. Also Ausgänge per Pc schalten.... Tut mir leid Sven, aber ich kann mir das alles nicht vorstellen, wäre aber froh, wenn Du mich eines besseren Belehrst :) So long, Darkleon
Na dann rechnen wir doch mal etwas nach. Ein PCF8574 (8-Bit I2C I/O Busexpander) benötigt für das Auslesen bzw. das Schalten seiner 8 Aus-/Eingänge 18 Bit (8Bit Adresse, 8 Bit Daten, 2x ACK) * 10µs (der läuft leider nur mit 100kHz I2C Takt) 180µs wir runden mal auf 200µs = 0,2 ms auf. Bei 8 solcher ICs für Ein- bzw Ausgänge wären das 1,6ms. Wenn du bei den ICs für die Eingänge die Interruptleitungen benutzt, könnten dir Eingänge also innerhalb einer Millisekunde abgefragt werden und die Ausgänge umgeschaltet werden. Ein 20MHz getakter PIC kann in dieser Zeit 4000 Befehle ausführen. Da ist also noch Luft. Der ADC benötigt pro Messung ca. 100µs. Das macht bei 16 Eingängen auch ca. 1,6ms. Hier musst du allerdings pollen, da der ADC keinen Interrupt bei einer Veränderung des Signals auslösen kann (er misst ja auch immer nur eine der 16 Leitungen). Allerdings könntest du jeden Eingang 500 mal in der Sekunde messen und entsprechend auswerten. Die Messung selbst läuft über Interrupt. Also immer wenn der ADC fertig ist mit messen, gibt er Bescheid und du wertest die Messungen aus und schaltest den Eingang weiter. Wenn dann der nächste Timerinterupt kommt startest du die nächste Messung für den vorher umgeschalteten Eingang (aquisition time im Auge behalten!). Auf Helligkeitsschwankungen könntest du also innerhalb 2ms regieren. Ebenso auf Veränderungen an den digitalen Eingängen. Deine Reaktionszeiten sind aber nicht in erster Linie durch die Befehlsabarbeitungsgeschwindigkeiten des PICs definiert (der sollte das schaffen) sondern durch deine Buslaufzeiten am I2C bzw. die Messzeiten des ADC! Und da wirst du auch nicht schneller, wenn du das auf mehrere PICs aufteilst, da diese auch an diese Zeiten gebunden sind. Bleibt nun noch USB. Da kenne ich mich aber leider noch nicht aus. Solange du aber nur Text an deinen PC sendest, sollte sich das zeitlich auch in Grenzen halten. Schwieriger könnte ich mir vorstellen, ist es ganze Blöcke möglichst schnell an den PC zu senden. Wobei ich nicht weiß, ob der PIC in der Lage ist einen ganzen Datenblock im Hintergrund per USB zu senden bzw. zu empfangen oder ob er auch jedes Byte durch das W Register jagen muss. Das werde ich mir mal anschauen müssen.... Ach ja und PWM für die Motoren. Da muss ich aber passen. Mit PWM habe ich mich noch nicht beschäftigt. Da gibt es aber sicher auch ICs, welche sich über I2C steuern lassen und dir den ganzen PWM Kram und die Brückenumschaltung abnehmen, so das du nur noch kurze Steuerbefehle an diese ICs senden musst. Der zeitlich langsamste Teil ist die Menüsteuerung und die Tastaturabfrage für diese Steuerung. Hier reicht es völlig die Tasten alle 10ms abzufragen und die Daten bei einer Änderung ans Display zu senden. Aber Überschlag es ruhig mal selbst und probier doch erst mal einen Versuchsaufbau. Dann wirst du ja sehen ob das klappen könnte oder ob du mit deiner 3 PIC Lösung besser fährst. Gruß Sven
Also ich finde es ein schönes Projekt. Sicher schafft auch ein einziger PIC, aber das Verwenden mehrerer hat eben den Vorteil, dass der Code pro Controller nicht ganz so groß wird und es entfällt die Hardware für MUXer und Schieberegister. Die Geschwindigkeit auf dem BUS wird allerdings wirklich ein Flaschenhals. Da der USB-Controller der Master sein soll, muss er immer erst eine Anfrage an die Slaves stellen und anschließend die Antwort abwarten. Dies muss immer zyklisch geschehen.
Bezüglich des Speichers wäre da ja noch die Möglichkeit ein SD Steckplatz zu verwenden. SD Karten sind sehr günstig und über SPI einfach anzusprechen. Die Wiederbeschreibbarkeit sollte auch nicht das Problem sein, vorallem, da man bei z.B. 1GB Speicher ja nicht immer auf den gleichen Speicherplatz zugreift, sondern rotieren kann.
Hallo! @Sven Ja das ganze ist jetzt (für mich) eher vorstellbar. Nur das PWM Signal wird glaub ich schwierig zum umsetzen sein, denn wenn ich dieses auch multiplexe, dann ist noch immer das Problem, dass z.B.: zwei Motoren mit einem fixen PWM-Signal fahren, der dritte Motor dann plötzlich gebraucht wird und dieser mit einem variablen PWM-Signal betrieben werden muss und dann vielleicht noch gleichzeitig der 4. Motor, in der zwischenzeit sollten die ersten beiden z.B.: wieder stehenbleiben. Da das total unterschiedlich auftreten kann, kann ich auch ncihts über eine Zeitsteuerung machen. Ich bräuchte also einen PWM-Multiplexer, der mir das PWM-Signal in der aktuellen Geschwindigkeit beibehält, obwohl ich das PWM-Steuersignal weggebe. Vor allem hab ich am PIC ja nur 2 PWM-Ausgänge und bräuchte dann 5 davon.... Das mit USB denke ich wird kein Problem, da ich meistens nur einzelne Zahlen an den Pc sende und der mir das dann umrechnet oder eben die gewünschte Aktion ausführt. @Chris Danke für Deinen Tipp. Davon hab ich auch schon gelesen und diese Variante wäre auch interessant, allerdings nur, wenn ich mehrere PICs verwende, da ich sonst (bei nur einem PIC) die "Standardwerte" in einen EPROM schreibe und mir der PIC diese ausliest. Denke mal, dass wenn das System irgendwann mal richtig läuft ich nur sehr selten Werte ändern muss. (Vielleicht 1x die Woche) Weiß hier jemand, ob man das Problem mit den PWM-Signalen mit Multiplexern (oder sonst was) lösen kann, oder brauch ich einfach mehrere PWM-Steuersignale?? Hoffe ihr habt mich verstanden und ihr könnt mir helfen. Danke schon im Voraus. mfg Darkleon
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.