Oryginalność mikrokontrolerów AVR z Chin

[marek1707]

Mówisz o metodzie programowej, czyli testach wykonywanych przez program? Tak, emulacja jest dobra jeśli program nie jest w stanie tego odróżnić, ale pytanie było chyba inne. Jak odróżnić AVR dobry od złego. Złego czyli mającego za mało pamięci lub brakujące niektóre peryferia.

O emulacji jądra AVR nie ma sensu rozmawiać. To byłoby nieopłacalne pod każdym względem. Zrobienie tego na jakimś większym układzie wymagałoby użycia wielokrotnie szybszego zegara, a więc nowszej technologii. Ucierpiałaby energetyka takiego projektu i bardzo trudno byłoby utrzymać pobory mocy na niezmienionym poziomie (w stosunku do oryginału) we wszystkich trybach pracy. Nie wiem skąd ten pomysł.

Gdybym miał robić własnego AVRa, wziąłbym gotowe jądro z opencores, obudował kilkoma prostymi peryferiami (zrobionymi samodzielnie lub wziętymi z tego samego źródła), wrzucił wszystko do syntezera, dodał standardową matrycę RAM, zamiast dużego i drogiego FLASHa wstawiłbym ROM, wygenerował maski z jakimś przykładowym programem i zamówił wersje próbne chipów. A potem zajął się akcją reklamową:

"Sprzedajemy procesory zgodne z AVR, ale 3 razy tańsze. Nie mają wszystkich tych niepotrzebnych w masowej produkcji rzeczy (FLASH, ISP), pobierają mniej prądu i są 2 razy szybsze. Zamówienia od 10 tys sztuk wraz żądaną zawartością ROMu proszę przysyłać na adres.."

Myślę, że szybko bym znalazł chętnych.

A od strony JTAGa widzisz scalak taki jaki jest naprawdę więc jeśli masz ARMa emulującego coś, to widzisz jądro ARM plus peryferia. Tam się nic oszukać nie da.

[nse]

"Chodzi Ci o poprawność działania tych zasobów, czy wręcz test samej obecności? "

Na początek test czy naprawdę mamy do dyspozycji deklarowane 2K SRAM, to proste do zrobienia dla studenta ślęczącego nad pracą podobną do tu omawianej ..., a przy okazji tego tematu zachęcić do wgłębienia się w "fizykę" procesorów ?

[marek1707]

Przyznam, że rozumiem każde słowo z osobna, ale sensu w tym co napisałeś nijak nie widzę. Mógłbyś pisać jaśniej?

[nse]

Przyznam, że rozumiem każde słowo z osobna, ale sensu w tym co napisałeś nijak nie widzę. Mógłbyś pisać jaśniej?

Możliwe że wyznaczamy różne cele dlatego się nie rozumiemy. Tobie chodzi o produkt, a mnie o edukacje zachęcającą do wgłębiania się w problem i nie ślepe podążanie po najniższej linii oporu, która nie jednokrotnie prowadzi do pułapek z których trudno się wycofać...

[marek1707]

Jeśli chcesz doprowadzić do sytuacji w której ktoś (kto??) zabierze się za pisanie testów AVRów lub innych procków po to byś spełnił jakieś swoje edukacyjne cele, to załóż nowy wątek i zaproponuj coś na początek. Np. opisz kilka różnych testów RAMu, spróbuj zrealizować taki test (ograniczonego obszaru, np. całej sterty) w C itp. Tu są sami zajęci ludzie i nikt nie będzie przed szereg wybiegał i dokładał sobie roboty.

EDIT: O żadnym produkcie nie myślę. To czcze dywagacje plus próby opisania Ci rzeczywistości w miarę zrozumiałym językiem.

[deshipu]

A od strony JTAGa widzisz scalak taki jaki jest naprawdę więc jeśli masz ARMa emulującego coś, to widzisz jądro ARM plus peryferia. Tam się nic oszukać nie da.

Oczywiście, że się da. Skąd wiesz, że ten JTAG, który masz wyprowadzony, jest prawdziwy a nie też emulowany?

[ Dodano: 21-06-2016, 14:09 ]

O emulacji jądra AVR nie ma sensu rozmawiać. To byłoby nieopłacalne pod każdym względem. Zrobienie tego na jakimś większym układzie wymagałoby użycia wielokrotnie szybszego zegara, a więc nowszej technologii. Ucierpiałaby energetyka takiego projektu i bardzo trudno byłoby utrzymać pobory mocy na niezmienionym poziomie (w stosunku do oryginału) we wszystkich trybach pracy. Nie wiem skąd ten pomysł.

Z chipami FTDI się udało -- no ale to sztucznie przedrożona stara technologia.

[nse]

"Tu są sami zajęci ludzie i nikt nie będzie przed szereg wybiegał i dokładał sobie roboty. "

Z mojej strony to też czcze dywagacje, widzę pewne zjawiska które mnie niepokoją i se gadam.

Nie chciałem nikomu dokładać roboty, ani przeszkadzać w jego pracy. Przepraszam

Przykładowo takim najprostszym testem pojemności RAM, to wpisanie jakiejś wartości przykładowo na początku i sprawdzanie czy ta wartość się nie zaczyna cyklicznie powtarzać po przewinięciu strony ..., a droga w kosmos to daleka droga można ją przebyć małymi krokami lub się zdobyć na karkołomny skok

[ Dodano: 21-06-2016, 14:25 ]

"... plus próby opisania Ci rzeczywistości w miarę zrozumiałym językiem."

Ten właśnie wysiłek u Ciebie doceniam

[marek1707]

"Skąd wiesz, że ten JTAG, który masz wyprowadzony, jest prawdziwy a nie też emulowany?"

Bo to byłby strzał w kolano. Ech, naczytałeś się internetu. JTAG służy do testowania chipu także po bondingu na ażur, po zamontowaniu w obudowie i również po przylutowaniu na PCB. Nie wiem ile wiesz o technologii produkcji układów scalonych, ale to już jest bardzo bliskie spiskowej teorii o krwiożerczej brzozie lub helu, snutej przez żałosnych dyletantów na co dzień zajmujących biciem piany (czyt: polityką). Mam nadzieję, że nikogo nie uraziłem.

A gdybym miał ograniczyć argumentację do techniki:

JTAG musi być szybki, bo czasem liczba danych które trzeba w boundary scan wepchnąć to wiele kilobitów a to tylko jeden stan testu. Takich stanów trzeba wymusić wiele tysięcy (w przypadku scalaków) jeśli nie miliony (w przypadku pakietów). Testowanie i tak jest drogie bo zautomatyzowane generatory wzorców i same testery JTAG są makabrycznie drogie, ich czas także kosztuje a koszt samego etapu testowania bezpośrednio dodaje się do ceny końcowej wyrobu. Dlatego JTAG pracuje z zegarami do kilkunastu MHz (ograniczonymi głównie problemami z propagacją szybkich sygnałów po liniach asymetrycznych) a sam scalak nie potrzebuje wtedy zegara lub dostaje go w postaci precyzyjnie generowanej liczby impulsów z testera. Żaden emulator nie mógłby w takich warunkach działać a z resztą nie miałoby to sensu, bo jest to interfejs głównie dla producenta - chipów lub gotowych pakietów. Nasze (rzadkie) wykorzystanie go przy programowaniu pamięci to 1% możliwości. Obwody testowania chipów są niezależnymi strukturami, zajmują czasem całkiem pokaźnie miejsce na krzemie i są opracowywane przez niezależnych ludzi na podstawie bardzo szczegółowych wytycznych dot. m.in. pokrycia testów. Ścieżka brzegowa przechodzi przez wiele przerzutników nie tylko otaczających jakiś blok (np. jądro ARM) odcinając go od otoczenia/reszty chipu, ale także udostępnia nam przerzutniki wewnątrz samych bloków. Możesz np. podczas zatrzymania procesora (bez zegara główego) bezpośrednio wpisać coś do rejestru odbiorczego UART i sprawdzić, czy dane dochodzą magistralą do CPU i czy nie ma ona zwarć między liniami albo wpisać coś do rejestru wyjściowego portu i sprawdzić, czy bity wychodzą na PCB przez bonding, ażur i lutowanie z jednoczesnym testowaniem parametrów elektrycznych driverów wyjściowych. To nie jest robione po to by kogokolwiek oszukać tylko po to, by nasz wyrób miał w ogóle szansę działania w docelowym miejscu.

[deshipu]

No dobra, emulowanie JTAGa zwiększa o kilka rzędów wartości stopień trudności, przyjąłem.

Ale czy taka atmega328p wogóle ma JTAG? Z tego, co wiem, to ma jakieś debugowanie przy pomocy wysokiego napięcia na nóżce reset, ale to chyba nędzna namiastka?

[nse]

@marek1707 :

Tak z czystej sympatii, na marginesie zapytam; Kiedy ostatnio po zejściu z góry poczułeś się najszczęśliwszym człowiekiem na ziemi i to tylko dlatego że mogłeś się napić zimnej wody ?

Czy coraz nowsze technologie o których możemy sobie jedynie pogadać nas uszczęśliwiają ?

Ja mam sympatie do rzeczy prostych

https://pl.wikipedia.org/wiki/Brzytwa_Ockhama

@deshipu:

[ Dodano: 21-06-2016, 15:32 ]

" Z tego, co wiem, to ma jakieś debugowanie przy pomocy wysokiego napięcia na nóżce reset, ale to chyba nędzna namiastka? "

To chyba służy do programowania równoległego, jak się coś w fusach poknoci ??

Tak dokładnie nie czytałem dokumentacji

[deshipu]

debugWIRE is designed as a simpler alternative to JTAG, aimed at processors with limited resources. It is supported by most modern 8-bit AVRs. By using debugWIRE one has full read and write access to all memory and full control over the execution flow. It supports single-step, run-to-cursor, step-out, and software break instructions. The single undocumented hardware breakpoint can be used by selecting run-to-cursor.

[ Dodano: 21-06-2016, 15:43 ]

Brzmi jak relatywnie prosta do zemulowania rzecz.

[marek1707]

nse: Irytujący jest dialog pisemny z osobą wyrażającą się bardzo niekonkretnie. Nie wiem czy nie chcesz czy nie umiesz pisać na temat. Czy Twoja sympatia do rzeczy prostych pochodzi z nieogarniania rzeczy troszkę bardziej skomplikowanych? Bo chcąc nie chcąc one istnieją, jedni je rozumieją, wymyślają, projektują i stosują w technice a inni tylko tego używają być może myśląc, że są ponad to. Robisz wrażenie jakbyś unikał głębszej dyskusji więc albo nie masz kompletnie pojęcia o tematyce niniejszego wątku (tak czuję) i usilnie starasz się ją sprowadzić na inne tory. Jeżeli chcesz przekazać coś zupełnie nie na temat, załóż swój wątek, to nie boli. Na pewno znajdą się chętni do czytania historii o komputerach z piasku czy szklankach wody.

deshipu: Odróżniaj debugowanie kodu od testowania chipu. To dwie różne rzeczy przeznaczone dla zupełnie innych ludzi. Implementacja JTAGa jest opcjonalna i zależy od polityki producenta. W skomplikowanych scalakach montowanych w dużych obudowach warto robić interfejs testujący chip i montaż, bo to się po prostu opłaca. Inne metody testowania (np. programowe) byłyby zbyt wolne, zbyt drogie i zbyt różne albo potrzebowały dużego i nietypowego wsparcia na linii produkcyjnej. JTAG to uznany standard i praktycznie każdy liczący się producent kontraktowy ma odpowiednie testery. To czy JTAG jest wyprowadzony na piny zależy od rachunku kosztów i troszkę też definiuje zakres zastosowań układu. Budując duży i skomplikowany pakiet nie wstawię tam małej ATmegi8 właśnie z tego powodu, że nie mogę jej podłączyć do ścieżki brzegowej. Muszę zrobić jej osobne złącze ISP, wyposażyć linię produkcyjną w odpowiednie stanowisko a testy otoczenia tego procesora robić programowo być może innym kodem niż docelowo w niej pracujący. To kosztuje i w zasadzie ją dyskwalifikuje. Natomiast budując zabawkę na jednym procesorku robioną w liczbie kilku tysięcy sztuk po prostu projektuję całe stanowisko testująco-programujące od zera. Wstawiam złącze na którym wyciągam sobie masy, wszystkie zasilania, jakiś interfejs ISP i może komunikacyjny z żywym programem. Stanowisko opieram na zwykłym kompie PC, testy wykonuje sam procesor a napięcia mierzę prostą kartą A/C. Do rzeczy nietypowych (diodki LED, obciążenia szyn zasilania czy jakieś linie I/O) mechanik robi pudełko w którym całość zamykam. Programowanie, testy, pomiary i sprawdzenie zapalania się diodek trwają razem 5 sekund, otwieramy klapkę i bierzemy następną płytkę. To jest standard dzisiejszych produkcji dla krótkich serii. Nikt nie siedzi z woltomierzem czy programatorem, bo konkurencja by go zjadła cenowo. debugWIRE jest pewną zewnętrzną emanacją interfejsu debugującego. Ponieważ ma on oczywisty dostęp do pewnych zasobów sprzętowych procesora, moim zdaniem jest to jednodrutowa implementacja czegoś znacznie większego. Znamy tylko kilka komend służących akurat do programowania pamięci i podczytywania zawartości rejestrów CPU, bo ATMEL uznał, że tylko tyle nam potrzeba. Byłoby głupotą sądzić, że producent pozbawił się możliwości testowania chipu po zamontowaniu go w obudowie. W każdym scalaku taki interfejs występuje. Może być uaktywniany jakimś wyższym napięciem na którejś nóżce, dziwną kombinacją stanów na wejściach lub nietrywialną sekwencją sygnałów. Mogli to zrobić przez debugWIRE (skoro już jest - a ładnie można to przełożyć na operacje wewnętrznego kontrolera JTAG) a mogli także wprost, przez zupełnie inne piny. Jaki byłby sens emulacji takich rzeczy przez ewentualnego podrabiacza? Przecież można (i należałoby) zrobić to wprost pod warunkiem, że posiadasz pełną dokumentację do oryginalnej kości. Pamiętaj, że to co widzisz w specyfikacji: lista instrukcji, organizacja rejestrów, znaczenie pinów itp to tylko dokumentacja użytkownika. Drugie tyle siedzi zaszyte w praktycznie każdym większym scalaku cyfrowym i służy jedynie jego testowaniu produkcyjnemu. Bez tego co piąty scalak sprzedawany na rynku byłby mniej lub bardziej wadliwy.

[deshipu]

Jaki byłby sens emulacji takich rzeczy przez ewentualnego podrabiacza?

No właśnie do tego zmierzam, że żaden, bo i tak jako użytkownik nie znający tajemnych komend Atmela nie mam żadnych szans na użycie tego do stwierdzenia, że chip jest podrobiony. Czyli w przypadku atmegi328p konkretnie scenariusz z procesorem wyprodukowanym w nowszej i tańszej technologii i emulującym rdzeń AVR jest potencjalnie możliwy -- choć na dzień dzisiejszy nie ma jeszcze technologii na tyle rozwiniętej, żeby się to komuś opłacało (i być może nigdy nie będzie, w końcu fizyka też nadaje jakieś granice innowacji).

Natomiast jeśli ktoś chciałby to robić nie ze względu na zarobek, a w innych celach (choćby po to, żeby samemu mieć tego JTAG-a, ale móc wykonywać stary kod), to możliwość w teorii istnieje.

[marek1707]

Uff, pomijając to o czym pisałem wcześniej:

- problemy z poborem mocy (musiałbyś mieć 10-krotnie szybszego FLASHa z którego pobierałbyś kod dla swojego emulatora kosztem tej samej energii, a to jest praktycznie dzisiaj niemożliwe), tu rozwiązaniem jest praca z RAMu lub ROMu,
- jeśli peryferia (timery, ADC, UARTy itd) też miałyby być emulowane to zegar rozkręcamy jeszcze 5-10 razy szybciej a jeśli robimy je w krzemie to po co emulować tylko jądro AVR - to już niewielki problem zrobić je samemu w Verilogu czy VHDL korzystając z darmowych wzroców?

- musiałbyś i tak zrobić własny interfejs testujący cały emulator czyli sprawdzający bardziej skomplikowaną kość pracującą z dużo wyższym zegarem,
- przetestować na produkcji bardziej skomplikowany scalak szybciej i za mniejsze pieniądze,
- dopasować zasilanie nowszej i dużo szybszej więc z pewnością niskonapięciowej technologii do zasilania 5V, plus programowanie FLASHa ISP przy bardzo różnych zasilaniach,

.. to tak, teoretycznie jest to możliwe. Jednak wyszło na Twoje

EDIT: "jako użytkownik nie znający tajemnych komend Atmela nie mam żadnych szans na użycie tego do stwierdzenia, że chip jest podrobiony"

Bez obrazy, ale Ty nikogo nie obchodzisz. Scalaki nie są robione dla Ciebie tylko dla dużych producentów elektroniki komercyjnej, profesjonalnej, wojskowej czy samochodowej. Oni muszą mieć możliwość szybkiego, taniego i niezawodnego testowania chipów i całych pakietów. Programiści dostają swoje zabawki w postaci interfejsów debugujących bo okazało się, że taniej jest wbudować to do każdego procesora niż budować duże urządzenie udające procesor w układzie docelowym (też robiłem takie rzeczy, ale dawno temu). Sprzętowo połączono dwa w jednym i jedni korzystają z tego samego linku do testowania na produkcji a drudzy do debugowania kodu. Przy czym z punktu widzenia "dużych" interfejs debugujący nie jest koniecznością (do tej pory kupowali sobie emulatory sprzętowe procesorów po 50kUSD to mogliby i teraz), a testujący już tak (bez tego jakakolwiek produkcja nie jest możliwa).

[deshipu]

- jeśli peryferia (timery, ADC, UARTy itd) też miałyby być emulowane to zegar rozkręcamy jeszcze 5-10 razy szybciej a jeśli robimy je w krzemie to po co emulować tylko jądro AVR - to już niewielki problem zrobić je samemu w Verilogu czy VHDL korzystając z darmowych wzroców?

Hmmm, czyli co, zamiast emulującego procka dajemy do klona tanią FPGA?