Czy programator PicKit2 w prostym klonie obsługuje procesory PIC32 z napięciem 3,3V?

Sat Nov 14, 2015 10:52 pm   

On Sat, 14 Nov 2015 22:00:36 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:

No właśnie mam takie samo zdanie o złączu do Atmegi, które widziałem
u kolegi atmegowca. Jak to złącze nazywacie - Kanda? Wielkie jak
cholera, dwurzędowe 2x5 pinów, kolega uparcie je w swoich płytkach
montuje mimo, że czasami zajmują mu połowę powierzchni płytki. Do
programowania Atmegi ICSP serio potrzeba aż 10 pinowegp złącza?
W PIC starczy 4 (Vpp,gnd, clk,dat) jeśli układ ma własne zasilanie.

--
Marek

Sat Nov 14, 2015 10:53 pm   

On 2015-11-14 22:45, Marek wrote:

Nie. Mam tutaj na tapecie przykład: potrzebuje 1 instrukcję na 1 clock i
hiper szybkie GPIO bez dużych obliczeń. AVR to daje. Taktowany 3x
szybciej ARM nie ... Taktowany 10x szybciej ARM kosztuje majątek i ma
footprint wielkości 10ciu AVRów. I pewno wolniejsze GPIO ;)

Tak, mógłbym wziąć CPLD/FPGA i dostać "lepiej" za 30x wieksze pieniądze.
To ja dziękuje ;)

Ostatnio pewna firma z Bytomia zrobiła najszybsza furmankę świata ('51).
Najwidoczniej rynek na aż tak denne procesory będzie istniał do końca
czegośtam.


Dla prędkości. ARMy sa wolniejsze niż się wydaje po MHz. Ogolnie im
szybszy procesor w MHz tym wolniejsze GPIO Taka obserwacja, nie
zawsze trzeźwa.

Sat Nov 14, 2015 10:59 pm   

On 2015-11-14 22:52, Marek wrote:

Ma określony kierunek wkładania wtyczki bo ma obudowę z klinem. Fakt,
niektórzy nie montują obudowy tylko gołe goldpiny. Nie rozumiem dlaczego.


Nie. Połowa to zasilanie w celu rozdzielenia przewodów sygnałowych.
Dodatkowo dzięki zasilaniu programator na poziomie sprzetowym wie jakim
napieciem gadać z CPU. Rozmiar "10 pinów" stosowany jest chyba tylko
dlatego że to najłatwiejsze w kupieniu gniazdo na taśmę.


PDI też ma 4 (3). Popularne w XMega.

W normalnych AVRach jest 4 + 2 zasilanie czyli jesli pozbedziesz się Vcc
to 5 drutów. Wiec złaczka 10 pin jest na wyrost, ale pozwala na
separacje lini sygnałowych.

Sat Nov 14, 2015 11:37 pm   

On Sat, 14 Nov 2015 22:53:34 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:


Powinieneś, jeśli głównym priorytetem ma być jak najszybsze machanie
pinem to użycie jakiekolwiek cpu do tego zadania trochę rozmija się
z celem do jakich większość cpu została zaprojektowana. To klasyczne
użycie narzędzia nieadekwatnego do relizacji zadania.



Jakiś link na ten temat masz pod ręka?
Chińczycy bardzo dużo używaja własnych klonów 51 w swoich produktach,
na mailing liście SDCC dość często są pytania dot. 51, pytania dot.
Z80 wcale ilością im nie ustępują :-)

--
Marek

Sat Nov 14, 2015 11:52 pm   

On 2015-11-14 23:37, Marek wrote:

Nie. Ekonomia stoi na przeszkodzie. FPGA są ciągle absurdalnie drogie.


http://www.chip.pl/news/sprzet/procesory/2011/11/w-polsce-powstal-najwydajniejszy-na-swiecie-procesor

Sun Nov 15, 2015 12:38 am   

On Sat, 14 Nov 2015 23:52:26 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:

17000MHz robi wrażenie (cały artykuł trzyma ten poziom kompetencji).
Również wizja użycia go w urządzeniach mobilnych brzmi ciekawie.
Minęło 4 lata , jakieś smartfony na nim ktoś widział?
Obawiam się że to case "procesora warszawa", wyciąganie kasy z unii.

--
Marek

Sun Nov 15, 2015 12:55 am   

On Sun, 15 Nov 2015 00:38:36 +0100, Marek <fake@fakeemail.com> wrote:

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!

--
Marek

Sun Nov 15, 2015 1:01 am   

On 2015-11-15 00:38, Marek wrote:

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.

Sun Nov 15, 2015 9:33 am   

On Sun, 15 Nov 2015 01:01:37 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:

Co konkretnie sugerujesz?

--
Marek

Sun Nov 15, 2015 10:11 am   

On 2015-11-15 09:33, Marek wrote:

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?

Sun Nov 15, 2015 10:31 am   

On 14.11.2015 22:45, Marek wrote:


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?

Sun Nov 15, 2015 11:14 am   

To, że pic16 (18F) jest przyjazny dla C.nie oznacza że Microchipowa
implementacja C jest przyjazna dla użytkownika , ale po kolei:

On Sun, 15 Nov 2015 10:31:51 +0100, Zbych <zbych@onet.pl> wrote:


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.

--
Marek

Sun Nov 15, 2015 11:30 am   

Dnia Sun, 15 Nov 2015 00:55:53 +0100, Marek napisał(a):

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.

Sun Nov 15, 2015 12:09 pm   

On Sun, 15 Nov 2015 11:30:15 +0100, "J.F."
<jfox_xnospamx@poczta.onet.pl> wrote:

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?

--
Marek

Sun Nov 15, 2015 12:30 pm   

On 15.11.2015 11:14, Marek wrote:

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: http://www.xargs.com/pic/picc18-vs-c18.html
Zwróć 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.