Programatory JTAG

Szkoda, że się nie ustosunkowales do pytań innych użytkowników z wątku o Raspi i karcie sd... :(

Hmm... Na twoją wiadomość odpowiedziałem w chwilę po zadaniu powyższego pytania. Poza tym coś mi umknęło? Bo w wątku widziałem kilka sugestii: zastosowanie starszego terminalu na x86, kadłubka laptopa albo bootowanie RasPi z USB. Rozwiązania z laptopem jednak wolałbym uniknąć ze względu na pobór prądu. Zastanawiam się czy nie pójść faktycznie w kierunku podpięciu do Maliny dysku SSD przez USB.

Bardzo ciekawe pytanie.

Teoretycznie, taka jest idea JTAG-a.

Moim zdaniem jest tak że software programujący od różnych producentów fpga/cpu będzie akceptował inne urządzenia w łańcuchu ale będzie wymagał dedykowanego programatora od każdego producenta.

Są firmy trzecie dostarczające swoje rozwiązania JTAG, ale czy poza skanowaniem ścieżki brzegowej potrafią coś więcej ? Nie wiem. Tutaj pewnie pytanie do firm takich jak xjtag.com bo to kwestia wbudowania algorytmów programujących. Nie wiem czy X i A byli skłonni się podzielić.

Tym bardziej że w części przypadków jest to programowanie pośrednie.

Jeśli chodzi wyłącznie o programowanie w czasie produkcji to poszedłbym jeszcze w inną stronę i każdy z jtagów podłączył do portu IO jakiegoś innego już istniejącego w projekcie procesora/mikrokontrolera bo producenci fpga , jak mi się mocno kojarzy, udostępniają źródła w C prostego programatora po jtag do zastosowań embedded. Altera/Intel na pewno a Xilinx jak dobrze pamiętam chyba też.

Pozdrawiam

Adam Górski

W dniu 02.07.2020 o 19:48, Adam Górski pisze:

W przypadku Xilinxa można przekonwertować wsad do postaci pliku binarnego, który programuje się dowolnym, programatorem obsługiwanym przez OpenOCD. Może inne fpga też tak mają.

Wydaje mi sie ze wiekszosc "malych" mikrokontrolerow nie na prawdziwego JTAG-a. Np. SWD logicznie dziala podobnie do JTAG-a, ale _nie_ ma mozliwosci laczenia "daisy chain". O ile pamietam jedyna standartowa funkcja JTAG-a jest "boundary scan", myslalem o tym zeby sie tym pobawic, ale te mikrokontrolery ktore ogladalem nie implementuja "boundary scan"...

Czyli pozostaja niestandartowe funkcje producenta. W przypadku ARM-ow dosc istotna czesc jest standartowa: interfejs pozwala "przechwycic" szyne SOC-a i debuguje sie przez podlaczone do niej uklady. Niestety, producenci robia ze szczegolow tajemnice (o ile wiem pelna dokumentacja jest dostepna tylko jak sie podpisze NDA (czyli wiazaca obietnice ze sie nie powie innym)). W praktyce, przez ST-linka (ktory teoretycznie jest tylko do procesorow ST) udalo mi sie dostac troche danych z LPC. Ale akurat procedury programowania sa inne. Tzn. kazdy producent ma swoj interfejs od flashowania.

Jest zrozumiale ze np. ST nie chce by ich programatory uzywac do programowania ukladow konkurencji (i podobnie inni producenci). Sa tez programatory uniwersalne, np. openocd, ale to raczej od niezaleznych dostawcow...

Sprzętowo JTAG sprowadza się do czterech linii komunikacyjnych i nie ma w nich nic szczególnie czarnomagicznego co wymagałoby programatora tego czy tamtego producenta. Np. w tym projekcie:

(strona „nieoficjalna” jeszcze) używamy najzwyklejszego złącza USB, za którym stoi popularny układ FTDI sterujący liniami JTAG.[*] O czym trzeba pamiętać przy większej liczbie układów to aby linie miały odpowiednio zabezpieczone poziomy (pull-up/push-down aka pull-down) gdyż nie wszyscy producenci wbudowują rezystory wewnątrz układów. To trzeba wyczytać w specyfikacjach używancyh układów. Tyle po stronie sprzętowej. Znaczące różnice pojawiają się natomiast w implementacjach protokołu używanego do programowania układów. Niemniej za to odpowiedzialne jest oprogramowanie generujące pliki wynikowe.

Nie bardzo też rozumiem jak chciałbyś programować ileś układów „jednocześnie”. Teoretycznie jestem sobie w stanie wyobrazić taką możliwość poprzez odpowiednie zmultipleksowanie różnych strumieni ale praktycznie nie byłoby to ani trywialne ani dodające wartości.

• - trudno wymagać od każdego nabywcy aby w razie potrzeby uaktualnienia logiki naszego urządzenia kupował programator, instalował kobylaste oprogramowanie producenta/ów układu/ów, męczył się z konfiguracją, uruchomieniem, itd.

Może nie traktuj pojęcia "jednocześnie" tak dosłownie. Ja np. mam na płycie 8 procków z identycznym firmware'm. Żeby nie wyprowadzać pinów JTAG na 8 złącz i nie przełączać programatora między tymi złączami, połączyłem procki w "daisy chain": jest tylko 1 złącze do programowania. Programator podłączam tylko raz, a firmware wysyłam 8 razy, wskazując programatorowi (w opcjach) na który procek to ma iść. Pojęcie "jednocześnie" rozumiałbym więc jako: "korzystając z 1 gniazda do programowania i z 1 programatora". Obawiam się, że realizacja tego przy połączeniu w "daisy chain" podzespołów rożnych producentów będzie bardzo trudna - może wręcz nierealna.

Prawdopodobnie tak ale próbuję się upewnić co poeta miał na myśli ;-)

Jeżeli mówimy o „jednym programatorze” i oprogramowaniu do sterowania tymże pochodzącym od konkretnego producenta to nie widzę dużych szans. Małych zresztą też ;-) Jeżeli nie z innych to przynajmniej z tego powodu, że takie oprogramowanie stwierdzi „brak [swojego] programatora” kiedy będzie podłączony inny. Być może dałoby się to zrealizować przy użyciu jakiegoś wolnego oprogramowania, ale nie mam praktycznych doświadczeń.