Hi zusammen!
Ich bastel im Moment mein erstes µC-Projekt.
Aus dem AVR-Tutorial habe ich diese Funktion zum entprellen kopiert:
inline uint8_t debounce(volatile uint8_t *port, uint8_t pin)
{
if ( ! (*port & (1 << pin)) )
{
/* Pin wurde auf Masse gezogen, 100ms warten */
_delay_ms(100);
if ( ! (*port & (1 << pin)) )
{
/* Anwender Zeit zum Loslassen des Tasters
geben */
_delay_ms(100);
return 1;
}
}
return 0;
}
in meiner Mainfunktion soll dann überprüft werden, ob ein gewisser
Schalter gedrückt wurde. Falls ja, dann wird countdownfrom runter bzw.
hochgezählt und auf einer 7-Segment-Anzeige ausgegeben.
int main(void)
{
init();
uint8_t countdownfrom = 2;
while (1) // Endlosschleife
{
//if (debounce(&PINC, PC0)) countdown2(14); /* Falls Taster an
PIN PC0 gedrueckt.. */
if (debounce(&PINC, PC1) && (countdownfrom>1))
{
countdownfrom--;
shownumber(countdownfrom);
}
if (debounce(&PINC, PC2) && (countdownfrom<19))
{
countdownfrom++;
shownumber(countdownfrom);
}
}
return 0;
}
Die Ports der Taster sind mittels 10k-Pullup auf 5V gezogen.
Hier noch die init()-Funktion:
void init(void)
{
DDRA = 0xff; // PortA als Ausgang deklarieren
PORTA = 0xff; // PortsA auf HIGH schalten
PORTA = 0b00000000; //0 ausgeben
DDRB = 0xff; // PortB als Ausgang deklarieren
PORTB = 0x00; // PortsB auf LOW schalten
DDRC = 0x00; // PortC als Eingang deklarieren
PORTC = 0b00000111 ; /* Pullup-Widerstand aktivieren */
}
Dummerweise habe ich dabei 2 Probleme. Bei der Simmulation (AVRStudio)
bekommt mein Rechner sich nicht mehr ein. 99% CPU-Last und nix tut sich
mehr ?!?!
2. Wenn ich das Programm auf den AVR (Atmega16) lade, dann fängt er
sofort an hochzuzählen??!?!?
Kann mir einer sgaen wodran das liegt?
So, ich habe inzwischen selbst was rausgefunden.
Obwohl der PORTC bei meinem atmega16 als Ausgang festgelegt wird,
liegen an PC2(TCK),PC3(TMS) und PC5(TDI) high Pegel an.
Kann es sein, das das JTAG-Interface eingeschaltet ist, oder ähnliches?
Falls ja, gibt es einen Weg die PORTs als I/O-Pins zu schalten?
geht das auch über nen C-Befehl? Ich spiele so ungerne mit den Fuse-Bits
rum. Habe gehört, da kan man schnell was kaputt machen ;)
Bin ja noch neu auf dem Gebiet.
einfach das JTAG Fuse Deaktiviern, kaputt gehn kann da nix solange du
nicht an anderen einstellungen rumspielst.
Ich hab IRGENWANN mal im Forum geshen das jemand meinte das Ginge auch
über eine Assemblerbefehl... aber frag mich nicht wie, den das Fuse
einmal umprogramieren ist kein Akt, du solt ja nciht rumspielen sondern
NUR das Jtag fuse verändern, da kann nxi bei passieren, nur finger weg
von den anderen Fuses wenn du nicht genau weißt wozu sie da sind.
Super, wenn ich mit PonyProg die Fuses auslese, dann sind angeblich alle
unprogrammiert. Unmöglicht!
Hat PonyProg da nen Bug oder so bzw. gibt es noch andere Programme um
die Fuses zu setzten?
Sorry, aber hat sich soeben erledigt. Bei Ponyprog hatte ich AVR-Auto
eingestellt damit geht es NICHT!
Einfach mal eben den Typ ausgewählt und schon werden die Fuses ohne
Probleme richtig gelesen.
Jetzt klappt es auch mit den PORTs! Alles liegt tatsächlich auf LOW!
SUPER VIELEN DANK!
Jetzt kann ich ja in Ruhe weiterbasteln ;)
Das geht auch ohne Änderung der Fuses:
in wl,mcucsr ;JTAG-
sbr wl,1<<jtd ;Interface
out mcucsr,wl ;deaktivieren
out mcucsr,wl ;(PortC aktivieren)
Diese Sequenz in der INIT-Routine (gleich nach dem Initialisieren des
Stackpointers) schaltet das JTAG-Interface aus. Im Datenblatt ist das
glaube sogar beschrieben.
...
danke!
Im Datenblatt habe ich das nicht gefunden und zudem kann ich mit
Assembler noch nix anfangen.
Da arbeite ich mich gerade erst ein. Scheint aber sehr viel effizienter
zu sein als das was gcc-avr erzeugt.
Wo wir gerade beim Thema sind:
Im Assembler-Tutorial ist der Link zu den Assemblerdirektiven defekt.
Ich mache die Links nicht, bitte beim Administrator melden.
Die ASM-Direktiven findest du aber auch in der Hilfe zum AVR-Studio und
im Instruction-set. Die Hilfe zum AVR-Studio ist neben den
AVR-Datenblättern eine recht brauchbare Informationsquelle.
ASM ist nicht unbedingt effizienter (Profis arbeiten nicht umsonst
unter C), es zwingt aber zum Lesen des Datenblattes und zum Verstehen
der Architektur. Und im Datenblatt gibt es die I/O-Registerliste und
die Erklärungen zu jedem Bit in jedem Register, also auch zu JTD in
MCUCSR. Sicher versteht man nicht alles auf einmal (auch ich nicht),
aber bei jedem Nachschlagen wird es (das was man versteht) etwas mehr.
Wenn man die Bedeutung jedes Bits in jedem I/O-Register in die
Checkliste aufnehmen wollte, dann würde das die Checkliste dermaßen
aufblähen, dass sie niemand mehr lesen würde.
...
Das sit kalr, aber das Problem mit dme Mega16 kommt ja immer wieder und
ein Hinweis auf die Möglcihkeit das per software abzuschalten wäre
sinnvoll denke ich :)
@abc,
Ganz einfach, die kosten doch Geld und Platz !
Und 10 Zeilen Software kosten überhaupt nix.
Wenn ich auch nur nen Widerstand durch ne Zeile Software einsparen
kann, dann nehme ich natürlich die Software, gar keine Frage.
Peter
