map - Befehl

Hellow zusammen!! Ich schreibe zum ersten mal auf diesem Forum! :slight_smile:
Ich verstehe die Erklärung in dem Arduino Referee für den map Befehl nicht. Könnte mir jeman erklären, was der Befehl macht? Das währe supper!
Auf jedenfall würde das mir sehr dolle helfen!
Bitte?!?!

Willkommen im Forum...

Google hätte Dir auch geholfen... Außerdem gilt Fettschrifft in Foren meist als schreien!

Link

Gruß SG

Hallo,

sagen wir Du bekommst Werte von einen Sensor, zB über den Analogen Eingang der eine Range von 0-1023 hat und willst wissen wieviel Prozent das sind.

neuerWert = map(analogRead(A0), 0, 1023, 0, 100);

Da geht aber noch mehr, sagen wir Du willst direkt einen Winkel für einen Servo Motor haben.

neuerWert = map(analogRead(A0), 0, 1023, 0, 180);

Die erste Stelle ist der Wert, dann kommt von-bis und die letzten zwei Werte sind für die Ausgabe (von-bis).

Grüße,
Donny

Dazu ist zu sagen, daß die Eingabewerte auch über die angegebene Werte (im Beispiel 0 bis 1023) hinausgehen können. Es sit einfach eine Verhältnisrechnung. Es kann auch ein umgekehrtes Verhältnis definiert werden zB
map(value, 0, 1023, 100, 0)

In der Referenz map() - Arduino Reference
wird die Berechnung erklährt:

map(value, long in_min, long in_max, long out_min, long out_max)
..
long map(long x, long in_min, long in_max, long out_min, long out_max)
{
  return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}

Grüße Uwe

In der Referenz wird die Berechnung erklärt:

Für Fortgeschrittene ist auch das Thema Integer-Arithmetik bedenkenswert.

Ob die ominöse 1023 richtig ist, wird gern zur Gl aubensfrage

Danke für eure suppertolle Hilfe!!!!!!!!!!!!!!

Jetzt habe ich es verstanden. :grin: :grin: :grin:

michael_x:
Ob die ominöse 1023 richtig ist, wird gern zur Gl aubensfrage

In diesem Fall schon. Der ADC spukt Werte von 0 bis 1023 aus. Ob die Signalquelle auch den ganzen möglichen Spannungahub (0 bis AREF) hergibt ist eine andere Frage.

Grüße Uwe

Ah noch was pingeliges:
In C/C++ gibt es keine Befehle sondern Funktionen.
Grüße Uwe

Der ADC spukt Werte von 0 bis 1023 aus.

Schon richtig.

0 -> 0
1 -> 0
10 -> 0
11 -> 1
12 -> 1
1020 -> 99
1022 -> 99
1023 -> 100

Wenn das so krumm gewollt ist, soll es mir recht sein.

michael_x:
...
Wenn das so krumm gewollt ist, soll es mir recht sein.

Was schlägst Du vor um es besser zu machen?
Grüße Uwe

Es macht auf jeden Fall keinen Sinn, die Funktion mit falschen Parametern zu füttern, nur weil die Implementierung mit einem Mangel behaftet ist.

So kann, oder besser, darf die Lösung nicht aussehen.

Denn das verstößt gegen das folgende Mantra:

Man programmiere immer nur gegen die Schnittstelle,
und niemals gegen die Implementierung..

long map(long x, long in_min, long in_max, long out_min, long out_max)
{
  if ((in_max - in_min) > (out_max - out_min)) {
    return (x - in_min) * (out_max - out_min+1) / (in_max - in_min+1) + out_min;
  }
  else
  {
    return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
  }
}

Quelle

ungetestet

map (in, 0,1024,0,100); // erzeugt 100 gleichbreite Segmente 0 . 99
map (in, 0 , 1024, 0, 101); // macht aus den 1024 ADC-Stufen (0..1023)  101 gleichbreite Segmente (0..100)

Nur als Vorschlag.

Nur als Vorschlag.

Dem Vorschlag stehe ich sehr ablehnend gegenüber.
Begründung: Ein Beitrag vorher.

Und ich stehe der von dir zitierten "Fehlermeldung" ablehnend gegenüber.

Klar sollte man gegen die Schnittstellen-Definition programmieren. Aber diese muss man auch lesen, und darf sich nicht eine andere wünschen.

Und irgendwann für eine existierende Funktion die Schnittstellen-Definition ändern geht schon überhaupt nicht.

Natürlich darf man sich besseres wünschen.
Klar, ist fraglich, ob man das so einfach bekommt...

Wie wäre es mit selber besser machen, oder wenigstens was besseres aktiv suchen.
(auch wenn da ein "Wie" steht, ist das keine Frage)

Zur Schnittstelle:
Original:

long map(long x, long in_min, long in_max, long out_min, long out_max)
Die aus dem issue:
long map(long x, long in_min, long in_max, long out_min, long out_max)
Für mich sehen die gleich aus.

gleiche Schnittstelle, nur andere Implementierung.

Zur Definition gehört auch die Funktionsbeschreibung. Das macht im Alltag es so problematisch, eine definierte Funktion einfach anders zu implementieren. Unbedachte Seiteneffekte sind schlecht, absichtliche Änderungen geht gar nicht.

reference:
The map() function uses integer math so will not generate fractions, when the math might indicate that it should do so. Fractional remainders are truncated, and are not rounded or averaged.
...
For the mathematically inclined ...

"Es einfach besser machen" wie in deinem Vorschlag mit anderem Funktionsnamen ist natürlich perfekt.
Muss man nur viel Reklame machen :wink:

mit anderem Funktionsnamen

Ja.
Das Mittel der Wahl.
Wenn man nicht im Core rumpfuschen will.
wg. den Seiteneffekten, oder weils einem das nächste Update eh wieder platt macht.

Zur Definition gehört auch die Funktionsbeschreibung. Das macht im Alltag es so problematisch, eine definierte Funktion einfach anders zu implementieren. Unbedachte Seiteneffekte sind schlecht, absichtliche Änderungen geht gar nicht.

Der Fokus auf die Schnittstelle soll ja gerade erlauben, die Implementierung ändern zu dürfen.

Irgendwelche negativen Seiteneffekte können ja auch nur auftreten, wenn man vorher schon (unbewusst?) gegen die Implementierung programmiert hat.
Das ist dann schon ein älterer Fehler.

Verfälschte Parameter, wegen defekter Implementierung, würde da noch einen Fehler drauf setzen.
Der klassische Doppelfehler.
Ich nenne das öfter mal: “Problemoptimierung”