-
        
+ Antworten
Ergebnis 1 bis 9 von 9

Thema: 12F675 als Slave in einem I2C-Bus betreiben?

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    18.02.2004
    Ort
    Bonn
    Alter
    37
    Beiträge
    32

    12F675 als Slave in einem I2C-Bus betreiben?

    Hallo Leute,

    ich bin gerade dabei, meine Schaltung zu überarbeiten.
    Bis dato habe ich nur einen PIC 16F73 verwendet, der alle Aufgaben, wie Datenerfassung, RS232, I2C-EEproms, Displayansteuerung und Tasterabfrage erledigt hat. Dem ganzen sind natürlich Grenzen gesetzt, an die ich jetzt auch gestossen bin(keine Pins mehr frei, Programmspeicher voll...).
    Nun muss ich also wieder Platz schaffen. Dazu sollen die A/D-Wandlungen nicht mehr in einem PIC stattfinden, sondern für jeden Kanal möchte ich einen 12F675 verwenden. Die gemessenen Werte sollen über den schon vorhandenen I2C-Bus an einen 16F73 gesendet werden, der dann die Werte weiterverarbeiten kann.

    So, nun zu meiner Frage:
    Ist es möglich, den 12F675 als Slave an einem I2C-Bus zu betreiben?
    Der Master(16F73) bringt ja Hardwareseitig I2C-unterstützung mit, läuft auch wunderbar. Allerdings hat der 12F675 dieses Feature nicht. Rein theoretisch müsste man das ganze per Software hinkriegen, oder? Falls es laufen sollte, muß ich mit Performanceverlusten rechnen?

    Bin für jede Hilfe dankbar!


    Gruß

    Peter

    edit: Dat is en 16F73, nicht 16F76

  2. #2
    Benutzer Stammmitglied
    Registriert seit
    25.08.2004
    Ort
    Planegg
    Beiträge
    96
    Hi peterguy,

    warum soviel Mühe? Es gibt schon fertige I2C-AD-Wandler Bausteine, z.B. von Philips oder Texas Instruments. Schau doch erst mal da, vor du dir die Mühe machst, den I2C softwaremäßig nachzuprogrammieren.

  3. #3
    Benutzer Stammmitglied
    Registriert seit
    18.02.2004
    Ort
    Bonn
    Alter
    37
    Beiträge
    32
    Hmm, das ist natürlich auch eine Alternative. Eigentlich wollte ich von den Slave-PICs zwar auch noch andere Informationen, wie z.B. Name der Messstelle, übertragen und schon eine Skalierung der Messwerte vornehmen lassen. Aber diese Informationen kann man ja auch in einem EEprom speichern bzw. die Berechnungen den Master durchführen lassen.

    Von dem Plan, 12F675er als Slaves zu verwenden, bin ich mittlerweile eh abgekommen, das ist ohne Hardware-I2C zu schwierig umzusetzen. Habe da jetzt eher den 16F88 ins Auge gefasst.

    Ich werde wohl nicht umhinkommen, beide Varianten(ADS1100 von BurrBrown oder PIC 16F8 auszuprobieren um mich dann für die Bessere zu entscheiden.

    Danke dir für den guten Ratschlag,

    Gruß
    Peter

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    26.07.2004
    Beiträge
    15
    Hi,
    vor paar Monaten habe ich einen I2C-SLave mit dem PIC12F675 realisiert und deswegen kann ich aus eigener Erfahrung sagen, es ist möglich.
    Aber du wirst NICHT über den Hardware I2C des PIC16Fxxx kommunizieren können. Denn der Software-I2C wird bei einem internen Takt (des PIC) von 1MHz nicht schnell genug sein um die Speed des Hardware I2C zu erreichen. Aber wenn du den PIC12F675 extern taktest, mit sagen wir mal 10 MHz und einer geschickten Programmierung, dann würde es auch mit dem Hardware I2C funktionieren.

  5. #5
    Neuer Benutzer Öfters hier
    Registriert seit
    26.07.2004
    Beiträge
    15
    Nachtrag zu meinem vorhergehenden Thread:
    Vergesst das mit dem 10Mhz Takt. Ich vergass das der PIC einen internen Takteiler (1:4) hat. Um den internen Takt von 10MHz zu realisieren müsstet ihr ein 40MHz-Quarz einsetzen und das packt der PIC12F675 nicht.
    Also: Kommunikation mit dem Hardware I2C nicht möglich.

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.10.2004
    Ort
    Nordschwarzwald
    Alter
    33
    Beiträge
    506
    Prinzipiell ist I2C problemlos in Software realisierbar, aber auf dem 12F675 bekommst du nur die Low-Speed-Variante hin, d.h. läuft mit 100kBit. Die High-Speed-Variante bekommst du auf dem PIC nicht in Software hin. Problem bei der Software-Realisierung: dein PIC ist fast die ganze Zeit mit dem I2C beschäftigt, also große Rechenaufgaben schafft er nicht mehr nebenher...

    Was die verwendung von Soft-I2C und Hard-I2C angeht, so ist das kein Problem, sofern man den Master (der ja Hard-I2C haben sollte) auf die Low-Speed-Variante einstellt.

    Du solltest dir allerdings überlegen, ob du I2C wirklich in Software haben willst, denn aus eigener Erfahrung weiss ich, dass es zwar klappt, aber das Timing etwas kritisch ist. Wenn du daher ein paar Cent mehr übrig hast, dann nimm lieber einen größeren PIC mit Hardware-I2C.

  7. #7
    Benutzer Stammmitglied
    Registriert seit
    18.02.2004
    Ort
    Bonn
    Alter
    37
    Beiträge
    32
    Ok, habe mir eure Ratschläge zu Herzen genommen. Die Idee, den 12F675 zu verwenden ist nun entgültig gestorben(man muß ja nicht das Rad neu erfinden).
    Momentan arbeite ich an folgenden Alternativen:

    1. Der ADS-1100 von BurrBrown (I2C Baustein mit 12 bis 16bit AD-Wandlung) :
    Diesen habe ich mir als Sample bestellt, zwei Tage später waren 20 Stück in meinem Briefkasten...
    Leider habe ich mir das Datenblatt vorher nicht richtig angeschaut, und zwar haben die Bauteile nur die Größe eines Stecknadelkopfes(2x3mm)...
    Naja, nichtdestotrotz habe ich mich direkt ans Löten gemacht...
    Geschlagene 4 Stunden und 3 zerstörte Bauteile später war der Prototyp einsatzbereit und was soll ich sagen? Er funktionierte auf Anhieb!
    Das Problem besteht jetzt hauptsächlich darin, daß der Master auch noch die Linearisierungsrechnungen und Skalierungen übernehmen muß, was natürlich erheblich Performance kostet.
    Mal schauen, vielleicht kann man ja eine Tabelle in einem EEPROM speichern, dann müsste der richtige Wert nur noch ausgelesen werden?!

    2. Der PIC 16F88:
    Dieser 18-Pinner hat einen Hardware I2C und 5 10bit AD-Wandler. Ich habe mir davon zwar auch Samples bestellt, nachdem die oben beschriebene Variante jedoch so gut funktioniert, wird der 16F88 nur zum Einsatz kommen, wenns Probleme mit dem EEPROM geben sollte... Immerhin sind das ~6€ Unterschied pro Messstelle(bei geplanten 5 Einheiten also 30 €).
    Den einzigen Vorteil des PIC sehen ich in der Performance, da der ADS nur bis zu 128 Samples pro Sekunde schafft. Aber was für einen Sinn macht eine noch schnellere Abtastung bei Temperatursensoren??? [-(

    Ergo: Der einfachste Weg ist oft der Beste!


    So long

    Peter(Der sich jetzt einen SMD-Lötkolben kaufen geht )

  8. #8
    Gast
    Was ich standardmäßig verwende sind die 16F870...
    Die bieten genügend IOs, haben Hardware-I2C, Hardware UART, 5 AD's und kosten bei Farnell 3,60 EUR pro Stück... Wenn die 16F870 zu klein sind, nimmt man einfach einen größeren der 16F87X-Reihe... die sind alle Codekompatibel und man kann dann leicht auf den kleinsten gehn, den man braucht...
    Für dein Projekt sollte eigentlich ein 16F870 ausreichen...

    Wenn du Temperatur messen willst, kannst du dir mal überlegen, ob du nicht einfacher fertige Temperatursensoren nimmst... Gibts z.B. von Dallas... oder wenn du nicht ganz so genau messen musst, reicht dir auch ne Diode (ungenauer, weil man mit dem PIC wohl eher keinen ganz so großen Lookup-Table bauen will)... allerdings ist das etwas trickreicher und die Kennlinie ist absolut nicht linear.
    Es gibt auch fertige Temperatursensoren für I2C (schau da auch mal bei Dallas, Microchip und evtl. noch TI).

  9. #9
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    15.10.2004
    Ort
    Nordschwarzwald
    Alter
    33
    Beiträge
    506
    der Beitrag hier drüber war von mir...
    irgendwie hab ich ich vergessen mich an dem Rechner hier einzuloggen *g*

+ Antworten

Berechtigungen

  • Neue Themen erstellen: Ja
  • Themen beantworten: Ja
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •