Der AVR-/ARDUINO-Faden
Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese
Re: Der AVR-/ARDUINO-Faden
Ist auch so. Warum sich das kompilieren lässt ist mir aber ein Rätsel....
Re: Der AVR-/ARDUINO-Faden
Arduino eben ...
Gegenprobe:
Ergibt im (auf? hinter?) Monitor:
Da ist sie wieder, die Fünfundneunzig.
Und nun alle gemeinsam:
Ergibt folgende Ausgabe:
Die Fünfundneunzig ist schon belegt, die Einhundertsieben ist frei.
Etwas in der Art hätte ich auch erwartet.
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;
}
Code: Alles auswählen
addivari(1, 2): 3
zeiger(4, 5): 9
zeiger: 95
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;
}
Code: Alles auswählen
millis(): 0
millis: 95
addivari(1, 2): 3
zeiger(4, 5): 9
zeiger: 107
Etwas in der Art hätte ich auch erwartet.
Ich weiß noch nicht, wonach ich suche. Aber ich fange schon mal an.sysconsol hat geschrieben:Einer von uns beiden ist ein Depp: Das Netz oder ich.
Re: Der AVR-/ARDUINO-Faden
Noch ein Versuch:
Auf der Konsole:
dis2.dump:
Etwas übersichtlicher:
dis3.dump:
Da muss ich erstmal wachsen - das ist mir gerade etwas zu hoch
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;
}
Code: Alles auswählen
avr-objdump -D sketch_dec09a.ino.hex -m avr5 >/media/ramdisk/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
Code: Alles auswählen
avr-objdump -S sketch_dec09a.ino.elf -m avr5 >/media/ramdisk/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>
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Nicht mit genau diesen, aber mit vergleichbaren. Das geht ziemlich unkompliziert mit den entsprechenden Libraries. Verdrahten, aufrufen, fertig.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?
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.
- Später Gast
- Beiträge: 1705
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Echt jetzt? Habs schon geordert. Da steht man könne sie einzeln runterschneiden und es gibt auch massig Tuts wie das einzubinden ist. Hmmm.Weisskeinen hat geschrieben: ↑Mo 9. Dez 2019, 21:04 Nicht mit genau diesen, aber mit vergleichbaren.
Okay, danke. da hätt ich sicher n paar gehimmelt sonst.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.
Re: Der AVR-/ARDUINO-Faden
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.
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.
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
Ä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...Später Gast hat geschrieben: ↑Di 10. Dez 2019, 00:10Echt jetzt? Habs schon geordert. Da steht man könne sie einzeln runterschneiden und es gibt auch massig Tuts wie das einzubinden ist. Hmmm.Weisskeinen hat geschrieben: ↑Mo 9. Dez 2019, 21:04 Nicht mit genau diesen, aber mit vergleichbaren.
- Später Gast
- Beiträge: 1705
- Registriert: Di 5. Apr 2016, 22:03
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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.
Hmm ja Stromverbrauch. mal schauen, ob ich das überhaupt voll aufdrehen muss, bei den Siebensegmentanzeigen reicht ja auch Stufe 1 oder 2 von 16.
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
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]
danke fürs anschauen und ev. Antwort
frickelfred
man kann das auch anders und besser machen, try and error eben
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);
}
danke fürs anschauen und ev. Antwort
frickelfred
man kann das auch anders und besser machen, try and error eben
Re: Der AVR-/ARDUINO-Faden
nicht initialisiert würd ich sagen.
byte dieser_geht_nicht=0;
das gilt für die anderen auch
byte dieser_geht_nicht=0;
das gilt für die anderen auch
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
dann musst du in der Setup initialisieren/definieren.
die variable gibt's, aber der wert ist unklar.
also "Was?++" geht dann halt nicht.
(nehme ich an)
Code: Alles auswählen
byte dieser_geht_nicht;
//------------------------------------setup---------------------
void setup() {
dieser_geht_nicht=0;
// put your setup code here, to run once:
also "Was?++" geht dann halt nicht.
(nehme ich an)
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
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?
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
Gegenfrage
meine Ersatzvarialble "dummy1" geht und macht das was "dieser_geht_nicht" tun soll?
meine Ersatzvarialble "dummy1" geht und macht das was "dieser_geht_nicht" tun soll?
Re: Der AVR-/ARDUINO-Faden
herrje,
dummy1 definierst du in der setup.
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.
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());
wenn alle variablen definiert sind, ist ihr zustand klar ohne sich in den untiefen des compilers auskennen zu zu müßen.
Re: Der AVR-/ARDUINO-Faden
muss theoretisch nicht im Setup sein.
Kannst du - wie du es ja bei anderen Variablen (z.B.: mset) machst, auch im define machen:
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;
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
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
"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
Re: Der AVR-/ARDUINO-Faden
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.
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.
-
- Beiträge: 240
- Registriert: Mo 16. Feb 2015, 13:50
Re: Der AVR-/ARDUINO-Faden
Am Anfang sah mein "Programm " so wie in dem Beispiel aus. Trotzdem DankeSir_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.
- Weisskeinen
- Beiträge: 3950
- Registriert: Di 27. Aug 2013, 16:19
Re: Der AVR-/ARDUINO-Faden
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...
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...
Re: Der AVR-/ARDUINO-Faden
ich spiel grad rum mit einem MAP Sensor + UNO.
folgender code:
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):
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
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
}
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);
}
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
Re: Der AVR-/ARDUINO-Faden
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 )
ich arbeite dran.
edit:
A0 bis A2 auf Gnd gelegt, der Sensor liegt auf A3.
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)
So schaize kanns also nicht sein was die da machen.
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
edit:
A0 bis A2 auf Gnd gelegt, der Sensor liegt auf A3.
Code: Alles auswählen
Serial.print(analogRead(A0));
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)
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;
}
Re: Der AVR-/ARDUINO-Faden
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!
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!
Re: Der AVR-/ARDUINO-Faden
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.
Re: Der AVR-/ARDUINO-Faden
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.
Re: Der AVR-/ARDUINO-Faden
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.
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.
Re: Der AVR-/ARDUINO-Faden
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
Re: Der AVR-/ARDUINO-Faden
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.
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.
- Fritzler
- Beiträge: 12604
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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)
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)
Re: Der AVR-/ARDUINO-Faden
Naja, dann gibt's einen ARM-/Teensy-Faden. Vielleicht?
Je schneller je besser bitte.
Je schneller je besser bitte.
- Fritzler
- Beiträge: 12604
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Also bei ARM kann ich auch so helfen, insbesondere STM32.
Aber nur ohne Gammlduino Untersatz
Aber nur ohne Gammlduino Untersatz
Re: Der AVR-/ARDUINO-Faden
Ich bin damit irgendwie immer noch nicht so richtig glücklich geworden. Naja, egal.(Irgendwie war es eine gute Idee komplett auf ARM zu wechseln)
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).
Re: Der AVR-/ARDUINO-Faden
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...
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...
- Fritzler
- Beiträge: 12604
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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
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.
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
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.
Wo drückt der ARM denn im Schuh?
Re: Der AVR-/ARDUINO-Faden
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.
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.
- Fritzler
- Beiträge: 12604
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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
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
Re: Der AVR-/ARDUINO-Faden
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.
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.
- Fritzler
- Beiträge: 12604
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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
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
Re: Der AVR-/ARDUINO-Faden
Komplexität überall.Wo drückt der ARM denn im Schuh?
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...
- Fritzler
- Beiträge: 12604
- Registriert: So 11. Aug 2013, 19:42
- Wohnort: D:/Berlin/Adlershof/Technologiepark
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
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/
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.
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.
Re: Der AVR-/ARDUINO-Faden
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.
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.
Re: Der AVR-/ARDUINO-Faden
schon mal einen anderen nano genommen? - nicht dass der Eine einen Schaden hat?
Re: Der AVR-/ARDUINO-Faden
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.?
hab auch bei den erweiterten seriellen einstellungen über den gerätemanager nix ausser fifo ja/nein.
da gabs doch noch mehr! latency etc.?
Re: Der AVR-/ARDUINO-Faden
was hat der UNO für einen USB-Chip? - Dann würde ich mir einen Nano mit gleichem Chip besorgen.
- Christian Knüll
- Beiträge: 40
- Registriert: So 2. Nov 2014, 19:45
- Wohnort: Höpfingen
- Kontaktdaten:
Re: Der AVR-/ARDUINO-Faden
Der CH340 schafft locker 1Mbaud - an dem sollte es nicht liegen.
Re: Der AVR-/ARDUINO-Faden
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.
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.
Re: Der AVR-/ARDUINO-Faden
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?
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?
Re: Der AVR-/ARDUINO-Faden
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
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
Re: Der AVR-/ARDUINO-Faden
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
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
Re: Der AVR-/ARDUINO-Faden
OK, wenn dir jetzt leichter ist