Hallo,
ich benutze ein AVR NET-IO mit eigener Firmware. Ich bin dabei eine
Motorregelung zu basteln. Diese Motorregelung bekommt Drehzahlsensoren
und regelt damit den angeschlossenen Elektromotor. Anfangs habe ich
meine Firmware mit ISP übertagen, jetzt mit JTAG. Verwendet wird der
Atmel-ICE Debugger:
http://www.reichelt.de/?ARTICLE=143878&PROVID=2788&wt_mc=amc141526782519998&&gclid=CNiMvZTnzcYCFSb3wgod-2sOmA
Momentan beschäftige ich mich damit, auf Pins ein Outputsignal zu geben,
in meinem Fall 5V oder 0V. Motor läuft/ Motor läuft nicht. Angeschlossen
habe ich dafür folgenden Drehzahlsteller:
http://www.reichelt.de/?ARTICLE=47585&PROVID=2788&wt_mc=amc141526782519998&&gclid=CPf1xJjkzcYCFUL4wgodZPwELA
Später soll auf einem bestimmten Pin natürlich ein PWM Signal sein um
den Motor zu steuern, aber ich fange erstmal damit an für eine bestimmte
Zeit 5V auf einen Pin zu geben.
Zusätzlich zu dem AVR NET-IO Board verwende ich noch eine
Anschlussplatine:
http://www.pollin.de/shop/dt/NDQ5OTgxOTk-/Bausaetze_Module/Bausaetze/Bausatz_SUB_D_Anschlussplatine.html
Auf der Anschlussplatine entsprechen die Pins Data0-Data7 dem PortC
meines ATMEGA32. Auf einem Dieser Pins würde ich gerne 5V geben umd die
Anschlussklemmen nutzen zu können. Deshalb habe ich einige Fragen zu den
IO Pins:
Zum JTAG debuggen sind die gelb markierten Pins schon belegt. Kann ich
die freien Pins von Port C jetzt nicht mehr als IO Pins benutzen? Oder
später als PWM Pins? Ich habe mit einem Voltmeter die Pins nach dem
Hochsetzen gemessen und keine Veränderung festgestellt.
Zum Testen habe ich auch mal alle Pins von Port B auf hoch gesetzt, da
werden allerdings nur bestimmte(PB1,PB2 und noch ein paar) auf 5V
gesetzt und manche bleiben 0V. Die Pins von PortC lassen sich gar nicht
verändern. Das ist mein Code:
1
if(a=='1'){//am Terminal wurde 1 eingegeben
2
DDRB=0xFF;//PortB als Output setzen
3
4
PORTB|=(1<<PB0);//PB0 im PORTB setzen
5
PORTB|=(1<<PB1);
6
PORTB|=(1<<PB2);
7
PORTB|=(1<<PB3);
8
PORTB|=(1<<PB4);
9
PORTB|=(1<<PB5);
10
PORTB|=(1<<PB6);
11
PORTB|=(1<<PB7);
12
13
// Analog für PortC:
14
// PORTC |= (1<< PC0);
15
// [...]
16
17
gotoGOTOMARKE1;//Springt wieder ins Hauptmenu und wartet auf Eingabe
18
}
19
20
if(a=='2'){//am Terminal wurde 2 eingegeben
21
DDRB=0x00;//PortB als Input setzen
22
23
PORTB&=~(1<<PB0);//PB0 im PORTB löschen
24
PORTB&=~(1<<PB1);
25
PORTB&=~(1<<PB2);
26
PORTB&=~(1<<PB3);
27
PORTB&=~(1<<PB4);
28
PORTB&=~(1<<PB5);
29
PORTB&=~(1<<PB6);
30
PORTB&=~(1<<PB7);
31
32
gotoGOTOMARKE1;//Springt wieder ins Hauptmenu und wartet auf Eingabe
33
34
}
35
36
if(a=='3'){//am Terminal wurde 3 eingegeben
37
//Einzelne Pins von DDRC als Output setzen:
38
DDRC=0b00000011;// PC0 und PC1 werden als Output gesetzt. Der Rest als Input
39
//PC0 und PC1 auf high setzen
40
PORTC|=(1<<PC0);
41
PORTC|=(1<<PC1);
42
43
gotoGOTOMARKE1;//Springt wieder ins Hauptmenu und wartet auf Eingabe
44
}
Ich hoffe es ist verständlich, was mein Problem ist und ihr könnt mir
helfen.
ich schrieb:> hi,> nein ist nicht dein (ganzer) code.> mfg> ich
Stimmt, ich benutze ein Codegerüst, in dem schon die serielle
Schnittstelle implementiert ist.
CRätselrater schrieb:> Goto sollte man aus dem C Standard verbannen.
Ich empfinde Goto auch als unsauber und werde es in meiner finalen
Programmsturktur nicht mehr verwenden. Vielen Dank für deine hilfreiche
Aussage
> Zum JTAG debuggen sind die gelb markierten Pins schon belegt.> Kann ich die freien Pins von Port C jetzt nicht mehr als IO Pins> benutzen? Oder später als PWM Pins?
Diese Pins kannst du per Fuse als I/O Port oder JTAG Anschluss
konfigurieren. Entweder oder, beide Betriebsarten zugleich sind niocht
möglich.
Stefan U. schrieb:>> Zum JTAG debuggen sind die gelb markierten Pins schon belegt.>> Kann ich die freien Pins von Port C jetzt nicht mehr als IO Pins>> benutzen? Oder später als PWM Pins?>>> Diese Pins kannst du per Fuse als I/O Port oder JTAG Anschluss> konfigurieren. Entweder oder, beide Betriebsarten zugleich sind niocht> möglich.
Vielen Dank, das hatte ich befürchtet.
Stefan U. schrieb:> Ich würde nie im Leben mit Goto in einen anderen Code-Block springen.> Mich wundert, dass der Compiler das nicht schon verweigert.
Warum sollte der Compiler syntaktisch korrekten Code verweigern? Muss
Code zwingend gut und semantisch sein um kompilierbar zu sein?
Ich hatte bereits ein schlechtes Gewissen bei dem Goto, durch die lieben
Antworten bekräftigt werde ich es beim nächsten Arbeiten an dem Code
entfernen.
Wenn PortC durch das Setzen der Fuse Bits nicht mehr als IO Port
verwendet werden kann, wieso können dann nicht alle Pins von PortB auf
high gesetzt werden? So weit ich weiß ist der PortB durch die gesetzten
Fuse Bits nicht betroffen.
Dirk D. schrieb:> Ich hatte bereits ein schlechtes Gewissen bei dem Goto, durch die lieben> Antworten bekräftigt werde ich es beim nächsten Arbeiten an dem Code> entfernen.
Wirf es gleich raus.
Vor allen Dingen, weil dein Code durch das goto so richtig mies geworden
ist.
Die generelle Struktur eines AVR Programms sieht so aus
D.h. wenn der Prozessor erst mal in der while Schleife (der sog.
Hauptschleife) angekommen ist, dann kommt er da nie wieder raus! Die
komplette Programmlogik spielt sich innerhalb dieser Hauptschleife ab
(bis auf die Teile, die per Interrupt erledigt werden)
in deinem Fall schiesst du dir selbst von hinten durch die Brust ins
Auge mit deinen GOto. Es gibt keinen Grund, sich aus der Hauptschleife
mit einem break raus zu katapultieren um dann das Programm wieder von
vorne (inklusive aller Initialisierungen) ausführen zu lassen.
Dirk D. schrieb:> Wenn PortC durch das Setzen der Fuse Bits nicht mehr als IO Port> verwendet werden kann,
Nur die JTAG-Anschlüsse sind verloren, die übrigen an Port C kannst Du
normal verwenden.
> Warum sollte der Compiler syntaktisch korrekten Code verweigern?
Na wenn es korrekt ist, dann soll der Compiler das natürlich mitmachen.
Ich habe Goto in C nur ein einziges mal verwendet.
Diese spezielle Verwendung hat mich sehr überrascht. Ich habe intuitiv
vermutet, dass das so nicht gehen kann.
Jetzt habe ich was zum dazu lernen - herausfinden, warum sowas möglich
ist.
Stefan U. schrieb:> Jetzt habe ich was zum dazu lernen - herausfinden, warum sowas möglich> ist.
Aus einem Block rauszuspringen ist nicht das grosse Problem.
Seine Struktur ist
1
intmain()
2
{
3
Label:
4
5
...
6
7
8
if(...){
9
...
10
gotoLabel;
11
}
12
}
syntaktisch kein Problem. Aber programmiertaktisch ein Desaster.