<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><font face="Arial">Mě na osmibitu připadá nakonec nejlepší
        varianta:</font></p>
    <p><font face="Arial">1) Formátovací řetězec je ve flash.<br>
      </font></p>
    <p><font face="Arial">2) Na zásobníku se vyhradí stejně velký buffer
        pomocí buf[i], kde i = strlen_P(format) + 1;</font></p>
    <p><font face="Arial">3) V buf se znaky # a @ nahradí patřičnými
        číslicemi nebo mezerou.</font></p>
    <p><font face="Arial">4) Buf se vytiskne a po návratu zmizí.</font></p>
    <p><font face="Arial">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ěť.<br>
      </font></p>
    <pre class="moz-signature" cols="72">Martin Záruba</pre>
    <div class="moz-cite-prefix">Dne 23.4.2024 v 10:34 Pavel Hudeček
      napsal(a):<br>
    </div>
    <blockquote type="cite"
      cite="mid:fe0f8b3a-40ce-4652-a2ac-b912a66c6f5f@seznam.cz">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      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.<br>
      Je samozřejmě možné, že to jde nějak optimalizovat, že to nakonec
      bude stejně dlouhé, nebo kratší, zas tolik jsem to nezkoumal.<br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      PH<br>
      <br>
      <div class="moz-cite-prefix">Dne 23.04.2024 v 8:53 Jan Waclawek
        napsal(a):<br>
      </div>
      <blockquote type="cite"
        cite="mid:PC1993202404230853590037cb0fdc60@wekovci">
        <pre class="moz-quote-pre" wrap="">[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.

</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite"> </blockquote>
          </blockquote>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">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. <a class="moz-txt-link-rfc2396E"
        href="https://github.com/mpaland/printf" moz-do-not-send="true"><https://github.com/mpaland/printf></a>
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):
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">* Za sebe můžu říct, že se mi to Vaše pojetí s formátovacím řetězcem líbí.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">*>* 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
</pre>
      </blockquote>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
HW-list mailing list  -  sponsored by <a class="moz-txt-link-abbreviated" href="http://www.HW.cz">www.HW.cz</a>
<a class="moz-txt-link-abbreviated" href="mailto:Hw-list@list.hw.cz">Hw-list@list.hw.cz</a>
<a class="moz-txt-link-freetext" href="http://list.hw.cz/mailman/listinfo/hw-list">http://list.hw.cz/mailman/listinfo/hw-list</a>
</pre>
    </blockquote>
  </body>
</html>