Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

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

Benutzeravatar
Finger
Administrator
Beiträge: 7392
Registriert: Di 12. Jun 2012, 20:16
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Finger »

Ist auch so. Warum sich das kompilieren lässt ist mir aber ein Rätsel....
sysconsol
Beiträge: 4059
Registriert: Fr 8. Jul 2016, 17:22

Re: Der AVR-/ARDUINO-Faden

Beitrag von sysconsol »

Arduino eben ... :lol:

Gegenprobe:

Code: Alles auswählen

int puffer2;

int addivari(int, int); // Prototyp

void setup() {
  Serial.begin(115200);
}

void loop() {
  int (*zeiger)(int, int);

  Serial.print("addivari(1, 2): ");
  Serial.println(addivari(1, 2));

  zeiger = addivari;

  Serial.print("zeiger(4, 5): ");
  Serial.println(zeiger(4, 5));

  Serial.print("zeiger: ");
  //Serial.println(zeiger); //--> wirft: no matching function for call to 'println(int (*&)(int, int))'

  puffer2 = zeiger;

  Serial.println(puffer2);  

  delay(10000);
}

int addivari(int a, int b){
  int c;
  c = a + b;
  return c;  
}
Ergibt im (auf? hinter?) Monitor:

Code: Alles auswählen

addivari(1, 2): 3
zeiger(4, 5): 9
zeiger: 95
Da ist sie wieder, die Fünfundneunzig.

Und nun alle gemeinsam:

Code: Alles auswählen

long unsigned int puffer1;
int puffer2;

int addivari(int, int); // Prototyp

void setup() {
  Serial.begin(115200);
}

void loop() {
  
  Serial.print("millis(): ");
  Serial.println(millis());
  Serial.print("millis: ");
  //Serial.println(millis); //--> wirft: no matching function for call to 'println(long unsigned int (&)())'

  puffer1 = millis;
  Serial.println(puffer1);

  int (*zeiger)(int, int);

  Serial.print("addivari(1, 2): ");
  Serial.println(addivari(1, 2));

  zeiger = addivari;

  Serial.print("zeiger(4, 5): ");
  Serial.println(zeiger(4, 5));

  Serial.print("zeiger: ");
  //Serial.println(zeiger); //--> wirft: no matching function for call to 'println(int (*&)(int, int))'

  puffer2 = zeiger;

  Serial.println(puffer2);
  

  delay(10000);
}

int addivari(int a, int b){
  int c;
  c = a + b;
  return c;  
}
Ergibt folgende Ausgabe:

Code: Alles auswählen

millis(): 0
millis: 95
addivari(1, 2): 3
zeiger(4, 5): 9
zeiger: 107
Die Fünfundneunzig ist schon belegt, die Einhundertsieben ist frei.
Etwas in der Art hätte ich auch erwartet.
sysconsol hat geschrieben:Einer von uns beiden ist ein Depp: Das Netz oder ich.
Ich weiß noch nicht, wonach ich suche. Aber ich fange schon mal an.
sysconsol
Beiträge: 4059
Registriert: Fr 8. Jul 2016, 17:22

Re: Der AVR-/ARDUINO-Faden

Beitrag von sysconsol »

Noch ein Versuch:

Code: Alles auswählen

int puffer2;
int addivari(int, int);

void setup() {
}

void loop() {
  int (*zeiger)(int, int);
  zeiger = addivari;
  puffer2 = zeiger;
}

int addivari(int a, int b){
  int c;
  c = a + b;
  return c;  
}
Auf der Konsole:

Code: Alles auswählen

avr-objdump -D sketch_dec09a.ino.hex -m avr5 >/media/ramdisk/dis2.dump
dis2.dump:

Code: Alles auswählen

sketch_dec09a.ino.hex:     file format ihex


Disassembly of section .sec1:

00000000 <.sec1>:
   0:	0c 94 34 00 	jmp	0x68	;  0x68
   4:	0c 94 46 00 	jmp	0x8c	;  0x8c
   8:	0c 94 46 00 	jmp	0x8c	;  0x8c
   c:	0c 94 46 00 	jmp	0x8c	;  0x8c
  10:	0c 94 46 00 	jmp	0x8c	;  0x8c
  14:	0c 94 46 00 	jmp	0x8c	;  0x8c
  18:	0c 94 46 00 	jmp	0x8c	;  0x8c
  1c:	0c 94 46 00 	jmp	0x8c	;  0x8c
  20:	0c 94 46 00 	jmp	0x8c	;  0x8c
  24:	0c 94 46 00 	jmp	0x8c	;  0x8c
  28:	0c 94 46 00 	jmp	0x8c	;  0x8c
  2c:	0c 94 46 00 	jmp	0x8c	;  0x8c
  30:	0c 94 46 00 	jmp	0x8c	;  0x8c
  34:	0c 94 46 00 	jmp	0x8c	;  0x8c
  38:	0c 94 46 00 	jmp	0x8c	;  0x8c
  3c:	0c 94 46 00 	jmp	0x8c	;  0x8c
  40:	0c 94 4b 00 	jmp	0x96	;  0x96
  44:	0c 94 46 00 	jmp	0x8c	;  0x8c
  48:	0c 94 46 00 	jmp	0x8c	;  0x8c
  4c:	0c 94 46 00 	jmp	0x8c	;  0x8c
  50:	0c 94 46 00 	jmp	0x8c	;  0x8c
  54:	0c 94 46 00 	jmp	0x8c	;  0x8c
  58:	0c 94 46 00 	jmp	0x8c	;  0x8c
  5c:	0c 94 46 00 	jmp	0x8c	;  0x8c
  60:	0c 94 46 00 	jmp	0x8c	;  0x8c
  64:	0c 94 46 00 	jmp	0x8c	;  0x8c
  68:	11 24       	eor	r1, r1
  6a:	1f be       	out	0x3f, r1	; 63
  6c:	cf ef       	ldi	r28, 0xFF	; 255
  6e:	d8 e0       	ldi	r29, 0x08	; 8
  70:	de bf       	out	0x3e, r29	; 62
  72:	cd bf       	out	0x3d, r28	; 61
  74:	21 e0       	ldi	r18, 0x01	; 1
  76:	a0 e0       	ldi	r26, 0x00	; 0
  78:	b1 e0       	ldi	r27, 0x01	; 1
  7a:	01 c0       	rjmp	.+2      	;  0x7e
  7c:	1d 92       	st	X+, r1
  7e:	a9 30       	cpi	r26, 0x09	; 9
  80:	b2 07       	cpc	r27, r18
  82:	e1 f7       	brne	.-8      	;  0x7c
  84:	0e 94 95 00 	call	0x12a	;  0x12a
  88:	0c 94 df 00 	jmp	0x1be	;  0x1be
  8c:	0c 94 00 00 	jmp	0	;  0x0
  90:	86 0f       	add	r24, r22
  92:	97 1f       	adc	r25, r23
  94:	08 95       	ret
  96:	1f 92       	push	r1
  98:	0f 92       	push	r0
  9a:	0f b6       	in	r0, 0x3f	; 63
  9c:	0f 92       	push	r0
  9e:	11 24       	eor	r1, r1
  a0:	2f 93       	push	r18
  a2:	3f 93       	push	r19
  a4:	8f 93       	push	r24
  a6:	9f 93       	push	r25
  a8:	af 93       	push	r26
  aa:	bf 93       	push	r27
  ac:	80 91 05 01 	lds	r24, 0x0105	;  0x800105
  b0:	90 91 06 01 	lds	r25, 0x0106	;  0x800106
  b4:	a0 91 07 01 	lds	r26, 0x0107	;  0x800107
  b8:	b0 91 08 01 	lds	r27, 0x0108	;  0x800108
  bc:	30 91 04 01 	lds	r19, 0x0104	;  0x800104
  c0:	23 e0       	ldi	r18, 0x03	; 3
  c2:	23 0f       	add	r18, r19
  c4:	2d 37       	cpi	r18, 0x7D	; 125
  c6:	58 f5       	brcc	.+86     	;  0x11e
  c8:	01 96       	adiw	r24, 0x01	; 1
  ca:	a1 1d       	adc	r26, r1
  cc:	b1 1d       	adc	r27, r1
  ce:	20 93 04 01 	sts	0x0104, r18	;  0x800104
  d2:	80 93 05 01 	sts	0x0105, r24	;  0x800105
  d6:	90 93 06 01 	sts	0x0106, r25	;  0x800106
  da:	a0 93 07 01 	sts	0x0107, r26	;  0x800107
  de:	b0 93 08 01 	sts	0x0108, r27	;  0x800108
  e2:	80 91 00 01 	lds	r24, 0x0100	;  0x800100
  e6:	90 91 01 01 	lds	r25, 0x0101	;  0x800101
  ea:	a0 91 02 01 	lds	r26, 0x0102	;  0x800102
  ee:	b0 91 03 01 	lds	r27, 0x0103	;  0x800103
  f2:	01 96       	adiw	r24, 0x01	; 1
  f4:	a1 1d       	adc	r26, r1
  f6:	b1 1d       	adc	r27, r1
  f8:	80 93 00 01 	sts	0x0100, r24	;  0x800100
  fc:	90 93 01 01 	sts	0x0101, r25	;  0x800101
 100:	a0 93 02 01 	sts	0x0102, r26	;  0x800102
 104:	b0 93 03 01 	sts	0x0103, r27	;  0x800103
 108:	bf 91       	pop	r27
 10a:	af 91       	pop	r26
 10c:	9f 91       	pop	r25
 10e:	8f 91       	pop	r24
 110:	3f 91       	pop	r19
 112:	2f 91       	pop	r18
 114:	0f 90       	pop	r0
 116:	0f be       	out	0x3f, r0	; 63
 118:	0f 90       	pop	r0
 11a:	1f 90       	pop	r1
 11c:	18 95       	reti
 11e:	26 e8       	ldi	r18, 0x86	; 134
 120:	23 0f       	add	r18, r19
 122:	02 96       	adiw	r24, 0x02	; 2
 124:	a1 1d       	adc	r26, r1
 126:	b1 1d       	adc	r27, r1
 128:	d2 cf       	rjmp	.-92     	;  0xce
 12a:	78 94       	sei
 12c:	84 b5       	in	r24, 0x24	; 36
 12e:	82 60       	ori	r24, 0x02	; 2
 130:	84 bd       	out	0x24, r24	; 36
 132:	84 b5       	in	r24, 0x24	; 36
 134:	81 60       	ori	r24, 0x01	; 1
 136:	84 bd       	out	0x24, r24	; 36
 138:	85 b5       	in	r24, 0x25	; 37
 13a:	82 60       	ori	r24, 0x02	; 2
 13c:	85 bd       	out	0x25, r24	; 37
 13e:	85 b5       	in	r24, 0x25	; 37
 140:	81 60       	ori	r24, 0x01	; 1
 142:	85 bd       	out	0x25, r24	; 37
 144:	80 91 6e 00 	lds	r24, 0x006E	;  0x80006e
 148:	81 60       	ori	r24, 0x01	; 1
 14a:	80 93 6e 00 	sts	0x006E, r24	;  0x80006e
 14e:	10 92 81 00 	sts	0x0081, r1	;  0x800081
 152:	80 91 81 00 	lds	r24, 0x0081	;  0x800081
 156:	82 60       	ori	r24, 0x02	; 2
 158:	80 93 81 00 	sts	0x0081, r24	;  0x800081
 15c:	80 91 81 00 	lds	r24, 0x0081	;  0x800081
 160:	81 60       	ori	r24, 0x01	; 1
 162:	80 93 81 00 	sts	0x0081, r24	;  0x800081
 166:	80 91 80 00 	lds	r24, 0x0080	;  0x800080
 16a:	81 60       	ori	r24, 0x01	; 1
 16c:	80 93 80 00 	sts	0x0080, r24	;  0x800080
 170:	80 91 b1 00 	lds	r24, 0x00B1	;  0x8000b1
 174:	84 60       	ori	r24, 0x04	; 4
 176:	80 93 b1 00 	sts	0x00B1, r24	;  0x8000b1
 17a:	80 91 b0 00 	lds	r24, 0x00B0	;  0x8000b0
 17e:	81 60       	ori	r24, 0x01	; 1
 180:	80 93 b0 00 	sts	0x00B0, r24	;  0x8000b0
 184:	80 91 7a 00 	lds	r24, 0x007A	;  0x80007a
 188:	84 60       	ori	r24, 0x04	; 4
 18a:	80 93 7a 00 	sts	0x007A, r24	;  0x80007a
 18e:	80 91 7a 00 	lds	r24, 0x007A	;  0x80007a
 192:	82 60       	ori	r24, 0x02	; 2
 194:	80 93 7a 00 	sts	0x007A, r24	;  0x80007a
 198:	80 91 7a 00 	lds	r24, 0x007A	;  0x80007a
 19c:	81 60       	ori	r24, 0x01	; 1
 19e:	80 93 7a 00 	sts	0x007A, r24	;  0x80007a
 1a2:	80 91 7a 00 	lds	r24, 0x007A	;  0x80007a
 1a6:	80 68       	ori	r24, 0x80	; 128
 1a8:	80 93 7a 00 	sts	0x007A, r24	;  0x80007a
 1ac:	10 92 c1 00 	sts	0x00C1, r1	;  0x8000c1
 1b0:	c0 e0       	ldi	r28, 0x00	; 0
 1b2:	d0 e0       	ldi	r29, 0x00	; 0
 1b4:	20 97       	sbiw	r28, 0x00	; 0
 1b6:	f1 f3       	breq	.-4      	;  0x1b4
 1b8:	0e 94 00 00 	call	0	;  0x0
 1bc:	fb cf       	rjmp	.-10     	;  0x1b4
 1be:	f8 94       	cli
 1c0:	ff cf       	rjmp	.-2      	;  0x1c0
Etwas übersichtlicher:

Code: Alles auswählen

avr-objdump -S sketch_dec09a.ino.elf -m avr5 >/media/ramdisk/dis3.dump
dis3.dump:

Code: Alles auswählen

sketch_dec09a.ino.elf:     file format elf32-avr


Disassembly of section .text:

00000000 <__vectors>:
   0:	0c 94 34 00 	jmp	0x68	; 0x68 <__ctors_end>
   4:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
   8:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
   c:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  10:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  14:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  18:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  1c:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  20:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  24:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  28:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  2c:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  30:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  34:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  38:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  3c:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  40:	0c 94 4b 00 	jmp	0x96	; 0x96 <__vector_16>
  44:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  48:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  4c:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  50:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  54:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  58:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  5c:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  60:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>
  64:	0c 94 46 00 	jmp	0x8c	; 0x8c <__bad_interrupt>

00000068 <__ctors_end>:
  68:	11 24       	eor	r1, r1
  6a:	1f be       	out	0x3f, r1	; 63
  6c:	cf ef       	ldi	r28, 0xFF	; 255
  6e:	d8 e0       	ldi	r29, 0x08	; 8
  70:	de bf       	out	0x3e, r29	; 62
  72:	cd bf       	out	0x3d, r28	; 61

00000074 <__do_clear_bss>:
  74:	21 e0       	ldi	r18, 0x01	; 1
  76:	a0 e0       	ldi	r26, 0x00	; 0
  78:	b1 e0       	ldi	r27, 0x01	; 1
  7a:	01 c0       	rjmp	.+2      	; 0x7e <.do_clear_bss_start>

0000007c <.do_clear_bss_loop>:
  7c:	1d 92       	st	X+, r1

0000007e <.do_clear_bss_start>:
  7e:	a9 30       	cpi	r26, 0x09	; 9
  80:	b2 07       	cpc	r27, r18
  82:	e1 f7       	brne	.-8      	; 0x7c <.do_clear_bss_loop>
  84:	0e 94 95 00 	call	0x12a	; 0x12a <main>
  88:	0c 94 df 00 	jmp	0x1be	; 0x1be <_exit>

0000008c <__bad_interrupt>:
  8c:	0c 94 00 00 	jmp	0	; 0x0 <__vectors>

00000090 <_Z8addivariii>:

int addivari(int a, int b){
  int c;
  c = a + b;
  return c;  
}
  90:	86 0f       	add	r24, r22
  92:	97 1f       	adc	r25, r23
  94:	08 95       	ret

00000096 <__vector_16>:
#if defined(TIM0_OVF_vect)
ISR(TIM0_OVF_vect)
#else
ISR(TIMER0_OVF_vect)
#endif
{
  96:	1f 92       	push	r1
  98:	0f 92       	push	r0
  9a:	0f b6       	in	r0, 0x3f	; 63
  9c:	0f 92       	push	r0
  9e:	11 24       	eor	r1, r1
  a0:	2f 93       	push	r18
  a2:	3f 93       	push	r19
  a4:	8f 93       	push	r24
  a6:	9f 93       	push	r25
  a8:	af 93       	push	r26
  aa:	bf 93       	push	r27
	// copy these to local variables so they can be stored in registers
	// (volatile variables must be read from memory on every access)
	unsigned long m = timer0_millis;
  ac:	80 91 05 01 	lds	r24, 0x0105	; 0x800105 <timer0_millis>
  b0:	90 91 06 01 	lds	r25, 0x0106	; 0x800106 <timer0_millis+0x1>
  b4:	a0 91 07 01 	lds	r26, 0x0107	; 0x800107 <timer0_millis+0x2>
  b8:	b0 91 08 01 	lds	r27, 0x0108	; 0x800108 <timer0_millis+0x3>
	unsigned char f = timer0_fract;
  bc:	30 91 04 01 	lds	r19, 0x0104	; 0x800104 <timer0_fract>

	m += MILLIS_INC;
	f += FRACT_INC;
  c0:	23 e0       	ldi	r18, 0x03	; 3
  c2:	23 0f       	add	r18, r19
	if (f >= FRACT_MAX) {
  c4:	2d 37       	cpi	r18, 0x7D	; 125
  c6:	58 f5       	brcc	.+86     	; 0x11e <__vector_16+0x88>
	// copy these to local variables so they can be stored in registers
	// (volatile variables must be read from memory on every access)
	unsigned long m = timer0_millis;
	unsigned char f = timer0_fract;

	m += MILLIS_INC;
  c8:	01 96       	adiw	r24, 0x01	; 1
  ca:	a1 1d       	adc	r26, r1
  cc:	b1 1d       	adc	r27, r1
	if (f >= FRACT_MAX) {
		f -= FRACT_MAX;
		m += 1;
	}

	timer0_fract = f;
  ce:	20 93 04 01 	sts	0x0104, r18	; 0x800104 <timer0_fract>
	timer0_millis = m;
  d2:	80 93 05 01 	sts	0x0105, r24	; 0x800105 <timer0_millis>
  d6:	90 93 06 01 	sts	0x0106, r25	; 0x800106 <timer0_millis+0x1>
  da:	a0 93 07 01 	sts	0x0107, r26	; 0x800107 <timer0_millis+0x2>
  de:	b0 93 08 01 	sts	0x0108, r27	; 0x800108 <timer0_millis+0x3>
	timer0_overflow_count++;
  e2:	80 91 00 01 	lds	r24, 0x0100	; 0x800100 <_edata>
  e6:	90 91 01 01 	lds	r25, 0x0101	; 0x800101 <_edata+0x1>
  ea:	a0 91 02 01 	lds	r26, 0x0102	; 0x800102 <_edata+0x2>
  ee:	b0 91 03 01 	lds	r27, 0x0103	; 0x800103 <_edata+0x3>
  f2:	01 96       	adiw	r24, 0x01	; 1
  f4:	a1 1d       	adc	r26, r1
  f6:	b1 1d       	adc	r27, r1
  f8:	80 93 00 01 	sts	0x0100, r24	; 0x800100 <_edata>
  fc:	90 93 01 01 	sts	0x0101, r25	; 0x800101 <_edata+0x1>
 100:	a0 93 02 01 	sts	0x0102, r26	; 0x800102 <_edata+0x2>
 104:	b0 93 03 01 	sts	0x0103, r27	; 0x800103 <_edata+0x3>
}
 108:	bf 91       	pop	r27
 10a:	af 91       	pop	r26
 10c:	9f 91       	pop	r25
 10e:	8f 91       	pop	r24
 110:	3f 91       	pop	r19
 112:	2f 91       	pop	r18
 114:	0f 90       	pop	r0
 116:	0f be       	out	0x3f, r0	; 63
 118:	0f 90       	pop	r0
 11a:	1f 90       	pop	r1
 11c:	18 95       	reti
	unsigned char f = timer0_fract;

	m += MILLIS_INC;
	f += FRACT_INC;
	if (f >= FRACT_MAX) {
		f -= FRACT_MAX;
 11e:	26 e8       	ldi	r18, 0x86	; 134
 120:	23 0f       	add	r18, r19
		m += 1;
 122:	02 96       	adiw	r24, 0x02	; 2
 124:	a1 1d       	adc	r26, r1
 126:	b1 1d       	adc	r27, r1
 128:	d2 cf       	rjmp	.-92     	; 0xce <__vector_16+0x38>

0000012a <main>:

void init()
{
	// this needs to be called before setup() or some functions won't
	// work there
	sei();
 12a:	78 94       	sei
	
	// on the ATmega168, timer 0 is also used for fast hardware pwm
	// (using phase-correct PWM would mean that timer 0 overflowed half as often
	// resulting in different millis() behavior on the ATmega8 and ATmega168)
#if defined(TCCR0A) && defined(WGM01)
	sbi(TCCR0A, WGM01);
 12c:	84 b5       	in	r24, 0x24	; 36
 12e:	82 60       	ori	r24, 0x02	; 2
 130:	84 bd       	out	0x24, r24	; 36
	sbi(TCCR0A, WGM00);
 132:	84 b5       	in	r24, 0x24	; 36
 134:	81 60       	ori	r24, 0x01	; 1
 136:	84 bd       	out	0x24, r24	; 36
	// this combination is for the standard atmega8
	sbi(TCCR0, CS01);
	sbi(TCCR0, CS00);
#elif defined(TCCR0B) && defined(CS01) && defined(CS00)
	// this combination is for the standard 168/328/1280/2560
	sbi(TCCR0B, CS01);
 138:	85 b5       	in	r24, 0x25	; 37
 13a:	82 60       	ori	r24, 0x02	; 2
 13c:	85 bd       	out	0x25, r24	; 37
	sbi(TCCR0B, CS00);
 13e:	85 b5       	in	r24, 0x25	; 37
 140:	81 60       	ori	r24, 0x01	; 1
 142:	85 bd       	out	0x25, r24	; 37

	// enable timer 0 overflow interrupt
#if defined(TIMSK) && defined(TOIE0)
	sbi(TIMSK, TOIE0);
#elif defined(TIMSK0) && defined(TOIE0)
	sbi(TIMSK0, TOIE0);
 144:	80 91 6e 00 	lds	r24, 0x006E	; 0x80006e <__TEXT_REGION_LENGTH__+0x7e006e>
 148:	81 60       	ori	r24, 0x01	; 1
 14a:	80 93 6e 00 	sts	0x006E, r24	; 0x80006e <__TEXT_REGION_LENGTH__+0x7e006e>
	// this is better for motors as it ensures an even waveform
	// note, however, that fast pwm mode can achieve a frequency of up
	// 8 MHz (with a 16 MHz clock) at 50% duty cycle

#if defined(TCCR1B) && defined(CS11) && defined(CS10)
	TCCR1B = 0;
 14e:	10 92 81 00 	sts	0x0081, r1	; 0x800081 <__TEXT_REGION_LENGTH__+0x7e0081>

	// set timer 1 prescale factor to 64
	sbi(TCCR1B, CS11);
 152:	80 91 81 00 	lds	r24, 0x0081	; 0x800081 <__TEXT_REGION_LENGTH__+0x7e0081>
 156:	82 60       	ori	r24, 0x02	; 2
 158:	80 93 81 00 	sts	0x0081, r24	; 0x800081 <__TEXT_REGION_LENGTH__+0x7e0081>
#if F_CPU >= 8000000L
	sbi(TCCR1B, CS10);
 15c:	80 91 81 00 	lds	r24, 0x0081	; 0x800081 <__TEXT_REGION_LENGTH__+0x7e0081>
 160:	81 60       	ori	r24, 0x01	; 1
 162:	80 93 81 00 	sts	0x0081, r24	; 0x800081 <__TEXT_REGION_LENGTH__+0x7e0081>
	sbi(TCCR1, CS10);
#endif
#endif
	// put timer 1 in 8-bit phase correct pwm mode
#if defined(TCCR1A) && defined(WGM10)
	sbi(TCCR1A, WGM10);
 166:	80 91 80 00 	lds	r24, 0x0080	; 0x800080 <__TEXT_REGION_LENGTH__+0x7e0080>
 16a:	81 60       	ori	r24, 0x01	; 1
 16c:	80 93 80 00 	sts	0x0080, r24	; 0x800080 <__TEXT_REGION_LENGTH__+0x7e0080>

	// set timer 2 prescale factor to 64
#if defined(TCCR2) && defined(CS22)
	sbi(TCCR2, CS22);
#elif defined(TCCR2B) && defined(CS22)
	sbi(TCCR2B, CS22);
 170:	80 91 b1 00 	lds	r24, 0x00B1	; 0x8000b1 <__TEXT_REGION_LENGTH__+0x7e00b1>
 174:	84 60       	ori	r24, 0x04	; 4
 176:	80 93 b1 00 	sts	0x00B1, r24	; 0x8000b1 <__TEXT_REGION_LENGTH__+0x7e00b1>

	// configure timer 2 for phase correct pwm (8-bit)
#if defined(TCCR2) && defined(WGM20)
	sbi(TCCR2, WGM20);
#elif defined(TCCR2A) && defined(WGM20)
	sbi(TCCR2A, WGM20);
 17a:	80 91 b0 00 	lds	r24, 0x00B0	; 0x8000b0 <__TEXT_REGION_LENGTH__+0x7e00b0>
 17e:	81 60       	ori	r24, 0x01	; 1
 180:	80 93 b0 00 	sts	0x00B0, r24	; 0x8000b0 <__TEXT_REGION_LENGTH__+0x7e00b0>
#endif

#if defined(ADCSRA)
	// set a2d prescaler so we are inside the desired 50-200 KHz range.
	#if F_CPU >= 16000000 // 16 MHz / 128 = 125 KHz
		sbi(ADCSRA, ADPS2);
 184:	80 91 7a 00 	lds	r24, 0x007A	; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
 188:	84 60       	ori	r24, 0x04	; 4
 18a:	80 93 7a 00 	sts	0x007A, r24	; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
		sbi(ADCSRA, ADPS1);
 18e:	80 91 7a 00 	lds	r24, 0x007A	; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
 192:	82 60       	ori	r24, 0x02	; 2
 194:	80 93 7a 00 	sts	0x007A, r24	; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
		sbi(ADCSRA, ADPS0);
 198:	80 91 7a 00 	lds	r24, 0x007A	; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
 19c:	81 60       	ori	r24, 0x01	; 1
 19e:	80 93 7a 00 	sts	0x007A, r24	; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
		cbi(ADCSRA, ADPS2);
		cbi(ADCSRA, ADPS1);
		sbi(ADCSRA, ADPS0);
	#endif
	// enable a2d conversions
	sbi(ADCSRA, ADEN);
 1a2:	80 91 7a 00 	lds	r24, 0x007A	; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
 1a6:	80 68       	ori	r24, 0x80	; 128
 1a8:	80 93 7a 00 	sts	0x007A, r24	; 0x80007a <__TEXT_REGION_LENGTH__+0x7e007a>
	// here so they can be used as normal digital i/o; they will be
	// reconnected in Serial.begin()
#if defined(UCSRB)
	UCSRB = 0;
#elif defined(UCSR0B)
	UCSR0B = 0;
 1ac:	10 92 c1 00 	sts	0x00C1, r1	; 0x8000c1 <__TEXT_REGION_LENGTH__+0x7e00c1>
	
	setup();
    
	for (;;) {
		loop();
		if (serialEventRun) serialEventRun();
 1b0:	c0 e0       	ldi	r28, 0x00	; 0
 1b2:	d0 e0       	ldi	r29, 0x00	; 0
 1b4:	20 97       	sbiw	r28, 0x00	; 0
 1b6:	f1 f3       	breq	.-4      	; 0x1b4 <main+0x8a>
 1b8:	0e 94 00 00 	call	0	; 0x0 <__vectors>
 1bc:	fb cf       	rjmp	.-10     	; 0x1b4 <main+0x8a>

000001be <_exit>:
 1be:	f8 94       	cli

000001c0 <__stop_program>:
 1c0:	ff cf       	rjmp	.-2      	; 0x1c0 <__stop_program>
Da muss ich erstmal wachsen - das ist mir gerade etwas zu hoch :oops:
Benutzeravatar
Weisskeinen
Beiträge: 3942
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Später Gast hat geschrieben: Fr 29. Nov 2019, 19:37
Die Visualisierung des Lautstärkepuffers ist blöd mit den Zahlen, da such ich noch was anderes, Vllt sone Dot-Matrix, da hab ich nur noch keine mit Max7219 und RGB LED als Paket gefunden. Hat Jemand schon Erfahrungen mit diesen einzeln ansteuerbaren LedStrips?

Ich würd da gerne 10-er Blocks runterschnippeln und dann damit den Puffer in grün(+) und rot(-) anzeigen. Geht das?
Nicht mit genau diesen, aber mit vergleichbaren. Das geht ziemlich unkompliziert mit den entsprechenden Libraries. Verdrahten, aufrufen, fertig.
Was man aber beachten muss ist, dass die sehr empfindlich sind, was die Stromversorgung und den Pegel am Input angeht. Sollte die Stromversorgung aus sein, der Input aber auf High gezogen werden, gehen die sofort kaputt. Schützen kann man die, indem man in die Datenleitung einen 330 Ohm-Widerstand einbaut und zwei Schottky-Dioden zwischen Dateneingang und Plusleitung beziehungsweise Minusleitung lötet. So, dass die von Minus nach Dateneingang nach Plus leitend wären. Wenn man das dann auch noch direkt an den Streifen lötet, sollte eigentlich nichts mehr passieren.
Benutzeravatar
Später Gast
Beiträge: 1680
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

Weisskeinen hat geschrieben: Mo 9. Dez 2019, 21:04 Nicht mit genau diesen, aber mit vergleichbaren.
Echt jetzt? Habs schon geordert. :| Da steht man könne sie einzeln runterschneiden und es gibt auch massig Tuts wie das einzubinden ist. Hmmm.

Was man aber beachten muss ist, dass die sehr empfindlich sind, was die Stromversorgung und den Pegel am Input angeht.
[...] sollte eigentlich nichts mehr passieren.
Okay, danke. da hätt ich sicher n paar gehimmelt sonst.
Benutzeravatar
ferdimh
Beiträge: 9379
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

Warum das eine kompilierbar ist (vrmtl mit Warnung) und das andere nicht, ist darin zu sehen, ob die Konvertierung explizit oder implizit erfolgt.
Serial.println ist eine überladene Funktion, und kann mehrere Typen annehmen (mindestens char *,int, float), wo es auch noch unterschiedliche Dinge tut. Der Compiler hat hier keine eindeutig valide Konvertierung zur Verfügung.
Im 2. Fall ist die Anweisung klar: Nimm den Pointer, pack ihn in einen unsigned long int (Diese Konvertierung ist zulässig, gibt aber normalerweise eine Warnung, die vrmtl von der Arduino-IDE hinter weiterem Text vergraben wird), zeige dann den unsigned long int an.
Serial.println((unsigned long int)millis);
sollte das gleiche tun.
Benutzeravatar
Weisskeinen
Beiträge: 3942
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Später Gast hat geschrieben: Di 10. Dez 2019, 00:10
Weisskeinen hat geschrieben: Mo 9. Dez 2019, 21:04 Nicht mit genau diesen, aber mit vergleichbaren.
Echt jetzt? Habs schon geordert. :| Da steht man könne sie einzeln runterschneiden und es gibt auch massig Tuts wie das einzubinden ist. Hmmm.
Äh, ja, vergleichbar insofern, dass meine auch diese WS2812B-LEDs drauf haben, aber in größerem Abstand und bei jemand anderem gekauft. Sonst nichts. Und ja, die kann man nach jeder LED abschneiden. Für größere Installationen sind die halt deshalb doof, weil die einzelne LED voll an 60mA braucht, bei 100 Stück muss man schon 6A bereit stellen u.s.w.. Es gibt wohl mittlerweile auch hochwertigere (!) Klone...
Benutzeravatar
Später Gast
Beiträge: 1680
Registriert: Di 5. Apr 2016, 22:03
Wohnort: Karlsruhe
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Später Gast »

Achso puh, dann hab ich dich nur falsch verstanden. Mit "ziemlich ähnlichen" dachte ich, da bräuchte ich was anderes...
Hmm ja Stromverbrauch. mal schauen, ob ich das überhaupt voll aufdrehen muss, bei den Siebensegmentanzeigen reicht ja auch Stufe 1 oder 2 von 16.
frickelfred56
Beiträge: 230
Registriert: Mo 16. Feb 2015, 13:50

Re: Der AVR-/ARDUINO-Faden

Beitrag von frickelfred56 »

Guten morgen zusammen
ich hab einen Code in Arduinisch zusammengebastelt und ste ein bisschen auf dem Schlauch.

Achja, Ich bin schon nicht mehr ganz neu ("Arduinoforum") und daher schreib ich da nix.

in meinem Code hab ich einen Zähler der nicht tut. auch umbenennen und auf einem anderen Rechner Compilern
hat nichts gebracht.
ich hab den jetzt mal mit "dieser_geht_nicht" bennant. kann sich das villeicht mal einer anschauen ob der Fehler auch so
auftritt oder mir erklären warum das nicht geht?

achja Code

Code: Alles auswählen

[code]
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
#include <EEPROM.h>


#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>


#define CE_PIN   8
#define CSN_PIN  9

RF24 radio(CE_PIN, CSN_PIN); // Create a Radio

// Set the LCD address to 0x27 for a 16 chars and 2 line display
LiquidCrystal_I2C lcd(0x27, 16, 2);


// -------------------const--------------------------
const char m_01[] PROGMEM = "   Version v6   ";  // Maximal 16 Zeichen
const char m_02[] PROGMEM = "DMT ------------";
const char m_03[] PROGMEM = "  Meldung 2     ";
const char m_04[] PROGMEM = "   Meldung 3    ";
const char m_05[] PROGMEM = "    Meldung 4   ";
const char m_06[] PROGMEM = "     Meldung 5  ";
const char m_07[] PROGMEM = "                ";
const char m_08[] PROGMEM = "                ";
const char m_09[] PROGMEM = " Reset druecken ";
const char* const mymenue[] PROGMEM = {m_01, m_02, m_03, m_04, m_05, m_06, m_07, m_08, m_09};
char b1menue[18];


const char m_11[] PROGMEM = "DMT kV   ";  // Maximal 8 Zeichen
const char m_12[] PROGMEM = " Kanal : ";
const char m_13[] PROGMEM = " MW 2  : ";
const char m_14[] PROGMEM = " MW 3  : ";
const char m_15[] PROGMEM = " MW 4  : ";
const char m_16[] PROGMEM = " MW 5  : ";
const char m_17[] PROGMEM = "#        ";
const char m_18[] PROGMEM = " Save    ";
const char* const mymenue1[] PROGMEM = {m_11, m_12, m_13, m_14, m_15, m_16, m_17, m_18};
char b2menue[10];

const char m_21[] PROGMEM = "FE 12/19 ";  // Maximal 8 Zeichen
const char m_22[] PROGMEM = "Speed  : ";
const char m_23[] PROGMEM = "Strom  : ";
const char m_24[] PROGMEM = "U-Batt : ";
const char m_25[] PROGMEM = "U-Akku : ";
const char m_26[] PROGMEM = "Comm   : ";
const char m_27[] PROGMEM = " ---   : ";
//const char m_26[] PROGMEM = " ##      ";
//const char m_27[] PROGMEM = " #       ";
const char* const mymenue3[] PROGMEM = {m_21, m_22, m_23, m_24, m_25, m_26, m_27};
char b3menue[9];


// --------------------var---------------------------
const byte slaveAddress[5] = {'D', 'M', 'T', 'K', 'V'};

const long lcd_on = 30000 ;     //15000;
const int tol = 25;
const int m_interval = 3000;
const int t_delay = 50;       // Tasten entprellzeit
const int t_out = 30000;

unsigned long txIntervalMillis = 15000; // send once per second


// nrf24l01 variablen
//char dataToSend[10] = "Message 0";
int dataToSend[10] = { -1, -12, -3, -1, -1, -1, -1, -1, -1, -1};
char txNum = '0';
int ackData[4] = { -1, -1, -1, -1}; // to hold the two values coming from the slave
bool newData = false;

unsigned long c_millis;
unsigned long p_millis;
unsigned long m_millis;
unsigned long t_e_millis;
unsigned long t_up_millis;
unsigned long t_dwn_millis;
unsigned long t_out_millis;

byte x_var[8];
float b_var[8] = {0.0, 0.2, 0.3, 123.4, 0.5, 0.6, 0.7};
char* wert[] = {"High  ","OK    ","Low   "};

int taste = 0;
bool taste_e = 0;
bool taste_up = 0;
bool taste_dwn = 0;
bool old_e;
bool old_up;
bool old_dwn;
bool t_e_imp;
bool t_up_imp;
bool t_dwn_imp;

byte mset = 0;
byte dummy1;
byte s_menue;
byte dummy2;

byte m_i;
byte mm_i;
byte dieser_geht_nicht;

//------------------------------------setup---------------------
void setup() {
  // put your setup code here, to run once:

  lcd.begin();
  lcd.backlight();
  Serial.begin(19200);
  for (byte i = 0; i < 8; i++)   {
    x_var[i] = EEPROM.read(i);

  }

  radio.begin();
  radio.setDataRate( RF24_250KBPS );

  radio.enableAckPayload();

  radio.setRetries(3, 5); // delay, count
  radio.openWritingPipe(slaveAddress);

  strcpy_P(b1menue, (char*)pgm_read_word(&(mymenue[0])));
  lcd.setCursor(0, 0);
  lcd.print(b1menue);
  delay(500);
  readTaste();
  if (taste_e) mset = 1;          // Setup_Menue aufrufen
  dummy1 = 10;
  dummy2 = 20;
  //Serial.println(freeRam());
}

void readTaste()   {

  taste = analogRead(A3);           // Tasten einlesen über Analog
  taste_e = 0; taste_up = 0; taste_dwn = 0;
  if (taste >= 0 & taste <= (0 + tol)) taste_e = 1;
  if (taste >= 550 & taste <= (550 + tol)) taste_dwn = 1;
  if (taste >= 920 & taste <= (920 + tol)) taste_up = 1;

}

//--------------------------------------------------------------------------
void showData() {
  if (newData == true) {
    Serial.print("  Acknowledge data ");
    Serial.print(ackData[0]);
    Serial.print(", ");
    Serial.print(ackData[1]);
    Serial.print(", ");
    Serial.print(ackData[2]);
    Serial.print(", ");
    Serial.print(ackData[3]);
    Serial.println();
    newData = false;
  }
}


//----------------------loop-----------------------
void loop() {
  // put your main code here, to run repeatedly:
  c_millis = millis();

  // ---------------Tasten auswerten-----------------
  readTaste();
  if (taste_e)   {                    // Taste enable
    if (!old_e & (c_millis - t_e_millis >= t_delay)) {
      old_e = 1;
      t_e_imp = 1;
      Serial.println("taste E ");
      t_out_millis = c_millis;
    } else  {
      t_e_imp = 0;
    }
  } else {
    t_e_millis = c_millis;
    old_e = 0;
    t_e_imp = 0;
  }

  //if (t_e_imp) Serial.println("imp E ");

  if (taste_up)   {                   // Taste up
    if (!old_up & (c_millis - t_up_millis >= t_delay)) {
      old_up = 1;
      t_up_imp = 1;
      Serial.println(taste);
      t_out_millis = c_millis;
      Serial.println("taste UP ");

    } else   {
      t_up_imp = 0;
    }
  } else  {
    t_up_millis = c_millis;
    old_up = 0;
    t_up_imp = 0;
  }   //ende t_up

  //if (t_up_imp) Serial.println("imp UP ");

  if (taste_dwn)   {                  // Taste down
    if (!old_dwn & (c_millis - t_dwn_millis >= t_delay)) {
      old_dwn = 1;
      t_dwn_imp = 1;

      t_out_millis = c_millis;
      Serial.println("taste DWN ");
    } else   {
      t_dwn_imp = 0;
    }
  } else   {
    t_dwn_millis = c_millis;
    old_dwn = 0;
    t_dwn_imp = 0;
  }  // ende t_dwn

  //if (t_dwn_imp) Serial.println("imp DWN ");


  // ----------------Einstellmenue---------------------

  //xxxxxxxx
  if ( mset == 1 & t_e_imp & mm_i == 7)   {     // setup verlassen
    for (byte i = 0; i < 8; i++)   {
      EEPROM.write( i, x_var[i] );
    }
    mm_i = 0;
    mset = 2;
    strcpy_P(b1menue, (char*)pgm_read_word(&(mymenue[1])));
    lcd.setCursor(0, 0);
    lcd.print(b1menue);
    strcpy_P(b1menue, (char*)pgm_read_word(&(mymenue[8])));
    lcd.setCursor(0, 1);
    lcd.print(b1menue);
  }

  if (mset == 1 & t_up_imp)   {

    if ( s_menue == 0)   {                       // taste incr
      x_var[mm_i] = x_var[mm_i] + 1;
      Serial.print("    s_m : ");
      Serial.println(s_menue);
    } else {
      mm_i++;
      if (mm_i >= 8) mm_i = 1;
    }
  }

  if (mset == 1 & t_dwn_imp)   {
    if ( s_menue == 0)   {
      x_var[mm_i] = x_var[mm_i] - 1;
    } else   {
      if (mm_i >= 1) mm_i--;
      if (mm_i <= 1) mm_i = 7;

    }
  }

  if (mset == 1 & t_e_imp )   {
    if ( s_menue == 1 )   {          // taste e
      //  dummy2 = dummy2 - 1;
      s_menue = 0;
      //  dummy1 = dummy1 + 1;
      if ( s_menue >= 2) s_menue = 0;
    } else {
      s_menue = 1;
    }
  }
  if ( mset == 1)   {
    lcd.setCursor(0, 0);
    //Serial.print(" XX1 ");
    lcd.print("  Setup         ");
    lcd.setCursor(0, 1);
    strcpy_P(b2menue, (char*)pgm_read_word(&(mymenue1[mm_i])));
    lcd.print(b2menue);
    if (mm_i >= 1 & mm_i <= 5 )   {
      if (s_menue == 0)   {
        lcd.write(0x23);
      } else   {
        lcd.write(0x20);
      }
      lcd.print(x_var[mm_i]);
    } else {
      lcd.print("    ");
    }
  }


  if (mset == 0 )   {       // Normalbetrieb

    //-------------------Anzeige rollen----------------
    if ( c_millis - m_millis >= m_interval )   {
      m_millis = c_millis;
      //Serial.print("abc ");Serial.println(m_i);
      dummy1++;
      dieser_geht_nicht++; //m_i++;
      Serial.print("dieser_geht_nicht : "); Serial.println(dieser_geht_nicht);
      Serial.print("dummy: "); Serial.println(dummy1);
      if ( dummy1 >= 7)  {
        dummy1 = 0;
        Serial.print("xyz ");
      }

      lcd.setCursor(0, 0);
      strcpy_P(b1menue, (char*)pgm_read_word(&(mymenue[1])));
      lcd.print(b1menue);
      lcd.setCursor(0, 1);
      strcpy_P(b3menue, (char*)pgm_read_word(&(mymenue3[dummy1])));
      lcd.print(b3menue);
      if (dummy1 >= 1 & dummy1 <= 2)   {
        lcd.print(b_var[dummy1]);
        lcd.print("   ");
      } else  if (dummy1 >= 3 & dummy1 <= 5)  {
        lcd.print(wert[1]);
        
       }else {
         lcd.print("      ");
      }
      //m_i++;

    }
  }

  //currentMillis = millis();
  if (c_millis - p_millis >= txIntervalMillis) {
    send();
    p_millis = c_millis;
  }


}  //ende loop

// ---------------------------------------------------------------
void send() {

  bool rslt;
  radio.stopListening();

  rslt = radio.write( &dataToSend, sizeof(dataToSend) );
  // Always use sizeof() as it gives the size as the number of bytes.
  // For example if dataToSend was an int sizeof() would correctly return 2
  radio.startListening();

  Serial.print("Data Sent ");
  for (byte i = 0; i < 9; i++ )  {
    Serial.print(dataToSend[i]);
    Serial.print(", ");
  }

  if (rslt) {
    if ( radio.isAckPayloadAvailable() ) {
      radio.read(&ackData, sizeof(ackData));
      newData = true;
    }  else {
      Serial.println("  Acknowledge but no data ");
    }
    showData();
    //updateMessage();
  }  else {
    Serial.println("  Tx fialed");
  }
}
  //--------------------------------------------------------------------------

  int freeRam ()  {
    extern int __heap_start, *__brkval;
    int v;
    return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
  }

[/code]


danke fürs anschauen und ev. Antwort

frickelfred

man kann das auch anders und besser machen, try and error eben
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

nicht initialisiert würd ich sagen.

byte dieser_geht_nicht=0;

das gilt für die anderen auch :?:
frickelfred56
Beiträge: 230
Registriert: Mo 16. Feb 2015, 13:50

Re: Der AVR-/ARDUINO-Faden

Beitrag von frickelfred56 »

ch_ris hat geschrieben: Do 12. Dez 2019, 11:20 nicht initialisiert würd ich sagen.

byte dieser_geht_nicht=0;

das gilt für die anderen auch :?:
Warum?
wenn man die Zeile (107) auskommentiert kommt der Fehler nicht definiert.
zuweisen von =0 geht auch nicht (bei mir)
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

dann musst du in der Setup initialisieren/definieren.

Code: Alles auswählen

byte dieser_geht_nicht;

//------------------------------------setup---------------------
void setup() {
dieser_geht_nicht=0;
  // put your setup code here, to run once:
die variable gibt's, aber der wert ist unklar.
also "Was?++" geht dann halt nicht.
(nehme ich an)
Benutzeravatar
Weisskeinen
Beiträge: 3942
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Undefiniert gibt's letztlich ja eigentlich nicht, da steht halt eventuell irgend ein Wert drin, der hoch gezählt werden soll. Was heißt denn "geht nicht"? Wird nicht hoch gezählt? Programm läuft gar nicht? Seltsame Dinge passieren? Andere Variablen bekommen falsche Werte?
frickelfred56
Beiträge: 230
Registriert: Mo 16. Feb 2015, 13:50

Re: Der AVR-/ARDUINO-Faden

Beitrag von frickelfred56 »

Gegenfrage

meine Ersatzvarialble "dummy1" geht und macht das was "dieser_geht_nicht" tun soll?
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

herrje,
dummy1 definierst du in der setup.

Code: Alles auswählen

  if (taste_e) mset = 1;          // Setup_Menue aufrufen
  dummy1 = 10;
  dummy2 = 20;
  //Serial.println(freeRam());
probiers doch einfach aus.
wenn alle variablen definiert sind, ist ihr zustand klar ohne sich in den untiefen des compilers auskennen zu zu müßen.
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 »

muss theoretisch nicht im Setup sein.

Kannst du - wie du es ja bei anderen Variablen (z.B.: mset) machst, auch im define machen:

Code: Alles auswählen

byte mset = 0;
byte dummy1;
byte s_menue;
byte dummy2;

byte m_i;
byte mm_i;
byte dieser_geht_nicht = 0;
frickelfred56
Beiträge: 230
Registriert: Mo 16. Feb 2015, 13:50

Re: Der AVR-/ARDUINO-Faden

Beitrag von frickelfred56 »

ich habe es jetzt nochmal Probiert.

"dieser_geht...." mit 0 initialisiert - gleiches verhalten wie vor
"dieser_geht...." mit 10 initialisiert - der Zähler zählt, aber dafür "dummy1" nicht mehr.

"dummy1" mit 10 initialisiert und beide laufen :?

Den Zusammenhang versteh ich nicht, und die Glaskugel ist in Revision


frickelfred
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 »

OK.
Verzeih wenn das jetzt brutal ist - aber ich hab so einen mords schnupfen und kann nimmer denken.

Wenn du das nicht verstehst, dann solltest du mal bei arduino "blink" - Example beginnen und die Sprache lernen, sonst wirst du so ein anspruchsvolleres Programm nie (sauber) zum laufen bekommen.
frickelfred56
Beiträge: 230
Registriert: Mo 16. Feb 2015, 13:50

Re: Der AVR-/ARDUINO-Faden

Beitrag von frickelfred56 »

Sir_Death hat geschrieben: Do 12. Dez 2019, 17:51 OK.
Verzeih wenn das jetzt brutal ist - aber ich hab so einen mords schnupfen und kann nimmer denken.

Wenn du das nicht verstehst, dann solltest du mal bei arduino "blink" - Example beginnen und die Sprache lernen, sonst wirst du so ein anspruchsvolleres Programm nie (sauber) zum laufen bekommen.
Am Anfang sah mein "Programm " so wie in dem Beispiel aus. Trotzdem Danke
Benutzeravatar
Weisskeinen
Beiträge: 3942
Registriert: Di 27. Aug 2013, 16:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von Weisskeinen »

Wie sieht's denn mit der Speicherbelegung aus? Ich hatte so ein Verhalten mal, als sich Heap und Stack in die Quere gekommen sind.
Manchmal machen die Compiler aber auch Blödsinn und man muss an einer bestimmten Stelle was umformulieren, damit's klappt. Wenn man dann größere Änderungen am Programm macht, geht das plötzlich wieder, wie zu Beginn formuliert. Dafür ist die Assembler-Ausgabe ganz hilfreich...
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

ich spiel grad rum mit einem MAP Sensor + UNO.
folgender code:

Code: Alles auswählen

void setup() {
	Serial.begin(9600);
}
void loop() {
	Serial.print(analogRead(A0));
	Serial.print("\t");
	Serial.print(analogRead(A1));
	Serial.print("\t");
	Serial.print(analogRead(A2)); //gnd
	Serial.print("\t");
	Serial.println(analogRead(A3));//sensor
}
gibt mir:
830 815 0 839 wenn ich am sensor sauge:
446 439 0 448
das pins die in der luft hängen dem Sensorwert folgen kann ich nachvollziehen.
soweit alles gut.
ich hätte aber gern nur 8bit, das aber subito.
hab mir daher aus dem Netz was zusammengeklaubt (man solle den ADC Free Running mode benutzen):

Code: Alles auswählen

#include "Arduino.h"

int numSamples = 0;
long t, t0;

volatile uint8_t ADCvalue;
volatile uint8_t z1;
volatile uint8_t z2;
volatile uint8_t z3;
volatile uint8_t z4;

void setup() {

	Serial.begin(9600);

	ADCSRA = 0;             // clear ADCSRA register
	ADCSRB = 0;             // clear ADCSRB register
	ADMUX |= (0 & 0x07);    // set A0 analog input pin
	ADMUX |= (1 << REFS0);  // set reference voltage
	ADMUX |= (1 << ADLAR);  // left align ADC value to 8 bits from ADCH register

	// sampling rate is [ADC clock] / [prescaler] / [conversion clock cycles]
	// for Arduino Uno ADC clock is 16 MHz and a conversion takes 13 clock cycles
	//ADCSRA |= (1 << ADPS2) | (1 << ADPS0);    // 32 prescaler for 38.5 KHz
	ADCSRA |= (1 << ADPS2);                     // 16 prescaler for 76.9 KHz
	//ADCSRA |= (1 << ADPS1) | (1 << ADPS0);    // 8 prescaler for 153.8 KHz

	ADCSRA |= (1 << ADATE); // enable auto trigger
	ADCSRA |= (1 << ADIE);  // enable interrupts when measurement complete
	ADCSRA |= (1 << ADEN);  // enable ADC
	ADCSRA |= (1 << ADSC);  // start ADC measurements
}

ISR(ADC_vect) {
	uint8_t tmp;            // temp register for storage of misc data

	tmp = ADMUX;            // read the value of ADMUX register
	tmp &= 0x0F;           // AND the first 4 bits (value of ADC pin being used)

	ADCvalue = ADCH;        // read the sensor value

	if (tmp == 0) {
		z1 = ADCvalue; // put ADCvalue into whatever register you use for ADC0 sensor
		ADMUX++;            // add 1 to ADMUX to go to the next sensor
	} else if (tmp == 1) {
		z2 = ADCvalue; // put ADCvalue into whatever register you use for ADC1 sensor
		ADMUX++;            // add 1 to ADMUX to go to the next sensor
	} else if (tmp == 2) {
		z3 = ADCvalue; // put ADCvalue into whatever register you use for ADC1 sensor
		ADMUX++;            // add 1 to ADMUX to go to the next sensor
	} else if (tmp == 3) {
		z4 = ADCvalue; // put ADCvalue into whatever register you use for ADC2 sensor
		ADMUX &= 0xF8;      // clear the last 4 bits to reset the mux to ADC0
	}
	numSamples++;
}

void loop() {

	if (numSamples >= 4) {
//		Serial.print((char)z1);
//		Serial.print((char)z2);
//		Serial.print((char)z3);
//		Serial.print((char)z4);
		Serial.print(z1);
		Serial.print("\t");
		Serial.print(z2);
		Serial.print("\t");
		Serial.print(z3);
		Serial.print("\t");
		Serial.println(z4);
		numSamples = 0;
	}

//	Serial.print((char)z4);
}
das liefert in ruhe:
198 207 205 31
wenn ich sauge:
115 115 113 0

Da passt doch nix zusammen? also reihenfolge und betrag scheinen nicht zu stimmen.
Hab versucht zu recherchieren und zu verstehn, komm aber nicht weiter :(
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

Der if/else Block ohne endbedingung ist schon mal eine blöde idee. -> geändert. löst die probleme aber nicht.
verkleinern der samplerate zieht zumindest schon mal den letzen kanal auf null. (209 206 205 0 )

Code: Alles auswählen

	ADCSRA |= (1 << ADPS2) | (1 << ADPS0);    // 32 prescaler for 38.5 KHz
	//ADCSRA |= (1 << ADPS2);                     // 16 prescaler for 76.9 KHz
	//ADCSRA |= (1 << ADPS1) | (1 << ADPS0);    // 8 prescaler for 153.8 KHz
ich arbeite dran.

edit:
A0 bis A2 auf Gnd gelegt, der Sensor liegt auf A3.

Code: Alles auswählen

Serial.print(analogRead(A0));
liefert mir den Sensorwert? nun gut, die anderen geben 0 aus, bei 38.5 KHz Samplerate.
Mit 76.9 KHz klappts nicht, 1 kanal wandert mit dem Sensorwert mit (196 32 0 0 )

nochmal edit:
hab gelesen analogRead() wäre blöd, freerunning mode wäre besser.
hab die mal spasseshalber angepasst (ADLAR und nur das high byte ausgeben), und es läuft (45-50kB/s) :lol:
So schaize kanns also nicht sein was die da machen.

Code: Alles auswählen

byte analogRead8(uint8_t pin)
{
	uint8_t low, high;

#if defined(analogPinToChannel)
#if defined(__AVR_ATmega32U4__)
	if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#endif
	pin = analogPinToChannel(pin);
#elif defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
	if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(__AVR_ATmega32U4__)
	if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__)
	if (pin >= 24) pin -= 24; // allow for channel or pin numbers
#else
	if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif

#if defined(ADCSRB) && defined(MUX5)
	// the MUX5 bit of ADCSRB selects whether we're reading from channels
	// 0 to 7 (MUX5 low) or 8 to 15 (MUX5 high).
	ADCSRB = (ADCSRB & ~(1 << MUX5)) | (((pin >> 3) & 0x01) << MUX5);
#endif

	// set the analog reference (high two bits of ADMUX) and select the
	// channel (low 4 bits).  this also sets ADLAR (left-adjust result)
	// to 0 (the default).
#if defined(ADMUX)
#if defined(__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)
	ADMUX = (analog_reference << 4) | (pin & 0x07);
	ADMUX |= (1 << ADLAR);  // left align ADC value to 8 bits from ADCH register
#else
	ADMUX = (analog_reference << 6) | (pin & 0x07);
	ADMUX |= (1 << ADLAR);  // left align ADC value to 8 bits from ADCH register
#endif
#endif

	// without a delay, we seem to read from the wrong channel
	//delay(1);

#if defined(ADCSRA) && defined(ADCL)
	// start the conversion
	sbi(ADCSRA, ADSC);

	// ADSC is cleared when the conversion finishes
	while (bit_is_set(ADCSRA, ADSC));

	// we have to read ADCL first; doing so locks both ADCL
	// and ADCH until ADCH is read.  reading ADCL second would
	// cause the results of each conversion to be discarded,
	// as ADCL and ADCH would be locked when it completed.
	low  = ADCL;
	high = ADCH;
#else
	// we dont have an ADC, return 0
	low  = 0;
	high = 0;
#endif

	// combine the two bytes
//	return (high << 8) | low;
	return high;
}
lommodore
Beiträge: 835
Registriert: So 22. Feb 2015, 14:52

Re: Der AVR-/ARDUINO-Faden

Beitrag von lommodore »

Ich hätte mal ne Frage an die Alteingesessenen AVR'ler hier.

Es geht um ein Timingkritisches Projekt mit einem der neuen ATTinys. Es soll das alte, Analoge D54 Steuersignal eines Strand Lightuing Lichtpults aufbereitet werden und von einem uC zu DMX übersetzt werden. Eine Schaltung, die den Controller mit Interrupts auf das Sync Signal füttert und den ADC mit einem gescheiten Pegel beschickt besteht, und funktioniert. Jetzt muss "nur" noch die Firmware programmiert werden. Dort stellt sich mir die Frage, C oder Assembler? Ersteres hat natürlich viele Vorteile, u.A. auch fertige Libs für DMX etc, in ASM müsste ich das mir selbst herbasteln, dafür ist ASM hardwarenäher und somit schneller. Die kürzesten Pulse sind die Sync Pulse mit 8uS, die in als Interrupt in den Controller gehen. Das ganze Timing Diagram gibts hier https://upload.wikimedia.org/wikipedia/en/e/eb/D54.png. Jetzt ist die Frage, womit ist das besser zu lösen? Ist C dafür schnell genug?

Danke für die Hilfe!
Anse
Beiträge: 2278
Registriert: Mo 12. Aug 2013, 21:30
Wohnort: Bühl (Baden)

Re: Der AVR-/ARDUINO-Faden

Beitrag von Anse »

C auf jeden Fall wenn Du jetzt nicht gerade der Assembler Guru bist. Man kann ja immer noch etwas Inline Assembler einstreuen. Auch wenn das wahrscheinlich nicht nötig sein wird.
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 »

Notfalls gibt es sicher auch noch die Möglichkeit, aus einem ASM-Stückchen eine C-Library zu bauen. Dazu wäre zwar ein Studium des Calling-Interfaces notwendig, aber damit könntest du dann beide Sprachen kombinieren.
Benutzeravatar
ferdimh
Beiträge: 9379
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

Der Geschwindigkeitsunterschied C zu Assembler ist auf dem AVR noch relativ groß, weil der Compiler nicht so clever ist, wie auf dem PC.
Ich konnte da mal >50% rausholen.
C kann Inline-Assembler. Auch aufm AVR.
Damit kann man erstmal "drauf los" programmieren, und wenn die Zeit wirklich knapp ist, das relevante Stücken assemblieren.
Was sehr hilfreich ist: Ein unbelegter Portpin, der zu Beginn der Interruptroutine High gesetzt wird und am Ende (oder nach einer bestimmten kritischen Arbeit) wieder low geht, ermöglicht die Betrachtung der zeitlichen Situation mittels Oszi.
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 »

Wenn ich mir das verlinkte Timing-Diagramm anschaue, geht es wohl darum, die Spannungspegel vor (oder nach?) einem Sync-Impuls zu bestimmen, richtig? In diesem Fall würde ich mir überlegen, ob die A/D-Wandler dafür überhaupt flink genug sind, oder ob eine kleine Hardware (mit z.B. vier Komparatoren) zur Problemlösung nicht einfacher wäre. Das würde m.E. zumindest zu einem wesentlich "entspannteren" Timing für den µC führen ;)
E_Tobi
Beiträge: 640
Registriert: Mo 12. Aug 2013, 22:26

Re: Der AVR-/ARDUINO-Faden

Beitrag von E_Tobi »

Ich würde das so lösen:
Es gibt immer einen Sprung von 0V auf -5V vor einem validen Wert.
Eine kleine Schaltung verschiebt diesen Sprung auf +3.3 auf 0V, und legt das auf einen Portpin.
Über den erzeugst du einen interrupt auf fallende Flanken. Dann hast du das Zeitfenster 15µs bis 50µs um ein paar mal das Signal zu messen. Das sollte zeitmäßig locker gehen.

Das Frame ist zu Ende wenn im Mess-Zeitfenster immer noch -5V Anliegen.
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 »

So wies aussieht werden wohl zukünftige GCC Versionen kein AVR Backend mehr haben:
https://www.mikrocontroller.net/topic/483643
(Johann ist einer derjenigen die sich da so richtig auskennen!)

So werden AVR Firmwares zwar noch mit uralt GCCs von 4 bis 7 gebaut, unter Linux eher kein Problem.
Aber zB bei Windoof10 gibts dann das Damoklesschwert, dass "inkompatible" Software beim halbjährlichen Zwangsupgrade einfach gelöscht wird und nicht mehr installierbar ist.
Microchip macht keinen Finger krumm das zu ändern*, denen sind die AVRs dann wohl doch nicht mehr so wichtig?

Inzwischen gibts ein Bounty, damit sich wer findet das zu ändern.
Also falls wer spenden will ;)

*Der AVR Support ist in deren properitären XC8 Compiler gewandert, aber die free Version kann nicht ordentlich optimieren.

(Irgendwie war es eine gute Idee komplett auf ARM zu wechseln)
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

Naja, dann gibt's einen ARM-/Teensy-Faden. Vielleicht?
Je schneller je besser bitte. :?
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 bei ARM kann ich auch so helfen, insbesondere STM32.
Aber nur ohne Gammlduino Untersatz ;)
Benutzeravatar
ferdimh
Beiträge: 9379
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

(Irgendwie war es eine gute Idee komplett auf ARM zu wechseln)
Ich bin damit irgendwie immer noch nicht so richtig glücklich geworden. Naja, egal.

So wie ich das sehe, ist das technische TODO um den Support zu erhalten garnicht so kompliziert. Schwieriger dürfte sein, die erzeugten Patches auch durch die Bürokratie zu kriegen (davon abgesehen, dass ich das Ganze mal wieder eine saublöde Aktion finde).
Benutzeravatar
sukram
Beiträge: 3063
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Puuh. Ich war gerade über den Jahreswechsel dabei, aus verschiedenen AVR Projekten eins für mich zusammenzufrickeln. Konkret in dem Fall yaMBSiavr (in der Ausprägung eines auf Github gefundenen Bodenfeuchtefühlerprojektes) und Fritzlers BME280 Lib.

Ziel war es, ein kompaktes Raumthermostat, wahlweise mit Analog-In und oder Digital I/O sowie Modbus RS485 auf einem 50x50mm Platinchen herzustellen. Es gibt vergleichbare Module fertig, z.B. von Thermokon (WRF07 P rH AO2V RS485Modbus), da kostet aber der Raumfühler mit Luftfeuchte, Modbus und I/O (0-10V und Digital) mal eben lässig >200Eur...

Derzeit existiert ein kompaktes Layout auf Basis eines Mega88 (der bis zum 328 Pinkompatibel sein sollte). Mit Stepdown von 24V auf 5V und 3.3V LDO für den BME280.

Jetzt überlege ich aber, ob ich das so wirklich baue. Kostenmäßig lande ich irgendwo bei 25-30Eur pro Modul, wenn das Layout keine groben Schnitzer hat (würde bei jlcpcb einkaufen). Schaue ich mich da ein wenkg um, finde ich bei Olimex ein niedliches kleines ESP32 Board mit LAN und PoE für ca 18Eur. Da kommt noch ein BME280 dazu (ca 6Eur) und fertig. Gut, das Modul ist 75mm Lang (+ LAN Stecker) und ich muss eine Sternverkabelung ziehen (Kabel muss so oder so eingebaut werden), aber am Ende lohnt es sich doch gar nicht, weiter über den Eigenbau nachzudenken, oder? Ich meine, wenn jetzt auch der Compilersupport zurückgefahren wird (stört mich jetzt nicht, aber wer weiß, wenn ich in ein paar Jahren da mal dran muss?)

Dass ich dann per LAN und nicht Modbus verkabele, ist egal - die Technik ist eh in einem isolierten Netzwerk...
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 »

Na das ist jetzt nicht zum Panik schieben da.
Dein Projekt wirste schon noch durchziehen können.
Das wird schon so 10J dauern bis da was stirbt.
Die letzte WinAVR Version is ja auch von 2011 :mrgreen:

Du hast eher das Problem der hohen Temperaturabweichung beim BME280, also pack noch ein LM75 daneben.

Ein ESP32 Brett mit POE und so günstig?
Jetz bin ich neugierig, zeig mal bitte.
Ich hab mir mal ein POE Switch zugelegt, weil ich diverses Testequipment mit ModbusTCP und POE bauen will.
ferdimh hat geschrieben: Sa 18. Jan 2020, 14:06 Ich bin damit irgendwie immer noch nicht so richtig glücklich geworden.
Wo drückt der ARM denn im Schuh?
Benutzeravatar
sukram
Beiträge: 3063
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Mal schauen, ich werde wohl erstmal vorsichtig in beide Richtungen experimentieren. Aufgrund akuter Faulheit bin ich aber geneigt, die weniger aufwendige Variante zu wählen.

Das ESP Board wäre das hier:

https://www.olimex.com/Products/IoT/ESP ... e-hardware

Ja, Versand und Steuer usw., aber trotzdem günstig, wenn man ein paar mehr kauft.

Mit den Temperaturwerten muss ich mal sehn, Platz für einen LM75 wäre noch, ggf. auch im TO Gehäuse mit langen Beinen - damit das Board weniger Einfluss hat.
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 »

Hmm, schade.
Leider nicht galvanisch getrennt.

Wenn die Temperatur so richtig genau sein soll gibts auchnoch sone Scherze:
https://www.mouser.de/ProductDetail/634-SI7051-A20-IM
https://www.mouser.de/ProductDetail/403-STS21
Benutzeravatar
sukram
Beiträge: 3063
Registriert: Sa 10. Mär 2018, 18:27
Wohnort: Leibzsch

Re: Der AVR-/ARDUINO-Faden

Beitrag von sukram »

Den gibts auch in galvanisch getrennt, kostet knapp 7 eur mehr:
https://www.olimex.com/Products/IoT/ESP ... e-hardware

Ich bin mir nicht sicher, ob ich die Temperatur so genau brauche... Wichtig wäre mir nur, dass eine eventuelle Abweichung im Bereich 10-40°C linear bleibt, damit man die mit einem Offset rausrechnen kann.

Nunja. Schritt 1 wird erstmal ein Prototyp in Lochraster werden, da habe ich alles griffbereit. Wenn es klappt, dass der AVR mit 8 oder 10Mhz immer noch schnell genug ist, werde ich die Platine komplett auf 3.3V umstricken. Aber erstmal "im großen" Testen.
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 »

Ja, da hilft dann nur experimentieren.

Die bei Olimex sind aber auch lustig.
Ich weis jetzt nicht warum die das so gemacht haben:
Die verbauen einen "wunschlos glücklich" POE IC von SI -> SI3402.
Der hat die beiden POE Gleichrichter drinne und einen Flyback DC/DC für die galvanische Trennung.
Aber stattdessen nehmen die einen speziellen RJ45 MagJack mit integrierten Gleichrichter (die Dinger kosten mehr) und nutzen den DCDC des SI nur als StepDown.
Dahinter packen die dann einen 5V->5V DCDC für die galvanische TRennung.
Äh wädd?

Mit 25€ kom ich aber schon in die Selbstbauregion, vor allem hab ich dann einen STM32 drinne und muss nicht auf den ESP32 umschwenken.
(WLAN brauchts erstmal nicht).
Aber jetzt kenn ich einen wunschlos glücklich POE IC :lol:
Benutzeravatar
ferdimh
Beiträge: 9379
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

Wo drückt der ARM denn im Schuh?
Komplexität überall.
Das ist weniger ein Problem des Prozessorkerns als der gefühlt 200 möglichen eingebauten oder nicht eingebauten Peripheriegeräte, die dann auch noch relativ komplex getaktet werden können.
Und dann gibts keine so etablierte Umgebung wie gcc+avr-libc, die "einfach so" da ist (=bei $LINUX_DISTRIBUTION enthalten). Wenn ich ein altes Projekt anfasse, gehts immer mit "wo habe ich denn jetzt die passenden libs+compiler archiviert?" los.
Das Problem würde sich mit steigender Etablierung lösen, wo sich wieder einzelne Typen (und auch Enwicklungsumgebungen) durchsetzen...
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 »

ferdimh hat geschrieben: So 19. Jan 2020, 13:03 Und dann gibts keine so etablierte Umgebung wie gcc+avr-libc, die "einfach so" da ist (=bei $LINUX_DISTRIBUTION enthalten).
Doch ;)
https://developer.arm.com/tools-and-sof ... /downloads
Natürlich kannst du den GCC auch selber zusammennageln wenn du auf Schmerzen stehst*.
Der avr-gcc ist doch auch nicht direkt enthalten und muss als Binärpaket nachinstalliert werden.

* Das ist auch immer das Selbe: gcc+newlib in der neusten Version und dann gehts los.
https://wiki.ubuntuusers.de/Archiv/GNU_ARM-Toolchain/
ferdimh hat geschrieben: So 19. Jan 2020, 13:03 Komplexität überall.
Das ist weniger ein Problem des Prozessorkerns als der gefühlt 200 möglichen eingebauten oder nicht eingebauten Peripheriegeräte
So viel gibts davon garnicht, das sind immer dieselben SPI/UART/I2C etc, nur eben sehr viele paralel davon im Silizium.
Daher darfste eben nicht sowas schreiben wie: uart2_putc(char c)
sondern: uart_putc(struct uartregs* uart, char c);
struct uartregs ist ein memory mappd struct der uart Register und das ist Teil des Inits für zB deine SPI LCD Lib, kommt also im Anwendungscode nicht an.
Aber ja für den SDIO/Ethernet Block musste mehr Hirnschmlz investieren, aber sowas hat der AVR erst garnicht.
ferdimh hat geschrieben: So 19. Jan 2020, 13:03 die dann auch noch relativ komplex getaktet werden können.
https://www.youtube.com/watch?v=pQsyuiPl1WY
Will sagen: gib Stoff! Wenn du nicht Stromsparen musst, dann dreh per PLL alles so hoch wies geht ;)

Sobald du deine Grundblöcke hast ist das auch nurnoch mit Lego spielen.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

Ich werd wahnsinnig.
Die aufgabe: einzelne Bytes über die serielle schnittstelle an den Labtop mit win10 schicken. Schnell.
Hab das getestet mit einem Uno, leuft.
Dann halbfertig aufgebaut mit Nano (CH340), hier kommt nur noch mist am laptop an, bei baudraten größer 230400.
Am Kabel liegts nicht, hab 3 ausprobiert.
stromversorgung usb/batterie macht auch keinen unterschied.
Treiber? ist 3.5.2019.1
unter win7 hatte das funktioniert bis hoch zu 921600. :(
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 »

schon mal einen anderen nano genommen? - nicht dass der Eine einen Schaden hat?
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

ja hab ich.
hab auch bei den erweiterten seriellen einstellungen über den gerätemanager nix ausser fifo ja/nein.
da gabs doch noch mehr! latency etc.?
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 »

was hat der UNO für einen USB-Chip? - Dann würde ich mir einen Nano mit gleichem Chip besorgen.
Benutzeravatar
Christian Knüll
Beiträge: 39
Registriert: So 2. Nov 2014, 19:45
Wohnort: Höpfingen
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Christian Knüll »

Der CH340 schafft locker 1Mbaud - an dem sollte es nicht liegen.
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 »

Wenn es kein Fake ist ;)

Ich denke nur, dass es - wenn es mit dem UNO geht und mit dem NANO nicht - an der Platine liegen muss, nicht am Rechner, nicht an der SW am Rechner, nicht an der SW für den Arduino.
Darum meine Frage nach einem möglichen Unterschied zwischen den Platinen.
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

glaub der uno hat nen ftdi.
Aber der ch340 kanns ja, und zwar genau dieser, hat er ja schon bewiesen.
Ich denke eher in richtung win10 bzw. treiber.
und da bin ich grad hilflos.
Wo kann ich bei dem win 10 die latency einstellen? :evil:
2020-01-30 08_17_32-Geräte-Manager.png
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...
dafür scheint der CH340 nicht ganz so toll geeignet zu sein. Er kann zwar 1 Mbaud, wenn die Daten in einem Strom kommen, aber bis sie ankommen...
https://forum.hobbycomponents.com/viewt ... 1782#p6387
https://www.alfaowner.com/threads/vag-c ... ue.523161/

latency kannst du einstellen, wenn es der Treiber unterstützt - FTDI kann das...
https://www.campbellsci.com/blog/usb-rs ... ble-issues
ch_ris
Beiträge: 3029
Registriert: Mo 30. Nov 2015, 10:08

Re: Der AVR-/ARDUINO-Faden

Beitrag von ch_ris »

mit der Lupe nochmal geguckt: ist kein ftdi auf dem Uno, sondern Atmega8U2 (...programmed as a USB-to-serial converter.)
Mag sein das der ch340 nicht so toll ist, aber es ging ja vorher mit win7, für mich bleibt der Arsch in der Geschichte das f....g win10.
Das ist jetzt kein Lösungsansatz, aber die Schuldfrage muss geklärt sein :lol: :cry:
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 »

OK, wenn dir jetzt leichter ist ;)
Antworten