Der AVR-/ARDUINO-Faden
Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese
- Weisskeinen
- Beiträge: 3948
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Vielleicht könnte man das auch mit einem SPI-Temperatursensor machen. SPI an sich geht auch gggaaaaannnnzzzzz lllllaaaannnngggsssaaammmm und damit über längere Leitungen, vorausgesetzt, der ADC braucht den SPI-Takt nicht zur Wandlung.
Re: Der AVR-/ARDUINO-Faden
Ginge vielleicht ein WLAN-Kabel mit ESP8266 oder ESP32?
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Takt =/= Flankensteilheit
-> RS422
-> RS422
- Weisskeinen
- Beiträge: 3948
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Einige ICs sind da echt hart im nehmen...
- Raja_Kentut
- Beiträge: 1554
- Registriert: Mi 14. Aug 2013, 13:11
- Wohnort: Veitsbronn-Bernbach
Re: Der AVR-/ARDUINO-Faden
geht alles, aber ich will möglichst wenig rumlöten/programmieren... SPI ist an sich keine schlechte Idee, aber da sind fertige Shields wohl auch selten/teuer. Hab jedenfalls nix gefunden...
Da meine Programmierkenntnisse nahe Fußpilzniveau angesiedelt sind :
Ließe sich beim Adruino der I2C langsamer einstellen ? (Wenn ja, wie?)
Das SHT31 Datenblatt hat da nix gegen : " The clock frequency can be freely chosen between 0 to 1000 kHz"
Da meine Programmierkenntnisse nahe Fußpilzniveau angesiedelt sind :
Ließe sich beim Adruino der I2C langsamer einstellen ? (Wenn ja, wie?)
Das SHT31 Datenblatt hat da nix gegen : " The clock frequency can be freely chosen between 0 to 1000 kHz"
- Weisskeinen
- Beiträge: 3948
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Da steht was dazu: https://forum.arduino.cc/index.php?topic=159855.0Raja_Kentut hat geschrieben:geht alles, aber ich will möglichst wenig rumlöten/programmieren... SPI ist an sich keine schlechte Idee, aber da sind fertige Shields wohl auch selten/teuer. Hab jedenfalls nix gefunden...
Da meine Programmierkenntnisse nahe Fußpilzniveau angesiedelt sind :
Ließe sich beim Adruino der I2C langsamer einstellen ? (Wenn ja, wie?)
Das SHT31 Datenblatt hat da nix gegen : " The clock frequency can be freely chosen between 0 to 1000 kHz"
- Raja_Kentut
- Beiträge: 1554
- Registriert: Mi 14. Aug 2013, 13:11
- Wohnort: Veitsbronn-Bernbach
Re: Der AVR-/ARDUINO-Faden
danke für den Link ins Arduino Forum!
im post #12 steht das "in the Wire library" einen entsprechenden Wert gibt:
"The speed of 100kHz is fixed in the Wire library, and it is used in the Wire.begin() function. It is passed to the twi.c file which sets the TWBR register.
The TWBR register can be set faster and slower.
It is a 8-bits register and it is default 72.
The value of 72 makes it easy to change the speed without the need to change the prescaler.
A value of 255 makes it three and a half times slower.
A value of 18 makes it four times faster.
"
heißt das, das ich in meinem Programm an richtiger Stelle " TWBR = 255;" einfügen kann und gut ist ? (255 entspräche ca. 28kHz)
Wo wäre dann diese Stelle, etwa hier ? :
Mein Programm :
#include <Arduino.h>
#include <Wire.h>
#include "Adafruit_SHT31.h"
float ttp = 0; // RK : Definition Variable für Taupunkt
int LED_Fan = 4; // RK : Pin4 heisst LED_Fan und schaltet LED Lüfterbetrieb an/aus
TWBR = 255; // RK : WÄRE HIER der richtige Platz um das I2C Speed Register zu verändern ?
Adafruit_SHT31 sht31 = Adafruit_SHT31();
void setup() {
Serial.begin(9600);
// while (!Serial)
// delay(10); // will pause Zero, Leonardo, etc until serial console opens
Serial.println("SHT31 test");
if (! sht31.begin(0x44)) { // Set to 0x45 for alternate i2c addr
Serial.println("Couldn't find SHT31");
while (1) delay(1);
}
pinMode(LED_Fan, OUTPUT); //RK : PIN4 als Output = Schaltausgang LED Lüfterbetrieb
digitalWrite (LED_Fan, LOW); // RK : Bei Programmstart LED Lüfterbetrieb aus
}
void loop() {
float t = sht31.readTemperature();
float h = sht31.readHumidity();
ttp = t - (100-h)/5; // RK: Berechnung Taupunkt
if (! isnan(t)) { // check if 'is not a number'
Serial.print("Temp *C = "); Serial.println(t);
} else {
Serial.println("Failed to read temperature");
}
if (! isnan(h)) { // check if 'is not a number'
Serial.print("Hum. % = "); Serial.println(h);
Serial.print("Taupkt *C = "); Serial.println(ttp); // RK:Ausgabe Taupunkttemperatur
} else {
Serial.println("Failed to read humidity");
}
Serial.println();
if (ttp < 15) { // RK :Wenn Taupunkttemperatur <15 Grad C LED Lüfterbetrieb an
digitalWrite (LED_Fan, HIGH);}
else if (h < 35) {digitalWrite (LED_Fan, HIGH);} // Bei h<50% wird Formel zu ungenau -> ttp wird zu hoch berechnet
else {digitalWrite (LED_Fan, LOW);} //Wenn h<35 steigt ttp nie über 12,9°C bei t<30°C
delay(10000);
}
float ttp = 0; // RK : Definition Variable für Taupunkt
int LED_Fan = 4; // RK : Pin4 heisst LED_Fan und schaltet LED Lüfterbetrieb an/aus
Adafruit_SHT31 sht31 = Adafruit_SHT31();
void setup() {
Serial.begin(9600);
Serial.println("SHT31 test");
if (! sht31.begin(0x44)) { // Set to 0x45 for alternate i2c addr
Serial.println("Couldn't find SHT31");
while (1) delay(1);
}
pinMode(LED_Fan, OUTPUT); //RK : PIN4 als Output = Schaltausgang LED Lüfterbetrieb
digitalWrite (LED_Fan, LOW); // RK : Bei Programmstart LED Lüfterbetrieb aus
}
void loop() {
float t = sht31.readTemperature();
float h = sht31.readHumidity();
ttp = t - (100-h)/5; // RK: Berechnung Taupunkt
if (! isnan(t)) { // check if 'is not a number'
Serial.print("Temp *C = "); Serial.println(t);
} else {
Serial.println("Failed to read temperature");
}
if (! isnan(h)) { // check if 'is not a number'
Serial.print("Hum. % = "); Serial.println(h);
Serial.print("Taupkt *C = "); Serial.println(ttp); // RK:Ausgabe Taupunkttemperatur
} else {
Serial.println("Failed to read humidity");
}
Serial.println();
if (ttp < 15) { // RK :Wenn Taupunkttemperatur <15 Grad C LED Lüfterbetrieb an
digitalWrite (LED_Fan, HIGH);}
else if (h < 35) {digitalWrite (LED_Fan, HIGH);} // Bei h<50% wird Formel zu ungenau -> ttp wird zu hoch berechnet
else {digitalWrite (LED_Fan, LOW);} //Wenn h<35 steigt ttp nie über 12,9°C bei t<30°C
delay(10000);
}
(Bitte nicht antworten "probiers doch aus" - kann ich gerade nicht, warte noch auf DHL fürn neuen Leonardo...)
im post #12 steht das "in the Wire library" einen entsprechenden Wert gibt:
"The speed of 100kHz is fixed in the Wire library, and it is used in the Wire.begin() function. It is passed to the twi.c file which sets the TWBR register.
The TWBR register can be set faster and slower.
It is a 8-bits register and it is default 72.
The value of 72 makes it easy to change the speed without the need to change the prescaler.
A value of 255 makes it three and a half times slower.
A value of 18 makes it four times faster.
"
heißt das, das ich in meinem Programm an richtiger Stelle " TWBR = 255;" einfügen kann und gut ist ? (255 entspräche ca. 28kHz)
Wo wäre dann diese Stelle, etwa hier ? :
Mein Programm :
#include <Arduino.h>
#include <Wire.h>
#include "Adafruit_SHT31.h"
float ttp = 0; // RK : Definition Variable für Taupunkt
int LED_Fan = 4; // RK : Pin4 heisst LED_Fan und schaltet LED Lüfterbetrieb an/aus
TWBR = 255; // RK : WÄRE HIER der richtige Platz um das I2C Speed Register zu verändern ?
Adafruit_SHT31 sht31 = Adafruit_SHT31();
void setup() {
Serial.begin(9600);
// while (!Serial)
// delay(10); // will pause Zero, Leonardo, etc until serial console opens
Serial.println("SHT31 test");
if (! sht31.begin(0x44)) { // Set to 0x45 for alternate i2c addr
Serial.println("Couldn't find SHT31");
while (1) delay(1);
}
pinMode(LED_Fan, OUTPUT); //RK : PIN4 als Output = Schaltausgang LED Lüfterbetrieb
digitalWrite (LED_Fan, LOW); // RK : Bei Programmstart LED Lüfterbetrieb aus
}
void loop() {
float t = sht31.readTemperature();
float h = sht31.readHumidity();
ttp = t - (100-h)/5; // RK: Berechnung Taupunkt
if (! isnan(t)) { // check if 'is not a number'
Serial.print("Temp *C = "); Serial.println(t);
} else {
Serial.println("Failed to read temperature");
}
if (! isnan(h)) { // check if 'is not a number'
Serial.print("Hum. % = "); Serial.println(h);
Serial.print("Taupkt *C = "); Serial.println(ttp); // RK:Ausgabe Taupunkttemperatur
} else {
Serial.println("Failed to read humidity");
}
Serial.println();
if (ttp < 15) { // RK :Wenn Taupunkttemperatur <15 Grad C LED Lüfterbetrieb an
digitalWrite (LED_Fan, HIGH);}
else if (h < 35) {digitalWrite (LED_Fan, HIGH);} // Bei h<50% wird Formel zu ungenau -> ttp wird zu hoch berechnet
else {digitalWrite (LED_Fan, LOW);} //Wenn h<35 steigt ttp nie über 12,9°C bei t<30°C
delay(10000);
}
float ttp = 0; // RK : Definition Variable für Taupunkt
int LED_Fan = 4; // RK : Pin4 heisst LED_Fan und schaltet LED Lüfterbetrieb an/aus
Adafruit_SHT31 sht31 = Adafruit_SHT31();
void setup() {
Serial.begin(9600);
Serial.println("SHT31 test");
if (! sht31.begin(0x44)) { // Set to 0x45 for alternate i2c addr
Serial.println("Couldn't find SHT31");
while (1) delay(1);
}
pinMode(LED_Fan, OUTPUT); //RK : PIN4 als Output = Schaltausgang LED Lüfterbetrieb
digitalWrite (LED_Fan, LOW); // RK : Bei Programmstart LED Lüfterbetrieb aus
}
void loop() {
float t = sht31.readTemperature();
float h = sht31.readHumidity();
ttp = t - (100-h)/5; // RK: Berechnung Taupunkt
if (! isnan(t)) { // check if 'is not a number'
Serial.print("Temp *C = "); Serial.println(t);
} else {
Serial.println("Failed to read temperature");
}
if (! isnan(h)) { // check if 'is not a number'
Serial.print("Hum. % = "); Serial.println(h);
Serial.print("Taupkt *C = "); Serial.println(ttp); // RK:Ausgabe Taupunkttemperatur
} else {
Serial.println("Failed to read humidity");
}
Serial.println();
if (ttp < 15) { // RK :Wenn Taupunkttemperatur <15 Grad C LED Lüfterbetrieb an
digitalWrite (LED_Fan, HIGH);}
else if (h < 35) {digitalWrite (LED_Fan, HIGH);} // Bei h<50% wird Formel zu ungenau -> ttp wird zu hoch berechnet
else {digitalWrite (LED_Fan, LOW);} //Wenn h<35 steigt ttp nie über 12,9°C bei t<30°C
delay(10000);
}
(Bitte nicht antworten "probiers doch aus" - kann ich gerade nicht, warte noch auf DHL fürn neuen Leonardo...)
- Raja_Kentut
- Beiträge: 1554
- Registriert: Mi 14. Aug 2013, 13:11
- Wohnort: Veitsbronn-Bernbach
Re: Der AVR-/ARDUINO-Faden
jetzt wird's mathematisch...
Die Sensorik läuft jetzt soweit, hab nen DS1820 Temperatursensor genommen, der zickt auch mim langen Kabel nicht rum.
Ich möchte jetzt den Taupunkt genauer und über einen weiten Temperaturbereich bestimmen und hab ne Formel gefunden,
die recht gute Ergebisse von -20 … +40°C und 20...100%RH liefert (http://www.loxwiki.eu)
Im EXEL funzt das perfekt, der Arduino rechnet aber was völlig falsches aus. Unten der Ausschnitt aus meinem Programm.
Ich vermute, das es mit der laaangen Formel zu tun hat. (bin froh das ich soweit gekommen bin, hab leider keine Ahnung vom "richtigen" Programmieren)
Frage : Wie muß ich die Formel programmieren, damit das Ergebnis stimmt ?
/SCHNIPP/
ttp = 243,12*((17,62*t)/(243,12+t)+log(h/100))/((17,62*243,12)/(243,12+t)-log(h/100)); // Näherungsformel für Gesamtbereich
// ttp = 243,12*((17,62*T)/(243,12+T)+LN(RH/100))/((17,62*243,12)/(243,12+T)-LN(RH/100)) - so funktionierts in EXEL
/SCHNAPP/
Die Sensorik läuft jetzt soweit, hab nen DS1820 Temperatursensor genommen, der zickt auch mim langen Kabel nicht rum.
Ich möchte jetzt den Taupunkt genauer und über einen weiten Temperaturbereich bestimmen und hab ne Formel gefunden,
die recht gute Ergebisse von -20 … +40°C und 20...100%RH liefert (http://www.loxwiki.eu)
Im EXEL funzt das perfekt, der Arduino rechnet aber was völlig falsches aus. Unten der Ausschnitt aus meinem Programm.
Ich vermute, das es mit der laaangen Formel zu tun hat. (bin froh das ich soweit gekommen bin, hab leider keine Ahnung vom "richtigen" Programmieren)
Frage : Wie muß ich die Formel programmieren, damit das Ergebnis stimmt ?
/SCHNIPP/
ttp = 243,12*((17,62*t)/(243,12+t)+log(h/100))/((17,62*243,12)/(243,12+t)-log(h/100)); // Näherungsformel für Gesamtbereich
// ttp = 243,12*((17,62*T)/(243,12+T)+LN(RH/100))/((17,62*243,12)/(243,12+T)-LN(RH/100)) - so funktionierts in EXEL
/SCHNAPP/
Re: Der AVR-/ARDUINO-Faden
Ist log auf dem Arduino das gleiche wie LN in Excel?
Passen die Datentypen, sprich sind das alle floats?
Mal die Formel in kleinere Stücke zerlegen, das Ergebnis auf dem seriellen Monitor ausgeben und mit Excel vergleichen? So würdest du rausbekommen, welche Teile funktionieren und bei welchen es hakt.
Theoretisch lässt sich eigentlich so auch auf einem Arduino rechnen, einen formellen Fehler kann ich auch nicht finden.
Passen die Datentypen, sprich sind das alle floats?
Mal die Formel in kleinere Stücke zerlegen, das Ergebnis auf dem seriellen Monitor ausgeben und mit Excel vergleichen? So würdest du rausbekommen, welche Teile funktionieren und bei welchen es hakt.
Theoretisch lässt sich eigentlich so auch auf einem Arduino rechnen, einen formellen Fehler kann ich auch nicht finden.
- Raja_Kentut
- Beiträge: 1554
- Registriert: Mi 14. Aug 2013, 13:11
- Wohnort: Veitsbronn-Bernbach
Re: Der AVR-/ARDUINO-Faden
ja, ln(x) heisst bei Arduino log(x) , jedenfalls wenn man dem Arduinoforim trauen darf...
die Variablen sind alle float...
die Variablen sind alle float...
Re: Der AVR-/ARDUINO-Faden
Wundert mich ein wenig, zumindest auf Taschenrechnern ist "ln" in der Regel der Logarithmus zur Basis e (eulersche Zahl) und "log" der Logarithmus zur Basis 10.
Vielleicht stimmt das aber auch.
Die Formel in Teilstücke zerlegen und schauen, bis wohin es klappt?
EDIT:
Das ist aber nicht direkt aus dem Programm rauskopiert, oder?
Kommas sind in der Arduino IDE nämlich Punkte...
Aber das müsste doch dann eigentlich zu einer Fehlermeldung geführt haben.
Vielleicht stimmt das aber auch.
Die Formel in Teilstücke zerlegen und schauen, bis wohin es klappt?
EDIT:
Das ist aber nicht direkt aus dem Programm rauskopiert, oder?
Kommas sind in der Arduino IDE nämlich Punkte...
Aber das müsste doch dann eigentlich zu einer Fehlermeldung geführt haben.
- Raja_Kentut
- Beiträge: 1554
- Registriert: Mi 14. Aug 2013, 13:11
- Wohnort: Veitsbronn-Bernbach
Re: Der AVR-/ARDUINO-Faden
PUNKT STATT KOMMA !!!! Das wars !!!! Daaaaaanke !!!!
gab übrigens keine Fehlermeldung beim Compilieren
gab übrigens keine Fehlermeldung beim Compilieren
- Weisskeinen
- Beiträge: 3948
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Was, echt? Das gibt keine Fehlermeldung? War mir nämlich gleich zu Anfang aufgefallen und ich dachte, du hast das nur schnell abgeschrieben und deshalb Dezimalkommata rein gemacht.
- Bauteiltöter
- Beiträge: 254
- Registriert: So 11. Aug 2013, 17:37
Re: Der AVR-/ARDUINO-Faden
Code: Alles auswählen
torben@igor:~/test$ gcc test.c -Wall -lm
test.c: In function ‘main’:
test.c:6:18: warning: left-hand operand of comma expression has no effect [-Wunused-value]
ttp = 243,12*((17,62*t)/(243,12+t)+log(h/100))/((17,62*243,12)/(243,12+t)-log(h/100)); // Näherungsformel für Gesamtbereich
^
test.c:6:29: warning: left-hand operand of comma expression has no effect [-Wunused-value]
ttp = 243,12*((17,62*t)/(243,12+t)+log(h/100))/((17,62*243,12)/(243,12+t)-log(h/100)); // Näherungsformel für Gesamtbereich
^
test.c:6:52: warning: left-hand operand of comma expression has no effect [-Wunused-value]
ttp = 243,12*((17,62*t)/(243,12+t)+log(h/100))/((17,62*243,12)/(243,12+t)-log(h/100)); // Näherungsformel für Gesamtbereich
^
test.c:6:59: warning: left-hand operand of comma expression has no effect [-Wunused-value]
ttp = 243,12*((17,62*t)/(243,12+t)+log(h/100))/((17,62*243,12)/(243,12+t)-log(h/100)); // Näherungsformel für Gesamtbereich
^
test.c:6:68: warning: left-hand operand of comma expression has no effect [-Wunused-value]
ttp = 243,12*((17,62*t)/(243,12+t)+log(h/100))/((17,62*243,12)/(243,12+t)-log(h/100)); // Näherungsformel für Gesamtbereich
^
test.c:4:16: warning: variable ‘ttp’ set but not used [-Wunused-but-set-variable]
double t=1,h=1,ttp;
kein -Wall = selber Schuld. Zum duzenden mal in diesem Thread.
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Gammelduino bietet das nichtmal an:
https://github.com/arduino/Arduino/issues/4184
Das ist ein Bugreport auf GitHub, dass doch bitte -Wall aktiviert sein soll in der IDE.
Was ist die Antwort?
https://github.com/arduino/Arduino/issues/4184
Das ist ein Bugreport auf GitHub, dass doch bitte -Wall aktiviert sein soll in der IDE.
Was ist die Antwort?
Oder auf Stackoverflow wo das jemand einschalten will:Warnings are unnecessary to the formers and, classes prove, scare them away.
Arduino 1.0.6: How to change compiler flag?
Using the IDE is very difficult to do that.
-
- Beiträge: 271
- Registriert: Di 13. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Hallo Leute
Ich habe einen Arduino Uno mit Datalogger-Shield mit RTC und ein LCD-Shield (1602) mit Keypad.
Alles sehr schön und gut, aber die Bibliotheken für die Ansteuerung dieser Funktionen die ich alle brauchen, führen dazu, dass ich noch 245 Byte von 2k RAM habe. Für die SD-Card brauch man aber angeblich über 512 Byte.
Ich finde diese Bibliotheken sind sehr Ressourcen fressend. Gibt es besser Bibliotheken oder eine andere Lösung? Selber alles zu schreiben, da fehlt mir im Moment das Wissen und die Zeit.
Ziel ist es ein Datalogger, welcher die Daten auf SD-Karte speichert und die Bedienung erfolgt über LCD und Keypad oder USB.
Gruss
Ich habe einen Arduino Uno mit Datalogger-Shield mit RTC und ein LCD-Shield (1602) mit Keypad.
Alles sehr schön und gut, aber die Bibliotheken für die Ansteuerung dieser Funktionen die ich alle brauchen, führen dazu, dass ich noch 245 Byte von 2k RAM habe. Für die SD-Card brauch man aber angeblich über 512 Byte.
Ich finde diese Bibliotheken sind sehr Ressourcen fressend. Gibt es besser Bibliotheken oder eine andere Lösung? Selber alles zu schreiben, da fehlt mir im Moment das Wissen und die Zeit.
Ziel ist es ein Datalogger, welcher die Daten auf SD-Karte speichert und die Bedienung erfolgt über LCD und Keypad oder USB.
Gruss
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Es gibt ja auch nur _EINE_ RTC auf der Welt!
LCD Lib: http://homepage.hispeed.ch/peterfleury/ ... tware.html
LCD Lib: http://homepage.hispeed.ch/peterfleury/ ... tware.html
-
- Beiträge: 271
- Registriert: Di 13. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Hallo FritzerFritzler hat geschrieben:Es gibt ja auch nur _EINE_ RTC auf der Welt!
LCD Lib: http://homepage.hispeed.ch/peterfleury/ ... tware.html
Meine RTC ist eine DS1307. Aber ich glaube kaum dass ich bei der RTC viel RAM einsparen kann.
Eigentlich braucht alleine die Lib <SD.h> schon die Hälfte des RAMs.
Gruss
Re: Der AVR-/ARDUINO-Faden
Doch klar, damit kann man viel sparen. Wenn du i2c ausles-Funktion selber schreibt, der nur nötige Funktion hat.
Ich habe damals Library für DS1307/2321 selber geschrieben, da mir von überladene Biblothek Schnauze habe.
Reine Uhrfunktion mit DS1307 braucht etwa 10byte. (ohne zu prüfen) (I2C Library nicht mitgerechnet)
Diese Code läuft mit P.Fleury I2C Library. Vergiss nicht, Variabel zu definieren. (ist nicht dabei)
PS: zugebenmass schreibe ich meiste Library selber, wenn ich genauer und längere überlegen, ist P.Fleury-Library (UART, LCD, I2C) einzige "fremde" Library.
Für SD1306 habe ich von u8g Library abgeguckt und selber geschrieben. Da ich nie geschafft habe, u8g zum laufen zu bringen.
Ich habe damals Library für DS1307/2321 selber geschrieben, da mir von überladene Biblothek Schnauze habe.
Reine Uhrfunktion mit DS1307 braucht etwa 10byte. (ohne zu prüfen) (I2C Library nicht mitgerechnet)
Diese Code läuft mit P.Fleury I2C Library. Vergiss nicht, Variabel zu definieren. (ist nicht dabei)
Code: Alles auswählen
void getTIME_BCD ()
{
i2c_start(0xD0); // DS2321 Adr =0xD0 auswählen
i2c_write (0x00); // Sekunden-Register auswählen
i2c_rep_start (0xD1); // Lesen-Modus
i2c_readNak(); // auslesen
S1 =(TWDR & 0x0F); // Daten (untere Nibble direkt übertragen)
S10 =((TWDR >>4)&0x07); // Daten ( oberne Nibble übertragen durch 4x nach rechts schieben)
i2c_rep_start (0xD0); // Schreibmodus
i2c_write (0x01); // Minuten-Register auswählen
i2c_rep_start (0xD1); // Lesenmodus
i2c_readNak(); // auslesen
M1 =(TWDR & 0x0F); // Daten (untere Nibble direkt übertragen)
M10 =(TWDR >>4); // Daten ( oberne Nibble übertragen durch 4x nach rechts schieben)
i2c_rep_start (0xD0); // Schreibmodus
i2c_write (0x02); // Stunden-Register auswählen
i2c_rep_start (0xD1); // Lesenmodus
i2c_readNak(); // auslesen
H1 =(TWDR & 0x0F); // Daten (untere Nibble direkt übertragen)
H10 =(TWDR >>4) &0x03; // Daten ( oberne Nibble übertragen durch 4x nach rechts schieben)
i2c_stop();
}
Für SD1306 habe ich von u8g Library abgeguckt und selber geschrieben. Da ich nie geschafft habe, u8g zum laufen zu bringen.
Re: Der AVR-/ARDUINO-Faden
Komisches Fänomen:
Ich hab hier einen AtMega88, dort ist ein Display am SPI PB2,3,4,5 angeschlossen und funktioniert.
Zum Haareraufen: Am PortB Pin1 kommen auch SPI Daten raus.
Ich hab das soweit durchgecheckt, der PB1 wird nirgends weiter getriggert, auch wenn ich den mit PORTB~=(1<<PB1) abschalte kommen die Daten.
ich will aber den OC1A nutzen.
Wie kann da was rauskommen vom SPI ?
Anderer Baustein tut das gleiche und auch wenn der Pin in der Luft hängt kommen da SPI Daten raus.
Ich hab hier einen AtMega88, dort ist ein Display am SPI PB2,3,4,5 angeschlossen und funktioniert.
Zum Haareraufen: Am PortB Pin1 kommen auch SPI Daten raus.
Ich hab das soweit durchgecheckt, der PB1 wird nirgends weiter getriggert, auch wenn ich den mit PORTB~=(1<<PB1) abschalte kommen die Daten.
ich will aber den OC1A nutzen.
Wie kann da was rauskommen vom SPI ?
Anderer Baustein tut das gleiche und auch wenn der Pin in der Luft hängt kommen da SPI Daten raus.
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Also der PB1 steckte zuletzt nicht mehr im Sockel?
Häng PB1 inner Luft hängend doch nochmal auf GND mit 330R.
AVCC hat Spannung?
Ansonsten hast du schon recht und PB1 ist zudem auch nicht direkt neben MOSI, sondern nSS.
Häng PB1 inner Luft hängend doch nochmal auf GND mit 330R.
AVCC hat Spannung?
Ansonsten hast du schon recht und PB1 ist zudem auch nicht direkt neben MOSI, sondern nSS.
Re: Der AVR-/ARDUINO-Faden
Am PB1 hängt normalerweise eine Schaltung dran die leicht gegen GND zieht.
AVCC hat 5V.
Da kann man doch nix falsch machen?
lcd.c Ausschnitt
Hier noch Baustelle:
evtl in der init_devices Scheiße?
main.c
AVCC hat 5V.
Da kann man doch nix falsch machen?
lcd.c Ausschnitt
Code: Alles auswählen
/ SPI - Initialisierung
// ***********************************************************************
void spi_master_init(void) {
DDRB |= (1 << PB3) | (1 << PB5) | (1 << PB2); // MOSI(PB3), SCK(PB5), SS(PB2) (Ausg�nge)
DDRB &= ~(1 << PB4); // MISO(PB4) (Eingang)
PORTB |= (1 << PB4); // MISO(PB4) Pull-Up-R zuschalten
//DDRB |= (1 << PX5); // EN Ausgang
CS_LCD_H; // LCD Disable
// Grundinitialisierung (SPI-Freigabe, Master, LSB-First, Mode 3, Fosz/64)
SPCR = ((1 << SPE) | (1 << MSTR) | (1 << DORD) |(1 << SPR0)| (1 << CPOL)
| (1 << CPHA));
}
Hier noch Baustelle:
evtl in der init_devices Scheiße?
main.c
Code: Alles auswählen
//************************************************************************/
// Projekt Includes
//************************************************************************/
#include "defines.h" // Projektdefinitionen
#include "lcd_dip204ks0073_spi_avr.c" // LCD-Funktionen
#include "ADC_Messung.h"
//************************************************************************/
// AVR/GCC Includes
//************************************************************************/
#include <avr/eeprom.h>
#include <stdbool.h>
#include "main.h"
#include <avr/interrupt.h>
#include <avr/io.h> // IO-Grundfunktionen
#include <util/delay.h> // Pausenfunktionen
#include <string.h> // Stringfunktion
#include <stdio.h> // Standardfunktion
#include <stdlib.h> // Standardbibliothek
//************************************************************************/
//Defines
//************************************************************************/
#define FOSC 8000000 // Clock Speed
#define BAUD 19600
#define MYUBRR FOSC/16/BAUD-1
#define rel1_an PORTD|=(1<<PD5)
#define rel1_aus PORTD &= ~(1<<PD5)
#define rel2_an PORTD|=(1<<PD6)
#define rel2_aus PORTD &= ~(1<<PD6)
#define rel3_an PORTD|=(1<<PD3)
#define rel3_aus PORTD &= ~(1<<PD3)
#define rel4_an PORTD|=(1<<PD4)
#define rel4_aus PORTD &= ~(1<<PD4)
#define out1_an PORTD|=(1<<PD7)
#define out2_aus PORTD &= ~(1<<PD7)
#define out1_an PORTB|=(1<<PD0)
#define out2_aus PORTB &= ~(1<<PD0)
//************************************************************************/
// Variablenbereich
//************************************************************************/
struct lcd_struc lcd; // LCD Datensatz
uint16_t poti1;
uint16_t poti2;
uint16_t poti3;
uint16_t ana1;
uint16_t ana2;
bool sw1;
bool sw2;
bool sw3;
bool motor;
char buffer[6];
void input_d(void)
{
if (PINC&(1<<PC5)){sw1=1;}
else {sw1=0;}
if (PINB&(1<<PB0)){sw2=1;}
else {sw2=0;}
if (PIND&(1<<PD7)){sw3=1;}
else {sw3=0;}
}
//void USART_Init(unsigned int ubrr)
//{
/*Set baud rate */
//UBRR0H = (unsigned char)(ubrr>>8);
//UBRR0L = (unsigned char)ubrr;
//Enable receiver and transmitter */
//UCSR0B = (1<<RXEN0)|(1<<TXEN0);
/* Set frame format: 8data, 2stop bit */
//UCSR0C |= (3<<UCSZ00);
//}
//void USART_Transmit( unsigned char data )
//{
/* Wait for empty transmit buffer*/
//while( !( UCSR0A & (1<<UDRE0)) )
//;
/* Put data into buffer, sends the data*/
//UDR0 = data;
//}
//void uart_puts (char *s)//char s[];
//{
// while (*s)
// { /* so lange *s != '\0' also ungleich dem "String-Endezeichen" */
// //uart_putc(*s);
// USART_Transmit(*s);
// *s++;
// }
// s[0]='\0';
//}
//************************************************************************/
// Devices init
//************************************************************************/
int init_devices(void)
{
cli();
EIMSK|=1<<INT1;
EICRA|=(1<<ISC11)|(1<<ISC10);//INTO einstellen auf steigende Flanke
//TCNT1=0; //Timer auf ca. 2 Sekunden
//TCCR1B|=((1<<CS11)|(1<<CS10)); //Timer anschalten prescaler 20Mhz/64 = 3,2us
spi_master_init(); // Hardware-SPI Initialisierung als Master
init_lcd(); // LCD Initialisierung im SPI-Mode
DDRB |=(1<<PB6)|(1<<PB7)|(1<<PB1);
DDRD |=(1<<PD5)|(1<<PD6)|(1<<PD3)|(1<<PD4)|(1<<PD7);
//DIDR0=0xFF;
//USART_Init(MYUBRR);
DDRC|=(1<<PC3)|(1<<PC4);
DDRC&=~(1<<PC5);
DDRB&=~(1<<PB0);
DDRD&=~(1<<PD7);
PORTC|=(1<<PC5);
PORTB|=(1<<PC0);
PORTD|=(1<<PD7);
sei();
}
// ********************************************************************/
// Hauptprogramm
// ********************************************************************/
int main (void) {
init_devices();
while(1) {
input_d();
poti1=messung(0);
poti2=messung(1);
poti3=messung(2);
ana1=messung(3);
ana2=messung(4);
PORTC&=~(1<<PC4);
PORTB&=~(1<<PB1);
//printf_lcd(0,0," L1 L2 L3",10);
//printf_lcd(0,1,"V:",10);
//printf_lcd(0,2,"A:",10);
//printf_lcd(0,3,"W:",10);
itoa(poti1,buffer,10);
//printf_lcd(2,1,buffer,10);
itoa(poti2,buffer,10);
//printf_lcd(2,2,buffer,10);
itoa(poti3,buffer,10);
printf_lcd(2,3,buffer,10);
PORTC|=(1<<PC4);
}
}
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Ich seh da ersmal nix schlimmes.
Wo hast du die m88 gekauft?
Aber noch was zu deinen defines:
KLAMMERN SETZEN!!!
#define MYUBRR FOSC/16/BAUD-1 -> #define MYUBRR (FOSC/16/BAUD-1)
irgendwann setzt du das vllt inne Formel ein (das weist du jetzt noch nicht) und dann rechnet dir der Compiler vllt was anderes aus.
Das ist ja nur ne Stringersetzung.
Wo hast du die m88 gekauft?
Aber noch was zu deinen defines:
KLAMMERN SETZEN!!!
#define MYUBRR FOSC/16/BAUD-1 -> #define MYUBRR (FOSC/16/BAUD-1)
irgendwann setzt du das vllt inne Formel ein (das weist du jetzt noch nicht) und dann rechnet dir der Compiler vllt was anderes aus.
Das ist ja nur ne Stringersetzung.
Re: Der AVR-/ARDUINO-Faden
Meinst du die p88 habe alle ne Macke? Ich hab 3 getestet.
Das mit den Klammern werd ich mir hoffentlich merken.
Das mit den Klammern werd ich mir hoffentlich merken.
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Mit welchem Dachpappenbrenner hast du DIE Lötstellen denn angelegt?
Aber die sollten ja trotzdem nicht dran Schuld sein wenn ein aus dem Sockel gehobenes Beinchen immernoch was ausgibt.
Also PB1 gibt wirklich dasselbe wie MISO aus?
Das haste auf nem 2 Kanal Oszi gesehen?
Lad doch mal den Code als zip hoch, dann kann ich as heute Abend auf nem m328 testen.
Aber die sollten ja trotzdem nicht dran Schuld sein wenn ein aus dem Sockel gehobenes Beinchen immernoch was ausgibt.
Also PB1 gibt wirklich dasselbe wie MISO aus?
Das haste auf nem 2 Kanal Oszi gesehen?
Lad doch mal den Code als zip hoch, dann kann ich as heute Abend auf nem m328 testen.
Re: Der AVR-/ARDUINO-Faden
Es scheint so das der Linker/Compiler einen Furz quer stecken hatte.
Nachdem ich ein paar mal neu compiliert habe und verschiedene M88/M168 compiliert habe, geht es jetzt.(Anscheinend)
Was da unter der Haube alles schief gehen kann.
Nachdem ich ein paar mal neu compiliert habe und verschiedene M88/M168 compiliert habe, geht es jetzt.(Anscheinend)
Was da unter der Haube alles schief gehen kann.
Re: Der AVR-/ARDUINO-Faden
Mit dem selben mit dem ich die SMD uln2003 aufbrate, wieso?Fritzler hat geschrieben:Mit welchem Dachpappenbrenner hast du DIE Lötstellen denn angelegt?
- Fritzler
- Beiträge: 12597
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Zumindest aus dem fotografierten Blickwinkel sehen die Lötstellen ziemlich Mies aus
Es ist egal, was der Compiler macht, aus PB1 KANN KEIN SPI KOMMEN!!!
Das is ja das total Merkwürdige.
Es ist egal, was der Compiler macht, aus PB1 KANN KEIN SPI KOMMEN!!!
Das is ja das total Merkwürdige.
Bootloader nicht mehr gefunden
Bin am verzweifeln:
Habe Update der Entwicklungsumgebung von 1.8.5 auf 1.8.7 gemacht und seit dem kann ich keine Software mehr flashen.
Habe es mit mehreren Nano-Klonen versucht. Mit Einstellung für alten und neuen Bootloader. Jedesmal meldet der Avrdude out of sync.
Physikalisch ist alles in Ordnung: der serielle Monitor in der IDE zeigt bei bereits programmierten Nanos brav die von mir programmierten Meldungen (auch mit 115200 Baud).
Deinstallieren von 1.8.7 und installieren von 1.8.5 half nicht.
Was ich vor ein paar Tagen gemacht habe: Unterstützung für die Sparkfun (Attiny85) Boards installiert und selbige geflashed. Könnte da ein Zusamenhang sein?
Heute Abend will ich mal einen Logicanalyser an die RX/TX Pins des Nanos klemmen um zu sehen, was da rüber geht.
Weiß jemand, was ich dort sinnvollerweise sehen müsste?
Habe Update der Entwicklungsumgebung von 1.8.5 auf 1.8.7 gemacht und seit dem kann ich keine Software mehr flashen.
Habe es mit mehreren Nano-Klonen versucht. Mit Einstellung für alten und neuen Bootloader. Jedesmal meldet der Avrdude out of sync.
Physikalisch ist alles in Ordnung: der serielle Monitor in der IDE zeigt bei bereits programmierten Nanos brav die von mir programmierten Meldungen (auch mit 115200 Baud).
Deinstallieren von 1.8.7 und installieren von 1.8.5 half nicht.
Was ich vor ein paar Tagen gemacht habe: Unterstützung für die Sparkfun (Attiny85) Boards installiert und selbige geflashed. Könnte da ein Zusamenhang sein?
Heute Abend will ich mal einen Logicanalyser an die RX/TX Pins des Nanos klemmen um zu sehen, was da rüber geht.
Weiß jemand, was ich dort sinnvollerweise sehen müsste?
Re: Der AVR-/ARDUINO-Faden
Hört sich für mich ein wenig nach diesem Problem an https://www.heise.de/make/artikel/Ardui ... 11641.html
Bootloader nicht mehr gefunden
Problem gelöst: Auf beiden Boards scheint der Bootloader platt zu sein. Ein drittes Board lässt sich problemlos flashen.
Falls jemand die IDE unter Debian 18.4 (bionic-beaver) laufen lassen will und auf Probleme mit dem COMM-Treiber stößt:
Mir hat diese Seite geholfen.
Zur Info
Gemessen auf dem Nano: Es werden 2 Bytes empfangen: 0x30 0x20
Bei old bootloader kommen die Daten mit 57600 Bit/s, beim neuen mit 115200 Bit/s
Edit: beim nagelneuen Board war nicht der Bootloader platt, sondern ein AtMega168 statt 328 bestückt. Das konnte ich aber nur unter dem Mikroskop erkennen...
Falls jemand die IDE unter Debian 18.4 (bionic-beaver) laufen lassen will und auf Probleme mit dem COMM-Treiber stößt:
Mir hat diese Seite geholfen.
Zur Info
Gemessen auf dem Nano: Es werden 2 Bytes empfangen: 0x30 0x20
Bei old bootloader kommen die Daten mit 57600 Bit/s, beim neuen mit 115200 Bit/s
Edit: beim nagelneuen Board war nicht der Bootloader platt, sondern ein AtMega168 statt 328 bestückt. Das konnte ich aber nur unter dem Mikroskop erkennen...
Re: Der AVR-/ARDUINO-Faden
Hallo,
folgendes Problem: ich habe ein Arduino Programm welches über die Serielle Schnittstelle
Befehle sendet. Da ich leider mit Arduino überhaupt nix am Hut habe, weiß jemand was hier
bei dem Programmcode gesendet wird?
> Const Progmem Uint16_t St [ ] = { 0x190 , 0x00 , 0xa3 }; < Was ich bis jetzt weis, es ist 9 Bit Protokoll.
Ich hab mit BASCOM jetzt schon so einiges duch aber tut nix.
MfG
Andreas
folgendes Problem: ich habe ein Arduino Programm welches über die Serielle Schnittstelle
Befehle sendet. Da ich leider mit Arduino überhaupt nix am Hut habe, weiß jemand was hier
bei dem Programmcode gesendet wird?
> Const Progmem Uint16_t St [ ] = { 0x190 , 0x00 , 0xa3 }; < Was ich bis jetzt weis, es ist 9 Bit Protokoll.
Ich hab mit BASCOM jetzt schon so einiges duch aber tut nix.
MfG
Andreas
Re: Der AVR-/ARDUINO-Faden
Diese Zeile sendet nix. Die Zeile bewirkt nur, daß drei 16bit-Variablen im RAM reserviert werden, die beim Programmstart mit den angegebenen Werten gefüllt sind.weiß jemand was hier bei dem Programmcode gesendet wird?
> Const Progmem Uint16_t St [ ] = { 0x190 , 0x00 , 0xa3 }; <
Edith meint: Korrekt abgeschrieben? M.E. könnte das Leerzeichen zwischen "St" und den eckigen Klammern zu einer Fehlermeldung des Compilers führen.
Re: Der AVR-/ARDUINO-Faden
Ja danke,
hatte tatsächlich ein Leerzeichen eingefügt, (wegen der Lesbarkeit).
Const Progmem Uint16_t St_minus_10[] = { 0x186 , 0x21 , 0x06 , 0xf9 };
sendDatagram(ST_Minus_10);
Hier ein vergleichbarer Schnipsel der zusammen gehört?
Also Variablen im Ram speichern und dann aber als was gesendet ?
hatte tatsächlich ein Leerzeichen eingefügt, (wegen der Lesbarkeit).
Const Progmem Uint16_t St_minus_10[] = { 0x186 , 0x21 , 0x06 , 0xf9 };
sendDatagram(ST_Minus_10);
Hier ein vergleichbarer Schnipsel der zusammen gehört?
Also Variablen im Ram speichern und dann aber als was gesendet ?
Re: Der AVR-/ARDUINO-Faden
Um das zu beantworten, müsstest du herausfinden, was die Funktion "sendDatagram()" mit den übergebenen Daten macht. Nach meiner Kenntnis ist diese Funktion nicht Bestandteil der Standard-Bibliothek, also müsste sie in dem Programm stehen. Der Code der Funktion müsste mit der ZeileAlso Variablen im Ram speichern und dann aber als was gesendet ?
Code: Alles auswählen
void sendDatagram( Uint16_t * data ) {
Ich sehe gerade: Das "Progmem" in der Zeile mit den Hexziffern bewirkt wohl, daß die Daten nicht im RAM, sondern im Programmspeicher (Flash) abgelegt sind, was jedoch an der Funktionalität wohl nichts ändert.
Re: Der AVR-/ARDUINO-Faden
Danke für deine Ausführung.
Ich werde erst mal das komplette Programm ausdrucken und suchen.
Arduino ist halt leider nicht meine Welt..
MfG
Andreas
Ich werde erst mal das komplette Programm ausdrucken und suchen.
Arduino ist halt leider nicht meine Welt..
MfG
Andreas
Re: Der AVR-/ARDUINO-Faden
Das ändert sehr wohl etwas. Auf den Programmspeicher kann man beim AVR nicht wie auf den SRAM zugreifen.xoexlepox hat geschrieben:Ich sehe gerade: Das "Progmem" in der Zeile mit den Hexziffern bewirkt wohl, daß die Daten nicht im RAM, sondern im Programmspeicher (Flash) abgelegt sind, was jedoch an der Funktionalität wohl nichts ändert.
Man muss die Daten vorher manuell in den SRAM holen. In Assembler macht man das mit der Instruktion LPM.
Wie es bei Arduino aussieht, kann ich leider nicht sagen.
Fraglich ist, ob sendDatagram() eine Adresse im SRAM als Parameter erwartet,
oder eine Adresse im Programmspeicher und dann selber die Daten von dort holt.
Nils
Re: Der AVR-/ARDUINO-Faden
>void sendDatagram(< habe ich nirgends im Programm gefunden.
Könnte das noch woanders vermerkt sein?
Könnte das noch woanders vermerkt sein?
Re: Der AVR-/ARDUINO-Faden
Danke für die hilfreiche Info! Ich mache relativ wenig mit dem AVR, bin meist mit PIC-Assembler unterwegs, und nutze C fast nur auf dem PC. Von daher war die Zeile der Funktionsdefinition auch "reine Schätzung"Auf den Programmspeicher kann man beim AVR nicht wie auf den SRAM zugreifen.
Ja, durchaus... Wie schon oben vermerkt, könnte das "void" auch "int" oder sonstwas sein. Suche einfach nach "sendDatagram(". Falls es wirklich nicht enthalten ist, schau mal, ob das ggf. in einer eingebundenen Headerdatei steckt. Die externen Header werden meist mit einer Zeile im Format "#include <dateiname>" eingebunden, wobei die spitzen Klammern auch Anführungszeichen sein könnten.>void sendDatagram(< habe ich nirgends im Programm gefunden. Könnte das noch woanders vermerkt sein?
Re: Der AVR-/ARDUINO-Faden
Jetzt zeig halt mal her um was für ein Programm es sich handelt!
Mit kleinen Codeausschnitten wird man dir hier kaum weiterhelfen können.
Mit kleinen Codeausschnitten wird man dir hier kaum weiterhelfen können.
Re: Der AVR-/ARDUINO-Faden
Das Arduino Programm habe ich nur als Schnipsel.
Das hier soll auch die Steuercodes erzeugen.
Mit meiner bescheidenen Technik kekomme ich zwar Dezimal das Selbe,aber bei mir
reagier der Empfänger nicht. Es könnte also ein Problem mit dem Timing sein.
Wichtig ist die serielle Übertragung des Steuerbefehls
Danke, MfG
Andreas
Das hier soll auch die Steuercodes erzeugen.
Mit meiner bescheidenen Technik kekomme ich zwar Dezimal das Selbe,aber bei mir
reagier der Empfänger nicht. Es könnte also ein Problem mit dem Timing sein.
Wichtig ist die serielle Übertragung des Steuerbefehls
Danke, MfG
Andreas
Re: Der AVR-/ARDUINO-Faden
Das scheint mit eher ein reines Empfangsprogramm zu sein.Das hier soll auch die Steuercodes erzeugen.
Der Code ist ja grausig! In dem Programm wird sich auf einige Dinge verlassen, auf die sich ein guter Programmierer nicht verlassen sollte: Z.B. daß alle Variablen beim Programmstart auf Null gesetzt sind, was je nach verwendetem Compiler und Modus (->Debug-Code) nicht unbedingt gewährleistet ist. Aber zumindest ist es halbwegs brauchbar dokumentiert.
Bevor ich mich da dran mache, das verwendete Protokoll herauszuklamüsern, wäre es ganz nett zu wissen, wie herum du das einsetzen möchtest: Willst du mit diesem (PC-) Programm etwas empfangen, was der Arduino senden, oder wie soll das laufen?
Was passiert, wenn du die Aussendung des Arduino mit einem "Terminalprogramm" auf dem PC empfängst (4800Bd, Parity enable, 8bit)? Kommt da überhaupt etwas an (ggf. auch irgendwelche Hieroglyphen)?
Edith meint: Nach kurzer Recherche habe ich das hier gefunden. Dort ist das verwendete Protokoll so grob beschrieben. Vielleicht reicht das schon, um die "Kommunikationsstörung" zu finden?
Re: Der AVR-/ARDUINO-Faden
Die Sache ist die:
Der Rechenknecht soll weg.
Ich möchte mit einem Atmega die Einheit ansteuern. Leider kann ich nur Bascom.
Ich würde nur gern wissen wie das Protokoll aussieht.
Sende ich Programmdaten vom Rechner und das Gleiche mit einem Atmega an einen Anderen
sind Dezimal beide Daten gleich. Aber irgendetwas muß ja anders sein.
Mit meinem Timing muß was nicht stimmen.
4800 Baud ,1 Stopbit und 8 Bits haut bei mir der Empfang hin.
Der Rechenknecht soll weg.
Ich möchte mit einem Atmega die Einheit ansteuern. Leider kann ich nur Bascom.
Ich würde nur gern wissen wie das Protokoll aussieht.
Sende ich Programmdaten vom Rechner und das Gleiche mit einem Atmega an einen Anderen
sind Dezimal beide Daten gleich. Aber irgendetwas muß ja anders sein.
Mit meinem Timing muß was nicht stimmen.
4800 Baud ,1 Stopbit und 8 Bits haut bei mir der Empfang hin.
Re: Der AVR-/ARDUINO-Faden
Das findest du auf den von mir verlinkten Seiten (einfach mal alle weiteren Links abklappen). Die von dir angegebene Sequenz "0x190 , 0x00 , 0xa3" bedeutet damit "0x100 + 0x90" -> Command 'Device ID' (0x100 -> Command, 0x90 -> Command code)", "0x00" -> kein weiteres Datenbyte als die drei Pflichtbytes, "0xa3" -> Daten (steht für "send by NMEA"). Und die Sequenz "0x186 , 0x21 , 0x06 , 0xf9" bedeutet: "0x186" -> "Command 'Key stroke'", "0x21" -> ein weiteres Datenbyte, und die beiden Datenbytes "0x06" und "0xf9" stehen für "-10".Ich würde nur gern wissen wie das Protokoll aussieht.
Ich vermute eher, das könnte am fehlenden Paritybit liegen, denn das gesetzte neunte Bit signalisiert ja in dem Protokoll ein "Commandbyte". Wie man es jedoch hinbekommt, den Arduino in Bascom zu überreden, neun Bits zu senden, das kann ich dir nicht sagen, denn ich habe keine Ahnung von Bascom Notfalls musst du "zu Fuß" auf den USART-Registern des Atmel-Chips "herumtrommeln". Welche Bits in welchen Registern dafür notwendig sind, findest du im Datenblatt des Chips.Mit meinem Timing muß was nicht stimmen.
4800 Baud ,1 Stopbit und 8 Bits haut bei mir der Empfang hin.
Re: Der AVR-/ARDUINO-Faden
Puh,
zuerst mal danke das du dir so viel Mühe gegeben hast. Das ist Bitschubsen für Fortgeschrittene.
Ich lese mich nochmal in die Thematik ein, könnte aber ein schnelles Ende nehmen.
MfG
Andreas
zuerst mal danke das du dir so viel Mühe gegeben hast. Das ist Bitschubsen für Fortgeschrittene.
Ich lese mich nochmal in die Thematik ein, könnte aber ein schnelles Ende nehmen.
MfG
Andreas
- Weisskeinen
- Beiträge: 3948
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Das gibt man bei der Konfiguration mit an, ob man keine, gerade oder ungerade Parity haben möchte.xoexlepox hat geschrieben:Ich vermute eher, das könnte am fehlenden Paritybit liegen, denn das gesetzte neunte Bit signalisiert ja in dem Protokoll ein "Commandbyte". Wie man es jedoch hinbekommt, den Arduino in Bascom zu überreden, neun Bits zu senden, das kann ich dir nicht sagen
Code: Alles auswählen
Serout S , 0 , D , 1 , Mybaud , 0 , 8 , 1
' ^ 1 stop bit
' ^---- 8 data bits
' ^------ even parity (0=N, 1 = E, 2=O)
' ^-------------- baud rate
' ^-------------------- pin number
' ^----------------------- port so PORTA.0 and PORTA.1 are used
' ^--------------------------- for strings pass 0
' ^-------------------------------- variable
Re: Der AVR-/ARDUINO-Faden
"Serout" hört sich sehr nach "Senden eines einzelnen Bytes/Strings" an, d.h. man könnte die Konfiguration "pro Byte" ändern? Das wäre zwar etwas "Bitgeschubse", für jedes Byte auszurechnen, ob nun das Parity-Bit "Odd" oder "Even" sein muss, um es auf "0" oder "1" zu setzen, aber sicher auch ein möglicher Weg.Das gibt man bei der Konfiguration mit an, ob man keine, gerade oder ungerade Parity haben möchte.
- Weisskeinen
- Beiträge: 3948
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Ich kenne kein Bascom, das sah aber nach Konfiguration der seriellen Schnittstelle aus. Die Atmel-Controller können das nach Konfiguration komplett selbst in Hardware machen, zum Senden schreibt man nur das entsprechende Byte ins Register und der AVR kümmert sich um den Rest. Beim Empfangen ist das ähnlich, dass man das empfangene Byte einfach aus dem entsprechenden Register abholt.
Die Parity-Berechnung geschieht auch hardwaremäßig, aber man muss angeben, ob das Bit für Odd-Parity (ungerade Bitanzahl) oder Even-Parity (gerade Bitanzahl) berechnet sein soll.
Natürlich kannst du die Konfiguration für jedes Byte ändern, nur sinnvoll ist das nicht, der Empfänger muss ja mit den gleichen Einstellungen laufen. Also ein Mal festlegen und das war's dann.
Edit: Ich sehe gerade, dass das Parity-Bit als Command-Bit missbraucht wird. Hmmm, ja, dann muss man wohl die Schnittstelle ständig umkonfigurieren, je nach dem, was man braucht. Und selbst die Anzahl der Bits zählen, die im eigentlichen Commandbyte drin sind.
Die Parity-Berechnung geschieht auch hardwaremäßig, aber man muss angeben, ob das Bit für Odd-Parity (ungerade Bitanzahl) oder Even-Parity (gerade Bitanzahl) berechnet sein soll.
Natürlich kannst du die Konfiguration für jedes Byte ändern, nur sinnvoll ist das nicht, der Empfänger muss ja mit den gleichen Einstellungen laufen. Also ein Mal festlegen und das war's dann.
Edit: Ich sehe gerade, dass das Parity-Bit als Command-Bit missbraucht wird. Hmmm, ja, dann muss man wohl die Schnittstelle ständig umkonfigurieren, je nach dem, was man braucht. Und selbst die Anzahl der Bits zählen, die im eigentlichen Commandbyte drin sind.
Re: Der AVR-/ARDUINO-Faden
Das ist ja das Gemeine an diesem Protokoll Aber wenn ich das Datenblatt vom Atmel richtig interpretiert habe, kann man (durch direktes "Getrommel" auf den Registern) auch 9Bit senden, und damit das Parity-Bit selber bestimmen. Eine andere Variante wäre, die anstehenden Bits in einem Timer-Interrupt selber einzeln "herauszuschießen". Nur ob man in Bascom auch Interrupt-Funktionen schreiben kann (und ob es dafür schnell genug ist), ist mir nicht bekannt.Ich sehe gerade, dass das Parity-Bit als Command-Bit missbraucht wird.