Dotychczas skupialiśmy naszą uwagę na aspektach związanych głównie z obsługa i tworzeniem obrazu – czy to biblioteka graficzna, czy widgety, czy wreszcie całe okna. Dlatego dziś warto po raz pierwszy zająć się tematem dźwięku ,który wbrew pozorom jest równie istotnym medium co obraz 🙂

Idealnym rozwiązaniem byłoby oczywiście wykorzystanie wbudowanego w nasz mikrokontroler przetwornika C/A (DAC) i wysterowanie poprzez wzmacniacz jakiegoś niewielkiego głośniczka. Pozwoliłoby to na odtwarzanie prostych, zmodulowanych tonów czy nawet odgrywanie krótkich plików WAV z karty SD. Wymaga ono jednak znacznego nakładu pracy, nie będąc przy tym niezbędną/krytyczną dla projektu funkcjonalnością.

Z tego powodu zdecydowałem się na rozwiązanie o wiele prostsze – zwykły brzęczyk z wbudowanym generatorem. Nie daje nam co prawda takich możliwości, ale i nie wymaga też wyrafinowanego sterowania – wystarczy jeden pin GPIO 🙂 W ten sposób mamy więcej czasu na zajęcie się lepiej stroną interfejsu.

Co może być takiego skompilowanego w pikaniu głośniczkiem?

Nic, o ile nie mielibyśmy żadnych planów co do rozbudowy i pozostali na etapie prostego brzęczyka. Wówczas faktycznie moglibyśmy ograniczyć cały interfejs do jednej – dwóch funkcji lub nawet w całości delegować sterowanie na stronę aplikacji… Ale nie tym razem! Ponieważ chcemy w przyszłości użyć innej metody generowania dźwięku, musimy zastanowić się jak stworzyć interfejs na tyle abstrakcyjny, aby nie wymagał później modyfikacji.

Aha… Znów szykuje się podział na warstwy?

Zdecydowanie tak 🙂 Niejednokrotnie zdążyliśmy się już przekonać o tym, że takie podejście ułatwia pracę. Tym razem zamiast zaczynać od strony sprzętu, spróbujemy rozpocząć pracę od zaprojektowania interfejsu dla aplikacji. Wymagania można zawrzeć w formie krótkiej listy:

• dźwięki klawiszy,
• dźwięk powiadomienia (mniej ważne komunikaty),
• dźwięk ostrzeżenia,
• dźwięk alarmowy (awaria, istotne komunikaty),
• dźwięk powitalny / pożegnalny,
• dźwięki GUI,

Określamy w ten sposób grupę dostępnych rodzajów alertów dźwiękowych. Aplikacja wysyłać będzie zatem jedynie żądanie odegrania jednego z nich do demona/usługi. Zdejmuje to strony aplikacji obowiązek bezpośredniego sterowania źródłem dźwięku. W pierwszym, uproszczonym podejściu poszczególne pozycje będą mapowały się na dłuższe, krótsze, pojedyncze lub wielokrotne piknięcia brzęczyka 🙂 W momencie wprowadzenia bardziej zaawansowanego rozwiązania będzie można je łatwo “przepiąć”, aby odgrywały np. ton o określonej częstotliwości. Nie będą przy tym wymagane żadne zmiany od strony aplikacji – one nadal będą posługiwać się tym samym zestawem dostępnych dźwięków.

Kwestii sprzętu nie ma chyba sensu szerzej omawiać – jest niezwykle prosta. Sterowanie odbywa się poprzez tranzystor NPN BC547C oraz rezystor ograniczający prąd, który wycisza nieco nieznośne piszczenie 🙁 .