Hallo, kann mir jemand ein Tutorial empfehlen. Ich möchte mich näher mit den SAM-Controllern beschäftigen und habe mir erstmal den SAMD10 ausgesucht. Leider scheitere ich bereits am Datenblatt. Ich möchte es vorerst ohne ASF versuchen. Irgendwie will es nicht in meinen Kopf, wie das mit den "Multiplexed Signals" funktioniert. Habe schon ein Knoten im Kopf. Mir fehlt der Einstiegspunkt.
Meinst du sowas?
1 | /*
|
2 | * PB16: PWM output to generate V[LCD]
|
3 | * PB16 = TC6/WO[0], function E
|
4 | * Normal PWM 8-bit mode, 16 MHz / 2 / 256 = 31.25 kHz PWM frequency
|
5 | */
|
6 | GCLK->CLKCTRL.reg = GCLK_CLKCTRL_CLKEN | GCLK_CLKCTRL_GEN(0) | |
7 | GCLK_CLKCTRL_ID(GCLK_CLKCTRL_ID_TC6_TC7_Val); |
8 | TC6->COUNT8.CTRLA.reg = TC_CTRLA_MODE(TC_CTRLA_MODE_COUNT8_Val) | |
9 | TC_CTRLA_WAVEGEN(TC_CTRLA_WAVEGEN_NPWM_Val) | |
10 | TC_CTRLA_PRESCALER(TC_CTRLA_PRESCALER_DIV2_Val); |
11 | while (TC6->COUNT8.STATUS.bit.SYNCBUSY) {} |
12 | TC6->COUNT8.CTRLA.reg |= TC_CTRLA_ENABLE; |
13 | while (TC6->COUNT8.STATUS.bit.SYNCBUSY) {} |
14 | TC6->COUNT8.CC[0].bit.CC = 5; /* yields about -1.4 V */ |
15 | PORT->Group[1].PMUX[16 / 2].bit.PMUXE = PORT_PMUX_PMUXE_E_Val; |
16 | PORT->Group[1].PINCFG[16].bit.PMUXEN = 1; |
(die letzten beiden Zeilen) Ist jetzt von einem SAMD20/21, aber das Prinzip dürfte beim 10er gleich sein. Manchmal findet man auch noch sowas drüber:
1 | #define PORTB PORT->Group[1]
|
Damit kannst du dann schreiben:
1 | PORTB.PMUX[16 / 2].bit.PMUXE = PORT_PMUX_PMUXE_E_Val; |
2 | PORTB.PINCFG[16].bit.PMUXEN = 1; |
Macht es etwas offensichtlicher, dass PB16 hier gemeint ist.
:
Bearbeitet durch Moderator
Das wäre genau was ich meine. Ohne ASF. Aber wie findet man die ganzen Parameter für die Einstellung des SAM? Das ist schon, wie ich finde, sehr komplex. Das Datenblatt gibt mir hier keinen mir einleuchtenden Weg vor. Vielleicht sehe ich ihn nur nicht. So ein "Fahrplan" wäre schon toll.
Warum ohne AFS? Schau dir halt das AFS-Beispiel an und kopier den Teil raus den du brauchst.
BlaBla schrieb: > Aber wie findet man die ganzen Parameter für die Einstellung des SAM? Die Tabelle "PORT Function Multiplexing" nennt dir dir Alternativbelegung des jeweiligen Portpins. In meinem Fall steht das Gewünschte im Kommentar über dem Codeblock: "PB16 = TC6/WO[0], function E". (Timer/Counter 6, Waveform output 0) Vielleicht beschreibst du ja mal eine Funktionalität, die du suchen würdest, und ich finde dir dann, wie man diese konfigurieren würde. Oder meinst du all die anderen Namen wie TC_CTRLA_WAVEGEN(TC_CTRLA_WAVEGEN_NPWM_Val) etc.? Dafür habe ich im Editor typischerweise das Headerfile in einem Fenster geöffnet.
Fabian F. schrieb: > Warum ohne AFS? AFS sagt mir jetzt nichts. Ich möchte vorerst ohne das Framework (ASF oder Start) arbeiten. Ich halte den Lerneffekt für größer. Jetzt drucke ich mir erst einmal einige, wie ich hoffe, für mich relevante Seiten aus. Jörg W. schrieb: > Vielleicht beschreibst du ja mal eine Funktionalität, die du suchen > würdest, und ich finde dir dann, wie man diese konfigurieren würde. Werde ich machen...Danke!
Jörg W. schrieb: > Fabian F. schrieb: >> Warum ohne AFS? > > Several layers of obfuscation and additional delays … Compileroptimierung kürzt das raus.
Fabian F. schrieb: > Jörg W. schrieb: >> Fabian F. schrieb: >>> Warum ohne AFS? >> >> Several layers of obfuscation and additional delays … > > Compileroptimierung kürzt das raus. Nein. Du hast dir das Zeug vermutlich noch nicht angesehen. Wenn man zum Setzen eines Bits erstmal eine Struktur ausfüllen muss, damit dann anschließend alles in einem Subsystem entsprechend eingestellt wird, dann kürzt das eben keine Optimierung mehr raus. Schließlich sind die IO-Register volatile, da darf der Compiler gar nichts dran ändern. ASF (und auch vergleichbare Obfuscation layers anderer Hersteller) sind eher ein Beispiel, wie man solch eine Abstraktion besser nicht machen sollte. Habe mir das angesehen und (für den dienstlichen Gebrauch) dankend drauf verzichtet. Da zimmere ich mir meinen Salat lieber selbst, dann blicke ich erstens noch durch und muss mich zweitens nur dann ausbremsen lassen, wenn es wirklich nicht anders geht. Ich benutze ASF lediglich als Referenz, wenn ich mal nachschauen will, wie das Problem, welches ich gerade lösen möchte, denn bei Atmicrochip umgesetzt worden wäre.
Hier: https://github.com/ataradov/mcu-starter-projects Gibt es einige schöne Repos, die man als Ausgangspunkt für eigene Hackereien um die SAMs nutzen kann, ohne ASF, allerdings mit korrekt eingebunden Headern für Registerdefinitionen etc.
Hallo martin, Das ist ein tolles Repo! Das gibt mir gleich Lust mit meinem selbstgemachten SAME70 Board loszulegen. Momentan wollte ich darauf warten, dass Microchip endlich den ASF Sourcecode in Harmony anbietet. Aber insgeheim hasse ich eh diesen ganzen Frameworkmist. Ein bisschen Abstraktion ist ja gut auf Mikrocontrollerebene, aber bei Harmony hast du überhaupt keine Idee mehr, was überhaupt noch vorgeht. Die frühere Peripheral Library von Microchip fand ich eigentlich perfekt für meinen Gebrauch: für jedes Modul (UART, SPI, ...) gab es einen Header und ein Sourcefile und die Funktionen/Argumente waren gut beschrieben (bzw selbsterklärend ihrer Namen wegen) und machten auch nichts weiter als die Register zu beschreiben. Gibt es irgendwo in ASF ein äquivalent zu der Peripheral Library? Ich kenne mich mit ASF nicht so gut aus, aber alleine die Ordnerstruktur kommt mir extrem groß vor. mfG macload1
Okay, Ich habe mir das Repo nochmal angeschaut, und eigentlich ist alles drin was soll. Beim ersten Blick fehlten mir die Funktionen wie "OpenSPI" ... aber wie schon oben gesagt, die beschrieben ja eh nur die verschiedenen Register und beim zweiten hinschauen sind diese Register auch relativ gut beschrieben in dem Repo. Vielen Dank für den Link! macload1
Auch ich finde es auf den ersten Blick interessant. Wird sicherlich beim Verständnis helfen. Danke an Martin.
martin schrieb: > Hier: https://github.com/ataradov/mcu-starter-projects Alexander Taradov, wusste gar nicht, dass er jetzt bei den SAMs gelandet ist. ;-) Hatte früher Support für unsere AT86RFxxx-Chips gemacht, auf jeden Fall ein helles Köpfchen. Bei avrfreaks.net heißt er "alexru".
Ich habe gerade einen ATSAMD10-XMINI angeschlossen und das Beispielprogramm "DEMO" aus dem Ordner "ATSAMD10\mcu-starter-projects-master\mcu-starter-projects-master\samd10 " von Alexander Taradov gestartet. Läuft bestens!! Hierauf kann ich aufbauen. Spitze!
Ich hänge gerade wieder: was bedeutet diese Zeichen "\" innerhalb des Programms?
1 | #define HAL_GPIO_PIN(name, port, pin) \
|
2 | static inline void HAL_GPIO_##name##_set(void) \
|
3 | { \
|
4 | PORT->Group[HAL_GPIO_PORT##port].OUTSET.reg = (1 << pin); \
|
5 | (void)HAL_GPIO_##name##_set; \
|
6 | }
|
C-Grundlagen … line continuation Braucht man in normalen Quelltexten natürlich nicht, weil dort die Zeilenaufteilung egal ist. Eine Makrodefinition muss sich allerdings komplett auf einer (logischen) Zeile befinden. Wenn man sie auf mehrere physische Zeilen aufteilen möchte, muss man die innerhalb des Makros befindlichen Newlines durch einen Backslash unwirksam machen.
Danke. Leider noch nie selbst gemacht. Deshalb die "blöde" Frage.
Beim Analysieren der Datei hal_gpio.h (SAMD10) ist mir eine Zeile aufgefallen, die ich an dieser Stelle nicht erwartet hätte. Das Makro sollte doch nur den Pin auf Output schalten. Warum wird der INEN für den Pin gesetzt?
1 | static inline void HAL_GPIO_##name##_out(void) \ |
2 | { \
|
3 | PORT->Group[HAL_GPIO_PORT##port].DIRSET.reg = (1 << pin); \ |
4 | ---> PORT->Group[HAL_GPIO_PORT##port].PINCFG[pin].reg |= PORT_PINCFG_INEN; \ |
5 | (void)HAL_GPIO_##name##_out; \ |
6 | }
|
Vielleicht willst du ja trotzdem den Pin-Zustand auch mal rücklesen können? Der wesentliche Grund für PINEN = 0 ist es doch, wenn man an den Pin ein Analogsignal anschließt, dass die Eingangstransistoren dann nicht laufend hin und her schalten (und dabei Stom ziehen). Sowie der Portpin für ein reines Digitalsignal benutzt wird (egal ob Ein- oder Ausgang), ist es OK, das Einganggatter auch mit dem Pin zu verbinden.
Jörg W. schrieb: > Sowie der Portpin > für ein reines Digitalsignal benutzt wird (egal ob Ein- oder Ausgang), > ist es OK, das Einganggatter auch mit dem Pin zu verbinden. Verstanden. Steht ja sogar im Datenblatt unter *Totem-Pole Output with Enabled Input*. Hätte mal nur ein paar Seiten weiterlesen soll 8-).
Bitte 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.