Formatovany tisk pro 8bit

[Pavel Hudeček]

Ten způsob s dělením 1e9, 1e8, ... 100, 10 jsem používal v minulém 
století v assembleru na 486 a bylo tolepší. Ale na 8bitu mi přišlo lepší 
nakonec odeslat byty v opačném pořadí, než generovat 32b dělitele.
Je samozřejmě možné, že to jde nějak optimalizovat, že to nakonec bude 
stejně dlouhé, nebo kratší, zas tolik jsem to nezkoumal.

Ale zrovna včera jsem dělal overloady na další datové typy a tam je pak 
jasná výhoda dělení 10, že celý vnitřek funkce m;že být úplně stejný pro 
8, 16 i 32b.

Mimochodem, vedlejší produkt včerejška je, že když je verze pro long a 
unsigned long, je lepší v signed obrátit znamínko a zavolat unsigned. 
Dokonce i když unsigned není jinak použitej.

PH

Dne 23.04.2024 v 8:53 Jan Waclawek napsal(a):
> [preposielam]
>
> Ahojte,
>
> temu ste uz sice vycerpali ale predsa sa ku nej este v kratkosti vratim. Ja
> som svojim sposobom trochu sahnuty a snazil som sa formatovany vystup
> naprogramovat do malych PIC s 4kW a 256 bytov RAM-ky. Musim povedat, ze to
> bolo pekne mentalne programatorske cvicenie. Musel som optimalizovat naozaj
> vsetko, vratane pristupu do tabuliek vo Flash pamati kontrolera. Bolo to
> sice len nejakych cca.10 instrukcii z kompilatora, ale aj to vo
> finale urobilo svoje. Pokial sa dobre pamatam, tak mi to vyslo tesne nad
> 2kW, takze sa to uz do tych najmensich PIC nevmestilo. Tu by som sa chcel
> spytat, preco vsetci robite konverziu od najmensej mocniny 10 a nie od
> najvacsej mocniny? Myslim si, ze to ma zopar vyhod pri dalsom spracovani
> retazca resp. pola tych znakov. A na formatovanie staci pouzit algoritmy,
> ktore tu spomenul p.Labaj, teda prehladavanie hrubou silou na iste znaky a
> jednoduche posuvanie retazca. Rozhodne ten kod nema 600 riadkov ako ta
> nizsie spomenuta kniznica, ale zase je len na signed int a unsigned int, a
> to este s osekanym rozsahom na -999...9999. Plus nastavenie
> desatinej bodky. Ja to mam urobene takto, a bohato mi to staci na velku
> cast vypisov na displej.
>
> A.
>
> Jeste stoji za zminku, ze resit usporne printf pro MCU uz napadlo
> spoustu lidi a je ke stazeni mnoho projektu, ktere lze ruzne
> parametrizovat atd. Namatkou napr. GitHub - mpaland/printf: Tiny, fast,
> non-dependent and fully loaded printf implementation for embedded
> systems. Extensive test suite passing.<https://github.com/mpaland/printf>
> Ja bych to printf s formatovanim uplne nezavrhoval, je to velmi
> prakticke a flexibilni a s rozumnou implementaci a orezanim slozitejsich
> formatu to neni nijak narocne na prostredky.
> Cpat to do 4kB flash a 256B RAM je samozrejme blbost ale u attiny s
> 16/2kB uz jsem se nejak moc neomezoval.
>
>
> Dne 20.04.2024 v 18:28 Petr Labaj napsal(a):
>> * Za sebe můžu říct, že se mi to Vaše pojetí s formátovacím řetězcem líbí.
> *>* Asi bych tam trochu šetřil s buffery, ale to je drobnost.
> *>>* Já to skládám 3 voláními (text, číslo, text), ale takhle je to docela
> *>* elegantní.
> *>>* PL
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20240423/3feba96a/attachment.htm>