www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Mehrere PICs und EEPROM via I2C?


Autor: Darkleon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Micha (steinadler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Darkleon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Micha (steinadler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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]

Autor: Darkleon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Der Micha (steinadler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Darkleon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Darkleon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Micha (steinadler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Darkleon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Micha (steinadler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Darkleon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Micha (steinadler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Darkleon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Der Micha (steinadler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Darkleon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.