Prosty klon PicKit2 i procesory PIC32

[Atlantis]

W sieci można znaleźć sporo projektów prostych i tanich programatorów
opartych na PicKit2. Większość z nich posiada kilka uproszczeń w
stosunku do oryginału. Powszechny jest np. brak możliwości ustawienia
napięcia na Vdd - zawsze będzie tam podawane 5V.

Pomimo tego w wieli opisach jest mowa, że taki programator ma obsługiwać
procesory PIC32, które nie pracują na napięciu 5V (zgodnie z
dokumentacją max. 3,6V).

Na taką informację można trafić chociażby tu:
http://allegro.pl/i5702702735.html

Ktoś popełnił błąd w opisie, czy faktycznie można programować te układy,
jeśli tylko programowany MCU zasili się z innego źródła o odpowiednim
napięciu? Poziomu napięcia na liniach sygnałowych będą odpowiednie?

Bo w przypadku takich AVR-ów programowanie układu pracującego na 3,3V za
pomocą programatora 5V jest bardzo złym pomysłem, nawet jeśli rozdzieli
się zasilanie. Ja zawsze stosuję optoizolację.
Czy z PIC-ami jest podobnie?

[ww]

On 2015-11-14 00:35, Atlantis wrote:
> Na taką informację można trafić chociażby tu:
> http://allegro.pl/i5702702735.html
>
> Ktoś popełnił błąd w opisie, czy faktycznie można programować te układy,
> jeśli tylko programowany MCU zasili się z innego źródła o odpowiednim
> napięciu? Poziomu napięcia na liniach sygnałowych będą odpowiednie

Skoro są 5V tolerant ?

[Marek]

On Sat, 14 Nov 2015 00:35:52 +0100, Atlantis <marekw19...@wp.pl>
wrote:

Pickit2 oryginalnie programuje układy 3.3V napięciem 3.3V, zresztą ma
na pokładzie mikro przetwornicę więc może generować dowolne napięcie
Vdd z zakresu 2-5V oraz Vpp aż do 12V. Z reguły napięcie określane
jest automatycznie przez model układu jaki chcemy zaprogramować,
soft programujący np. pk2cmd posiada bazę układów stąd zna ich
parametry i odpowiednio steruje firmwarem w pickit2. Można też
ustawiać inne napiecie ustawiając odpowiednią opcję w sofcie
programującym.
Jeśli chodzi o klony pickit2 to jeśli są wykonywane ze schematu
pickit2 jaki udostępnia Microchip i mają wgrany firmware do pickit2
(oryginalny) to praktycznie niczym się nie różnią od oryginału.
Pickit2 może mieć problem z pewnymi układami wydanymi później,
dotyczy to nowych układów mid range z rodziny 16f, nowych 18F oraz
nowych pic32. O ile w przypadku 16F nie ma co żałować bo są to układy
dla masochistów to układy 18F można zaprogramować po aktualizacji
bazy układów softu programującego.

W przypadku pic32 powstał otwarty akternatywny soft napisany przez
tego gościa od retrobsd, soft nazywa się pic32prog i programuje
wszystkie pic32 nawet te nowe, które nie są wspierane przez
oryginalny soft od Microchipa.

Oczywiście można kupić pickit3, ale oplnie o nim dosadnie wyraził
bloger Dave (eevblog):

http://www.youtube.com/watch?v=LjfIS65mwn8

Po czym Microchip odpowiedział mu tym filmem :-)

http://www.youtube.com/watch?v=3YUvlrVlNao

--
Marek

[Atlantis]

Chodziło mi o uproszczone klony PicKit2 - spora część z nich nie mają
możliwości zmiany Vdd - jest tylko 5V, ustawione "na sztywno" i nie
reagujące na ustawienia wprowadzane w uprogramowaniu.
Przetworniczka dostarcza tylko 12V dla Vpp.

Chopdzi mi o coś takiego:
http://www.blue17.elektroda.eu/pic/1354

Jakie układy można bezpiecznie programować takim urządzeniem? Tylko te
zasilane 5V, czy w przypadku zastosowania oddzielnego zasilania nada się
ono także do 3,3V?

[Marek]

On Sat, 14 Nov 2015 13:58:16 +0100, Atlantis <marekw19...@wp.pl>
wrote:

Niebardzo. Klasyczne układy pic 5V wymagają Vdd min 4.5 max 5.5,
oraz Vpp 12V.
Są wśród nich też układy z opcją LVP (low voltage programming) wtedy
wystarczy 5V Vpp zamiast 12V.
Ale z tego ci kojarzę większość układów 3.3V (oprócz tych
tolerujących Vdd 5V np. 18f26K22) programuje się nap. 3.3V, stąd 5 a
już 12 może im zrobić krzywdę.

Trzeba zwrócic uwagę też na to, że jeśli dany pic toleruje 5V (np.
pic32) to tylko na wybranych gpio i a nie na Vdd.

Jak chcesz się bawić w budowę programatora zbuduj pełen pickit2,
schemat i firmware są dostępne.

--
Marek

[Atlantis]

W dniu 2015-11-14 o 14:16, Marek pisze:

> Jak chcesz się bawić w budowę programatora zbuduj pełen pickit2, schemat
> i firmware są dostępne.

Polecisz jakiś projekt?

Bo wszędzie widzę albo te mocno uproszczone, pozbawione funkcjonalności,
albo wymagajace zamawiania płytek z uwagi na wykorzystanie dwustronnych
PCB. Czasem zresztą autorzy z dziwnych powodów nie zamieszczają plików w
odpowiedniej jakości.

A układów zaprojektowanych z użyciem elementów SMD w ogóle jak na
lekarstwo...

[kriters]

Nie lepiej kupić jednak gotowy ? Mnie gotowe klony pickit 2 i pickit 3
kosztowały
tyle co to dziadostwo bez obudowy.

[Sebastian Biały]

On 2015-11-14 15:58, Atlantis wrote:

>> Jak chcesz się bawić w budowę programatora zbuduj pełen pickit2, schemat
>> i firmware są dostępne.
> Polecisz jakiś projekt?

Czekaj, wersję 3 mozna kupić na allegro za jakieś 90zł, co prawda to
podróby (chyba) ale mają regulację 2.5<->5.5V. IMHO koszt zrobienia od
zera jest wyższy.

[Zbych]

http://www.aliexpress.com/wholesale?SearchText=pickit3

[Marek]

On Sat, 14 Nov 2015 15:58:11 +0100, Atlantis <marekw19...@wp.pl>
wrote:
> Polecisz jakiś projekt?

Nie bardzo, jak się uczyłem piców to zbudowałem programator na rs232
(12V na tym porcie było jak znalazł na Vpp), jest popularnych kilka
takich schematów. Mając ten programator napisałem własny soft do
programowania układów 12f,16f i 18f by w pełni nauczyć się tych mcu
nawet od strony ich programowania.
O ile edukacyjnie to się sprawdziło to sam programator był
nieporęczny, kiedyś przez przypadek jakiś luźny przewód dotknął
stronę 12V i pin mcu uszkadzając go. To wydarzenie oraz chęć
przejścia na pic32, których i tak nie mógłbym programować tym
programatorem zmobilizowały mnie do kupienia pickit2 i nie żałuję.

> Bo wszędzie widzę albo te mocno uproszczone, pozbawione
funkcjonalności,
> albo wymagajace zamawiania płytek z uwagi na wykorzystanie
dwustronnych
> PCB. Czasem zresztą autorzy z dziwnych powodów nie zamieszczają
plików w
> odpowiedniej jakości.
> A układów zaprojektowanych z użyciem elementów SMD w ogóle jak na
> lekarstwo...

A kupno pickit2 nie wchodzi w rachubę?
Moim zdaniem nie warto kombinować, szczególnie jeśli chcesz np.
programować pic32, bo tymi prostymi programatorami go nie
zaprogramujesz tzn. teoretycznie by można, w końcu to tylko
wachlowanie pinami ale soft wymagajacy zaprogramowanie pic32 wymaga
dość wyrafinowanego softu (tzw. programming executive), nie sądzę że
taki soft znajdziesz do tych prostych programatorów.

--
Marek

[Marek]

On Sat, 14 Nov 2015 16:13:31 +0100, Sebastian
Biały<he...@poczta.onet.pl> wrote:
> Czekaj, wersję 3 mozna kupić na allegro za jakieś 90zł, co prawda
to
> podróby (chyba) ale mają regulację 2.5<->5.5V. IMHO koszt zrobienia
od
> zera jest wyższy.

Ale po co ma kupować pickit3 który wymaga zamkniętego softu? Podobnie
jak Stallman odradzam inwestowanie w cokolwiek co ma zamknięty soft
jeśli jest otwarta alternatywa. Z takim zamkniętym nic później nie
można zrobić. Pickit2 ma otwarty soft i zaprogramuje nim wszystkie
układy, które potrzebuje w swoim hobby. No i dwójka powinna być
tańsza od trójki

--
Marek

[Sebastian Biały]

On 2015-11-14 17:48, Marek wrote:
> Ale po co ma kupować pickit3 który wymaga zamkniętego softu?

Bo w starszej wersji jest chyba kłopotliwy w zakupie.

Microchip to typowa firma olewająca OS, ale coś tam się zmienia:

http://www.microchip.com/forums/m654567.aspx?print=true

Ponadto gdzieś widziałem kilka firmware do podmiany.

PS. Absurdalność programatora PICów (dziwaczne napiecia, zamkniety arch,
kiepska dokumentacja, brak alternatyw itd) trzyma mnie od lat z daleka
od PICów. Może to kiepski argument, ale start z byle czym innym jak AVR
czy STM32 jest o niebo wygodniejszy niż żalosne koncepcje Microchipa.

[Marek]

On Sat, 14 Nov 2015 18:38:30 +0100, Sebastian
Biały<he...@poczta.onet.pl> wrote:
> PS. Absurdalność programatora PICów (dziwaczne napiecia, zamkniety
arch,

Dlaczego dziwaczne? Programator zasilany jest,z USB, generuje takie
napięcia jakie potrzebują PICe wyprodukowane w ostatnich 20 latach
(np kultowy 16F84) kiedy avr nawet nie było. Wcześniejsze PICe
wymagały 12V Vpp więc pickit2 je generuje.
Pickit2 jest arch. otwartą, wraz z programatorem user dostaje jego
schemat. Cześć firmwaru, ta w programatorze nie jest chyba otwarta
(mogę się mylić, już nie pamiętam) ale soft PC który się komunikuje z
pickitem (pk2cmd) jest otwarty. Dzięki temu wiadomo jak działa ta
cześć firmwaru w pickicie, co w efekcie umożliwiło dodanie nowych
układów do obsługi a nawet powstanie alternatywnego otwartego softu
(pic32prog) rozszerzające kolejne możliwości pickita2.
Co do samego programowania dokumentacja jest bardzo precyzyjna, na
upartego układt 8 bitowe 16F i 18F można zaprogramować bit po bicie
dostarczając odpowiednie Vdd iVpp a sygnały clk i dat generując
przełącznikami. Długo to by trwało ale da sie :-)

> kiepska dokumentacja, brak alternatyw

Ale jakie akternatywy masz na myśli?

> itd) trzyma mnie od lat z daleka
> od PICów. Może to kiepski argument, ale start z byle czym innym jak
AVR
> czy STM32 jest o niebo wygodniejszy niż żalosne koncepcje
Microchipa.

Ciągle na elektrodzie czytam "jak odblokiwać AVR", jakieś absurdy,
nie rozumiem jak może mcu być zablokowany, w PICach nie ma takiego
problemu.

W AVR w jakiś przypadkach musi być zew. kwarc bo układu się nie da
zaprogramować bo coś tam.

Userzy AVR często zazdroszczą PICom bogatych peryferiów już w
układach midrange, czyli słabszych pamięciowo od takiej popularnej
Atmegi8. Ostatnio kolega AVRowiec zadrościł, że taki prosty
pic16f6*8a na pinie timera (w trybie licznik zew. impulsów) może
zliczać impulsy z częstością większą niż jego Foscmax, czego Atmega8
nie umie bo tam jest jakieś ograniczenie 1/2Fosc wynikające z
konieczności samplowania i synchronizacją z Fosc Atmegi.

Także nie przesadzałbym tak z tą dziwacznością PICów, nie twierdzę o
jakieś specjalnej wyższości 8bit PICow nad 8bit AVR , uważam że są
godnymi konkurentami wzajemnie wypełniając braki tam gdzie konkurent
kuleje :-).

Jeśli chodzi o PIC32 a STM no to tu bardziej ciężka sprawa, bo wydaję
się obecnie, że,ARM ma jednak przewagę nad MIPSem na kilku polach,
chociaż podobno MIPS ostatniego słowa nie powiedział a ostatnie
ruchy w sprzedaży licencji mogą przynieść nowe ciekawe układy.

--
Marek

[Sebastian Biały]

On 2015-11-14 20:43, Marek wrote:
>> PS. Absurdalność programatora PICów (dziwaczne napiecia, zamkniety
> arch,
> Dlaczego dziwaczne?

12V do programowania flasha? O ile pamiętam AVRy go nie potrzebują poza
override resetu.

Ba, nawet złącze programowania piców jest ... gówniane. Nie chroni przed
odwróceniem ani wsadzeniem jeden pin obok. Niby detal, ale pokazuje
gdzie ma MC hobbystów.

> Programator zasilany jest,z USB, generuje takie
> napięcia jakie potrzebują PICe wyprodukowane w ostatnich 20 latach (np
> kultowy 16F84) kiedy avr nawet nie było. Wcześniejsze PICe wymagały 12V
> Vpp więc pickit2 je generuje.

O tym mówie. Pierwszym powodem dla ktorego nie uzywam PICów jest fakt że
pierwotnie były absurdalnie popieprzone w programowaniu z powodu 12V i
braku dostepności narzędzi takich jakich chce (a nie chce klikać). To
były czasy przed USB (co niewiele zmienia). Miałem jedne z pierwszych
PICów z flashem, pierwszy programator (wszystko na uczelni) i spędzilem
tydzień zanim okazalo się że programator nie działa z *tym* LPT. Bo nie.
Ślad w psychice pozostał bo STK200 do AVRów zadziałał nawet na Amidze.
Ba, zadziałał nawet taki na 5 rezystorach.

> Pickit2 jest arch. otwartą, wraz z programatorem user dostaje jego
> schemat. Cześć firmwaru, ta w programatorze nie jest chyba otwarta
> (mogę się mylić, już nie pamiętam) ale soft PC który się komunikuje z
> pickitem (pk2cmd) jest otwarty. Dzięki temu wiadomo jak działa ta cześć
> firmwaru w pickicie, co w efekcie umożliwiło dodanie nowych układów do
> obsługi a nawet powstanie alternatywnego otwartego softu (pic32prog)
> rozszerzające kolejne możliwości pickita2.

Tak, ale to było *potem*.

> Co do samego programowania dokumentacja jest bardzo precyzyjna, na
> upartego układt 8 bitowe 16F i 18F można zaprogramować bit po bicie
> dostarczając odpowiednie Vdd iVpp a sygnały clk i dat generując
> przełącznikami. Długo to by trwało ale da sie :-)

Tak, ale to było *potem*.

>> kiepska dokumentacja, brak alternatyw
> Ale jakie akternatywy masz na myśli?

Ludzie używający pickit3 narzekali swego czasu że musza uzywać debilnego
oprogramowania z MC i nie działa połowa ficzerów. I nie ma alternatyw.
Do dzisiaj się zmieniło, ale to był nastepny sygnal ostrzegawczy: "uwaga
MC nie należy ufać".

> Ciągle na elektrodzie czytam "jak odblokiwać AVR", jakieś absurdy, nie
> rozumiem jak może mcu być zablokowany, w PICach nie ma takiego problemu.

Ktoś przestawił oscylator na zewnętrzny i go nie podpiął. Tak na 90%.

> W AVR w jakiś przypadkach musi być zew. kwarc bo układu się nie da
> zaprogramować bo coś tam.

Nie. Na wewnętrznym RC programuje się ok. Jeśli przestawisz na
zewnętrzny to niestety. To nie arm w którym zazwyczaj procesor
przestawia się świadomie na inny clock.

> Userzy AVR często zazdroszczą PICom bogatych peryferiów już w układach

Też zazdroszcze. Ślinka mi pociekła na pierwszy uC z USB i był to jakiś
tam pic. AVRy tego nie miały jeszcze długo, de facto do dzisiaj, nie
licząc xmega.

> midrange, czyli słabszych pamięciowo od takiej popularnej Atmegi8.
> Ostatnio kolega AVRowiec zadrościł, że taki prosty pic16f6*8a na pinie
> timera (w trybie licznik zew. impulsów) może zliczać impulsy z
> częstością większą niż jego Foscmax, czego Atmega8 nie umie bo tam jest
> jakieś ograniczenie 1/2Fosc wynikające z konieczności samplowania i
> synchronizacją z Fosc Atmegi.

Ale tutaj troche przesadzasz, corner case nie ma żadnego praktycznego
wpływu na wybór rodziny cpu w skali globalnej przez hobbystów. Zwróć
uwagę że twórcy arduino mieli w dupie peryferia, chodziło o łatwośc i
dostepnośc kompiltora. MC im tego nie dostarczył z powodu fobii przed
OpenSource i gównianej architektury PICów, nieprzyjaznej dla języków
wyższego poziomu.

> Także nie przesadzałbym tak z tą dziwacznością PICów, nie twierdzę o
> jakieś specjalnej wyższości 8bit PICow nad 8bit AVR , uważam że są
> godnymi konkurentami wzajemnie wypełniając braki tam gdzie konkurent
> kuleje :-).

Też tak uważam, jednak ten watek pokazuje ze start z PICami może być
kłopotliwy. Tam gdzie jest 10 rodzajów programatorow do AVRa
dzialających praktycznie na każdym CPU i każdym softem to w przypadku
PICów mamy wybór między spiraconym pickit2 z poputym przetwornikiem
napięcia albo chińska podróbą pickit3 z niejasnym efektem po podpięciu
do cpu z 2.5V.

> Jeśli chodzi o PIC32 a STM no to tu bardziej ciężka sprawa, bo wydaję
> się obecnie, że,ARM ma jednak przewagę nad MIPSem na kilku polach,

STM przede wszystkim jest bardziej przyjazny dla hobbysty z powodu
normalnego JTAGa, normalnej architektury i normalnej polityki. Np. Atmel
dobił mnie gdy pewnego dnia podskoczyły 4x ceny pewnej serii SAM7.

> chociaż podobno MIPS ostatniego słowa nie powiedział a ostatnie ruchy w
> sprzedaży licencji mogą przynieść nowe ciekawe układy.

MIPS jest ok. Stary pic to porażka dla programisty. Zawsze powtarzałem
że najlepszym rozwiązaniem byłyby peryferia PICa z rdzeniem AVR.

[Marek]

On Sat, 14 Nov 2015 22:00:36 +0100, Sebastian
Biały<he...@poczta.onet.pl> wrote:
> > Co do samego programowania dokumentacja jest bardzo precyzyjna, na
> > upartego układt 8 bitowe 16F i 18F można zaprogramować bit po
bicie
> > dostarczając odpowiednie Vdd iVpp a sygnały clk i dat generując
> > przełącznikami. Długo to by trwało ale da sie :-)
> Tak, ale to było *potem*.

Ale przełącznikami mogłeś zaprogramować już *wtedy* a nie potem.
To, że wtedy nie znałeś algorytmu programowania (flasha) nie oznacza
że nie, dałoby się tego zrobić bez programatora.

> Ale tutaj troche przesadzasz, corner case nie ma żadnego
praktycznego
> wpływu na wybór rodziny cpu w skali globalnej przez hobbystów.
Zwróć
> uwagę że twórcy arduino mieli w dupie peryferia, chodziło o łatwośc
i
> dostepnośc kompiltora. MC im tego nie dostarczył z powodu fobii
przed
> OpenSource i gównianej architektury PICów, nieprzyjaznej dla
języków
> wyższego poziomu.

Ta uwaga dotyczy tylko układów 16F i mniejszych, układy 18F
(konkurencyjne z popularnymi Atmegami) mają już architekturę
przyjazną C.

> MIPS jest ok. Stary pic to porażka dla programisty. Zawsze
powtarzałem
> że najlepszym rozwiązaniem byłyby peryferia PICa z rdzeniem AVR.

A nie z rdzeniem ARM?
No bo tak na prawdę po co hobbyscie 8 bitowy mcu z jego wszystkimi
ograniczeniami 8bitowca? Kiedy pojawiły się pic32mx w wersji dip28,
wygodne w prototypowaniu uznałem, że chrzanić 8bitowce. Pomijając
wąskie zastosowanie gdzie taki 8bitowiec z XLP (eXtreme Low Power)
przydaje się w aplikacji zasilanej bateryjnie, to poza tym nie widzę
zalet w ich stosowaniu w hobby czy w domu i zagrodzie.

Szczerze liczyłem na to, że Mchp przejdzie z MIPS na ARM, ich decyzja
na "sterydowanie" MXa do wersji MZ zamiast wydania ARMa trochę.mnie
rozczarowała. Byłem przekonany, że gdy PiC32 mi się znudzi lub jego
zasoby staną się zbyt szczupłe (ram, flash) do jakiegoś projektu, to
będzie okazja bezboleśnie przejść na ich ARM (gdyby wydali).

--
Marek

[Marek]

On Sat, 14 Nov 2015 22:00:36 +0100, Sebastian
Biały<he...@poczta.onet.pl> wrote:
> Ba, nawet złącze programowania piców jest ... gówniane. Nie chroni
przed
> odwróceniem ani wsadzeniem jeden pin obok. Niby detal, ale pokazuje
> gdzie ma MC hobbystów.

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

[Sebastian Biały]

On 2015-11-14 22:45, Marek wrote:
>> że najlepszym rozwiązaniem byłyby peryferia PICa z rdzeniem AVR.
> A nie z rdzeniem ARM?

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.

> No bo tak na prawdę po co hobbyscie 8 bitowy mcu z
> jego wszystkimi ograniczeniami 8bitowca?

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.

[Sebastian Biały]

On 2015-11-14 22:52, Marek 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?

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.

> ICSP serio potrzeba aż 10 pinowegp złącza?

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ę.

> W PIC starczy 4 (Vpp,gnd, clk,dat) jeśli układ ma własne zasilanie.

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.

[Marek]

On Sat, 14 Nov 2015 22:53:34 +0100, Sebastian
Biały<he...@poczta.onet.pl> 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.

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.

> 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.

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

[Sebastian Biały]

On 2015-11-14 23:37, Marek wrote:
>> Tak, mógłbym wziąć CPLD/FPGA i dostać "lepiej" za 30x wieksze
> pieniądze.
> Powinieneś

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

>> 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.
> Jakiś link na ten temat masz pod ręka?

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

[Marek]

On Sat, 14 Nov 2015 23:52:26 +0100, Sebastian
Biały<he...@poczta.onet.pl> wrote:
> http://www.chip.pl/news/sprzet/procesory/2011/11/w-polsce-powstal-najwydajniejszy-na-swiecie-procesor

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

[Marek]

On Sun, 15 Nov 2015 00:38:36 +0100, Marek <fa...@fakeemail.com> wrote:
> Obawiam się że to case "procesora warszawa", wyciąganie kasy z unii.

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

[Sebastian Biały]

On 2015-11-15 00:38, Marek wrote:
>> http://www.chip.pl/news/sprzet/procesory/2011/11/w-polsce-powstal-najwydajniejszy-na-swiecie-procesor
> 17000MHz robi wrażenie (cały artykuł trzyma ten poziom kompetencji).

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.

> Również wizja użycia go w urządzeniach mobilnych brzmi ciekawie.

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.

> Obawiam się że to case "procesora warszawa", wyciąganie kasy z unii.

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.

[Marek]

On Sun, 15 Nov 2015 01:01:37 +0100, Sebastian
Biały<he...@poczta.onet.pl> wrote:
> 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.

Co konkretnie sugerujesz?

--
Marek

[Sebastian Biały]

On 2015-11-15 09:33, Marek wrote:
>> 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.
> 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?

[Zbych]

On 14.11.2015 22:45, Marek wrote:

> układy 18F
> (konkurencyjne z popularnymi Atmegami) mają już architekturę przyjazną C.

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?

[Marek]

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 <zb...@onet.pl> wrote:
> A co jest przyjaznego w stronicowaniu RAMu co 256B, stronicowaniu
flasha

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.


> i sprzętowym stosie?

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ń.

> 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?

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?

>Albo
> czemu musi tablice przekraczające 256B adresować tylko z użyciem
wskaźników?

? 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

[J.F.]

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.

[Marek]

On Sun, 15 Nov 2015 11:30:15 +0100, "J.F."
<jfox_x...@poczta.onet.pl> wrote:
> 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.

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

[Zbych]

On 15.11.2015 11:14, Marek wrote:
>> i sprzętowym stosie?
>
> 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ń.

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.

>> I czemu użytkownik oryginalnego kompilatora microchipa (picc18) musi
>> ręcznie przydzielać zmienne do banków

> jeślihttp://www.xargs.com/pic/picc18-vs-c18.html

>> chce w jednej jednostce kompilacji użyć więcej niż 256B na zmienne?
>
> 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.

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.

> 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ść.

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

> Jak rozwiązano linearny dostęp do pamięci w Atmedze/gcc-avr?

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

>> Albo czemu musi tablice przekraczające 256B adresować tylko z użyciem
> wskaźników?
>
> ? w C18 nigdy nie miałem problemu z adresowaniem dużych tablic, poproszę
> o szczegóły/przykład.

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.

[Zbych]

On 15.11.2015 12:30, Zbych wrote:
> On 15.11.2015 11:14, Marek wrote:
>>> i sprzętowym stosie?
>>
>> 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ń.
>
> 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.

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.

[Marek]

On Sun, 15 Nov 2015 12:30:49 +0100, Zbych <zb...@onet.pl> wrote:
> Sprzętowy stos przeszkadza w przełączaniu wątków.

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

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

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

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

Pytanie jak wyżej.

> 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.

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.

--
Marek

[Marek]

On Sun, 15 Nov 2015 12:56:27 +0100, Zbych <zb...@onet.pl> wrote:
> 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.

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.

--
Marek

[J.F.]

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


J.

[AlexY]

Marek pisze:
[..]

> 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).

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.

--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

[Marek]

On Sun, 15 Nov 2015 13:11:29 +0000, AlexY <al...@irc.pl> wrote:
> Dostałem w prezencie szynę nowych PICów (16F877), ucieszyłem się

Daj sobie spokój z 16F.

--
Marek

[Marek]

On Sun, 15 Nov 2015 13:40:18 +0100, "J.F."
<jfox_x...@poczta.onet.pl> wrote:
> Ale w takim procku mialbys jeszcze wiecej rejestrow do zapamietania
> :-)
> Albo podobny zestaw shadow :-)

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

--
Marek

[Zbych]

On 15.11.2015 13:17, Marek wrote:
> On Sun, 15 Nov 2015 12:30:49 +0100, Zbych <zb...@onet.pl> wrote:
>> Sprzętowy stos przeszkadza w przełączaniu wątków.
>
> Bosh, jakie wątki, mówimy o prostej 8 bitowej architekturze.

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.

>> 8-bitowy procek nie oznacza 8-bitowej przestrzeni adresowej. Skąd
> ten
>> pomysł?
>
> Wow, Atmega ma 16 bitowe rejestry ogólnego przeznaczenia (nie chodzi o
> rejestr PC)?

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.

>> 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.
>
> 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).

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

[janusz_k]

W dniu 2015-11-15 o 13:20, Marek pisze:

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ą.

--
Pozdr

Janusz_K

[J.F.]

I kompilator obsluzy Ci przerwanie szybko i bezpiecznie ...

J.

[janusz_k]

W dniu 2015-11-15 o 13:17, Marek pisze:

> On Sun, 15 Nov 2015 12:30:49 +0100, Zbych <zb...@onet.pl> wrote:
>> Sprzętowy stos przeszkadza w przełączaniu wątków.
>
> Bosh, jakie wątki, mówimy o prostej 8 bitowej architekturze.
>
>
>> 8-bitowy procek nie oznacza 8-bitowej przestrzeni adresowej. Skąd
> ten
>> pomysł?
>
> Wow, Atmega ma 16 bitowe rejestry ogólnego przeznaczenia (nie chodzi o
> rejestr PC)?

Tak i to nawet trzy, do tego dodawanie, odejmowanie od nich liczby 0-63,
gdzie wynik jest może być np: indexem do tablicy, kopiowanie rej 16bit,
poza tym lista rozkazów jest 16 bitowa.

--
Pozdr

Janusz_K

[Marek]

On Sun, 15 Nov 2015 16:18:03 +0100, Zbych <zb...@onet.pl> wrote:
> 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.

Atmega posiada mechanizmy sprzętowego wsparcia przełączania wątków
czy wywłaszczenia cpu? Bo przypominam, że mówimy o Atmedze.

> 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.

Rotfl, jaka jest różnica między łączeniem rejestrów 8 bitowych w
8080 cxy Z80 (nie wiem po co te przykłady skoro mówimy o Atmedze i
PIC) w jakikolwiek sposób aby poruszać się w 16bit przestrzeni
adresowej od użycia rejestru wyboru banku (wyboru starszego bitu w
adresie)? Oba mechanizmy dają taki sam efekt i są tym samym. Ale to
nie oznacza, że są tak samo wydajnymi metodami w porównaniu do
pełnego jednego rejestru 16bitowego, gdzie jest realna (a nie
pośrednia) liniowość w zakresie 16 bit adresacji.
To, że C18 ma problem z odczytem tablic inaczej niż przez wskaźnik
(nie wiem po co robić inny odczyt) to tylko problem tego kompilatora,
jest hitec, jest sdcc a teraz nawet xc8. w tych też ten problem
występuje?

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

Zdefiniuj "większe". Problem jaki podajesz z tą tablicą jest
wydumany, bo zakłada odczyt bez użycia wskaźnika, co w wielu
przypadkach jest niefektywne.

--
Marek

[Marek]

On Sun, 15 Nov 2015 17:07:55 +0100, janusz_k <Janu...@o2.pl> wrote:
> Tak i to nawet trzy, do tego dodawanie, odejmowanie od nich liczby
0-63,
> gdzie wynik jest może być np: indexem do tablicy, kopiowanie rej
16bit,
> poza tym lista rozkazów jest 16 bitowa.

A czy nie są to czasem łączone rejestry jak w 8080, przy czym zapis
odczyt i tak jest w 8bit. kawałkach?

--
Marek

[Marek]

On Sun, 15 Nov 2015 16:18:03 +0100, Zbych <zb...@onet.pl> wrote:

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

No to teraz wiem, kogo konkretnie miał na myśli Sebastian pisząc o
polskich wynalazcach najszybszych na świecie furmanek :-)

--
Marek

[janusz_k]

W dniu 2015-11-15 o 18:04, Marek pisze:

Tak są łączone i odczyt w kawałkach ale co to ma za znaczenie? operacje
są robione na obu tzn word i to jest istotne, służą do adresacji
pamięci.


--
Pozdr

Janusz_K

[janusz_k]

W dniu 2015-11-15 o 17:58, Marek pisze:

> On Sun, 15 Nov 2015 16:18:03 +0100, Zbych <zb...@onet.pl> wrote:
>> 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.
>
> Atmega posiada mechanizmy sprzętowego wsparcia przełączania wątków czy
> wywłaszczenia cpu? Bo przypominam, że mówimy o Atmedze.

Nie.

>
>> 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.
>
> Rotfl, jaka jest różnica między łączeniem rejestrów 8 bitowych w 8080
> cxy Z80 (nie wiem po co te przykłady skoro mówimy o Atmedze i PIC) w
> jakikolwiek sposób aby poruszać się w 16bit przestrzeni adresowej od
> użycia rejestru wyboru banku (wyboru starszego bitu w adresie)? Oba
> mechanizmy dają taki sam efekt i są tym samym. Ale to nie oznacza, że są
> tak samo wydajnymi metodami w porównaniu do pełnego jednego rejestru
> 16bitowego, gdzie jest realna (a nie pośrednia) liniowość w zakresie 16
> bit adresacji.

Kiedy właśnie w atmedze te dwa rejestry zachowują się jak jeden, tylko
operacje są troche ułomne bo dodawać, odejmować można w zakresie 0-63.
Więc w obsłudze jest dużo prostszy bo nie trzeba przełączać banków.

> To, że C18 ma problem z odczytem tablic inaczej niż przez wskaźnik (nie
> wiem po co robić inny odczyt) to tylko problem tego kompilatora, jest
> hitec, jest sdcc a teraz nawet xc8. w tych też ten problem występuje?
>
>
>> Czyli mam uC z 4kB RAMu na pokładzie i zrobienie w nim "wielkiej"
>> tablicy przekraczającej 256B to przegięcie? Dobrze się czujesz?
>
> Zdefiniuj "większe". Problem jaki podajesz z tą tablicą jest wydumany,
> bo zakłada odczyt bez użycia wskaźnika, co w wielu przypadkach jest
> niefektywne.
>

Jedno pobranie nieefektywne?
W atmedze jest to jeden rozkaz 2*word, a ty musisz wpier załądować
rejestr indexowy a później dopiero wczytać daną adresując ją tym
rejestrem, czyli dwie a nawet trzy operacje.

--
Pozdr

Janusz_K

[janusz_k]

W dniu 2015-11-15 o 18:07, Marek pisze:

Głośno o tym było :)

--
Pozdr

Janusz_K

[Sebastian Biały]

On 2015-11-15 17:58, Marek wrote:
> Atmega posiada mechanizmy sprzętowego wsparcia przełączania wątków czy
> wywłaszczenia cpu? Bo przypominam, że mówimy o Atmedze.

Atmega nie przeszkadza w wywlaszczaniu.

PIC (stary) przeszkadza w wywłaszczaniu.

Pi x drzwi na tym polega różnica. Oba nie mają żadnego wsparcia
sprzętowego i prawde mowiąc - znacznie większe procesory nie mają. Ważne
żeby nie przeszkadzać.

Prawda jest taka że PICa zaprojektował elektronik zaś AVRa programista.
Widać to po ograniczeniach obu arch.

[janusz_k]

> A nie z rdzeniem ARM? No bo tak na prawdę po co hobbyscie 8 bitowy mcu z
> jego wszystkimi ograniczeniami 8bitowca? Kiedy pojawiły się pic32mx w
> wersji dip28, wygodne w prototypowaniu uznałem, że chrzanić 8bitowce.
> Pomijając wąskie zastosowanie gdzie taki 8bitowiec z XLP (eXtreme Low
> Power) przydaje się w aplikacji zasilanej bateryjnie, to poza tym nie
> widzę zalet w ich stosowaniu w hobby czy w domu i zagrodzie.
Mylisz się, po pierwsze łatwiejszy w nauczeniu, po drugie 95% projektów
amatorów nie wykorzystuje mocy obliczeniowej 8 bitowca a co dopiero 32.
One w sumie bardziej przeszkadzają niż pomagają.
Dopiero skomplikowane obliczenia zmiennoprzecinkowe wymagają 32-bitowca.
Piszę skomplikowane bo widziałem kilka projektów DFT robionych na 8
bitach które sensownie chodziły.
A że naprawiam sprzęt profesjonalny to mam szerszy ogląd co jest
używane, większość sterowników czy prostych terminali chodzi na 8 bitach
:) mocniejsze procki są dopiero w kolorowych terminalach z dotykiem,
falownikach i serwach, nowych plc.


--
Pozdr

Janusz_K

[Zbych]

On 15.11.2015 17:58, Marek wrote:
> On Sun, 15 Nov 2015 16:18:03 +0100, Zbych <zb...@onet.pl> wrote:
>> 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.
>
> Atmega posiada mechanizmy sprzętowego wsparcia przełączania wątków czy
> wywłaszczenia cpu? Bo przypominam, że mówimy o Atmedze.

Czy to co ma AVR wpływa jakoś na brak ograniczeń w PICach?
Nie bardzo rozumiem po co za każdym razem wywlekasz jakiegoś AVRa?

A odpowiadając na pytanie - nie, nie ma sprzętowego wsparcia, ale daje
możliwość przełączania wątków. Antyczna '51 to dawała.

> To, że C18 ma problem z odczytem tablic inaczej niż przez wskaźnik (nie
> wiem po co robić inny odczyt)

Za każdym razem jak pada argument, na który nie masz sensownej
odpowiedzi to pada pytanie "a po co?", "czy avr to ma?", albo jakieś
mądrości o furmankach. Jesteś jakoś uczuciowo związany z PIC?

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

np. 573B.

> Problem jaki podajesz z tą tablicą jest wydumany,
> bo zakłada odczyt bez użycia wskaźnika, co w wielu przypadkach jest
> niefektywne.

To czy ja użyję w sposób jawny wskaźnika, czy nie, nie ma znaczenia.
Kompilator niech pod spodem tak to robi, żeby było efektywnie.
Ja chcę mieć dostęp w liniowy sposób do całej wbudowanej pamięci.

[AlexY]

Marek pisze:

> On Sun, 15 Nov 2015 13:11:29 +0000, AlexY <al...@irc.pl> wrote:
>> Dostałem w prezencie szynę nowych PICów (16F877), ucieszyłem się
>
> Daj sobie spokój z 16F.

Bo?
Dałem sobie spokój z PICami w ogóle, ta kość ma ze 2 razy więcej zasobów
i bajerów aniżeli potrzebowałem, odpuściłem głównie z powodu zagmatwanej
obsługi SFR i pamięci RAM oraz bezsensownej obsługi tablic w pamięci
programu, a potrzebowałem generator znaków dla LCD graficznego.

[Marek]

On Sun, 15 Nov 2015 19:17:08 +0100, janusz_k <Janu...@o2.pl> wrote:
> Jedno pobranie nieefektywne?

A dlaczego jedno?

> W atmedze jest to jeden rozkaz 2*word, a ty musisz wpier załądować
> rejestr indexowy a później dopiero wczytać daną adresując ją tym
> rejestrem, czyli dwie a nawet trzy operacje.

Momencik, ale żeby w Atmedze móc wywołać ten rozkaz adres trzeba
gdzieś załadować, prawda? Coś tu na skróty idziesz :).

--
Marek

[Marek]

On Sun, 15 Nov 2015 19:44:01 +0100, Zbych <zb...@onet.pl> wrote:
> Czy to co ma AVR wpływa jakoś na brak ograniczeń w PICach?
> Nie bardzo rozumiem po co za każdym razem wywlekasz jakiegoś AVRa?

No bo nie wiem czy zauważyłeś ale dyskusja jest o wadach i zaletach
avr i pic (core pic16 żeby było z czym porównywać)

> Za każdym razem jak pada argument, na który nie masz sensownej
> odpowiedzi to pada pytanie "a po co?",

Ależ gdyby były to argumenty w ramach granic tematu to słowa bym nie
powiedział :)

> "czy avr to ma?", albo jakieś
> mądrości o furmankach. Jesteś jakoś uczuciowo związany z PIC?

Nie ukrywam tego, inaczej głosu bym nie zabierał.

> Kompilator niech pod spodem tak to robi, żeby było efektywnie.
> Ja chcę mieć dostęp w liniowy sposób do całej wbudowanej pamięci.

Tu zgoda, dlatego nie przemawia do mnie argument, że skoro kompilator
zły to mcu też do bani. Można zmienić kompilator.
A nawet odwrotnie. Kiedyś używałem sdcc bo jest wygodniejszy w
pewnych aspektach programistycznych (nie odróżnia wsk. do ram i
flash) no i jest otwarty ale generuje kod nieoptymalny pod kątem
rozmiaru. Wróciłem do C18, bo daje prawie o połowę mniejszy kod. Wolę
już upierdliwości C18 (pod strony programistycznej) ale przynajmniej
generuje kod optymalny pod architekturę do jakiej został stworzony.

--
Marek

[Marek]

On Sun, 15 Nov 2015 19:33:20 +0000, AlexY <al...@irc.pl> wrote:
> Bo?
> Dałem sobie spokój z PICami w ogóle, ta kość ma ze 2 razy więcej
zasobów
> i bajerów aniżeli potrzebowałem, odpuściłem głównie z powodu
zagmatwanej

> obsługi SFR i pamięci RAM Wiekóworaz bezsensownej obsługi tablic w

pamięci
> programu, a potrzebowałem generator znaków dla LCD graficznego.

Własnie dlatego.
Jest to architektura nieprzyjazna C*, kompatybilna z 25 letnim 16F84,
raczej do programowania w asemblerze, co przy tej arch. to koszmar.
Na zasoby nie patrz, Microchip zawsze wsadza co się da nawet do
prymitywnego mcu tej klasy.

Nie wiem czemu userzy z doświadczeniami z Atmegą a chcący poznać pice
wybierają często 16F, które są rząd klasy w tyle za Atmegami.
Oczywiście to szybko wychodzi więc później mówią że pice (wszystkie)
są do bani.
Jeśli ktoś zna Atmegę i programuje w C to powinien wybierać układy
18F, szczególnie układy serii J które mają super precyzyjne wew.
oscylatory albo K które mają 64MHz PLL.



*- co nie oznacza, że nie ma kompilatorów C do nich.

--
Marek

[AlexY]

Marek pisze:
[..]

> Nie wiem czemu userzy z doświadczeniami z Atmegą a chcący poznać pice
> wybierają często 16F, które są rząd klasy w tyle za Atmegami. Oczywiście
> to szybko wychodzi więc później mówią że pice (wszystkie) są do bani.

Akurat takie dostałem za friko, firma gdzie kolega robił przestała ich
używać i reszta miała iść do utylizacji.

> Jeśli ktoś zna Atmegę i programuje w C to powinien wybierać układy 18F,
> szczególnie układy serii J które mają super precyzyjne wew. oscylatory
> albo K które mają 64MHz PLL.

No to nie o mnie, jeszcze nie znam atmeg i nie piszę w C, tylko assembler.

[Marek]

On Mon, 16 Nov 2015 10:55:03 +0000, AlexY <al...@irc.pl> wrote:
> No to nie o mnie, jeszcze nie znam atmeg i nie piszę w C, tylko
assembler.

Szczere wyrazy współczucia :), szczególnie jeśli miałbyś męczyć
assembler w tych 16F.

Kiedyś popełniłem na tych układach prosty sterownik włącz/wyłącz z
modemem gsm. Całość w assemblerze (było to zanim przeszedłem na 18F i
C), modem nie obsługiwał trybu text w smsach tylko pdu no więc
machnąłem pdu encoder/decoder w tym assemblerze. Efekt był taki, że
po dwóch dniach przerwy od napisania działającej wersji mimo
komentarzy za cholerę nie mogłem się połapać o co chodziło "autorowi"
w tym kodzie...

--
Marek

[Piotr Wyderski]

Marek wrote:

> Wolę już upierdliwości C18 (pod strony programistycznej) ale
> przynajmniej generuje kod optymalny pod architekturę do jakiej został
stworzony.

Ale dopiero w trybie "jak se kupisz", bo wersja free nie ma
włączonej optymalizacji. Co w 21. wieku jest absurdem i raczej
powinno odstraszać od wejścia w PICe, zwłaszcza te duże. Na
ARM jest darmowy i bardzo dobry kompilator.

Pozdrawiam, Piotr

[Marek]

On Mon, 16 Nov 2015 15:00:09 +0100, Piotr Wyderski
<pete...@neverland.mil> wrote:
> Ale dopiero w trybie "jak se kupisz", bo wersja free nie ma
> włączonej optymalizacji. Co w 21. wieku jest absurdem i raczej
> powinno odstraszać od wejścia w PICe, zwłaszcza te duże. Na
> ARM jest darmowy i bardzo dobry kompilator.

Zgodzę się, płatne narzędzia w takim przypadku i w dzisiejszych
czasach to nieporozumienie, szczególnie gdy konkurencja udostępnia
utilsy za darmo bez ograniczeń funkcjonalnych.
Dla mnie wygląda to, że w Mchp w marketingu siedzi jakąś grupa
oszołomów, lub są pod jakimś wpływem. Co z resztą sami potwierdzili
pośrednio w filmie będącym odpowiedzią na krytykę pickita3.

--
Marek

[Marek]

On Sun, 15 Nov 2015 19:19:52 +0100, Sebastian
Biały<he...@poczta.onet.pl> wrote:
> Atmega nie przeszkadza w wywlaszczaniu.
> PIC (stary) przeszkadza w wywłaszczaniu.

Powolutku. Już ustaliliśmy, że pice z corem 14 bit ("stare" czyli 16F
i mniejsze) są do bani i ich nie bierzemy pod uwagę w porównywaniu z
Atmegą, bo tu nie ma co porównywać. W czym przeszkadzają 18F w
tworzeniu wątków? Oprócz stosu hardwerowego mają stos softwarowy oraz
rejestry do zarządzania nim (FSR*, STKPTR itd). Kojarzę nawet
wsparcie do 18F w FreeRTOS.

--
Marek

[Piotr Wyderski]

Sebastian Biały wrote:

> PS. Absurdalność programatora PICów (dziwaczne napiecia, zamkniety arch,
> kiepska dokumentacja, brak alternatyw itd) trzyma mnie od lat z daleka
> od PICów. Może to kiepski argument, ale start z byle czym innym jak AVR
> czy STM32 jest o niebo wygodniejszy

Tylko niestety AVR mają bardzo biedne peryferia. Z tego powodu
nigdy nie było mi szkoda ich porzucenia na rzecz PICów.

Pozdrawiam, Piotr

[Piotr Wyderski]

Marek wrote:

> Daj sobie spokój z 16F.

Czemu, 1709 JEST FAJNY!!! :-)))

Pozdrawiam, Piotr

[Piotr Wyderski]

Marek wrote:

> Na zasoby nie patrz, Microchip zawsze wsadza co się da nawet do
> prymitywnego mcu tej klasy.

Pierwszy raz widzę, by ktoś narzekał na *nadmiar* zasobów. :-)))
Niewykorzystaną powierzchnię krzemu obłożyli podatkiem katastralnym? ;-)

Ja sobie nie mogę wybaczyc, ile czasu zmarnowałem na obchodzenie
ograniczeń niepełnosprawnych już u poczęcia peryferiów w AVRkach...

Pozdrawiam, Piotr

[janusz_k]

W dniu 2015-11-15 o 20:37, Marek pisze:

> On Sun, 15 Nov 2015 19:17:08 +0100, janusz_k <Janu...@o2.pl> wrote:
>> Jedno pobranie nieefektywne?
>
> A dlaczego jedno?

sam napisałeś "Problem jaki podajesz z tą tablicą jest wydumany, bo

zakłada odczyt bez użycia wskaźnika, co w wielu przypadkach jest
niefektywne."

Sam napisałeś o odczycie bez wskaźnika, czyli nie przeszukujemy tablicy
za pomocą rejestru idexowego tylko czytamy sobie jeden bajt gdzieś z
pamięci, wolno? wolno.
I dla tego przypadku się odniosłem, w atmedze można odczytać dowolny
bajt z ram jedną instrukcją dwu słowową czyli ma długość 32 bity, ale
nadal jest to jedna instrukcja "LDS Rd,k" gdzie Rd to dowolny rejestr
0-32 a k liczba 0 - 65535.

>
>> W atmedze jest to jeden rozkaz 2*word, a ty musisz wpier załądować
>> rejestr indexowy a później dopiero wczytać daną adresując ją tym
>> rejestrem, czyli dwie a nawet trzy operacje.
>
> Momencik, ale żeby w Atmedze móc wywołać ten rozkaz adres trzeba gdzieś
> załadować, prawda? Coś tu na skróty idziesz :).

Nie, adres jest w rozkazie, napisałem wyżej. To ty musisz załadować
adres do rej indexowego i to nawet dwa razy, Lo, Hi bajt a potem dopiero
wykonać operację, czyli w sumie trzy instrukcje.


--
Pozdr

Janusz_K

[J.F.]

Użytkownik "Piotr Wyderski" napisał w wiadomości grup
dyskusyjnych:n2d498$b4f$1...@node1.news.atman.pl...

Marek wrote:
>> Na zasoby nie patrz, Microchip zawsze wsadza co się da nawet do
>> prymitywnego mcu tej klasy.

>Pierwszy raz widzę, by ktoś narzekał na *nadmiar* zasobów. :-)))
>Niewykorzystaną powierzchnię krzemu obłożyli podatkiem katastralnym?
>;-)

Byc moze - wszak mniejszego kawalka niz jakis tam sie nie nie da
zamontowac :-)

>Ja sobie nie mogę wybaczyc, ile czasu zmarnowałem na obchodzenie
>ograniczeń niepełnosprawnych już u poczęcia peryferiów w AVRkach...

Ale to masz na mysli PIC, PIC32, dsPIC ?

Bo mi sie tam wydaje, ze wczesne PICe byly ulomne nawet bardziej niz
AVR ...

J.

[Sebastian Biały]

On 2015-11-16 15:45, Marek wrote:
>> Atmega nie przeszkadza w wywlaszczaniu.
>> PIC (stary) przeszkadza w wywłaszczaniu.
> Powolutku. Już ustaliliśmy, że pice z corem 14 bit ("stare" czyli 16F i
> mniejsze) są do bani i ich nie bierzemy pod uwagę w porównywaniu z
> Atmegą, bo tu nie ma co porównywać. W czym przeszkadzają 18F w tworzeniu
> wątków?

Napisałem "stary". W zwiazku z tym cała reszta wypowiedzi mija sie z celem.

[Sebastian Biały]

On 2015-11-15 21:39, Marek wrote:
> albo K które mają 64MHz PLL.

Ale dalej dzielą to przez 4 czy tam jest lepiej niż w starszych?

[Marek]

On Mon, 16 Nov 2015 18:37:43 +0100, Piotr Wyderski
<pete...@neverland.mil> wrote:
> Pierwszy raz widzę, by ktoś narzekał na *nadmiar* zasobów. :-)))

Po prostu te same zasoby są w 18F, więcej pamięci, 64Mhz PLL. Wiem,
że XC8 supportuje już 16F ale mimo wszystko 18F są bardziej
zaawansowane.

--
Marek

[Marek]

On Mon, 16 Nov 2015 19:24:57 +0100, Sebastian
Biały<he...@poczta.onet.pl> wrote:
> Ale dalej dzielą to przez 4 czy tam jest lepiej niż w starszych?

Nadal jest Fosc/4, to podstawa tej religi ;).
Natomiast Fosc/1 może być wejściem dla timera.

--
Marek

[AlexY]

Marek pisze:

> On Mon, 16 Nov 2015 10:55:03 +0000, AlexY <al...@irc.pl> wrote:
>> No to nie o mnie, jeszcze nie znam atmeg i nie piszę w C, tylko
> assembler.
>
> Szczere wyrazy współczucia :), szczególnie jeśli miałbyś męczyć
> assembler w tych 16F.

Pisanie programu szło nawet nieźle do czasu owego generatora znaków, na
pewniaka po staremu zacząłem szukać polecenia odczytu pamięci programu i
mi kopara opadła jak zobaczyłem jak to się robi, peryferia fakt ma fajne
ale procek jest tak upierdliwy że zwyczajnie odpuściłem.

> Kiedyś popełniłem na tych układach prosty sterownik włącz/wyłącz z
> modemem gsm. Całość w assemblerze (było to zanim przeszedłem na 18F i
> C), modem nie obsługiwał trybu text w smsach tylko pdu no więc
> machnąłem pdu encoder/decoder w tym assemblerze. Efekt był taki, że po
> dwóch dniach przerwy od napisania działającej wersji mimo komentarzy za
> cholerę nie mogłem się połapać o co chodziło "autorowi" w tym kodzie...

W tym celu bazuję na algorytmach, poszczególne bloki tłumaczę na assembler.

[Waldek Hebisch]

Sebastian Bia?y <he...@poczta.onet.pl> wrote:
> On 2015-11-14 22:45, Marek wrote:
> >> ?e najlepszym rozwi?zaniem by?yby peryferia PICa z rdzeniem AVR.

> > A nie z rdzeniem ARM?
>

> Nie. Mam tutaj na tapecie przyklad: 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 ;)

Mozesz to rozwinac? Czytajac datasheety widze ze instrucje obslugujace
GPIO w ARM maja sie wykonac w 1 takcie procesora (chyba ze GPIO jest
podwieszone do szyny z wolniejszym zegarem, ale to w modelach majaczych
szybszy zeger). Dla STM32F10xx datasheet podaje ze GPIO przelacza do
18 MHz, to duzo mniej niz maksymalny zegar, ale porownywalne z
AVR przy 18 MHz zegarze. Do tego w praktyce dane do GPIO trzeba
jakos wyprodukowac, a z odzcztanymi danymi cos zrobic. Wiec
wyglada ze gdzis polowa czestoci zegara to maksimum na GPIO.
Wiec taki STM32F10xx powinien wygrac z AVR gdzies do 36 MHz.

Dla LM4F120H5QR (marketing zmienil numer na TM... ale o ile
wiem parametry maja byc te same) Ti podaje o GPIO:

: Fast toggle capable of a change every clock cycle for ports on AHB, every
: two clock cycles for ports on APB

przy 80 MHz to wyglada duzo lepiej niz AVR. Fakt ze to drozszy
model, ale nie najwysza polka.

Co przegapilem?

> 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.

No, jak chcesz naprawde szybkie CPU to sie wstawia bufory na IO,
a wtedy sa dodatkoww opoznienia w porownaniu z CPU ktore ma
wolniejszy zeger i nie buforuje IO...

--
Waldek Hebisch

[Sebastian Biały]

On 2015-11-17 15:08, Waldek Hebisch wrote:
>> Nie. Mam tutaj na tapecie przyklad: 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 ;)
> Mozesz to rozwinac?

Mam trywialne zagadnienie, musze wyprodukować jak najszybciej zmiany na
magistrali adresowej Z80, ale za pomocą AVR. To znaczy że musze jak
najszybciej wypychać rejestry na porty tak aby zaemulować odpowiedź
jakiegoś urządzenia albo pobrać z niej dane. Nie pytaj po co, retro jako
hobby :)

Dane są gotowe w rejestrach, chodzi o ich wypychanie jak najszybciej i w
precyzyjnych momentach.

> Czytajac datasheety widze ze instrucje obslugujace
> GPIO w ARM maja sie wykonac w 1 takcie procesora (chyba ze GPIO jest
> podwieszone do szyny z wolniejszym zegarem, ale to w modelach majaczych
> szybszy zeger).

Problemem jest fakt że w ARM kod wykonywany z Flash jest wolniejszy niż
wykonywany z RAM. Efektem czego SAM7 poganiany zegarem 60MHz przegrywał
z AVRem poganianym 20MHz. Byłem tym bardzo zdziwiony do czasu aż nie
doczytałem że Flash ma absurdalnie duże waitstates. W obu wypadkach było
mov 0,port; mov 1,port; jump again; Oczywiście mogę przenieść kod do RAM
i już, ale wtedy okrakiem staje prędkośc GPIO w SAM7. I tak się
oduczyłem patrzeć na MHz.

Dla STM32F10xx datasheet podaje ze GPIO przelacza do
> 18 MHz

Tak, GPIO jest również powolne w dużych procesorach z przyczyn niejasnych.

> wyglada ze gdzis polowa czestoci zegara to maksimum na GPIO.
> Wiec taki STM32F10xx powinien wygrac z AVR gdzies do 36 MHz.

W moim projekcie jak zauważyleś wyżej potrzeba jest również 5V :) Miałem
nadzieje na dsPIC33, ale okazało się ze tam zegar dzielony jest dalej
przez 4 więc nic nie zyskam.

> Dla LM4F120H5QR (marketing zmienil numer na TM... ale o ile
> wiem parametry maja byc te same) Ti podaje o GPIO:
>
> : Fast toggle capable of a change every clock cycle for ports on AHB, every
> : two clock cycles for ports on APB
>
> przy 80 MHz to wyglada duzo lepiej niz AVR. Fakt ze to drozszy
> model, ale nie najwysza polka.
> Co przegapilem?

Nic. Do wyboru jest wiele szybkich cpu, ale niektórych nie ma sensu do
zabawy z różnych względów brac: albo 3.3V, albo obudowa z miliardem
nózek, albo 7 napięć zasilających, itd.

> No, jak chcesz naprawde szybkie CPU

Nie, nie chce. Chce odpowiednie narzedzie do problemu. Wydaje się że PIC
się nie sprawdzi a AVR tak.

[Marek]

On Tue, 17 Nov 2015 20:32:41 +0100, Sebastian
Biały<he...@poczta.onet.pl> wrote:
> Mam trywialne zagadnienie, musze wyprodukować jak najszybciej
zmiany na
> magistrali adresowej Z80, ale za pomocą AVR. To znaczy że musze jak
> najszybciej wypychać rejestry na porty tak aby zaemulować odpowiedź
> jakiegoś urządzenia albo pobrać z niej dane. Nie pytaj po co, retro
jako
> hobby :)

Jakośv ciągle stosujesz ogólniki "jak najszybciej" zamiast podać
konkretne liczby. Ile w Mhz wachlowanie pinem Cię zadowoli 20Mhz,
100Mhz, 1000Mhz?

--
Marek

[Sebastian Biały]

On 2015-11-17 23:23, Marek wrote:
>> jakiegoś urządzenia albo pobrać z niej dane. Nie pytaj po co, retro
> jako
>> hobby :)
> Jakośv ciągle stosujesz ogólniki "jak najszybciej" zamiast podać
> konkretne liczby. Ile w Mhz wachlowanie pinem Cię zadowoli 20Mhz,
> 100Mhz, 1000Mhz?

Potrzebuje minimum około 10 cykli cpu (najlepiej >16 bo wtedy mam
swobodę) pomiedzy 1 cyklem zegara Z80, taktowanie powiedzmy 3MHz. Czyli
potrzebuje w moim cpu 30MIPSów licząc instrukcję na cykl, tak na start,
oraz spodziewam się że GPIO bedzie machało tak samo szybko. Ponadto
liczy się też asm, np. niezwykle byłby wygodny skok przez tablicę
adresów we flash.

[JDX]

On 2015-11-15 19:25, janusz_k wrote:
[...]

> Mylisz się, po pierwsze łatwiejszy w nauczeniu, po drugie 95% projektów
> amatorów nie wykorzystuje mocy obliczeniowej 8 bitowca a co dopiero 32.

Bez przesady z tą trudnością. IMO np. AVR i ARM7TDMI to "the same shit".
Jednak MCU 32-bitowy pozwala uniknąć programiście niektórych
upierdliwości, ot, np. atomowe dodawanie liczb "szerszych" niż 8-bitowe.
No i fakt, do realizacji jakiegoś urządzenia często nie są potrzebne
jakieś duże ilości (D)MIPS-ów, ale np. potrzeba sporo pamięci danych i
pod tym względem 32-bitowce są z reguły lepiej wyposażone co pozwala na
umieszczenie na PCB jednej kostki zamiast MCU i dodatkowego RAM-u.

[JDX]

On 2015-11-14 13:42, Marek wrote:
[...]
> http://www.youtube.com/watch?v=LjfIS65mwn8
>
> Po czym Microchip odpowiedział mu tym filmem :-)
>
> http://www.youtube.com/watch?v=3YUvlrVlNao
Hehe, jak oglądałem Dave'a to od razu pomyślałem, że przyczepią się do
tego dickhead manager-a. :-D

[Waldek Hebisch]

Sebastian Bia?y <he...@poczta.onet.pl> wrote:
> On 2015-11-17 15:08, Waldek Hebisch wrote:
> >> Nie. Mam tutaj na tapecie przyklad: 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 ;)
> > Mozesz to rozwinac?
>

> Mam trywialne zagadnienie, musze wyprodukowa? jak najszybciej zmiany na
> magistrali adresowej Z80, ale za pomoc? AVR. To znaczy ?e musze jak
> najszybciej wypycha? rejestry na porty tak aby zaemulowa? odpowied?
> jakiego? urz?dzenia albo pobra? z niej dane. Nie pytaj po co, retro jako
> hobby :)
>
> Dane s? gotowe w rejestrach, chodzi o ich wypychanie jak najszybciej i w
> precyzyjnych momentach.

No, jesli chesz emulowac Z80 to musisz napierw policzyc co
wyslac na szyne...

> > Czytajac datasheety widze ze instrucje obslugujace
> > GPIO w ARM maja sie wykonac w 1 takcie procesora (chyba ze GPIO jest
> > podwieszone do szyny z wolniejszym zegarem, ale to w modelach majaczych
> > szybszy zeger).
>

> Problemem jest fakt ?e w ARM kod wykonywany z Flash jest wolniejszy ni?
> wykonywany z RAM. Efektem czego SAM7 poganiany zegarem 60MHz przegrywa?
> z AVRem poganianym 20MHz. By?em tym bardzo zdziwiony do czasu a? nie
> doczyta?em ?e Flash ma absurdalnie du?e waitstates. W obu wypadkach by?o
> mov 0,port; mov 1,port; jump again; Oczywi?cie mog? przenie?? kod do RAM
> i ju?, ale wtedy okrakiem staje pr?dko?c GPIO w SAM7. I tak si?
> oduczy?em patrze? na MHz.

Niestety, flash jest powonly i jest normalne ze procesor ma szybszy
zegar niz zegar flash-u. Dla liniowych fragmentow kodu powinien
dzialac prefetch, tylko przy skokach powinny dojsc te waitstates.
Po tym con napisales zdecydowalem sie sprawdzic jak to wychodzi
na innych prockach. Na Atemega 328P (jako baza) wychdza 4 cykle
na okrazenie. Na STM32F051R9T6 ponizsza petla z RAM-u wykonuje
sie w 7 taktach:

00000000 <wr_loop>:
0: 6010 str r0, [r2, #0]
2: 6011 str r1, [r2, #0]
4: e7fc b.n 0 <wr_loop>

Tu korekta do tego co pisalem wczesniej: na Cortexie M0
zapis i odczyt to 2 takty. Skok to 3, razem 7. Przy
48 MHz zegarze daje to 6.857 MHz -- pomiar na pinie
z dokladnoscia do bledu pomiaru daje to samo. To jest
lepiej niz 5 MHz osiagalne z Atmegi. Oczywiscie 3 takty
na skok boli w porownaniu z 2 dla Atmegi. Flash moze
dodac waitstates, ale nie powinno to byc wiecej niz 2
na skok (a optymistycznie 1). Wiec mysle ze nawet
przy pracy z flasha Cortex M0 powinien byc szybszy niz
Atmega.

> Dla STM32F10xx datasheet podaje ze GPIO przelacza do
> > 18 MHz
>

> Tak, GPIO jest r?wnie? powolne w du?ych procesorach z przyczyn niejasnych.

Jak rozumiem chodzi o ograniczenie EMI, a przy okazji mozna
uniknac problemow jak sciezki sa niedopasowane do pinow.
Ten STM wyzej ma konfigurowalna szybkosc, "high" ma miec
czasy narastania i opadania ponizej 5 ns przy malym obciazeniu,
"medium" na czasy ponizej 25 ns, ale to wystarczylo zeby
bramka LSTTL zlapala impulsy.

> > wyglada ze gdzis polowa czestoci zegara to maksimum na GPIO.
> > Wiec taki STM32F10xx powinien wygrac z AVR gdzies do 36 MHz.
>

> W moim projekcie jak zauwa?yle? wy?ej potrzeba jest r?wnie? 5V :) Mia?em
> nadzieje na dsPIC33, ale okaza?o si? ze tam zegar dzielony jest dalej
> przez 4 wi?c nic nie zyskam.

5V zasilanie czy zgodnosc z 5V? Jak rozumiem Z80 pracowal na
poziomach zblizonych do TTL i czesto byly do niego podpiete
uklady LSTTL. Ten STM ma produkowac syganaly zgodne z TTL
(pierwszy stopien licznika do zliczania impulsow na pinie
byl w LSTTL) i wytrzymac 5V na wejsciu, wiec jak mu dodasz
zasilacz 3.3 V to powinien dzialac na szynie Z80. Oczywiscie
trzeba by spradzic obciazalnosc, ale 8 mA na pin to chyba
podobnie do Z80...

A propo: uklady serii STM32F030 (podstawowe parametry takie
jak STM32F051) to najtansze procki ktore zauwazylem w
katalogu Farnella (nie szukalen dlugo wiec moze jest
cos tanszego).

--
Waldek Hebisch