Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese

Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Aha, das ist das also! Dann beschreiben diese Bildchen also diesen Übergang.

Es macht also nur Sinn, an der Güte zu feilen oder die Filterart zu ändern, wenn man mit der Grenzfrequenz in die Nähe der wegzufilternden Frequenz muß. Wenn es aber egal ist, ob vor der zu filternden Frequenz noch etwas beeinflußt wird oder nicht, kann man nur die Ordnung erhöhen und/oder die Grenzfrequenz senken. In meinem Fall (244Hz) ist also schon ab einer Grenzfrequenz von ca. 200Hz egal.
Jede zusätzliche Filterordnung halbiert die Restwelligkeit, also müßte unter dem Noise bei mir noch eine Welle liegen, die erst bei einem anständigen Aufbau sichtbar wird, also entweder brauche ich mindestens noch eine Stufe oder die Grenzfrequenz muß noch eine Dekade runter.
frickelfred56
Beiträge: 240
Registriert: Mo 16. Feb 2015, 13:50

Re: Der AVR-/ARDUINO-Faden

Beitrag von frickelfred56 »

Hallo zusammen

Ich versuche gerade mir ein Schaltmodul zu Basteln, welches zu Sonnenaufgang und Untergang schaltet.
dazu habe ich das DCF77 Modul (http://playground.arduino.cc/Code/DCF77) mit der Berechnung der Sonnenauf -
Untergangzeit zusammengeschaltet. ( http://www.arduinoforum.de/arduino-Thre ... teuerungen ) Danke für den Code. Das klappt auch alles .
Und hier nun mein Problem?
Für die Umschaltung zwischen Sommer und Winterzeit benötige ich das Entsprechende DCF Signal (Bit 17 oder 18 ) im DCF Protokoll.

Hier ein kurzer Ausschnittt aus Der Datei DCF77.cpp

//convert the received buffer into time
time.Second = 0;
time.Minute = rx_buffer->Min-((rx_buffer->Min/16)*6);
time.Hour = rx_buffer->Hour-((rx_buffer->Hour/16)*6);
time.Day = rx_buffer->Day-((rx_buffer->Day/16)*6);
time.Month = rx_buffer->Month-((rx_buffer->Month/16)*6);
time.Year = 2000 + rx_buffer->Year-((rx_buffer->Year/16)*6) -1970;
latestupdatedTime = makeTime(time);
CEST = rx_buffer->CEST;
//Parity correct
return true;
} else {
//Parity incorrect
return false;
}

Wenn ich den Code richtig verstanden habe, stellen die Var CST und CEST die gesuchten Variablen dar ?

Wie kann ich auf die Variablen von der Arduino Sketch Ebene zugreifen.

Danke für die Antworten und soory für den (Ewig) Langen Text.
Kenakapheus
Beiträge: 173
Registriert: Fr 1. Jan 2016, 20:43
Wohnort: Freie Feldlage (Ja, da wo das Treffen ist))

Re: Der AVR-/ARDUINO-Faden

Beitrag von Kenakapheus »

Hi,

ohne weiteres geht das leider nicht, die Variable ist im Objekt als Privat markiert und daher nicht von außen sichtbar.

ABER...
Mit etwas gefrikel geht es schon.

Ich habe leider gerade keinen Compiler zum überprüfen da, aber eigentlich sollte das so klappen.
Wenn nicht Poste doch bitte mal die Fehlermeldung und den gesamten Sketch.

Code: Alles auswählen

struct overlay_s {
	bool initialized;	
	static int dCF77Pin;
	static int dCFinterrupt;
	static byte pulseStart;
	static time_t previousUpdatedTime;
	static time_t latestupdatedTime;           	
	static  time_t processingTimestamp;
	static  time_t previousProcessingTimestamp;		
	static unsigned char CEST;
} *dcf_overlay = (overlay_s *)(&DCF77);

unsigned char CEST = dcf_overlay->CEST;
Wobei [DCF77] die Insanz der Library ist (Die Variable, die du mit .getTime() benutzt).

Grüße Kenakapheus
frickelfred56
Beiträge: 240
Registriert: Mo 16. Feb 2015, 13:50

Re: Der AVR-/ARDUINO-Faden

Beitrag von frickelfred56 »

Hallo
Erst mal Danke für die Antwort.
komme Heute leder nicht dazu das zu Probieren.
melde mich wenn ich es probiert habe
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Hm... das ist alles diese Arduino-Sprache? Damit kenne ich mich nicht aus, aber bei C++ würde der einfach in der abgeleiteten Klasse eine neue Variable aufmachen, die dann intern aber nicht benutzt wird. Somit gäbe es keine Fehlermeldung, aber der Wert wäre immer 0.

Andernfalls wäre das "private:" ja auch ziemlich witzlos.

Da müßte man schon die Header der Lib ändern und zumindest mal protected daraus machen, dann könnte man immerhin mit Zugriffsfunktionen arbeiten (oder einfach gleich in dem Header noch die passende Zugriffsunktion eintragen). OK, wir sind ja auf einem µC, da könnte man jetzt gucken, wo der die Variable hinlegt und manuell in Assembler darauf zugreifen, dagegen kann sich der Compiler ja nicht wehren, aber das muß man dann dauernd selber nachprüfen, ob das noch die richtige Adresase benutzt, bei einem größeren Projekt will man das nicht...
Kenakapheus
Beiträge: 173
Registriert: Fr 1. Jan 2016, 20:43
Wohnort: Freie Feldlage (Ja, da wo das Treffen ist))

Re: Der AVR-/ARDUINO-Faden

Beitrag von Kenakapheus »

Hi,

nein das ist ganz normales C/C++, aber wie kommst du darauf das der Code die Klasse ableitet?
Die Variablen im Struct stehen genauso in der Klasse werden nur gebraucht damit der Compiler weiß wo der Wert steht.

Im Prinzip habe ich genau das vor was du als 2. vorgeschlagen hast:
Der Code greift einfach auf das richtige Byte im RAM zu. Allerdings überlasse ich das ausrechnen der genauen
Adresse dem Compiler, somit müsste sich schon was an der Lib ändern damit der Trick nicht mehr klappt.

Grüße Kenakapheus
Blueloop
Beiträge: 148
Registriert: Mo 12. Aug 2013, 17:59
Wohnort: Ettlingen

Re: Der AVR-/ARDUINO-Faden

Beitrag von Blueloop »

Warum so kompliziert, man kann doch einfach die LIB ändern, die kommt ja eh als Sourcecode.
Ist auf jedenfall besser als so ein Hack da zu basteln. Natürlich gehts beim nächsten Update der Lib nichtmehr, aber da kann man sich ja einen Kommentar in seinen Code Stricken der auf die notwendige Anpassung hinweist, damit man das in 5 Jahren noch weiß.
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Ah, OK, ich hatte angenommen, das sei nicht echtes C++ und habe daher gar nicht auf die Syntax geachtet. Du machst einfach einen Cast (reinterpret_cast) in ein außer dem "private:" identisches struct, das würde das automatisieren, stimmt, müßte so gehen. Blueloops Einwand gilt natürlich trotzdem (da die lib wahrscheinlich nicht vorkompiliert geladen wird, dürften auch geänderte Compileroptionen nicht vorkommen), ist nur die Frage, ob die überhaupt noch geupdated wird und wenn ja, ob das struct verändert wird. ich schreibe an solche Stellen immer ein "#warning <Grund>", das sieht man spätestens beim Neukompilieren, den alten Code guckt man ja nicht komplett durch bei einer Änderung.
Benutzeravatar
xoexlepox
Beiträge: 4815
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Falls du nicht an dem Library-Code herumschrauben möchtest, sehe ich noch drei weitere Möglichkeiten:

1) Wenn ich es beim kurzen Überfliegen richtig mitbekommen habe, liefert die Lib den aktuellen Zeitpunkt sowohl als UTC, als auch als "offizielle" Zeit. Wenn du davon die Differenz bildest, bekommst du auch heraus, ob es nun Sommerzeit ist, oder nicht.

2) Womit wird denn das Modul zur Sonnenaufgangsberechnung "gefüttert"? Das Sinnvollste wäre doch UTC, dann baucht man sich um diesen ganzen Mist der Zeitumstellung keine Gedanken zu machen ;)

3) Wenn du das Datum hast, sollte es kein großes Problem sein, daraus zu bestimmen, ob das nun Sommerzeit ist, oder nicht. Etwas fummelig wird dabei zwar die nächtliche fehlende (oder überzählige) Stunde, aber zu diesen Zeiten ist die Sonne sicher unter dem Horizont ;)
frickelfred56
Beiträge: 240
Registriert: Mo 16. Feb 2015, 13:50

Re: Der AVR-/ARDUINO-Faden

Beitrag von frickelfred56 »

Hallo zusammen

Erstmal Danke für die Antworten
Leider kann ich die nächten Wochen an dem Projekt nicht weitermachen.
Die Gesundheit fordert andere Prioritäten.
Myvesdin
Beiträge: 45
Registriert: Sa 5. Apr 2014, 10:20

Re: Der AVR-/ARDUINO-Faden

Beitrag von Myvesdin »

Moin moin,

ich bin gerade einwenig am verzweifeln.

Code: Alles auswählen

#include <DS1307RTC.h>
#include <Wire.h> 
#include <LiquidCrystal_I2C.h>
#include <Time.h>

LiquidCrystal_I2C lcd(0x27,20,4);  // set the LCD address to 0x27 for a 20 chars and 4 line display
uint8_t heart[8] = {0x0,0xa,0x1f,0x1f,0xe,0x4,0x0};
uint8_t battlowest[8] = {0xe,0x1f,0x11,0x11,0x11,0x11,0x11,0x1f};
uint8_t battlower[8] = {0xe,0x1f,0x11,0x11,0x11,0x11,0x1f,0x1f};
uint8_t battlow[8] = {0xe,0x1f,0x11,0x11,0x11,0x1f,0x1f,0x1f};
uint8_t battmid[8] = {0xe,0x1f,0x11,0x11,0x1f,0x1f,0x1f,0x1f};
uint8_t batthigh[8] = {0xe,0x1f,0x11,0x1f,0x1f,0x1f,0x1f,0x1f};
uint8_t batthighest[8] = {0xe,0x1f,0x1f,0x1f,0x1f,0x1f,0x1f,0x1f};



int val = 0;
int abruf = 0;
long licht = 0;
int lichtan = 0;
int letztstunde = 0;
int letztminute = 0;
int battery = 0;



void setup()
{
  lcd.init();                      // initialize the lcd 
  pinMode(6, INPUT);
  //digitalWrite(6, HIGH);    //Button
  pinMode(13, OUTPUT);
  lcd.noBacklight();
  lcd.createChar(1, heart);
  lcd.createChar(2, battlowest);
  lcd.createChar(3, battlower);
  lcd.createChar(4, battlow);
  lcd.createChar(5, battmid);
  lcd.createChar(6, batthigh);
  lcd.createChar(7, batthighest);
  lcd.home();
  lcd.write(1);  
  tmElements_t tm;  //Uhrzeit
  RTC.read(tm);
  lcd.setCursor(0,3);
  if (tm.Hour < 10){lcd.print("0");};
  lcd.print(tm.Hour);
  letztstunde = tm.Hour;
  lcd.print(":");
  if (tm.Minute < 10){lcd.print("0");};
  lcd.print(tm.Minute);
  letztminute = tm.Minute;

}

void loop()
{

  abruf = abruf + 1;

 
  
  if (abruf > 5000){
    tmElements_t tm;
    RTC.read(tm);     //Zeit
    if (letztstunde == tm.Hour){}
      else
       {
        lcd.setCursor(0,3);
        if (tm.Hour < 10){lcd.print("0");};
        lcd.print(tm.Hour);
        letztstunde = tm.Hour;
        }
     if (letztminute == tm.Minute){}
      else
       {
        lcd.setCursor(3,3);
        if (tm.Minute < 10){lcd.print("0");};
        lcd.print(tm.Minute);
        letztminute = tm.Minute;
        }   
    abruf = 0;
    }
    val = digitalRead(6);
  if (val == 0){        //Button
    lcd.backlight();
   //digitalWrite(13,1);
    lichtan = 1;
    licht = 0;
    }
  //val = digitalRead(6);
  if (lichtan = 1);{
    licht = licht +1;
    }
  if (licht > 320000){
    licht = 0;
    lichtan = 0;
    lcd.noBacklight();
    }

}
So funktioniert der Code und die Hintergrundbeleuchtung geht nach einiger Zeit wieder aus.

Code: Alles auswählen

#include <DS1307RTC.h>
#include <Wire.h> 
#include <LiquidCrystal_I2C.h>
#include <Time.h>

LiquidCrystal_I2C lcd(0x27,20,4);  // set the LCD address to 0x27 for a 20 chars and 4 line display
uint8_t heart[8] = {0x0,0xa,0x1f,0x1f,0xe,0x4,0x0};
uint8_t battlowest[8] = {0xe,0x1f,0x11,0x11,0x11,0x11,0x11,0x1f};
uint8_t battlower[8] = {0xe,0x1f,0x11,0x11,0x11,0x11,0x1f,0x1f};
uint8_t battlow[8] = {0xe,0x1f,0x11,0x11,0x11,0x1f,0x1f,0x1f};
uint8_t battmid[8] = {0xe,0x1f,0x11,0x11,0x1f,0x1f,0x1f,0x1f};
uint8_t batthigh[8] = {0xe,0x1f,0x11,0x1f,0x1f,0x1f,0x1f,0x1f};
uint8_t batthighest[8] = {0xe,0x1f,0x1f,0x1f,0x1f,0x1f,0x1f,0x1f};



int val = 0;
int abruf = 0;
long licht = 0;
int lichtan = 0;
int letztstunde = 0;
int letztminute = 0;
int battery = 0;



void setup()
{
  lcd.init();                      // initialize the lcd 
  pinMode(6, INPUT);
  //digitalWrite(6, HIGH);    //Button
  pinMode(13, OUTPUT);
  lcd.noBacklight();
  lcd.createChar(1, heart);
  lcd.createChar(2, battlowest);
  lcd.createChar(3, battlower);
  lcd.createChar(4, battlow);
  lcd.createChar(5, battmid);
  lcd.createChar(6, batthigh);
  lcd.createChar(7, batthighest);
  lcd.home();
  lcd.write(1);  
  tmElements_t tm;  //Uhrzeit
  RTC.read(tm);
  lcd.setCursor(0,3);
  if (tm.Hour < 10){lcd.print("0");};
  lcd.print(tm.Hour);
  letztstunde = tm.Hour;
  lcd.print(":");
  if (tm.Minute < 10){lcd.print("0");};
  lcd.print(tm.Minute);
  letztminute = tm.Minute;

}

void loop()
{
 battery = analogRead(A0);    //DAT HIER
  
  abruf = abruf + 1;

 
  
  if (abruf > 5000){
    tmElements_t tm;
    RTC.read(tm);     //Zeit
    if (letztstunde == tm.Hour){}
      else
       {
        lcd.setCursor(0,3);
        if (tm.Hour < 10){lcd.print("0");};
        lcd.print(tm.Hour);
        letztstunde = tm.Hour;
        }
     if (letztminute == tm.Minute){}
      else
       {
        lcd.setCursor(3,3);
        if (tm.Minute < 10){lcd.print("0");};
        lcd.print(tm.Minute);
        letztminute = tm.Minute;
        }   
    abruf = 0;
    }
    val = digitalRead(6);
  if (val == 0){        //Button
    lcd.backlight();
   //digitalWrite(13,1);
    lichtan = 1;
    licht = 0;
    }
  //val = digitalRead(6);
  if (lichtan = 1);{
    licht = licht +1;
    }
  if (licht > 320000){
    licht = 0;
    lichtan = 0;
    lcd.noBacklight();
    }

}
Sobald man aber "battery = analogRead(A0);" in den Loop einfügt hängt sich der Arduino auf oder so
Aufjedenfall geht die Hintergrundbeleuchtung nicht wieder aus.

Wo liegt das Problem im Code?

Grüße
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

Hmmm...

Ich hab leider gerade keinen Arduino zur Hand um deinen Source auszuprobieren.
Aber wenn ich bisher nicht alles falsch verstanden habe, braucht "analogRead" relativ lange zur Durchführung (im Gegensatz zu anderen Befehlen)
Hast du einfach schon mal abgewartet? - Einerseits, ob deine Minutenanzeige hochzählt - dann hat er sich nicht aufgehängt, und andrerseits, ob das Backlight nicht doch irgendwann ausgeht.
Oder setz einfach mal den Vergleichswert für deine Backlight-Zeit kleiner.

P.S. Ich bin selber nur ein fürchterlicher Arduino-Programmierer - gibt hier sicher einige, die das viel besser können. Aber für dein Backlight Google mal nach "non blocking delay" http://playground.arduino.cc/Code/AvoidDelay - dann hast du eine fixe Verzögerung, die nicht von Programmlaufzeiten abhängig ist.

Für die RTC würde ich dir eher die DS3231 empfehlen als die DS1307 - da kannst du gleich ohne RTC arbeiten.
Wie man den Arduino leichter mit der RTC Synchron bekommt - schau dir die hier verlinkte Library an (letzte 2 Absätze des Textes) https://arduino-hannover.de/2015/02/25/ ... s-arduino/

Ich hoffe, die Tipps helfen dir.

lg.
Sir_Death
Myvesdin
Beiträge: 45
Registriert: Sa 5. Apr 2014, 10:20

Re: Der AVR-/ARDUINO-Faden

Beitrag von Myvesdin »

Moin,

Die Zeitanzeige läuft wie normal weiter.
Auch die gemessene Spannung ändert sich und stimmt überein.

Nur das erneute Ausschalten der Displaybeleuchtung geht nicht.

Code: Alles auswählen

if (val == 0){        //Button
    lcd.backlight();
   digitalWrite(13,1);
    lichtan = 1;
    licht = 0;
    }
Und auch die LED leuchtet in diesem Fall dauerhaft, obwohl der PIN auf 5V liegt.

Grüße
andreas6
Beiträge: 4161
Registriert: So 11. Aug 2013, 15:09

Re: Der AVR-/ARDUINO-Faden

Beitrag von andreas6 »

Da fällt mir ein Fehler ins Auge:

Code: Alles auswählen

if (lichtan = 1);{
Ist der Klassiker, dort findet auch eine ungewollte Zuweisung statt. Nimm "==", das geht besser.

MfG. Andreas
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

andreas6 hat geschrieben:Da fällt mir ein Fehler ins Auge:

Code: Alles auswählen

if (lichtan = 1);{
Ist der Klassiker, dort findet auch eine ungewollte Zuweisung statt. Nimm "==", das geht besser.

MfG. Andreas
Uuupps habe ich auch überlesen - passierte mir auch immer wieder. :lol:
Da gibt es einen super Tipp von Meister Zabex:

Code: Alles auswählen

if (1==lichtan) 
schreibst du dort dann nur

Code: Alles auswählen

if (1=lichtan) 
wirft er dir automatisch einen Fehler aus! - geht natürlich nur mit Konstanten - nicht wenn du 2 Variablen vergleichst.
Benutzeravatar
ferdimh
Beiträge: 9429
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

Das auf das If folgende Semikolon macht die Funktionalität auch nicht besser.
wenn die Bedingung zutrifft, rennt es gleich in ein Semikolon.
Danach kommt ein Block, der auf jeden Fall ausgeführt wird...
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

Sir_Death hat geschrieben: Da gibt es einen super Tipp von Meister Zabex: [...]wirft er dir automatisch einen Fehler aus! - geht natürlich nur mit Konstanten - nicht wenn du 2 Variablen vergleichst.
Oder aber, man überlässt dem Compiler das Flüchtigkeitsfehlersuchen und hört auch auf ihn.
Mit -Wall liefert der nämlich schön brav:

Code: Alles auswählen

gcc test.c -Wall test.c: In function ‘main’:
test.c:5:2: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
  if(fehler=1);{
  ^
Mit -Wextra gibt es dann auch gleich noch:

Code: Alles auswählen

test.c:5:14: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
  if(fehler=1);{
              ^
Beide Fehler lassen sich so ganz einfach vom Compiler finden. -Wall und -Wextra sollte man immer gesetzt haben. Scheinbar macht das die Arduino-Umgebung nicht von alleine... aber man kann das bestimmt nachholen.
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

Das wäre super, wenn das ginge! - Irgendwer einen Tipp wie?
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

Google nach "arduino IDE compiler switch" bringt diesen Post bei Stackoverflow hervor: http://stackoverflow.com/questions/2803 ... piler-flag

Darin heißt es, dass zumindest bei 1.5.x die Datei ".\Arduino\hardware\arduino\avr\platform.txt" die Kommandozeilenparameter definiert.

Außerdem steht da, welches Format eine "platform.local.txt" im selben Verzeichniss haben muss um extra Compiler-Schalter anzugeben. So wie ich das sehe, muss -Wall -Wextra auf jeden Fall bei compiler.c.extra_flags und compiler.cpp.extra_flags ergänzt werden. Ansonsten kennt sich vielleicht hier jemand besser mit der Arduino-IDE aus?
Myvesdin
Beiträge: 45
Registriert: Sa 5. Apr 2014, 10:20

Re: Der AVR-/ARDUINO-Faden

Beitrag von Myvesdin »

Danke an alle helfenden
So klappst jetzt perfekt

Code: Alles auswählen

{
  
  
  abruf = abruf + 1;

 
  
  if (abruf > 5000){
    battery = analogRead(A0);
    tmElements_t tm;
    RTC.read(tm);     //Zeit
    if (letztstunde == tm.Hour){}
      else
       {
        lcd.setCursor(0,3);
        if (tm.Hour < 10){lcd.print("0");};
        lcd.print(tm.Hour);
        letztstunde = tm.Hour;
        }
     if (letztminute == tm.Minute){}
      else
       {
        lcd.setCursor(3,3);
        if (tm.Minute < 10){lcd.print("0");};
        lcd.print(tm.Minute);
        letztminute = tm.Minute;
        }   
    abruf = 0;
    }
    val = digitalRead(6);
  if (val == 0){        //Button
    lcd.backlight();
   //digitalWrite(13,1);
    lichtan = 1;
    licht = 0;
    }
  //val = digitalRead(6);
  if (lichtan == 1){
    licht = licht +1;
    }
  if (licht > 230000){
    licht = 0;
    lichtan = 0;
    lcd.noBacklight();
    }
}

Grüße
Sir_Death
Beiträge: 3446
Registriert: Mo 11. Mai 2015, 22:36
Wohnort: südlich von Wien

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sir_Death »

Bauteiltöter hat geschrieben:Google nach "arduino IDE compiler switch" bringt diesen Post bei Stackoverflow hervor: http://stackoverflow.com/questions/2803 ... piler-flag

Darin heißt es, dass zumindest bei 1.5.x die Datei ".\Arduino\hardware\arduino\avr\platform.txt" die Kommandozeilenparameter definiert.

Außerdem steht da, welches Format eine "platform.local.txt" im selben Verzeichniss haben muss um extra Compiler-Schalter anzugeben. So wie ich das sehe, muss -Wall -Wextra auf jeden Fall bei compiler.c.extra_flags und compiler.cpp.extra_flags ergänzt werden. Ansonsten kennt sich vielleicht hier jemand besser mit der Arduino-IDE aus?
Ich habe mich heute mit der Plattform.local.txt gespielt - leider ohne irgendein Ergebnis.. mal schauen, ob ich mich nochmal mit der platform.txt spiele...
Benutzeravatar
zauberkopf
Beiträge: 9528
Registriert: So 11. Aug 2013, 15:33
Wohnort: gefährliches Halbwissen

Re: Der AVR-/ARDUINO-Faden

Beitrag von zauberkopf »

Übrigens, Franz, der Sondengott, hat was beim AVR festgestellt :
Wenn man den AVR als Taktquelle mißbraucht, ist der Takt nicht frei von Jitter, sondern ist mit einem geringen behaftet, je nach dem was die CPU gerade macht.
Das ist ihm aufgefallen, als er versuchte einen RDA1846 mit dem Takt vom AVR zu versorgen.
Der nachgemessener Jitter ist zwar extrem klein, aber reicht aus, um den RDA aus dem Konzept zu bringen. Dieser benötigt nämlich eine extrem saubere Taktquelle.
Benutzeravatar
Geistesblitz
Beiträge: 1934
Registriert: Di 5. Nov 2013, 17:53
Wohnort: Dresden

Re: Der AVR-/ARDUINO-Faden

Beitrag von Geistesblitz »

So, ich hab da mal etwas, wo ich ein wenig Hilfe brauch:

Ich bin schon seit längerem dabei, nach und nach eine Elektronik für eigene DC-Servos zu basteln. Einen funktionsfähigen Regler hab ich dafür auch schon aufgebaut, jetzt befasse ich mich allerdings etwas mehr mit dem Thema serielle Kommunikation, wo bei mir sicherlich auch noch etwas Nachholbedarf besteht.

Momentan ist es so, dass der Controller über SPI mit einem Magnetsensor kommuniziert (dieser schickt an sich nur die rohen Positionsdaten zurück, 14 Bit Auflösung hat das Teil, die übrigen 2 Bit enthalten auch Informationen, die hier aber nicht weiter wichtig sind) und über einen USB-UART-Wandler mit dem PC. Dort hab ich auch ein relativ simples Programm in LabView (mag ich eigentlich nicht, war für die Aufgabe aber das Einfachste) zusammengehackt, welches die Sollwerte an den Controller schickt, Istwerte empfängt und beides schön in einem kontinuierlich laufenden Diagramm anzeigt.

Die Kommunikation soll jetzt aber ausgebaut werden, sodass ich außer den Sollpositionen auch Betriebsmodi und Reglerparameter einstellen und auslesen kann, außerdem sollen mehrere Teilnehmer an einem Bus hängen können. Könnte man das auch noch mit UART machen und sich ein System zur Adressierung ausdenken oder ist es sinnvoll auf I²C zu wechseln? Das hätte auch den Vorteil, dass man eventuell einen Master mit dem PC über UART verbinden könnte und der dann über I²C mit den Reglermodulen redet.

Vielleicht bilde ich mir aber auch nur ein, dass das sinnvoll wäre. Kann mir da vielleicht einer helfen? Ich merk auch gerade, dass ich bei UART auch gar nicht wüsste, wie man bei mehreren Teilnehmern die Datenleitungen verdrahten müsste, damit es zu keinen Kollisionen kommt, bei welchen die Controller sich gegenseitig räuchern.
Zuletzt geändert von Geistesblitz am So 24. Jul 2016, 23:55, insgesamt 1-mal geändert.
Benutzeravatar
Fritzler
Beiträge: 12602
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Schreib doch bitte das nächste mal mit Absätzen...
Da kricht man ja Augenkrebs!

AVRs haben nen 9Bit UART und das 9. Bit kann für MUltimaster und Adressierungen am UART genutzt werden -> mal das DB eines atrmega durchlesen.
Benutzeravatar
Geistesblitz
Beiträge: 1934
Registriert: Di 5. Nov 2013, 17:53
Wohnort: Dresden

Re: Der AVR-/ARDUINO-Faden

Beitrag von Geistesblitz »

So besser?

Ich hab mir bisher noch kein Datenblatt eines AVR komplett durchgelesen, dafür ist mir das einfach zu viel. Ich werd aber mal nach der Stelle gucken, die du ansprichst, auch wenn ich mir noch nciht so recht vorstellen kann, wie das funktionieren soll.

Jedenfalls bin ich noch weiter dabei, mich zu informieren, und I²C erscheint mir da doch sinnvoller. Hab hier auch eine Quelle gefunden, nach welcher es wohl ganz gut gehen soll, AVRs als Slave zu konfigurieren. Muss ich beizeiten mal ausprobieren.
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Hatte das glaub ich schonmal in einem anderen Fred gepostet, aber egal: [url="sbprojects.com/sbbus]der Typ[/url] macht das mit RS232 und Optokopplern. Kann allerdings nur Single Master.
Benutzeravatar
Trax
Beiträge: 1677
Registriert: Mi 30. Okt 2013, 23:21

Re: Der AVR-/ARDUINO-Faden

Beitrag von Trax »

Kann man den ARef pin eines AVR irgendwie als weiteren ADC Chanel missbrauchen?

Datenblat sagt:
ATmega1284P features an internal bandgap refer
ence. This reference is used for Brown-out
Detection, and it can be used as an input to the Analog Comparator or the ADC
Da müsste ich doch wen dich die interne referenz messe und und an der externen unterschiedliche Spannungen anlege unterschiedliches messen können, oder?
Benutzeravatar
MadEngineer
Beiträge: 111
Registriert: Fr 26. Jun 2015, 12:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von MadEngineer »

Ja das müsste gehen. Diesen Klimmzug musste ich mal bei einem STM32 machen. Als Referenzspannung war nur die Versorgungsspannung möglich. Dann die interne Bandgap messen und schon kann man auf Vref, sprich die Versorungungsspannung zurückrechnen. Du weißt ja, dass deine Referenzspannung der Vollausschlag des ADC ist und deine Bandgap-Spannung ist ja auch bekannt..

Bei den AVR müsstest du dann im ADMUX Register:
-REFS1 und REFS0 auf 0 setzen --> externe Referenzpannung via AREF
-MUX4..0 auf 0x1E setzen --> 1,1V Bandgap

Dabei gilt es eigentlich nur zu beachten, dass AVCC immer um +/-0,3V Vcc ist und die AREF irgendwo 1V und AVCC liegt. Der AVCC sollte ja eh über eine Induktivität mit eigenem Entkoppelkondensator an Vcc liegen.
Durch die Auswahl von AVCC als Referenz lässt sich dann auch die Betriebspannung messen. Ist sehr praktisch beim Batteriebetrieb, da es den den Spannungsteiler spart :mrgreen:
Benutzeravatar
Chaoskreator
Beiträge: 943
Registriert: Mo 12. Aug 2013, 20:58
Wohnort: 92xxx

Re: Der AVR-/ARDUINO-Faden

Beitrag von Chaoskreator »

Hallo zusammen,

ich erstelle momentan ein Programm für einen ATTiny85 mit dem avr-gcc 4.8.2 unter Xubuntu 14.04.
ich habe das Problem, dass das DDRB-Register um's Verrecken nicht gesetzt wird. DDRB ist 0, sowohl vor als auch nach dem Ausführen der Funktion.
Ich dachte, solche Anfänger-Probleme hätte ich längst hinter mir. :roll:
Ich habe zum Ausprobieren mal auf 0xFF gesetzt, um das im Disasembly besser erkennen zu können.
Das DDRB-Register hat Adresse 0x17.
Mit Assembler kenne ich mich nicht so gut aus. Wo genau wird da das Register an Adresse 0x17 beschrieben? In der ganzen .lss-Datei finde ich kein "0x17".

Der richtige Controller ist in den Compiler-Flags eingestellt.
#include <avr/io.h> wird inkludiert, sonst würde er ja nicht wissen, was "DDRB" bedeuten soll.
Kompilieren erfolgt ohne Fehler und ohne Warnungen.

Folgender Code

Code: Alles auswählen

inline static void HW_InitIoPins(void)
{
   DDRB =   0xFF;
}
ergibt im Disasembly (die .lss-Datei):

Code: Alles auswählen

inline static void HW_InitIoPins(void)
{
     41c:	cf 93       	push	r28
     41e:	df 93       	push	r29
     420:	cd b7       	in	r28, 0x3d	; 61
     422:	de b7       	in	r29, 0x3e	; 62
   DDRB =   0xFF;
     424:	87 e3       	ldi	r24, 0x37	; 55
     426:	90 e0       	ldi	r25, 0x00	; 0
     428:	2f ef       	ldi	r18, 0xFF	; 255
     42a:	fc 01       	movw	r30, r24
     42c:	20 83       	st	Z, r18
}
     42e:	df 91       	pop	r29
     430:	cf 91       	pop	r28
     432:	08 95       	ret
Matt
Beiträge: 6092
Registriert: So 24. Aug 2014, 21:22

Re: Der AVR-/ARDUINO-Faden

Beitrag von Matt »

ob man lieber nach

Code: Alles auswählen

int main  (void)
{
   DDRB =   0xFF;
}
folgen sollten.. "int main" statt anders..
Ichw eiss nichtmal , wie deine ganze Code aussieht.

Achtung, bin noch eher "leiche" /Anfänger und bastelte mit Arduino Nano, wo ich deren Bootloader abgeschossen habe und INSTA LEDlux RGB plane über Fädeldraht an PWM Output (OCxx) gehängt.. es tut sowie ich erwartet habe.
Benutzeravatar
Fritzler
Beiträge: 12602
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Ich hab meine Antwort mal in dne Code gepackt:

Code: Alles auswählen

424:   87 e3          ldi   r24, 0x37   ; 55		<- 0x37 in RegisterPAAR Laden (lowbyte)
426:   90 e0          ldi   r25, 0x00   ; 0			<- 0x0 in RegisterPAAR Laden (highbyte)
428:   2f ef          ldi   r18, 0xFF   ; 255		<- deine 255 in ein Register packen
42a:   fc 01          movw   r30, r24				<- Registerpaare kopieren (r24 nach r30 und r25 nach r31)
42c:   20 83          st   Z, r18					<- Z Pointerregister ist r31/r30 und die 255 dort hinschreiben
Er schreibt also deine 255 nach 0x37.
Sicher, dasse den tiny85 im makefile angegeben hast und nicht irgendeinen anderen avr?

edit:
upps, hab den Offset vergessen.
Die IOs werden ab Speicheradresse 0x20 eingeblendet.
Also 0x17 + 0x20 = 0x37.
Er schreibt also in DDRB.

Daher ist jetzt die Frage was erwartest du?
Dass jetzt der Pin auf 1 geht?
Dann musste noch PORTB = 255 schreiben.
Benutzeravatar
Chaoskreator
Beiträge: 943
Registriert: Mo 12. Aug 2013, 20:58
Wohnort: 92xxx

Re: Der AVR-/ARDUINO-Faden

Beitrag von Chaoskreator »

Ich erzähle mal die ganze Geschichte.
Ursprünglich hatte ich als Initialisierungscode:

Code: Alles auswählen

inline static void HW_InitIoPins(void)
{
   DDRB =   (1<<PB4) | (1<<PB1);
   PORTB =  (1<<PB2); //Pull-Up
}
Wider Erwarten ließ sich aber mit

Code: Alles auswählen

PORTB |= (1<<PB4);
der Pin PB4 nicht auf HIGH setzen. Er bleibt ständig auf 0 V.

Dann hatte ich im Debugger

Code: Alles auswählen

*(volatile uint8_t *)(0x17)
eingetragen, um die Einstellung im DDRB-Register zu kontrollieren, aber ständig 0 gelesen. Wenn es da ein Offset von 0x20 gibt, erklärt das natürlich warum das so ist.
Ich nutze Code::Blocks als Entwicklungsumgebung. Als Debugger die Kombination gdb und avarice.
Ich habe zwar die Schaltung schon mal kontrolliert. PB4 geht, wie geplant, über 22k auf die Basis eines BC547.
Vielleicht sollte ich das doch nochmal kontrollieren. Nicht dass ich da nicht doch einen Kurzschluss gebaut habe (Lochrasterplatine).
Benutzeravatar
Fritzler
Beiträge: 12602
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Guck mal da: http://www.engbedded.com/fusecalc/ dann tiny85 auswählen
Ausversehen die Clock Output Fuse gesetzt?
Das kommt nämlich an PORTB4 raus und im MHz Bereich misst dein Messgerät garantiert Mist.
Benutzeravatar
Chaoskreator
Beiträge: 943
Registriert: Mo 12. Aug 2013, 20:58
Wohnort: 92xxx

Re: Der AVR-/ARDUINO-Faden

Beitrag von Chaoskreator »

GELÖST!!!!!!!11111einseinseins

Ich hatte das Tiny85-Projekt von einem früheren Projekt kopiert und angepasst. In dem damaligen Projekt nutzte ich eine PWM.
PWM... Na, klingelt's schon? :D

Ein paar Zeilen nach dem Aufruf der Pin-Initialisierungsfunktion wurde folgendes ausgeführt:

Code: Alles auswählen

inline static void HW_InitTimer1ForPwm(void)
{
   TCCR1 = (1<<CS11) | (1<<CS10); //Prescaler PCK/2
   GTCCR =   (1<<PWM1B)   //Pulse Width Modulator B Enable
           | (1<<COM1B1); //Clear the OC1B output line.
}
Natürlich setzt die PWM-Ausgabe den Portpin auf null, weil das OCR-Register null ist.

Falls einer von den µC-Anfängern das liest:
Der Grund für das Problem war, dass ich eine PWM-Ausgabe für den Portpin initialisiert hatte, was ich aber eigentlich nicht wollte!

Die meisten Computer-Probleme sitzen halt doch vor der Tastatur.
*Hirn-->Tisch*

Ich dachte inzwischen schon an einen kaputten Controller. Dieses Wunschdenken, dass es sich um einen Hardware-Defekt handelt, hatte sich aber bei mir noch nie erfüllt. ;)
Matt
Beiträge: 6092
Registriert: So 24. Aug 2014, 21:22

Re: Der AVR-/ARDUINO-Faden

Beitrag von Matt »

klassische Copy&Paste-Fehler..

ist mir auch mal passiert.

Achja, ich erzähle mal eigene blöde Fehler mit AVR..
Ich wollte PWM, OCR1A und OCR1B mit unterschiedliche Werte ansteuern, aber es funktioniert nicht wirklich, als ob OCR1B auf OCR1A einfluss hat. Ich hab daran halbe Stunden rumprobiert...und Registerfunktion verstehen wollen.

Am Ende ist Fehler gefunden, ich habe rote und grüne LED an OC1A/B gehängt, wobei beide LED gemeinsame Widerstand hat (was auch warum bin ich da faul) und LED mit geringere UF leuchtet , also grüne erlischt wieder bzw. dunkelt ab, wenn rote heller aufgesteuert wird..
TDI
Beiträge: 2639
Registriert: Fr 28. Jun 2013, 09:43
Wohnort: plattdeutsches Nordland

Re: Der AVR-/ARDUINO-Faden

Beitrag von TDI »

Moin,

dies ist der Code für einen Arduino, der eine Morsebake steuert. Funktioniert so weit.

Code: Alles auswählen

// include the library code:
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(6, 9, 5, 2, 3, 4);

//Define the LED Pin
#define PIN_OUT        13
//Define unit length in ms
#define UNIT_LENGTH    100

//Build a struct with the morse code mapping
static const struct {const char letter, *code;} MorseMap[] =
{
  { 'A', ".-" },
  { 'B', "-..." },
  { 'C', "-.-." },
  { 'D', "-.." },
  { 'E', "." },
  { 'F', "..-." },
  { 'G', "--." },
  { 'H', "...." },
  { 'I', ".." },
  { 'J', ".---" },
  { 'K', ".-.-" },
  { 'L', ".-.." },
  { 'M', "--" },
  { 'N', "-." },
  { 'O', "---" },
  { 'P', ".--." },
  { 'Q', "--.-" },
  { 'R', ".-." },
  { 'S', "..." },
  { 'T', "-" },
  { 'U', "..-" },
  { 'V', "...-" },
  { 'W', ".--" },
  { 'X', "-..-" },
  { 'Y', "-.--" },
  { 'Z', "--.." },
  { ' ', "     " }, //Gap between word, seven units 
    
  { '1', ".----" },
  { '2', "..---" },
  { '3', "...--" },
  { '4', "....-" },
  { '5', "....." },
  { '6', "-...." },
  { '7', "--..." },
  { '8', "---.." },
  { '9', "----." },
  { '0', "-----" },

  { '/', "–..-." },  
  { '.', ".–.–.–" },
  { ',', "--..--" },
  { '?', "..--.." },
  { '!', "-.-.--" },
  { ':', "---..." },
  { ';', "-.-.-." },
  { '(', "-.--." },
  { ')', "-.--.-" },
  { '"', ".-..-." },
  { '@', ".--.-." },
  { '&', ".-..." },
};

void setup()
{
  pinMode( PIN_OUT, OUTPUT );
  digitalWrite( PIN_OUT, LOW );
  // set up the LCD's number of columns and rows:
  lcd.begin(16, 2);
}

void loop()
{
  // set the cursor to (16,1):
  lcd.setCursor(16, 1);
  // set the display to automatically scroll:
  lcd.autoscroll();
  
  
  
  String morseWord = encode( "MORSEBAKE TEST " );
    
  for(int i=0; i<=morseWord.length(); i++)
  {
    
    switch( morseWord[i] )
    {
      case '.': //dit
        digitalWrite( PIN_OUT, HIGH );
       // tone(8,2500);
        delay( UNIT_LENGTH );
       // noTone(8);
        digitalWrite( PIN_OUT, LOW );
        delay( UNIT_LENGTH );
        break;

      case '-': //dah
        digitalWrite( PIN_OUT, HIGH );
       // tone(8,2500);
        delay( UNIT_LENGTH*3 );
        digitalWrite( PIN_OUT, LOW );
       // noTone(8);
        delay( UNIT_LENGTH );  
        break;

      case ' ': //gap
        delay( UNIT_LENGTH );
    }
    
  }
}

String encode(const char *string)
{
  size_t i, j;
  String morseWord = "";
  
  for( i = 0; string[i]; ++i )
  {
    for( j = 0; j < sizeof MorseMap / sizeof *MorseMap; ++j )
    {
      if( toupper(string[i]) == MorseMap[j].letter )
      {
        morseWord += MorseMap[j].code;
        break;
      }
    }
    morseWord += " "; //Add tailing space to seperate the chars
  }

  return morseWord; 
  
   
}

String decode(String morse)
{
  String msg = "";
  
  int lastPos = 0;
  int pos = morse.indexOf(' ');
  while( lastPos <= morse.lastIndexOf(' ') )
  {    
    for( int i = 0; i < sizeof MorseMap / sizeof *MorseMap; ++i )
    {
      if( morse.substring(lastPos, pos) == MorseMap[i].code )
      {
        msg += MorseMap[i].letter;
               }
    }

    lastPos = pos+1;
    pos = morse.indexOf(' ', lastPos);
    
    // Handle white-spaces between words (7 spaces)
    while( morse[lastPos] == ' ' && morse[pos+1] == ' ' )
    {
      pos ++;
    }
  }
 // turn off automatic scrolling
  lcd.noAutoscroll();

  // clear screen for the next loop:
  // lcd.clear();
  return msg;
}
Jetzt möchte ich den Text zeitgleich auch auf einem LCD-Display ausgeben und zwar so, dass man auf dem Display sieht, welches Zeichen gerade als Morsecode ausgegeben wird. Meine Idee ist, dass in der oberen Zeile ein fester Text steht und in der zweiten Zeile der Text von rechts nach links durchgescrollt wird und in der Mitte des Displays (vielleicht reverse oder im Morsetakt blinkend) das gerade gemorste Zeichen zu sehen ist.

Leider bin ich prog-technisch noch zu grün hinter den Ohren um im Code erkennen zu können, an welcher Stelle ich wie den Buchstaben abgreife, der gerade in Morsecode ausgegeben wird.

Danke für Tips und Hilfe

TDI
Benutzeravatar
Raider
Beiträge: 1121
Registriert: Fr 11. Jul 2014, 16:58
Wohnort: Ellerhoop

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raider »

TDI hat geschrieben:
Leider bin ich prog-technisch noch zu grün hinter den Ohren um im Code erkennen zu können, an welcher Stelle ich wie den Buchstaben abgreife, der gerade in Morsecode ausgegeben wird.

TDI
Das wird relativ schwierig, da du erst den Text in Morsecode umwandelst und dann mit der for schleife ausgibst. Man müsste das so umbauen, dass mit encode immer nur der aktuelle Buchstabe in einer for-Schleife umgewandelt wird. Habe das mal grob skizziert, hoffentlich einigermaßen verständlich. Word ist dein eingabetext. Ob der Code jetzt genauso funktioniert, keine Ahnung :D

Code: Alles auswählen


for(int i=0; i<=word.length(); i++ )
{ 
 String morseCharacter = encode(word[i])
 for(int j=0; j<=morseCharacter.length(); j++ )
  { 
    switch( morseCharacter[j] )
    {
      case '.': //dit
        digitalWrite( PIN_OUT, HIGH );
       // tone(8,2500);
        delay( UNIT_LENGTH );
       // noTone(8);
        digitalWrite( PIN_OUT, LOW );
        delay( UNIT_LENGTH );
        break;

      case '-': //dah
        digitalWrite( PIN_OUT, HIGH );
       // tone(8,2500);
        delay( UNIT_LENGTH*3 );
        digitalWrite( PIN_OUT, LOW );
       // noTone(8);
        delay( UNIT_LENGTH );  
        break;

      case ' ': //gap
        delay( UNIT_LENGTH );
    }
}
  
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Also bei dem Konstrukt mit dem struct und der linearen Suche rollen sich mir die Fußnägel hoch. ;) Zumindest beim Kodieren wäre ein simpler LUT erheblich effizienter und rückwärts zumindest nicht schlechter. Wenn jetzt auf dem AVR die STL verfügbar ist (was ich nicht weiß), wäre das ein Fall für eine map (Hash-table).

Egal, zur eigentlichen Frage: es wäre gar kein Problem, das zu morsende Wort unkodiert zu speichern, erst vor der Sendeschleife encode() aufzurufen und dann den ohnehin mitlaufenden Zeichenzähler als Index in das unkodierte Wort zu nutzen.
Edit: sorry, geht doch nicht so einfach, weil die Zeichen nicht gleich lang sind, man muß also tatsächlich zeichenweise codieren oder jedes Zeichen einzeln als String oder mit Länge ablegen. /Edit
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

Die meisten Arduinos haben einen AT328 mit 5Volt. Für die Analogeingänge sehe ich im Datenblatt "Leckstrom max. 50 nA @ 2,5 Volt" und irgendwas von 100 MegOhm. Anderweitig wird geschrieben, man solle diese mit Quellwiderständen nicht über 10 kOhm betreiben.

Ja was denn nun, wo im Datenblatt finde ich das? Wie hochohmig darf ich den Spannungsteiler auslegen, um einen 12V-Blei zu messen?
Benutzeravatar
xoexlepox
Beiträge: 4815
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Profipruckel hat geschrieben:Anderweitig wird geschrieben, man solle diese mit Quellwiderständen nicht über 10 kOhm betreiben.
Könnte das an dem "Sample and Hold" liegen, was auf einem Kondensator beruht, der an der zu messenden Spannung anliegt, und bei der Messung davon abgeklemmt wird, um während der Digitalisierung einen stabilen Wert zu haben? Wenn dann noch ein Analogmuliplexer vorgeschaltet ist, um ggf. an mehreren Eingänge zu messen, ist es notwendig, diesen Kondensator auf die entsprechende Spannung aufzuladen, bevor die Messung beginnt. Die Auf/Entladung des Kondensators dauert aufgrund des Quellwiderstands natürlich ein wenig... -> Wenn du nur eine (sich sehr langsam ändernde) Spannung messen willst, ist der hochohmige Wert ok, aber wenn du möchtest, daß ein paar µs nach der Umschaltung des Eingangs die korrekte Spannung ansteht, brauchst du natürlich "etwas mehr Dampf" aus der Quelle ;)

Edith meint: Die genaue Beschreibung (und entsprechende Formeln zur Berechnung der "Wartezeit") solltest du im Bereich "A/D-Wandler" in Datenblatt des Chips finden. Zumindest bei den PICs ist das so.
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

xoexlepox hat geschrieben:
Profipruckel hat geschrieben:Anderweitig wird geschrieben, man solle diese mit Quellwiderständen nicht über 10 kOhm betreiben.
Könnte das an dem "Sample and Hold" liegen, was auf einem Kondensator beruht, ..
Danke für Deine (einzige) Antwort - ich habe das im Datenblatt gefunden, auf Seite 244 von 650:

"When the channel is selected, the source must drive the S/H capacitor through the series resistance (combined resistance in the input path).
The ADC is optimized for analog signals with an output impedance of approximately 10 k? or less. If such a source is used, the sampling time will be negligible. If a source with higher impedance is used, the sampling time will depend on how long time the source needs to charge the S/H capacitor, with can vary widely. The user is recommended to only use low impedance sources with slowly varying signals, since this minimizes the required charge transfer to the S/H capacitor."


Im zugehörigen Prinzipschaltbild sehe ich 14 pF.
Wenn du nur eine (sich sehr langsam ändernde) Spannung messen willst, ist der hochohmige Wert ok, aber wenn du möchtest, daß ein paar µs nach der Umschaltung des Eingangs die korrekte Spannung ansteht,
Ich weiß nicht, wie sich die Arduino-Umgebung da verhält bzw. was hinter "analogRead" stattfindet. Einen Zugriff auf die Wandlungszeit oder das Ready-Bit sehe ich dort nicht.

An anderer Stelle habe ich etwas gefunden, was mir schlüssig scheint: Bei hochohmigem Teiler einen Kondensator drauf, damit der AVR zügig messen kann.

Ich hatte es nicht geschrieben: Ich will alle x Minuten die Spannung eines Akkus messen, ohne deutlich zu dessen Entladung beizutragen, habe also Zeit.
Benutzeravatar
Fritzler
Beiträge: 12602
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Da hilft aber nicht hochohmig, sondern den Spannungsteiler über nen PFET abklemmen wenn der nicht gebraucht wird.

Zu dem Arduino analogread Mumpitz sag ich jetz mal nix... (natürlich haben die daran nicht gedacht)
Benutzeravatar
BMS
Beiträge: 220
Registriert: Di 13. Aug 2013, 10:56

Re: Der AVR-/ARDUINO-Faden

Beitrag von BMS »

Oder hochohmig + Kondensator vom ADC Eingang nach GND. Oder CD4066 als Analogschalter.
Vor kurzem im Roboternetz
(bin dort auch als BMS unterwegs)
Grüße, Bernhard
Benutzeravatar
xoexlepox
Beiträge: 4815
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Profipruckel hat geschrieben:Einen Zugriff auf die Wandlungszeit oder das Ready-Bit sehe ich dort nicht.
Hmmm, ich habe mich bisher nur recht oberflächlich mit den ATMELs beschäftigt (und die Arduino-Libs sofort "abgeklemmt") , gehe aber mal davon aus, daß du die Funtion des "AnalogRead" auch "zu Fuß" (mit Zugriffen auf die Registerbits) realisieren kannst. Beim PIC gibt es nur ein Bit, welches beim Start der A/D-Wandlung gesetzt wird, und beim Ende der Wandlung wieder gelöscht wird (und ggf. einen Interrupt auslöst). Wie lange es dauert, den S&H-Kondensator zu laden, "weiss" die Hardware natürlich nicht ;)
Bei hochohmigem Teiler einen Kondensator drauf, damit der AVR zügig messen kann.
Das könnte bei der Umschaltung von A/D-Eingängen nützlich sein, aber der externe Kondensator muss natürlich auch von der hochohmigen Quelle auf die korrekte Spannung gebracht werden ;)
Ich will alle x Minuten die Spannung eines Akkus messen, ohne deutlich zu dessen Entladung beizutragen, habe also Zeit.
Wenn du keine anderen Analogeingänge verwendest, und somit den Analogmultiplexer nicht verwendest, kannst du es m.E. durchaus hochohmig belassen.
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

Fritzler hat geschrieben:Da hilft aber nicht hochohmig, sondern den Spannungsteiler über nen PFET abklemmen wenn der nicht gebraucht wird.
In meinem ursprünglichen Entwurf habe ich das so. Es ist eine Rechenaufgabe: mA nur für die Messung oder µA dauerhaft.
Zu dem Arduino analogread Mumpitz sag ich jetz mal nix... (natürlich haben die daran nicht gedacht)
"Arduino analogread" habe ich nicht wirklich verstanden. In meiner Lötstation werfe ich den ersten Meßwert weg, weil der sporadisch grob falsch ist. Dann hole ich mir zehn weitere im Abstand von je einer ms und rechne den Mittelwert - passt.
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

BMS hat geschrieben:Oder hochohmig + Kondensator vom ADC Eingang nach GND. Oder CD4066 als Analogschalter.
Vor kurzem im Roboternetz
(bin dort auch als BMS unterwegs)
Grüße, Bernhard
Na ja, auch das Roboternetz macht mich nicht erheblich schlauer. Mit Deinem Beitrag 21.07.2016, 16:29 bringst Du den großen Kondensator ins Spiel, eine klare Aussage zum Meßfehler sehe ich aber auch dort nicht.

Ich denke, ich werde einen niederohmigen Teiler verwenden und schalten - für ein Einzelstück kann ich die zusätzlichen Bauteilekosten gerade noch aufbringen.

Ach ja, Edit: Einen 4066 werde ich mir für einen Kanal nicht antun, eher ein PhotoMos-Relay, die habe ich im Dutzend da.
xanakind
Beiträge: 12617
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

Ich bin gerade dabei mir für´s Auto eine neue Steuerung der Sitzheizung(und andere Dinge...) zu basteln.....
die Originale Sitzheizung kann nur Volle Kanne die Eier grillen oder aus.
Darum kommen andere Schalter mit Potis aus einem Opel rein.

Klappt auch alles wunderbar, hat jedoch einen Haken:

Stehen die Regler auf kleinster Stufe, bekommt die CPU (Arduino Nano) 5 Volt.
auf der höchsten Stufe dann entsprechend nurnoch 1 Volt.

Gibt s eine einfache Möglichkeit den eingelesen Analogen Wert der beiden Potis zu negieren?

Achso: Hier der Hochkomplizierte Programmabschnitt:

Code: Alles auswählen

//Sitzheizung_rechts
  if (digitalRead(sitz_rechts_on)){
  val = analogRead (sitz_rechts_out);
  analogWrite (sitz_rechts, val /4);
  }else{
    digitalWrite(sitz_rechts, LOW);
Vielleicht kann mir da wer weiterhelfen? :)
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

Code: Alles auswählen

val=1034-val;
So zum Beispiel?
Dann gibts bei 0V 1034 als Wert und bei 5V 0.
xanakind
Beiträge: 12617
Registriert: So 11. Aug 2013, 21:55

Re: Der AVR-/ARDUINO-Faden

Beitrag von xanakind »

Vielen lieben Dank!
läuft! :D
jetzt muss ich nurnoch rausfinden, warum auf der letzten Stufe wieder etwas weniger Leistung rauskommt.....
vielleicht machen die Opelschalter intern irgend einen Murks.....mal schauen.
Benutzeravatar
Sven
Beiträge: 4423
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sven »

Wie kommst du auf 1034?
Der AD Wandler hat doch 10 Bit, damit sollte 1023 der Maximalwert sein ;)
Antworten