Kategoria: Zrób to sam

VideoEditor 1.0.0.20

o 11 września 2022

VideoEditor 1.0.0.20 to prosty program, będący narzędziem znacznie ułatwiającym pracę ze wspaniałym ffmpeg.

Na ten moment, program umożliwia konwertowanie plików video oraz ich łatwe przycinanie.

Po uruchomieniu programu, należy wejść w ustawienia i zdefiniować ścieżkę do samego ffmpeg.exe. Skąd go wziąć? Można oczywiście go sobie zbudować, ale polecam skorzystać ze strony CODEX FFMPEG, gdzie są dostępne zawsze aktualne binaria.

Następnie polecam przejrzeć zakładkę z presetami kodeków video. Kilka zawarłem jako domyślne. Jeśli umiesz obsługiwać ffmpeg, możesz zdefiniować swoje własne nowe ustawienia.

Po skonfigurowaniu programu, po prostu otwórz plik video, zaznacz punkty przycięcia filmu, jeśli chcesz, wybierz preset konwersji i naciśnij “Convert”. Podajesz nazwę nowego pliku i czekasz na zakończenie konwersji.

Program będę dalej rozwijał i dodawał nowe funkcjonalności. W planach również obsługa różnych języków i instalator.

Dla chętnych, dostępne są źródła na GitHubie.

Program można pobrać tutaj. Miłej zabawy! 🙂

Sound analysis for visualization purposes

przez utak3r

o 6 grudnia 2020

w Komputerologia stosowana, Zrób to sam

Music analysis – part 1

I’m working on a small project (which will be revealed once it reaches some useful stage), and one of the things I need to work on, is to enabling sound visualization.

Visualizing the sound usually incorporates two factors: the amplitudes (which creates the ‘wave’) and a frequencies spectrogram. In this part we will try to do those analysis, however not ready for realtime visualizing yet, this will be made on the next stage – first we need to understand, what’s going on, before we start optimizing it.

We’re using here Python 3.8, together with some additional libraries – see imports section below.

For now we will use simple scipy.io.wavfile library for reading the sound files. For real usage we need to use a better library, as this one is pretty much limited.

In [64]:

import matplotlib.pyplot as plt
from matplotlib import colors as clrs
plt.rcParams['agg.path.chunksize'] = 10000
from scipy.io import wavfile as wav
from scipy.fftpack import fft, fftfreq
import numpy as np
from skimage.util import img_as_int
from skimage.transform import resize
from skimage import io, color, exposure

Reading a file¶

In our analysis we take the mono signal, so we have to convert it, if needed. After loading, we will check the basic parameters of the loaded file, like its length and sample rating.

In [124]:

samplerate, audio = wav.read('test_signal_03.wav')
if audio.ndim > 1:
    audio = np.mean(audio, axis=1) # we want mono!

num_samples = audio.shape[0]
audio_length = num_samples / samplerate
max_value = np.max(audio)

print(f'Audio length: {audio_length:.2f} seconds')
print(f'Audio samples: {num_samples}')
print(f'Max value:{max_value}')

fig, axes = plt.subplots()
axes.plot(np.arange(num_samples) / samplerate, audio)
axes.set_xlabel('Time [s]')
axes.set_ylabel('Amplitude');
plt.show()
plt.close(fig)

Audio length: 146.00 seconds
Audio samples: 6438600
Max value:24741.0

Selecting a fragment¶

For visualization, the whole file won’t give us anything useful. Both the amplitudes and especially the spectrogram, need to reflect some small portion of thw whole. What portion?

Visualization is a video. Video is made of frames. For each frame we need the new portion of data. Fortunately, video framerate is way lower than sound samplerate. We can select a portion of samples that reflect a selected period of time between two frames – current and the next one.

As input parameters, we take the current time in seconds and the target video framerate.

In [129]:

fps = 30
total_frames = int(audio_length * fps)
current_position = 100 # in seconds
current_frame = int(current_position*fps)
number_of_frames = 1 # number of frames to analyse
print(f'Current frame: {current_frame}/{total_frames}')

sample_start = int(current_frame / fps * samplerate)
sample_end = int((current_frame + number_of_frames) / fps * samplerate)
N = sample_end - sample_start
T = 1.0 / samplerate

Current frame: 3000/4380

Performing an analysis¶

We’re ready to perform the analysis. First one, amplitudes, is pretty straightforward, we just read the data from the file.

In [133]:

audio_part = audio[sample_start:sample_end]

For the spectrogram, we perform a 1-D discrete Fourier transform and put the results over the frequencies axis. FFT produces both negative and positive values. If input values are real numbers (as ours are) negative results are exactly same as positive ones (but negative, of course) – hence we can draw only the positive ones.

In [134]:

freqs = fftfreq(N, T)
spectrum = abs(fft(audio_part))[:int(freqs.size/2)]

Now we can plot the figures and see both.

In [136]:

fig=plt.figure(figsize=(10, 3))
axes=[]
axes.append(fig.add_subplot(1, 2, (1, 1)))
axes.append(fig.add_subplot(1, 2, (2, 2)))

axes[0].plot(np.arange(N) / samplerate, audio_part)
axes[0].set_xlabel('Time [s]')
axes[1].plot(freqs[:int(freqs.size/2)], spectrum)
axes[1].set_xlabel('Frequency [Hz]')

fig.tight_layout()    
plt.show()
plt.close(fig)

Color mapping¶

Before we prepare our textures for further use, we will prepare a special color map. We want the values to be represented in the red channel, from pure black to pure saturated red.

In [138]:

reds = plt.get_cmap('Reds', 256)
black_reds = reds(np.linspace(0, 1, 256))
for i in range(256):
    black_reds[i:i+1, :] = np.array([i/256, 0, 0, 1])
map_black_reds = clrs.ListedColormap(black_reds)

The final texture¶

We’re making a 512×512 texture, where top 256 lines are frequencies spectrogram, while bottom 256 lines are amplitudes.

In [141]:

audio_part_img = exposure.rescale_intensity(audio_part, out_range=(-1.0, 1.0))
audio_part_img = np.expand_dims(audio_part_img, axis=0)
audio_part_img = resize(audio_part_img, (256, 512), anti_aliasing=True)

spectrum_img = exposure.rescale_intensity(spectrum, out_range=(0, 100))
spectrum_img = np.expand_dims(spectrum_img, axis=0)
spectrum_img = resize(spectrum_img, (256, 512), anti_aliasing=True)

fig=plt.figure(figsize=(5.12, 5.12), dpi=100)
fig.subplots_adjust(hspace=0)
fig.tight_layout()
axes=[]
axes.append(fig.add_subplot(2, 1, 1))
axes[0].set_axis_off()
axes[0].margins(0)
axes.append(fig.add_subplot(2, 1, 2))
axes[1].set_axis_off()
axes[1].margins(0)

axes[0].imshow(spectrum_img, cmap=map_black_reds)
axes[1].imshow(audio_part_img, cmap=map_black_reds)

plt.savefig("test_sound.png", dpi=fig.dpi)
plt.show()
plt.close(fig)

Our resulting texture is exactly what we need for sound visualization. The problem is, producing it takes too much time and cannot be used for realtime usage. This problem we’ll solve next time.

Selektor koloru z trybem float

przez utak3r

o 11 sierpnia 2016

w Fotografia i grafika, Komputerologia stosowana, Zrób to sam

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… 🙁

Wybierz kolor:

Hex:

R:
G:
B:

RGB jako floaty:

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

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

przez utak3r

o 16 listopada 2015

w Komputerologia stosowana, Zrób to sam

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ę.

Android – backup danych aplikacji bez roota

przez utak3r

o 31 marca 2015

w Komputerologia stosowana, Zrób to sam

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 🙂

Timer do lampki

przez utak3r

o 27 maja 2010

w Zrób to sam

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!

PIC16F – Realizacja software’owego buforu odbioru USART

przez utak3r

o 21 maja 2010

w Zrób to sam

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.

PIC16F – obsługa LCD z Nokia 3310

przez utak3r

o 29 kwietnia 2010

w Zrób to sam

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.

Tu było foto: termometrfoto01small.jpg

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.

Tu było foto: termometrfoto03small.jpg Tu było foto: termometrfoto02small.jpg

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ł 🙂

Najprostszy programator PIC16F i pokrewnych

przez utak3r

o 18 kwietnia 2010

w Zrób to sam

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 😉