RN-Wissen.de - Benutzerbeiträge [de]

Diskussion:RN-Control Demoprogramm in C

2010-04-18T13:57:48Z

Manni2k: Rechtschreibfehler

== C99-Standard ==

Das Programm erzeugt beim kompilieren mit AVRStudio 4.13.528 Fehler bei den For-Schleifen. Das rührt daher, dass in rncontrol.h Variablen in C++-Manier in den for-Anweisung selbst deklariert werden.

Bsp.:
<pre>
void sound(uint8_t hoehe, uint16_t laenge)
{
for(uint16_t i=0; i<laenge*15; i=i+(2*hoehe))
{
setportdon(7);
_delay_ms(hoehe);
setportdoff(7);
_delay_ms(hoehe);
}
}
</pre>

Fehler:

"error: 'for' loop initial declaration used outside C99 mode"

Werde das jetzt an den relevanten Stellen so ändern :
<pre>
void sound(uint8_t hoehe, uint16_t laenge)
{
uint16_t i;
for(i=0; i<laenge*15; i=i+(2*hoehe))
{
setportdon(7);
_delay_ms(hoehe);
setportdoff(7);
_delay_ms(hoehe);
}
}
</pre>

Wäre schön, wenn es dann zur Sicherheit mal jemand testen könnte.

Habe zur Sicherheit bei allen Änderungen mal

'''"initial declaration error" fix'''

eingefügt.

'''EDIT von Manni2k: Ich habe in den Anmerkungen zum C-Demoprogramm mal den Hinweis eingebaut, dass man dem AVR-Compiler den C99-Standard mitteilen muss. Ich denke, dass dies besser ist, als das Programm auf den alten Standard hin umzubauen.'''

== Tastenabfrage ==

Zum letzten Abschnitt: Stimmt!

Mir ist aufgefallen, dass das Basic Beispieltestprogramm für die Tastenabfrage am Porta.7 den Pull-Up Widerstand verwendet, um bei nicht gedrückter Taste einen definierten Spannungspegel am AD Wandlereingang zu haben (+5V)

<pre>

...

Config Adc = Single , Prescaler = Auto 'Für Tastenabfrage und Spannungsmessung

Config Pina.7 = Input 'Für Tastenabfrage
Porta.7 = 1 'Pullup Widerstand ein

...

</pre>

Dies ist im C-Programm nicht so realisiert und der Pin hängt bei nicht gedrückter Taste in der Luft, was möglicher Weise zu dem im C-Programm beschriebenen Effekt führt

<pre>

.....

setportaon(7); //Ohne das hier "flackern" die Werte aus irgend einem Grund -> es werden
// mitunter Tasten erkannt, die gar nicht gedrückt wurden oder das
//Programm bleibt für einige Sekunden "hängen"
waitms(1);
setportaoff(7);
....

</pre>

Meine Lösung:

<pre>

.........

/*### Hauptschleife ###*/

int main(void)
{

/*###Initialisierungsphase###*/

//Pins bzw. Ports als Ein-/Ausgänge konfigurieren

//Initialisierungen

setportdoff(7); //Speaker aus

init_USART(); //USART konfigurieren

DDRA = 0x00; //00000000 -> alle Analogports als Eingänge

SFIOR &= ~(1<<PUD); // Pull-UP enable (nicht unbedingt nötig, aber zur Klarheit!)
PORTA |= (1<<PA7); // internen Pull-Up an PA7 aktivieren

......

</pre>

Dann muss die Buttonabfrage wegen des Pull-Up Widerstandes entsprechend angepasst werden, denn er liegt nun parallel zu dem 10k Widerstand + 1 bis 4 1k Widerständen (je nach gedrückter Taste). Dann stimmen die Ergebnisse der AD Wandlung auch mit dem des Basic-Programms überein und können direkt übernommen werden

<pre>

...

/*### Buttonabfrage ###*/

uint8_t button(void)
{
uint8_t taste = 0; //Variable für Nummer des Tasters
uint16_t analog7 = adcwert(7); //Wert des Ports

//-----------auskommentieren, sonst wird der int. Pull Up Widerstand wieder abgeschaltet!

// setportaon(7);
// waitms(1);
// setportaoff(7);

/ Die folgende Zeile ist nur zur Überprüfung aller gelesenen Werte und kann auskommentiert werden
utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);sendUSART("\r\n");

//Abfrage des gedrückten Tasters - um Störungen zu vermeiden wurden
//die Bereiche sehr eng gefasst, sollten bei Bedarf an jedes Board extra angepasst werden.
if((analog7>=400) && (analog7<=450)) {taste = 1;utoa(analog7, wort, 10),sendUSART("Wert=");sendUSART(wort);}
else if((analog7>=330) && (analog7<=380)) {taste = 2;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=260) && (analog7<=305)) {taste = 3;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=180) && (analog7<=230)) {taste = 4;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=90) && (analog7<=130)) {taste = 5;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else {}

return taste;
}

</pre>

Hier mal die bei mir gemessenen AD Werte: (in der letzten Tabellenspalte wurde der interne Pull Up Widerstand (PW) durch einen externen 22k Widerstand ersetzt!)

{| border= 1
|Taste
|ohne PW
|mit internem PW
|mit ext. PW (22k)
|-
|1
|341
|408
|432
|-
|2
|272
|340
|363
|-
|3
|204
|268
|286
|-
|4
|135
|190
|202
|-
|5
|67
|106
|106
|}

== Korrektur der Soundausgabe ==

Hallo,

ich bin zwar grad erst in die Mikrocontrollerwelt eingestiegen, habe aber gleich mal einen Verbesserungsvorschlag für das Demoprogramm:

Die Soundausgabe hat bei mir nicht wirklich funktioniert (RN-Control mit 16 MHz). Es lag einerseits daran, dass die waitms()-Funktion nicht die korrekte Anzahl an Millisekunden gewartet hat und andererseits hat auch die sound()-Funktion nur komische Töne erzeugt. Unter [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=30242 diesem Link] (Registrierung nötig) kann man sich eine alternative delay.h herunterladen (delay_x.h). Diese stellt Delays bis auf einen Taktzyklus genau dar und ist Compileroptimierungsunabhängig. Damit habe ich eine neue sound()-Funktion geschrieben, der als Argumente die Frequenz in Hertz und die Dauer in 1/10-Sekunden übergeben wird.

<pre>
void sound(uint16_t frequenz, uint16_t dauer)
{
uint32_t cycles;
uint16_t holdtime;
cycles=frequenz*dauer/2;
holdtime=1000000/frequenz;

for (uint16_t i = 0; i<(cycles/10); i++)
{
setportdon(7);
_delay_us(holdtime);
setportdoff(7);
_delay_us(holdtime);
}
}
</pre>

Natürlich vorher die delay_x.h ins \util-Verzeichnis packen und die include Anweisung entsprechend anpassen.

Das ganze lässt sich sicher noch optimieren. Probierts mal aus, bei mir hats hervorragend geklappt. Wenn das ganze bugfrei ist, dann würd ichs (wenn das genehm ist) im Hauptartikel entsprechend umschreiben.

'''EDIT von Manni2k: Hat bei mir leider auch nicht funktioniert. Du rufst "_delay_us" auch mit einer Nicht-Konstanten auf, was laut avr-libc doku zu fehlerhaften Delays führt.'''

== Korrektur der Soundausgabe 2 ==

Ich habe mich mal rangemacht, das Sound-Problem zu lösen und bin am Ende zu einer kurzen, schlanken und effizienten Lösung gekommen, die darin besteht, lediglich die Zeilen in der sound()-Funktion mit "_delay_ms(hoehe);" durch "_delay_loop_2(hoehe<<7);" zu ersetzen. Die Problematik bestand u.a. darin, dass laut avr-libc doku _delay_ms und _delay_us nur mit zur Compilerzeit konstanten Werten aufgerufen werden dürfen. Die ist bei den delay_basic-Funktionen _delay_loop_1 und _delay_loop_2 anders. Wie diese Funktionen genau funktionieren steht in der avr-libc doku ([http://www.nongnu.org/avr-libc/user-manual/group__util__delay__basic.html hier]). Die Multiplikation von hoehe mit der Konstanten 128 (hoehe<<7) wurde experimentell bestimmt und lässt sich durch (hoehe<<7) effizient berechnen.

Weiteres dazu unter folgendem Thread:
[http://www.roboternetz.de/phpBB2/viewtopic.php?t=53723 Thread: Sound-Probleme mit dem Demoprogramm in C + kurze Fragen]

== Optimierungen ==
Ich bin zwiar kein wirklicher C Spezi, aber da sind einige Teile nicht gut gelöst. Einen Teil könnte der Compiler eventuell automatisch optinmieren, GCC tuts aber noch nicht überall.

Bei der ADWandlerroutine solle man statt
wert = wert / 4; besser "wert >> 2" nutzen, ist nicht so übersichtlich, aber die Division wird so vermieden.

Viele der ganz kurzen Funktionen (z.B. Bit in Ports setzen) sollte man wenigstes als inline deklarieren.
Besser wäre es da mit #define zu arbeiten.

Diskussion:RN-Control Demoprogramm in C

2010-04-18T13:56:18Z

Manni2k: Abschnitte hinzugefügt / modifiziert (-> strukturierter jetzt)

== C99-Standard ==

Das Programm erzeugt beim kompilieren mit AVRStudio 4.13.528 Fehler bei den For-Schleifen. Das rührt daher, dass in rncontrol.h Variablen in C++-Manier in den for-Anweisung selbst deklariert werden.

Bsp.:
<pre>
void sound(uint8_t hoehe, uint16_t laenge)
{
for(uint16_t i=0; i<laenge*15; i=i+(2*hoehe))
{
setportdon(7);
_delay_ms(hoehe);
setportdoff(7);
_delay_ms(hoehe);
}
}
</pre>

Fehler:

"error: 'for' loop initial declaration used outside C99 mode"

Werde das jetzt an den relevanten Stellen so ändern :
<pre>
void sound(uint8_t hoehe, uint16_t laenge)
{
uint16_t i;
for(i=0; i<laenge*15; i=i+(2*hoehe))
{
setportdon(7);
_delay_ms(hoehe);
setportdoff(7);
_delay_ms(hoehe);
}
}
</pre>

Wäre schön, wenn es dann zur Sicherheit mal jemand testen könnte.

Habe zur Sicherheit bei allen Änderungen mal

'''"initial declaration error" fix'''

eingefügt.

'''EDIT von Manni2k: Ich habe in den Anmerkungen zum C-Demoprogramm mal den Hinweis eingebaut, dass man dem AVR-Compiler den C99-Standard mitteilen muss. Ich denke, dass dies besser ist, als das Programm auf den alten Standard hin umzubauen.'''

== Tastenabfrage ==

Zum letzten Abschnitt: Stimmt!

Mir ist aufgefallen, dass das Basic Beispieltestprogramm für die Tastenabfrage am Porta.7 den Pull-Up Widerstand verwendet, um bei nicht gedrückter Taste einen definierten Spannungspegel am AD Wandlereingang zu haben (+5V)

<pre>

...

Config Adc = Single , Prescaler = Auto 'Für Tastenabfrage und Spannungsmessung

Config Pina.7 = Input 'Für Tastenabfrage
Porta.7 = 1 'Pullup Widerstand ein

...

</pre>

Dies ist im C-Programm nicht so realisiert und der Pin hängt bei nicht gedrückter Taste in der Luft, was möglicher Weise zu dem im C-Programm beschriebenen Effekt führt

<pre>

.....

setportaon(7); //Ohne das hier "flackern" die Werte aus irgend einem Grund -> es werden
// mitunter Tasten erkannt, die gar nicht gedrückt wurden oder das
//Programm bleibt für einige Sekunden "hängen"
waitms(1);
setportaoff(7);
....

</pre>

Meine Lösung:

<pre>

.........

/*### Hauptschleife ###*/

int main(void)
{

/*###Initialisierungsphase###*/

//Pins bzw. Ports als Ein-/Ausgänge konfigurieren

//Initialisierungen

setportdoff(7); //Speaker aus

init_USART(); //USART konfigurieren

DDRA = 0x00; //00000000 -> alle Analogports als Eingänge

SFIOR &= ~(1<<PUD); // Pull-UP enable (nicht unbedingt nötig, aber zur Klarheit!)
PORTA |= (1<<PA7); // internen Pull-Up an PA7 aktivieren

......

</pre>

Dann muss die Buttonabfrage wegen des Pull-Up Widerstandes entsprechend angepasst werden, denn er liegt nun parallel zu dem 10k Widerstand + 1 bis 4 1k Widerständen (je nach gedrückter Taste). Dann stimmen die Ergebnisse der AD Wandlung auch mit dem des Basic-Programms überein und können direkt übernommen werden

<pre>

...

/*### Buttonabfrage ###*/

uint8_t button(void)
{
uint8_t taste = 0; //Variable für Nummer des Tasters
uint16_t analog7 = adcwert(7); //Wert des Ports

//-----------auskommentieren, sonst wird der int. Pull Up Widerstand wieder abgeschaltet!

// setportaon(7);
// waitms(1);
// setportaoff(7);

/ Die folgende Zeile ist nur zur Überprüfung aller gelesenen Werte und kann auskommentiert werden
utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);sendUSART("\r\n");

//Abfrage des gedrückten Tasters - um Störungen zu vermeiden wurden
//die Bereiche sehr eng gefasst, sollten bei Bedarf an jedes Board extra angepasst werden.
if((analog7>=400) && (analog7<=450)) {taste = 1;utoa(analog7, wort, 10),sendUSART("Wert=");sendUSART(wort);}
else if((analog7>=330) && (analog7<=380)) {taste = 2;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=260) && (analog7<=305)) {taste = 3;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=180) && (analog7<=230)) {taste = 4;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=90) && (analog7<=130)) {taste = 5;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else {}

return taste;
}

</pre>

Hier mal die bei mir gemessenen AD Werte: (in der letzten Tabellenspalte wurde der interne Pull Up Widerstand (PW) durch einen externen 22k Widerstand ersetzt!)

{| border= 1
|Taste
|ohne PW
|mit internem PW
|mit ext. PW (22k)
|-
|1
|341
|408
|432
|-
|2
|272
|340
|363
|-
|3
|204
|268
|286
|-
|4
|135
|190
|202
|-
|5
|67
|106
|106
|}

== Korrektur der Soundausgabe ==

Hallo,

ich bin zwar grad erst in die Mikrocontrollerwelt eingestiegen, habe aber gleich mal einen Verbesserungsvorschlag für das Demoprogramm:

Die Soundausgabe hat bei mir nicht wirklich funktioniert (RN-Control mit 16 MHz). Es lag einerseits daran, dass die waitms()-Funktion nicht die korrekte Anzahl an Millisekunden gewartet hat und andererseits hat auch die sound()-Funktion nur komische Töne erzeugt. Unter [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=30242 diesem Link] (Registrierung nötig) kann man sich eine alternative delay.h herunterladen (delay_x.h). Diese stellt Delays bis auf einen Taktzyklus genau dar und ist Compileroptimierungsunabhängig. Damit habe ich eine neue sound()-Funktion geschrieben, der als Argumente die Frequenz in Hertz und die Dauer in 1/10-Sekunden übergeben wird.

<pre>
void sound(uint16_t frequenz, uint16_t dauer)
{
uint32_t cycles;
uint16_t holdtime;
cycles=frequenz*dauer/2;
holdtime=1000000/frequenz;

for (uint16_t i = 0; i<(cycles/10); i++)
{
setportdon(7);
_delay_us(holdtime);
setportdoff(7);
_delay_us(holdtime);
}
}
</pre>

Natürlich vorher die delay_x.h ins \util-Verzeichnis packen und die include Anweisung entsprechend anpassen.

Das ganze lässt sich sicher noch optimieren. Probierts mal aus, bei mir hats hervorragend geklappt. Wenn das ganze bugfrei ist, dann würd ichs (wenn das genehm ist) im Hauptartikel entsprechend umschreiben.

'''EDIT von Manni2k: Hat bei mit leider auch nicht funktioniert. Du rufst "_delay_us" auch mit einer Nicht-Konstanten auf, was laut avr-libc doku zu fehlerhaften Delays führt.'''

== Korrektur der Soundausgabe 2 ==

Ich habe mich mal rangemacht, das Sound-Problem zu lösen und bin am Ende zu einer kurzen, schlanken und effizienten Lösung gekommen, die darin besteht, lediglich die Zeilen in der sound()-Funktion mit "_delay_ms(hoehe);" durch "_delay_loop_2(hoehe<<7);" zu ersetzen. Die Problematik bestand u.a. darin, dass laut avr-libc doku _delay_ms und _delay_us nur mit zur Compilerzeit konstanten Werten aufgerufen werden dürfen. Die ist bei den delay_basic-Funktionen _delay_loop_1 und _delay_loop_2 ander. Wie diese Funktionen genau funktionieren steht in der avr-libc doku ([http://www.nongnu.org/avr-libc/user-manual/group__util__delay__basic.html hier]). Die Multiplikation von hoehe mit der Konstanten 128 (hoehe<<7) wurde experimentell bestimmt und lässt sich durch (hoehe<<7) effizient berechnen.

Weiteres dazu unter folgendem Thread:
[http://www.roboternetz.de/phpBB2/viewtopic.php?t=53723 Thread: Sound-Probleme mit dem Demoprogramm in C + kurze Fragen]

== Optimierungen ==
Ich bin zwiar kein wirklicher C Spezi, aber da sind einige Teile nicht gut gelöst. Einen Teil könnte der Compiler eventuell automatisch optinmieren, GCC tuts aber noch nicht überall.

Bei der ADWandlerroutine solle man statt
wert = wert / 4; besser "wert >> 2" nutzen, ist nicht so übersichtlich, aber die Division wird so vermieden.

Viele der ganz kurzen Funktionen (z.B. Bit in Ports setzen) sollte man wenigstes als inline deklarieren.
Besser wäre es da mit #define zu arbeiten.

Diskussion:RN-Control Demoprogramm in C

2010-04-18T13:54:04Z

Manni2k: Korrektur der Soundausgabe 2

Das Programm erzeugt beim kompilieren mit AVRStudio 4.13.528 Fehler bei den For-Schleifen. Das rührt daher, dass in rncontrol.h Variablen in C++-Manier in den for-Anweisung selbst deklariert werden.

Bsp.:
<pre>
void sound(uint8_t hoehe, uint16_t laenge)
{
for(uint16_t i=0; i<laenge*15; i=i+(2*hoehe))
{
setportdon(7);
_delay_ms(hoehe);
setportdoff(7);
_delay_ms(hoehe);
}
}
</pre>

Fehler:

"error: 'for' loop initial declaration used outside C99 mode"

Werde das jetzt an den relevanten Stellen so ändern :
<pre>
void sound(uint8_t hoehe, uint16_t laenge)
{
uint16_t i;
for(i=0; i<laenge*15; i=i+(2*hoehe))
{
setportdon(7);
_delay_ms(hoehe);
setportdoff(7);
_delay_ms(hoehe);
}
}
</pre>

Wäre schön, wenn es dann zur Sicherheit mal jemand testen könnte.

Habe zur Sicherheit bei allen Änderungen mal

'''"initial declaration error" fix'''

eingefügt.

'''EDIT von Manni2k: Ich habe in den Anmerkungen zum C-Demoprogramm mal den Hinweis eingebaut, dass man dem AVR-Compiler den C99-Standard mitteilen muss. Ich denke, dass dies besser ist, als das Programm auf den alten Standard hin umzubauen.'''

== Neuer Abschnitt ==

Zum letzten Abschnitt: Stimmt!

Mir ist aufgefallen, dass das Basic Beispieltestprogramm für die Tastenabfrage am Porta.7 den Pull-Up Widerstand verwendet, um bei nicht gedrückter Taste einen definierten Spannungspegel am AD Wandlereingang zu haben (+5V)

<pre>

...

Config Adc = Single , Prescaler = Auto 'Für Tastenabfrage und Spannungsmessung

Config Pina.7 = Input 'Für Tastenabfrage
Porta.7 = 1 'Pullup Widerstand ein

...

</pre>

Dies ist im C-Programm nicht so realisiert und der Pin hängt bei nicht gedrückter Taste in der Luft, was möglicher Weise zu dem im C-Programm beschriebenen Effekt führt

<pre>

.....

setportaon(7); //Ohne das hier "flackern" die Werte aus irgend einem Grund -> es werden
// mitunter Tasten erkannt, die gar nicht gedrückt wurden oder das
//Programm bleibt für einige Sekunden "hängen"
waitms(1);
setportaoff(7);
....

</pre>

Meine Lösung:

<pre>

.........

/*### Hauptschleife ###*/

int main(void)
{

/*###Initialisierungsphase###*/

//Pins bzw. Ports als Ein-/Ausgänge konfigurieren

//Initialisierungen

setportdoff(7); //Speaker aus

init_USART(); //USART konfigurieren

DDRA = 0x00; //00000000 -> alle Analogports als Eingänge

SFIOR &= ~(1<<PUD); // Pull-UP enable (nicht unbedingt nötig, aber zur Klarheit!)
PORTA |= (1<<PA7); // internen Pull-Up an PA7 aktivieren

......

</pre>

Dann muss die Buttonabfrage wegen des Pull-Up Widerstandes entsprechend angepasst werden, denn er liegt nun parallel zu dem 10k Widerstand + 1 bis 4 1k Widerständen (je nach gedrückter Taste). Dann stimmen die Ergebnisse der AD Wandlung auch mit dem des Basic-Programms überein und können direkt übernommen werden

<pre>

...

/*### Buttonabfrage ###*/

uint8_t button(void)
{
uint8_t taste = 0; //Variable für Nummer des Tasters
uint16_t analog7 = adcwert(7); //Wert des Ports

//-----------auskommentieren, sonst wird der int. Pull Up Widerstand wieder abgeschaltet!

// setportaon(7);
// waitms(1);
// setportaoff(7);

/ Die folgende Zeile ist nur zur Überprüfung aller gelesenen Werte und kann auskommentiert werden
utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);sendUSART("\r\n");

//Abfrage des gedrückten Tasters - um Störungen zu vermeiden wurden
//die Bereiche sehr eng gefasst, sollten bei Bedarf an jedes Board extra angepasst werden.
if((analog7>=400) && (analog7<=450)) {taste = 1;utoa(analog7, wort, 10),sendUSART("Wert=");sendUSART(wort);}
else if((analog7>=330) && (analog7<=380)) {taste = 2;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=260) && (analog7<=305)) {taste = 3;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=180) && (analog7<=230)) {taste = 4;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=90) && (analog7<=130)) {taste = 5;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else {}

return taste;
}

</pre>

Hier mal die bei mir gemessenen AD Werte: (in der letzten Tabellenspalte wurde der interne Pull Up Widerstand (PW) durch einen externen 22k Widerstand ersetzt!)

{| border= 1
|Taste
|ohne PW
|mit internem PW
|mit ext. PW (22k)
|-
|1
|341
|408
|432
|-
|2
|272
|340
|363
|-
|3
|204
|268
|286
|-
|4
|135
|190
|202
|-
|5
|67
|106
|106
|}

== Korrektur der Soundausgabe ==

Hallo,

ich bin zwar grad erst in die Mikrocontrollerwelt eingestiegen, habe aber gleich mal einen Verbesserungsvorschlag für das Demoprogramm:

Die Soundausgabe hat bei mir nicht wirklich funktioniert (RN-Control mit 16 MHz). Es lag einerseits daran, dass die waitms()-Funktion nicht die korrekte Anzahl an Millisekunden gewartet hat und andererseits hat auch die sound()-Funktion nur komische Töne erzeugt. Unter [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=30242 diesem Link] (Registrierung nötig) kann man sich eine alternative delay.h herunterladen (delay_x.h). Diese stellt Delays bis auf einen Taktzyklus genau dar und ist Compileroptimierungsunabhängig. Damit habe ich eine neue sound()-Funktion geschrieben, der als Argumente die Frequenz in Hertz und die Dauer in 1/10-Sekunden übergeben wird.

<pre>
void sound(uint16_t frequenz, uint16_t dauer)
{
uint32_t cycles;
uint16_t holdtime;
cycles=frequenz*dauer/2;
holdtime=1000000/frequenz;

for (uint16_t i = 0; i<(cycles/10); i++)
{
setportdon(7);
_delay_us(holdtime);
setportdoff(7);
_delay_us(holdtime);
}
}
</pre>

Natürlich vorher die delay_x.h ins \util-Verzeichnis packen und die include Anweisung entsprechend anpassen.

Das ganze lässt sich sicher noch optimieren. Probierts mal aus, bei mir hats hervorragend geklappt. Wenn das ganze bugfrei ist, dann würd ichs (wenn das genehm ist) im Hauptartikel entsprechend umschreiben.

'''EDIT von Manni2k: Hat bei mit leider auch nicht funktioniert. Du rufst "_delay_us" auch mit einer Nicht-Konstanten auf, was laut avr-libc doku zu fehlerhaften Delays führt.'''

== Korrektur der Soundausgabe 2 ==

Ich habe mich mal rangemacht, das Sound-Problem zu lösen und bin am Ende zu einer kurzen, schlanken und effizienten Lösung gekommen, die darin besteht, lediglich die Zeilen in der sound()-Funktion mit "_delay_ms(hoehe);" durch "_delay_loop_2(hoehe<<7);" zu ersetzen. Die Problematik bestand u.a. darin, dass laut avr-libc doku _delay_ms und _delay_us nur mit zur Compilerzeit konstanten Werten aufgerufen werden dürfen. Die ist bei den delay_basic-Funktionen _delay_loop_1 und _delay_loop_2 ander. Wie diese Funktionen genau funktionieren steht in der avr-libc doku ([http://www.nongnu.org/avr-libc/user-manual/group__util__delay__basic.html hier]). Die Multiplikation von hoehe mit der Konstanten 128 (hoehe<<7) wurde experimentell bestimmt und lässt sich durch (hoehe<<7) effizient berechnen.

Weiteres dazu unter folgendem Thread:
[http://www.roboternetz.de/phpBB2/viewtopic.php?t=53723 Thread: Sound-Probleme mit dem Demoprogramm in C + kurze Fragen]

== Optimierungen ==
Ich bin zwiar kein wirklicher C Spezi, aber da sind einige Teile nicht gut gelöst. Einen Teil könnte der Compiler eventuell automatisch optinmieren, GCC tuts aber noch nicht überall.

Bei der ADWandlerroutine solle man statt
wert = wert / 4; besser "wert >> 2" nutzen, ist nicht so übersichtlich, aber die Division wird so vermieden.

Viele der ganz kurzen Funktionen (z.B. Bit in Ports setzen) sollte man wenigstes als inline deklarieren.
Besser wäre es da mit #define zu arbeiten.

Diskussion:RN-Control Demoprogramm in C

2010-04-18T13:52:56Z

Manni2k:

Das Programm erzeugt beim kompilieren mit AVRStudio 4.13.528 Fehler bei den For-Schleifen. Das rührt daher, dass in rncontrol.h Variablen in C++-Manier in den for-Anweisung selbst deklariert werden.

Bsp.:
<pre>
void sound(uint8_t hoehe, uint16_t laenge)
{
for(uint16_t i=0; i<laenge*15; i=i+(2*hoehe))
{
setportdon(7);
_delay_ms(hoehe);
setportdoff(7);
_delay_ms(hoehe);
}
}
</pre>

Fehler:

"error: 'for' loop initial declaration used outside C99 mode"

Werde das jetzt an den relevanten Stellen so ändern :
<pre>
void sound(uint8_t hoehe, uint16_t laenge)
{
uint16_t i;
for(i=0; i<laenge*15; i=i+(2*hoehe))
{
setportdon(7);
_delay_ms(hoehe);
setportdoff(7);
_delay_ms(hoehe);
}
}
</pre>

Wäre schön, wenn es dann zur Sicherheit mal jemand testen könnte.

Habe zur Sicherheit bei allen Änderungen mal

'''"initial declaration error" fix'''

eingefügt.

EDIT von Manni2k: Ich habe in den Anmerkungen zum C-Demoprogramm mal den Hinweis eingebaut, dass man dem AVR-Compiler den C99-Standard mitteilen muss. Ich denke, dass dies besser ist, als das Programm auf den alten Standard hin umzubauen.

== Neuer Abschnitt ==

Zum letzten Abschnitt: Stimmt!

Mir ist aufgefallen, dass das Basic Beispieltestprogramm für die Tastenabfrage am Porta.7 den Pull-Up Widerstand verwendet, um bei nicht gedrückter Taste einen definierten Spannungspegel am AD Wandlereingang zu haben (+5V)

<pre>

...

Config Adc = Single , Prescaler = Auto 'Für Tastenabfrage und Spannungsmessung

Config Pina.7 = Input 'Für Tastenabfrage
Porta.7 = 1 'Pullup Widerstand ein

...

</pre>

Dies ist im C-Programm nicht so realisiert und der Pin hängt bei nicht gedrückter Taste in der Luft, was möglicher Weise zu dem im C-Programm beschriebenen Effekt führt

<pre>

.....

setportaon(7); //Ohne das hier "flackern" die Werte aus irgend einem Grund -> es werden
// mitunter Tasten erkannt, die gar nicht gedrückt wurden oder das
//Programm bleibt für einige Sekunden "hängen"
waitms(1);
setportaoff(7);
....

</pre>

Meine Lösung:

<pre>

.........

/*### Hauptschleife ###*/

int main(void)
{

/*###Initialisierungsphase###*/

//Pins bzw. Ports als Ein-/Ausgänge konfigurieren

//Initialisierungen

setportdoff(7); //Speaker aus

init_USART(); //USART konfigurieren

DDRA = 0x00; //00000000 -> alle Analogports als Eingänge

SFIOR &= ~(1<<PUD); // Pull-UP enable (nicht unbedingt nötig, aber zur Klarheit!)
PORTA |= (1<<PA7); // internen Pull-Up an PA7 aktivieren

......

</pre>

Dann muss die Buttonabfrage wegen des Pull-Up Widerstandes entsprechend angepasst werden, denn er liegt nun parallel zu dem 10k Widerstand + 1 bis 4 1k Widerständen (je nach gedrückter Taste). Dann stimmen die Ergebnisse der AD Wandlung auch mit dem des Basic-Programms überein und können direkt übernommen werden

<pre>

...

/*### Buttonabfrage ###*/

uint8_t button(void)
{
uint8_t taste = 0; //Variable für Nummer des Tasters
uint16_t analog7 = adcwert(7); //Wert des Ports

//-----------auskommentieren, sonst wird der int. Pull Up Widerstand wieder abgeschaltet!

// setportaon(7);
// waitms(1);
// setportaoff(7);

/ Die folgende Zeile ist nur zur Überprüfung aller gelesenen Werte und kann auskommentiert werden
utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);sendUSART("\r\n");

//Abfrage des gedrückten Tasters - um Störungen zu vermeiden wurden
//die Bereiche sehr eng gefasst, sollten bei Bedarf an jedes Board extra angepasst werden.
if((analog7>=400) && (analog7<=450)) {taste = 1;utoa(analog7, wort, 10),sendUSART("Wert=");sendUSART(wort);}
else if((analog7>=330) && (analog7<=380)) {taste = 2;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=260) && (analog7<=305)) {taste = 3;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=180) && (analog7<=230)) {taste = 4;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=90) && (analog7<=130)) {taste = 5;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else {}

return taste;
}

</pre>

Hier mal die bei mir gemessenen AD Werte: (in der letzten Tabellenspalte wurde der interne Pull Up Widerstand (PW) durch einen externen 22k Widerstand ersetzt!)

{| border= 1
|Taste
|ohne PW
|mit internem PW
|mit ext. PW (22k)
|-
|1
|341
|408
|432
|-
|2
|272
|340
|363
|-
|3
|204
|268
|286
|-
|4
|135
|190
|202
|-
|5
|67
|106
|106
|}

== Korrektur der Soundausgabe ==

Hallo,

ich bin zwar grad erst in die Mikrocontrollerwelt eingestiegen, habe aber gleich mal einen Verbesserungsvorschlag für das Demoprogramm:

Die Soundausgabe hat bei mir nicht wirklich funktioniert (RN-Control mit 16 MHz). Es lag einerseits daran, dass die waitms()-Funktion nicht die korrekte Anzahl an Millisekunden gewartet hat und andererseits hat auch die sound()-Funktion nur komische Töne erzeugt. Unter [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=30242 diesem Link] (Registrierung nötig) kann man sich eine alternative delay.h herunterladen (delay_x.h). Diese stellt Delays bis auf einen Taktzyklus genau dar und ist Compileroptimierungsunabhängig. Damit habe ich eine neue sound()-Funktion geschrieben, der als Argumente die Frequenz in Hertz und die Dauer in 1/10-Sekunden übergeben wird.

<pre>
void sound(uint16_t frequenz, uint16_t dauer)
{
uint32_t cycles;
uint16_t holdtime;
cycles=frequenz*dauer/2;
holdtime=1000000/frequenz;

for (uint16_t i = 0; i<(cycles/10); i++)
{
setportdon(7);
_delay_us(holdtime);
setportdoff(7);
_delay_us(holdtime);
}
}
</pre>

Natürlich vorher die delay_x.h ins \util-Verzeichnis packen und die include Anweisung entsprechend anpassen.

Das ganze lässt sich sicher noch optimieren. Probierts mal aus, bei mir hats hervorragend geklappt. Wenn das ganze bugfrei ist, dann würd ichs (wenn das genehm ist) im Hauptartikel entsprechend umschreiben.

EDIT von Manni2k: Hat bei mit leider auch nicht funktioniert. Du rufst "_delay_us" auch mit einer Nicht-Konstanten auf, was laut avr-libc doku zu fehlerhaften Delays führt.

== Korrektur der Soundausgabe 2 ==

Ich habe mich mal rangemacht, das Sound-Problem zu lösen und bin am Ende zu einer kurzen, schlanken und effizienten Lösung gekommen, die darin besteht, lediglich die Zeilen in der sound()-Funktion mit "_delay_ms(hoehe);" durch "_delay_loop_2(hoehe<<7);" zu ersetzen. Die Problematik bestand u.a. darin, dass laut avr-libc doku _delay_ms und _delay_us nur mit zur Compilerzeit konstanten Werten aufgerufen werden dürfen. Die ist bei den delay_basic-Funktionen _delay_loop_1 und _delay_loop_2 ander. Wie diese Funktionen genau funktionieren steht in der avr-libc doku ([http://www.nongnu.org/avr-libc/user-manual/group__util__delay__basic.html hier]). Die Multiplikation von hoehe mit der Konstanten 128 (hoehe<<7) wurde experimentell bestimmt und lässt sich durch (hoehe<<7) effizient berechnen.

[http://www.roboternetz.de/phpBB2/viewtopic.php?t=53723 Thread: Sound-Probleme mit dem Demoprogramm in C + kurze Fragen]

== Optimierungen ==
Ich bin zwiar kein wirklicher C Spezi, aber da sind einige Teile nicht gut gelöst. Einen Teil könnte der Compiler eventuell automatisch optinmieren, GCC tuts aber noch nicht überall.

Bei der ADWandlerroutine solle man statt
wert = wert / 4; besser "wert >> 2" nutzen, ist nicht so übersichtlich, aber die Division wird so vermieden.

Viele der ganz kurzen Funktionen (z.B. Bit in Ports setzen) sollte man wenigstes als inline deklarieren.
Besser wäre es da mit #define zu arbeiten.

RN-Control Demoprogramm in C

2010-04-18T13:43:20Z

Manni2k: Verbesserung von kleinen Fehlern und Anmerkungen

[[Bild:rncontrol1.4diagramm.jpg|thumb|Funktionen des Boards]]Beim Controllerboard RN-Control wir ein Demo-Programm mitgeliefert, welches demonstriert, wie man Tasten abfragt, Spannungen misst, Sound ausgibt oder Ports abfragt. Also elementare Dinge, damit man einen schnellen Einstieg findet. Bislang gab's dieses Demo nur für [[Bascom]] Basic, weil diese Sprache sehr leicht erlernbar ist.

Für User, die in C einsteigen möchten, hat jetzt RN-User Corone das gleiche Programm auch für C umgesetzt und hier bereitgestellt. Einige zusätzliche Grundfunktionen in der Header-Datei erleichtern die Umsetzung.

== Die C Header-Datei ==
<pre>
/*
###################################################
rncontrol.h

Diese Header-Datei stellt grundlegende Funktionen für das RN-Control 1.4 in C zur Verfügung.

Autor: Georg Richter
#######################################################
*/

#include <util/delay.h>

/*### waitms - Programm pausieren lassen ###*/

/*Die Funktion lässt circa so viele Millisekunden verstreichen, wie angegeben werden.
Angepasst auf das RN-Control 1.4 mit 16 MHz-Quarz!
Vorsicht, Wert ist nur experimentell angenähert, nicht exakt berechnet!*/

void waitms(uint16_t ms)
{
for(; ms>0; ms--)
{
uint16_t __c = 4000;
__asm__ volatile (
"1: sbiw %0,1" "\n\t"
"brne 1b"
: "=w" (__c)
: "0" (__c)
);
}
}

/*### Ports setzen ###*/

//Ports auf HIGH setzen
static inline void setportaon(const uint8_t n)
{PORTA |= (1<<n);} //set PORTA.n high

static inline void setportbon(const uint8_t n)
{PORTB |= (1<<n);} //set PORTB.n high

static inline void setportcon(const uint8_t n)
{PORTC |= (1<<n);} //set PORTC.n high

static inline void setportdon(const uint8_t n)
{PORTD |= (1<<n);} //set PORTD.n high

//Ports auf LOW setzen
static inline void setportaoff(const uint8_t n)
{PORTA &= ~(1<<n);} //set PORTA.n low

static inline void setportboff(const uint8_t n)
{PORTB &= ~(1<<n);} //set PORTB.n low

static inline void setportcoff(const uint8_t n)
{PORTC &= ~(1<<n);} //set PORTC.n low

static inline void setportdoff(const uint8_t n)
{PORTD &= ~(1<<n);} //set PORTD.n low

/*### Senden per USART - RS232-Kommunikation ###*/

/*Zum senden von Zeichen im Hauptprogramm entweder

char irgendwas[] = "meintext";
sendUSART(irgendwas);

oder direkt

sendUSART("meinText");

verwenden.*/

void init_USART(void)
{
UCSRB |= (1<<TXEN); //UART TX (Transmit - senden) einschalten
UCSRC |= (1<<URSEL)|(3<<UCSZ0); //Modus Asynchron 8N1 (8 Datenbits, No Parity, 1 Stopbit)
UBRRH = 0; //Highbyte ist 0
UBRRL = 103; //Lowbyte ist 103 (dezimal) -> (Frequenz_in_Hz / (Baudrate * 16)) - 1 <- Quarfrequenz = 16*1000*1000 Hz!!!!
}

void sendchar(unsigned char c)
{
while(!(UCSRA & (1<<UDRE))) //Warten, bis Senden möglich ist
{
}

UDR = c; //schreibt das Zeichen aus 'c' auf die Schnittstelle
}

void sendUSART(char *s) //*s funktiniert wie eine Art Array - auch bei einem String werden die Zeichen (char) einzeln ausgelesen - und hier dann auf die Sendeschnittstelle übertragen
{
while(*s)
{
sendchar(*s);
s++;
}
}

/*### ADC-Ansteuerung ###*/

uint16_t adcwert(uint8_t kanal)
{
uint16_t wert = 0; //Variable für Ergebnis deklarieren

ADCSRA = (1<<ADEN)|(1<<ADPS2)|(1<<ADPS1)|(1<<ADPS0); //ADEN aktiviert überhaupt erst den internen ADC-Wandler, ADPS2 bis ADPS0 stellen den verwendeten Prescaler ein, denn die Wandlerfrequenz muss immer zwischen 50 und 200 kHz liegen! Der Prescaler muss bei 16MHz also zwischen 80 und 320 eingestellt werden, als einzige Möglichkeit bleibt hier 128 (=alle auf 1).

ADMUX = kanal;
//ADMUX = (1<<REFS1)|(1<<REFS0); //Einstellen der Referenzspannung auf "extern", also REFS1 und REFS0 auf "0" - daher auskommentierte Zeile

ADCSRA |= (1<<ADSC); //nach Aktivierung des ADC wird ein "Dummy-Readout" empfohlen, man liest also einen Wert und verwirft diesen, um den ADC "warmlaufen zu lassen"
while(ADCSRA & (1<<ADSC)) {} //auf Abschluss der Konvertierung warten
wert = ADCW; //ADCW muss einmal gelesen werden, sonst wird Ergebnis der nächsten Wandlung nicht übernommen.

/* Eigentliche Messung - Mittelwert aus 4 aufeinanderfolgenden Wandlungen */
wert = 0;
for(uint8_t i=0; i<4; i++)
{
ADCSRA |= (1<<ADSC); //eine Wandlung "single conversion" starten
while(ADCSRA & (1<<ADSC)) {} //auf Abschluss der Konvertierung warten
wert = wert + ADCW; //Wandlungsergebnisse aufaddieren
}

ADCSRA &= ~(1<<ADEN); //ADC deaktivieren

wert = wert/4; //Durchschnittswert bilden

return wert;
}

/*### Buttonabfrage ###*/

uint8_t button(void)
{
uint8_t taste = 0; //Variable für Nummer des Tasters
uint16_t analog7 = adcwert(7); //Wert des Ports

setportaon(7); //Ohne das hier "flackern" die Werte aus irgend einem Grund -> es werden mitunter Tasten erkannt, die gar nicht gedrückt wurden oder das Programm bleibt für einige Sekunden "hängen"
waitms(1);
setportaoff(7);

//Abfrage des gedrückten Tasters - um Störungen zu vermeiden wurden
//die Bereiche sehr eng gefasst, sollten bei Bedarf an jedes Board extra angepasst werden.
if((analog7>=337) && (analog7<=343)) {taste = 1;}
else if((analog7>=268) && (analog7<=274)) {taste = 2;}
else if((analog7>=200) && (analog7<=206)) {taste = 3;}
else if((analog7>=132) && (analog7<=138)) {taste = 4;}
else if((analog7>=64) && (analog7<=70)) {taste = 5;}
else {}

return taste;
}

/*### Sound durch den Speaker ausgeben ###*/

/*i wird immer um das doppelte der Tonhöhe hochgezählt. Grund: Um so tiefer
der Ton, desto größer ist "hoehe" -> desto länger sind die Pausenzeiten pro
"Tonschwingung". Dadurch würden tiefe Töne immer länger werden, was durch
diese Funktion abgefangen wird. Alle Töne mit der Länge x werden auch
ca x ms lang gespielt. Vernachlässigt wird hierbei jedoch die benötigte Zeit
zum Umschalten der Pins und Hochzählen der Schleife, um so höher der Ton,
desto länger wird er also real gespielt, weil öfter gezählt und umgeschaltet
werden muss. Bei hoehe=1 benötigt ein Ton etwa das 1,733-fache der Zeit, die
als Dauer angegeben wird; bei hoehe=30 wird sie hingegen beinahe eingehalten.
Der Multiplikator von 15 in der Länge gleicht die seltsame Dauer, die die
Delay-Schleife hat, aus (die kommt aus irgend einem Grund nicht mal annähernd
an Millisekunden heran).*/

void sound(uint8_t hoehe, uint16_t laenge)
{
for(uint16_t i=0; i<laenge*15; i=i+(2*hoehe))
{
setportdon(7);
_delay_loop_2(hoehe<<7); // 0,032ms*hoehe warten bei einem 16 MHz-Quarz
setportdoff(7); // (hoehe<<7) ist eine effizientere Schreibweise von hoehe*128
_delay_loop_2(hoehe<<7);
}
}

/*### PWM-Routinen zur Motoransteuerung ###*/

void init_timer1(void) //Initialisierung des Timers für Erzeugung des PWM-Signals
{
/* normale 8-bit PWM aktivieren (nicht invertiert),
Das Bit WGM10 wird im Datenblatt auch als PWM10 bezeichnet */
TCCR1A = (1<<COM1A1)|(1<<COM1B1)|(1<<WGM10);

/* Einstellen der PWM-Frequenz auf 14 kHz ( Prescaler = 1 ) */
TCCR1B = (1<<CS10);

/* Interrupts für Timer1 deaktivieren
Achtung : Auch die Interrupts für die anderen Timer stehen in diesem Register */
TIMSK &= ~0x3c;
}

void setPWMlinks(uint8_t speed) //Geschwindigkeit linker Motor
{OCR1BL = speed;}

void setPWMrechts(uint8_t speed) //Geschwindigkeit rechter Motor
{OCR1AL = speed;}

void Mlinkszur(void) //Uhrzeigersinn
{PORTC |= (1<<PC6); PORTC &= ~(1<<PC7);}

void Mlinksvor(void) //mathematischer Drehsinn
{PORTC &= ~(1<<PC6); PORTC |= (1<<PC7);}

void Mlinksstop(void) //aus
{ PORTC &= ~(1<<PC6); PORTC &= ~(1<<PC7);}

void Mrechtsvor(void) //Uhrzeigersinn
{PORTB |= (1<<PB0); PORTB &= ~(1<<PB1);}

void Mrechtszur(void) //mathematischer Drehsinn
{PORTB &= ~(1<<PB0); PORTB |= (1<<PB1);}

void Mrechtsstop(void) //aus
{PORTB &= ~(1<<PB0); PORTB &= ~(1<<PB1);}
</pre>

== Das C Demoprogramm==
<pre>
/*
###################################################
RNControl-Test.c

Aufgabe:
Dieses Testprogramm testet gleich mehrere Eigenschaften auf dem Board
Den verschiedenen Tasten sind bestimmte Funktionen zugeordnet
Taste 1: Zeigt Batteriespannung über RS232 an
Taste 2: Angeschlossene Motoren beschleunigen und abbremsen
Taste 3: Einige Male Lauflicht über LED´s anzeigen. Am I2C-Bus
darf in diesem Moment nichts angeschlossen sein
Taste 4: Zeigt analoge Messwerte an allen Port A PIN´s über RS232 an
Taste 5: Zeigt digitalen I/O Zustand von PA0 bis PA5 an

Sehr gut kann man aus dem Demo auch entnehmen wie Sound ausgegeben wird,
wie Tasten abgefragt werden und wie Subroutinen und Funktionen angelegt werden

Autor: Georg Richter
#######################################################
*/

#include <stdlib.h>
#include <avr/io.h>
#include "rncontrol.h"

/*### Variablen ###*/
const float referenzspannung = 0.0048828125; //Referenzwert zur Multiplikation mit den Werten der Analogports (0...1023), um auf die Voltzahl zu kommen (0...5). Ergibt sich aus 5/1024.
uint16_t analog; //Variable für jeweils an einem Analogport gemessenen Wert, um nicht für eine Ausgabe mehrere Messungen durchführen zu müssen.
char wort[5]; //Zahlen (Integer und Float) müssen vor der Ausgabe per RS232 in ASCII-Zeichen konvertiert werden, für die ein Speicher benötigt wird.

/*### Batteriespannung ###*/
void Batteriespannung(void)
{
sendUSART("Analog6 = "); analog = adcwert(6);
utoa(analog, wort, 10); sendUSART(wort); sendUSART(" = ");
dtostrf(analog*referenzspannung, 11, 8, wort); sendUSART(wort); sendUSART(" Volt\r\n");
dtostrf(adcwert(6)*referenzspannung*5.66804, 11, 8, wort);
sendUSART("Batteriespannung = "); sendUSART(wort); sendUSART(" Volt\r\n\n\n\n");
waitms(300);
}

/*### Motortest ###*/
void Motortest(void)
{
Mlinksvor();
Mrechtsvor();

setPWMlinks(0);
setPWMrechts(0);
waitms(40);

for(uint8_t i=0; i<255; i=i+5)
{
setPWMlinks(i);
setPWMrechts(i);
waitms(40);
}

setPWMlinks(255);
setPWMrechts(255);
waitms(40);

for(uint8_t i=255; i>0; i=i-5)
{
setPWMlinks(i);
setPWMrechts(i);
waitms(40);
}

setPWMlinks(0);
setPWMrechts(0);

Mlinksstop();
Mrechtsstop();
waitms(300);
}

/*### LED-Lauflicht ###*/
void Lauflicht(void)
{
for(uint8_t i=0; i<10; i++)
{
setportcoff(0);
waitms(150);
setportcon(0);
setportcoff(1);
waitms(150);
setportcon(1);
setportcoff(2);
waitms(150);
setportcon(2);
setportcoff(3);
waitms(150);
setportcon(3);
setportcoff(4);
waitms(150);
setportcon(4);
setportcoff(5);
waitms(150);
setportcon(5);
waitms(300);
}
}

/*### Analogwerte ###*/
void Analogwerte(void)
{
//Alle internen Pullups an, ausgenommen Port A3 und Batteriespannung/Taster (A6 und A7). Da A3 aber nun auch nicht auf GND liegt, ergibt sich ein "Rauschen", der Wert variiert mit jeder Messung mehr oder weniger stark.
setportaon(0);
setportaon(1);
setportaon(2);
setportaoff(3);
setportaon(4);
setportaon(5);

for(uint8_t i=0; i<8; i++)
{
analog = adcwert(i); //Messung Analogport [i]
utoa(i, wort, 10); sendUSART("Analog"); sendUSART(wort); sendUSART(" = "); //Ausgabe: "Analog[i] = "
utoa(analog, wort, 10); sendUSART(wort); sendUSART(" = "); //Ausgabe: "[Analogwert] = "
dtostrf(analog*referenzspannung, 11, 8, wort); sendUSART(wort); sendUSART(" Volt\r\n"); //Ausgabe: "[Reale Voltzahl] Volt[Umbruch]"
}

sendUSART("\n\n\n");
waitms(300);
}

/*### Digitalwerte ###*/
void Digitalwerte(void)
{
//Einige interne Pullups an, andere aus -> gibt bei einigen "Rauscheffekt", mal misst er "high", mal "low" und mal irgendwas dazwischen "?".
//Ein kleines Stückchen Draht an einem der Ports wirkt wahre Wunder, was das Rauschen betrifft -> viel öfter "low" dabei als ohne. Nachteil: Die Tastenerkennung funktioniert kaum noch.
setportaoff(0);
setportaon(1);
setportaoff(2);
setportaon(3);
setportaon(4);
setportaon(5);

for(uint8_t i=0; i<8; i++)
{
utoa(i, wort, 10); sendUSART("Digital"); sendUSART(wort); sendUSART(" = "); //Ausgabe: "Digital[i] = "
if (PINA & (1<<i)) {sendUSART("high");} else {sendUSART("low");} //Abgleich des Zustandes - Ausgabe: "high" oder "low"
sendUSART("\r\n");
}

sendUSART("\n\n\n");
waitms(300);
}

/*### Hauptschleife ###*/
int main(void)
{

/*###Initialisierungsphase###*/

//Pins bzw. Ports als Ein-/Ausgänge konfigurieren
DDRA |= 0x00; //00000000 -> alle Analogports als Eingänge
DDRB |= 0x03; //00000011 -> PORTB.0 und PORTB.1 sind Kanäle des rechten Motors
DDRC |= 0xFF; //11111111 -> PORTC.6 und PORTC.7 sind Kanäle des linken Motors, Rest sind LEDs für Lauflicht
DDRD |= 0xB0; //10110000 -> PORTD.4 ist PWM-Kanal des linken Motors, PORTD.5 des rechten

//Initialisierungen
setportcon(0); setportcon(1); setportcon(2); setportcon(3); setportcon(4); setportcon(5); //LEDs ausschalten
setportdoff(7); //Speaker aus
init_timer1(); //Initialisierung Timer für PWM
init_USART(); //USART konfigurieren

/*###Hauptschleife###*/
sound(6, 270); //Startmelodie
sound(8, 270);
sound(11, 270);
sound(7, 270);
waitms(10);
sound(7, 270);
sound(6, 270);
sound(11, 540);
sendUSART("\r\n\n\n"); //Sendet einen kleinen Begrüßungstext. "\r" setzt den Cursor wieder auf Zeilenanfag, "\n" beginnt dann die nächste Zeile
sendUSART("**** RN-CONTROL 1.4 *****\r\n");
sendUSART(" \r\n");
sendUSART("Fuer C umgeschrieben Version des mitgelieferten\r\n");
sendUSART("Bascom-BASIC Beispielprogramms inkl. eigener\r\n");
sendUSART("Header-Datei mit wichtigen Grundfunktionen.\r\n");
sendUSART(" \r\n");
sendUSART("Vielen Dank an die RN-Community fuer ihre Hilfe!\r\n\n\n\n");

Mlinksstop();
Mrechtsstop();

setPWMlinks(0);
setPWMrechts(0);

while(1)
{
switch(button())
{
case 1: Batteriespannung(); break;
case 2: Motortest(); break;
case 3: Lauflicht(); break;
case 4: Analogwerte(); break;
case 5: Digitalwerte(); break;
default: break;
}
}

return 0;
}

</pre>

==Anmerkungen==
* Bitte beachtet, dass dieses C-Demoprogramm bei den for-Schleifen den sogenannten ISO-Standard ISO/IEC 9899:1999 (kurz: C99) verwendet. Dieses muss dem AVR Compiler mittels -std=gnu99 oder -std=c99 mitgeteilt werden, da man sonst den Fehler "error: 'for' loop initial declaration used outside C99 mode" erhält. Soll dennoch der alte Standard verwendet werden, so muss die Deklaration der Zählvariablen aus den for-Schleifen rausgezogen werden.
* Werft auch einen Blick in die Diskussions-Seite zu diesem Artikel. Dort stehen weitere hilfreiche Anmerkungen, die z.T. noch nicht in dieses C-Demoprogramm eingeflossen sind.

==Autoren==
* RN-User Corone
* Frank (nur Gestaltung und Übernahme)
* CsT (Verbesserung von kleinen Fehlern)
* Manni2k (Verbesserung von kleinen Fehlern und Anmerkungen)

==Siehe auch==
* [[RN-Control]]
* [[Bascom]]

[[Kategorie:Grundlagen]]
[[Kategorie:Microcontroller]]
[[Kategorie:Quellcode C]]
[[Kategorie:Software]]
[[Kategorie:Praxis]]

Diskussion:RN-Control Demoprogramm in C

2010-04-18T13:23:17Z

Manni2k: Triple-Post entfernt.

Das Programm erzeugt beim kompilieren mit AVRStudio 4.13.528 Fehler bei den For-Schleifen. Das rührt daher, dass in rncontrol.h Variablen in C++-Manier in den for-Anweisung selbst deklariert werden.

Bsp.:
<pre>
void sound(uint8_t hoehe, uint16_t laenge)
{
for(uint16_t i=0; i<laenge*15; i=i+(2*hoehe))
{
setportdon(7);
_delay_ms(hoehe);
setportdoff(7);
_delay_ms(hoehe);
}
}
</pre>

Fehler:

"error: 'for' loop initial declaration used outside C99 mode"

Werde das jetzt an den relevanten Stellen so ändern :
<pre>
void sound(uint8_t hoehe, uint16_t laenge)
{
uint16_t i;
for(i=0; i<laenge*15; i=i+(2*hoehe))
{
setportdon(7);
_delay_ms(hoehe);
setportdoff(7);
_delay_ms(hoehe);
}
}
</pre>

Wäre schön, wenn es dann zur Sicherheit mal jemand testen könnte.

Habe zur Sicherheit bei allen Änderungen mal

'''"initial declaration error" fix'''

eingefügt.

== Neuer Abschnitt ==

Zum letzten Abschnitt: Stimmt!

Mir ist aufgefallen, dass das Basic Beispieltestprogramm für die Tastenabfrage am Porta.7 den Pull-Up Widerstand verwendet, um bei nicht gedrückter Taste einen definierten Spannungspegel am AD Wandlereingang zu haben (+5V)

<pre>

...

Config Adc = Single , Prescaler = Auto 'Für Tastenabfrage und Spannungsmessung

Config Pina.7 = Input 'Für Tastenabfrage
Porta.7 = 1 'Pullup Widerstand ein

...

</pre>

Dies ist im C-Programm nicht so realisiert und der Pin hängt bei nicht gedrückter Taste in der Luft, was möglicher Weise zu dem im C-Programm beschriebenen Effekt führt

<pre>

.....

setportaon(7); //Ohne das hier "flackern" die Werte aus irgend einem Grund -> es werden
// mitunter Tasten erkannt, die gar nicht gedrückt wurden oder das
//Programm bleibt für einige Sekunden "hängen"
waitms(1);
setportaoff(7);
....

</pre>

Meine Lösung:

<pre>

.........

/*### Hauptschleife ###*/

int main(void)
{

/*###Initialisierungsphase###*/

//Pins bzw. Ports als Ein-/Ausgänge konfigurieren

//Initialisierungen

setportdoff(7); //Speaker aus

init_USART(); //USART konfigurieren

DDRA = 0x00; //00000000 -> alle Analogports als Eingänge

SFIOR &= ~(1<<PUD); // Pull-UP enable (nicht unbedingt nötig, aber zur Klarheit!)
PORTA |= (1<<PA7); // internen Pull-Up an PA7 aktivieren

......

</pre>

Dann muss die Buttonabfrage wegen des Pull-Up Widerstandes entsprechend angepasst werden, denn er liegt nun parallel zu dem 10k Widerstand + 1 bis 4 1k Widerständen (je nach gedrückter Taste). Dann stimmen die Ergebnisse der AD Wandlung auch mit dem des Basic-Programms überein und können direkt übernommen werden

<pre>

...

/*### Buttonabfrage ###*/

uint8_t button(void)
{
uint8_t taste = 0; //Variable für Nummer des Tasters
uint16_t analog7 = adcwert(7); //Wert des Ports

//-----------auskommentieren, sonst wird der int. Pull Up Widerstand wieder abgeschaltet!

// setportaon(7);
// waitms(1);
// setportaoff(7);

/ Die folgende Zeile ist nur zur Überprüfung aller gelesenen Werte und kann auskommentiert werden
utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);sendUSART("\r\n");

//Abfrage des gedrückten Tasters - um Störungen zu vermeiden wurden
//die Bereiche sehr eng gefasst, sollten bei Bedarf an jedes Board extra angepasst werden.
if((analog7>=400) && (analog7<=450)) {taste = 1;utoa(analog7, wort, 10),sendUSART("Wert=");sendUSART(wort);}
else if((analog7>=330) && (analog7<=380)) {taste = 2;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=260) && (analog7<=305)) {taste = 3;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=180) && (analog7<=230)) {taste = 4;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else if((analog7>=90) && (analog7<=130)) {taste = 5;utoa(analog7, wort, 10),sendUSART("ADC-Wert=");sendUSART(wort);}
else {}

return taste;
}

</pre>

Hier mal die bei mir gemessenen AD Werte: (in der letzten Tabellenspalte wurde der interne Pull Up Widerstand (PW) durch einen externen 22k Widerstand ersetzt!)

{| border= 1
|Taste
|ohne PW
|mit internem PW
|mit ext. PW (22k)
|-
|1
|341
|408
|432
|-
|2
|272
|340
|363
|-
|3
|204
|268
|286
|-
|4
|135
|190
|202
|-
|5
|67
|106
|106
|}

== Korrektur der Soundausgabe ==

Hallo,

ich bin zwar grad erst in die Mikrocontrollerwelt eingestiegen, habe aber gleich mal einen Verbesserungsvorschlag für das Demoprogramm:

Die Soundausgabe hat bei mir nicht wirklich funktioniert (RN-Control mit 16 MHz). Es lag einerseits daran, dass die waitms()-Funktion nicht die korrekte Anzahl an Millisekunden gewartet hat und andererseits hat auch die sound()-Funktion nur komische Töne erzeugt. Unter [http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=30242 diesem Link] (Registrierung nötig) kann man sich eine alternative delay.h herunterladen (delay_x.h). Diese stellt Delays bis auf einen Taktzyklus genau dar und ist Compileroptimierungsunabhängig. Damit habe ich eine neue sound()-Funktion geschrieben, der als Argumente die Frequenz in Hertz und die Dauer in 1/10-Sekunden übergeben wird.

<pre>
void sound(uint16_t frequenz, uint16_t dauer)
{
uint32_t cycles;
uint16_t holdtime;
cycles=frequenz*dauer/2;
holdtime=1000000/frequenz;

for (uint16_t i = 0; i<(cycles/10); i++)
{
setportdon(7);
_delay_us(holdtime);
setportdoff(7);
_delay_us(holdtime);
}
}
</pre>

Natürlich vorher die delay_x.h ins \util-Verzeichnis packen und die include Anweisung entsprechend anpassen.

Das ganze lässt sich sicher noch optimieren. Probierts mal aus, bei mir hats hervorragend geklappt. Wenn das ganze bugfrei ist, dann würd ichs (wenn das genehm ist) im Hauptartikel entsprechend umschreiben.

== Optimierungen ==
Ich bin zwiar kein wirklicher C Spezi, aber da sind einige Teile nicht gut gelöst. Einen Teil könnte der Compiler eventuell automatisch optinmieren, GCC tuts aber noch nicht überall.

Bei der ADWandlerroutine solle man statt
wert = wert / 4; besser "wert >> 2" nutzen, ist nicht so übersichtlich, aber die Division wird so vermieden.

Viele der ganz kurzen Funktionen (z.B. Bit in Ports setzen) sollte man wenigstes als inline deklarieren.
Besser wäre es da mit #define zu arbeiten.