Prosty klon PicKit2 i procesory PIC32

Dodam tylko, że świat musi na prawdę być pod wrażeniem jakimi jesteśmy mistrzami w tworzeniu super procesorów, których twörcy robią na nich biznes mimo, ze nie sprzedali ani jednej sztuki. A idioci z Intela czy innego AMD wydają kasę na marketing, dział sprzedaży, wsparcia.... Rotfl! Uczyć się od Polaków robić biznesy!

Tam jest masa dupereli ale nawet jak się trafią konkrety to brzmi jakoś nienajszybciej. Np. 0.5DMIPS/MHz (żeby za chwile na stronie produktu napisać 75.08 VAX MIPS w celu reklamy :). Bieda. Może w powiązaniu z ilością bramek może imponować, ale bezwzględnie raczje nie.

Pewno do *szybkiego* sterowania modemem gsm. Z tego co widzę to te kawałki telefonów są sterowane tego typu antykami. Jakoś nie mogę się powstrzymać przed wizją że 30 lat temu ktoś napisał soft i zginął kod źrodłowy albo że architektura jest konsekrowana jakimś certyfikatem.

Gdyby nie było tego całego szumu w mediach pelnego kłamstw i półprawd to może bym założył że trafili w niszę i tyle. A że szum zrobił się przeogromny to mam wrażenie że ktoś tu kogoś robi ciula wykorzystując tępych dziennikarzy i masę niezrozumiałych liczb.

wykorzystując

Co konkretnie sugerujesz?

Komuś zależy na sukcesie bo otwiera to drzwi? Dziennikarze złapali clickbait i rozdmuchują ile wlezie? Społczeństwo wymaga nawet tak absurdalnych sukcesów?

A co jest przyjaznego w stronicowaniu RAMu co 256B, stronicowaniu flasha i sprzętowym stosie? I czemu użytkownik oryginalnego kompilatora microchipa (picc18) musi ręcznie przydzielać zmienne do banków jeśli chce w jednej jednostce kompilacji użyć więcej niż 256B na zmienne? Albo czemu musi tablice przekraczające 256B adresować tylko z użyciem wskaźników?

Stronicowanie flasha jest w corach pic14 (16F i mniejsze), core'y pic16 (18F) tego nie mają. Problem stronicowanie w pic14 nie dotyczy programowania C, np. SDCC na pic14 obsługuje to przezroczyscie dla programisty. Oczywiście inną kwestią jest wpływ na wydajność takiego stronicowania.

W czym to przeszkadza, skoro on jest tylko używany do call/return a kompilator i tak używa własny stos, którego wielkość można dowolnie ustalać? Po za tym są "shadowed registers", które sprzętowo wspomagają zachowywanie/odtwarzanie rejestrów przy obsłudze przerwań.

Ależ to są głównie problemy C18 (kompilatora i linkera), użyj inny kompilator. W SDCC np. nie ma problemu z rozróżnianiem wskaźników do flash i ram. W XC8 też już tego nie ma.

Trzeba też brać pod uwagę, że mówimy o 8 bitiwcach. Rejestry są 8 bitowe więc dostęp do pamięci większej niż 256 bajtów będzie zawsze się odbywał przez paradygmat stronicowania, bez względu jak technicznie będzie to zrealizowane (segment:offset, przełączanie banków, łączenie rejestrów itp). Oczywiście kompilator/linker może to "ukryć", ale to już kwestia implementacji, ale ona może mieć wpływ na wydajność. Jak rozwiązano linearny dostęp do pamięci w Atmedze/gcc-avr?

? w C18 nigdy nie miałem problemu z adresowaniem dużych tablic, poproszę o szczegóły/przykład. W SDCC jest/był problem z dużymi tablicami ale to dotyczy core'ow pic14.

Chodzi mi po glowie ze jest w Polsce kilka firm, ktore "projektuja procesory". Moze i nie sprzedali ani jednej szkuki, ale opis w VHDL jakiegos ARM czy 8051 to rzecz (a wlasciwie nie rzecz), ktora mozna drogo sprzedac.

J.

Ależ ja to nawet jestem w stanie zrozumieć, ale pod pewnym warunkiem: oczekuję, że będę mógł go kupić (nie ważne kto kupi licencję i będzie fizycznie go produkował), zaimplementować i *też* zrobić na nim biznes. Ja nie chcę czytać takich nagłówków ("pierwszy Polski procesor!" albo "Najszybszy na świecie Polski procesor!"), ja chcę aby na elektrodzie obok PIC, ARM czy AVR była zakładka np. PLPROC i dotyczyła rodzimej konstrukcji. Mrzonka?

Sprzętowy stos przeszkadza w przełączaniu wątków. Ile jest zestawów "shadow registers"? Po jednym dla każdego wektora przerwania? Bo dokumentacja microchipa jest jakoś skąpa w tym zakresie.

Własny procek microchipa i jego własny (płatny!) kompilator nie był w stanie ukryć upierdliwości (czy może przyjaznej dla kompilatorów) architektury.

XC8 nie testowałem, bo parę lat wstecz gdy wybierałem kompilator na PIC, to XC8 generował większy kod na PIC18 i sypał dużą ilością warningów na stosie TCP/IP microchipa. Stwierdziłem, że nie chcę być królikiem doświadczalnym. Opłacanie prawa do aktualizacji też nie nastawiało optymistycznie:

If your HPA has expired, you are entitled to download all compiler versions that have been released up to the time of the expiration.

8-bitowy procek nie oznacza 8-bitowej przestrzeni adresowej. Skąd ten pomysł?

Normalnie, adres jest 16-bitowy (albo dłuższy).

Cytat ze strony:

ć uwagę na ostatnie zdanie.

PICC-18 allows RAM objects of any size to be declared, though some limitations exist that require balancing objects between C source files in certain cases. C18 does not support RAM objects larger than 256 bytes by default; creating such objects requires editing linker control files and adding pragmas to the C source which include hard-coded variable addresses. These objects can only be accessed through pointers, not directly.

Znalazłem odpowiedź, zestaw jest jeden: Shadow registers can only be used with high priority interrupts – If low priority interrupt uses shadow registers, then can be overwritten by high priority interrupt

Czyli znowu zrobili to tak, żeby było upierdliwie.

Bosh, jakie wątki, mówimy o prostej 8 bitowej architekturze.

Wow, Atmega ma 16 bitowe rejestry ogólnego przeznaczenia (nie chodzi o rejestr PC)?

Pytanie jak wyżej.

variable

Moment, domyślnie przyjąłem, że mówisz o dużych tablicach we flash, bo jeśli ktoś chce używać duże tablice w ram na tak małym mcu, to przepraszam ale wybrał złe narządzie do realizacji swoich celów (co jest nagminne). Fakt, w przypadku ram jest tak jak opisujesz, natomiast nie widzę w tym problemu o ile nie próbuje się wykorzystywać niekompatybilnego z tym kodu.

Priorytety w tak prostych mcu to tylko kwiatek do korzucha. Nigdy nie miałem powodu ich używania, a jeśli bym miał użyłbym 32 bitowego procka a nie bawiłbym się w furmanki na sterydach.

Ale w takim procku mialbys jeszcze wiecej rejestrow do zapamietania :-) Albo podobny zestaw shadow :-)

J.

Marek pisze: [..]

Dlaczego złe narzędzie? Jeśli mam w kości dostępny 1 czy 2kB to chcę mieć swobodę jego użycia a nie ograniczenia. Dostałem w prezencie szynę nowych PICów (16F877), ucieszyłem się kombinując co ja z nich nie wystrugam, ale jak zacząłem się wgryzać w temat to mi się odechciało po napisaniu może 1/10 kodu, wcześniej robiłem na *51, teraz dostałem trochę atmeg, już widzę że to będzie to, właśnie strugam do nich prymitywny programator.

Daj sobie spokój z 16F.

Argument typu "a Porshe więcej pali". Nic nie muszę pamiętać, to problem kompilatora.

Na tak, przecież przełączanie wątków można robić na minimum na

16-bitach, sorry zapomniałem. Dobrze, że w innych firmach o tej zasadzie nie słyszeli.

A co ma długość rejestrów do możliwości _liniowego_ adresowania?

8080 to potrafił, Z80 to potrafił, ale widać geniusze z microchipa na to nie wpadli. Za to nie przeszkodziło im to opatentować mikrokontrolery, które mają mniej nóżek niż bitów.

Czyli mam uC z 4kB RAMu na pokładzie i zrobienie w nim "wielkiej" tablicy przekraczającej 256B to przegięcie? Dobrze się czujesz?

Bez przesady, piorytety to jest właśnie to czego mi brakuje w avr-ach. jak masz do obsłużenia więcej niż 2 przerwania to się przydają.

Dnia Sun, 15 Nov 2015 14:19:36 +0100, Marek napisał(a):

I kompilator obsluzy Ci przerwanie szybko i bezpiecznie ...

J.