[AVR-GCC] Głupie pytanie, uint8 na bcd :/

Saper/nolin11:

Najprosciej (ale nie najszybciej (dzielenie)) dla u8: (n%10)|((n/10)<<4) Dziala niestety tylko dla 0-99.

Dla innych zakresow trzeba podejsc kilkuetapowo: dzielac przez 100, liczac mod 100, oraz kownertujac kolejne wartosci do bcd uzywajac powyzszego kodu.

Osobiscie, gdybym mial troche wolnego miejsca (w rom), uzylbym 100 bajtowej tablicy jako lookup do liczenia bcd z zakresu 0-99. Wtedy pozostaje tylko n=table[m].

W bardzo "low-endowych" systemach czasami w specyficznych sytuacjach (proste liczniki, gdzie zliczamy wartosci ze stalym krokiem) lepiej uzyc funkcji (inc/dec) ktore operuja od razu na bcd (i sprawdzaja przeniesienie do nastepnej dziesiatki na biezaco).

powiedzmy że napisałem to tak : uint8_t int2bcd(uint8_t i) { return ((i / 10) << 4) | (i % 10); }

Potrzebuje to do wporwadzania danych do pcf'a więc do 99 jest ok :) Zegarek na led'ach :))

yyyyyyy :))

mam m32 (docelowo pewnie będzie m8535)

Nie wiem skąd ale mam nawyk jak najbardziej skracania kodu jak się da i upraszczania ażyby mało zajmował :) Może nawyk używania przez bardzo długi czas procesorów które miały tylko 2k flash'a

Użytkownik Saper/nolin11 napisał:

Witam Też mi pozostał taki nawyk :-) Ale dodatkowo mam manię wyciskania taktów zegara z procedur i to traktuję jako priorytet. Skracaniem programu zaczynam się zajmować dopiero jak flash się ma ku końcowi :)

Pozdrawiam Grzegorz

W assemblerze jest tak, że im krótszy kod źródłowy, tym krótszy wynikowy. W c już tak nie jest. I często skracanie kodu źródłowego jest wydłużaniem wynikowego. Warto wiedzieć jak się poszczególne instrukcje i funkcje kompilują. Przydatna jest znajomość opcji kompilatora, żeby odpowiednio optymalizował kod.

To się robi zwykłym algorytmem, nie rzeźbie po avr'ach ale mogę dać Ci przykład na pica ;)

Algorytm można rozszerzać na dowolną ilość bajtów i chyba w miarę prosto przenieść na inny procesor.

A tak poza tym to myślę, że takich przykładów musi być pełno na sieci.

Pozdrawiam, sword