Hallo, ich habe im Datenblatt des ATtiny 1606 gelesen das dieser Controller eine "CCL"-Einheit enthält. So wie ich es verstehe handelt es sich dabei um eine Art Mini-FPGA-Baustein, der unabhängig von der CPU des Controllers, bestimmte logische Verknüpfungen durchführen kann. Hat jemand von euch so eine CCL-Einheit verwendet und kann mal beschreiben welches Problem er damit gelöst hat? rhf
Gast
#7243417
Roland F. schrieb: > ich habe im Datenblatt des ATtiny 1606 gelesen das dieser Controller > eine "CCL"-Einheit enthält. So wie ich es verstehe handelt es sich dabei > um eine Art Mini-FPGA-Baustein, der unabhängig von der CPU des > Controllers, bestimmte logische Verknüpfungen durchführen kann. Und noch etwas mehr. Neben den LUTs, die für die logischen Verknüpfungen von bis zu drei Eingangssignalen zuständig sind, gibt es auch noch für jedes LUT-Paar einen sog. "Sequencer", mit dem man noch mehr fummeln kann, also insbesondere Sachen, die über boolsche Logik hinausgehen. > Hat jemand von euch so eine CCL-Einheit verwendet und kann mal > beschreiben welches Problem er damit gelöst hat? Nicht mit einem Tiny, aber mit einem AVR128DA64. Das Prinzip ist aber dasselbe. Benutzt habe ich dabei allerdings nur die boolsche Logik von drei LUTs. Die Sache ist ein bidirektionaler Multiplexer/Demultiplexer zwischen zwei COM-Ports auf der einen Seite und einem COM-Port auf der anderen Seite und der AVR selber hat mit der ganzen Sache nach der Initialisierung der CCL nix mehr zu tun. Er stellt dann diesbezüglich bloß noch die logische Funktion bereit, ohne jede weitere eigene Intervention. Witzigerweise steckte diese Funktionalität ursprünglich tatsächlich in einem (heute nicht mehr lieferbaren oder zumindest nicht mehr bezahlbaren) FPGA... Da steckte noch mehr drin, nämlich ein SPI-Portexpander. Nur mit dieser Funktionalität beschäftigt sich jetzt der AVR. Zeit hat er ja genug dafür, da er sich um dieses COM-Port-Multiplexing nicht mehr weiter kümmern muss...
Getting Started with CCL https://ww1.microchip.com/downloads/en/Appnotes/TB3218-Getting-Started-with-CCL-DS90003218.pdf
Roland F. schrieb: > Hallo, > ich habe im Datenblatt des ATtiny 1606 gelesen das dieser Controller > eine "CCL"-Einheit enthält. (...) > Hat jemand von euch so eine CCL-Einheit verwendet und kann mal > beschreiben welches Problem er damit gelöst hat? Mit der etwas ältern XCL-Unit des xmega32E5 habe ich ein D-Flipflop implementiert, dass mit bei der Implementierung eines reziproken Frequenzmessers die Zähler freigibt. Bevor Du aber mit dem CCL experimentierst, solltes Du unbedingt das Errate-Sheet lesen. Zitat: "CCL - Configurable Custom Logic 2.3.1 Connecting LUTs in Linked Mode Require OUTEN Set to ‘1’ Connecting the LUTs in linked mode require LUTnCTRLA.OUTEN set to ‘1’ for the LUT providing the input source." "Work around Use an event channel to link the LUTs or do not use the corresponding I/O pin for other purposes." Und besonders lustig: "D-latch is Not Functional The CCL D-latch is not functional." "Work around None" Grüßle, Volker
Gast
#7243679
@ c-hater (schrieb im Beitrag #7243417)
Magst Du
> dieses COM-Port-Multiplexing
hier mal genauer ausführen?
Roland F. schrieb: > Hat jemand von euch so eine CCL-Einheit verwendet und kann mal > beschreiben welches Problem er damit gelöst hat? Eine Hardwareverriegelung ohne weitere externe Logik.
Hallo, danke für eure Antworten: c-hater schrieb: > Er stellt dann diesbezüglich bloß noch die logische Funktion > bereit, ohne jede weitere eigene Intervention. Ja, man braucht keine Software schreiben und testen (bis eben auf die Initialisierung) und braucht auch keine externe Hardware. Beeindruckend. Georg M. schrieb: > Getting Started with CCL Das Applikationspapier kannte ich noch nicht. Die aufgeführten Beispiele machen das Ganze klarer. Volker B. schrieb: > Bevor Du aber mit dem CCL experimentierst, solltes Du unbedingt das > Errate-Sheet lesen. > ... > Und besonders lustig: > > "D-latch is Not Functional > The CCL D-latch is not functional." > > "Work around None" Tja, ist wohl alles noch etwas neu, aber das wird schon. :-) rhf
Gast
#7244242
> welches Problem ... gelöst Vielleicht dieses: Beitrag "AVR128DB28: TCB0 liefert kein Signal an PA2"
Gast
#7249262
Richard schrieb: > Magst Du > >> dieses COM-Port-Multiplexing > > hier mal genauer ausführen? Simple Sache. Es gibt einen Host-Controller, der nur eine UART hat, aber mit zwei Peers reden muss. Er tut das abwechselnd. Um das tun zu können, braucht er halt so einen MUX/DEMUX. Er steuert das Ding über TX und ein "PEERSELECT"-Signal, welches steuert, bei welchem Peer sein TX-Signal sichtbar wird. Und sein RX wird halt je nach "PEERSELECT" entweder von dem TX des einen einen oder des anderen Peer bespaßt. Das war's. Der springende Punkt im Zshg. mit CCL ist: Nachdem die CCL einmal initialisiert ist, hat der AVR mit dem ganzen Kram nix mehr zu schaffen. Weder werden irgendwelche UARTs des AVR benutzt, noch muss er er sich in Software damit beschäftigen, irgendwelche Bytes zwischen seinen UARTs hin- und herzuschaufeln.
Gast
#7249534
c-hater schrieb: > Die Sache ist ein bidirektionaler Multiplexer/Demultiplexer > zwischen zwei COM-Ports auf der einen Seite und einem COM-Port auf der > anderen Seite > Es gibt einen Host-Controller, der nur eine UART hat, aber > mit zwei Peers reden muss. Er tut das abwechselnd. Um das tun zu können, > braucht er halt so einen MUX/DEMUX. Er steuert das Ding über TX und ein > "PEERSELECT"-Signal, welches steuert, bei welchem Peer sein TX-Signal > sichtbar wird. > Und sein RX wird halt je nach "PEERSELECT" entweder von dem TX des einen > einen oder des anderen Peer bespaßt. > Simple Sache. Zu simpel und allgemein erklärt daß ich mir nichts drunter vorstellen kann. Soll dieser Multiplexer/Demultiplexer ein eigenständiges Gerät sein oder wie meinst Du das? In diesem Fall hätte ich ganz einfach einen 3-UART AVR verwendet. Jetzt sagst Du aber > Weder werden irgendwelche UARTs des AVR benutzt und das Umswitchen von einem Eingang abwechselnd auf zwei Ausgänge (und umgekehrt) wird einzig und allein mit der CCL-Einheit bewerkstelligt? Wie genau nun geschieht das?
Gast
#7250021
Richard schrieb: > Zu simpel und allgemein erklärt daß ich mir nichts drunter vorstellen > kann. Das tut mir sehr leid für dich. > Soll dieser Multiplexer/Demultiplexer ein eigenständiges Gerät sein Nein. Das ist ein Teil der Funktionalität, die früher(tm) in einer bestimmten bestehenden uralten Schaltung durch einen FPGA bereitgestellt wurde. Der AVR ersetzt nun einfach nur diesen FPGA, ansonsten bleibt die bestehende Schaltung unverändert. > In diesem Fall hätte ich ganz einfach einen 3-UART > AVR verwendet. Der AVR128DA64 hat sogar SECHS UARTs. Er wäre aber für die restliche Funktionalität des ehemaligen FPGA zu langsam geworden, wenn den UART-Kram in Software abhandeln müsste, hätte also den FPGA nicht ersetzen können. Dadurch, dass dieser Teil an die CCL delegiert wurde, kann er es aber. > und das Umswitchen von einem Eingang abwechselnd auf zwei Ausgänge (und > umgekehrt) wird einzig und allein mit der CCL-Einheit bewerkstelligt? Genau. > Wie genau nun geschieht das? Durch geeignete Programmierung der CCL, so dass diese die nötige logische Funktionalität umsetzt (und ein paar äußere Verbindungen zwischen den Eingängen der drei beteiligten LUTs).
Gast
#7250146
c-hater schrieb: > Durch geeignete Programmierung der CCL Danke. Informationswert = Null.
Könnte man mit dem CCL direkt einen IQ-Mischer in einer MCU realisieren?
Gast
#7250162
Roland F. schrieb: > Hallo, > ich habe im Datenblatt des ATtiny 1606 gelesen das dieser Controller > eine "CCL"-Einheit enthält. So wie ich es verstehe handelt es sich dabei > um eine Art Mini-FPGA-Baustein, Eine LUT macht noch keinen FPGA, Das ganze schaut eher nach einer Min-PLA o.ä. , wie das Teil im alten C64, nur noch viel kleiner. http://skoe.de/docs/c64-dissected/pla/c64_pla_dissected_a4ds.pdf Naja, rettet vielleicht mal einem PCB-Designer den Arsch, weil er den passenden 74xxx vergessen hat und die Softwarelösung auf Bitop Operationen wegen der leidlichen Ausmaskierer zu langsam ist.
Gast
#7250164
Richard schrieb: > c-hater schrieb: >> Durch geeignete Programmierung der CCL > > Danke. Informationswert = Null. Du meinst: du bekommst keine fertige Lösung?! Nö, der Kunde hat dafür bezahlt. Und wenn du die willst, wirst du genauso löhnen müssen. So ist das halt im Kapitalismus.
Gast
#7250169
Mcn schrieb: > Eine LUT macht noch keinen FPGA Das sicher nicht. Aber wenn es ein paar mehr sind, kann man u.U. einen ersetzen.
Gast
#7250186
c-hater schrieb: > Mcn schrieb: > >> Eine LUT macht noch keinen FPGA > > Das sicher nicht. Aber wenn es ein paar mehr sind, kann man u.U. einen > ersetzen. Eher nicht, selbst die kleinen FPGA's laufen mit 100+MHz und liefern genug LUT's mit, um nebenher einen 8 oder 32 bit Prozessor darin zu bauen. Beispielsweise den 8bit Picoblaze, der mit ca 200 LUT's daher kommt. https://www1.hs-bremerhaven.de/kmueller/VHDL/ug129.pdf Und selbst der kleinste Spartan 7 (/6) kommt mit ca 7000 LUT's daher. Also lieber einen kleinen FPGA einsetzen als mit 100 µC einen ersetzen zu wollen. https://docs.xilinx.com/v/u/en-US/7-series-product-selection-guide DiesesCCL mit einem FPGA zu vergleichen ist leider ein neuer Höhepunkt der Marketing-Idiotie.
Gast
#7250201
c-hater schrieb: > Du meinst: du bekommst keine fertige Lösung?! Nein. Ich meine, Du hast gar keine. Wie sich nämlich mit den 3 CCL Funktionalitäten Logic Gate, State Decoder und SR Latch ein autonomer Multiplexer für serielle Signale realisieren lassen soll ist schon mehr als schleierhaft! Grundsätzlich lässt sich das alles besser in Software realisieren- die CCL scheint mir höchstens für seltene Spezialfälle zu taugen zumal deren festgelegte Pin-I/O noch zusätzlich einschränkt.
Gast
#7250239
an Richard:
Besonders viel ist mir bislang zu CCL auch nicht eingefallen, aber dies
> zumal deren festgelegte Pin-I/O noch zusätzlich einschränkt
lässt sich mit dem Event-System umgehen.
Gast
#7250251
S. Landolt schrieb: > lässt sich mit dem Event-System umgehen. Vielleicht finden sich ja so doch noch einige Probleme zur gegebenen Lösung :)
Gast
#7250260
Nun ja, die Ausgangsfrage war
> CCL-Einheit verwendet und ... welches Problem er damit gelöst ...
worauf u.a. c-hater geantwortet hat.
Wenn jetzt die Frage "Was ist der Sinn von CCL" lautet ... - möchte ich
lieber nicht antworten, da nicht kompetent.
Gast
#7250271
S. Landolt schrieb: > da nicht kompetent Etwas mehr Zutrauen! Es ist doch nur eine c-hater schrieb: > Simple Sache :)
Gast
#7250301
Diese CCL sind als günstiger Ersatz für die nicht mehr verfügbaren CPLD gedacht. Zuerst gab es CCL bei Silabs dann bei den neueren PIC und wurden dann in die neueren AVR übernommen. Hier ein Vergleich wie WS2812B Led Driver implementiert wird auf AVR PIC Silabs: https://siliconlabs.force.com/community/s/share/a5U8Y000000bxnDUAQ/ws2812b-led-driver-on-efm8bb51-microcontroller
Mcn schrieb: > Dieses CCL mit einem FPGA zu vergleichen ist leider ein neuer Höhepunkt > der Marketing-Idiotie. Der Unsinn stammt aber von c-hater und nicht vom Hersteller. Und was man mit der CCL machen kann ist nur eine Frage der eigenen Phantasie was man mit paar Logikgattern machen könnte. Bevor man irgendwelche Kabel zieht kann man Ereignisse logisch verknüpfen. Es gibt auch eine App Note 2434 für einen Hardwareencoder. Dann ist zwar alles belegt, aber ein größeres Beispiel.
Wir haben das Abholen von Daten per SPI aus zwei AD-wandlern realisiert, die einen integrieren FIR Filter haben. Das Problem war,dass die Daten "gestückelt" abgeholt werden sollen, um keine Digitalsignale während der analogen Wandlung zu haben. Nun werden die 24Bit, byteweise abgeholt, immer dann, wenn die Wandler gerade fertig sind mit ihrer Wandlung. Das ganze findet auf einem atsamd51 statt. Könnte man sicher auch analog aufbauen, aber warum, wenn es integriert is.
Richard schrieb: > S. Landolt schrieb: >> da nicht kompetent > > Etwas mehr Zutrauen! > Es ist doch nur eine > > c-hater schrieb: >> Simple Sache > > :) Einfach Google oder eine andere Suchmaschine Deines Misstrauens verwenden: https://ww1.microchip.com/downloads/en/Appnotes/00002387B.pdf
Gast
#7250703
Randbemerkung: Es gibt(?)/gab vor ca. 20 Jahren von Atmel einen echten 8bit µC (AVR-Architektur) mit deutlichen (5k - 40k Gatteräquivalente) FPGA-Anteil - den FPSLIC: https://media.digikey.com/pdf/data%20sheets/atmel%20pdfs/at94k05_10_40al%20complete.pdf Beitrag "FPSLIC - AVR im FPGA von ATMEL?" http://uafr.freeshell.org/fh/seminar/seminar.pdf https://www.limpkin.fr/index.php?post/2010/02/14/The-FPSLIC-bicolor-matrix-project
Gast
#7250757
Uwe D. schrieb: > Einfach Google oder eine andere Suchmaschine Deines Misstrauens > verwenden: https://ww1.microchip.com/downloads/en/Appnotes/00002387B.pdf Über Sinn und Zweck eines "core independent nightlight" lässt sich sicher streiten- das ist "core dependent" im (Rechen)Aufwand ja nun wirklich nicht der Rede wert und mit wenig Code erledigt. Hier stellt sich vielmehr die Frage lohnt es dafür wirklich, sich in das etwas vertrackte CCL einzuarbeiten. Allzuviele Entwickler dürften das bislang nicht getan haben wenn hier solche Fragen aufkommen- das Dokument ist ja schon von 2017. Die richtige Killeranwendung hab ich jedenfalls noch nicht gesehen.
Gast
#7250767
Richard schrieb: > Nein. Ich meine, Du hast gar keine. Was du meinst, leitet sich wohl nur von deiner mangelnden Kompetenz ab. > Wie sich nämlich mit den 3 CCL Funktionalitäten Logic Gate, State > Decoder und SR Latch ein autonomer Multiplexer für serielle Signale > realisieren lassen soll ist schon mehr als schleierhaft! Wie schon bemerkt, braucht man dafür genau drei LUTs und ein paar äußere Verbindungen zwischen deren Eingangspins (ebenfalls genau drei). Das ist reine boolsche Logik. > Grundsätzlich lässt sich das alles besser in Software realisieren Nein, das konkrete Beispiel zeigt einen Fall, wo das nicht so ist. Beweist also mindestens, dass das "grundsätzlich" in deiner Behauptung falsch sein muss.
Gast
#7250770
c-hater schrieb: > Was du meinst, leitet sich wohl nur von deiner mangelnden Kompetenz ab. Bislang ist die Deinige bei diesem Thema nicht belegt. c-hater schrieb: > das konkrete Beispiel zeigt einen Fall Welches? Von Dir kam da noch nichts.
Gast
#7250849
Richard schrieb:
> etwas vertrackte CCL einzuarbeiten
Wenn Sie eine konkrete Frage zu CCL haben, dann stellen Sie sie, und wir
werden versuchen, sie zu beantworten.
Wenn Sie aber über Sinn&Unsinn von CCL diskutieren wollen, so ist das
so wenig nutzbringend wie C vs. Assembler, 5 V vs. 3.3 V, SMD vs. THT
&c.
Hallo, richtig, alle Controller dieser Welt haben verschiedene Hardwareinheiten onboard. Nur weil man davon etwas nicht nutzt oder nicht versteht muss das nicht schlecht sein.
Walter T. schrieb: > Könnte man mit dem CCL direkt einen IQ-Mischer in einer MCU realisieren? Nein, die CCL sind / beinhalten keine Analog-Schalter.
Gast
#7250990
S. Landolt schrieb: > Wenn Sie aber über Sinn&Unsinn von CCL diskutieren wollen Am sinnvollen Beispiel! Denn darum geht es doch. Wozu ist diese CCL nun wirklich zu gebrauchen?! Eine wünschenswerte Anwendung hätte ich durchaus. Bei einem Projekt wird ein 8x16 Punkmatrix-Modul angesteuert. Der dazu nötige Interrupt zur Ansteuerung der 8 Reihen (Mosfets) und 16 Spalten * 3Farben = 8*48 Leds (3*16 Channel Driver IC, SPI) benötigt 800 Hz für ein halbwegs ruhiges Bild. Das fordert den AVR neben anderen Aufgaben recht ordentlich. Wär toll das irgendwie core-independent hinzubekommen.
Gast
#7251010
Hmm - da sehe ich ad hoc keinen Einsatz für CCL; bin allerdings wenig erfahren, was LED-Matrizen betrifft. An der SPI-Kommunikation wird sich wohl nichts verbessern lassen. Aber allgemein gefragt: 800 Hz, das entspricht bei 24 MHz (z.B. ein AVR-Dx) 30 kTakten - das erscheint mir recht üppig, wo entsteht da der Engpass?
Gast
#7251037
S. Landolt schrieb: > Hmm - da sehe ich ad hoc keinen Einsatz für CCL; bin allerdings wenig > erfahren, was LED-Matrizen betrifft. An der SPI-Kommunikation wird sich > wohl nichts verbessern lassen. Die Rede war von einem 800Hz Timer-Interrupt der das Ganze steuert und das regelmäßige Beschicken der Spaltentreiber via SPI(Interrupt) veranlasst. Irgendwie muß die Bildinformation aber vom Speicher aufs Display kommen, mangels DMA seh ich da mit der CCL-Einheit allein keine Möglichkeit das core-independent hinzubekommen. S. Landolt schrieb: > Aber allgemein gefragt: 800 Hz, das entspricht bei 24 MHz (z.B. ein > AVR-Dx) 30 kTakten - das erscheint mir recht üppig, wo entsteht da der > Engpass? Der AVR-DB läuft mit 16MHz, etwas Spielraum nach oben möchte ich mir noch freihalten. Es sind noch weitere Interrupts (RTC,UART) im Spiel und das Hauptprogramm möchte ebenso zügig vorankommen. Von einem richtigen Engpass würde ich noch nicht sprechen - aber das soll jetzt hier kein Thema sein.
Gast
#7251050
> mangels DMA seh ich da mit der CCL-Einheit ... Tja, und sie ist eben auch kein Ersatz für DMA. > muß die Bildinformation aber vom Speicher aufs Display > kommen ... AVR-DB läuft mit 16MHz Das kann doch aber nicht mehr als wenige Hundert der zur Verfügung stehenden Zwanzigtausend Takte verbrauchen, oder? > aber das soll jetzt hier kein Thema sein Dann verabschiede ich mich fürs erste in diesen trüben Sonntagnachmittag.
Gast
#7251054
Richard schrieb: > Eine wünschenswerte Anwendung hätte ich durchaus. > Bei einem Projekt wird ein 8x16 Punkmatrix-Modul angesteuert. > Der dazu nötige Interrupt zur Ansteuerung der 8 Reihen (Mosfets) und 16 > Spalten * 3Farben = 8*48 Leds (3*16 Channel Driver IC, SPI) benötigt 800 > Hz für ein halbwegs ruhiges Bild. Das fordert den AVR neben anderen > Aufgaben recht ordentlich. Wär toll das irgendwie core-independent > hinzubekommen. Also grundsätzlich sehe ich in dieser Anwendung nix, wobei die CCL irgendwie helfen könnte. So what, es gibt auch noch andere Anwendungen für µC, als LEDs funzeln zu lassen... Und übrigens: wenn diese Ansteuerung bei 800Hz Framerate einen AVR128@24Mhz ernsthaft belastet, dann stimmt mit dem Code irgendwas nicht. Immerhin stehen in jeder Framezeit 30000 Takte zur Verfügung. Und der AVR hat in der Zeit nur 48mal die Aufgabe, zwei Bytes auszugeben. Für die Ausgabe dieser zwei Bytes stehen also 625 Takte zur Verfügung. Mit der Ablaufverwaltung des Lesezeigers in den Framebuffer dauert sowas bei sinnvoller Programmierung und Organisation eben dieses Buffers was um die 18 Takte, dazu kommt dann noch das Signalspiel mit dem LED-Driver. Vermutlich SPI und es ist nur CS anzusteuern, also weitere zwei Takte. Sind wir bei 20. Dazu noch der unvermeidliche Interuptframe, sind wir bei 28 Takten. Sprich: sowas lastet die genannte MCU zu weniger als 5% aus. Braucht dein Code nenneswert mehr, machst du irgendwas falsch.
Richard schrieb: > Irgendwie muß die Bildinformation aber vom Speicher aufs Display kommen, > mangels DMA seh ich da mit der CCL-Einheit allein keine Möglichkeit das > core-independent hinzubekommen. Warum nimmst Du dann keinen AVR mit DMA bzw. DMAC (Direct Memory Access Controller), wie z.B. den ATxmega16A4U? Grüßle, Volker Nachtrag: Auch der ATXMega32A4-AU, der im Markt-Bereich angeboten wird, besitzt einen DMAC -- aber unbedingt die zugh. Errata angucken. Diese MCU strotzt nur so vor Fehlern!
Gast
#7251075
c-hater schrieb: > Also grundsätzlich sehe ich in dieser Anwendung nix, wobei die CCL > irgendwie helfen könnte. Genau. Was die Frage weiter offenlässt wo die CCL nun ihre großen Erfolge feiert. > Und übrigens: wenn diese Ansteuerung bei 800Hz Framerate einen > AVR128@24Mhz ernsthaft belastet Also speziell nochmal für Dich: Es sind 16MHz und meine Anwendung ist hier kein Thema. Passender wäre wenn Du Dein Beispiel von oben endlich im Detail vorstellen würdest damit andere auch was über die CCL lernen können. Volker B. schrieb: > Warum nimmst Du dann keinen AVR mit DMA Weil ich aus diversen Gründen einen AVR-DB nehme, ganz einfach. Der langt- es wär nur die Frage gewesen ob die CCL hier eine Hilfe wäre. > Auch der ATXMega32A4-AU, der im Markt-Bereich angeboten wird, > besitzt einen DMAC -- aber unbedingt die zugh. Errata angucken. Diese > MCU strotzt nur so vor Fehlern! Immer die A4U Variante nehmen!
Gast
#7251090
Richard schrieb: > Am sinnvollen Beispiel! Denn darum geht es doch. > Wozu ist diese CCL nun wirklich zu gebrauchen?! Der WS2812B Led Driver ist kein sinnvolles Beispiel? Abgesehen davon, der Sinn eines CPLD ist doch schnelle Logik, also im nsec Bereich, wo ein Interrupt zu viel Latenz hat. Und genau das geht mit den CCL doch. Ein "Ersatz" für ein FPGA ist CCL jedenfalls nicht.
Gast
#7251095
> was über die CCL lernen Also gut, auf vielfachen Wunsch eines einzelnen Mitglieds - aber nicht zuviel erwarten, ist wie bereits von mir ganz oben angeführt, nur die Beseitigung eines Mangels bei den TCB. Sicher nichts > wo die CCL nun ihre großen Erfolge feiert Und Verbesserungsvorschläge wären mehr als willkommen, ich würde gerne auch dazulernen.
Gast
#7251098
Richard schrieb: > Genau. Was die Frage weiter offenlässt wo die CCL nun ihre großen > Erfolge feiert. Da, wofür sie geeignet ist. > Also speziell nochmal für Dich: Es sind 16MHz OMG. Dann darfst du meine Angaben zu den verfügbaren Takten durch 1,5 teilen und die Angabe zu der Auslastung, die sowas verursachen darf, mit 1,5 multiplizieren. An der grundsätzliche Aussage ändert sich dadurch rein garnix. Interessant wäre mal: wieviel Prozent braucht denn deine Implementierung nun, so dass es "kritisch" wird? Zeig' sie doch einfach mal... > Passender wäre wenn Du Dein Beispiel von oben endlich > im Detail vorstellen würdest Das darf ich nicht. Ist halt im Kundenauftrag entstanden. Es sollte aber mit den gegeben Hinweisen absolut trivial sein, das selber zu bauen. Wenn man halt so einen 1:2 COM-Port MUX/DEMUX braucht...
Gast
#7251109
Lothar schrieb: > Der WS2812B Led Driver ist kein sinnvolles Beispiel? Das mag so sein, ohne jetzt die Einzelheiten dieser Ansteuerung zu kennen. Die CCL als Manipulator eines Bitstroms! S. Landolt schrieb: > Beseitigung eines Mangels bei den TCB Immerhin. Danke für den Code. Die CCL quasi als Timer-Erweiterung!
Gast
#7251118
Richard schrieb: > Die CCL quasi als Timer-Erweiterung! Das ist nur EINE mögliche Anwendung.
Gast
#7251143
c-hater schrieb: > absolut trivial > Das darf ich nicht. Ich darf auch nicht :)
Gast
#7251163
Richard schrieb: > Das mag so sein, ohne jetzt die Einzelheiten dieser Ansteuerung zu > kennen Die Implementierung mit CCL angesehen? Lothar schrieb: > Hier ein Vergleich wie WS2812B Led Driver implementiert wird auf AVR PIC > Silabs: > > https://siliconlabs.force.com/community/s/share/a5U8Y000000bxnDUAQ/ws2812b-led-driver-on-efm8bb51-microcontroller
Gast
#7251243
an Richard: War halt doch schon fast ein Jahr her, und jetzt fiel es gleich ins Auge: hier eine Variante mit einfacherer Ansteuerung des JK-Flip-Flops.
Gast
#7251332
S. Landolt schrieb: > an Richard: > War halt doch schon fast ein Jahr her, und jetzt fiel es gleich ins > Auge: hier eine Variante mit einfacherer Ansteuerung des JK-Flip-Flops. Der Fall mit dem TCB Timer hat Dir offensichtlich keine Ruhe gelassen. Das wär jetzt was für die Code Rubrik für die CCL-Tüftler. Muß aber ehrlich sagen, ich tu mich bislang sehr schwer damit. Auch mangels eigenen Bedarfs.
Richard schrieb: > Uwe D. schrieb: >> Einfach Google oder eine andere Suchmaschine Deines Misstrauens >> verwenden: https://ww1.microchip.com/downloads/en/Appnotes/00002387B.pdf > > Über Sinn und Zweck eines "core independent nightlight" lässt sich > sicher streiten- das ist "core dependent" im (Rechen)Aufwand ja nun > wirklich nicht der Rede wert und mit wenig Code erledigt. Hier stellt > sich vielmehr die Frage lohnt es dafür wirklich, sich in das etwas > vertrackte CCL einzuarbeiten. Allzuviele Entwickler dürften das bislang > nicht getan haben wenn hier solche Fragen aufkommen- das Dokument ist ja > schon von 2017. Die richtige Killeranwendung hab ich jedenfalls noch > nicht gesehen. https://forum.arduino.cc/t/nano-every-atmega4809-am-anfang-stand-der-anfang/701185/13 Post #13 - und natürlich kann man alles mit Code das Gleiche erreichen. Nur sorgt die CCL dafür, dass der übermüdete/unkonzentrierte/unwissende Entwickler keinen Kurzschluss baut… So, das genügt. Kannst ja mal selbst den möglichen Nutzen prüfen anstatt die Zeit damit zu verplempern, warum CCL nur Grütze ist…
Gast
#7251358
Uwe D. schrieb: > Nur sorgt die CCL dafür, dass der übermüdete/unkonzentrierte/unwissende > Entwickler keinen Kurzschluss baut… Aber bitte zuerst die Bugs studieren. :) Volker B. schrieb: > Bevor Du aber mit dem CCL experimentierst, solltes Du unbedingt das > Errate-Sheet lesen. > > Zitat: > > "CCL - Configurable Custom Logic > 2.3.1 Connecting LUTs in Linked Mode Require OUTEN Set to ‘1’ > Connecting the LUTs in linked mode require LUTnCTRLA.OUTEN set to ‘1’ > for the LUT providing the input source." > > "Work around > Use an event channel to link the LUTs or do not use the corresponding > I/O pin for other purposes." > > Und besonders lustig: > > "D-latch is Not Functional > The CCL D-latch is not functional." > > "Work around > None"
Roland F. schrieb: > Hallo, > ich habe im Datenblatt des ATtiny 1606 gelesen das dieser Controller > eine "CCL"-Einheit enthält. So wie ich es verstehe handelt es sich dabei > um eine Art Mini-FPGA-Baustein, der unabhängig von der CPU des > Controllers, bestimmte logische Verknüpfungen durchführen kann. > Hat jemand von euch so eine CCL-Einheit verwendet und kann mal > beschreiben welches Problem er damit gelöst hat? Uart in Half-Duplex mit wahlweise normalen / invertierten Pegeln
Gast
#7251371
Wilhelm M. schrieb: > Uart in Half-Duplex mit wahlweise normalen / invertierten Pegeln Wer braucht sowas bitte? Uwe D. schrieb: > warum CCL nur Grütze ist Da hast Du was mißverstanden. Wir sind hier auf der Suche nach sinnvollen Anwendungen .
Richard schrieb: > Wilhelm M. schrieb: >> Uart in Half-Duplex mit wahlweise normalen / invertierten Pegeln > > Wer braucht sowas bitte? Ich (und z.B. viele andere, die im RC-Bereich unterwegs sind) ;-)
Gast
#7251381
Wilhelm M. schrieb: > Ich (und z.B. viele andere, die im RC-Bereich unterwegs sind) ;-) Na schön. Wenn es nach mir ginge wär bei der UART Abrüstung angesagt. Baudrate für fix 8N1 konfigurieren und ab geht die Post auf RX/TX.
Richard schrieb: > Wenn es nach mir ginge wär bei der UART Abrüstung angesagt. > Baudrate für fix 8N1 konfigurieren und ab geht die Post auf RX/TX. Das ist doch schon super einfach, was willst Du da abrüsten???
Gast
#7251398
Wilhelm M. schrieb: > Das ist doch schon super einfach, was willst Du da abrüsten??? Du machst wohl Scherze. Schau Dir die vielen Modi an. Weg damit. Alles nur Tribut einer Entwicklung in der Entwickler und Firmen aller Welt unbedingt eigene Süppchen kochen wollten. Die CCL steht hier in der gleichen Tradition. Was für Kopfstände um beispielsweise einen Takt auszugeben- wie oben in S.Landolts Code zu besichtigen. Die nötigen Konfigurationen über 3 Ecken mögen intellektuelle Tüftlergemüter befriedigen, sind aber kein Beitrag die Dinge einfach und übersichtlich und damit fehlerarm zu halten.
Gast
#7251402
Richard schrieb: > Du machst wohl Scherze. > Schau Dir die vielen Modi an. > Weg damit. Du solltest vielleicht besser Arduino & Co. nutzen.
Richard schrieb: > Du machst wohl Scherze. > Schau Dir die vielen Modi an. > Weg damit. Was machst Du denn bei 9E2? Dann bist Du wahrscheinlich der erste, der wieder jammert.
Gast
#7251415
Unglaublich schrieb: > Du solltest vielleicht besser Arduino & Co. nutzen. Und Dir sei gesagt, bei "unglaublichen" Sachen lernt man meist was Neues :) Wilhelm M. schrieb: > Was machst Du denn bei 9E2? Dann bist Du wahrscheinlich der erste, der > wieder jammert. Sicher nicht. Man könnte "9E2" Exoten ja vielleicht auch aus seiner Auswahl ausklammern?! Standards sind angesagt.
Richard schrieb: > Unglaublich schrieb: >> Du solltest vielleicht besser Arduino & Co. nutzen. > > Und Dir sei gesagt, bei "unglaublichen" Sachen lernt man meist was Neues > :) > > Wilhelm M. schrieb: >> Was machst Du denn bei 9E2? Dann bist Du wahrscheinlich der erste, der >> wieder jammert. > > Sicher nicht. Man könnte "9E2" Exoten ja vielleicht auch aus seiner > Auswahl ausklammern?! Jetzt erkläre bitte mal, was daran kompliziert ist, die Baud-Rate und den 8-bit-Modus zu setzen (die restlichen reset-defaults passen ja für 8N1). Richard schrieb: > Standards sind angesagt. Wahrscheinlich sollte 8N1@9600 nun der Standard sein? Sorry, aber µCs sind nicht nur für Hobbybastler gemacht.
Gast
#7251429
Wilhelm M. schrieb: > Wahrscheinlich sollte 8N1@9600 nun der Standard sein? Die Konfiguration der Baudrate hatte ich doch ausdrücklich erwähnt. Das langt dann aber vollkommen. Auch als Beitrag zu möglichen Fehlern übrigens. Jene Minderheit der das als welchem Grunde auch immer nicht langt darf das ja gerne anders sehen. Damit können wir das an dieser Stelle bewenden lassen.
Gast
#7251438
Richard schrieb: > Standards sind angesagt. Dann kannst Du Dich ja schonmal an 5N1.5 gewöhnen: https://de.wikipedia.org/wiki/Baudot-Code#Der_Baudot-Murray-Code_(CCITT-2) Richard schrieb: > Jene Minderheit der das als welchem Grunde auch immer nicht > langt Was die Mehrheit braucht, entscheidest Du? Also entweder Narzisst oder Troll.
Gast
#7251440
Unglaublich schrieb: > Was die Mehrheit braucht, entscheidest Du? Dir scheint die Übersicht zu fehlen was bei serieller Kommunikation gängig ist und was nicht. Ansonsten darfst auch Du bitte wieder zum eigentlichen CCL Thema zurückfinden (so denn mit eigenen Kenntnissen ausgestattet).
Richard, deine Frage bzw. Diskussion ist vollkommen sinnfrei. Wenn man irgendein Problem zu lösen hat und man grübelt darüber und man kommt vielleicht zu dem Gedanken das die CCL der Problemlösung dienen könnte, dann beschäftigt man sich damit und gut ist. Nicht jeder benötigt für jede Aufgabe jede verfügbare Hardwareeinheit. Sind die nicht benutzten Hardwareeinheiten deswegen Unfug? Ich denke nicht. Deine negative Einstellung gegenüber der CCL ist absolut unproduktiv und unprofessionell. Auf die gezeigten Bsp. gehst du nämlich nicht ein. Das zeigt mir du willst es gar nicht wissen. Auf ein lang und breit dokumentiertes Bsp. kommt als Einzigste Reaktion von dir "Aber bitte zuerst die Bugs studieren.". Was hat das Bsp. mit Bugs zu tun? Das zeigt mir auch nur wieder du willst dich damit nicht befassen. Du möchtest nur sinnfrei diskutieren und stänkern. Deswegen bin ich hier raus. Mach was du willst.
Richard schrieb: > Wilhelm M. schrieb: >> Wahrscheinlich sollte 8N1@9600 nun der Standard sein? > > Die Konfiguration der Baudrate hatte ich doch ausdrücklich erwähnt. Ja, aber nicht, was daran kompliziert sein soll, den 8-Bit Modus einzustellen. > Das langt dann aber vollkommen. Nein. > Auch als Beitrag zu möglichen Fehlern > übrigens. Fehler kann man überall machen (vor allem, wenn man nur die CPP-Konstanten aus den Atmel-Headern verwendet). > Jene Minderheit der das als welchem Grunde auch immer nicht > langt darf das ja gerne anders sehen. Minderheit?
Gast
#7251640
Veit D. schrieb: > Das zeigt mir auch nur wieder du willst dich damit nicht befassen. Ich befasse mich gerne mit sinnvollen Beispielen. Ausbeute bislang: Äußerst mager. Aber wen wundert's.
Richard schrieb: > Veit D. schrieb: >> Das zeigt mir auch nur wieder du willst dich damit nicht befassen. > > Ich befasse mich gerne mit sinnvollen Beispielen. Ausbeute bislang: > Äußerst mager. Aber wen wundert's. Wenn Du in dem bisher gesagten keine sinnvollen Beispiele siehst, dann ist das einzig Dein Problem.
Richard schrieb: > Wenn es nach mir ginge wär bei der UART Abrüstung angesagt. > Baudrate für fix 8N1 konfigurieren und ab geht die Post auf RX/TX. Wieso füttert ihr diesen Troll eigentlich so hartnäckig? Auslachen und ignorieren.
Gast
#7252797
Cyblord -. schrieb: > Wieso füttert ihr diesen Troll eigentlich so hartnäckig? Auslachen und > ignorieren. Puh. Jetzt hast Du's mir aber gegeben! Hast zwar selber keinen (CCL)Plan aber Hauptsache rumkrakeelt. Wie ich sehe regt das den Ideenfluss zum Thema aber auch nicht weiter an...
Für Leute mit Interesse, wobei man sicher noch einiges verbessern kann: https://hackaday.com/tag/configurable-custom-logic/
Uwe D. schrieb: > https://forum.arduino.cc/t/nano-every-atmega4809-am-anfang-stand-der-anfang/701185/13 > Post #13 - und natürlich kann man alles mit Code das Gleiche erreichen. https://europe1.discourse-cdn.com/arduino/original/4X/a/2/6/a264bb28c4b464a3e2d0d8655e63b655f38a63ee.png PWM-Verteilungslogik fürn RC-Car-Fahrt(en)steller. Ist ja mal was für richtige Nerds, oder? Weis nicht recht, da löte ich dann doch lieber n CMOS-IC in die Ecke, als mir das anzutun. Gut - gibt es jetzt ja vorgekaut - aber wäre ich Leben nicht von selbst drauf gekommen, wie man das nun syntaktisch in GlueLogic umsetzt.
"But we haven’t seen any practical example of the CCL peripheral in an Atmel chip up until now"
Gast
#7264632
Gibt noch mehr interessante Anwendungen https://hackaday.com/2021/03/08/avr-configurable-custom-logic-as-a-frequency-divider-at-4x-chips-clock-speed/
"a set of frequency dividers that blink three LEDs with up to a 90 MHz input signal" Wer braucht sowas bitte? Oder das Beispiel der Schalter-Entprellung. Das ist alles simpel und sparsam in Software machbar. Uwe D. schrieb: > Nur sorgt > die CCL dafür, dass der übermüdete/unkonzentrierte/unwissende Entwickler > keinen Kurzschluss baut… Die kann genausogut fürs Gegenteil sorgen weil der Entwickler das Teil nicht durchblickt.
Gast
#7264652
Roland F. schrieb: > Hallo, > ich habe im Datenblatt des ATtiny 1606 gelesen das dieser Controller > eine "CCL"-Einheit enthält. So wie ich es verstehe handelt es sich dabei > um eine Art Mini-FPGA-Baustein, der unabhängig von der CPU des > Controllers, bestimmte logische Verknüpfungen durchführen kann. Richtig. Das entscheidende ist hier "Mini" > Hat jemand von euch so eine CCL-Einheit verwendet und kann mal > beschreiben welches Problem er damit gelöst hat? Durch die CCL-Einheit ist es uns möglich Pins umzumappen, bei welchen sich ansonsten die Perepherie-Einheiten "auf die Füße Treten" würden. Ein Beispiel ist beim Attiny214 wenn man den ADC0-Out verwenden möchte, und gleichzeitig WOB aktiviert haben will. Beides liegt auf PA6. Leitet man ein Signal durch die CCL, dann kann man ein Signal beispielsweise auf PA7 umlegen. Ist kein Mega-Tolles Beispiel, und wäre von Atmel auch anders lösbar gewesen. Für uns war es aber auf alle Fälle "die Rettung". > > rhf P.S. kleiner Tipp: Die CCL funktioniert in einigen Punkten nicht so wie im Datenblatt beschrieben. Es lohnt sich ein Blick in die Erratas (ist sowieso immer eine gute Idee).
der_eine schrieb: > Ist kein Mega-Tolles Beispiel Das Um-Mappen wär schon eine Anwendung. Aber nur weil man bei der Planung zuvor nachlässig war. Viel sinnvoller als solche halbgaren Erweiterungen, und zwar für jede Anwendung, wär das Drehen an der allgemeinen Taktschraube gewesen. Logische Funktionen lassen sich immer in Software abbilden.
Jan V. schrieb: > der_eine schrieb: >> Ist kein Mega-Tolles Beispiel > > Das Um-Mappen wär schon eine Anwendung. > Aber nur weil man bei der Planung zuvor nachlässig war. Nein, s.a. mein Beispiel von oben mit einem half-duplex UART, den man zwischen invertiertem und nicht-invertierten Modus umschalten kann. Hier braucht man die CCL (und eine externe Diode), weil der eingebaute UART zwar die RX-Signale invertieren kann, aber nur einen OpenDrain-TX-Ausgang besitzt, der einem im invertierten Modus nichts nutzt.
Wilhelm M. schrieb: > aber nur einen OpenDrain-TX-Ausgang besitzt, der einem im invertierten > Modus nichts nutzt. Mit externem Pull-Widerstand auch nicht?
Gast
#7264735
Jan V. schrieb: > Das Um-Mappen wär schon eine Anwendung. > Aber nur weil man bei der Planung zuvor nachlässig war. Jan V. schrieb: > Das Um-Mappen wär schon eine Anwendung. > Aber nur weil man bei der Planung zuvor nachlässig war. Was heißt da nachlässig? Wenn man WOB und AC0-Out gleichzeitig braucht, dann geht daß nicht anders (ja, EVENT-OUT würde auch gehen, wurde aber noch für was anderes benötigt). > Logische Funktionen lassen sich immer in Software abbilden. Aber Software kommt immer Verzögert und kann durch Interrupts etc. blockiert werden. Wäre für uns nicht machbar gewesen, und damit die Controllerfamilie für unseren Zweck nicht tauglich gewesen. Gruß
der_eine schrieb: > Wäre für uns nicht machbar gewesen, Will ich Euch auch nicht einreden ohne das Projekt genau zu kennen. Die ganz einfach freie Zuordnung aller Funktionalitäten zu allen IO-Pins wär dafür aber die eigentlich passende Lösung. Dafür hätte man die CCL Chipfläche besser nutzen können. So ist die CCL eher eine lückenfüllende Krücke. Immerhin habt Ihr dafür eine Einsatzmöglichkeit gefunden. Gratulation.
Axel R. schrieb: > Uwe D. schrieb: >> > https://forum.arduino.cc/t/nano-every-atmega4809-am-anfang-stand-der-anfang/701185/13 >> Post #13 - und natürlich kann man alles mit Code das Gleiche erreichen. > > https://europe1.discourse-cdn.com/arduino/original/4X/a/2/6/a264bb28c4b464a3e2d0d8655e63b655f38a63ee.png > > PWM-Verteilungslogik fürn RC-Car-Fahrt(en)steller. > Ist ja mal was für richtige Nerds, oder? Weis nicht recht, da löte ich > dann doch lieber n CMOS-IC in die Ecke, als mir das anzutun. Gut - gibt Nö, da spare ich auf jeden Fall den Chip. (Genau wie ich jeden externen OPV oder Timer o.ä. einsparen würde, wenn das geht.)
Jan V. schrieb: > "a set of frequency dividers that blink three LEDs with up to a 90 MHz > input signal" > > Wer braucht sowas bitte? > Oder das Beispiel der Schalter-Entprellung. Das ist alles simpel und > sparsam in Software machbar. Wenn der Platz im Speicher knapp ist, dann per Hardware. Du musst auch nix blinken lassen, kannst aber Platz sparen und ohne externe Teile zeitlich entspannter agieren… Offensichtlich sind Deine Anwendungen immer ohne Ressourcen Limits.
c-hater schrieb: > Das darf ich nicht. Ist halt im Kundenauftrag entstanden. Es sollte aber > mit den gegeben Hinweisen absolut trivial sein, das selber zu bauen. > Wenn man halt so einen 1:2 COM-Port MUX/DEMUX braucht... Welche Hinweise? Aber erst erkläre mal bitte, wie du ein inkommendes Signal auf einen von 2 Ports umrouten willst, nur mit CCL, ohne CPU.
Gast
#7264871
Der eigentliche Clou dabei ist, dass man 90MHz mit dem niedrig getakteten AVR verarbeiten kann. LEDs dann blinken zu lassen, ist ja nur eine simple Beispielanwendung.
Uwe D. schrieb: > Wenn der Platz im Speicher knapp ist, dann per Hardware Ich denke das ist ein sehr seltener Grund. Old schrieb: > Der eigentliche Clou dabei ist, dass man 90MHz mit dem niedrig > getakteten AVR verarbeiten kann. Wofür bitte? Das ist mir zu theoretisch. Und man muß ja immer auch eins im Hinterkopf behalten: Viel leistungsstärkere 32-Bit MCUs arbeiten bei/mit höheren Frequenzen und sind nicht oder kaum teurer.
Gast
#7265004
Jan V. schrieb: > Viel leistungsstärkere 32-Bit MCUs arbeiten bei/mit > höheren Frequenzen und sind nicht oder kaum teurer. Im Vergleich zu AVR Aber es gibt ja PIC und EFM mit 4 CCL für unter $1
Lothar schrieb: > Aber es gibt ja PIC und EFM mit 4 CCL für unter $1 Fehlt trotzdem noch die konkrete Anwendung. Wofür also sollte ein 8Bitter 90MHz teilen wollen? Ist ja alles gut und schön was machbar wäre.
Gast
#7265130
Wie bereits geschrieben ist die Anwendung von CCL in der Industrie - nicht für Bastler - Glue Logic Dafür gibt es diese Möglichkeiten: - 74xx-Chips: braucht Platz, teuer - CPLD: gibt es nicht mehr - kleine FPGA: teuer, nicht-deterministisches Timing - billig uC der die Logik im main loop macht: muss programmiert werden, eventuell nicht schnell genug - billig uC mit CCL: muss nicht programmiert werden, nur mit dem CCL Tool konfiguriert, uC macht nichts = kaum Stromverbrauch, deterministisch im nsec Bereich Anstatt also weiter CPLD zu produzieren, werden uC mit zusätzlich CCL ausgestattet, und der uC wird dann gar nicht genutzt. Hier ein Beispiel, das ist ein QFN20 in Stückzahlen 50 Cent und hat 4 CCL https://www.mouser.de/ProductDetail/Silicon-Labs/EFM8BB51F8G-C-QFN20?qs=7D1LtPJG0i3GGYLLlbsrGQ%3D%3D
Lothar schrieb: > Wie bereits geschrieben ist die Anwendung von CCL in der Industrie - > nicht für Bastler - Glue Logic Das entschuldigt die Nichtnennung konkreter Anwendungen ebenso wenig. > Anstatt also weiter CPLD zu produzieren, werden uC mit zusätzlich CCL > ausgestattet, und der uC wird dann gar nicht genutzt. Was *im Falle der AVR* zu belegen wäre. Konkret natürlich. Also ich kann mir das nicht vorstellen.
Gast
#7265165
Lothar schrieb: > - CPLD: gibt es nicht mehr Doch, jede Menge bswp Coolrunner2, auch PAL's gibt es noch. - 74xx-Chips: braucht Platz, teuer Nö die gibt es auch als SMD für apple und nen Ei >Anstatt also weiter CPLD zu produzieren, werden uC mit zusätzlich CCL >ausgestattet, und der uC wird dann gar nicht genutzt. Mumpitz²
So eine EFM Pinfunktions-Crossbar würd ich mir für AVR viel lieber wünschen als diese beschränkte CCL. Dreikäsehochreibe schrieb: > Mumpitz² Wenn das nämlich wirklich so wäre dann hätten die günstigeren AVR Varianten keine abgespeckten CCL LUT/Funktionalitäten, das wär dann nicht ganz logisch.
Angehängte Dateien:
-
crossbar.jpg
(350 KB)
Naja - Du blendest hier aus, dass PIC und AVR hausintern im Wettbewerb stehen. Mit Logik hat das wenig zu tun.
Gast
#7265201
Jan V. schrieb: > Fehlt trotzdem noch die konkrete Anwendung. > Wofür also sollte ein 8Bitter 90MHz teilen wollen? Konkretes Beispiel, wo mangels CCL extern geteilt werden musste: Automatischer Antennentuner mit Messung der Sendefrequenz.
Hmmm schrieb: > Konkretes Beispiel, wo mangels CCL extern geteilt werden musste: > Automatischer Antennentuner mit Messung der Sendefrequenz. Danke.
Uwe D. schrieb: > Du blendest hier aus, dass PIC und AVR hausintern im Wettbewerb stehen. Wollen wir doch mal festhalten daß mit den günstigeren Preisen günstigerer AVR Derivate der Funktionsumfang im Allgemeinen und der der CCL im speziellen eingeschränkt wird. Wenn MCUs nur mit und wegen der CCL eingesetzt würden (jener Mumpitz²) würde man die CCL ja nicht just bei den Varianten beschneiden die gerade wegen ihres niedrigen Preises am ehesten als CPLD bzw. diskrete Logik- Ersatz geeignet wären... Das meinte ich mit nicht ganz logisch.
Gast
#7265277
Hmmm schrieb: > Jan V. schrieb: >> Fehlt trotzdem noch die konkrete Anwendung. >> Wofür also sollte ein 8Bitter 90MHz teilen wollen? > > Konkretes Beispiel, wo mangels CCL extern geteilt werden musste: > Automatischer Antennentuner mit Messung der Sendefrequenz. Genau das z.B. Die zu den AVRs vergleichbaren PICs können selber bis 50…60MHz zählen/teilen, während die AVRs bestenfalls nur 2…3…6MHz beherrschen.
Gast
#7265468
Jan V. schrieb: > Wollen wir doch mal festhalten daß mit den günstigeren Preisen > günstigerer AVR Derivate der Funktionsumfang im Allgemeinen und der der > CCL im speziellen eingeschränkt wird. Die Möglichkeiten der CCL korrelieren (aus technischen Gründen der Implementierung) im Wesentlichen mit der Anzahl der Pins (eigentlich: der Byte-Ports, deren Anzahl aber logischerweise stark von der Pinzahl abhängt). Der Preis der AVR-Controller korreliert im Wesentlichen ebenfalls mit der Anzahl der Pins. Das ist das ganze Geheimnis hinter dem von dir gefundenen Zusammenhang. Keine Illuminaten-Verschwörung...
Old schrieb: > während die AVRs bestenfalls nur 2…3…6MHz beherrschen Meinst Du damit z.B. TCA Event-Counting? c-hater schrieb: > Keine Illuminaten-Verschwörung Nein, aber Lothar's Mumpitz.
Beitrag #7265670 wurde von einem Moderator gelöscht.
So ganz neu ist das mit CCL in Atmel Chips übrigens nicht, die ATSAMC2x haben das seit 2015 und die ATSAMD5x/ATSAME5x seit 2017. Und so ist das jetzt auch in den PIC32CM zu finden die Clones von den ATSAMC2x sind. Die neuere AVR DA Version von CCL kann allerdings mehr, zum Beispiel hat die 2 LUTs mehr.
Gast
#7265915
Rudolph R. schrieb: > Die neuere AVR DA Version von CCL kann allerdings mehr, zum Beispiel hat > die 2 LUTs mehr. Das kann man so allgemein nicht sagen. Es hängt bei allen neueren AVR8 (auch bei den DA/DB) stark von Pinzahl ab, was die CCL kann. Viele andere Features übrigens ebenfalls. Sieht man sehr schön z.B. hier (siehe Anhang). Allein schon die grundlegende Gestaltung der Tabelle stellt das vollkommen klar.
Gast
#7265917
c-hater schrieb: > Sieht man sehr schön z.B. hier (siehe Anhang). Mist, Anhang vergessen.
Angehängte Dateien:
-
ccl.png
(110 KB)
Gast
#7265974
Jan V. schrieb: > Nein, aber Lothar's Mumpitz Wir machen das so es kostet fast nichts und es funktioniert und damit sind Deine Einwände hinfällig :-) Im Übrigen hab ich schon gesehen, dass auch in Schaltschränken, anstatt für eine Logik sechs Relais einzubauen, sowas hier für die Logik programmiert und eingebaut wurde. Kostet nicht mehr und nimmt weniger Platz weg: https://www.controllino.com/product/controllino-mini-pure/
Lothar schrieb: > Wir machen das so es kostet fast nichts Jan V. schrieb: > Was *im Falle der AVR* zu belegen wäre.
Gast
#7266024
Es gibt Bus-Protokolle (GPIB oder die alte Centronics-Druckerschnittstelle) bei denen man quasi sofort auf eine Flanke reagieren muss um den Status zu setzen dass man noch Zeit braucht bis das nächste Datenwort kommen darf. Per Interrupt zu reagieren wäre zu langsam. Für diesem Fall braucht man entweder externe Logik-Gatter oder eben das CCL.
Gast
#7266041
Jan V. schrieb: > Lothar schrieb: > >> Aber es gibt ja PIC und EFM mit 4 CCL für unter $1 > > Fehlt trotzdem noch die konkrete Anwendung. > Wofür also sollte ein 8Bitter 90MHz teilen wollen? Ist ja alles gut und > schön was machbar wäre. Mir schwebt da ein current mode boost converter zum Laden von Akkus vor. Die Regelung und Steuerung in einem AVR.
Gast
#7266051
asd schrieb: > die alte > Centronics-Druckerschnittstelle > Per Interrupt zu reagieren wäre > zu langsam Ganz zufälligerweise hab ich selber genau das eine mit dem anderen betrieben, noch zu Z80 Zeiten. Es geht also. Heute bringt der AVR noch ein mehrfaches an Rechenleistung mit. Entscheidend ist ja meist nicht die sofortige Reaktion sondern daß z.B. eine Flanke nicht verloren geht. In Form eines Interrupt-Flags ist das gesichert. Die CCL dürfte all ihrer Unabhängigkeit zum Trotz meistens doch nur Teil der Lösung sein, bei der das Mitwirken des Controllers kraft seiner Software erforderlich bleibt.
Gast
#7266150
Ron T. schrieb: > Entscheidend ist ja meist nicht die sofortige Reaktion sondern > daß z.B. eine Flanke nicht verloren geht. Das ist richtig. > In Form eines Interrupt-Flags > ist das gesichert. Das ist nicht unbedingt richtig. Bei den PinChange-Interrupts eines AVR8 z.B. dann nicht, wenn mehr als ein Pin ihn auslösen können. Es können sich bis zu 8 Pins so ein Ding teilen. Und zumindest bei den "klassischen" AVR8 gibt es keine Möglichkeit, festzustellen, welcher es nun war, der das Flag gesetzt hat, jedenfalls dann nicht, wenn es mehr als einer gewesen sein könnte. OK, die Dinger haben natürlich auch keine CCL, die hilft hier also nicht weiter. Wenn sie eine hätten, könnte sie aber weiter helfen... > Die CCL dürfte all ihrer Unabhängigkeit zum Trotz > meistens doch nur Teil der Lösung sein, bei der das Mitwirken des > Controllers kraft seiner Software erforderlich bleibt. Das ist in den meisten Fällen sehr wahrscheinlich tatsächlich so. Aber es gibt halt auch Ausnahmen, wo ein Problem komplett in der CCL abhandelbar ist. Siehe mein Beispiel mit dem COM-Port-Mux/Demux.
Beitrag #7266153 wurde von einem Moderator gelöscht.
Gast
#7266328
c-hater schrieb: > Bei den PinChange-Interrupts eines AVR8 > z.B. dann nicht, wenn mehr als ein Pin ihn auslösen können. Es können > sich bis zu 8 Pins so ein Ding teilen Kapazitäten sind begrenzt. Das ist bei allen Kapazitäten so. c-hater schrieb: > usnahmen, wo ein Problem komplett in der CCL > abhandelbar ist. Siehe mein Beispiel mit dem COM-Port-Mux/Demux. Der Beleg steht noch aus. Das haben hier nun schon mehrere bemängelt.
Gast
#7266622
Mit der CCL lässt sich z.B. TxD über die LUT auf eine höhere Timerfrequenz (>1MHz) modulieren. Praktisch angewendet mit einem Tiny1614 in einem 360°-Sensor, dessen Kopf über einen Royer-Konverter versorgt wurde und der über ein zweites konzentrisches Spulenpaar die Daten abgab (da will man naturgemäß etwas von der Royer-Frequenz weg).
c-hater schrieb: > Siehe mein Beispiel mit dem COM-Port-Mux/Demux. Und zum zweten Mal: Welches Beispiel? Wo?
Gast
#7266940
Marc V. schrieb: > Wo? Nirgendwo. Gibts nicht. Passende Ausrede kam doch schon. Aus den Fingern gesogen wie so vieles im Forum. Euro schrieb: > Mit der CCL lässt sich z.B. TxD über die LUT auf eine höhere > Timerfrequenz (>1MHz) modulieren. Schon seeeehr speziell aber danke fürs Beispiel.
Gast
#7267016
Richard schrieb: > Schon seeeehr speziell aber danke fürs Beispiel. Ich will nicht lügen. Mit dem ATMega habe ich früher TxD und SystemClock extern über zwei FETs zur Sendespule hin verknüpft. Jetzt braucht es "nur" noch Einen. Einen Pin spart die Sache übrigens nicht, da in der UART das TxD-Enabled gleichzeitig Logik und Pin-Funktion schaltet.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.