7. Podsumowanie

7. Podsumowanie

 

7.1. Zrealizowane cele

 
Zaadoptowano niezbędne moduły do obsługi przetwarzania A/C oraz C/A (w tym do obsługi pamięci układów FPGA), zaadoptowano moduły kontrolujące interfejsy I2C, RS oraz GPIB, zaadoptowano moduł RS oraz wykonano moduł USB kontrolujące system.

Powyżej opisane moduły połączono w system o konfiguracji master-slave o magistralowej topologii połączeń, który następnie przetestowano napisaną aplikacją użytkownika. Testy wykazały iż system działa prawidłowo w większości przypadków. Przypadki kiedy cały system nie działa prawidłowo zostały opisane w podrozdziale 7.4.2.

 

7.2. Możliwości wykorzystania

 
Stworzona aplikacja użytkownika w ramach zaimplementowanych funkcji pozwala na:
  • badanie wpływu parametrów sygnału zegarowego taktującego przetworniki na otrzymywane wartości próbek sygnału w przypadku akwizycji oraz na wytwarzane sygnały w przypadku generacji sygnału,
  • zarówno sterowanie urządzeniami dołączonymi do interfejsu GPIB jak i tworzenie zaawansowanych procedur pomiarowych,
  • zarówno konfigurowanie urządzeń przy wykorzystaniu interfejsu RS232C jak i wykorzystanie tego interfejsu jako komunikator lub do przesyłania niedużych plików, • konfigurowanie urządzeń przy wykorzystaniu interfejsu I2C, który nie jest zazwyczaj dostępnym interfejsem w komputerach PC,
  • wykorzystanie aplikacji podobnie jak popularnych programów "HyperTerminal" czy "Terminal v1.9" dzięki zaimplementowanej funkcjonalności debugingu.

Zaimplementowane funkcje mogą zostać wykorzystane w zarówno jako pomoc dydaktyczna jak i również mogą okazać się pomocne w do celów prototypowania innych urządzeń.

Pierwszym wykorzystaniem opracowanych w niniejszej pracy funkcjonalności było użycie interfejsu I2C, w celach testowania zaimplementowanego kodu na ATmega8-16U, realizującego Glue-Logic pomiędzy interfejsem I2C a SPI.

Projekt ten wykonywany był na łamach zadania o tytule Projekt Stabilizowanego Zasilacza na Wysokie Napięcie w którym uczestniczyli: Schodowski Łukasz, Radosław Rybaniec, Tomasz Janicki.

 

7.3. Możliwości dalszego rozwoju

 
Wykonane prace pozwoliły na głębsze przemyślenie zrealizowanego systemu pomiarowego, co pozwala na zaproponowanie pewnych rozwiązań przyszłym edytorom niniejszego systemu pomiarowego. Propozycje zostały wypunktowane poniżej:
  1. Wykorzystanie interfejsów szeregowych jest dostatecznym rozwiązaniem w przypadku wolnych transmisji takich jak konfiguracja, gdyż typowo nie istnieje potrzeba częstej rekonfiguracji urządzeń. Problemem jest natomiast transmisja dużych bloków danych zarówno pomiędzy PC a UMC, ale i także pomiędzy DAC i DIC.

    Przypadkiem dłuższej transmisji danych pomiędzy DAC i DIC byłoby: przesłanie zawartości pamięci z przetwornika analogowo-cyfrowego, odpowiednie przetworzenie tych danych, a następnie przesłanie ich dalej do kontrolera GPIB.

    Propozycją rozwiązującą taki problem jest stworzenie prostego kontrolera na płycie UMC, któremu kontroler szeregowy (rs_syscon lub VCusb) oddawałby sterowanie na czas pełnego przesyłu bloku danych, z pamięci przypisanej przetwornikom do kontrolera GPIB. Przy takim rozwiązaniu transmisja zachodziłaby z maksymalną możliwą szybkosćią określoną przez zegar na płycie UMC.

    W przypadku transmisji dużej ilości danych pomiędzy PC a UMC takiej jak: przesłanie sygnału wcześniej zapisanego w pliku - nie jest efektywne stosowanie interfejsów szeregowych (nawet tak szybkich jak USB).

    Propozycją rozwiązującą ten problem byłoby stworzenie jednego z dwóch kontrolerów: kontrolera Ethernet albo kontrolera VME/VXI. Pierwsze rozwiązanie dawałoby dodatkowo możliwość komunikacji z UMC poprzez internet, natomiast drugie dawałoby możliwość wykorzystania programów takich jak LAbView do tworzenia interfejsu użytkownika.

    Oba rozwiązania dają znacznie większą przepustowość niż interfejsy szeregowe i być może dzięki nim dawałoby się stworzyć system pomiarowy przetwarzający dane nawet w czasie rzeczywistym.

  2. Wykorzystanie biblioteki WinApi pomimo prostego wykorzystania posiada znaczącą wadę – nie przenosńość na inne systemy operacyjne. Jedyną możliwosćią uruchomienia aplikacji pod innymi systemami operacyjnymi jest emulacja taką jak w przypadku systemu Linux daje program Wine. Rozwiązanie to jednak nie gwarantuje prawidłowosći funkcjonowania aplikacji.
    Jedynym rozwiązaniem jest przepisanie aplikacji z wykorzystaniem innych bibliotek takich jak popularne WxWidgets.

7.4. Niezrealizowane dodatki, znane Bugi i troubleshooting

 

7.4.1. Niezrealizowane dodatki

 
  • System posiada możliwość (mechaniczną, elektryczną) do komunikacji protokołem PCI [4], który mógłby zostać użyty zamiast Wishbone, co podniosłoby rangę zaproponowanych rozwiązań do rangi standardowych, co umożliwiłoby stosowanie płyt DIC oraz DAC wszędzie tam, gdzie istnieje interfejs PMC. Niestety z powodów wadliwych połączeń nie udało się przetestować takiej komunikacji.
  • Z racji ograniczonych zasobów układów FPGA, a w tym pamięci RAM, zostały przypisane pewne skończone bloki pamięci do przetworników C/A oraz A/C na płycie DAC. Pomysłem było skonstruować dodatkowe moduły sprzętowe, które średnio-zaawansowany użytkownik mógłby dobrać (przy tworzeniu projektu systemu) i niniejszym w ten sposób zmieniać pojemność pamięci dla poszczególnych przetworników. Niestety nie zostało to wykonane. Aby zmieniać pojemności przypisanej pamięci należy ręcznie w projekcie sprzętowym oraz w aplikacji użytkownika zmienić odpowiadające im wartosći oraz przekompilować oba projekty zwracając na uwagi kompilatora.

7.4.2. Znane Bugi i troubleshooting

 
 
  • Podczas wyłączania aplikacji lub odłączania portu COM, gdy wczesńiej próbowano dokonać transmisji na portach COM w przypadku komunikacji przez interfejs którego moduł kontrolera systemu nie jest wgrany na FPGA płyty UMC, to aplikacja ma wysokie prawdopodobieństwo zawiesić się w oczekiwaniu na zakończenie transakcji po porcie COM, której w rzeczywistości nie było:

    "A small caveat: closing the last handle to a file object counts as a synchronous I/O operation, and it will synchronize with other synchronous I/O operations if the file wasn’t opened with FILE_FLAG_OVERLAPPED. Closing the last handle to a pipe, socket or other device that’s being currently used in a synchronous I/O operation will block until the operation completes. This is due to a small design oversight in the Windows I/O subsystem: the synchronous I/O lock of a file object isn’t dropped before entering the wait for the operation’s completion, causing the nesting of two locks and the potential for deadlocks. In Windows Vista and later, CancelSynchronousIo can be used to interrupt and cancel stuck I/O operations" --  Zródło MSDN

    Aby ominąć powyższy problem należy, jeżeli wystąpi to zrestartować komputer (zabicię procesu nic nie daje!) albo uważnie konfigurować połączenie portu COM w pierwszej fazie konfiguracji systemu poprzez aplikację użytkownika.

 
  • Podczas włączania oscyloskopu, gdy jest on podłączony do interfejsu GPIB a do układu FPGA na płycie DIC nie został wgrany jeszcze strumień konfiguracyjny, to zauważono częstą niepoprawną inicjalizację oscyloskopu TDS7404B, co powoduję iż należy z restartować oscyloskop. Czynność wykonywać aż do skutku. W przypadku wcześniej wgranej konfiguracji do układu FPGA na płycie DIC nie zauważono takiego zachowania.
 
  • Podczas przełączania zegara (zakładka konfiguracji AD9512) z CLK2 na MAX9452, gdy wczesńiej CLK2 był włączony, lub podczas przełączenia z MAX9452 na CLK2, gdy wczesńiej MAX9452 był włączony, to pamięć przypisana przetwornikom może ulec przypadkowym zmianom, co całkowicie dyskwalifikuje wcześniejsze zgromadzone w niej informacje. Aby temu zapobiec należy wczesńiej wyłączyć aktywny zegar, następnie dokonać zmiany na nieaktywny pożądany sygnał zegarowy i ostatecznie włączyć go.