mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PIC 18LF4550: Diskussion über Konzept: Eure Meinung, bitte!


Autor: Markus J. (doc_database)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo beisammen,

ich konzeptioniere gerade ein Steuergerät mit einem PIC 18F4550 I/P 
(PDIP 40).
Es soll über einen Steuerbus (I²C) Beleuchtungsobjekte ansteuern.
Wegen der Überlänge benutze ich zur Übertragung CAN-Hardware, also 
differentielle Signalübertragung.
Soweit, so gut. Es funktioniert.

Ich möchte das Ganze jetzt schrittweise erweitern, und stelle daher das 
Konzept zur Diskussion; ich habe mit 8051 angefangen und bin noch recht 
neu mit den PIC.

Bisher hatte ich meistens die Aufgabe, eines der Peripherien alleine 
oder nacheinader zu nutzen.
Bei der jetztigen Aufgabe wäre ich um ein bißchen Unterstützung, sprich 
Zustimmung oder konstruktive Kritik sehr dankbar.

Um es kurz zu machen:

Ich programmiere in C und nutze die von Microchip zur Verfügung 
gestellten Bibliotheken.
Wieso 18F4550? bekannt, aktuell, vielfältig einsetzbar
I²C? Ich benutze die Hardware des PIC, und möchte mit 400kHz einen I²C - 
Hub (PCA9518DWR) ansteuern. Dies wegen der unterschiedlichen 
Geschwindigkeiten der einzelnen Abgänge.

Welche Geräte hängen am I²C?
Beleuchtungsobjekte(100kHz und weniger), RTC (DS1307)(100kHz), Licht-& 
Temperatursensor (100kHz und weniger), Grafikdisplay (100kHz, SED1530, 
LCD-Modul Epson E0855-2)

Wozu RTC?
Um 1Hz auf den PIC zurückzukoppeln. Ich möchte den PIC nicht mit 
dererlei zeitraubenden Aufgaben beanspruchen. 1Hz um alle 10 Sekunden 
wieder ein Ereignis auszulösen an RB7, Interrupt-on-Change
[Edit: missverständlich: Ein Ereignis (Interupt) wird selbstverständlich 
sekündlich ausgelöst, gemeint war eine Änderung am Beleuchtungsobjekt, 
das alle 10 Sekunden eintreten soll]
Der PIC kann einen zweiten Takt verarbeiten, z.B. einen Uhrenquarz, aber 
alles schön langsam und schrittweise. Soweit bin ich einfach noch nicht.

Was noch?
Rotary Encoder A&B an RB4 & RB5, Interrupt-on-Change, keine 
Flankensteuerung, Taster des Rotary Encoder an RB6.
Hier auch die Möglichkeit, den Encoder über I²C abzufragen, zum Beispiel 
über einen PCF8574, gesehen in [[Using Rotary Encoders
as Input Devices] 
http://www.circuitcellar.com/library/print/0303/mi...] 
, Seite 6

Hat damit schon jemand Erfahrungen gemacht?

Wie gesagt, ich fühle mich nicht als Einzelkämpfer und würde gerne eure 
Meinung dazu hören.
Was kann man anders machen, was ist falsch oder unklug?

Ich habe die Bitte an euch, das genauso gut zu erklären und zu 
begründen, wie bisher auch schon in diesem Forum geschehen, damit auch 
andere daraus lernen können.
Ich möchte ausdrücklich nicht die Arbeit auf das Forum abwälzen, 
sondern die Plausibilität meiner Gedankengänge mit anderen abgleichen.

Besten Dank!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Markus J. (doc_database)

>Wozu RTC?
>Um 1Hz auf den PIC zurückzukoppeln. Ich möchte den PIC nicht mit
>dererlei zeitraubenden Aufgaben beanspruchen. 1Hz um alle 10 Sekunden

???
Das macht ein Timer nebenbei.

AVR - Die genaue Sekunde / RTC

>Rotary Encoder A&B an RB4 & RB5, Interrupt-on-Change,

Eher Schlecht. Das ist auch ein Job für den Timer-Interrupt.

Drehgeber

>Hier auch die Möglichkeit, den Encoder über I²C abzufragen, zum Beispiel
>über einen PCF8574, gesehen in [[Using Rotary Encoders

Kann man machen, ist aber um Grössenordungen langsamer als an direkten 
Portpins. Und durch den I2C wird relativ viel Overhead erzeugt.

MfG
Falk

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine timerbasierte 1Hz Uhr ist zeitraubend??? Kann's extern verstehen, 
wenn Strom irgendwie gepuffert sein muss, das ist extern teils einfacher 
als intern, aber dieses Argument ist bizarr.

Autor: Markus J. (doc_database)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:
> Eine timerbasierte 1Hz Uhr ist zeitraubend??? Kann's extern verstehen,
> wenn Strom irgendwie gepuffert sein muss, das ist extern teils einfacher
> als intern, aber dieses Argument ist bizarr.

Später soll auch die Uhrzeit ausgewertet werden, daher die externe RTC.
Ich weiß, das der PIC eine eigene RTC hat, aber ich trau mich an diese 
Hardware NOCH nicht ran.
Die externe RTC ist gepuffert.
Und der PIC kann auch gepuffert werden, halt im Nano-Watt-Modus, aber 
soweit bin ich noch nicht mit meinem Wissen. (ich widerhole mich ungern 
:-)) )
Ich weiß, das diese Lösung etwas "anders" ist...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus J. wrote:

> Es soll über einen Steuerbus (I²C) Beleuchtungsobjekte ansteuern.
> Wegen der Überlänge benutze ich zur Übertragung CAN-Hardware, also
> differentielle Signalübertragung.
> Soweit, so gut. Es funktioniert.

Kannst Du mal erläutern, wie?

CAN-Controller haben doch separate RX und TX-Pins, I2C-IC sind aber 
bidirectional, wie kann man denn da CAN-Transceicver anschließen?


> Wieso 18F4550? bekannt, aktuell, vielfältig einsetzbar

Also ich kenne ihn nicht.
Er hat halt die Krankheit, wie alle PICs, daß Interruptquellen keine 
eigenen Vektoren haben. Man hat also nur einen großen Interrupthandler, 
in dem man erst mühsam die Interruptquellen auseinander pflücken muß, 
das kann dauern.


> I²C? Ich benutze die Hardware des PIC, und möchte mit 400kHz einen I²C -
> Hub (PCA9518DWR) ansteuern. Dies wegen der unterschiedlichen
> Geschwindigkeiten der einzelnen Abgänge.

Ich halte I2C nicht für größere Netze geeignet.


> Wozu RTC?
> Um 1Hz auf den PIC zurückzukoppeln. Ich möchte den PIC nicht mit
> dererlei zeitraubenden Aufgaben beanspruchen.

Zeitraubend keinesfalls.
Aber wenn Du den Programmieraufwand scheust, ist das o.k.

Ich persönlich finde es allerdings weniger aufwendig, Zeit und Datum 
direkt in Variablen zu halten, anstatt alles erst umständlich durch den 
I2C-Bus hin (Uhr stellen) und zurück (Uhr auslesen) zu tunneln.


> Der PIC kann einen zweiten Takt verarbeiten

Du meinst warscheinlich Task.
Ich setze bei größeren Projekten auch gerne einen Scheduler ein, der 
dann viele zeitabhängige Tasks quasi gleichzeitig abarbeitet.
Das erspart unnütze Warteschleifen als Performancekiller.


> Rotary Encoder A&B an RB4 & RB5, Interrupt-on-Change, keine
> Flankensteuerung, Taster des Rotary Encoder an RB6.
> Hier auch die Möglichkeit, den Encoder über I²C abzufragen, zum Beispiel
> über einen PCF8574

Da könnte bei schnellem Drehen dem I2C aber die Puste ausgehen. Du 
willst ja noch vieles andere am I2C machen.

Für Encoder abfragen und Tasten entprellen nehme ich immer nen 
Timerinterrupt, ist Code- und Zeitsparend.


> Hat damit schon jemand Erfahrungen gemacht?

Wie gesagt, mit PICs: null, nada.
Bei 8051 und AVR könnte ich helfen.


Peter

Autor: Markus J. (doc_database)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:
> Markus J. wrote:
>
>> Es soll über einen Steuerbus (I²C) Beleuchtungsobjekte ansteuern.
>> Wegen der Überlänge benutze ich zur Übertragung CAN-Hardware, also
>> differentielle Signalübertragung.
>> Soweit, so gut. Es funktioniert.
>
> Kannst Du mal erläutern, wie?
>
> CAN-Controller haben doch separate RX und TX-Pins, I2C-IC sind aber
> bidirectional, wie kann man denn da CAN-Transceicver anschließen?
>

Es gibt dazu ein AN: [AN460
Using the P82B96 for bus 
interface[http://www.standardics.nxp.com/support/documents/i...]]
Darin ist beschrieben, wie man CAN - Transceiver für I²C benutzt. Es 
wird lediglich die Hardware dazu benutzt, aber nicht das Protokoll.
>
>> Wieso 18F4550? bekannt, aktuell, vielfältig einsetzbar
>
> Also ich kenne ihn nicht.
> Er hat halt die Krankheit, wie alle PICs, daß Interruptquellen keine
> eigenen Vektoren haben. Man hat also nur einen großen Interrupthandler,
> in dem man erst mühsam die Interruptquellen auseinander pflücken muß,
> das kann dauern.

stimmt. Aber was ist schon perfekt?

>
>
>> I²C? Ich benutze die Hardware des PIC, und möchte mit 400kHz einen I²C -
>> Hub (PCA9518DWR) ansteuern. Dies wegen der unterschiedlichen
>> Geschwindigkeiten der einzelnen Abgänge.
>
> Ich halte I2C nicht für größere Netze geeignet.

stimmt auch. Bei I²C muss man bei größeren Netzen daraug achten, das die 
Laufzeiten durch das Kabel und zurück zum Sender an die 
Übertragungsfrequenz angepaßt wird, damit auch eine kurze Antwort der 
letzten Node registriert wird.
Bei I²C, also dem ganz reinen I²C ohne Umsetzter und sowas, hat man 
zustätlich das Problem, das man über die kapazitiven Einflüsse des 
Kabels Verschleifungen des Signals bekommt.
Das kommt daher, das die Spannung klein ist (5V in der Regel, aber auch 
3,3 Volt möglich) und die Ströme damit auch gering sind.

>
>
>> Wozu RTC?
>> Um 1Hz auf den PIC zurückzukoppeln. Ich möchte den PIC nicht mit
>> dererlei zeitraubenden Aufgaben beanspruchen.
>
> Zeitraubend keinesfalls.
> Aber wenn Du den Programmieraufwand scheust, ist das o.k.
>
> Ich persönlich finde es allerdings weniger aufwendig, Zeit und Datum
> direkt in Variablen zu halten, anstatt alles erst umständlich durch den
> I2C-Bus hin (Uhr stellen) und zurück (Uhr auslesen) zu tunneln.

Kommt noch. Eine RTC im PIC zu realisieren ist mit Sicherheit möglich. 
Da ich allerdings im Augenblich sowieso mit der I²C Bibliothek arbeite, 
geht es auch so.
Mit diesem Zwischenschritt ist der Entwurf zwar nicht so kompakt, aber 
ich komme schneller vorran.

>
>
>> Der PIC kann einen zweiten Takt verarbeiten
>
> Du meinst warscheinlich Task.
> Ich setze bei größeren Projekten auch gerne einen Scheduler ein, der
> dann viele zeitabhängige Tasks quasi gleichzeitig abarbeitet.
> Das erspart unnütze Warteschleifen als Performancekiller.
>
Mit Task kann ich jetzt gerade nichts anfangen.
Also: der PIC kann mit zwei Oszilatoren erbeiten.
Laut Manual ist dies primär dafür gedacht, wenn der PIC in den 
Energiesparmodus geht und damit heruntergetaktet wird.
Weitehin kann man diese Option natürlich auch benutzen, um eine RTC zu 
realiseren.

>
>> Rotary Encoder A&B an RB4 & RB5, Interrupt-on-Change, keine
>> Flankensteuerung, Taster des Rotary Encoder an RB6.
>> Hier auch die Möglichkeit, den Encoder über I²C abzufragen, zum Beispiel
>> über einen PCF8574
>
> Da könnte bei schnellem Drehen dem I2C aber die Puste ausgehen. Du
> willst ja noch vieles andere am I2C machen.
>
> Für Encoder abfragen und Tasten entprellen nehme ich immer nen
> Timerinterrupt, ist Code- und Zeitsparend.
>
Ich fand die Idee recht pfiffig, weil ich das Display und die Tasten im 
Gehäuse absetzten möchte und kein Freund von vielen Strippen bin.
Daher auch die Ansteuerung des Displays uber I²C.
Den Encoder über I²C abzufragen ist bestimmt nicht so einfach, denke 
ich.
Wie schon im Artikel über Drehgeber erwähnt, sollte man  / muss man den 
Drehgeber mit dem 4-fachen der möglichen Impulsrate abfragen, um 
vernünfitige Ergebnisse zu bekommen.
Wie gut das über I²C geht, kommt auf einen Versuch an.
Wie gesagt, ich habe es noch nicht ausprobiert und kenne es lediglich 
aus dem Schaltungsvorschlag.
Zu den I²C Leitungen wäre dann bloß noch eine weitere Strippe nötig, auf 
der ich den /INT des PCF8574 zum µC führe.

>
>> Hat damit schon jemand Erfahrungen gemacht?
>
> Wie gesagt, mit PICs: null, nada.
> Bei 8051 und AVR könnte ich helfen.
>
>
> Peter

Das ist nicht so wichtig: Die Artikel über das Entprellen von Tasten und 
viele andere Artikel hier sind vom Ansatz her sehr gut, sodass man es 
auch auf andere µC portieren kann.
Etwas Ahnung von der Materie vorrausgesetzt.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Markus J. (doc_database)

>> in dem man erst mühsam die Interruptquellen auseinander pflücken muß,
>> das kann dauern.

>stimmt. Aber was ist schon perfekt?

Nichts. Aber viele Controller sind wesentlich besser als die PICs ;-)
Flame on!

>> Ich halte I2C nicht für größere Netze geeignet.

>stimmt auch. Bei I²C muss man bei größeren Netzen daraug achten, das die
>Laufzeiten durch das Kabel und zurück zum Sender an die
>Übertragungsfrequenz angepaßt wird, damit auch eine kurze Antwort der


;-))

Du bist lustig. Schon mal überlegt, wie lange ein Kabel sein muss, damit 
Laufzeiten eine Rolle spielen? Mal so ein Tip.

Signallaufzeit auch einem Kabel ist ca. 5ns/m. Bei 100m Kabel sind das 
500ns. Damit kommt man langsam in die Grössenordung der minimalen HIGH 
Pulse bei 400 kHz. Aber! Da I2C mit Open Drain arbeitet, kann  kein 
sinnvoller Pull-Up ein 100m langes Kabel in 500ns auf HIGH ziehen. Pi 
mal Daumen hat ein Meter Kabel ca. 100pF, macht bei 100m 10.000pF. 
Selbst ein kleiner Pull-Uo von 1kOhm erreicht damit nur eine 
Zeitkonstante von 10us (Mikrosekunden), eine steigenden Flanke dauert 
somit mind. 20..30us.

>zustätlich das Problem, das man über die kapazitiven Einflüsse des
>Kabels Verschleifungen des Signals bekommt.

Nicht zusätzlich, das ist der Kernpunkt. I2C ist nicht laufzeitbegrenzt, 
es ist durch die Treiberstärke des Pull-Ups begrenzt. Schliesslich war 
I2C nur für Kommunikation auf Platinenformat konzipiert, nicht als 
raumverbindendes Netzwerk.

>Ich fand die Idee recht pfiffig, weil ich das Display und die Tasten im
>Gehäuse absetzten möchte und kein Freund von vielen Strippen bin.

Ist richtig, aber dennoch muss man solche Encoder bei Handbetätigung mit 
100 Hz und mehr abfragen. Da ist ne Menge los auf deinem I2C Bus.
Besser wäre ein winziger uC direkt am Display. Der kann dann sehr 
langsam über I2C abgefragt werden.

Mfg
Falk

Autor: Markus J. (doc_database)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Markus J. (doc_database)
>
>>> in dem man erst mühsam die Interruptquellen auseinander pflücken muß,
>>> das kann dauern.
>
>>stimmt. Aber was ist schon perfekt?
>
> Nichts. Aber viele Controller sind wesentlich besser als die PICs ;-)
> Flame on!

Naja, dieses Thema wird auch hier in der Fa. behandelt. Ich würde es 
eher als Religion bezeichnen.
Ich persönlich komme vom Handling einfach besser mit den PIC`s klar, 
wobei ich auch mal ein Hands-On mit AVR`s hatte.
Also Glaubensache, und ich möchte mich nicht auf das dünne Eis begeben, 
um hier eine Wertung/Entscheidung für andere zu treffen.

Wichtig ist doch, was am Ende bei rum kommt, und der Schwachpunkt dabei 
ist doch, wie immer der Mensch, der dem µC erst mal sagen muß, was er zu 
tun hat.
Findige Entwickler kommen daher mit beiden Typen klar.

>
>>> Ich halte I2C nicht für größere Netze geeignet.
>
>>stimmt auch. Bei I²C muss man bei größeren Netzen daraug achten, das die
>>Laufzeiten durch das Kabel und zurück zum Sender an die
>>Übertragungsfrequenz angepaßt wird, damit auch eine kurze Antwort der
>
>
> ;-))
>
> Du bist lustig. Schon mal überlegt, wie lange ein Kabel sein muss, damit
> Laufzeiten eine Rolle spielen? Mal so ein Tip.
>
> Signallaufzeit auch einem Kabel ist ca. 5ns/m. Bei 100m Kabel sind das
> 500ns. Damit kommt man langsam in die Grössenordung der minimalen HIGH
> Pulse bei 400 kHz. Aber! Da I2C mit Open Drain arbeitet, kann  kein
> sinnvoller Pull-Up ein 100m langes Kabel in 500ns auf HIGH ziehen. Pi
> mal Daumen hat ein Meter Kabel ca. 100pF, macht bei 100m 10.000pF.
> Selbst ein kleiner Pull-Uo von 1kOhm erreicht damit nur eine
> Zeitkonstante von 10us (Mikrosekunden), eine steigenden Flanke dauert
> somit mind. 20..30us.

Langsam!!! :-))
Ich benutze I²C nicht pur! Les' nochmal.
Ich gehe nur ein kurzes Stück AUF DER PLATINE mit I²C[pur] und setze 
dann die Signale um, um das beschriebene Problem zu umgehen.

Den Gedankengang oben (wie auch unten) hatte ich dabei auch, und ziehe 
hier die beschriebene Lösung hinzu.

>
>>zustätlich das Problem, das man über die kapazitiven Einflüsse des
>>Kabels Verschleifungen des Signals bekommt.
>
> Nicht zusätzlich, das ist der Kernpunkt. I2C ist nicht laufzeitbegrenzt,
> es ist durch die Treiberstärke des Pull-Ups begrenzt. Schliesslich war
> I2C nur für Kommunikation auf Platinenformat konzipiert, nicht als
> raumverbindendes Netzwerk.
>
>>Ich fand die Idee recht pfiffig, weil ich das Display und die Tasten im
>>Gehäuse absetzten möchte und kein Freund von vielen Strippen bin.
>
> Ist richtig, aber dennoch muss man solche Encoder bei Handbetätigung mit
> 100 Hz und mehr abfragen. Da ist ne Menge los auf deinem I2C Bus.
> Besser wäre ein winziger uC direkt am Display. Der kann dann sehr
> langsam über I2C abgefragt werden.
>
> Mfg
> Falk

Völlig richtig.
Daher die Überlegung mit einem I²C - Hub, den ich schneller ansprechen 
kann, als den Rest des Netzwerkes.
Hier: PCA9518: 5 Kanal I²C Hub.
An diesem Punkt bin ich mir einfach noch nicht klar, was genau ich 
mache.
Ich tendiere allerdings zu klassischen Lösung, sprich: wie vorgschlagen, 
den Encoder direkt am PIC auszuwerten, oder irgendeinen Winzling dem 
vorzuschalten.

Autor: Markus J. (doc_database)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>>Ich fand die Idee recht pfiffig, weil ich das Display und die Tasten im
>>>Gehäuse absetzten möchte und kein Freund von vielen Strippen bin.
>>
>> Ist richtig, aber dennoch muss man solche Encoder bei Handbetätigung mit
>> 100 Hz und mehr abfragen. Da ist ne Menge los auf deinem I2C Bus.
>> Besser wäre ein winziger uC direkt am Display. Der kann dann sehr
>> langsam über I2C abgefragt werden.
>>
>> Mfg
>> Falk

Um nochmnal genauer auf den Punkt einzugehen:
Wie in dem Artikel beschrieben, schließt man den Encoder an einen 
PCF8574 an (I²C Port - Expander mit Interrupt).
bei einer Änderung des Zustandes liegt am /Int - Augang des PCF8574 ein 
[Edit] LOW an.
Damit brauche ich nicht dauernd den Encoder über den I²C - Bus zu 
pollen, sondern nur dann, wenn ein Interrupt anliegt den PortExpander 
abfragen.
Das war die Idee.

Schnell genug sollte die Geschichte eigentlich sein.
In dieser Zeit können die restlichen Aufgaben, die über den Bus 
gesteuert werden, ruhen, bzw. deren Priorität ist geringer, und werden 
später abgearbeitet.
Ein Entprellen ist dann auch nicht mehr von nöten, da ich die Kontakte 
in regelmäßigen Intervallen abfrage, die von der Geschwindigkeit des 
Busse abhängen.
Alles weitere mache ich dann, wie hier in dem Artikel "Drehgebern" 
erwähnt wurde.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Markus J. (doc_database)

>Wie in dem Artikel beschrieben, schließt man den Encoder an einen
>PCF8574 an (I²C Port - Expander mit Interrupt).
>bei einer Änderung des Zustandes liegt am /Int - Augang des PCF8574 ein
>HIGH an.
>Damit brauche ich nicht dauernd den Encoder über den I²C - Bus zu
>pollen, sondern nur dann, wenn ein Interrupt anliegt den PortExpander
>abfragen.
>Das war die Idee.

Und die ist schlecht. Warum das so ist, steht hier

Drehgeber

>Alles weitere mache ich dann, wie hier in dem Artikel "Drehgebern"
>erwähnt wurde.

Warum schreibst du dann sowas?

MfG
Falk

Autor: Markus J. (doc_database)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Markus J. (doc_database)
>
>>Wie in dem Artikel beschrieben, schließt man den Encoder an einen
>>PCF8574 an (I²C Port - Expander mit Interrupt).
>>bei einer Änderung des Zustandes liegt am /Int - Augang des PCF8574 ein
>>HIGH an.
>>Damit brauche ich nicht dauernd den Encoder über den I²C - Bus zu
>>pollen, sondern nur dann, wenn ein Interrupt anliegt den PortExpander
>>abfragen.
>>Das war die Idee.
>
> Und die ist schlecht. Warum das so ist, steht hier
>
> Drehgeber
>
>>Alles weitere mache ich dann, wie hier in dem Artikel "Drehgebern"
>>erwähnt wurde.
>
> Warum schreibst du dann sowas?
>
> MfG
> Falk

Habe ich etwas in dem Artikel übersehen?
Im Moment versteh ich es nicht:
Ich bekomme einen Interrupt, der meldet, das sich gerade etwas am 
Drehgeber  geändert hat.
Also schicke ich meine Geister los und frage den derzeitigen Zustand des 
PCF ab. Ich vergleich ihn mit dem vorherigen und weiß bescheid -> 
Gray-Codec.
Daraufhin löse ich eine Reaktion auf den Drehgeber aus (Display, was 
weiß ich), lösche den Interrupt und warte auf den nächsten Interupt.

Wo also liegt der Punkt, der dich an der Idee stört?

Autor: Markus J. (doc_database)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Markus J. (doc_database)
>
>>> in dem man erst mühsam die Interruptquellen auseinander pflücken muß,
>>> das kann dauern.
>
>>stimmt. Aber was ist schon perfekt?
>
> Nichts. Aber viele Controller sind wesentlich besser als die PICs ;-)
> Flame on!
>

"Wer ist der bessere Mensch?", fragte der Amerikaner,
", der Chines' oder Indianer?"

frei und ohne Wertung nach MJ`08
:-))

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Markus J. (doc_database)

>Wo also liegt der Punkt, der dich an der Idee stört?

Die Interrupts. "Warum Sparvarianten nicht gut sind"

MFG
Falk

Autor: Markus J. (doc_database)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Markus J. (doc_database)
>
>>Wo also liegt der Punkt, der dich an der Idee stört?
>
> Die Interrupts. "Warum Sparvarianten nicht gut sind"
>
> MFG
> Falk

OK, ich les den Absatz nochmal in aller Ruhe.
Du kannst dir sicher sein, das ich mir das durch den Kopf gehen lasse.
Besten Dank!

Autor: Markus J. (doc_database)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus J. wrote:
> Falk Brunner wrote:
>> @ Markus J. (doc_database)
>>
>>>Wo also liegt der Punkt, der dich an der Idee stört?
>>
>> Die Interrupts. "Warum Sparvarianten nicht gut sind"
>>
>> MFG
>> Falk

Meine Überlegungen sind noch nicht abgeschlossen, aber wie ich schon 
sagte, brauch der Bus eine Zeit, um den aktuellen Wert zu übertragen.
Bzw. der PIC brauch ein paar µS, um auf den kommenden /Int zu reagieren.
Weiterhin muß der PCF erst einmal angesprochen werden.
Nach Datenblatt gibt der Hersteller max 5ms für das Prellen an.
In der Zwischenzeit ist das Prellen abgeklungen und die Abfrage SOLLTE 
mit dem richtigen Ergebnis daherkommen.
Muss ich nochmal in Ruhe durchrechnen.
Ein hin und herflattern erwarte ich bei den verwendeten Encodern nicht.
Soweit ich das verstehe, ist das auch bauformabhängig.

Ich denk mal weiter darüber nach...

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@doc_
>Darin ist beschrieben, wie man CAN - Transceiver für I²C benutzt. Es
>wird lediglich die Hardware dazu benutzt, aber nicht das Protokoll.

Ehrlich gesagt halte ich das für unnötig kompliziert. Ich habe nirgends 
etwas von USB gelesen, warum also nicht den Bruder 18LF4580 nehmen? Der 
hat einen CAN-Controller OnBoard. Das CAN-Protokoll in SW auf I2C zu 
realisieren macht nicht allzuviel Spass, befürchte ich...

@...
>>> in dem man erst mühsam die Interruptquellen auseinander pflücken muß,
>>> das kann dauern.

>>stimmt. Aber was ist schon perfekt?

Naja, das mit den Interruptquellen ist ein sehr theoretischer Ansatz. 
Wenn man hier keinen groben Mist baut, kann man damit leben.

>Nichts. Aber viele Controller sind wesentlich besser als die PICs ;-)
>Flame on!

Bitte nicht! Das ist nach wie vor überflüssig, wer schlechte Ergebnisse 
auf den Controller 'abschiebt' hat entweder den falschen ausgewählt oder 
ist ein mieser Programmierer. Beides Kategorie: selbst schuld!

Gruss,
Edson

Autor: Markus J. (doc_database)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meister Eder wrote:
> @doc_
>>Darin ist beschrieben, wie man CAN - Transceiver für I²C benutzt. Es
>>wird lediglich die Hardware dazu benutzt, aber nicht das Protokoll.
>

Ich benutze KEIN CAN - Protokoll.
Ich benutze nur die Hardware, um meinen Signalweg über eine längere 
Strecke übertragen zu können.
Ich benutze ganz klar I²C - Protokokoll.

> Ehrlich gesagt halte ich das für unnötig kompliziert. Ich habe nirgends
> etwas von USB gelesen, warum also nicht den Bruder 18LF4580 nehmen? Der
> hat einen CAN-Controller OnBoard. Das CAN-Protokoll in SW auf I2C zu
> realisieren macht nicht allzuviel Spass, befürchte ich...
>
USB nutze ich derzeit nicht.
Es gibt für diese Anwendung sicher auch einen kleineren PIC, aber auf 
dem habe ich genug Spielraum zum "üben".
Mit dem PIC (kleiner Bruder 18F2550) habe ich allerdings schon Projekte 
mit USB - Anwendung gemacht.
Wie gesagt, immer nur ein Perepheriemodul eingesetzt.

Es kann aber durchaus sein, das ich dem PIC wieder einen Bootloader 
einimpfe, um Updates besser einspielen zu können.
Die Option halte ich mir frei.
Einen Platz für eine USB-Buchse habe ich allerdings schon vorgesehen.

> @...
>>>> in dem man erst mühsam die Interruptquellen auseinander pflücken muß,
>>>> das kann dauern.
>
>>>stimmt. Aber was ist schon perfekt?
>
> Naja, das mit den Interruptquellen ist ein sehr theoretischer Ansatz.
> Wenn man hier keinen groben Mist baut, kann man damit leben.
>
>>Nichts. Aber viele Controller sind wesentlich besser als die PICs ;-)
>>Flame on!
>
> Bitte nicht! Das ist nach wie vor überflüssig, wer schlechte Ergebnisse
> auf den Controller 'abschiebt' hat entweder den falschen ausgewählt oder
> ist ein mieser Programmierer. Beides Kategorie: selbst schuld!
>
> Gruss,
> Edson

Ack.

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.