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.:
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);
}
}
Fehler:
"error: 'for' loop initial declaration used outside C99 mode"
Werde das jetzt an den relevanten Stellen so ändern :
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);
}
}
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.
Inhaltsverzeichnis
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)
... Config Adc = Single , Prescaler = Auto 'Für Tastenabfrage und Spannungsmessung Config Pina.7 = Input 'Für Tastenabfrage Porta.7 = 1 'Pullup Widerstand ein ...
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
.....
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);
....
Meine Lösung:
.........
/*### 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
......
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
...
/*### 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;
}
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!)
| 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 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.
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);
}
}
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.
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 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.
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);
}
}
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.
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 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.
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);
}
}
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.
