Marek wrote:

> Daj sobie spokój z 16F.

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

Pozdrawiam, Piotr

do góry

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

do góry

W dniu 2015-11-15 o 20:37, Marek pisze:
> On Sun, 15 Nov 2015 19:17:08 +0100, janusz_k <J...@o...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

do góry

Użytkownik "Piotr Wyderski" napisał w wiadomości grup
dyskusyjnych:n2d498$b4f$...@n...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.

do góry

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.

do góry

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?

do góry

On Mon, 16 Nov 2015 18:37:43 +0100, Piotr Wyderski
<p...@n...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

do góry

On Mon, 16 Nov 2015 19:24:57 +0100, Sebastian
Biały<h...@p...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

do góry

Marek pisze:
> On Mon, 16 Nov 2015 10:55:03 +0000, AlexY <a...@i...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.


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

do góry

Sebastian Bia?y <h...@p...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

do góry