Hallo Ihr, ich versuche nun schon länger anhand der Dokumentation eine simple Funktion zu erstellen. PF1 input -> PF2 Out vom eventsystem welches einfach nur den Portpegel weiter reicht. Nach Dokumentation ist PF2 der Out vom EVOUTF, das sollte klappen. Nur der Rest an Informationen finde ich nicht. Wenn ich alles richtig verstanden habe muss ich eigentlich folgendes machen: Verbinden von PF1 mit einem Eventgenerator "routen" des Events an EVOUTF Hat jemand einen Beispielcode für mich? Gruß Anselm p.S.: Alle Beispiele die ich so finde beziehen sich auf die ATTiny, dort scheinen andere Funktionen/Parameter gebraucht zu werden.
Servus, kurz gesagt mit IAR ohne Hardware hier zu haben:
1 | /* Pin PF2 als Event-out */
|
2 | PORTMUX.EVSYSROUTEA=PORTMUX_EVOUT5_bm; |
3 | |
4 | /* Port F1 ==> Chanenel 4 */
|
5 | EVSYS.CHANNEL4 = EVSYS_GENERATOR_PORT1_PIN1_gc; |
6 | |
7 | /* EV_ch4 ==> OUT F */
|
8 | EVSYS.USEREVOUTF=EVSYS_CHANNEL4_bm; |
Leider heissen die Register anders als bei der Attiny-1 Serie. Aber nach meiner Erfahrung sollte es so passen. Leider gibts beim Portmux und IAR kein vernünftiges #define für den Ausgang. Wenn du den gcc verwendest, werden die Namen der #defines etwas anders heissen, sollte aber trotzdem funktionieren. Gruß und berichte bitte auch ob es klappt.
Ist zwar Assembler (-Macro), sollte aber klar sein:
1 | ; "PF1 input -> PF2 Out": |
2 | puti EVSYS_CHANNEL4,0b0100__1_001 ; PF1 input |
3 | puti EVSYS_USEREVOUTF,4 +1 ; PF2 Out |
Hallo, finden tut man das im Manual Kapitel 14.5.2. Es gibt auch eine App Note dazu. Die benutzbaren Channels richten sich immer nach dem Event Generator. Event User kannste an alle Channels ranhängen. Das heißt du schaust in die Tabelle und guckst mit welchen Channel du den Eingangspins verbinden kannst, den Generator. Alle 'Generator' Pins von Port F kannste nur mit Channel 4 oder 5 verbinden. Damit wird auch der Event Port 1 festgelegt, linkere Spalte in der Tabelle. Alle vordefinierten Namen findest du im Controller Headerfile ab Zeile 643. Ansonsten musste alle Bits im Register einzeln verordern und zuweisen.
1 | EVSYS.CHANNEL4 = EVSYS_GENERATOR_PORT1_PIN1_gc; // verbinde Generator 'Pin PF1' mit Kanal 4 |
PORT1 ist aus Tabelle festgelegt. PIN1 ist das Bit1 von deinem Port PF1. Welche Pins als Event User verfügbar sind findet man in der Pin I/O Tabelle "Multiplexed Signals". In Spalte EVSYS. PF2 -> EVOUTF. Es wird damit nicht der gesamte Port F zum User sondern nur der eine Pin davon.
1 | EVSYS.USEREVOUTF = EVSYS_CHANNEL_CHANNEL4_gc; // verbinde User Pin PF2 mit Kanal 4 |
Vorher konfigurierst du Pin PF2 noch als Ausgang. Extra Port Signale umrouten muss man nicht.
> Vorher konfigurierst du Pin PF2 noch als Ausgang.
Kann nicht schaden, schien aber bei mir nicht nötig zu sein.
Hallo, also DDR Bits sind nicht gesetzt und dennoch reagiert das wie low aktiv. Muss ich bei Gelegenheit mal genauer untersuchen. Sollte den TO erstmal nicht beunruhigen.
Vielen Dank Veit, das mit dem Port1/Pin1 irritiert total, es bezieht sich aber auf den Eventsys generator (der ja nur mit speziellen pins verbunden werden kann. Zu sehen unter 14.5.2 im Manual. Gibt es Dokumentation die solche wichtige Information wie den Namen "EVSYS_CHANNEL_CHANNEL4_gc" benennt? Soetwas habe ich nicht finden können. Gruß Anselm p.S.: Ich verwende Microchipstudio & GCC
Anselm 6. schrieb: > Gibt es Dokumentation die solche wichtige Information wie den Namen > "EVSYS_CHANNEL_CHANNEL4_gc" benennt? > Soetwas habe ich nicht finden können. sollte in irgendwelchen .h-files zu finden sein. Port 1 Pin 1 ist nach Tabelle in Kap. 14.5.2 der Pin 1 von Port 1 (in diesem Fall bei Event-Kanal 4 eben Port F). Ist irgendwie blöd "komprimiert" geschrieben. Vergiss aber nicht, beim Portmux den Ausgang zu setzten, sonst hat der Pin keine Ahnung, daß er auf den Event-Ausgang reagieren soll. Gruß
Sorry, Der Chef schrieb: > > Vergiss aber nicht, beim Portmux den Ausgang zu setzten, sonst hat der > Pin keine Ahnung, daß er auf den Event-Ausgang reagieren soll. > Ist bei dem Device quatsch (ich bin halt mehr auf dem attiny814 zu hause, und da muß man den Portmux wirklich setzen). Bei dem Atmega4809 scheint es so zu sein, daß man im Portmux gar nix setzen muß, um den Eventoutput zu ermöglichen. Ob man dafür das DDR-Register setzen muß, kommt nicht klar raus.
1 | /* Pin PF2 als Event-out */
|
2 | |
3 | PORTMUX.EVSYSROUTEA=PORTMUX_EVOUT5_bm; |
scheint also nicht nötig. Sorry nochmal für die Falschinfo. Kannst Du mal Deinen "nicht-funktionieren" Code posten? Danke Robert
Hallo Veit Devil, ich wollte Anselm ja auch nicht beunruhigen, sondern nur meinen vergleichsweise dürftig aussehenden Zweizeiler rechtfertigen.
> solche wichtige Information wie den Namen "EVSYS_CHANNEL_CHANNEL4_gc"
Ist sicher ein Stück weit Geschmackssache, aber mir ist das zu
umständlich: _bp und _bm und _gc, und dann noch die ellenlangen
Bezeichner - ins Datenblatt muss ich ohnehin schauen, dann kann ich auch
gleich die Bitmuster hinschreiben.
Hallo, ich verstehe dich schon, keine Sorge, ist ja zum Glück alles Geschmacksache. Ich selbst finde das angenehmer wenn man später seinen Code liest, dann macht der sprechende Name für mich Sinn. Auch wenn er zugegeben sehr lang ist. Ich benötige von alledem nur die Bitmasken _bm oder die Gruppenbits _gc. Ich glaube der Gesamtaufwand wird gleich sein. Entweder man sucht sich im Manual alle Bits zusammen oder man guckt im Headerfile nach einem passenden Namen. Werden viele Einzelbits benötigt ist der _gc Name sogar kürzer. :-) :) @ Anselm: Wenn du das Atmel/Microchip-Studio verwendest, markiere ein Registernamen oder Bitname, Maus Rechtsklick, springe zur Definition/Dekalration und du landest im Controller Headerfile. Genauso kannste das mit Funktionen machen und landest bei deren Definition. Beim Controller Headerfile suchste mal auf dem Rechner nach iom4809.h. Diese Datei habe ich mir nach Funktionseinheiten zerlegt, dann geht die Suche noch schneller. Am Ende entwickelt jeder seinen eigenen Stil. Das was ich aktuell mit den vordefinierten Namen mache, hätte ich beim ATmega328P/2560 gar nicht machen können bzw. kann man nicht machen. Da gibts keine fertigen Bitmasken oder Gruppenbitnamen. Da muss man zwangsweise Einzelbits verordern.
Hallo, übrigens, merke ich jetzt erst, es gibt wie früher gar keine einzelnen definierten Bits mehr. Sowas wie _BV(CS12) kann man gar nicht schreiben. Was Microchip vielleicht hätte machen können, einige Doppelte zusammenfassen können.
1 | typedef enum TCA_SINGLE_CLKSEL_enum |
2 | {
|
3 | TCA_SINGLE_CLKSEL_DIV1_gc = (0x00<<1), /* System Clock */ |
4 | TCA_SINGLE_CLKSEL_DIV2_gc = (0x01<<1), /* System Clock / 2 */ |
5 | TCA_SINGLE_CLKSEL_DIV4_gc = (0x02<<1), /* System Clock / 4 */ |
6 | TCA_SINGLE_CLKSEL_DIV8_gc = (0x03<<1), /* System Clock / 8 */ |
7 | TCA_SINGLE_CLKSEL_DIV16_gc = (0x04<<1), /* System Clock / 16 */ |
8 | TCA_SINGLE_CLKSEL_DIV64_gc = (0x05<<1), /* System Clock / 64 */ |
9 | TCA_SINGLE_CLKSEL_DIV256_gc = (0x06<<1), /* System Clock / 256 */ |
10 | TCA_SINGLE_CLKSEL_DIV1024_gc = (0x07<<1), /* System Clock / 1024 */ |
11 | } TCA_SINGLE_CLKSEL_t; |
12 | |
13 | typedef enum TCA_SPLIT_CLKSEL_enum |
14 | {
|
15 | TCA_SPLIT_CLKSEL_DIV1_gc = (0x00<<1), /* System Clock */ |
16 | TCA_SPLIT_CLKSEL_DIV2_gc = (0x01<<1), /* System Clock / 2 */ |
17 | TCA_SPLIT_CLKSEL_DIV4_gc = (0x02<<1), /* System Clock / 4 */ |
18 | TCA_SPLIT_CLKSEL_DIV8_gc = (0x03<<1), /* System Clock / 8 */ |
19 | TCA_SPLIT_CLKSEL_DIV16_gc = (0x04<<1), /* System Clock / 16 */ |
20 | TCA_SPLIT_CLKSEL_DIV64_gc = (0x05<<1), /* System Clock / 64 */ |
21 | TCA_SPLIT_CLKSEL_DIV256_gc = (0x06<<1), /* System Clock / 256 */ |
22 | TCA_SPLIT_CLKSEL_DIV1024_gc = (0x07<<1), /* System Clock / 1024 */ |
23 | } TCA_SPLIT_CLKSEL_t; |
Das hätte vielleicht auch das gereicht
1 | typedef enum TCA_SPLIT_CLKSEL_enum |
2 | {
|
3 | TCA_CLKSEL_DIV1_gc = (0x00<<1), /* System Clock */ |
4 | TCA_CLKSEL_DIV2_gc = (0x01<<1), /* System Clock / 2 */ |
5 | TCA_CLKSEL_DIV4_gc = (0x02<<1), /* System Clock / 4 */ |
6 | TCA_CLKSEL_DIV8_gc = (0x03<<1), /* System Clock / 8 */ |
7 | TCA_CLKSEL_DIV16_gc = (0x04<<1), /* System Clock / 16 */ |
8 | TCA_CLKSEL_DIV64_gc = (0x05<<1), /* System Clock / 64 */ |
9 | TCA_CLKSEL_DIV256_gc = (0x06<<1), /* System Clock / 256 */ |
10 | TCA_CLKSEL_DIV1024_gc = (0x07<<1), /* System Clock / 1024 */ |
11 | } TCA_CLKSEL_t; |
Aber alles hätte könnte vielleicht nützt nichts, ich schweife ab ...
Hallo Veit Devil, nun, dann will ich, als AVR-Studio 4.11 Nutzer (und für mich abschließend), noch eine gewisse Frustration loswerden: wo beim ATmega4809 noch ein 'EVSYS_USEREVOUTF' reichte, verlangt Microchip für die AVR-Dx 'EVSYS_USEREVSYSEVOUTC', das kann ich nur unter Bezeichnerlängen-Inflation einordnen, und was den "sprechenden Namen" betrifft, da ziehe ich meinen eigenen Kommentar vor, wenn ich z.B. an dies Register 'FAULTCTRL' denke. Gruß aus dem (heute sonnigen) Schwarzwald
Hallo, also, diese nackten Zeilen
1 | EVSYS.CHANNEL4 = EVSYS_GENERATOR_PORT1_PIN1_gc; // PF1 IN |
2 | EVSYS.USEREVOUTF = EVSYS_CHANNEL_CHANNEL4_gc; // PF2 OUT |
sorgen scheinbar dafür sich Pin PF2 wie ein gesetzter Ausgang verhält. Obwohl kein Direction Bit gesetzt ist. Ich habe die Register dabei ausgelesen. Zeitgleich zieht es den Eingang PF1 ohne aktivierten Pullup bei mir immer sofort auf '1', wenn ich das Kabel von Masse nehme. Setze ich das PF2 Direction Bit verhält es nicht genau anders herum. Ausgang PF2 ist immer '0' bzw. Led leuchtet nicht. Außer ich lege PF1 auf '+'. Sobald ich das wegnehme geht das Input Bit auf 0. Ich dachte das ist alles intern CMOS Technik, da müßte doch das unbeschaltete Eingangsbit länger auf dem letzten Wert bleiben. 'grübel' Außerdem kann ich im Manual nichts lesen das das Eventsystem den I/O überschreibt. Das Verhalten von PF2 deutet jedoch daraufhin. Ich setze dennoch lieber das Direction Bit bis das eindeutig geklärt ist.
Veit D. schrieb: > Zeitgleich zieht es den Eingang PF1 ohne aktivierten Pullup > bei mir immer sofort auf '1', wenn ich das Kabel von Masse nehme. Servus, Offene Eingänge nehmen einen zufälligen Pegel an. Das ist durch interne Leckströme bedingt. Deshalb steht auch ganz oft in Datenblättern: Input-Pins should not float. Im blödsten Fall ist der Pegel auch nicht ganz stabil, und die interne Eingangsbeschaltung wechselt dauernd zwischen HIGH und LOW, was zu einer (sinnlosen) aber messbaren erhöhten Stromaufnahme führt. Also brav per Pull-up (intern möglich) oder Pull-Down (nur extern möglich) auf ein definiertes Potential legen. Die Leckströme sind nach Tabelle 32.17 typischerweise <50nA, d.h. der Widerstand kann schon ordentlich hochohmig sein, maximal halt so groß, daß bei 50nA noch ein ausreichend hoher/niedriger Pegel erreicht wird. Da im Datenblatt nur typische Werte angegeben sind, würde ich halt mal noch Faktor 10 Luft lassen. Gruß Robert
Hallo, ich glaube wir reden aneinander vorbei. Wie sich offene Eingänge verhalten ist mir bekannt. Nur verhält sich dieser Eingang hier nicht wie ein offener Eingang. PF1 hat einen stabilen und immerwährenden gleichen Pegel nach Reset etc. Welcher Pegel das ist, ist nur abhängig vom Direction Bit PF2. Die einzigste Erklärung wäre derzeit, wie du auch erwähnst, durch interne Leckströme und weil es Nachbarpins sind, dass sich da intern was einstellt. Mich wunderte das die Led an PF2 sofort und immer leuchtet mit nur diesen beiden Codezeilen - auch immer wieder nach Resets.
Hallo Veit Devil, mir ist unklar, was Sie wie messen. Bei mir sieht es gleich aus, egal ob mit oder ohne 'sbi VPORTF_DIR,2': an PF1 ist die Mitte eines Spannungsteilers, zwei 100 kOhm nach Ucc und GND, angeschlossen, und dort messe ich immer die Hälfte von Ucc. Tippe ich kurz auf GND, geht PF2 auf low, tippe ich auf Ucc, geht PF2 high, und bleibt jeweils dort. Aber: worum geht es überhaupt, was wäre zu beweisen?
Hallo, die Monoflop artigen Effekte sind gelöst. Das liegt am Steckbrett. Sobald ich ein Jumperkabel am Pin PF1 einstecke sinkt die Ausgangsspannung an PF2 minimal ab, die Led wird minimal dunkler, sieht man nur bei ganz genauen hinschauen. Messtechnisch jedoch reproduzierbar. Ohne eingesteckten Kabel an PF1 habe ich nun auch den erwarteten Effekt des nur antippens. Dann bleibt es eine ganze Weile Low bis es irgendwann auf High wechselst. Alles im grünen Bereich. Die Steckbretter erzeugen ja sowieso kapazitive Effekte. Ich wollte wissen warum PF2 eigenständig ohne extra Konfiguration als Ausgang arbeitet. Da die Led "satt" leuchtet wie sie leuchten soll und nicht glimmt, muss der Pin irgendwie als Ausgang konfiguriert sein, trotz das DIR 0 ist. Im Manual unter Eventsystem finde ich keinen Hinweis das hier der I/O vom Eventsystem überschrieben wird. Steht ja sonst immer dabei. Es kann aber bald gar nicht anders sein als das der I/O überschrieben wird. Ansonsten würde die Led nicht korrekt leuchten. Ich vermute aktuell es wurde im Manual vergessen zu erwähnen. Eine andere Erklärung fällt mir aktuell dazu nicht ein.
Okay, hatte ich ja schon vor drei Tagen erwähnt. Ist einerseits sinnvoll, dass das automatisch erfolgt, andererseits aber eigentlich nicht wichtig, wer es nicht weiß, konfiguriert eben zusätzlich. Dass der Umstand nicht im Datenblatt zu finden ist ... - dazu sage ich jetzt lieber nichts. Der AVR128DB28 verhält sich übrigens genauso.
Angehängte Dateien:
-
Alternate_Functions.png
30 KB
Veit D. schrieb: > Ich vermute aktuell es wurde im Manual vergessen zu erwähnen. Die neuen Datenblätter sind ne Krätze. Bei den alten AVRs gabe es für jeden Pin eine Tabelle, wo ganz genau die Logikgleichungen für jede Sonderfunktion standen. Anbei mal als Beispiel der ATmega328. Schön zu sehen ist, daß an PD1 das TXEN das DDOE setzt, also die UART den Pin auf Ausgang setzt. Gerade wenn soviel an Konfigurationen dazu gekommen ist, wäre es doch besonders wichtig, die Datenblätter übersichtlich zu halten. Ich hab ehrlich gesagt auch keine Lust, was mit den neuen AVRs zu machen. Die vielen Zusatzfeatures (EVSYS, PORTMUX, CCL) sind nette Gimmicks, aber in der Praxis braucht man sie kaum. Die Timer sind auch viel komplizierter und die Beschreibung verworrener geworden. Der Gate Mode ist hinzugekommen, was ja der alte 8051 auch schon konnte. Der konnte sogar gleichzeitig externen Takt und Gate Mode.
Hallo, also mal ehrlich. Von Krätze kann absolut keine Rede sein. Wirklich nicht. Man muss sich auf das neue Format einlassen. Ich habe mich relativ schnell daran gewöhnt und muss sagen, ich finde den Aufbau sogar besser wie die alten Atmel Manuals. Gerade wenn man die Register der Einheit die man gerade beackert benötigt, gibts immer eine Überblickstabelle mit allen Bitnamen an Bitposition. Wo man früher durch das halbe Manual blättern musste. Jetzt kann man im Manual gleich per Klick hinspringen. Und nur weil jetzt hier eine Info fehlt, ist nicht gleich das gesamten Manual schlecht. Bei allen kleinen Problemchen kann ich das wirklich nicht alles über einen Kam scheren. Wenn ich längere Zeit die Neuen in der Mangel hatte und dann mal wieder was mit einem alten µC mache, dann merke ich erst wie "umständlich" die alte Atmel Manual Struktur ist. Und erinnere dich bitte zurück, waren die ersten Atmel Manuals perfekt? Die Timer sind anders ja, komplizierter finde ich die nicht. Man muss sie aber auch verstehen wollen. Die Features finde ich auch nicht schlecht. Man kann ein paar Interrupts oder Laufzeitcode einsparen mit dem Eventsystem. Da wird sich mit der Zeit immer mehr dafür finden. Man muss nur etwas umdenken. Portmux kann man fürs Layout auch immer gebrauchen. Die Summe an Möglichkeiten macht den µC interessant und die AVRxDB Serie noch viel viel mehr. Außerdem kann man mit dem Support reden und sich eine Tabelle wünschen. Man hat es dann wenigstens versucht. Falls du fragen zum Timer hast, nur zu, ich versuche zu helfen. Auch wenn du letztens beim OVF Thema zu mir sehr wortkarg warst.
Dass aber das Datenblatt der AVR128DB kein copy erlaubt, halte ich für eine merkwürdige, um nicht zu sagen absurde, Einstellung von Microchip. Wird auch nicht dadurch besser, dass es z.B. bei Bosch-Sensoren ebenso ist.
Hallo, okay, machen wir es so, wenn es nicht zu offtopic wird, der TO scheint eh raus zu sein, sammel ich hier bis Ende April alle Mängel des Manuals und dann schreibe ich an den Support. Egal ob megaAVR0 oder AVRxDB oder AVRxDA. bisher: [megaAVR0] - Pin Funktion Eventsystem EVOUTx Override fehlt (sehr wahrscheinlich) - Pin Funktion Override Tabelle wäre nett [AVRxDB] - .pdf Eigenschaften zu stark eingeschränkt Was stört euch noch? Einfach locker aufzählen.
> megaAVR0 ... Eventsystem EVOUTx Override ... Nun, wie bereits erwähnt, gilt das auch für AVR-DB (und hat dort den wohlklingenden Bezeichner 'EVSYS_USEREVSYSEVOUTx' (woran sich aber natürlich nichts mehr ändern lässt)).
@S. Landolt Microchip.pdf mit pdf24creator einlesen und editierbar wieder abspeichern.
Danke, einen entsprechenden Tipp hatte ich bereits vor einiger Zeit von jemandem hier erhalten. Aber als Kritikpunkt halte ich daran fest - oder kennt jemand den tieferen Sinn dahinter, Bosch macht es ja ebenfalls?
Hallo, der Tipp kam damals übrigens von mir. ;-) Beim AVRxDB ist das Eventsystem umfangreicher. Ich kann es mit anbringen. Andere defines wurde auch schon geändert. Natürlich sinkt die Chance je länger der Controller im Markt ist.
Peter D. schrieb: > Die neuen Datenblätter sind ne Krätze. Das ist leider nur zu wahr. Insbesondere die Tatsache, dass sie oft über lange Zeit schlicht unvollständig bleiben. Und dazu die Tatsache, dass sie an vielen Stellen schlicht falsch (oder auch "nur": unzutreffend) sind. Es geht hier ganz klar in Richtung des unsäglichen Wahnsinns, an den man sich bei ARM-Datenblättern praktisch jeden Herstellers schon seit langer Zeit gewöhnen musste... > Die vielen Zusatzfeatures (EVSYS, PORTMUX, CCL) sind nette Gimmicks, > aber in der Praxis braucht man sie kaum. Naja, PORTMUX kann hilfreich sein, um z.B. wenigstens einen 8Bit-Port frei zu bekommen, wenn man große Teile der eingebauten Peripherie benutzt. Für EVSYS habe ich bisher nur zwei sinnvolle Verwendungen gefunden. Nämlich: 1): ADC mit einem Timer synchronisieren. Die Möglichkeiten der klassischen AVR dafür gibt es nicht mehr, aber z.B. für Schaltregler (in Software) ist das ein absolut notwendiges Feature für eine gute Regelung. 2) CCL mit Timer(n) verknüpfen, für einen rotary decoder in Hardware. Das erschließt Bereiche bezüglich der sicher erfassbaren Schrittrate, die mit den klassischen AVR schlicht völlig unmöglich sind (jedenfalls, wenn der auch noch was anderes tun soll als den dämlichen Encoder zu lesen). Das CCL hingegen finde ich absolut geil. Das kann sehr oft externe Hardware sparen. Wenn die möglichen Pin-Mappings dafür etwas flexibler wären, könnte man das sogar noch viel öfter und intensiver nutzen. So läuft es aber oft darauf hinaus: entweder externe Hardware oder einen "größeren" (und damit natürlich i.d.R. teureren) AVR. Das ist sehr schade. > Die Timer sind auch viel komplizierter Nicht wirklich. Sie sind halt nur ein bissel anders. Das Prinzip ist aber natürlich weitgehend das gleiche. Was auch sonst.... > und die Beschreibung verworrener Das stimmt. Vor allem aber ist sie UNVOLLSTÄNDIG. Ganz zentrale Punkte ihres Verhaltens werden teilweise nicht dokumentiert oder zumindest nicht klar verständlich. Das betrifft inbesondere den Typ-D-Timer.
Veit D. schrieb: > Auch > wenn du letztens beim OVF Thema zu mir sehr wortkarg warst. Kanst Du mal nen Link darauf posten. Ich bin schon älter (ü60) und kann mir nicht alles merken. Ich fand das alte Konzept, das alle in einem PDF steht, sogar richtig Klasse. Bei den ARM-TDMI habe ich geflucht, daß man gefühlt 1000 PDFs braucht, eins allein für den Interruptcontroller usw. usw. Der Speicherplatz ist doch heutzutage kein Problem mehr aber jeder Programmierer soll sich die Arbeit für den konkreten Typ von neuem machen.
Man kann auch prima ohne Umschalterei Pulsbreiten messen (EVSYS mit Timer), mehr Zeit für kritische/andere Aufgaben.
Veit D. schrieb: > bisher: > > [megaAVR0] > - Pin Funktion Eventsystem EVOUTx Override fehlt (sehr wahrscheinlich) > - Pin Funktion Override Tabelle wäre nett > Das verstehe ich inhaltlich nicht, also was genau fehlt.
Uwe D. schrieb: > Veit D. schrieb: >> bisher: >> >> [megaAVR0] >> - Pin Funktion Eventsystem EVOUTx Override fehlt (sehr wahrscheinlich) >> - Pin Funktion Override Tabelle wäre nett >> > > Das verstehe ich inhaltlich nicht, also was genau fehlt. Hab es gerade beim ATTiny412 gemerkt: Da fehlen alle alternativen Pins in der Multiplexing Tabelle... Für den ATTiny402 ist diese korrekt. Was für‘n Witz.
Hallo, @ Peter: ich schreibe dir das noch kurz per PN. Kann aber öffentlich vorweg nehmen, dass alles im Nachgang betrachtet mit heutigen Wissen alles nicht mehr so schlimm ist. Hatte ja was dabei gelernt. Von daher ist alles gut. :-) Ich möchte das im öffentlichen Raum nicht negativ stehen lassen. Zum Thema Manual. Es gibt nur ein .pdf wo alles drin steht. ? Es gibt auch eine Excel Pin Übersichtstabelle. Das ist die Portmux Übersicht in Excel. Ich ahne jedoch etwas. Verwendest du noch die alten Manuals? Zu Beginn gab es 2 oder gar 3 .pdf's, ja, das wurde vor einer Weile zusammengefasst zu einem gewohnten Manual für diesen Controller. Version DS40002173C von 2021. Das Einzigste was ausgelagert ist, ist das Instruction Set Manual DS40002198B. @ Uwe: Peter wünscht sich eine Übersichtstabelle woraus einfacher hervorgeht welche Funktionseinheit die normale I/O Port Funktion überschreibt. Was zum Bsp. die Usart macht. Siehe paar Antworten weiter oben. Normalerweise steht das in den Kapiteln zu den Funktionseinheiten drin. Beim ATmega4808/09 und AVDxDB ist das zumindestens drin, wenn auch ohne zusätzliche Tabelle. @ c-hater: Da die TCD vom AVRxDB Problembeschreibung sicherlich sehr umfangreich ausfällt, kannste vielleicht selbst an den Support schreiben. Ansonsten ändert sich das nicht. Ich selbst habe mit TCD noch nichts weiter gemacht außer der Tonerzeugung im "bekannten" Thread.
Uwe D. schrieb: > Hab es gerade beim ATTiny412 gemerkt: Da fehlen alle alternativen Pins > in der Multiplexing Tabelle... Für den ATTiny402 ist diese korrekt. Was > für‘n Witz. Habe mir das mal angeschaut. Es steht alles da. Was fehlt denn? Manual DS40002287A. In den Spalten stehen immer die Alternativen mit hochgestellter 3) drin.
:
Bearbeitet durch User
Danke @Veit. Du hast ein anderes PDF referenziert, das ist in Ordnung so. Aber: In diesem PDF DS40001911A ist eben nicht alles drin. Und ich meine das betrifft nur dieses Dokument, dass ich heute Morgen bei Microchip direkt von der Webseite gezogen habe. Ja, das „Preliminary“ habe ich zu spät wahrgenommen...
Hallo, DS40001911A.pdf ist von 2017. Das wirst du wohl kaum heute von der offiziellen Seite zum Controller gezogen haben. Maximal bist du im Archiv gelandet. Ich gehe immer direkt auf die Seite des Controllers und von dort aus auf Documents. So hat man immer die aktuelle Version.
Veit D. schrieb: > Hallo, > > DS40001911A.pdf ist von 2017. Das wirst du wohl kaum heute von der > offiziellen Seite zum Controller gezogen haben. Maximal bist du im > Archiv gelandet. Doch, genau heute. Denn zum Testen habe ich nock keinen neuen Tiny mit 8 Pins, deshalb habe ich Google angeschmissen und geguckt. Der Gedanke war, die ATTiny85 basierten Sensoren künftig mit den neuen Tinys zu bauen - eben weil einiges jetzt in Hardware geht.
Also wenn ich auf der Seite 'ATTINY412' (ignorieren wir mal die Schreibweise) unter 'Documents' das 'ATtiny212/214/412/414/416 Data Sheet' lade, erhalte ich DS40002287A (und dort funktioniert sogar das copy).
Hallo, okay, mir ist jetzt klar was du gemacht hast. Suchbegriff eingegeben und 2. Link direkt auf das .pdf geklickt. Das ist das alte 2017er Manual. Vertraue niemals blind einer Suchmaschine. :-) Ich klicke immer auf den 1. Link direkt zu Microchip usw.
:
Bearbeitet durch User
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.