[bascom] odczyt z tablicy wartości byte do zmiennej word

Question

Hej, problem jest następujący. Mam długą tablicę, 99% znajdujących się w niej danych to są dane 1-bajtowe, ale kilka musze mieć 2-bajtowych. Więc aby ...

User removed account · Accepted Answer

To jest tak oczywista informacja że nie ma tego w Helpie.
Tak samo jak całego alfabetu czy tabliczki mnożenia ;p
Skąd Lookup miał by wiedzieć jaką długość mają kolejne elementy?
Owszem mógł by, ale taka tablica musiała by dodatkowo zawierać pola określające długość elementów czyli też była by dłuższa.

Po drugie to trafia do pamięci programu a nie do RAMu.
Zmienna i tak jak rozumiem miała być typu WORD więc zużycie RAMu Ci nie wzrośnie. Programu owszem, ale przy takiej ilości elementów specjalnie bym się tym nie przejmował.

Przy większej ilości elementów i sytuacji gdy tylko niektóre wykraczają poza zakres 0...255 można zastosować pewną kompresję (do rozróżniania Byte/Word wystarczy tylko jedne bit).
Ale Lookup już tego nie łyknie. Trzeba by napisać własną funkcję.

ZbeeGin · Accepted Answer

LOOKUP nie wie jakiego typu są dane, które ma przeglądać. Równie dobrze możesz mieć tablicę słów (Word) a odczytywać ją bajt po bajcie przez LOOKUP, gdzie zmienną do której zwraca ona wartość będzie Byte. To otwiera pewne możliwości:

1. Normalnie dane są jednobajtowe. Dane dwubajtowe, są w stałych i określonych miejscach oraz jest ich bardzo mało. Zatem można tak sparametryzować LOOKUP by w wyjątkowych pozycjach czytało słowa a nie bajty. To tylko kwestia właściwego ułożenia danych i ich ilości, która musi niestety być parzysta.

2. Normalnie dane są jednobajtowe. Dane dwubajtowe są mniejsze niż 32767. Zgodnie z koncepcją kol. atom1477 czytasz bajty. Jeśli wartość jest słowem to najstarszy bit w nim jest ustawiony. Co warunkuje w programie także odczyt następnej danej (offset+1, z równoczesnym przesunięciem wskaźnika by ją przeskoczyć). Po prostym poskładaniu masz daną typu Word. Potem ten bit maskujesz bo jest zbędny, np. RESET Zmienna.15. Ten tryb nadaje się prawie wyłącznie do odczytu sekwencyjnego. No i dane muszą być zapisane jako Big endian by nie komplikować zbytnio.

User removed account · Answer

Bo wszystkie wartości w tablicy odczytywanej poleceniem Lookup muszą być tego samego typu.
A dokładniej muszą być tego typu co zmienna do której się odczytuje, czyli w tym przypadku tego pytu co zmienna "Zmienna”.
Jeżeli Zmienna jest typu Word, to wszystkie wartości w tablicy muszą być typu Word. Niezbyt to pocieszające bo nawet dla małych wartości musisz użyć zmiennej typu Word, ale nic się nie da poradzić.

manekinen · Answer

Mógłbyś podać źródło tej informacji? Czy po prostu wiesz to z autopsji? W helpie nic taiego nie napisano przy poleceniu lookup, zgrabnie ominięto ten problem tworząc dwie różne zmienne i odczytując byte do byte a word do word.Zmienna word to nie problem bo to tylko dodatkowy bajt w ramie, ale chodzi o to że wszystkie dane bajtowe w tablicy musze zapisywać jako word co powiększa ją dwukrotnie bez potrzeby Myślałem żeby zamienić polecenie lookup na loadlabel i cpeek, ale wyliczanie adresu w tablicy będzie tak skomplikowane (przez to że raz byte a raz word) że prościej ominąć cały problem na siłe dodatkowym warunkiem i flagą.Cóż, dzięki.

manekinen · Answer

No tak, nie wie... ale dane zapisane są bajt po bajcie... więc jeśli lookup czytając do zmiennej typu word, automatycznie liczy sobie wszystko podwójnie, i wie gdzie zaczyna się tablica, to czemu prostu nie odczyta dwóch kolejnych bajtów? Logicznie rzecz biorąc powinien wylądować po prostu dwa razy dalej w tablicy, ale nic nie stoi na przeszkodzie aby te dane odczytać prawda? A odczytuje same krzaki. Nie żebym próbował komuś wmówić coś, po prostu nie rozumiem tego Obliczanie adresu tych dwu-bajtowych danych raczej jest bezsensowne, trzeba by było stworzyć dodatkową tablicę która by mówiła nam którą wartość trzeba czytać jako bajt a którą jako słowo. Albo zrobić to na warunku. Tak czy siak wszystko komplikując. Dzięki za pomoc, w zasadzie już sobie poradziłem inaczej, ponieważ tych dwu-bajtowych jest tylko kilka, to niech stracę, na warunku zrobiłem, porównuje adres i jeśli trzeba odczytać dwu-bajtową to odczytuje w osobnej funkcji z osobnej tablicy do zmiennej typu word a potem sobie działam dalej. Śmieszne jest to że wcale nie musze odczytywać całej wartości, bo i tak za każdym odczytem wykorzystuje tylko jeden bit.

User removed account · Answer

Odcztujesz krzaki bo większość danych jest typu Byte, a Ty je odczytujesz jako Word. Czyli z dwóch danych robi Ci się jedna, większa, czyli krzak.

manekinen · Answer

No dobra ale to nie jest wytłumaczenie...

atom1477 wrote:
Czyli z dwóch danych robi Ci się jedna, większa, czyli krzak.

Ale chcę wiedzieć jak to działa. Jak napisałem wyżej, dane które są w tablicy, _fizycznie_ są zapisane w pamięci flash bajt po bajcie i to parametr adres który używamy z poleceniem lookup przesuwa wskaźnik na kolejne bajty w pamięci flash. Przecież taki tablicowy word wygląda tak samo w pamięci flash jak tablicowy byte (tyle że są to dwa bajty następujące po sobie). Lookup w obydwu przypadkach nie wie co odczytuje, zna tylko adres w którym zaczyna się tablica w pamięci flash. Jak napisał ZbeeGin, (jeśli dobrze zrozumiałem) można odczytać z tablicy wartość word do zmiennej byte, najpierw starszą część a przesuwając offset o komórkę do przodu odczytać młodszą i sobie to skleić. Więc czemu nie działa to odwrotnie, czemu lookup do zmiennej word nie może odczytać dwóch następujących po sobie bajtów w pamięci...

Dodano po 11 [minuty]:

Nie sprawdzałem jak by się zachowało cpeek, to jest praktycznie to samo co lookup tyle że nie podajemy adresu w tablicy tylko adres w pamięci flash i z tego co widze można użyć zmiennej word, long, (kompilator nie wywala błędu). I tu nie widze problemu, czemu y nie dać mu adresu tablicy i odczytać dwóch wartości bajtowych w jedną zmienną word... lookup ma problemy z tym.

User removed account · Answer

W zasadzie można do Word odczytać Byte. Ale na zasadzie konwersji typów.
A Lookup nie pozwala na konwersję typów. Typ odczytywanego parametru jest narzucany przez typ zmiennej do której się odczytuje, a więc siłą rzeczy te typy będą identyczne. Jeżeli więc odczytujesz do zmiennej typu Word, to Lookup zawsze będzie odczytywało po 2 bajty.

Musiał byś użyć odczytu do Byte, a potem przepisać wynik do Word.
Wtedy Bascom skonwertuje Byte do Word (w starszą połówkę wstawi 0 znaczy się).

Ale nawet konwersja typów polega na tym, że typu są znane. A u Ciebie nie są bo są przemieszane.
Na razie w tej tablicy masz porządek więc to co napisał ZbeeGin w punkcie 1 mogło by się sprawdzić. Ale nie wiem czy to jest ostateczna tablica a więc nie wiem czy nie pojawi się tam jakaś losowość danych.

Poza tym, zobacz.
Na razie masz 6 elementów typu Byte w tej tablicy.
Kombinowanie z Lookup-ami, If-ami i innymi rzeczami zajmie na pewno więcej niż 10B.
A zamienienie tych wartości bajtowych na wartości WODR tylko 6B.
Podopisuj wszystkim wartościom „%” i odczytuj do zmiennej Word i problemu nie będzie.

PS. Acha. Tego nie rozumiesz:

Quote:

dane które są w tablicy, _fizycznie_ są zapisane w pamięci flash bajt po bajcie i to parametr adres który używamy z poleceniem lookup przesuwa wskaźnik na kolejne bajty w pamięci flash

Otóż ten "adres" nie przesuwa o bajty, ale o długość zmiennej. Czyli jak masz Word to przesuwa o 2 bajty.

manekinen · Answer

Ale zawsze jest to wielokrotność 8 bitów. I przypuśćmy że nie jest istotne czy przesunie o długość zmiennej byte czy o długość zmiennej word... ...ale i tak trafi na kolejne dane które mają ład i skład, więc czemu nie może tego normalnie przepisać do zmiennej word cokolwiek by to nie było Tylko bierze jakieś dane z kosmosu. O to mi chodzi. Dodano po 2 [minuty]: No i tak też pisałem na początku, ale długość tablicy to 440 bajtów (a jeszcze będzie nieco dłuższa), zamieniając wszystkie bajty na słowa podwoi się do kilobajta zaraz...