Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Curiosity nano jako pomoc w debuggowaniu projektów sprzętowych

tmf 06 Jan 2022 22:33 771 6
Altium Designer Computer Controls
  • Tym razem nieco nietypowo – chciałbym wam pokazać w postaci wideoporadnika prosty trik, który może ułatwić debugowanie układów cyfrowych.
    Obecnie mamy do dyspozycji rozbudowane symulatory układów, dzięki którym zanim je zbudujemy możemy je dosyć dobrze przetestować. Jednak ciągle układy cyfrowe potrafią sprawiać problemy, nie tylko na skutek wadliwego projektu, ale także błędów związanych z montażem. Wyszukiwanie tego typu problemów bywa trudne, szczególnie, jeśli musimy wymusić w tym celu odpowiednie stany wielu różnych sygnałów cyfrowych lub sygnały te muszą pojawić się w określonej sekwencji. Tu z pomocą mogą przyjść płytki deweloperskie, takie jak np. Curiosity nano oraz zintegrowane środowiska programistyczne, dzięki którym możemy nasze płytki zamienić w programowalne wielopinowe układy IO, które wprost idealnie będą się nadawały do debugowania sprzętu. Tu szczególnie fajnie wypada Curiosity nano ze względu na:
    - relatywnie dobrą cenę,
    - darmowe, dobre IDE, w którym można wykorzystać jego potencjał,
    - dużą liczbę pinów IO,
    - obecny na płytce programowalny regulator napięcia o zakresie 1,6-5,5V.
    Szczególnie ta ostatnia cecha jest niezwykle pożądana, gdyż możemy debuggować sprzęt cyfrowy zasilany z szerokiego zakresu napięć. Więcej znajdziecie w wideoporadniku:

    Zapraszam do komentowania i podzielenia się własnymi pomysłami – jak rozwiązujecie problemy sprzętowe w budowanych przez was układach cyfrowych?

    Cool? Ranking DIY
    About Author
    tmf
    Moderator of Microcontroller designs
    Offline 
  • Altium Designer Computer Controls
  • #2
    maniek1818
    Level 22  
    Cześć.
    Układy cyfrowe buduję wyłącznie na uC w oparciu o wiedzę, zawartą w książkach od Ciebie :D
    Do debugowania wystarcza mi 8 liniowy Saleae, a czasem jak coś uruchamiam nowego to nawet jedna dioda LED załatwia sprawę.
    Do rzeczy. Posiadam płytkę Curiosity z Tiny3217. Ma mniej linii I/O, ale bardzo spodobała mi się Twoja idea użycia tej płytki. Debugger projektów sprzętowych z możliwością pisania własnych funkcji w znanym wszystkim języku C.
    Jaka jest wydajność zasilania takiego Curiosity? Może da radę bezpośrednio z tej płytki zasilać proste projekty, co zmniejszy ryzyko usmażenia.
  • Altium Designer Computer Controls
  • #3
    tmf
    Moderator of Microcontroller designs
    maniek1818 wrote:
    aka jest wydajność zasilania takiego Curiosity? Może da radę bezpośrednio z tej płytki zasilać proste projekty, co zmniejszy ryzyko usmażenia.

    Niestety niewielka. Regulator wg noty daje 500 mA, ale... to ile rzeczywiście możesz pobrać zależy od napięcia wyjściowego. Ponieważ jest to regulator LDO, więc jeśli na wyjściu dasz 4-5V to nie będzie problemu - całe 500 mA weźmiesz, ale dla 1,8V ograniczeniem będzie moc wydzielana w układzie. Na szczęście nie ma ryzyka uszkodzenia - regulator ma zabezpieczenie termiczne.
  • #4
    spec220
    Level 24  
    Witam.
    Faktycznie w ostatnim czasie powstało sporo uproszczeń w zakresie projektowania logiki z zakresu CMOS. Zarówno analizatory stanów logicznych poszczególnych kości US, jak również same środowiska programistyczne które umożliwiają programowanie "kości" metodą graficzną kompilując schemat logiczny na kod. Ma to oczywiście swoje ograniczenia, ale dla ludzi starej daty takich jak ja nie ukrywam iż jest to spore uproszczenie, bo nie trzeba niczego pisać. O ile opracowanie samej logiki działania układu nie jest aż takie trudne do zrobienia na schemacie logicznym tzw. bramkach, to o wiele trudniej jest ową logikę przedstawić za pomocą kodu...

    Osobiście (za młodych lat) też sporo rzeczy robiłem na tzw. bramkach, licznikach, przerzutnikach itp. Z tym że "jechało" się na żywca. I nie mówię tu o jakimś błędzie w zasilaniu czy zwarciu, co by uwaliło US, tylko czystym błędzie logicznym który mógłby spowodować nieprawidłowe działanie układu. Dlatego też zanim coś się przetestowało/ zrobiło prototyp trzeba było dobrze przeanalizować sam projekt na kartce papieru, zwłaszcza w przypadku kiedy człowiek nie posługiwał się pomocnymi symulatorami na PC...
    Tutaj prosty przykład. Nie ma tu niczego skomplikowanego, ale i tu jest wiele miejsc w których można było popełnić błąd... O ile procesor można kompilować X razy aż się osiągnie pożądany efekt, tak w przypadku pojedynczych kości błąd wiąże się to z hardwarową modyfikacją układu.
    Curiosity nano jako pomoc w debuggowaniu projektów sprzętowych
    Curiosity nano jako pomoc w debuggowaniu projektów sprzętowych
  • #5
    tmf
    Moderator of Microcontroller designs
    spec220 wrote:
    Osobiście (za młodych lat) też sporo rzeczy robiłem na tzw. bramkach, licznikach, przerzutnikach itp. Z tym że "jechało" się na żywca. I nie mówię tu o jakimś błędzie w zasilaniu czy zwarciu, co by uwaliło US, tylko czystym błędzie logicznym który mógłby spowodować nieprawidłowe działanie układu.

    Ja popełniam co najmniej dwa typy błędów:
    1. Bład logiczny w schemacie.
    2. Błąd wykonania - złe połączenia, brak styku, coś nieprzylutowane.
    W obu przypadkach sprawdza się podejście, które zaprezentowałem. Można doprowadzić układ do określonego stanu i sprawdzić czy wynik pokrywa się z oczekiwaniami. Z użyciem MCU jest to proste, bo mamy kilkadziesiąt sterowalnych pinów IO - łatwiej nimi sterować z IDE niż przekładać kabelki na stykówce. Można też wygenerować automatyczne testy, dla bardziej skomplikowanych sytuacji - mniej więcej coś w stylu gotowych funkcji jakie są w drugiej części filmiku.
    Przygaje się to nie tylko dla starych układów, gdzie mamy dużo prostych chipów, ale także dla nowoczesnych, gdzie jest jakieś glue logic. Oczywiście jeśli mamy MCU na pokładzie, to można go wykorzystać w trybie debugowania właśnie do debugowania hardware. W praktyce np. macham w IDE pinem i sprawdzam, czy określony stan pojawia się na właściwych nogach układów docelowych. Wiele razy umożliwiło mi to np. szybkie znalezienie źle przylutowanego pinu, lub zwarcie przez mostek cynowy dwóch pinów.
  • #6
    spec220
    Level 24  
    Artykuł jest fajny, a samo urządzenie przydatne przynajmniej w przypadku sprawdzenia określonych stanów logicznych, no ale co kiedy trzeba wymusić określony algorytm? czy zasymulować działanie danej kości? Zapewne trzeba napisać kawałek kodu, a z tym już bym nie dał rady... Osobiście łatwiej wziąć mi "kawałek" ATmegi narysować graficznie wymagany "brakujący" fragment logiki oraz "wstrzyknąć" dane w określone miejsce. Z programowalnego mikrokontrolera metodą graficzną mogę zrobić tzw. zastępczą kość CMOS i oprócz monitorowania stanów logicznych symulować cały fragment układu.
    Ograniczenia wynikają jedynie z timerów oraz szybkości działania, no ale kto powiedział, że w trakcie symulacji układ musi pracować z bazową częstotliwością? Ważne aby stany logiczne były ok.

    Tak swoją drogą, to szkoda że takich gadżetów nie było w tamtych czasach. Zapewne sporo ułatwiłyby życie. Jak dla mnie wystarczyłby chociażby symulator PC stanów logicznych, bo błąd w połączeniu zawsze można popełnić. Nawet na wstępnym etapie projektowania PCB, przez co czasem się zdąża, że trzeba "coś tam rzeźbić" w druku o ile błąd nie jest aż tak bardzo kardynalny... :) (mowa o prototypie)
  • #7
    fotomh-s
    Level 23  
    Ja się kiedyś bawiłem rozwiązaniem zwanym SignalTap. Jest to narzędzie od Altera/Intel które umożliwia zastosowanie FPGA jako analizatora stanów logicznych. Można zarówno sprawdzać sygnały wewnątrz FPGA (jeśli mamy tak jakąś konfigurację wgraną) jak i z zewnątrz z pinów IO. Działa poprzez interface JTAG. Wadą jest niestety ograniczona pamięć block RAM tanich układów FPGA, do tego spore zużycie LE. To oznacza że raczej odpada podsłuchiwanie jakichś większych projektów (które już zajmują sporo LE albo pamięci block RAM). FPGA także mogą stosować debugging pinów przez JTAG (tak zwany boundary scan), chociaż akurat nie potrafiłem znaleźć informacji jak to uruchomić na EP2C5T144 (ponoć Quartus sam w sobie boundary scana nie obsługuje i potrzebne jakieś zewnętrzne narzędzia). Co ciekawe FPGA posiadają konfigurowalne napięcia pracy bloków IO, gdzie każdy blok może mieć przypisany inny standard. Do wyboru niestety nie ma 5V TTL, bo współczesne układy FPGA mają IO działające <= 3.3V. Są jednak i rzeczy takie jak np. LVDS, czyli wbudowana sprzętowa obsługa sygnałów różnicowych. Można także sobie np. zsyntezować jakieś peryferia np. do podsłuchiwania UART/I2C/SPI/CAN/jakiegoś standardu o którym świat nie słyszał ;-)