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/millier152/2303017.pdf] , 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!
@ 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
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.
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...
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
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/i2c/pdf/an460.pdf]] 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.
@ 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
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.
>>>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.
@ 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
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?
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 :-))
@ 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
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!
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...
@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
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.
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.