Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #223056 > unrolled thread

Rechnen ist schwer

Back to article view | Back to de.sci.electronics

Contents

  Rechnen ist schwer Peter Thoms <dl6lat@darc.de> - 2017-02-10 10:51 +0100
    Re: Rechnen ist schwer Udo Pi <UpNg$0001@ifmd.de> - 2017-02-10 11:26 +0100
    Re: Rechnen ist schwer "MaWin" <me@private.net> - 2017-02-10 11:54 +0100
      Re: Rechnen ist schwer Peter Thoms <dl6lat@darc.de> - 2017-02-10 12:38 +0100
      Re: Rechnen ist schwer Peter Thoms <dl6lat@darc.de> - 2017-02-10 12:40 +0100
        Re: Rechnen ist schwer Edzard Egberts <news@edzeg.net> - 2017-02-10 13:17 +0100
          Re: Rechnen ist schwer Heiko Lechner <no.spam.to.me@arcor.de> - 2017-02-10 13:32 +0100
            Re: Rechnen ist schwer Edzard Egberts <news@edzeg.net> - 2017-02-10 15:15 +0100
              Re: Rechnen ist schwer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2017-02-10 16:28 +0100
                Re: Rechnen ist schwer Edzard Egberts <news@edzeg.net> - 2017-02-10 16:46 +0100
              Re: Rechnen ist schwer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-02-11 13:00 +0100
        Re: Rechnen ist schwer Michael Bäuerle <michael.baeuerle@stz-e.de> - 2017-02-10 13:59 +0100
          Re: Rechnen ist schwer Gerald Oppen <Gerald.Oppen@web.de> - 2017-02-10 20:07 +0100
            Re: Rechnen ist schwer Peter Thoms <dl6lat@darc.de> - 2017-02-11 00:35 +0100
            Re: Rechnen ist schwer Michael Bäuerle <michael.baeuerle@gmx.net> - 2017-02-11 16:00 +0000
              Re: Rechnen ist schwer Michael Schwingen <news-1457978346@discworld.dascon.de> - 2017-02-11 16:26 +0000
                Re: Rechnen ist schwer Michael Bäuerle <michael.baeuerle@gmx.net> - 2017-02-11 16:55 +0000
        Re: Rechnen ist schwer "MaWin" <me@private.net> - 2017-02-10 14:49 +0100
    Re: Rechnen ist schwer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-02-10 13:46 +0100
      Re: Rechnen ist schwer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2017-02-10 16:30 +0100
        Re: Rechnen ist schwer Michael Bäuerle <michael.baeuerle@stz-e.de> - 2017-02-10 17:02 +0100
        Re: Rechnen ist schwer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-02-11 13:21 +0100
          Re: Rechnen ist schwer Peter Thoms <dl6lat@darc.de> - 2017-02-11 16:32 +0100
          Re: Rechnen ist schwer Peter Thoms <dl6lat@darc.de> - 2017-02-11 16:45 +0100
            Re: Rechnen ist schwer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-02-13 00:06 +0100
              Re: Rechnen ist schwer Peter Thoms <dl6lat@darc.de> - 2017-02-13 18:52 +0100
    Re: Rechnen ist schwer Peter Thoms <dl6lat@darc.de> - 2017-02-10 15:26 +0100
    Re: Rechnen ist schwer Rafael Deliano <rafael_deliano@arcor.de> - 2017-02-10 17:20 +0100
      Re: Rechnen ist schwer Peter Thoms <dl6lat@darc.de> - 2017-02-11 00:44 +0100

Page 1 of 2  [1] 2  Next page →

#223056 — Rechnen ist schwer

Hallo,

wie denn das?

Ich stoppel gerade an einem AVR-Prozessor in C und bekomme vom 10-Bit 
AD-Wandler einen int-Wert von 8-Bit heraus, der mir erst mal reicht.

In dummer Weise aber nicht lange:
Was ich aber für eine Regelung bräuchte wäre einen Nullpunkt, mittig im 
Wertebereich.
Bspw. wäre int. 100 der Nullpunmkt (Initialwert, man trifft ja nie genau 
127) und Abweichungen lägen linear um die 100 verteilt herum.

Wie geht das?
Mit 25 Fallunterscheidungen im Integer-Bereich bleiben oder aber
wie, die Betonung liegt auf wie, umstellen auf signed Integer?


peter

[toc] | [next] | [standalone]

#223061

Wenn Du in der Regelung "signed" arbeitest, solltest Du den Wert in 
signed umwandeln:

10bit unsigned in signed int umwandeln, dann den Offset (127) abziehen.

Gruss Udo

[toc] | [prev] | [next] | [standalone]

#223066

"Peter Thoms" <dl6lat@darc.de> schrieb im Newsbeitrag 
news:o7k2f4$ln$1@news.albasani.net...

> Was ich aber für eine Regelung bräuchte wäre einen Nullpunkt, mittig im 
> Wertebereich.
> Bspw. wäre int. 100 der Nullpunmkt (Initialwert, man trifft ja nie genau 
> 127) und Abweichungen lägen linear um die 100 verteilt herum.

100 abziehen ? Das Ergebnis in C hat dann sowieso 16 bit.

-- 
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

[toc] | [prev] | [next] | [standalone]

#223067

Am 10.02.2017 um 11:54 schrieb MaWin:
> "Peter Thoms" <dl6lat@darc.de> schrieb im Newsbeitrag
> news:o7k2f4$ln$1@news.albasani.net...
>
>> Was ich aber für eine Regelung bräuchte wäre einen Nullpunkt, mittig
>> im Wertebereich.
>> Bspw. wäre int. 100 der Nullpunmkt (Initialwert, man trifft ja nie
>> genau 127) und Abweichungen lägen linear um die 100 verteilt herum.
>
> 100 abziehen ? Das Ergebnis in C hat dann sowieso 16 bit.
Am 10.02.2017 um 11:26 schrieb Udo Pi:
> Wenn Du in der Regelung "signed" arbeitest, solltest Du den Wert in
> signed umwandeln:
>
> 10bit unsigned in signed int umwandeln, dann den Offset (127) abziehen.
Hallo,

ja, gerne hätte ich das so.
Wäre das eine korrekte Umwandlung:

sign int 16Bit Rechenwert = int 8 Bit AD-WandlerWert

und gut?


Peter

[toc] | [prev] | [next] | [standalone]

#223068

Am 10.02.2017 um 11:54 schrieb MaWin:
> "Peter Thoms" <dl6lat@darc.de> schrieb im Newsbeitrag
> news:o7k2f4$ln$1@news.albasani.net...
>
>> Was ich aber für eine Regelung bräuchte wäre einen Nullpunkt, mittig
>> im Wertebereich.
>> Bspw. wäre int. 100 der Nullpunmkt (Initialwert, man trifft ja nie
>> genau 127) und Abweichungen lägen linear um die 100 verteilt herum.
>
> 100 abziehen ? Das Ergebnis in C hat dann sowieso 16 bit.
>
Hallo,

ja, gerne hätte ich das so.
Wäre das eine korrekte Umwandlung:

sign_int_16Bit_Rechenwert = int_8_Bit_AD-WandlerWert

und gut?


Peter

[toc] | [prev] | [next] | [standalone]

#223072

Peter Thoms wrote:
> Am 10.02.2017 um 11:54 schrieb MaWin:
>> "Peter Thoms" <dl6lat@darc.de> schrieb im Newsbeitrag
>> news:o7k2f4$ln$1@news.albasani.net...
>>
>>> Was ich aber für eine Regelung bräuchte wäre einen Nullpunkt, mittig
>>> im Wertebereich.
>>> Bspw. wäre int. 100 der Nullpunmkt (Initialwert, man trifft ja nie
>>> genau 127) und Abweichungen lägen linear um die 100 verteilt herum.
>>
>> 100 abziehen ? Das Ergebnis in C hat dann sowieso 16 bit.
>>
> Hallo,
> 
> ja, gerne hätte ich das so.
> Wäre das eine korrekte Umwandlung:
> 
> sign_int_16Bit_Rechenwert = int_8_Bit_AD-WandlerWert

Nimm' doch bitte richtige Typen ohne implizite Annahmen, das oben ist
nur richtig, wenn "int_8_Bit" unsigned ist:

unsigned char AD_Value= Get_ADC() >> 2;	// 10bit als 8bit uchar lesen
signed short int Calc= AD_Value;
	// das ordnet Calc positive Werte von 0..255 zu


char AD_Value= Get_ADC() >> 2;	// 10bit als 8bit char lesen
signed short int Calc= AD_Value;
	// das ordnet Calc positive und negative Werte zu

Im zweiten Fall werden alle Werte größer 127 als negative Zahlen zugeordnet.

[toc] | [prev] | [next] | [standalone]

#223077

Am 10.02.2017 um 13:17 schrieb Edzard Egberts:

> Nimm' doch bitte richtige Typen ohne implizite Annahmen, das oben ist
> nur richtig, wenn "int_8_Bit" unsigned ist:
> 
> unsigned char
> signed short int
> char

stdint.h:

int8_t
int16_t
int32_t
uint8_t
uint16_t
uint32_t

[toc] | [prev] | [next] | [standalone]

#223105

Heiko Lechner wrote:
> Am 10.02.2017 um 13:17 schrieb Edzard Egberts:
> 
>> Nimm' doch bitte richtige Typen ohne implizite Annahmen, das oben ist
>> nur richtig, wenn "int_8_Bit" unsigned ist:
>>
>> unsigned char
>> signed short int
>> char
> 
> stdint.h:
> 
> int8_t
> int16_t
> int32_t
> uint8_t
> uint16_t
> uint32_t

Ich kann nicht davon ausgehen, dass Pter diese typedefs bekannt sind und
die Möglichkeit, Definitionen abzukürzen, fügt meinem Beitrag auch
nichts hinzu. Was Du nicht ganz ausgeschrieben hast:

typedef unsigned char uint8_t;
typedef signed short int int32_t;
typedef signed char int8_t;

[toc] | [prev] | [next] | [standalone]

#223117

On 10.02.2017 15:15, Edzard Egberts wrote:

> Ich kann nicht davon ausgehen, dass Pter diese typedefs bekannt sind und
> die Möglichkeit, Definitionen abzukürzen, fügt meinem Beitrag auch
> nichts hinzu. Was Du nicht ganz ausgeschrieben hast:
> 
> typedef unsigned char uint8_t;
> typedef signed char int8_t;

Die zwei sind OK.

> typedef signed short int int32_t;

Das ist aber Quatsch:

signed short int x;
_Static_assert(sizeof(x) == 4, "Failed");


x.c:2:1: error: static assertion failed: "Failed"
 _Static_assert(sizeof(x) == 4, "Failed");

Die stdint.h Typen sind immer zu bevorzugen, wenn man eine bestimmte
Wortbreite benötigt. Außerdem sind sie standardisiert.

Gruß,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#223120

Johannes Bauer wrote:
> On 10.02.2017 15:15, Edzard Egberts wrote:
> 
>> typedef signed short int int32_t;
> 
> Das ist aber Quatsch:

Stimmt, das sollte so aussehen:

typedef signed short int int16_t;

> Die stdint.h Typen sind immer zu bevorzugen, wenn man eine bestimmte
> Wortbreite benötigt. Außerdem sind sie standardisiert.

Ich benutze stdint.h selber, ich kenne aber auch den Unterschied
zwischen "eingebauten" Typen und Definitionen.

[toc] | [prev] | [next] | [standalone]

#223179

Am 10.02.2017 um 15:15 schrieb Edzard Egberts:

> Ich kann nicht davon ausgehen, dass Pter diese typedefs bekannt sind und
> die Möglichkeit, Definitionen abzukürzen, fügt meinem Beitrag auch
> nichts hinzu. Was Du nicht ganz ausgeschrieben hast:
>
> typedef unsigned char uint8_t;
> typedef signed short int int32_t;
> typedef signed char int8_t;

Solche Definitionen sind compiler- bzw. systemspezifisch, eigene 
typedefs sind keinesfalls portabel. Wie Johannes bereits geschrieben 
hat, sollte man ausschließlich diese Standard-Typnamen verwenden, und 
sie nicht durch eigene Definitionen ersetzen.

Seit den 64 Bit Prozessoren kann man sich ja nicht mal mehr drauf 
verlassen, daß int und Pointer die gleiche Länge haben, was lange Zeit 
zum Grundwissen eines jeden C Programmierers gehört hat.

DoDi

[toc] | [prev] | [next] | [standalone]

#223088

Peter Thoms wrote:
> 
> [...]
> ja, gerne hätte ich das so.
> Wäre das eine korrekte Umwandlung:
> 
> sign_int_16Bit_Rechenwert = int_8_Bit_AD-WandlerWert
> 
> und gut?

Auch wenn die AVR A/D-Wandler keine Heldentaten vollbringen wäre es
hier, wenn du mit 16Bit weiterrechnen willst, doch sinnvoll alle 10 Bits
auszulesen:

   uint16_t v;
   /* Bit ADLAR in Register ADMUX nicht gesetzt => "right adjusted" */
   v = (uint16_t) ADCL;  /* ADCL muss zuerst gelesen werden */
   v |= (uint16_t) ADCH << 8;

"right adjusted" bedeutet die 8 LSBs in ADCL und die 2 MSBs in ADCH.
In v steht nun das Ergebnis mit vollen 10 Bit (aber noch unsigned).

Mit 8 Bit signed Werten zu rechnen ist in C ein bisschen gefährlich
wegen der "integer promotion" (interne Umwandlung zu int, auf AVR also
16 Bit). Aus z.B. dem 8 Bit Wert -128 (0x80) kann so ungewollt 0xFF80
werden (65408 als unsigned interpretiert), da negative Zahlen in
Zweierkomplement-Darstellung mit 1 aufgefüllt werden, postive aber
mit 0. Siehe hierzu auch:
<https://www.securecoding.cert.org/confluence/display/c/INT02-C.+Understand+integer+conversion+rules>

[toc] | [prev] | [next] | [standalone]

#223138

Am 10.02.2017 um 13:59 schrieb Michael Bäuerle:

>
> Auch wenn die AVR A/D-Wandler keine Heldentaten vollbringen wäre es
> hier, wenn du mit 16Bit weiterrechnen willst, doch sinnvoll alle 10 Bits
> auszulesen:
>
>    uint16_t v;
>    /* Bit ADLAR in Register ADMUX nicht gesetzt => "right adjusted" */
>    v = (uint16_t) ADCL;  /* ADCL muss zuerst gelesen werden */
>    v |= (uint16_t) ADCH << 8;

Mit dem IAR-Compiler zumindest funktioniert der 16Bit-Zugriff 
automatisch ohne diese manuelle schiebereien..
ui16_AdcValue = ADC;


> "right adjusted" bedeutet die 8 LSBs in ADCL und die 2 MSBs in ADCH.
> In v steht nun das Ergebnis mit vollen 10 Bit (aber noch unsigned).
>
> Mit 8 Bit signed Werten zu rechnen ist in C ein bisschen gefährlich
> wegen der "integer promotion" (interne Umwandlung zu int, auf AVR also
> 16 Bit). Aus z.B. dem 8 Bit Wert -128 (0x80) kann so ungewollt 0xFF80
> werden (65408 als unsigned interpretiert), da negative Zahlen in
> Zweierkomplement-Darstellung mit 1 aufgefüllt werden, postive aber
> mit 0. Siehe hierzu auch:
> <https://www.securecoding.cert.org/confluence/display/c/INT02-C.+Understand+integer+conversion+rules>

Der andere Weg ist wenn die 8Bit reichen (warum den 8bitter mit 16Bit 
Quälen:)
ui8_AdcValue = ADCL;


Gerald

[toc] | [prev] | [next] | [standalone]

#223147

Am 10.02.2017 um 20:07 schrieb Gerald Oppen:
> Der andere Weg ist wenn die 8Bit reichen (warum den 8bitter mit 16Bit
> Quälen:)
> ui8_AdcValue = ADCL;
Hallo,

das ist der Punkt, das Wertverhältnis im Rechenweg untereinander.

Ich hätte sonst eine 8-fache Verstärkung drinn, die ich vor dem nächsten 
"Vergleicher" eh wieder wegdrücken muss.

Ich hatte ADCH abgefragt (linksbündige Ausgabe) und erfuhr hier als 
Alternative den Shift-Befehl. OK, ich hätte auch einfach stumpf durch 8 
teilen können.


peter

[toc] | [prev] | [next] | [standalone]

#223204

Gerald Oppen wrote:
> Am 10.02.2017 um 13:59 schrieb Michael Bäuerle:
> > 
> > Auch wenn die AVR A/D-Wandler keine Heldentaten vollbringen wäre es
> > hier, wenn du mit 16Bit weiterrechnen willst, doch sinnvoll alle 10 Bits
> > auszulesen:
> > 
> >    uint16_t v;
> >    /* Bit ADLAR in Register ADMUX nicht gesetzt => "right adjusted" */
> >    v = (uint16_t) ADCL;  /* ADCL muss zuerst gelesen werden */
> >    v |= (uint16_t) ADCH << 8;
> 
> Mit dem IAR-Compiler zumindest funktioniert der 16Bit-Zugriff 
> automatisch ohne diese manuelle schiebereien..
> ui16_AdcValue = ADC;

AFAIK kann der GCC das nicht.

[toc] | [prev] | [next] | [standalone]

#223205

On 2017-02-11, Michael Bäuerle <michael.baeuerle@gmx.net> wrote:
>> Mit dem IAR-Compiler zumindest funktioniert der 16Bit-Zugriff 
>> automatisch ohne diese manuelle schiebereien..
>> ui16_AdcValue = ADC;
>
> AFAIK kann der GCC das nicht.

Erzähl' das bitte meinem AVR-GCC nicht:

// return ADC value if ready, -1 if not
static int16_t get_adc(void)
{
  // loop_until_bit_is_set(ADCSRA, ADIF);
  if (ADCSRA & _BV(ADIF))
  {
    ADCSRA |= _BV(ADIF); 
    return ADC;
  }
  return -1;
}

cu
Michael

[toc] | [prev] | [next] | [standalone]

#223207

Michael Schwingen wrote:
> On 2017-02-11, Michael Bäuerle <michael.baeuerle@gmx.net> wrote:
> > Gerald Oppen wrote:
> > > 
> > > Mit dem IAR-Compiler zumindest funktioniert der 16Bit-Zugriff 
> > > automatisch ohne diese manuelle schiebereien..
> > > ui16_AdcValue = ADC;
> > 
> > AFAIK kann der GCC das nicht.
> 
> Erzähl' das bitte meinem AVR-GCC nicht:
> 
> // return ADC value if ready, -1 if not
> static int16_t get_adc(void)
> {
>   // loop_until_bit_is_set(ADCSRA, ADIF);
>   if (ADCSRA & _BV(ADIF))
>   {
>     ADCSRA |= _BV(ADIF); 
>     return ADC;
>   }
>   return -1;
> }

Danke für die Korrektur. Ich habe mal in die Headerfiles einer über
10 Jahre alten libc geschaut (memory mapped I/O bei einem ATmega128):
| 
| #define ADC       _SFR_IO16(0x04)
| #define _SFR_IO16(io_addr) _MMIO_WORD((io_addr) + 0x20)
| #define _MMIO_WORD(mem_addr) (*(volatile unsigned int *)(mem_addr))

Das ging also wohl schon immer und meine Erinnerung war falsch.

[toc] | [prev] | [next] | [standalone]

#223099

"Peter Thoms" <dl6lat@darc.de> schrieb im Newsbeitrag 
news:o7k8sb$hk0$3@news.albasani.net...

> ja, gerne hätte ich das so.
> Wäre das eine korrekte Umwandlung:
>
> sign_int_16Bit_Rechenwert = int_8_Bit_AD-WandlerWert

Ja.

uint8_t wandlerwert = ADC>>2;

int16_t rechenwert = wandlerwert - 100;
-- 
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

[toc] | [prev] | [next] | [standalone]

#223085

Am 10.02.2017 um 10:51 schrieb Peter Thoms:
> Hallo,
>
> wie denn das?
>
> Ich stoppel gerade an einem AVR-Prozessor in C und bekomme vom 10-Bit
> AD-Wandler einen int-Wert von 8-Bit heraus, der mir erst mal reicht.
>
> In dummer Weise aber nicht lange:
> Was ich aber für eine Regelung bräuchte wäre einen Nullpunkt, mittig im
> Wertebereich.
> Bspw. wäre int. 100 der Nullpunmkt (Initialwert, man trifft ja nie genau
> 127) und Abweichungen lägen linear um die 100 verteilt herum.
>
> Wie geht das?

Du kannst dafür die map() Funktion verwenden, um den Bereich des ADC 
(0-1023) in einen beliebigen anderen (ganzzahligen) Bereich abzubilden. 
Siehe Reference zu map(), dort findest Du ein Beispiel und auch die Formel.

Oder Du programmierst das selbst:
aus = (analogRead(A0) - 512) * irgendwas;

DoDi

[toc] | [prev] | [next] | [standalone]

#223118

On 10.02.2017 13:46, Hans-Peter Diettrich wrote:

> Du kannst dafür die map() Funktion verwenden, um den Bereich des ADC
> (0-1023) in einen beliebigen anderen (ganzzahligen) Bereich abzubilden.
> Siehe Reference zu map(), dort findest Du ein Beispiel und auch die Formel.

Nö, map() gibt's in C garantiert nicht.

Gruß,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.sci.electronics

csiph-web