Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

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

Benutzeravatar
Weisskeinen
Beiträge: 3943
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

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.
Benutzeravatar
Sunset
Beiträge: 1498
Registriert: Fr 6. Dez 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sunset »

Ginge vielleicht ein WLAN-Kabel mit ESP8266 oder ESP32?
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Takt =/= Flankensteilheit
-> RS422
Benutzeravatar
Weisskeinen
Beiträge: 3943
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Einige ICs sind da echt hart im nehmen...
Benutzeravatar
Raja_Kentut
Beiträge: 1528
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

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"
Benutzeravatar
Weisskeinen
Beiträge: 3943
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Raja_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"
Da steht was dazu: https://forum.arduino.cc/index.php?topic=159855.0
Benutzeravatar
Raja_Kentut
Beiträge: 1528
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

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...)
Benutzeravatar
Raja_Kentut
Beiträge: 1528
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

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/
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

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.
Benutzeravatar
Raja_Kentut
Beiträge: 1528
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

ja, ln(x) heisst bei Arduino log(x) , jedenfalls wenn man dem Arduinoforim trauen darf...

die Variablen sind alle float...
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

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.
Benutzeravatar
Raja_Kentut
Beiträge: 1528
Registriert: Mi 14. Aug 2013, 13:11
Wohnort: Veitsbronn-Bernbach

Re: Der AVR-/ARDUINO-Faden

Beitrag von Raja_Kentut »

PUNKT STATT KOMMA !!!! Das wars !!!! Daaaaaanke !!!!
gab übrigens keine Fehlermeldung beim Compilieren
Benutzeravatar
Weisskeinen
Beiträge: 3943
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

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.
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

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;
:roll:

kein -Wall = selber Schuld. Zum duzenden mal in diesem Thread.
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

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?
Warnings are unnecessary to the formers and, classes prove, scare them away.
Oder auf Stackoverflow wo das jemand einschalten will:
Arduino 1.0.6: How to change compiler flag?
Using the IDE is very difficult to do that.
Bild
Fischjoghurt
Beiträge: 271
Registriert: Di 13. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fischjoghurt »

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
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Es gibt ja auch nur _EINE_ RTC auf der Welt!

LCD Lib: http://homepage.hispeed.ch/peterfleury/ ... tware.html
Fischjoghurt
Beiträge: 271
Registriert: Di 13. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fischjoghurt »

Fritzler hat geschrieben:Es gibt ja auch nur _EINE_ RTC auf der Welt!

LCD Lib: http://homepage.hispeed.ch/peterfleury/ ... tware.html
Hallo Fritzer

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
Matt
Beiträge: 6084
Registriert: So 24. Aug 2014, 21:22

Re: Der AVR-/ARDUINO-Faden

Beitrag von Matt »

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)

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();
}		
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.
Benutzeravatar
Hightech
Beiträge: 11307
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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.
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

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.
Benutzeravatar
Hightech
Beiträge: 11307
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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

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);

    }
}

Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

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.
Benutzeravatar
Hightech
Beiträge: 11307
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Meinst du die p88 habe alle ne Macke? Ich hab 3 getestet.
Das mit den Klammern werd ich mir hoffentlich merken.
Benutzeravatar
Hightech
Beiträge: 11307
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

AtM88 als Ersatz für den Zero-Pi:

Warum sollte da was nicht funktionieren:
Bild
Bild

Irgendwann will man nur noch das es Läuft, egal wie es aussieht.
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

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.
Benutzeravatar
Hightech
Beiträge: 11307
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

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.
Benutzeravatar
Hightech
Beiträge: 11307
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Fritzler hat geschrieben:Mit welchem Dachpappenbrenner hast du DIE Lötstellen denn angelegt?
Mit dem selben mit dem ich die SMD uln2003 aufbrate, wieso?
Benutzeravatar
Fritzler
Beiträge: 12579
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

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.
Benutzeravatar
Zabex
Beiträge: 632
Registriert: Di 2. Jul 2013, 08:45
Wohnort: Aldenhoven
Kontaktdaten:

Bootloader nicht mehr gefunden

Beitrag von Zabex »

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?
Benutzeravatar
Sterne
Beiträge: 1044
Registriert: Fr 28. Jun 2013, 10:30
Wohnort: Frickelkommando Nordwest

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sterne »

Hört sich für mich ein wenig nach diesem Problem an https://www.heise.de/make/artikel/Ardui ... 11641.html
Benutzeravatar
Zabex
Beiträge: 632
Registriert: Di 2. Jul 2013, 08:45
Wohnort: Aldenhoven
Kontaktdaten:

Bootloader nicht mehr gefunden

Beitrag von Zabex »

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...
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

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
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

weiß jemand was hier bei dem Programmcode gesendet wird?
> Const Progmem Uint16_t St [ ] = { 0x190 , 0x00 , 0xa3 }; <
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.

Edith meint: Korrekt abgeschrieben? M.E. könnte das Leerzeichen zwischen "St" und den eckigen Klammern zu einer Fehlermeldung des Compilers führen.
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

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 ?
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Also Variablen im Ram speichern und dann aber als was gesendet ?
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 Zeile

Code: Alles auswählen

void sendDatagram( Uint16_t * data ) {
(oder so ähnlich) beginnen. Der Code der Funktion beginnt nach dem "{" in der angegebenen Zeile, und endet mit der entsprechenden schließenden Klammer.

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.
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

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
Benutzeravatar
NilsH
Beiträge: 130
Registriert: Mo 12. Aug 2013, 22:50
Wohnort: Berlin
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von NilsH »

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.
Das ändert sehr wohl etwas. Auf den Programmspeicher kann man beim AVR nicht wie auf den SRAM zugreifen.
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
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

>void sendDatagram(< habe ich nirgends im Programm gefunden.
Könnte das noch woanders vermerkt sein?
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Auf den Programmspeicher kann man beim AVR nicht wie auf den SRAM zugreifen.
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" ;)
>void sendDatagram(< habe ich nirgends im Programm gefunden. Könnte das noch woanders vermerkt sein?
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.
IPv6
Beiträge: 2166
Registriert: Fr 17. Mär 2017, 22:05

Re: Der AVR-/ARDUINO-Faden

Beitrag von IPv6 »

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.
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

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.
seatalk_in_c.txt
(2.46 KiB) 91-mal heruntergeladen
Wichtig ist die serielle Übertragung des Steuerbefehls

Danke, MfG
Andreas
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Das hier soll auch die Steuercodes erzeugen.
Das scheint mit eher ein reines Empfangsprogramm zu sein.

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?
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

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.
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Ich würde nur gern wissen wie das Protokoll aussieht.
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".
Mit meinem Timing muß was nicht stimmen.
4800 Baud ,1 Stopbit und 8 Bits haut bei mir der Empfang hin.
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.
Mirqua
Beiträge: 652
Registriert: Mo 12. Aug 2013, 08:53
Wohnort: nördl. von Berlin

Re: Der AVR-/ARDUINO-Faden

Beitrag von Mirqua »

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
Benutzeravatar
Weisskeinen
Beiträge: 3943
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

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
Das gibt man bei der Konfiguration mit an, ob man keine, gerade oder ungerade Parity haben möchte.

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
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Das gibt man bei der Konfiguration mit an, ob man keine, gerade oder ungerade Parity haben möchte.
"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.
Benutzeravatar
Weisskeinen
Beiträge: 3943
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

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.
Benutzeravatar
xoexlepox
Beiträge: 4814
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

Ich sehe gerade, dass das Parity-Bit als Command-Bit missbraucht wird.
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.
Antworten