Selektor koloru z trybem float

Selektor koloru z trybem float

Jest wiele selektorów kolorów online. Większość zwraca wyniki w wartościach RGB z zakresu <0..255>, w zapisie szesnastkowym, oraz HSL. Jednak brakuje w nich wszystkich jeszcze jednej formy podawania wyników: w formie wartości RGB w zakresie <0..1>, używanym w niektórych programach, zwłaszcza 3D. Osobiście często używam POV-Raya i za każdym razem muszę używać kalkulatora, aby przeliczyć wszystkie trzy wartości na odpowiedni zakres.

Początkowo miałem zamiar napisać malutki programik do tego celu, ale stwierdziłem, że wersja on-line będzie wygodniejsza w użyciu. Nie jest to żadne rocket science 😉 ale swoje zadanie spełnia. Może w przyszłości jakoś go rozbuduję i usprawnię, ale… nie obiecuję 😉

Jeszcze jedna uwaga… poniższe nie działa z IE… 🙁






Może się komuś przyda – mi na pewno 🙂

Facebooktwittergoogle_plusredditpinterestlinkedinmail
twitterlinkedin

Android – dobór koloru tekstu pod kolor tła

Gdy dodajemy tekst na jakimś tle, którego kolor ustawiany jest dynamicznie, mamy problem: jaki kolor tekstu? Czarny czy biały?

Aby rozwiązać ten problem, należy sprawdzić, jak jasny jest kolor tła. Problem w tym, że wpływ poszczególnych komponentów RGB na ogólną jasność jest różna, stąd trzeba ową jasność policzyć uwzględniając tę zasadę. Ja użyłem dość popularnej w internecie formuły – i spisuje się naprawdę dobrze.

    /**
     * Find the right color of the text, depending on the color of the background.
     * @param aColor Color, to which we're adjusting by contrast.
     * @return Black or white color.
     */
    public int getBlackOrWhite(int aColor)
    {
        int red = (aColor >> 16) & 0xFF;
        int green = (aColor >> 8) & 0xFF;
        int blue = (aColor >> 0) & 0xFF;
        int result = 0;
        if (((double)red*0.299 + (double)green*0.587 + (double)blue*0.114) > 186)
            result = Color.BLACK;
        else
            result = Color.WHITE;
        return result;
    }

Parametrem wejściowym jest kolor tła, wartość zwracana to kolor czarny lub biały. Formuła doboru wygląda na dobrą, bo spośród tych kolorów, które przetestowałem, wybór: czarny-biały zawsze był trafny, stąd mogę ją z czystym sumieniem polecić – co też czynię.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
twitterlinkedin

Android – backup danych aplikacji bez roota

Ostatnio musiałem się zmierzyć z przeniesieniem danych pomiędzy dwoma telefonami Androidowymi, które nie są zrootowane. Szczerze mówiąc, nigdy tego jeszcze nie robiłem, bo w swoich urządzeniach root jest pierwszą czynnością, którą wykonuję po rozpakowaniu 😉 dlatego też postanowiłem się podzielić z wami efektami prac.

Jedyne narzędzie, którego będziesz potrzebować (poza sterownikami USB do telefonu, które powinny się automatycznie zainstalować po podłączeniu telefonu) to Android Platform Tools, którego głównym składnikiem jest Android Debug Bridge (ADB). Android Platform Tools normalnie wchodzą w skład Android SDK i stamtąd właśnie należy je pobrać, ale ktoś, kto potrzebuje jedynie wykonać kilka prostych czynności, nie musi chcieć ciągnąć tego całego bagażu. Tutaj możecie pobrać paczuszkę przygotowaną przeze mnie. Są to Platform Tools w wersji 22, czyli najnowszej na dzień dzisiejszy, obsługującej Android 5.1.

Zanim jednak będziecie mogli użyć ADB na swoim telefonie, należy włączyć ukryte menu w ustawieniach telefonu. Idziemy do Ustawienia → Informacje o urządzeniu i klikamy raz za razem pozycję Numer wersji. Po około 10 tapnięciach pokaże się komunikat, że nowe menu zostało włączone. Wracamy do Ustawień i widzimy nowe menu: Opcje programisty. Wchodzimy do środka i zaznaczamy opcję Debugowanie USB. Od tej chwili możemy używać ADB.

debug_usb

Rozpakowujemy Platform Tools do jakiegoś katalogu. Najlepiej dodać sobie ścieżkę do niego do zmiennej $PATH, żeby móc z adb korzystać z dowolnego miejsca. Sprawdzamy, czy działa:

\> adb version
Android Debug Bridge version 1.0.32

Jeśli działa, podpinamy telefon, odczekujemy, aż system zainstaluje nowe sterowniki USB (z powodu aktywacji trybu debugowania) i sprawdzamy, czy urządzenie jest widoczne:

\> adb devices
List of devices attached
10feda99 device

Sukces! Można działać 🙂

Jeśli powyżej ujrzysz kilka urządzeń na liście, wszystkie dalsze komendy musisz poprzedzić opcją -s z identyfikatorem urządenia.

Sama czynność backupu jest w zasadzie banalna. Zacznijmy od opcji backupowania jednej lub kilku wybranych aplikacji:

\> adb backup -f CatchNotes.ab -apk com.threebanana.notes com.catchnotes.sketch.samsung
Now unlock your device and confirm the backup operation.

Co tu widzimy? Zleciłem backup dwóch aplikacji (com.threebanana.notes oraz com.catchnotes.sketch.samsung) tworzących pakiet Catch Notes i plugin do niego (już niedostępne w sklepie Play – a szkoda). Backup danych wraz z samą instalką aplikacji (APK). Kopia zapasowa zostanie zapisana do pliku CatchNotes.ab. Poniżej widać, że program każe wziąć do ręki telefon.

backup

Jeśli korzystamy z szyfrowania naszych danych w telefonie, wpisujemy hasło i następnie Utwórz kopię zapasową danych. I… to tyle 🙂  na dysku zostanie utworzony plik o nazwie CatchNotes.ab, zawierający dwie instalki APK wraz z danymi obu aplikacji.

Nie wszystkie aplikacje spełniają zalecenia Androida i stosują się do jego zasad (a jakże…). Np. taka gra Temple Run 2 przechowuje swoje dane inaczej niż pozostałe aplikacje, co spowoduje, że powyższy sposób nie zachowa owych danych. Co robić? Musimy skopiować je ręcznie. Wchodzimy Eksploratorem (lub Total Commanderem, jeśli jesteśmy świadomymi użytkownikami komputera 😉 ) do telefonu i wchodzimy do katalogu Phone\Android\data. Zobaczymy tam całą masę katalogów, a wśród nich com.imangi.templerun2. Kopiujemy na komputer cały katalog. W urządzeniu docelowym musimy koniecznie najpierw zainstalować aplikację, a później nadpisać ten sam katalog naszą kopią.

templerun2_data

Oprócz kopii zapasowej wybranych aplikacji, możemy chcieć wykonać pełny backup. Mamy do dyspozycji kilka dodatkowych opcji:

  • -shared spowoduje skopiowanie wszystkich danych współdzielonych i z karty SD.
  • -all spowoduje skopiowanie wszystkich aplikacji, bez ich podawania w komendzie.
  • -system / -nosystem jeśli podaliśmy opcję -all, ta opcja decyduje, czy backupujemy tylko aplikacje użytkownika, czy również aplikacje systemowe.

Np.:

\> adb backup -apk -shared -all

Taka opcja zajmie sporo czasu i wygeneruje potężny plik.

 

Jak taką kopię zapasową później przywrócić?

\> adb restore mojakopia.ab

i… tyle 🙂

 

I tak już na końcu, jako bonus… wśród naprawdę wielu fajnych rzeczy, które można zrobić przy pomocy ADB, jest m.in. również nagrywanie ekranu (tylko na nowszych Androidach):

\> adb shell screenrecord /storage/extSdCard/test123.mp4

Video jest mocno skompresowane, ale do prezentacji jakiejś opcji czy czynności nadaje się świetnie 🙂

Facebooktwittergoogle_plusredditpinterestlinkedinmail
twitterlinkedin

Timer do lampki

W pokoju córeczki, gdy idzie spać, zostawiamy małą lampeczkę włączoną. Potem, gdy nam się o niej przypomni, należy ją wyłączyć. Owo „gdy nam się o niej przypomni” trwa od godziny do 6 godzin 😉 Problem nie jest w poborze prądu, którego ta lampeczka pożera naprawdę niewiele, ale w tym, że jeśli się przebudzi w czasie, gdy lampka wciąż będzie się świecić, to albo się rozbudza, albo zabrania jej gasić – na kolejny okres czasu. Gdy się przebudzi przy zgaszonej już lampce – nie ma problemu. Dlatego też postanowiłem zbudować małego pomocnika w słusznej sprawie: timer dla urządzeń zasilanych z sieci 230V.

Schemat elektryczny tego urządzenia jest zwyczajnie banalny – ot, standardowe połączenie multipleksowanych dwóch cyfr 7-segmentowego wyświetlacza LED do mikrokontrolera PIC16F628A. Jako interfejs ustawiania zadanego czasu, można było zastosować dwa przyciski, ale ja u siebie wstawiłem enkoder obrotowy, który w obsłudze końcowej jest nieporównywalnie przyjemniejszy od przycisków – zwłaszcza, gdy przyjdzie nam ustawić czas rzędu np. 90 minut 😉 Zastosowanie enkodera pociąga za sobą zmiany w programie, gdyż działa on tak, że za pomocą dwu-bitowego kodu Graya odczytujemy stan urządzenia – a stany mogą być trzy: w lewo, w prawo i nieokreślony. Dlatego też oprogramowanie wewnętrzne mikrokontrolera nie będzie niestety pasować do zwykłych przycisków.

Modułem wykonawczym może być dowolna realizacja… może to być przekaźnik z cewką 5V, może być z własnym zasilaniem (np. 12V), może też to być zestaw optotriak-triak. Tę ostatnią opcję wybrałem dla swojej realizacji, jako, że z powodu swojego charakteru pasuje tutaj najbardziej do projektu. Poniżej możecie zobaczyć schematy pokazujące, jak zrealizować takie moduły wykonawcze.

Wsad do mikrokontrolera można pobrać tutaj. W razie jakichkolwiek problemów, czy to ze schematem, czy z oprogramowaniem – pytać 🙂 Jeżeli macie jakieś pomysły na usprawnienie urządzonka – pisać. Miłego odliczania czasu!

Facebooktwittergoogle_plusredditpinterestlinkedinmail
twitterlinkedin

PIC16F – Realizacja software’owego buforu odbioru USART

Pracowałem ostatnimi dniami nad małym kontrolerkiem, sterowanym przez RS232. Obsługa niektórych poleceń, wydawanych do niego, trwała nawet po kilka milisekund i… okazało się, że użyty przeze mnie 16F628A ma bufor wejściowy USARTa rozmiaru… 2 bajtów. Tak, to nie pomyłka 😐 Dlatego postanowiłem napisać obsługę cyklicznego bufora wejściowego – o rozmiarze wg uznania 🙂 Poniżej przedstawiam wam, jak coś takiego zrealizować. Na początku, zmienne globalne:

#define RX_BUFOR_MAX        32
unsigned char buforRX[RX_BUFOR_MAX];
unsigned char *buforRX_head, *buforRX_end, *RXreadstart, RXbajt;

i podczas inicjalizacji programu:

    // ustawiamy bufor odbioru danych z UARTa
    buforRX_head = buforRX;
    buforRX_end = buforRX + RX_BUFOR_MAX;
    RXreadstart = buforRX;

Tyle przygotowań. Proces odbioru danych i składowanie ich w cyklicznym buforze zrealizujemy w przerwaniu. Najpierw odpalamy przerwanie:

   STATUS.RP0 = 1;
   PIE1.RCIE = 1; // przerwanie odbioru danych z UARTa
   STATUS.RP0 = 0;
   PIR1 = 0;
   INTCON.GIE = 1;
   INTCON.PEIE = 1;

I definiujemy obsługę:

void    interrupt(void)
{
  // przyszedł znak z UARTa
  if (PIR1.RCIF)
  {
      // cykliczny bufor z użyciem "indirect addressing"
      asm {
          movf RCREG,W
          movwf _RXbajt
          movf _buforRX_head, W
          movwf FSR
          movf _RXbajt, W
          movwf INDF
          incf _buforRX_head, f
      }
      if (buforRX_head == buforRX_end) // koniec buforu,
          buforRX_head = buforRX;         // zawijamy ogon.
         
      PIR1.RCIF = 0; // koniec przerwania
  }
}

Pozostało nam napisanie funkcji korzystających z owego bufora. Wpierw funkcja badająca, czy w buforze czeka na nas jakiś nieprzetworzony znak:

// czy w cyklicznym buforze czekają dane do odczytania?
unsigned char BUFRS_Data_Ready()
{
    if (RXreadstart == buforRX_head)
        return 0;
    else
        return 1;
}

No i funkcja odczytująca kolejny znak:

// odczyt znaku z cyklicznego buforu
unsigned char BUFRS_Read()
{
    unsigned char bajt;
    asm {
        movf _RXreadstart, W
        movwf FSR
        movf INDF, W
        movwf BUFRS_Read_bajt_L0
        incf _RXreadstart, f
    }
    if (RXreadstart == buforRX_end)
        RXreadstart = buforRX;
    return bajt;
}

Na koniec przedstawię jeszcze moją małą funkcję odczytującą znak z określonym timeoutem operacji:

void BUFRS_Read_Timeout(unsigned char *bajt, unsigned char timeout)
{
    unsigned char tout, read;
    tout = 0;
    read = 1;
    *bajt = 0;
    while ((read == 1) && (tout < timeout))
    {
        if (BUFRS_Data_Ready() > 0)
        {
            *bajt = BUFRS_Read();
            read = 0;
        }
        else
            tout++;
    }
}

To tyle. U mnie – jak już pisałem, obsługa niektórych znaków zajmuje kilka milisekund, niektórych kilka mikrosekund – całość działa poprawnie przy 19200 (kwarc 20MHz). Oczywiście, powyższe działa tylko na mikrokontrolerach wyposażonych w sprzętowy moduł USART. Powodzenia.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
twitterlinkedin

PIC16F – obsługa LCD z Nokia 3310

Zabawiałem się w ostatnich dniach wyświetlaczem LCD z poczciwej Nokii 3310. LCD nie jest rewelacyjny, ale ma te swoje 84×48 pikseli monochromatycznego obrazu. W trybie tekstowym, z małą czcionką, wystarcza to na 6 rzędów po 14 znaków.

Szukając w sieci biblioteki do jego obsługi, przejrzałem zyliony projektów typu „LCD-on-LPT” i nieco mniej, bo już tylko miliony 😉 projektów na wszelkie AVRki. PICe jakoś słabo były reprezentowane, a już mikroC najsłabiej. Dlatego skompilowałem z wszystkich dostępnych mi materiałów działającą bibliotekę. Z powodzeniem uruchomiłem ją na 2kB procesorze 16F628A (uwaga: LCD pracuje pod napięciem 3.3V!!) Na chwilę obecną, biblioteka pozwala na wyświetlanie napisów w dwóch różnych rozmiarach – przy użyciu tylko jednego zdefiniowanego kroju pisma – skalowanie następuje w locie, podczas wyświetlania. W planach dodanie grafiki. Biblioteka dostępna jest jako LGPL, podczas jej opracowywania, jak już wspominałem, wykorzystywałem różne źródła (no i własną pracę). Największymi dawcami idei i pomysłów byli Louis Frigon oraz Lieven Hollevoet. Załączam również przykładowy projekt, wykorzystujący ów LCD i bibliotekę – taki mały zegarko-termometr Dzięki niemu można dowiedzieć się, jak podłączyć wyświetlacz i jak skorzystać z biblioteki. Zwracam tylko uwagę na konieczność ustawienia swoich pinów LCD w pliku N3310LCD.h.

 

Bibliotekę oraz przykładowy projekt znaleźć można na forum elektrody. A następny LCD w kolejce do rozpracowania jest przyjemny LCD kolorowy, o wymiarach 128×128 pikseli – dostępny na allegro za ok. 20zł 🙂

Facebooktwittergoogle_plusredditpinterestlinkedinmail
twitterlinkedin

Najprostszy programator PIC16F i pokrewnych

Podczas poszukiwania kilku elementów w mojej przepastnej szafie, odnalazłem dwa zagubione egzemplarze mikrokontrolera PIC 16F628A firmy Microchip… Dodając do tego, że od dawna myślałem o powrocie do mikrokontrolerów, a także że od kilku lat dzień w dzień widuję się z kolegą, który wciąż mnie namawia do tego (a sam jest specem) – no cóż, te dwie odnalezione kostki dopełniły dzieła i… wróciłem do zajmowania się nimi 🙂 W dzisiejszych czasach królują dwie rodziny małych mikrokontrolerów – AVRy od Atmela i PICe od Microchipa. Zwłaszcza wśród nowo zaczynających (m.in. dzięki „Oślej Łączce” z czasopism AVT) popularne są AVR. Ja jednak PICe już znam – to po pierwsze, a po drugie, mimo wszystko, PICe uważam za lepszy wybór (ale wojen żadnych nie mam zamiaru toczyć z nikim w tym temacie).
Zabawa rozpoczęła się oczywiście od budowy programatora. Z czasem i tak zakupię duży programator na USB, z możliwością debugowania, ale na razie… wychodząc z założenia, że to tylko chwilowe rozwiązanie, należało znaleźć coś, co jest najprostsze i najtańsze w produkcji. Wybór padł na JDM, ale jak się szybko okazało, większość dostępnych schematów odnosi się do starszych przedstawicieli 16F. Dlatego Dostosowałem schemat do warunków programowania 16F628A, przy okazji upraszczając schemat JDM (i tak już prosty). Po trzech dniach walk i prób na breadboardzie (płytce stykowej) osiągnąłem działający egzemplarz. Kilka dni intensywnego działania – programuje 100 na 100 🙂 Dlatego też już poszedł na płytkę drukowaną. Przy okazji, wyposażyłem go w złącze ICSP, które sppisuje się świetnie (o programowaniu ICSP powiem potem kilka słów jeszcze). Schemat? Schemat jest prosty jak… drut 😉 Wygląda bardziej skomplikowanie, niż to jest w rzeczywistości – a to za sprawą wyprowadzenia dodatkowego złącza ICSP.
Płytki PCB nawet nie projektowałem, w pół godziny polutujecie wszystko sobie na dowolnej płytce uniwersalnej. Jedyny problem to gniazdo RS232, w którym trzeba będzie nieco ponaginać piny… osobiście piny 6 oraz 9 usunąłem, natomiast piny 7 i 8 lekko nagiąłem – w ten sposób całe gniazdo ładnie osiadło w rastrze 2,54 mm. Jako gniazdo pod procesor dałem podstawkę DIL18, ale jeżeli znajdziecie gniazdo ZIF – polecam. Do programowania ICSP postawiłem sobie gniazdo 2×5 pinów, takie, jakie widać na płytach komputerowych (taśma 10 żył). Dlaczego takie? Po pierwsze, taśmę 10 pin łatwo dostać 😉 a po drugie, po podłączeniu całego jednego rzędu w tym gnieździe do masy, na taśmie co druga żyła to masa właśnie. Ma to niebagatelne znaczenie, gdyż okazuje się, iż największym problemem w taśmach do ICSP jest linia CLOCK. Dlatego więc: taśmę robimy tylko tak długą, jak jest to potrzebne, linię CLOCK odseparować, o ile to możliwe, dodatkowo linie przedzielone masą: świetna sprawa. Warto zrobić sobie dwie taśmy: jedną zakończoną wtyczką z obu stron, drugą z wtyczką i po drugiej stronie rozdzielonymi i odizolowanymi kabelkami, dodatkowo pobielonymi cyną. Po co? Do włożenia w breadboard, żeby podczas prototypowania układu nie przekładać czipa w te i we wte co dwie minuty.
Na koniec kilka słów o dostosowywaniu układu docelowego do przyszłego programowania poprzez ICSP. Dwie najważniejsze sprawy, to bezwzględne odłączenie oryginalnego zasilania układu podczas programowania (a to z kolei pociąga za sobą, aby linię Vdd z gniazda podłączyć bezpośrednio do procesora, a nie do wspólnego punktu zasilania) oraz separacja linii Vpp – na przykład diodą. Takie rozwiązania wyklucza co prawda ten port z bycia ewentualnym wyjściem, ale… pamiętaj, że podczas programowania Vpp wynosi do 13V! Jedynym innym wyjściem jest zastosowanie wyłącznika mechanicznego. Z pozostałych problemów, warto jest nie używać, o ile to nie jest koniecznie, linii CLOCK i DATA, gdyż podczas programowania podpięte układy mogą wprowadzić zakłócenia uniemożliwiające poprawne zaprogramowanie układu.
To tyle, życzę miłego programowania 😉
Facebooktwittergoogle_plusredditpinterestlinkedinmail
twitterlinkedin