Wie große Look-Up-Table erstellen?

[Christian (Gast)]

Hallo,

um ein Sensorsignal zu linearisieren, möchte ich eine Look-Up-Table 
verwenden.

Eingangswert wären 10Bit vom AD-Wandler (also 1024 mögliche Werte), 
Ausgang der Tabelle ist momentan ein 8Bit (evtl. 16Bit)-Ganzzahlenwert. 
Um dem Controller Rechenarbeit zu ersparen, möchte ich die schon 
vorgekauten Werte verwenden. Diese mit Excel/OpenofficeCalc berechnen 
ist nicht weiter schwierig, wie bekomm ich die dann am bequemsten in den 
C-Quellcode rein?

Wie eine LUT prinzipiell funktioniert, ist mir eigentlich klar. Nur 
kennt jemand ein Tool, um diese großen Datenmengen in den Quellcode 
(oder eine entsprechende c/h-Datei) zu importieren? Über Sinn und Unsinn 
der Tabelle möchte ich nicht diskutieren, der Controller hat mehr als 
genug Speicher übrig :-)

Grüße
Christian

[(prx) A. K. (prx)]

Quellcode muss man nicht zwangsläufig mit der Tastatur eingeben. Man 
kann ihn auch automatisch erzeugen.

Export => CSV und per Programm daraus C-Quellcode erzeugen. Wenn du in 
Excel/Sonstwas programmieren kannst, dann geht das natürlich auch 
direkt.

[meiner (Gast)]

hatte letztens ein ähnliches problem und mich dann dazu entschieden die 
tabelle einfach direkt bei der initialisierung zu erstellen, spart man 
sich den umweg über openoffice, und kann sie recht einfach ändern und 
plattform/compiler-unabhängig ist das ganz auch

geht natürlich nur, wenn sie nicht zu groß ist und/oder du genug zeit 
hast :)

[Uwe (de0508)]

hallo,

für welchen Controller und welchen C-Compiler soll es sein?

Ich setzt das direkt in einem Sheet um und ergänze die nötigen Strings 
links und rechts in den Spalten.

Dann einfach alles markieren und in einem Texteditor einfügen.

[holger (Gast)]

>Diese mit Excel/OpenofficeCalc berechnen
>ist nicht weiter schwierig, wie bekomm ich die dann am bequemsten in den
>C-Quellcode rein?

Exportieren als CSV z.B. lut.csv

uint16_t mylut[] = {
#include "lut.csv"
};

[Tom K. (ez81)]

Hallo Christian,

Für ein ähnliches Problem habe ich  einen csv zu C Konverter in Python 
geschrieben.
Aus dem csv im Anhang habe ich mit

python lookuptable.py example.csv 1.h 1.c

das .c und .h erzeugt. Ohne Gewähr, evtl. hilft es.

[Marcus B. (raketenfred)]

was spricht gegen eine switch-schleife:
uint16_t lookupfunktion(uint8_t variabele)
{
switch(variabele)
{
//Nun der generierte Part:
case A1: return B1;break;
//Fertig
}
return ERROR;
}

Und die case kann man einfach mit der verketten Funktion in Excel bzw 
Open Office erzeugen

[Klaus W. (mfgkw)]

Marcus B. schrieb:
> was spricht gegen eine switch-schleife:

Zumindest, daß es sie nicht gibt. Genausowenig wie die if-Schleife.

[Rolf Magnus (Gast)]

Marcus B. schrieb:
> was spricht gegen eine switch-schleife:
> uint16_t lookupfunktion(uint8_t variabele)
> {
> switch(variabele)
> {
> //Nun der generierte Part:
> case A1: return B1;break;
> //Fertig
> }
> return ERROR;
> }

Was spricht denn dafür?

[Karl H. (kbuchegg)]

Rolf Magnus schrieb:
> Marcus B. schrieb:
>> was spricht gegen eine switch-schleife:
>> uint16_t lookupfunktion(uint8_t variabele)
>> {
>> switch(variabele)
>> {
>> //Nun der generierte Part:
>> case A1: return B1;break;
>> //Fertig
>> }
>> return ERROR;
>> }
>
> Was spricht denn dafür?

Hab ich mich zuerst auch gefragt.
Die Antwort: Dass der Compiler unter Umständen weiß, wie er den Lookup 
schneller hinkriegt als mit linearem Suchen.

Aber abgesehen davon - nichts. Und selbst dieses Argument ist IMHO in 
vielen Fällen nicht wirklich stichhaltig.

[Johann L. (gjlayde)]

Karl Heinz Buchegger schrieb:
> Rolf Magnus schrieb:
>> Marcus B. schrieb:
>>> was spricht gegen eine switch-schleife:
>>> uint16_t lookupfunktion(uint8_t variabele)
>>> {
>>> switch(variabele)
>>> {
>>> //Nun der generierte Part:
>>> case A1: return B1;break;
>>> //Fertig
>>> }
>>> return ERROR;
>>> }
>>
>> Was spricht denn dafür?
>
> Hab ich mich zuerst auch gefragt.
> Die Antwort: Dass der Compiler unter Umständen weiß, wie er den Lookup
> schneller hinkriegt als mit linearem Suchen.

Wenn ein eine Tabelle ist, muss ja nicht gesucht werden da über den 
Index zugegriffen werden kann. Abhängig von der gcc-Version und dem 
eingesetzten µC schiesst man sich (oder dem Programm) mit switch u.U. 
ins Knie.

Grund: Wenn der switch nur "variable" auf Konstanten abbildet, dann legt 
gcc selber eine LUT an anstatt über eine Dispatch-Tabelle zu springen. 
Clou: die LUT wird in .rodata angelegt, und diese Section liegt 
bei avr-gcc im RAM, siehe http://gcc.gnu.org/PR49857

Zudem wird das Programm nicht gerade übersichtlicher, und den switch 
automatisch zu erzeugen ist auch nicht einfacher als eine LUT zu 
erzeugen.

[Floh (Gast)]

Christian schrieb:
> Diese mit Excel/OpenofficeCalc berechnen
> ist nicht weiter schwierig, wie bekomm ich die dann am bequemsten in den
> C-Quellcode rein?

Nimm eine PC-Programmiersprache deiner Wahl (bei mir z.B. c oder 
python), programmier ein kleines Dos-Programm, dass die Werte mit ',' 
getrennt auf der Konsole ausgibt. Dann ist die Zahlen einfach als ganzes 
in den c-Code kopieren. Luxuriös ist auch z.B. nach 8 Zahlen eine neue 
Zeile, da man sonst teilweise nacheditieren muss (Konsole schneidet am 
Ende Zahlen auseinander).
:-)