Moin,
mir gehen die pins am ATmega328p aus, ich würde gerne PC5 als Output
setzen. Wenn ich
DDRC |= (1 << PC5);
setze, funktioniert u.a. die serielle Kommunikation nicht mehr
(PD[0:1]), über die ich auf den MUC zugreife. Ich bin nicht sicher, was
sonst noch alles nicht mehr funktioniert oder ob der MUC komplett hängt.
Google sagt der Pin wird bei anderen (!) ATMega MUCs für JTAG benutzt
und die entsprechende Fuse zu deaktivieren hilft, aber soweit ich weiß
hat der 328p kein JTAG?
Keine Ahnung ob das relevant ist, aber PC[0:2] sind bereits Ausgänge
(funktionierend), und PC[3:4] werden als Eingänge über pin-change
Interrupts abgefragt, was ebenfalls funktioniert. Die in-change
Interrupts auf PC[3:4] zu deaktivieren ändert nichts am Problem.
Danke im Voraus!
Port C ist der mit den ADC Eingängen, der eine Sonderstellung
bei der Versorgung hat. Er wird nämlich durch AVcc versorgt
und nicht durch die normalen Vcc Pins.
Jetzt könnte es sein dass du versehentlich AVcc nicht
angeschlossen hast? Und das Abblock-C dazu auch nicht?
Ansonsten müsstest du halt mal deine Schaltung und/oder
deinen Aufbau zeigen ....
Zweite mögliche Ursache:
(aus dem Datenblatt:)
SCL/ADC5/PCINT13 – Port C, Bit 5:
SCL, 2-wire Serial Interface Clock: When the TWEN bit in TWCR is set
(one) to enable the 2-wire Serial Interface, pin PC5 is disconnected
from the port and becomes the Serial Clock I/O pin for the 2-wire
Serial Interface.
------------------------------------------------------------------
Wenn also aus irgendeinem Grund "sich jemand erlaubt" im TWCR
herumzuspielen kann der Pin eine andere Funktion bekommen als
die die du dir vorstellst.
Hi Arduinoquäler,
AVCC und VCC sind zusammen gelegt. Wie gesagt PC[0:2] als Outputs
funktionieren (treiben LEDs), ebenso funktionieren PC[3:4] als
(digitale) Inputs.
Im Datenblatt finde ich folgenden Satz: "Note that PC6...4 use digital
supply voltage, VCC." Ich interpretiere das so dass lediglich PC[0-3]
den AVCC verwenden, wäre aber bei mir ja egal, da extern zusammen
gelegt.
Eine Schaltung in geeigneter Form habe ich aktuell nicht, aber hier mal
die komplette Pinbelegung vom AVR in Reihenfolge der Pins:
PC6: reset pushbutton
PD0: RX vom UART (verbunden ist ein serial-to-USB von Pololu)
PD1: TX zum UART
PD2: digitaler Output
PD3: digitaler Output
PD4: digitaler Output (chip-select für eins der SPI Slaves)
PB6, PB7: 16 Mhz Crystal
PD5: digitaler Output
PD6: digitaler Output
PD7: digitaler Output (chip-select für den zweiten SPI Slave)
PB0: digitaler Output
PB1: digitaler Input
PB2: als SPI-SS Output konfiguriert, aber nicht verbunden da ich mehrere
chip-selects brauche, s.o.)
PB3: SPI MOSI
PB4: SPI MISO
PB5: SPI clock
PC0: digitaler Output (LED)
PC1: digitaler Output (LED)
PC2: digitaler Output (LED)
PC3: digitaler input (pin-change interrupt an pushbutton)
PC4: digitaler input (pin-change interrupt an pushbutton)
PC5: soll ein digitaler Output werden
PD2, PD3, PB0, PB1 und letzlich PC5 werden an einen Bus angeschlossen,
die Signale kommen/gehen über den Bus.
VCC, AVCC und AREF sind extern zusammen geschlossen und über einen 100nF
Kondensator gepuffert.
Die beiden GND pins sind ebenfalls extern zusammen geschlossen.
SPI Slave eins ist eine Reihe von Shift-Registern, der zweite Slave ist
eine Schaltung zum Lesen einer SD Karte.
@Jens W: aktuell habe ich an PC5 lediglich ein Voltmeter, def. keinen
Kurzschluss :)
Zu deinem Hinweis mit der two-wire TWEN funktion: Ich hatte das TWEN bit
im TWCR Register zeitweilig explizit auf null gesetzt, aber das brachte
keine Änderung.
Dennoch, ich checcke das noch mal...
MrOnak schrieb:> Im Datenblatt finde ich folgenden Satz: "Note that PC6...4 use digital> supply voltage, VCC." Ich interpretiere das so dass lediglich PC[0-3]> den AVCC verwenden, .....
In der Tat du hast Recht ..... (ist wieder bei jedem AVR anders ....)
Hmm also das twp-wire Interface explizit deaktiviert hilft nicht:
TWCR &= ~(1 << TWEN);
DDRC |= (1 << PC5);
Ändert gar nichts.
Im übrigen scheint der MUC komplett zu hängen wenn PC5 ein Output ist.
Eine der Funktionen kann ich über einen Pushbutton triggern aber da
passiert ebenfalls nichts.
Am PC5 pin liegt aktuell wie gesagt keine Schaltung, da ist lediglich
mein Voltmeter angeschlossen. Einen Kurzschluss zwischen PC5 und
irgendwas anderem kann ich definitiv ausschließen.
... und als ADC Eingang verwendest du den Port auch nicht?
Hast du alle deine Initialisierungen im Griff oder verwendest
du irgendwelche Libs in die du noch nicht hineingeschaut hast?
Nein die Eingänge PC[3:4] verwende ich lediglich digital, über die
pin-change interrupts.
Bei den Initialisierungen bin ich durch...
Die SPI library ist von mir, die setzt nur die Pins am Port die
verwendet werden und nicht global PORTB = 0x00 oder sonstiges.
Die UART library ist die bekannte von Peter Fleury... da erwarte ich
eigentlich keine Überraschungen, aber habe in uart_init() trotzdem mal
nachgesehen, ohne etwas verdächtiges zu finden.
Nachtrag... alle anderen Pins setze ich manuell entsprechend.
Was mich so stutzig macht, ist dass die Schaltung komplett
funktioniert... das letzte Stück vom Puzzle ist der PC5 Output, der
ledlich dazu dient dem Bus mitzuteilen, dass die Schaltung Kontrolle
über den Bus erhalten möchte.
Wenn ich
DDRC |= (1 << PC5);
auskommentiere und im Code einfach davon ausgehe dass ich Kontrolle über
den Bus habe ohne das abzufragen dann funktioniert alles. Kommentiere
ich die obige Zeile wieder ein, hängt das Ding.
Mysterien am Montag... seufz
Versuche mal, den Pin als Eingang zu verwenden und gebe im laufenden
System ein paar High/Low Wechsel drauf.
Wenn der Controller dabei ausfällt, hast du vermutlich versehentlich
Interrupts aktiviert aber es gibt keinen passenden Interrupt-Handler.
Na dann würde ich doch mal versuchen auf dem nicht funktionierenden
Port/Pin ohne alle Libs eine LED zum Leuchten zu bringen.
Das würde doch Erleuchtung bringen ....
@Stefan Us: Gute Idee, aber war erfolglos.
Der pin-change interrupt an PC3 funktioniert weiterhin, auch wenn ich
PC5 mehrmals hi/lo toggle. Ebenso kann ich nach mehrfachem togglen
weiterin über UART zugreifen und erhalte die korrekten Antworten.
Ich vermute aber sowieso, dass PC5 über PCINT1_vect angefangen würde,
genau wie PC[3:4] und die ISR habe ich. Damit bliebe nur (?) das TWI
interrupt.
Ich habe zur Sicherheit noch das TWIE bit in TWCR deaktiviert:
TWCR &= ~(1 << TWEN);
TWCR &= ~(1 << TWIE);
DDRC |= (1 << PC5);
... aber das Ergebnis ist das Gleiche.
Was two-wire interface am 328p angeht bin ich relativ unbeleckt, fehlt
mir noch was um TWI komplett zu deaktivieren?
@Arduinoquäler: Tja ich dachte über das Stadium LEDs zu blinken wäre die
Schaltung hinaus, aber scheinbar nicht... Ich habe alle Libraries aus
dem makefile geworden und meine main() sieht jetzt so aus:
int main(void) {
DDRC |= (1 << PC5);
DDRC |= (1 << PC2);
PORTC |= (1 << PC5);
PORTC |= (1 << PC2);
while(1) {
_delay_ms(500);
PORTC &= ~(1 << PC5);
PORTC &= ~(1 << PC2);
_delay_ms(500);
PORTC |= (1 << PC5);
PORTC |= (1 << PC2);
}
return 0;
}
Da blinkt nix. PC2 ist wie gesagt ein bekannt funktionierender Ausgang.
Wenn ich alles was PC5 angeht auskommentiere, blikt PC2 wie erwartet.
Sch...ade. Ich werd dann wohl mal das Ding auseinander nehmen und alles
durchmessen :(
Dann ist wohl der Chip defekt. Anders kann ich mir das Verhalten nicht
mehr erklären.
> meine main() sieht jetzt so aus:
Da fehlt allerdings mindestens ein include für die <avr/io.h> und
<utils/delay.h> Die hast du aber drin, oder?
Die IO/delay libraries sind drin, sonst würde PC2 nicht blinken wenn PC5
kein output ist. Egal, ich messe das Ding jetzt mal komplett durch und
wenn ich daraus auch nicht schlau werde tausche ich den MUC, ich hoffe
ich habe noch einen rumliegen.
Wenigstens bin ich erleichtert dass es kein offensichtliches Problem
ist...
Ich melde mich noch mal :)
Gnarf.
Okay... scheinbar habe ich in all den Jahren seit ich meinen
Testplatinen-freundlichen 328p noch nie irgend etwas an PC5
angeschlossen. Der Pin war nämlich wunderbar mit einem der Beine vom
16Mhz Kristall kurzgeschlossen.
Kein Takt, kein Blink.
Ich muss jetzt mal im Handbuch von meinem Multimeter wühlen bis wo das
Ding Frequenzen messen kann, es hat mir nämlich wunderbar 0V und 0Hz
angezeigt als ich gestern getestet habe.
Meine Herren, ich danke für die Unterstützung!
Die Frequenz am Quarz kannst du mit dem Multimeter nicht messen. Dazu
ist das Signal viel zu klein.
Selbst mit dem Oszi ist das schon schwer, da die Kapazität des Tastkopfs
schon die Frequenz und den Pegel beeinflusst.
Stell den Controller mal auf den internen 8MHz Oszillator um. Dann
sollte das funktionieren.
Also für Testzwecke Betrieb ohne Quarz.
Gruß, Jens
Naja es passt ja jetzt. Die 0.01mm unbeabsichtigte Lötbrücke gefunden
und entfernt und alles läuft wie erwartet...
Im Übrigen, die TWI Deaktivierung ist nicht notwendig, der PC5
funktioniert auch ohne als Output. Vielleicht hilft das für die Zukunft
bei jemandem.
Jens W. schrieb:> Die Frequenz am Quarz kannst du mit dem Multimeter nicht messen. Dazu> ist das Signal viel zu klein.
Das Signal ist üblicherweise garnicht mal so klein, das kann nämlich
durchaus nahezu die volle Höhe der Versorgungsspannung erreichen. Daher
auch der Begriff "full swing oszillator" in vielen DBs von Atmel. Dieser
Begriff bezeichnet genau dies.
Wenn man also den Oszillator nicht bewußt auf's Energiesparen getrimmt
hat und in der Lage war, die wirklich passenden Bürdekapazitäten
auszuwählen und zu bestücken, dann ist das Signal üblicherweise nicht
klein.
Auf jeden Fall groß genug, um selbst mit einem Billichmultimeter der
30-Euro-Klasse direkt die Frequenz des Quarzes "messen" zu können,
jedenfalls, wenn man erst antastet, nachdem der Oszillator erstmal
angelaufen ist.
Das Multimeter zeigt dann zumindest plausible Werte im Rahmen seiner
Messgenauigkeit an. Natürlich ist die typisch wesentlich geringer als
die Genauigkeit des Quarzes, deswegen habe ich das "messen" hier mal in
Anführungszeichen gesetzt.
Probleme bei der Messung hat man nur bei falsch dimensionierten
Oszillatorschaltungen oder halt bei welchen, die bewusst auf's
Energiesparen getrimmt wurden und deshalb planmäßig nur deutlich
geringere Pegel erreichen. In beiden Fällen kann (und wird) natürlich
das Antasten mit der Messeinrichtung viel leichter dazu führen, dass die
Schwingung abreißt.
Übrigens, man kann das auch genau umgekehrt betrachten: Wenn der Plan
nicht war, den Oszillator besonders energiesparend zu machen und
Antasten mit Oszi oder Multimeter zum Schwingungsabriss führt, dann
stimmt was mit der Schaltung, dem Layout oder den Takt-Fuses nicht!
Da solltest du mal drüber nachdenken...