Mehrere PICs und EEPROM via I2C?

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.

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]

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

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

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.

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.

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

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.