Poznaj układy PLD cz.5 - Tworzenie komponentów schematowych, PSoC, modularyzacja

Modularyzacja - co to znaczy?

Modularyzację można rozumieć na dwa sposoby. Po pierwsze jako pogrupowanie komponentów tworzących pewną logiczną całość w taki sposób, by grupa wyraźnie odcinała się od pozostałych składników układu. Po drugie jako wyodrębnienie powtarzających się składników układu i zamknięcie ich w specjalizowane komponenty. Oba te aspekty są dobrze wspierane przez PSoC Creator.

W każdym z nich chodzi „tylko” o wyraźne podkreślenie intencji jego twórcy, m.in. poprzez podniesienie czytelności schematu. Osiąga się to jednak innymi środkami. Choć dzięki modularyzacji nie osiągniemy niczego więcej, niż potrafiliśmy zrobić do tej pory, to po stopniu opanowania przede wszystkim tej techniki można poznać, czym „jakość” różni się od „jakoś”. Bardzo pouczającym sprawdzianem jest powrót po upływie kilku miesięcy do własnego projektu i próba odgadnięcia, co poeta miał wówczas na myśli. Zawodowcy wiedzą dobrze, że programów nie pisze się dla komputerów, tylko dla ludzi – a jeśli sami nie będziemy rozumieli siebie, to jak wymagać tego od innych?

Przejdźmy do rzeczy: na początek zajmijmy się pierwszym aspektem, bo mamy już niemal wszystkie potrzebne narzędzia. Wnikliwi Czytelnicy zauważyli już pewnie, że arkusz schematu po utworzeniu domyślnie nazywa się „Page 1”. A skoro jest strona pierwsza, to zapewne może być i druga. Istotnie, po kliknięciu prawym klawiszem myszki nad etykietką arkusza pojawi się menu zarządzania arkuszami (rysunek 1).

Rys.1 PSoC Creator - menu zarządzania arkuszami

Nazwy Add Schematic Page, Delete Page i Rename Page mówią same za siebie. Możemy dodać do schematu dowolnie wiele arkuszy, a dzięki ostatniej opcji ich nazwy uczynić znaczącymi, np. Zasilacz. Podkreślam, że arkusze są jedynie elementem prezentacyjno-edycyjnym: do syntezy wsadu dla układu PLD jest brany ich pełny komplet, który podlega przetwarzaniu jako całość. Niemal, bo wybrane arkusze można wyłączyć z procesu syntezy dzięki czwartej opcji z menu: Disable Page. Dzięki temu możemy nie tylko umieszczać niezbędne bloki funkcjonalne na dedykowanych arkuszach, ale też tworzyć np. arkusze z opcjonalnymi elementami diagnostycznymi, potrzebnymi tylko w fazie uruchamiania układu oraz usuwania błędów. Układ docelowy może być ich pozbawiony bez potrzeby fizycznego usuwania komponentów ze schematu – nigdy nie wiadomo, kiedy diagnostyka znów stanie się potrzebna.

Jedyną wątpliwość może wzbudzić sposób przekazywania sygnałów pomiędzy dwoma arkuszami. Nie ma przecież możliwości narysowania połączenia pomiędzy nimi. Rozwiązaniem przyjętym w PSoC Creatorze jest mechanizm nazwanych sygnałów. Każde połączenie na schemacie ma jakąś nazwę, choć zazwyczaj nie interesujemy się nią i pozostawiamy jej wygenerowanie narzędziu.

Rys.2 PSoC Creator - wizard połączenia

Tak jednak być nie musi, dwukrotne kliknięcie na wybrane połączenie przywołuje wizard (rysunek 2), w którym możemy nadać połączeniu własną nazwę w polu (2), po uprzednim „odptaszeniu” kontrolki (1). PSoC Creator uznaje wtedy, że jeśli dwa połączenia nazywają się tak samo, to w istocie są tym samym połączeniem, niezależnie od arkuszy, na których się znajdują.

„Wiszące przewody” nie wyglądają jednak estetycznie i mogą sugerować, że praca nad danym arkuszem nie została jeszcze zakończona, więc w celu jasnego wyrażenia intencji PSoC Creator dostarcza nam „wirtualnego” komponentu – diamentu, który pełni funkcję „terminatora” takich połączeń. Mieliśmy z nim już styczność w poprzednim odcinku, choć użyliśmy go w innym celu: ukrywania połączeń niezbędnych, lecz „zaciemniających” schemat.

Skorzystajmy z okazji, że jesteśmy przy wizardzie połączeń i omówmy go do końca. W sekcji Indices (3) domyślną opcją jest None, bo zazwyczaj mamy do czynienia z pojedynczym połączeniem. Wybierając opcję Bus, możemy jednak utworzyć całą grupę logicznie powiązanych połączeń – szynę, podając zakresy indeksów zaczynające się od 0. Zwyczajowo lewy indeks jest tym większym.

Dziwić może nadmiarowa możliwość podawania obu indeksów, skoro tworzymy szyny wielobitowe, np. 32-bitowe. Nazwa szyny będzie postaci np. DATA[31:0], więc po co komu prawy indeks? Istotnie, informacja ta jest nadmiarowa, dopóki tworzymy nową szynę, ale co w sytuacji, gdy z istniejącej szyny chcielibyśmy wybrać tylko interesujący nas podzbiór przewodów, np. grupy DATA[31:16] oraz DATA[15:0]? Wówczas prawy indeks okazuje się niezbędny, a wymuszenie jego podania prowadzi do jednolitego interfejsu zarówno na poziomie graficznym, jak i w Verilogu.

Procedura podziału jest bardzo intuicyjna: po prostu rysuje się nowe połączenie i łączy je z większą szyną. Następnie w wizardzie tego połączenia możemy podać potrzebny zakres i wszystkie połączenia między szynami powstaną automatycznie. Jeżeli interesuje nas podłączenie się do tylko jednego sygnału z szyny, wybieramy opcję Bit i podajemy numer interesującego nas przewodu.

Prościej się już tego chyba zrobić nie dało. Przykładowe możliwości pokazuje rysunek 3.

Dzięki „diamentowi” i podziałowi schematu urządzenia na dobrze określone bloki funkcjonalne, zawarte na osobnych arkuszach, możemy znacznie poprawić czytelność projektu.

Rys.3 Przykładowe połączenia

Może się jednak okazać, że podczas wykonywania podziału zdamy sobie sprawę, że wydzielony właśnie blok nadaje się do samodzielnego istnienia i będzie go można użyć również w innych projektach. Może też się okazać, że w projekcie istnieje wiele replik tego samego bloku i nie ma sensu kilkakrotnie klonować identycznej funkcjonalności. Dlaczego więc nie spróbować zamknąć schematu bloku w osobnym „pudełku” i dalej posługiwać się już tylko tym pudełkiem, bez potrzeby szczegółowego wnikania w jego realizację układową?

Jest to jak najbardziej słuszny wniosek, który prowadzi nas wprost do tworzenia własnych komponentów. Konkretnie do ich najprostszej postaci, zwanej komponentem schematowym.

Tworzenie komponentów schematowcyh - PSoC Creator

Każdy komponent dostępny w PSoC Creatorze składa się z interfejsu, parametrów i tworzących go plików; może też istnieć w kilku wersjach. Plików wchodzących w skład komponentu może być wiele: implementacja warstwy sprzętowej w Verilogu, pliki w C dostarczające API do wygodnego dostępu do egzemplarza komponentu w programie, dokumentacja podręczna w PDF (jeśli zdecydujemy się ją napisać i dostarczyć) itp.

Ale po kolei. Najprościej będzie nauczyć się tego na przykładzie. Otwórzmy więc archiwum zawierające projekt dołączony do odcinka marcowego (timer 555) i spróbujmy przekształcić zawarty w nim schemat timera w komponent. Komponenty można trzymać razem z innymi elementami projektu, ale lepiej wydzielić dla nich osobny projekt biblioteczny. Zaznaczamy więc Workspace ‘EdW03’ w zakładce Workspace Explorer i w menu dostępnym pod prawym klawiszem myszy wybieramy Add→ New project.

Rys.4 Zakładka 'Components' - PSoC Creator

W wizardzie tworzenia projektu wybieramy ‘Library project’ i przechodzimy dalej. Na następnej stronie należy zaznaczyć architektury CPU, na których mają działać nasze komponenty. Kosztem większego wysiłku można tworzyć komponenty uniwersalne, ale w chwili obecnej interesuje nas tylko właściwy dla rodziny 5LP rdzeń Cortex M3. W następnej zakładce podajemy ścieżkę do projektu (ja zostawiłem zaproponowaną przez narzędzie) oraz nazwę projektu – ja swój nazwałem Custom.

Otrzymaliśmy pusty projekt, do którego możemy dodawać teraz komponenty. Przechodzimy na zakładkę Components (rysunek 4), zaznaczamy „Project Custom” i z menu wybieramy Add Component Item. Będziemy chcieli skorzystać z edytora symboli, więc w wizardzie zaznaczamy Symbol→Symbol Wizard. W polu Component name wpisujemy „EDW555”. Jeżeli do nazwy dodamy sufiks postaci „_vX_Y”, gdzie X jest numerem wersji, a Y podwersji, PSoC Creator rozpozna ten wzorzec i przyjmie, że zamierzamy skorzystać z wersjonowania komponentu. To użyteczna własność, więc nazwę komponentu zmieniamy na „EDW555_v1_0” i klikamy Create New. Prowadzi to nas do etapu edycji symbolu komponentu (rysunek 5).

Rys.5 Edycja symbolu komponentu

W zakładce Terminal name (1) podajemy nazwę wyprowadzenia komponentu, a w zakładce Type (2) jego rodzaj. Dopuszczalne typy są opisane intuicyjnie na rozwijanej liście związanej z danym wyprowadzeniem, więc nie ma potrzeby ich szerszego omawiania. Za pomocą kontrolek (4) można zmieniać wzajemne położenie wyprowadzeń (co zmienia ich kolejność na „obudowie” komponentu), kasować niepotrzebne wyprowadzenia oraz zmienić kolor belki tytułowej symbolu komponentu. Podgląd symbolu jest dostępny na bieżąco w okienku (3). Po wypełnieniu listy potrzebnych wyprowadzeń klikamy OK.

PSoC Creator prowadzi nas do drugiego poziomu edytora symboli, gdzie możemy zmienić proporcje elementów komponentu, przesunąć wyprowadzenia itp. Ja powiększyłem nieco ramkę komponentu, wprowadziłem większe odstępy między wyprowadzeniami i skorygowałem zawartość belki tytułowej (rysunek 6).

Rys.6 Zmienione proporcje elementów komponentu

Jeżeli w toku prac symbol komponentu będzie wymagał modyfikacji, zawsze możemy wrócić do niniejszego edytora poprzez otwarcie związanego z komponentem pliku symbolu *.cysym (w naszym przypadku EDW555_v1_0.cysym) w wizardzie nawigacji po składowych projektu po lewej stronie okna głównego.

Drugą istotną cechą edytora symbolu jest możliwość określenia właściwości komponentu. Należy kliknąć prawym klawiszem myszy poza symbolem komponentu i z menu wybrać Properties.

W wizardzie właściwości można wpisać między innymi informacje o autorze, ale są tam i inne istotne ustawienia. Pierwsze służy do określenia lokalizacji, w której komponent zostanie umieszczony w katalogu.

W Symbol→ Doc.CatalogPlacement klikamy na ‘...’ i wpisujemy napis postaci „/MojaZakładka/MojaKategoria/”. Ja wpisałem „/Moje/Generatory/”. Uwaga na ukośniki, program zwraca na nie uwagę!

Komponent jest już dostępny, choć PSoC Creator ukrywa go przed nami z powodu braku implementacji – jak dotąd mamy jedynie symbol. Jeśli pomimo tego chcemy komponent zobaczyć, musimy zrobić dwie rzeczy. Po pierwsze, PSoC Creator nie wie, że projekt główny (ne555) zależy od zawartości biblioteki Custom. Wracamy więc do widoku projektu (zakładka source w wizardzie Workspace Explorer), zaznaczamy „Project ‘ne555’ i z menu pod prawym klawiszem myszy zaznaczamy Dependencies. W sekcji User Dependencies pojawi się nasza biblioteka Custom i musimy „zaptaszyć” ją w kolumnie Components.

Następnie w głównym menu Tools→Options→Design Entry→ Component Catalog wybieramy Show Hidden Components. Elementy ukryte to takie, których nie możemy lub – zdaniem PSoC Creatora – nie powinniśmy widzieć. Nie możemy, bo brakuje im implementacji lub nie są przeznaczone dla naszej platformy. Nie powinniśmy, bo są to skomplikowane i trudne do użycia komponenty niskopoziomowe, przez obudowanie których powstają „przyjaźniejsze” warianty przeznaczone dla mniej doświadczonych użytkowników. Dobre pojęcie o różnicach daje porównanie np. „nagiego” komponentu Analog Primitives → SAR [v2.0] z „przyjaznym” Analog→ADC→SAR ADC [v3.10]. My do początkujących już nie należymy, więc perspektywa poznania prawdy o komponentach nas nie przeraża. :)

W wyniku powyższych działań w katalogu komponentów pojawiła się nowa zakładka (rysunek 7), a w niej nasz timer. Sukces!

Rys.7 Nowa zakładka w katalogu komponentów 

Co prawda jeszcze niepełny, bo PSoC Creator słusznie protestuje, że komponent bez implementacji jest bezużyteczny. Pozwala go jednak przeciągnąć na schemat i podłączyć, więc ewidentnie osiągnęliśmy postęp.

Dodajmy teraz brakujące elementy. Wracamy do zakładki Components, zaznaczamy Project ‘Custom’ →EDW555_v1_0 i z menu pod prawym klawiszem wybieramy Add Component Item. Implementacja będzie opierała się na schemacie, więc dokładnie to wybieramy: Implementation→Schematic i klikamy Create New.

Rys.8

Narzędzie zapyta nas o rozmiar planszy schematu: ja zaznaczyłem zaproponowaną wielkość domyślną. Przełączamy się na zakładkę Source i ze schematu projektu głównego TopDesign.cysch wycinamy wszystkie wnętrzności układu 555, ale bez pinów: po objęciu zaznaczeniem całej kolorowej podkładki wciskamy Ctrl-X. Następnie wracamy do Project ‘Custom’ →EDW555_v1_0.cysch i wklejamy wyciętą zawartość poprzez Ctrl-V. Zauważamy też, że menu rysowania schematów powiększyło się nam o paletę terminali (rysunek 8). Trzeba więc dodać do schematu terminale o odpowiednich nazwach i odpowiedniego typu, a następnie połączyć je z pozostałą częścią układu. Efekt końcowy pokazują rysunki 9 (wnętrzności układu) i 10 (przykładowe użycie).

Możemy teraz spróbować uruchomić syntezę projektu – zakończy się ona niepowodzeniem, ale okazuje się, że proces zaszedł zaskakująco daleko i zatrzymał się dopiero na kompilacji pliku main.c, która jest jednym z ostatnich etapów syntezy.

Rys.9 Schemat 'wnętrzności' układu

Konkretnie, brakuje definicji funkcji VDAC8_1_Start(); itp., które stanowiły część oryginalnego projektu i zostały automatycznie wygenerowane przez kompilator na podstawie schematu marcowej wersji układu EDW555. Oczywiście wszystkie użyte wtedy bloki dalej są potrzebne, ale teraz nie są już one częścią projektu, lecz częścią komponentu.

Rys.10 Przykładowe użycie

Komponent z kolei jest czarną skrzynką, której zawartość z zasady nie jest ujawniana użytkownikowi, stąd właściwe skonfigurowanie tej zawartości jest obowiązkiem komponentu, a nie użytkownika. W tym celu w skład definicji komponentu wchodzi nie tylko utworzony już przez nas schemat, ale również pliki w C, których zadaniem jest udostępnienie użytkownikowi interfejsu (API, Application Programming Interface) do komunikacji z komponentem. Częścią takiego API jest m.in. wspomniana już funkcja VDAC8_1_Start(), która „magicznie” pojawiła się po użyciu przetwornika DAC. Opanowanie podstaw tej magii jest właśnie naszym następnym celem.

Dla osób mających pewne doświadczenie w programowaniu w C nie będzie niczym zaskakującym, że API komponentu składa się z (co najmniej) dwóch plików. Pierwszy z nich to tzw. plik nagłówkowy (header, zwyczajowo noszący rozszerzenie *.h), który zawiera deklaracje wszystkich funkcji udostępnionych użytkownikowi przez autora komponentu. Drugi (*.c) zawiera implementacje tych funkcji. Dokładnie tak wygląda to w przypadku gotowych komponentów bibliotecznych (vide katalog Generated Source w zakładce nawigacji po składowych projektu), więc i my będziemy się trzymali tej konwencji. Jest to jednak tylko konwencja, więc jeżeli Czytelnikowi odpowiada zupełnie inny projekt struktury logicznej plików API, to PSoC Creator nie narzuca tu żadnych istotnych ograniczeń.

No to do dzieła!

Z bieżącego Source wracamy do widoku Components nawigatora projektów i po zaznaczeniu EDW555_v1_0 z prawego menu wybieramy Add Component Item. Z listy wybieramy API→ API Header File, zmieniamy mu nazwę z mało czytelnego header01.h na EDW555.h i klikamy Create New. Pojawił się plik, który należy następnie wypełnić treścią. API naszego timera jest skrajnie proste i składa się z tylko jednej funkcji, której zadaniem jest uruchomienie wszystkich składowych komponentu – dokładnie tak, jak w odcinku marcowym. Nazwijmy ją więc EDW555Start(). Z powodów technicznych warto też zabezpieczyć plik nagłówkowy przed wielokrotnym włączeniem, dodając linijkę #pragma once. Treść całego pliku składa się z dwóch linijek, więc wyjątkowo przytoczę ją poniżej:

#pragma once
void EDW555Start();

Ponownie przeprowadzamy kompilację projektu i (nie przejmując się chwilowo błędami) widzimy, że w katalogu Generated Source pojawił się katalog o nazwie Timer, która odpowiada nazwie egzemplarza komponentu na schemacie, a w nim automatycznie wygenerowany plik Timer_EDW555.h o treści identycznej z powyższym nagłówkiem. Widzimy więc, że dla każdego egzemplarza komponentu PSoC Creator automatycznie generuje pliki API o nazwie NazwaEgzemplarza_NazwaPlikuAPI. Tak naprawdę nasz oryginalny plik EDW555.h nie jest więc nagłówkiem, lecz szablonem nagłówka!

Jest to bardzo istotna informacja, bo szablony mogą być parametryzowalne i plik wynikowy nie zawsze będzie prostą kopią szablonu. Omówimy to dokładniej w następnym odcinku, teraz jednak doprowadźmy nasz projekt do kompilowalności. Z pliku main.c wycinamy fragment odpowiedzialny za inicjalizację składowych komponentu (przyda się za chwilę) i zastępujemy go prostym wywołaniem funkcji EDW555Start(). Teraz to komponent ma wiedzieć, jak się poprawnie uruchomić; użytkownik tylko czytelnie wskazuje intencje, wybierając właściwą funkcję.

Ponowna kompilacja kończy się błędem Undefined reference to ‘EDW555Start’, zgłoszonym przez linker. Istotnie, jak dotąd jedynie zapowiedzieliśmy kompilatorowi istnienie takiej funkcji gdzieś w projekcie, ale jej nie zaimplementowaliśmy.

Czas naprawić ten brak: Add Component Item, ale tym razem wybieramy API C File, nadajemy plikowi nazwę EDW555.c i wypełniamy treścią. Implementacja powinna wiedzieć o deklaracjach, więc plik zaczniemy od linijki

#include „EDW555.h”

Kompilacja ujawni jednak, że takiego pliku nie ma, choć przecież dopiero go utworzyliśmy! Jest tak dlatego, że do kompilacji są brane wyłącznie wyniki parametryzacji szablonu pliku (tj. Timer_EDW555.h), a nie same szablony. Ale... przecież to bez sensu, bo skąd autor komponentu ma wiedzieć, jaką nazwę egzemplarzowi komponentu nada użytkownik?!

Słuszne spostrzeżenie!

Otóż… nie wie tego użytkownik, ale PSoC Creator już tak. Nazwa ta jest zawarta w parametrze `$INSTANCE_NAME`, którego można użyć w szablonach plików API, zamiast samodzielnie podawać nazwę egzemplarza. PSoC Creator automatycznie zastąpi każde wystąpienie tego parametru w pliku wejściowym właściwą w danym kontekście nazwą egzemplarza komponentu. Jeśli więc napiszemy

#include „`$INSTANCE_ NAME`_EDW555.h”

to po tłumaczeniu otrzymamy właśnie potrzebną nam linijkę

#include „Timer_ EDW555.h”

Można się o tym przekonać poprzez uruchomienie kompilacji i lekturę treści wygenerowanego pliku Timer_EDW555.c.

Rozwiązanie już mamy, ale musimy zastosować je w kilku różnych miejscach. Pierwsze już poprawiliśmy powyżej, korygując nazwę włączanego nagłówka. Drugie to nazwy komponentów użytych do zbudowania naszego timera (tj. komparatory i przetworniki DAC). Podczas tworzenia schematu komponentu nie zmieniliśmy im nazw i dalej mamy np. komparator Comp_1.

Ale to już nie jest ten sam komparator, co w odcinku marcowym! Wtedy w strukturze projektu mieliśmy odwzorowanie jeden do jednego pomiędzy nazwą komponentu na schemacie a blokiem sprzętowym w strukturze procesora. Teraz jednak budujemy komponent z myślą o potencjalnym wielokrotnym jego użyciu w projekcie. Gdyby utrzymać poprzednią konwencję i na schemacie umieścić dwa egzemplarze timera EDW555, z których każdy zawiera komparator Comp_1, to do którego egzemplarza Comp_1 będziemy odnosić się w szablonach API?

Komparatora właściwego dla danego egzemplarza timera, czy też może jakiegoś wspólnego, co oznaczałoby katastrofę? Nas interesuje pierwszy wariant i problem znów rozwiązujemy parametrem `$INSTANCE_NAME`. Spójrzmy uważniej na katalog z automatycznie wygenerowanymi plikami projektu. Nie ma w nim już katalogu Comp_1, jest za to Timer_Comp_1. A więc to tak, PSoC Creator automatycznie prefiksuje nazwy komponentów składowych nazwą komponentu je zawierającego...

U nas są tylko dwa poziomy zagnieżdżenia, ale gdyby było ich więcej, to schemat generowania nazw by się odpowiednią liczbę razy powtórzył – zasada jest czytelna. Z tego właśnie powodu w naszym szablonie API nie możemy wywołać Comp_1_Start(), lecz `$INSTANCE_ NAME`_Comp_1_Start().

Trzeci problem to niejawna deklaracja tej funkcji: kompilator zgłasza ostrzeżenie. To prawda, brakuje nam nagłówków API komponentów składowych. Im również nie będziemy wpisywali pełnej nazwy ręcznie, lecz

#include „`$INSTANCE_NAME`_Comp_1.h”

Czwarty, ostatni problem to opisany właśnie problem drugi, ale tym razem w odniesieniu do samego komponentu timera, a nie do jego komponentów składowych. W wyniku powyższych poprawek treść (tzw. ciało) funkcji EDW555Start() sama w sobie jest już poprawna, ale problem jest z nazwą. No tak, gdybyśmy użyli większej liczby egzemplarzy timera, to PSoC Creator dostarczy wielu jej definicji i projekt się nie skompiluje. Powód jest oczywisty, nazwa funkcji nie zależy od nazwy egzemplarza. Poprawka jest trywialna: zmieniamy jej nazwę na `$INSTANCE_ NAME`_Start(), choć pamiętamy, by zrobić to w dwóch miejscach: w pliku EDW555.h oraz EDW555.c. Nasz plik API finalnie wygląda więc tak:

#include „`$INSTANCE_NAME`_EDW555.h”
#include „`$INSTANCE_NAME`_VDAC8_1.h”
#include „`$INSTANCE_NAME`_VDAC8_2.h”
#include „`$INSTANCE_NAME`_Comp_1.h”
#include „`$INSTANCE_NAME`_Comp_2.h”
void `$INSTANCE_NAME`_Start() {
`$INSTANCE_NAME`_VDAC8_1_Start();
`$INSTANCE_NAME`_VDAC8_2_Start();
`$INSTANCE_NAME`_Comp_1_Start();
`$INSTANCE_NAME`_Comp_2_Start();
}

W pliku main.c wystarczy wywołać już tylko Timer_Start() i wszystkie składowe komponentu Timer uruchomią się automatycznie. Jesteśmy w pełni zgodni z konwencją stosowaną w komponentach bibliotecznych, a nasz element nie odróżnia się od nich w projekcie. Mamy nowy, w pełni funkcjonalny i spójny z resztą klocek. Czas więc po raz ostatni skompilować projekt i zaprogramować płytkę. Jak można się przekonać na oscylogramie (rysunek 11), układ działa poprawnie.

Rys.11 Oscylogram

Uff! Opisana właśnie procedura wydaje się zawiła i skomplikowana, ale wrażenie to wynika jedynie ze szczegółowości opisu tworzenia komponentu. Po nabraniu niewielkiej nawet wprawy dodawanie nowych komponentów okazuje się procesem bardzo szybkim i intuicyjnym, warto więc nieco poćwiczyć.

Osiągnęliśmy dziś bardzo ważny etap: z biernych użytkowników bibliotecznych gotowców stając się twórcami! To naprawdę ogromny sukces! Jednak daleko nam jeszcze do pełnego wykorzystania potencjału tkwiącego w modularyzacji, więc w kolejnym odcinku omówimy szczegółowo następne bardzo silne narzędzie – parametryzację komponentów.

Uzbrojeni w tę wiedzę wrócimy do poznawania kolejnych tajników sprzętowych układów 5LP. Gdyby jednak Czytelnik chciał wyprzedzić plan niniejszego cyklu i samodzielnie zgłębić tematykę komponentów na poziomie zaawansowanym, to oprócz projektu demonstracyjnego w materiałach na Elportalu umieściłem PSoC_Creator_Component_Author_ Guide.pdf.