Bascom : Syntax zum Tabelle auslesen

[dg2ygq]

Ich brauche mal Hilfe auf die Schnelle, mein Buch ist noch unterwegs, und die Bascom-Hilfe ist nicht wirklich eine Hilfe

Folgendes Problem:
Ich benötige in meinem Programm 3 unterschiedliche Tabellen.
2 Tabellen sind 16bit, die andere 8 Bit.
Nun möchte ich einer Variablen den inhalt von zB. der 6. Stelle zuteilen.

Nun bekomme ich die Syntax nicht hin, wie ich welche DataZeile bzw Pos. der Daten ich zu packen bekommen.

Danke

Michael

 

[Markus]

BASCOM und DATA-Tabellen

Hallo Michael,

bei Tabellen in BASCOM ist folgendes zu beachten:

Integer und Word Konstanten müssen mit einem %-Zeichen enden.
Long Konstanten müssen mit einem &-Zeichen enden.
Single Konstanten müssen mit einem !-Zeichen enden..
Double Konstanten müssen mit einem #-Zeichen enden.

Beispiele:

Data_byte:
DATA &HFF, 233, &B10010110  ' Beispiel für Byte

Data_word:
DATA 16000%, &HFFFF%, 1000%  ' Beispiel für Word

Data_long:
DATA 123456789&  ' Beispiel für Long

Zum Auslesen der Tabellen gibt es mehrere Möglichkeiten. Um eine Tabelle sequentiell auszulesen/durchzulesen gibt es das Konstrukt

Dim Temp_word As Word
Dim Count As Byte

Restore Data_word  'Startpunkt der Daten
For Count = 1 To 3  'Anzahl der vorhandenen Daten
    Read Temp_word
    Print Count ; " " ; Temp_word
Next

Nachteil dieser Methode ist, das man die Tabelle immer von Anfang an bis zur gewünschten Variable durchlesen muss. Eine weitaus elegantere Lösung ist hier der Befehl LookUp. Mit Lookup kann ein Tabelleneintrag indiziert ausgelsen werden. Es wird mit 0 begonnen zu lesen, 0 liefert also den ersten Tabelleninhalt.

Dim Temp_word As Word

Temp_word = Lookup(1, Data_word)  ' liefert den 2. Tabelleninhalt
Print Temp_word  ' Druckt 65535 bei obigem Beispiel

So, jetzt haben wir mal die Basics behandelt. Nun zu Deinen drei Tabellen. Prinzipiell ist das ganz einfach. Du musst die Tabellen nur mit eigenen Label versehen und schon kannst Du loslegen.

Tabelle1:
DATA 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
DATA 17,18,19,20,21.....
DATA ....

Tabelle2:
DATA 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
DATA 17,18,19,20,21.....
DATA ....

Tabelle3:
DATA 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
DATA 17,18,19,20,21.....
DATA ....

Zur Erklärung:
Prinzipiell ist der Umgang mit Tabellen sehr einfach. Sie sind nichts anderes als einen sequentielle Aneinanderreihung von Daten im Speicher welche 1, 2, 4, 8 Byte usw. groß sein können. Darum mußt Du Dich bei BASCOM nicht kümmern. Das macht BASCOM für Dich.
Die Daten sind vom Anfang an aufzteigend durchnummerirert. Achtung! Hier gibt es je nach zugriffsmethode unterschiede. Manchmal geht es mit NULL los und manchmal mit EINS.
Damit Du den Startpunkt kennst wo die Daten im Speicher liegen gibt es das jeweilige Label z.B. "Tabelle1:" welches Du beim READ oder beim LOOKUP verwendest.
Bei LOOKUP kannst Du einen Index angeben. Das hast Du oben schon gelernt. Bei READ ist es so, dass BASCOM für Dich den READ-Zeiger automatisch beim Lesen erhöht. Das bedeutet bei jedem READ springt der Zeiger auf das nächste Datenfeld automatisch weiter. Um hier an den Anfang zurück zu kommen verwendet man den RESTORE-Befehl. Der setzt den Zeiger wieder an den Anfang Deiner Tabelle.


So aber ich glaube das müsste an Hintergrundinfos reichen um den Sonntag nun noch voll mit Tabellen zu verbringen

Übrigens, viel davon steht in der BASCOM Hilfe drin
Noch was zur BASCOM-Hilfe; im Download-Bereich bei MCS Electronic gibt es das roße BASCOM-AVR Manual als PDF zum Download. Das Ding hat aktuell ca. 790 Seiten und ist als Hilfe sehr sehr nützlich. Dort findest Du auch zu dem ganzen Zeug wa sich oben kurz beschrieben habe ausführliche Hilfe und Codebeispiel! Du findets das Ding unter
http://www.mcselec.com/index.php?option=com_docman&task=cat_view&gid=99&Itemid=54

Und glaube mir, so um das eine oder andere englische Datenblatt bzw. und um Hilfen kommt man nicht herum und selbst wenn man seine Arbeit auf BASCOM und den ATmega8 beschränkt , nur Mut Mit der Zeit fällt Dir das Durcharbeiten auch leicheter.

Grüßle,
Markus

 

[dg2ygq]

Danke für die Super Erklärung!

Mein Versuch will nicht richtig:

Worda_frequency = Lookup(kanal , Efreq)

"Kanal" beinhaltet eine Zahl zwischen 1 und 10, Efreq die Datazeile. "Kanal" wird in der Klammer auch automatisch klein geschrieben??

Efreq:
Data 0 , 13016% , 13024% , 13032% , 13048% , 13056% , 13064% , 13072% , 13088% , 13096% , 13104%

Welche Kleinigkeit hab ich übersehen?

 

[Markus]

Hallo,

Dein Problem ist das fehlende %-Zeichen bei 0 in der Data-Zeile. Du darfst bei solchen Statements die Datentypen nicht mischen.

Eine Zahl ohne irgendwas bedeutet 1-Byte im Speicher und % bedeutet Word und damit 2 Byte im Speicher. So, jetzt versuchst Du mit LookUp auf die Tabelle zuzugreifen und sagt Du möchtest Word lesen. Genau hier entsteht Dein Problem. Ganz am Anfang steht nur eine 1-Byte-Null und Du überspringst mit LoopUp(kanal, Efreq) nicht 1 Byte sondern 2 Bytes. Klar, oder?

Damit liest Du aus der Tabelle bei kanal = 1 für das erste Word noch das low-Byte von 13016% und das high-Byte 13024%. Das kann nicht funktionieren.

Fazit:
Immer darauf achten, wenn Du Dich in Tabellen für einen Datentyp entschieden hast diesen auch zu verwenden.
Also, mach schnell an die NULL Dein % und schon funktionierts.

Efreq:
Data [B][COLOR="Red"]0%[/COLOR][/B] , 13016% , 13024% , 13032% , 13048% , 13056% , 13064% , 13072% , 13088% , 13096% , 13104%

Grüße,
Markus

 

[dg2ygq]

Hey, das war`s

Stimmt, er übermittelte ganz merkwürdige "Frequenzen", im ganz merkwürdigen "Raster" *lach

Danke Markus

 

[Bonze]

muss das mal hervorholen,.
und zwar möchte ich mit lookup versch tabellen auslesen, das gtanze soll in zwei verschachtelten for schleifen geschehen,.
bsp:

for i = 0 to 10

[COLOR="#800000"]for i2= 0 to 6
lookup (i , dta i2)
next
[/COLOR]
next

dta1:
data &h1, &h2
dta2: 
data &h2, &h5

wie schaff ich es bascom beizubringen das der 2te parameter von lookup auch ne variable is ?

 

[LotadaC]

Laut Bascom-Online-Hilfe ist der erste Parameter ein Index in einer Tabelle (also eine Zahl - ein Zahlenwert), der 2te ein Label, eine Speicheradresse.
lookup lädt (entsprechend der Zielvariable viele) byte(s) (beginnend) von (labeladresse+index) aus dem Speicher (Flash ? ) in die Zielvariable.

Ich weiß jetzt nicht, ob Bascom die Label prüft (also die "Anzahl" der Einträge - in Deinem Beispiel zeigt "dta1" auf eine Speicherzelle, in der &h1 steht, in der nächsten Zelle steht &h2. In der nächsten steht auch &h2 (auf diese Zelle zeigt "dta2"), in der nächsten &h5 - also alles hintereinander.
"zielvariable=lookup(3,dta1)" sollte also die 3te Zelle hinter dta1 (also die &h5) in die Zielvariable laden... wenn Bascom da nicht kontrollieren will, ob da inzwischen ein neuer Label festgelegt wurde - probiers aus...
(wenn die "Zeilen" alle gleich viele Elemente haben, kannst Du das "Rechteck" mit Zeilenindex*(Spaltenzahl)+Spaltenindex oder so durchrattern)

 

[Bonze]

also, es gibt 6 zeilen, und 11 spalten,.
möchte jetzt feld fuer feld durchgehen
mein problem ist, das ich halt in meiner for schleife dta1 -dta6 durchegehn will bzw lookup dta1-6,.
und genau diese 1 bis 6 ist mein problem

 

[LotadaC]

Schon mal versucht, meinen Vorschlag da oben umzusetzen?
also

For i=0 to 65
 zielvariable=lookup(i,dta1)
 ;Zielvariable also das aktuelle Element) verarbeiten
next i

Im Speicher gibt es keine Tabelle - da steht alles hintereinander (ok, in words, aber das ist erstmal egal)...
Oder meckert Bascom da jetzt, daß zb. bei i=40 auf eine Speicherzelle zugegriffen werden soll, die nach label dta1, nach label dta2, nach label dta3 usw liegt?

 

[Bonze]

ne kann dir da nich so folgen ;/

in der tab sollen alle meine bus codes drinstehen

      'for schleife zum checken
      'zeile->spalte->feld
       For I = 0 To 17                                      'prüfe jede spalte der datentabelle
           For I2 = 1 To 6                                  'prüfe alle empfangene bytes
              'If Lookup(i , I2) = Recieved(i2) Then
                  'Print "Suche erfolgreich"
                  '   call sendnec(lookup(i2, dta(7)))
              'End If
           Next
       Next



$eeprom
'Dta(1):                                                     'quellid eigentlich wird das beim empfangen schon gefiltert
'Data &H50 , &H50 , &H50 , &H50 , &H50 , &H50 , &H50 , &H50 , &H50 , &H50 , &H50 , &H50 , &H50 , &H3F , &H3F , &H00 , &H00

Dta(2):                                                     'laenge
Data &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04

Dta(3):                                                     'ziel
Data &H68 , &H68 , &H68 , &H68 , &H68 , &H68 , &H68 , &H68 , &HB0 , &HC8 , &HC8 , &HC8 , &HC8 , &H60 , &H60 , &HBF , &HBF

Dta(4):                                                     'data1
Data &H32 , &H32 , &H3B , &H3B , &H3B , &H3B , &H3B , &H3B , &H3B , &H3B , &H3B , &H3B , &H0C , &H0C , &H72 , &H72 , &H76

Dta(5):                                                     'data2
Data &H11 , &H10 , &H01 , &H11 , &H21 , &H08 , &H18 , &H28 , &H80 , &H80 , &H90 , &HA0 , &H40 , &H80 , &H40 , &H16 , &H02

Dta(6):                                                     'xor
Data &H1F , &H1E , &H06 , &H16 , &H26 , &H0F , &H1F , &H2F , &H5F , &H00 , &H00 , &HA00 , &H00 , &HD7 , &H17 , &HDF , &HEF

Dta(7):                                                     'NEC CODE
Data &B00101000 , &B10101000 , &B00101000 , &B00101000 , &B00101000 , &B11100001 , &B00101000 , &B00101000 , &H00 , &H00 , &H00 , &HA00 , &H00 , &H00 , &H00 , &H00 , &H00
$data

 

[dino03]

Hi,

mach es do einfach so ...

for zeile = 0 to 5
  for eintrag = 0 to 7
    element = zeile * 8 + eintrag
    lookup (element) ... oder so
  next eintrag
next zeile

dta:
' zeile 0
Data &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04 , &H04 
' zeile 1
Data &H32 , &H32 , &H3B , &H3B , &H3B , &H3B , &H3B , &H3B
' zeile 2
Data ...........

oder so ähnlich (hab noch nicht mit Data gearbeitet). Du berechnest deinen Index sozusagen aus den beiden Schleifenzählern.

Gruß
Dino

 

[LotadaC]

Eeprom also (kein Flash) - ok...
Je nach Kontroller hast Du mehr oder weniger viele Speicherzellen im Eeprom. Jede Zelle enthält ein Byte. Die sind mit 0 beginnend durchadressiert.
Du mußt Dir das Quasi als (1 Byte breite) Liste vorstellen - sowas wie Tabellen gibt es nicht.
Mit der Eeprom-Direktive sagts Du Bascom, daß die folgenden Data-Zeilen im Eeprom landen sollen.
Die Data-Zeilen füllen jetzt einfach nacheinander die Eeprom-Liste - also Byte auf Byte.
Die Label, die Du jetzt dazwischen gesetzt hast, sind sowas wie Merker für Bascom. Man muß dann nicht die genaue Eeprom-Adresse beim Zugriff angeben, sondern verwendet den label. Wird von irgendwo im Programm mal bezug auf dieses Label genommen, wird dort beim Kompilieren die entsprecchende Adresse (Zahl) übersetzt. Selbst, wenn beim Brennen das Eeprom gar nicht beschrieben wird, greift der Controller zur Laufzeit dann trotzdem auf die entsprechenden Zellen zu - was auch immer da dann steht.
Genug der Vorrede:
lookup ist laut Bascom-Hilfe eine Funktion, Die aus einer (irgendwie organisierten) Daten"tabelle" eine bestimmte Anzahl an Bytes (festgelegt durch die Zielvariable) lädt. Die Adresse wird dabei durch ein Label (=Zeile) und einen Index (=Spalte) festgelegt. Hintergrund ist der vereinfachte indizierte Zugriff auf mehr-Byte-Werte (also Integer, words oder sowas). Index ist also irgendein Wert (zur Laufzeit), deswegen kannst Du da auch den Schleifenindex verwenden - label muß aber eben ein, irgendwo m Programm definierter label sein.

Du willst eigentlich eher mir readeeprom arbeiten, da hier als Adresse Variablen akzeptiert werden. Allerdings mußt Du Dich um das Ausrechnen der Tabelle jetzt selbst kümmern. Aber denk mal nach, was das verschachtelte Auslesen der Tabelle in Wirklichkeit im Eeprom bedeutet (Liste). readeeprom besitzt ein Autoinkrement - Wenn Du also bereits eine Zelle ausgelesen hast, zeigt ein Bascom-Eeprom-Zeiger quasi schon auf die nächste Zelle. Ein weiteres readeeprom ohne Adressangabe liest jetzt diese Zelle aus (und inkrementiert diesen Zeiger wieder)...

Der eigentliche Eeprom-Zugriff erfolgt über 3 (eigentlich 4) I/O-Register. Ein Controlregister (in dem festgelegt wird, daß jetzt geschrieben oder gelesen wird (vereinfacht gesagt), und man ablesen kann, ob das überhaupt geht usw), ein (ggf 2) Adressregister, die auf die entsprechende Zelle zeigen, und ein Data-Register, durch das das Byte eben ausgelesen/geschrieben wird.
Um zu lesen, wird die entsprechende Adresse in das/die Adressregister "gesteckt", und ein Bit im Kontrollregister gesetzt (strenggenommen sollte man vorher auch noch prüfen, ob nicht grad geschrieben wird, aber egal). Die Hardware verbindet jetzt quasi das adressierte Eeprom-Register mit dem Data-Register -> dort kann man also das gespeicherte Byte auslesen.
Das auslösen eines Schreibvorganges läuft mit umgekehrter Reihenfolge (und einem Sicherheits-Zwischenschritt) im Prinzip ähnlich ab (dauert aber (physikalisch bedingt) länger).

Edit zu Dino:
So meinte ich das auch ganz unten in meinem vorletzten Beitrag...
Aber lookup (und auch readeeprom) ist eine Funktion, muß also einer Variable zugewiesen werden (genau genommen ist das sogar ... ähm ... eine überladene Funktione (?), da der Ziel-Datentyp (Byteanzahl) festlegt, wieviele Bytes geladen (und zugewiesen) werden. Oder wie nennt man sowas?).

Aber jetzt geh mal durch, welche Werte "element" bei jedem Schleifendurchlauf so annimmt... (ok, die beiden Schleifenindizees braucht man vielleicht in der Schleife auch woanders...)

 

[Bonze]

mhh,
vl gehts auch anders, wollte den empfangenen hex codes binaercodes zuordnen,.
bzw die passende spalte mit dem uebereinstimmenden code raussuchen

 

[Cassio]

Hallo zusammen!

Der Lookup() Befehl kann nicht mit zwei Variablen arbeiten!
Letztlich muss er das aber auch gar nicht.

Per LookUP() kannst du sowieso keine Daten aus dem EEPROM lesen.


Wie LotadaC schon geschrieben hat.......
Es gibt im EEPROM-Speicher keine Tabelle!
Diese Tabelle existiert nur für dich.
Im EEPROM liegen alle Werte hintereinander. Mehr nicht!

Wenn du also nun 6 Zeilen und 11 Spalten vor dir siehst, dann befinden sich die 66 Byte im EEPROM lediglich hintereinander.


Benötigst du also den Wert in Zeile 3 aus Spalte 10, dann musst im Programm nur den 32. Speicherplatz auslesen.
Benötigst du den Wert in Zeile 6 aus Spalte 11, dann ist es der 66. Speicherplatz.

Welches Byte allerdings nun der 66. Speicherplatz bei dir ist, hängt von deinem Programm ab.

Wenn du z.B. die ersten 16 Byte frei lässt, dann musst du das natürlich berücksichtigen.
Nehmen wir also an, du beginnst mit deinen Daten erst ab Speicheradresse &H10.... also dem 17. Byte im EEPROM.
(Das liegt daran, das im EEPROM die Speicheradressen wieder mit &H00 beginnen.)


Um jetzt den 66. Speicherplatz zu erreichen und den Wert in die Variable "Save" zu übergeben, könnten deine Befehle z.B. so aussehen:

'6. Zeile, 11. Spalte
EE_nummer = 6 * 11

'ersten 16Byte sind frei
EE_nummer = EE_nummer + 16

'Wert in "Save" übergeben
READEEPROM Save , EE_nummer

Ist es dir nun klar geworden?
Ich hoffe, ich habe mich verständlich genug ausgedrückt.


Grüße,
Cassio

 

[Bonze]

ohje , wollt de den code eigentlich ein bisschen straffen dadurch, dann fahr ich wohl lieber mit den if elseif constructen,. das ist wahrscheinlich sogar speicherschonender, wenn auch nicht so uebersichtlich ,.

 

[LotadaC]

Zwischenfrage an Cassio: woran soll man erkennen, daß lookup keine Data's im Eeprom erreicht? In der Hilfe steht da nichts explizites zu, nur eben, daß Daten aus einer Table (mit Data abgelegt) geladen werden.
Aus Hardware Sicht ist eigentlich logisch, wenns nicht klappt - weil sich hinter der Label-Konstante ja nur die Adresse , also eine Zahl verbirgt. Wenn man das doch versucht, werden dann bytes aus derselben Adresse, nur eben aus dem Flash(?) geladen?

Zu Bonze: wiso?
Das wesentliche hat Dino Doch schon geschrieben - nur eben mit readeeprom statt lookup (und der da korrekten Syntax), und halt eben Deinen maximalen Indizees. Solltest Du so in Dein Programm einbauen können.

Und dann wie gesagt, mal die einzelnen Werte von element bei jedem Schleifendurchlauf ausrechnen (Stichwort: Autoinkrement bei readeeprom-Adresse).
Verschachtelte Schleifen brauchst Du natürlich trotzdem wegen der anderen Instruktionen.
P.S.: I und I2 sind nicht wirklich "klingende" Indexvariablen

 

[dino03]

Hi,

ohje , wollt de den code eigentlich ein bisschen straffen dadurch, dann fahr ich wohl lieber mit den if elseif constructen,. das ist wahrscheinlich sogar speicherschonender, wenn auch nicht so uebersichtlich ,.

in Assembler könnte man das nun über eine indirekte Adressierung wunderbar aus einer Tabelle holen. Ohne irgendwelchen if/els Gedöns.

Die Tabelle fängt zB beim Label "Daten:" an.

Daten:
byte0 , byte1 , byte2 , byte3 , ...
byte16 , byte 17 , ...

dann holt man sich das Byte (Daten+Index. Man addiert also zur Basisadresse "Daten:" der Tabelle im Speicher einen Index hinzu und holt an dieser berechneten Stelle das Byte ab. So kann man problemlos 256 verschiedene Eingangswerte in 256 verschiedene Ausgangswerte umarbeiten. Die Tabelle belegt im Speicher allerdings dann auch 256 Byte.

Eigentlich sollte das in Bascom auch irgendwie möglich sein.

Gruß
Dino

 

[Bonze]

ja, das wird aber nich so einfach,.
ich empfange 6 bytes, je nachdem wie die adresse bzw die daten in dem 3 bzw 4&5 byte aussieht, werden versch aktionen durchgefuehrt,.
deshalb wollte ich dann die tabelle danach durchsuchen, und dann aus der letzten zeile der tabelle mein aktionsbyte auslesen

 

[Cassio]

Hallo Bonze!

Das klingt jetzt aber wieder nach einer ganz anderen Funktion....

Wenn du deine Datentabelle nur nach einem bestimmten Byte durchsuchen möchtest,
dann solltest du dir vielleicht mal den Befehl LOOKDOWN() ansehen.

Ich könnte mir vorstellen, dass du damit besser zurecht kommen würdest.


Grüße,
Cassio

EDIT:
Ach so,
funktioniert natürlich auch nur im SRAM.
Kann sein, dass du die Tabelle vorher mit RESTORE aus dem EEPROM laden kannst.
Das habe ich aber noch nicht ausprobiert.

 

[LotadaC]

Also ich denke auch, daß Du da grad was gaanz anderes versuchst, als Du eigentlich erreichen willst...
Wenn ich das mit dem NEC-Kram damals in Verbindung bringe, erinnere ich mich auch daran, daß Du irgendwas (seriell?) aus einer anderen (mehreren) Quelle(n) empfangen wolltest, und dann eine davon abgeleitete Antwort an den NEC weiterleiten wolltest.
Gib uns (zumindest mir) bitte erstmal 'ne Übersicht über die Struktur der Telegramme, welche Bytes welche Funktion haben.
Du kommentierst "Quell-ID", "Länge","Ziel-ID", 2 DatenBytes (also 1 Word), eine Checksumme, und das zu sendende NEC-Byte. Mußt Du die wirklich alle zur Auswahl der zu sendenden NEC-Antwort auswerten? Beim NEC hattest Du ja nur ein Ziel - sind hier die unterschiedlichen Ziele überhaupt relevant?
Da Du innerhalb der einzelnen Positionen eigentlich nicht viele verschiedene diskrete Werte hast, sind die IFs gar nicht so schlecht, nur eben durch eine switch/case oder select/case oder case/of (oder wie auch immer das bei Bascom heißt - Cassio, Hilfe!) Konstruktion umgesetzt.

Die XOR-Checksumme interessiert Dich doch hier auch gar nicht mehr (das ist doch die Original übermittelte, oder?) Eigentlich schreibst Du doch die empfangenen Bytes nacheinander in einen Puffer, und bildest dabei gleich die Checksumme mit. Wurde die Checksumme empfangen, vergleichst Du die mit Deiner. Stimmen die überein, übernimmst Du den Pufferinhalt zur weiteren Verarbeitung, ansonsten verwirfst Du ihn. Da Du ja irgendeinen Bus oder sowas mitschneidest, interessieren Dich vielleicht gar nicht alle Bytes - Du mußt zwar alle bei der Bildung der Checksumme berücksichtigen, puffern und weiterverarbeiten aber möglicherweise nicht alle. Vielleicht interessieren Dich auch nur einige Quellen oder Ziele (case of), und/oder da dann nur bestimmte Datenwords.

Länge scheint auch nur für den eigentlichen Empfang relevant zu sein - also falls unterschiedlich lange Telegramme auftreten können.

Ähm... wie sieht dann eigentlich Deine Empfangsroutine aus (UART wars doch, oder?)

P.S.: irgendwie driftet das wieder vom ursprünglichen Topic (von 2008) weg...