Formatovany tisk pro 8bit

[Martin Záruba]

Mě na osmibitu připadá nakonec nejlepší varianta:

1) Formátovací řetězec je ve flash.

2) Na zásobníku se vyhradí stejně velký buffer pomocí buf[i], kde i = 
strlen_P(format) + 1;

3) V buf se znaky # a @ nahradí patřičnými číslicemi nebo mezerou.

4) Buf se vytiskne a po návratu zmizí.

Je dobře udělat přetížení pro všechny typy čísel, kde v tom přetížení je 
pouze volání tiskové funkce, kde hodnota se předá jako (int32_t), 
protože jinak konverze nastane při každém volání funkce. Takto to ušetří 
paměť.

Martin Záruba

Dne 23.4.2024 v 10:34 Pavel Hudeček napsal(a):
> 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
>
> _______________________________________________
> HW-list mailing list  -  sponsored bywww.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20240423/75e21e87/attachment.htm>