W.S. schrieb: > Du sollst nicht 10 Stunden lang "diverse Treiber" ausprobieren, sondern > innerhalb dieser Zeit begreifen, wie der Hase läuft und dann selbst > was zustande bringen. > > Es ist doch so UNSÄGLICH EINFACH! Ich hab das genauso mit USB CDC auf dem STM32F103 gemacht xD Das war ein Sonntag - ziemlich genau 10h - und nach dem uhm ähm 9ten Versuch oder so hat's dann endlich geklappt ;-) W.S. schrieb: > Lade dir mal das herunter: > "https://www.mikrocontroller.net/attachment/316790/STM32F103C8T6.ZIP"; > und lies es dir durch. Das ist ein Minimal-System, was auf nem > chinesischen ST-Link2 für stolze 2 Euro oder so läuft und du kannst per > USB CDC damit kommunizieren. Ja wahnsinn! Hab mir wirklich die Finger wund gegoogelt und etliche USB CDC Codes getestet, bis ich zähneknirschend aufgegeben hab und mich schlussendlich meinem Schicksal - an ST's HAL und CubeMX gebunden zu sein - hingab und meinen bereits HAL-freien und funktionierenden Code nach HAL portieren musste :S Den werde ich auch noch testen ... :)
:
Bearbeitet durch User
oooooooder man machts mit Assembler. Da gibts keine Konstrukte ;) Für die meisten kleinen Basteleien (wo der Code kaum länger als ein paar Seiten wird) ist doch Assembler völlig ausreichend. Meistens gehts doch darum, Pins einzulesen und je nach Status andere Pins zu schalten. Meistens sind es doch so Sachen wie: temperatur > X? wenn nicht, springe zu ende ausgang4 schalten led3 schalten ende: Und nichtmal mehr SPI muss man heutzutage noch selber programmieren. Einfach nur "sts SPDR,r16" und schon geht das Byte in r16 auf Reisen. Ob man jetzt "sts SPDR,r16" schreibt oder "SPDR = 123" ist doch nun wirklich kein grosser Unterschied. Allerdings besteht für einen Einsteiger in C die Gefahr, auf die Idee zu kommen, sowas wie "SPDR = 'Hallo Welt'" schreiben zu wollen.
Einverstanden. Bei ASM muss man vorher noch ldi r16,123 schreiben. Nicht hauen! ;)
ASM Superprofi schrieb: > Für die meisten kleinen Basteleien (wo der Code kaum länger als ein paar > Seiten wird) ist doch Assembler völlig ausreichend. Du scheinst einen Hang zum Minimalismus zu haben ... Finde ich prinzipiell nicht schlecht, allerdings ist das mittlerweile unnötig. Evtl resultiert das auch aus deiner Liebe zu den 8-pinnigen Tinys ... Evtl ist da der C-Compiler schon damit überfordert xD Was mich halt ein bisserl stört ... Bei dir schwingt immer so ein "Ich bin so geil" mit ... Ich bin so geil, mir reichen 8Pins ... Ich bin so geil, mir reicht Assembler usw^^
:
Bearbeitet durch User
Es findet sich sicher jemand, der auf dem AtTiny einen Cross-C-Compiler für einen Intel-PC schreibt und damit die neueste PC-Software schreibt... ;-)
ASM Superprofi schrieb: > Für die meisten kleinen Basteleien (wo der Code kaum länger als ein paar > Seiten wird) ist doch Assembler völlig ausreichend. Meistens gehts doch > darum, Pins einzulesen und je nach Status andere Pins zu schalten. Stimmt schon, nur will man normalerweise auch noch ein Display dranhängen, zwei Taster und ein kleines Menü für irgendwelche Einstellungen dazubasteln. Das wird mit Assembler schnell extrem lästig, selbst dann, wenn es sich nur um eine 7-Segment-Anzeige handelt. Ich bleibe dabei: mit Basic oder C (einschließlich dessen Derivate) kommt man in der halben Zei4t ans Ziel. Eine LED kann man mit 6 Zeilen Basic ohne nachdenken zu müssen zum Blinken bringen. Schneller geht es nicht!
Mampf F. schrieb: > Was mich halt ein bisserl stört ... Bei dir schwingt immer so ein "Ich > bin so geil" mit ... Ich bin so geil, mir reichen 8Pins ... Ich bin so > geil, mir reicht Assembler usw^^ Dann sieh es halt anders: Ich bin so arm, dass ich mir nichtmal leisten kann, einen mega für eine einfache LED-Blinkerei zu nehmen!!! Ich bin so dumm, dass ich C nicht kapiert habe und deshalb bei ASM Zuflucht gesucht habe.
Schreiber schrieb: > Stimmt schon, nur will man normalerweise auch noch ein Display > dranhängen, zwei Taster und ein kleines Menü für irgendwelche > Einstellungen dazubasteln. Ab "Display dran mit Menüführung" bin ich durchaus damit einverstanden, die Sache in C anzugehen... ... obwohl ich meine TFTs mit ASM ansteuere. Hach ich bin ja so geil!! Für Mampfi: Da ich zu blöd bin zu kapieren, wie man ASM mit C Objekten mischt, musste ich tatsächlich eine TFT Lib in ASM schreiben :(((((( ;)
ASM Superprofi schrieb: > ldi r16,123 ARM Assembler ist besser, einfacher, orthogonaler, und sowieso :-) W.S. schrieb: > Kinetis-Blabla-Studio Da gibt es doch jetzt das ganz neue und tolle MCUXpresso :-) Bereite mich grade auf den Zwangsumstieg von LPCXpresso vor ... http://www.nxp.com/products/software-and-tools/run-time-software/mcuxpresso-software-and-tools/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE
ASM Superprofi schrieb: > Für Mampfi: Da ich zu blöd bin zu kapieren, wie man ASM mit C Objekten > mischt, musste ich tatsächlich eine TFT Lib in ASM schreiben :(((((( > > ;) ?????
W.S. schrieb: >> Es gibt dafür die schöne Erfindung des Kapitels. > Das war zwar ein netter Spruch, aber ich würde dich dafür dazu > verdammen, einmal einen Kinetis MKE06xxx aufzusetzen, OHNE deren > Kinetis-Blabla-Studio verwenden zu dürfen. Hab ich gemacht. Überhaupt kein Problem. Hatte mich vorher anhand eines STM32 in ARM eingearbeitet (davor AVR). Alles im Selbststudium. Erst Kinetis L, dann später noch E. Die Kinetis E0x-Reihe ist so minimalistisch, die Dinger sind kein bisschen schwieriger als damals ein ATmega, das GPIO ist ab Reset schon eingeschaltet und die Peripheriefunktionen auf den Pins aktivieren sich bei Benutzung von selbst, genau so simpel wie beim AVR. Die Dokumentation ist sauber und übersichtlich aufgebaut, alles steht genau da wo man es vermutet und wo es auch hingehört: * Jede Peripherie hat ein eigenes Kapitel in dem alles erklärt wird, jedes Register und jedes Bit, teils auch mit Code-Beispielen oder Ablaufplänen für die Initialisierung oder die empfohlene Behandlung im Interrupt. * Und im Kapitel 3 ist aufgelistet wieviele von jeder Sorte auf diesem konkreten Chip instantiiert sind und wie die untereinander verschaltet sind (Mux-Tabellen, etc). * Alles was man zur Programmierung braucht steht übersichtlich in einem einzigen Dokument. Wenn man links das Inhaltsverzeichnis des PDF aufklappt findet man jede Information binnen Sekunden. Und hat man ein Kinetis Manual gesehen kennt man sie alle. Mir ist nicht klar warum Du immer wieder behauptest die Doku wäre schlecht, von der hervorragend organisierten Kinetis Doku könnten sich mancher andere ein Scheibe abschneiden. Das einzige was nervt (aber das ist bei allen anderen ebenfalls so) ist daß man tonnenweise unnötigen Schrott herunterladen und durchwühlen muss bis man irgendwo versteckt im hintersten Zipfel eines unförmigen "SDK" .zip versteckt hinter Tonnen von stinkendem HAL-Unrat die eigentlich wichtigen Sachen wie CMSIS-Header, Linkerscripte und Startup findet, aber das muss man ja pro CPU nur ein einziges mal machen, dann hat mans, und da bekleckern sich andere Hersteller auch nicht mit Ruhm, bei STM gehts diesbezüglich genauso unübersichtlich zu.
:
Bearbeitet durch User
Eine letzte Frage hätte ich noch bezüglich Atmega328, es gibt verschiedene Bezeichnungen bei den Chips, z.B. Atmega328, Atmega328p, Atmega328p-pu. Ziemlich verwirrend, was ist da der Unterschied bzw. spielt das überhaupt ne Rolle welchen ich zu Beginn nehme?
oleg schrieb: > Eine letzte Frage hätte ich noch bezüglich Atmega328, es gibt > verschiedene Bezeichnungen bei den Chips, z.B. Atmega328, Atmega328p, > Atmega328p-pu. Ziemlich verwirrend, was ist da der Unterschied bzw. > spielt das überhaupt ne Rolle welchen ich zu Beginn nehme? Und die wirklich letzte Frage, kann ich mit diesem Atmega328 das AVR Tutorial hier auf dieser Seite durcharbeiten? Davon abgesehen, dass ich hier im Form jede Menge Hilfe bekommen könnte.
oleg schrieb: > z.B. Atmega328, Atmega328p, > Atmega328p-pu. *P - “Picopower”, hat ein paar Powersave-Funktionen mehr als der ohne P. Die angehängten -PU etc. bezeichnen die Gehäusevarianten. Die findest du am Ende des Datenblatts erklärt (“Ordering Information” und “Packaging Information”). Wenn man sie weglässt, beschreibt man halt nur das generische Bauteil, ohne auf das Gehäuse einzugehen. > Ziemlich verwirrend, was ist da der Unterschied bzw. > spielt das überhaupt ne Rolle welchen ich zu Beginn nehme? Das Gehäuse dürfte sehr wohl eine Rolle spielen :), nicht jeder wird beispielsweise gleich einen ATmega328P-MU nehmen wollen.
Mampf F. schrieb: > Ja wahnsinn! Nee, nix Wahnsinn. Ich hatte vor Jahren mal den USB-Quellcode von Nuvoton auseinander genommen, weil der so unsäglich von Macros strotzte, daß man ne Krise davon kriegt. Als Ergebnis hab ich mir dann meinen eigenen USB-CDC-Treiber geschrieben und auf die Vorlage von Nuvoton gepfiffen. Die haben es nämlich auch nicht besser gemacht als all die Anderen (NXP, ST und so) und einen irren Haufen Kruscht eingebaut - insbesondere sowas wie Arrays variabler Länge von void Pointern. Klasse, sowas liebt unsereins über alle Maßen!! Ich krieg jetzt noch Pickel, wenn ich nur dran denke... W.S.
Bernd K. schrieb: > Die Dokumentation ist sauber und übersichtlich aufgebaut, alles steht > genau da wo man es vermutet und wo es auch hingehört: > > * Jede Peripherie hat ein eigenes Kapitel in dem alles erklärt wird, > jedes Register und jedes Bit, teils auch mit Code-Beispielen oder > Ablaufplänen für die Initialisierung oder die empfohlene Behandlung im > Interrupt. So langsam regen mich deine ständigen Behauptungen auf. Worüber schreibst du eigentlich? Ich hab den Eindruck, du schreibst über ein ganz anderes Produkt als ich. Also, ich schreibe zum Beispiel über "MKE02P64M40SF0RM.pdf", das ist das RefManual zu den MKE02Z16VLC4, MKE02Z32VLC4, MKE02Z64VLC4, MKE02Z16VLD4, MKE02Z32VLD4, MKE02Z64VLD4, MKE02Z32VLH4, MKE02Z64VLH4, MKE02Z32VQH4, MKE02Z64VQH4, MKE02Z16VFM4, MKE02Z32VFM4 und MKE02Z64VFM4. Dort gibt's ein Kapitel 11: Port Control (PORTS). Dort werden aber nicht die Ports und deren Verwendung erklärt, sondern lediglich das Glitchfilter, die Pullups, die Pulldowns und die Stromstärke (HDRIVE). Eigentlich würde das in das Kapitel 32: GPIO gehören. Die tatsächliche Port-Verwendung, also ob so ein Pin nun UART-TxD oder Counter-Clock oder I2C oder GPIO oder was sonst noch sein soll, wird weder in Kapitel 11 noch in Kapitel 32 geklärt. Dazu findet man NUR in "MKE02P64M40SF0.pdf", was das Datenblatt zu einigen der im RefManual behandelten µC ist, eine Tabelle. Geht so, zwar nicht schön, aber geht. Aber schauen wir mal dort rein und nehmen uns ein Pin heraus, z.B. PTB2. Das kann sein: PTB2(also GPIO), KBI0_P6(Keyboard-Interrupt), SPI0_SCK(SPI eben), FTM0_CH0(Timer Modul), ADC0_SE6(Analog). So! Wenn man jetzt PTB2 als GPIO benutzen will, aber eben auch den SPI-Modul und auch den Timer-Modul - natürlich auf anderen Ports, oder den Timer z.B. nur intern ohne I/O, wie stellt man jetzt die Funktion dieses PTB2 denn ein? Bei anderen Kinetis-Familien ist das so gehandhabt wie bei vielen µC von NXP und ST. Da gibt es HW-Register, wo man die gewünschte Port-Funktion hineinschreibt und fertig ist die Zuweisung. Aber bei der MKE-Reihe gibt es derartige Register eben NICHT. Verstehst du das endlich? Es gibt sie NICHT! Deswegen kann man den Portpins auch nicht dediziert ihre Funktion zuweisen, wie man das bei anderen Produkten kann. Das ist schlichtweg Bockmist der Sonderklasse. Bei meiner damaligen Anfrage an Freescale wurde mir geantwortet, daß man die Auswahl damit tätigt, daß man keine weiter rechts in der Tabelle des Datenblattes "MKE02P64M40SF0.pdf" (Seiten 32..33) stehende Peripherie aktiviert, denn es wird automatisch immer die Funktion dem Pin zugewiesen, die am weitesten rechts in der Tabelle steht. Klasse! Wenn ich nen Pin als GPIO benutzen will, bei dem z.B. auch UART0 aufgelistet ist, dann darf ich UART0 nicht aktivieren, weil sonst der Pin nicht mehr als GPIO benutzbar ist. Nun taucht UART0 mehrfach auf, hier sowohl auf PTB1 als auch auf PTA3 - und wo steht, wie man beim festlegen der Pins verfahren muß, auf denen man UART0 nicht haben will? UART0_TxD braucht man ja nur einmal und nicht auf allen dafür möglichen Pins. Die Antwort ist klar: Man muß für jedes Pin durch alle seine möglichen Verwendungen tingeln und in den dafür zuständigen Peripherie-Cores genau DIESE Verwendung ausschließen, z.B. indem man dort ein anderes Pin ansagt (falls man damit nicht an andere Setup's anrempelt) oder den Core eben irgendwie so einstellt, daß er eben genau DIESES Pin nicht benutzt. Im Klartext: Für die immer wiederkehrende Basis-Arbeit des Zuweisens der Funktionen für ein Port-Pin muß man immer wieder durch alle Kapitel des RefManuals sich durchquälen und dort Einstellungen vornehmen. Gilt aber nur, wenn man das weiß! In keiner Dokumentation zu dieser Familie ist das tatsächliche Verfahren zur Funktions-Auswahl beschrieben - man kann das allenfalls stückweise zwischen den Zeilen lesen. Dieses Verfahren ist (Damen mal bitte wegschauen) OBERSCHEISSE! Es geht nur dann passabel, wenn man brav das Konfigurations-Tool des Herstellers benutzt, weil man selber von Hand mit dem Konfigurieren des Chips graue Haare kriegt. Da ganze gleicht etwas dem Rubik-Würfel: Um eine Sache einzustellen, muß man an allen anderen Sachen zugleich mitdrehen - und das so lange, bis es denn endlich paßt. Nein, gerade bei dieser Kinetis-Familie sucht man sich tot in den Manuals, eben weil dort weder in der Hardware noch in der Dokumentation die Dinge dort und so sind, wo und wie sie hingehören. Natürlich riecht man den Zweck dahinter. Was ST mit Cube, Infineon mit Dave und andere Hersteller mit jeweils ihren Tools tun, das macht Freescale eben auch. So Bernd, jetzt bist du dran: Schildere doch einfach mal, wie man all den Portpins eines der genannten µC dediziert deren gewünschte Funktionen zuweist. Nach deiner Meinung geht das ja so einfach. W.S.
W.S. schrieb: > Bernd K. schrieb: >> Die Dokumentation ist sauber und übersichtlich aufgebaut, alles steht >> genau da wo man es vermutet und wo es auch hingehört: >> >> * Jede Peripherie hat ein eigenes Kapitel in dem alles erklärt wird, >> jedes Register und jedes Bit, teils auch mit Code-Beispielen oder >> Ablaufplänen für die Initialisierung oder die empfohlene Behandlung im >> Interrupt. > > So langsam regen mich deine ständigen Behauptungen auf. Worüber > schreibst du eigentlich? Ich hab den Eindruck, du schreibst über ein > ganz anderes Produkt als ich. > > Also, ich schreibe zum Beispiel über "MKE02P64M40SF0RM.pdf" Was stimmt bei Dir nicht? Bei jeder Gelegenheit meckerst Du rum wie Dir die Handbücher nicht passen aber jedesmal kommst Du wieder mit nem neuem MKE oder MKL an, diesmal ein MKE06. Warum hängst Du so sehr an Kinetis wenn sie doch so scheiße sind? Und wenn Dich tatsächlich jemand dazu zwingt warum merkst Du Dir nicht endlich mal die zwei oder drei Kapitelüberschriften die bei ALLEN Kinetis identisch lauten in denen immer wieder die selben 3 Sachen stehen nach denen Du immer und immer wieder wieder fragst und die man Dir jedesmal aufs Neue beantwortet und namentlich die Kapitel nennt und die Du jedesmal angeblich trotzdem wieder suchen musst wenn Du trotz tiefster Abneigung wieder mit dem nächsten Kinetis daherkommst der fast identisch aufgebaut ist wie der letzte und fast das selbe RefMan hat? Was ist los mit Dir? > Dort gibt's ein Kapitel 11: Port Control (PORTS). Dort werden aber > nicht die Ports und deren Verwendung erklärt, sondern lediglich das > Glitchfilter, die Pullups, die Pulldowns und die Stromstärke (HDRIVE). > Eigentlich würde das in das Kapitel 32: GPIO gehören. Im PORT Kapitel steht gleich am Anfang dick und fett daß deren IO über die GPIO-Register kontrolliert wird. Wer lesen kann ist klar im Vorteil. In den Blockschaltbildern ist das auch bebildert für die die weniger gut lesen können. Das ist bei allen Kinetis so, auch bei den letzte 12 über die Du Dich aufgeregt hast, und be jedem steht schwarz auf weiß im PORT-Kapitel daß IO über die GPIO-Register gemacht wird langsam sollte sich das im Hirn eingebrannt haben, meinst Du nicht? > Die tatsächliche > Port-Verwendung, also ob so ein Pin nun UART-TxD oder Counter-Clock oder > I2C oder GPIO oder was sonst noch sein soll, wird weder in Kapitel 11 > noch in Kapitel 32 geklärt. Dazu findet man NUR in > "MKE02P64M40SF0.pdf", was das Datenblatt zu einigen der im RefManual > behandelten µC ist, eine Tabelle. Geht so, zwar nicht schön, aber geht. Nein, das ist gelogen. Pinout und Alternate-Funktionen stehen dick und fett im Kapitel 10 Signal multiplexing and pin assignments (wie bei ALLEN Kinetis). Das ist das selbe PDF, man muss hier nicht nach dem Datenblatt suchen. Und das ist kein verstecktes Unterkapitel das man erst aufklappen müsste, das springt einen sofort an in der ersten Ebene. Mach die Augen auf / kauf Dir eine Brille (nichtzutreffendes streichen). > So! Wenn man jetzt PTB2 als GPIO benutzen will, aber eben auch den > SPI-Modul und auch den Timer-Modul - natürlich auf anderen Ports, oder > den Timer z.B. nur intern ohne I/O, wie stellt man jetzt die Funktion > dieses PTB2 denn ein? Im SIM->PINSEL stellt man das ein, das steht dick und fett und blau unterlegt (und verlinkt) gleich am Anfang des oben genannten Kapitels Signal multiplexing and pin assignments. Stellst Du Dich absichtlich so dumm? Bist Du ein Troll? > Aber bei der MKE-Reihe gibt es derartige Register eben NICHT. > Verstehst du das endlich? Es gibt sie NICHT! SIM->PINSEL. Wie oben erwähnt. > Wenn ich nen Pin als GPIO benutzen will, bei dem z.B. auch UART0 > aufgelistet ist, dann darf ich UART0 nicht aktivieren, Dann legst Du den UART0 halt eben auf die beiden Alternativpins, wo ist das Problem? > Im Klartext: Für die immer wiederkehrende Basis-Arbeit des Zuweisens der > Funktionen für ein Port-Pin muß man immer wieder durch alle Kapitel > des RefManuals sich durchquälen und dort Einstellungen vornehmen. Bullschit. Man nimmt die Tabelle mit dem Pinout (immer noch Kapitel 10 welches sich bereits in den Bildschirm eingebrannt haben sollte) und sucht sich die Pins für UART, SPI, ADC, oder was auch immer aus die man gerne verwenden will, trägt die getroffene Auswahl im PINSEL-Register ein und der Rest bleibt GPIO. Fertig. > Dieses Verfahren ist (Damen mal bitte wegschauen) OBERSCHEISSE! Bei AVR hat man das genauso gemacht, Sonderfunktionen liegen auch da auf festen Pins und wenn man z.B. den UART einschaltet krallt der sich seine beiden Pins von selbst, trotzdem hört man immer wieder AVR sei so einfach. Beim MKE funktionierts genauso. > Es geht > nur dann passabel, wenn man brav das Konfigurations-Tool des Herstellers > benutzt, weil man selber von Hand mit dem Konfigurieren des Chips graue > Haare kriegt Das erzähl mal den ganzen AVR-Programmierern hier dort geht das exakt genauso: erst sucht man sich die Pins mit den Sonderfunktionen raus die man für irgendwas braucht und der ganze Rest der übrig bleibt kann für GPIO verwendet werden. hat noch keiner graue Haare von bekommen und nach nem Konfig-Tool hab ich dort noch keinen schreien hören. Du solltest vielleicht das Hobby wechseln wenn Dir das so sehr zusetzt daß es schon die Haarfarbe angreift. > Da ganze gleicht etwas dem Rubik-Würfel: Um eine Sache > einzustellen, muß man an allen anderen Sachen zugleich mitdrehen - und > das so lange, bis es denn endlich paßt. Bei welchen "allen anderen" Sachen? Du sprichst in Rätseln. > Nein, gerade bei dieser Kinetis-Familie sucht man sich tot in den > Manuals, Also ich blende immer als erstes links das Inhaltsverzeichnis ein, dann finde ich Kapitel 3 oder Kapitel 10 (die beiden Kapitel die Du andauernd aufs neue suchst) binnen 2 Sekunden.
:
Bearbeitet durch User
Bernd K. schrieb: > Dann legst Du den UART0 halt eben auf die beiden Alternativpins, wo ist > das Problem? Daß eben auf den Alternativpins bereits etwas anderes zu liegen gekommen ist und daß man dann selbiges eben abwürgt, sofern UART0 in der Tafel eben weiter rechts steht. Kapierst du diese Umständlichkeit nun endlich? Man muß eben genau so, wie ich das geschrieben habe, durch alle Kapitel tingeln, um sich die Informationen mühsam zusammenzusuchen, die man braucht. Und es ist eben doch der Rubik-Würfel, wenn man zum Auswählen eines GPIO den USART erst mal auf nen Alternativport und den Timer auch auf nen Alternativport und den Weißdergeier auch noch auf seinen Alternativport verlegen muß und dann zusehen muß, was man dann mit den Alternativports anstellt, um sie sinnvoll benutzen zu können. Also genau wie du es auf deine Art umrissen hast, muß man bei diesen µC kreuz und quer im RefManual und im DB herumsuchen, um sich die Informationen zusammen zu klauben, die man braucht, um das Teil benutzen zu können. Stets und ständig steht eben was man braucht nicht dort, wo man es braucht, sondern woanders oder garnicht. Und warum ich gelegentlich drauf zurückkomme? Nun, ganz einfach: Weil eben die Chips und die Dokumente dazu von Freescale so schlecht sind wie sie sind. Schade eigentlich, der Preis hätte mich durchaus interessiert, aber in der Gesamtkalkulation ist es eben nur ein Posten von vielen. Aber so leicht lasse ich dich nicht davonkommen, da du ja den entsprechenden Ton angeschlagen hast. Also erkläre der lauschenden Gemeinde doch abschließend mal, wie man denn vorgeht, wenn man z.B. sämtliche Timer intern zu gebrauchen gedenkt und dennoch alle Portpins als GPIO zu benutzen gedenkt. Nur so als Beispiel zwecks Klarheit über die Vorgehensweise. W.S.
W.S. schrieb: > Man muß eben genau so, wie ich das geschrieben habe, durch alle Kapitel > tingeln, um sich die Informationen mühsam zusammenzusuchen, die man > braucht. Nein, muss man nicht, man muss * erstens planen welche Peripheriegeräte man zu nutzen gedenkt * zweitens dann in der Tabelle nachschauen auf welchen Pins die rauskommen und das in seinem Schaltplan entsprechend anschließen * drittens alles was übrig bleibt kann man als GPIO nutzen und das in seinem Schaltplan entsprechend anschließen. Fertig. Ich sehe nicht wozu man da durch irgendwelche Kapitel "tingeln" muss, alle möglichen Pinfunktionen für jeden einzelnen Pin stehen übersichtlich in der Pinout Tabelle, diese Tabelle ist alles was man dazu braucht.
W.S. schrieb: > Also erkläre der lauschenden > Gemeinde doch abschließend mal, wie man denn vorgeht, wenn man z.B. > sämtliche Timer intern zu gebrauchen gedenkt und dennoch alle Portpins > als GPIO zu benutzen gedenkt. Nur so als Beispiel zwecks Klarheit über > die Vorgehensweise. Dann schaltet man einfach keinen der PWM-Ausgänge ein, was auch nicht weiter schwer ist denn die sind ja per Default sowieso alle erstmal ausgeschaltet und wenn Du die Timerkanäle nur für interne Zwecke nutzt (Interrupt, DMA-Trigger, etc) hast Du ja nicht den geringsten Grund die PWM-Erzeugung einzuschalten. Dann bleiben die zugehörigen Pins auf GPIO weil nicht anderweitig genutzt.
Da ist es doch herrlich wenn die Hersteller Werkzeuge liefern mit denen man einfach so komplizierte Konfigurationen hinbekommt ohne die Manuals lesen zu müssen :-)))
JojoS schrieb: > Da ist es doch herrlich wenn die Hersteller Werkzeuge liefern mit denen > man einfach so komplizierte Konfigurationen hinbekommt ohne die Manuals W.S. ud ich streiten uns hier über einen KE06, der ist ungefähr so kompliziert wie ein ATMega und konfiguriert sich auch so ähnlich: Schaltest Du die PWM-Erzeugung an kannst Du den betreffenden Pin (der im Pinout so beschriftet ist) nicht mehr als GPIO nutzen. Schaltest Du den UART an krallt der sich seinen TX-Pin. Schaltest ihn wieder ab ist der Pin wieder GPIO. Dafür hat noch keiner ein Konfig-Tool gebraucht, da gibts nämlich überhaupt nix zu konfigurieren, das geht automatisch. Da muss man nur in der Tabelle nachschauen welche Peripherie auf welchen Pins rauskommt. Optimal für ängstliche AVR-Umsteiger, da fühlt man sich gleich wie zuhause.
:
Bearbeitet durch User
Naja, so Tools wie Cube von ST meckern schon wenn etwas nicht zusammen passt. Wenn man das zur Laufzeit umkonfiguriert können die natürlich auch nicht helfen, aber einfacher als ein Telefonbuch dickes Manual durch zu lesen sind die Tools schon. Ansonsten noch ein entspanntes Wochenende.
JojoS schrieb: > aber einfacher als ein Telefonbuch dickes Manual > durch zu lesen sind die Tools schon. Es reicht für den Anfang alle Kapitel wegzulassen die Funktionen beschreiben die man gar nicht nutzen will. Die sind nämlich allesamt per Default ausgeschaltet und kommen einem nicht in die Quere. Man liest die algemeinen Kapitel am Anfang die das Produkt beschreiben und einen Überblick verschaffen, das sind vielleicht 100 Seiten (im Taschenbuchformat luftig gesetzt und mit Diagrammen angereichert, nicht im Telefonbuchformat), und vom Rest nur noch gezielt das was man braucht.
:
Bearbeitet durch User
Sehe ich auch so, trotzdem erwartet man zB das Pins per default gpio sind aber nach Reset zB debug pins sind. Bin ich vor Jahren beim mega32 drauf reingefallen und das gibts bei den ARM heute noch genauso. Gut wenn man es vorher gelesen hat, aber in welchem Kapitel fängt der blutige Angänger an?
Johannes S. schrieb: > Sehe ich auch so, trotzdem erwartet man zB das Pins per default gpio > sind aber nach Reset zB debug pins sind. Beim Kinetis E (über den ich mich oben mit WS stritt) ist das genau so:
1 | After reset, the shared peripheral functions are disabled so that the pins |
2 | are controlled by the parallel I/O except PTA4, PTA5, PTB4 and PTC4 that are |
3 | default to SWD_DIO, SWD_CLK, NMI and RESET function. All of the parallel I/O |
4 | are configured as high- impedance (Hi-Z). |
> Bin ich vor Jahren beim mega32 > drauf reingefallen und das gibts bei den ARM heute noch genauso. Worauf genau bist Du reingefallen? > Gut > wenn man es vorher gelesen hat, aber in welchem Kapitel fängt der > blutige Angänger an? Bei Kapitel 1, bis der allgemeine Teil vorbei ist, der ganze Rest ist Nachschlagewerk.
Bernd K. schrieb: > Worauf genau bist Du reingefallen? Der berühmte Port C bei dem einige Bits nicht funktionierten (weil sie per default Jtag sind). Das war früher wöchentliches Thema wie 'LED ohne Wiederstand' und 'mein 7805 glüht'. Aber auch da wurde sie hier schon geholfen.
Johannes S. schrieb: > Der berühmte Port C bei dem einige Bits nicht funktionierten (weil sie > per default Jtag sind). Ja, für solche Sachen kann man das Manual immer gut gebrauchen. Es gibt halt leider noch keine andere Möglichkeit wie man das Wissen schneller ins Gehirn uploaden kann. Ich würd mir statt nem riesigen Datenblatt auch lieber den zugehörigen Braindump besorgen und dann 5 Sekunden lang den Stick ins Ohr stecken ums zu laden, aber das geht leider noch nicht.
Gut, ich habe mitgelesen (jeden einzelnen Beitrag) und bin zu dem Schluss gekommen es mit dem ARM auf mich zu nehmen (STM32F0Discovery). Hauptaugenmerk wird aber zuerst das AVR Tutorial mit einem AVR sein. In den Cortex werde ich mich dann parallel einarbeiten, ganz zwanglos und ohne Stress :-) Danke einem jeden einzelnen von euch, eure Meinungen waren sehr hilfreich für mich.
oleg schrieb: > Danke einem jeden einzelnen von euch, eure Meinungen waren sehr > hilfreich für mich. Wir haben zu danken ... Es ist normalerweise die Regel, dass Gäste - nachdem die eine Diskussion angestoßen haben - nie wieder die Antworten lesen ... Gut, dass das alles nicht umsonst war xD
Das mit den Parallel einarbeiten würde ich lassen. Die Unterschiede sind einfach zu groß. Am besten erst mal den AVR verstehen dann zum ARM übergehen. Ein ARM ist einfach zu komplex um als Anfänger das Registerwerk zu verstehen.
Marco H. schrieb: > das Registerwerk zu verstehen Das „Registerwerk“ ist ja nun eher nicht das Problem, das ist kaum schwieriger zu verstehen als das beim AVR (und überdies völlig durch den C-Compiler versteckt). Schwieriger ist da eher das „Drumrum“ zur CPU, also die Erzeugung der diversen Takte, der Interruptcontroller und dergleichen. Einen Teil dieser zusätzlichen Komplexität findet man auf der AVR-Seite allerdings auch bereits bei den Xmegas vor, auch dort ist der Einstieg ein bisschen komplexer als bei den Standard-AVRs.
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.