Dynamiczna etykieta ?

[Leszekjed]

Czy ktoś zna rozwiązanie problemu polegającego w skrócie na korzystaniu z dynamicznych etykiet (o ile cos takiego w Baccom-ie istnieje ?).
Muszę w kodzie programu umieścić dane w formie instrukcji DATA np takie jak:

ET1:
DATA 1.1!, 2.2!, 3.3!
ET2:
DATA 4.4!, 5.5!!, 6.6!
.
.
ETn:
DATA 7.1!, 4.7!, 8.9!

Odwołanie do danych następuje w formie instrukcji RESTORE np. do danych w drugim wierszu trzeba użyć RESTORE ET2 oraz oczywiście READ

Czy istnieje sposób aby parametr dla instrukcji RESTORE mógł być dynamiczny ? Próbowałem zbudować zmienną X as string*3 na zasadzie sumy X="ET"+STR(n) ale sprawa pada na etapie kompilacji. Kompilator musi mieć sztywne nazwy etykiet.

Mówiąc jeszcze bardziej ogólnie szukam sposobu aby w programie zmieścić dane (dane statyczne) w ilości kilku kB, do których można by się było odwoływać dynamicznie - przez zmienny wskaźnik. Użycie tablic przepełnia mi dla tej ilości danych obszar danych przeznaczonych na zmienne. Program ma działać na układzie AT MEGA 32.
L.J.

[ZbeeGin]

Polecam zainteresować się funkcją LOOKUP() jeśli chodzi i liczby oraz LOOKUPSTR() jeśli chodzi o ciągi znaków.
Jeżeli "bloki" danych są stałej długości - tak jak w Twoim przykładzie - to obliczenia pozycji dla KONKRETNEJ_DANEJ_W_BLOKU są następujące: NR_BLOKU*STAŁA_DŁUGOŚĆ_DANYCH_BLOKU+KONKRETNA_DANA_W_BLOKU.

Jeśli "bloki" danych mają różne długości to trzeba zapamietać początki "bloków" w innych danych i pobierać je zgodnie numerami "bloku". Po dodaniu przesunięcia dostaniesz się do właściwej danej.

Jest z tym więcej zachodu ale jest to chyba najprostszy ze sposobów wykorzystujący to co jest dostępne z poziomu BASCOM-a.

[Leszekjed]

Dziękuję za sugestię, nie bardzo wiem na razie jak określać adresy początków bloków. Bloki danych będą stałe ale w układzie:
string*6, single, single, single
Myślałem aby wszystkie dane wpisać w jedno polecenie DATA i wtedy z rozróżnieniem bloków (po cztery dane) nie byłoby problemu bo wystarczy czytać dane kolejno po 4. Ale ile danych można zmieścić w takiej instrukcji ?. Z ograniczeń polecenia lookup wynika, że 2^16 ale czy nie ma innych ograniczeń np. czy jest techniczna możliwość zapisania tylu danych w jednym poleceniu DATA ?
Przy okazji gratuluję świetnej roboty przy nowym help-ie do BASCOM-a !
L.J.

[ZbeeGin]

Dziękuję za sugestię, nie bardzo wiem na razie jak określać adresy początków bloków. Bloki danych będą stałe ale w układzie:
string*6, single, single, single

To teoretycznie będzie 7 + 4 + 4 + 4 bajty = 19 bajtów. Ciąg ma zawsze jeden bajt więcej i jest tam wartość 0. Tak jak w języku C. Można to wyłączyć ale to już wyższa szkoła jazdy.
Pamiętaj tylko, że ciąg "ALA" zajmie tylko 4 bajty!!! Bascom nie zarezerwuje 7 bajtów, gdyż zawsze bierze dokładnie to co jest wpisane. Dlatego ważne będzie dopełnianie ciągów spacjami:

DATA "ALA ", 10.3!, 12.4!, 1.7!
DATA "BODZIO", 43.1!, 12.6!, 1.9!

Przy mieszanych danych nie da się w taki prosty sposób wykorzystać funkcji LOOKUPSTR i LOOKUP. Chyba, że rozdzielisz ciągi znaków i dane liczbowe na dwa odrębne, główne bloki danych.

Myślałem aby wszystkie dane wpisać w jedno polecenie DATA i wtedy z rozróżnieniem bloków (po cztery dane) nie byłoby problemu bo wystarczy czytać dane kolejno po 4. Ale ile danych można zmieścić w takiej instrukcji?. Z ograniczeń polecenia lookup wynika, że 2^16 ale czy nie ma innych ograniczeń np. czy jest techniczna możliwość zapisania tylu danych w jednym poleceniu DATA?

Praktycznie chyba nie ma ograniczeń co do ilości danych w jednej linii DATA. Choć nie powinieneś przekraczać 255 (lub może nawet 65535?) znaków w jednym wierszu programu, bo kompilator może sobie nie poradzić z tak długą linią. Jeśli chcesz umieścić dużo danych to przecież możesz je umieścić w kilku liniach DATA. I tak są one traktowane jako jeden ciąg bajtów. Przykład:

LBL1:
DATA 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
DATA 11, 12, 13, 14, 15, 16, 17, 18, 19, 20
LBL2:
DATA 50, 51, 52, 53, 54

Pierwszy bajt danych zawiera 1 a ostatni 54. Labelki to tylko umowne wskaźniki pozwalające sobie jakoś to logicznie podzielić, uprościć program...

[Leszekjed]

Dziękuję za odpowiedź.
Faktycznie, po praktycznch próbach (a raczej błędach) doszedłem do tego, że dane czytane są w liniach DATA sekwencyjnie bez względu na stojące między liniami etykiety.
Mam jednak parę praktycznych uwag dotyczących dostępu do danych. Dane zorganizowałem tak jak sugerujesz w kilku liniach DATA rozdzielonych etykietami. Ponieważ jednak dane te muszą być pogrupowane w bloki tematyczne to rozpoznanie czy jest to koniec linii w bloku czy też koniec całego bloku danych dokonuję przez analizę zawartości danej typu string. Jeśli linia DATA nie jest ostatnia to ostatnia dana string zawiera ciąg "DALEJ" a jeśli jest ostatnia to zawiera ciąg "KONIEC". W ten sposób mogę przeglądać dane sekwencyjnie wiersz po wierszu i z powrotem do wiersza pierwszego danego bloku po napotkaniu danej "KONIEC" . Nie muszę się też martwić o stałą długość danej typu string. Oczywiście dane typu DALEJ i KONIEC pomiajam przy czytaniu.
Sprawdziłem też praktycznie, że linia DATA nie może mieć nieskończonej długości. Przy ok. 40 zestawach danych (typu string+single+single) co na znaki wynosi w jednej linii DATA ok. 680 znaków, kompilator zaczyna histeryzować przedziwnymi komunikatami o błędach uniemożliwiając dalsza pracę. W ten sposób straciłem kilkanaście godzin pracy bo właśnie w takiej sytuacji kompilator zaproponował zamknięcie pliku z jego zachowaniem po czym okazało się po otwarciu ponownym pliku, że jest dokładnie pusty !!!. Dla mających ten problem w przyszłości podpowiadam, że należy odmówić propozycji zachowania pliku a sam plik należy skorygować po zamknięciu BASCOM-a edytorem tekstowym dzieląc na mniejsze kawałki zbyt długą linię.
L.J.