Skrócone wypisywanie różnego rodzaju zmiennych w Arduino

[rziomber]

Prezentacja zmiennych różnego typu na ekranach jest nieco irytująca

    lcd.print(amp, 1);
    lcd.print("mA ");
    lcd.print(power, 0);
    lcd.print("mW ");
    lcd.print(lux);
    lcd.print(" lx "); ....

Dla portu szeregowego pewnym ułatwieniem może być biblioteka https://github.com/janelia-arduino/Streaming

#include <Streaming.h>
void setup() {
  Serial.begin(9600);
  const float pi = 3.14159;
  Serial << "Hello, world!" << _FLOAT(pi,3) << endl; 
}

Oczywiście jest jeszcze stary snprintf z C.

char buffer [100];
snprintf (buffer, 100, "TEXT %d %s", 60, "next");
Serial.print(buffer);

To szczególnie wygodne, gdy musimy ten sam ciąg znaków wysłać np na LCD i port szeregowy. Tekst formatuje się tak, jak w https://pl.wikibooks.org/wiki/C/printf#Format

Problem może pojawić się z wypisywaniem zmiennych typu float na Atmegach. Domyślne flagi kompilacji nie zapewniają obsługi %f. Z pomocą przychodzi dtostrf()

  float f = 32.4;
  char str[50];
  char bufFloat[10];
  dtostrf(f, /* minStringWidth*/1, /*numAfterDecimal*/ 2, bufFloat);
  // gcvt (f, 2, bufFloat); Nie dziala na Arduino!
  char txt[] = "Hello World";
  sprintf(str, "%s %i float %s", txt, 5, bufFloat);
  Serial.println(str);

lub sprytne obejście problemu

sprintf(str, "%d.%02d", (int)floatVal, (int)(fabsf(floatVal)*100)%100);

Łączenie Stringów jest bardzo wygodne, niestety generuje większy plik binarny i może prowadzić do heap fragmentation a to do resetowania mikrokontrolera. Przy mniejszych projektach i kasowaniu stringa przy przebiegu pętli powinno działać.

Serial.print("text" + String(5) + " " + String(floatVal, 2));

Z pomocą może przyjść też https://www.geeksforgeeks.org/variadic-function-templates-c/

C++17

template<typename... Args>
void universalPrint(Args... args) {
  (lcd.print(args), ...);
}
template<typename... Args>
void universalPrintln(Args... args) {
  universalPrint(args..., '\n');
}


universalPrint(bme.readTemperature(), "C ", bme.readHumidity(), "% ", bme.readPressure() / 100., "hPa");

Starszy C++

void universalPrint() {}
template<typename Arg, typename... Args>
void universalPrint(Arg arg, Args... args) {
  lcd.print(arg);
  universalPrint(args...);
}
template<typename... Args>
void universalPrintln(Args... args) {
  universalPrint(args..., '\n');
}

Próbowałem napisać klasę, której konstruktorowi można przekazać metodę drukującą, a potem przekazywać parametry operatorem <<, niestety działa to tylko ze zmiennymi jednego typu. Mieszanie ciągów znaków i liczb się nie uda. Nie wiem, jak przechowywać przeciążone metody w klasie.

#include<iostream>

class Foo
{
public:
  void bar (int i)
  {
    std::cout << "Hello from Foo " << i << "\n";
  }
};


template <typename C, typename F> class Baz
{
private:
  C obj;
  F func;
public:
Baz (C o, F f):obj (o), func (f){}

  template <typename T> void call (T i)
  {
    (obj.*func) (i);
  }
  template <typename T> friend Baz & operator<< (Baz & mc, T i)
  {
    mc.call (i);
    return mc;
  }
};

int main ()
{
  Foo f;
  Baz b (f, &Foo::bar);

  b.call (5);
  b << 7 << 8 << 9;
  return 0;
}

Przed chwilą znalazłem PrintEx Library for Arduino, która przy okazji zastępuje kulawe sprintf z AVR

#include <PrintEx.h>
char buffer[100];

void setup(){
  sprintf(buffer, "This is a float: %.3f", 23.451f);
  Serial.begin(9600);
  Serial.println(buffer);
}

Macie jakieś ciekawsze, wygodne rozwiązania?

Edytowano Październik 28, 2023 przez rziomber

[ethanak]

38 minut temu, rziomber napisał:

Problem może pojawić się z wypisywaniem zmiennych typu float na Atmegach.

Hm... według mnie problemu nie ma - trzeba tylko umieć przekazać konkretne parametry do kompilatora. Arduino-cli ma taką możliwość, .trzeba dołączyć do wywołania coś takiego (nie wiem czy Arduino IDE na to pozwala, ale jeśli nie to można zgłosić jako feature request):

--build-property=compiler.ldflags=-Wl,-u,vfprintf -lprintf_flt -lm

Poza tym dotyczy to wyłącznie AVR-ów.

Poza tym również na AVR-ach działa bez problemu normalny printf, tylko trzeba go do tego zmusić (proponuję przeanalizować sobie przykłady do biblioteki nRF24L01). A np. dla ESP8266/ESP32 (i paru innych) printf jest metodą klasy Print, czyli można po prostu:

lcd.printf("%2d mA %2d mW %4d lx", amp, power, lux);

Zresztą to samo można zrobić również dla platform, które takiej metody w klasie Print nie posiadają - tyle że będzie to wymagało dopisania paru linijek kodu.

Reasumując: mechanizm wypisywania różnych rzeczy na różnych ustrojstwach istnieje od dawna (rodzina funkcji stdio/*printf), ma się dobrze i poza bardziej szczególnymi przypadkami (z wczoraj: wypisanie wartości trzech zmiennych na seriala przez ATtiny13) nie widzę potrzeby stosowania jakichkolwiek super-hiper-wspaniałych alternatyw.

[rziomber]

Wyświetlacze mają tendecję do migania przy czyszczeniu ekranu metodą clear().

Dla "kasofiskalnych" 16x2 i 20x4 rozwiązaniem jest podmiana znaków jeden po drugim.

    auto printLine = [](uint8_t line, char* str) {
      lcd.setCursor(0, line);
      lcd.print(str);
      for (uint8_t i = strlen(str); i < 20; i++) {
        lcd.print(" ");
      }
    };

    char line[21];
    snprintf(line, 21, "%.1fC %.1f%%", bme.readTemperature(), bme.readHumidity());
    printLine(1, line);

Dla wielu TFT niestety dojdzie do zsumowania poprzedniego obrazu z nowym tekstem (np spacja wypisana w miejscu litery nie zmieni niczego). Tutaj trzeba chyba rysować prostokąty w kolorze tła, by zamazać stary tekst.
A może macie lepsze rozwiązania? 🙂

[ethanak]

9 godzin temu, rziomber napisał:

Dla wielu TFT niestety dojdzie do zsumowania poprzedniego obrazu z nowym tekstem

Mylisz pojęcia.

Wyświetlacz TFT (wraz z układem sterującym, bo sam TFT raczej niewiele potrafi) nie wie nic o jakichś znakach, tekstach i podobnych firdymałkach. Potrafi postawić piksel w określonym kolorze w określonym miejscu na ekranie i niewiele więcej. To o czym piszesz to kwestia programu sterującego, a te mogą dużo więcej (warto sobie poczytać o tych możliwościach zanim się zacznie teoretyzować czego on nie potrafi).

Przykładowo - popularna biblioteka Adafruit GFX przy operowaniu wbudowanym fontem ma dwie możliwości. Wywołanie:

tft.setTextColor(fg);

spowoduje, że wyświetlanie tekstu będzie się odbywało tak jak piszesz (tzn. zmieniane będą tylko te piksele,które są ustawione w glifie). Ale już coś takiego:

tft.setTextColor(fg, bg);

będzie kontrolować wszystkie piksele w obrębie znaku (czyli nie będzie żadnego sumowania, ustawiony w glifie piksel będzie rysowany w kolorze fg, nieustawiony w kolorze bg).

Nie dotyczy to fontów proporcjonalnych, szczególnie w przypadkach, gdy jeden znak nachodzi na drugi (italic, odpowiedni kerning. ligatury). Tu już nie można operować kolorem tła. Ale i na to jest sposób - wystarczy wyczyścić tylko ten fragment na którym jest tekst (wspomniana biblioteka pozwala określić rozmiary pola które powinno być wyczyszczone).

Niestety - tu też będzie "migać", tyle że będzie to mniej zauważalne. Ale i na to jest sposób: można użyć czegoś w rodzaju canvas (we wspomnianej bibliotece są odpowiednie funkcje) aby narysować tekst gdzieś w obszarze pamięci poza ekranem, a potem szybko skopiować gotowy obrazek do wyświetlacza. Układy TFT SPI mają odpowiednie mechanizmy (patrz pojęcie "window").

Konkretne rozwiązanie wraz z kodem pokazałem kiedyś w wątku o modelarstwie kolejowym i skrolowaniu tekstu na rozkładzie jazdy - ale przecież kto by takie głupoty czytał...

 

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[rziomber]

14 godzin temu, ethanak napisał:

Przykładowo - popularna biblioteka Adafruit GFX przy operowaniu wbudowanym fontem ma dwie możliwości. Wywołanie:

tft.setTextColor(fg);

spowoduje, że wyświetlanie tekstu będzie się odbywało tak jak piszesz (tzn. zmieniane będą tylko te piksele,które są ustawione w glifie). Ale już coś takiego:

tft.setTextColor(fg, bg);

będzie kontrolować wszystkie piksele w obrębie znaku (czyli nie będzie żadnego sumowania, ustawiony w glifie piksel będzie rysowany w kolorze fg, nieustawiony w kolorze bg).

Cenna uwaga! https://learn.adafruit.com/adafruit-gfx-graphics-library/minimizing-redraw-flicker

Rzeczywiście wątek

jest skarbnicą wiedzy wszelakiej 🙂

Z "konkurencyjnego" obozu U8G2:

Cytat

To get output the complete display image U8G2 must be used in full buffer mode (Constructor with _F_, see also sendbuffer).

https://github.com/olikraus/u8g2/wiki/u8g2reference