"Dariusz Dorochowicz" <dadoro@_wp_._com_> wrote in message
news:53429065$0$2379$65785112@news.neostrada.pl...
> Tylko patrzę, patrzę, i o ile widzę go w DIP8, to już w SO8 czy czymś
> podobnym już nie widzę. No, ale TSSOP16 w ostateczności też może być.

Dzisiejsza młodzież to wybredna jakaś... ;-)

do góry

Sylwester Łazar <i...@a...pl> wrote:
>> Problem jest inny - Ty odpalasz silną maszynę uniwersalną mogącą Ci
>> pomóc zaprojektować stację kosmiczną lub silnik odrzutowy w CAD
>> i używasz jej do odczytania skrzynki pocztowej co może zrobić telefon.
>
> To pisz dalej z telefonu :-)
>
> Twój telefonowy czytnik newsów:
> "Microsoft Windows Live Mail 14.0.8117.416"

Nie ma problemu...
Poczta, usenet - i z komputera i z tableta i z telefonu.

Czy Ty jeszcze pamiętasz o co właściwie Ci chodzi w tej dyskusji?
Bo coraz bardziej się miotasz i na oślep strzelasz...

do góry

W dniu 2014-04-07 20:43, Michał Baszyński pisze:

> pytanie było o 8 nóżek, po co w takim dużo więcej?

No więc właśnie czasem 8 nóżek jest wystarczające, a zasobów jest mało.
wystarczy że masz dwa urządzenia łączące się jakimś protokołem
szeregowym, ale różnym, i nie masz możliwości ingerencji w nie. Tu
często brakuje właśnie RAMu, bo sama obsługa protokołów jest względnie
prosta i mieści się w całkiem niewielkim flaszu. Jeszcze więcej trzeba
kiedy masz protokoły operujące na tym samym medium fizycznym i chcesz
mieć urządzenie rozpoznające z czym ma do czynienia (bo czemu nie?) i
żeby cokolwiek zacząć musisz zebrać trochę próbek tego, co przychodzi.
Oczywiście zawsze można dać jakąś kostkę na SPI, ale w końcu nie o to
chodzi.

> BTW - jak się poszuka, to ARM-y (ale z trochę z większą ilością nóżek)
> są też robione w wersji 5V (a nie 3,3V), np. Kinetis E czy Toshiby.

Pamiętam, że były jakieś ARMy akceptujące 5V na IO, ale zasilane były z 3V.

Pozdrawiam

DD

do góry

W dniu 2014-04-08 00:58, Sylwester Łazar pisze:
>> Twoje rozważania na temat efektów kompilacji na PICach zostały
>> uzupełnione przez Janusza, który podał efekt kompilacji na AVR (1.6). Z
>> tego wynika, że mogą być kompilatory dające wydajniejszy kod niż te dla
>> PICów.
> Naprawdę ciężko z Tobą się rozmawia:
> Przecież masz tam specjalnie naznaczone, że porównuję do PIC18F
> Jak można wyciągnąć wniosek, że można porównywać kod C z jednego uC
> z kodem ASM z drugiego.

To po co te twoje porównania z wyliczeniem 1.6?

> Poza tym masz JASNO i WPROST napisane, że chodzi o CYKLE,
> a nie instrukcje.
> czyli to jest porównanie czasowe jednego uC z zupełnie innym.

No dobra w instrukcjach będzie 34/20 (w pętli głównej). Czyli 1.7

> No nie wiem jak musi pracować umysł człowieka, aby wyciągnąć wniosek,
> że w takim razie kod w C dla TEGO SAMEGO uC jest tylko 1,6x wolniejszy.

Założyłem, że kod asm na AVR będzie równie dobrze napisany jak ten twój
na PIC :)


> Przecież w tamtej dyskusji porównywane były zupełnie inne uC.
>
> Nie da sie z Tobą rozmawiać, bo wybrałeś sobie losowy współczynnik z
> dyskusji i usiłujesz wyciągnąć wniosek,
> że jak sobie napiszesz w C i skompilujesz to tylko 1,6x wolniej Ci to
> chodzi, niż napisałbyś
> na tym samym uC w ASM.

To ty się miotasz. Natchniony rozważaniami w innym wątku (na temat tego
czy warto przejść na bardziej rozbudowane uC i na programowanie w C)
wyruszyłeś na jakąś krucjatę i ogłosiłeś, że c jest 6 razy gorszy od
asm. Wrzucasz jeszcze teksty, że razy 16 i że przechodząc na c trzeba
przejść na co najmniej 10 razy szybszy procek żeby skompensować stratę
wydajności generowaną przez kompilator. A przy dokładniejszch analizach
wychodzi, że twój kod asemblerowy na PICu pędzonym 40MHz ma
prawdopodobnie taką samą wydajność jak skompilowany z c kod na ATmegę
32 taktowaną 16MHz. Procek wzbudził twoje uznanie, a jest to procek
który praktycznie znika już z rynku. Wygląda na to, że zahibernowałeś
się w tym PIC i asm i nie widzisz co się wokół dzieje.


>
> Toż to bzdura.
>
> Równie dobrze mógłbyś spojrzeć na temperaturę za oknem i jak ci wyjdzie 1,
> to oznacza, że
> nie warto pisać w ASM, bo to to samo co w C.
>
> Ale zaraz zaraz....
> A wiesz, że możesz mieć rację?
>
> Jakbyś Ty napisał niezbyt udany kod w asm i w C, to u Ciebie mogłoby być:
> Tc/Tasm = 1,6.
> Po co się ograniczać.
> Niech będzie i Tc/Tasm = 0,1
>
> I teraz już wiem.
> Ty już zrobiłeś sobie takie doświadczenie.
> Napisałeś w C. Wyszło Ci, że Twój kod sortuje Ci 5 liczb w 5 sekund,
> a potem napisałeś swój kod w ASM i wyszło Ci, że liczy w 50 sekund.
> Teraz rozumiem, dlaczego piszesz w C.
> Wyciągnąłeś prawidlowy wniosek ;-)

Wyzwałeś mnie od kłamców, stwierdziłeś, że ujadam jak pies, teraz
twierdzisz, że jestem beznadziejnym programistą. Poprawia ci to
samopoczucie i twoim zdaniem daje ci przewagę w dyskusji? Ciekawe czemu?
Przecież jesteś przekonany o swoich umiejętnościach, których ja nigdzie
nie kwestionowałem. Więc chyba nie jest budowanie nadwątlonego poczucia
własnej wartości przez poniżanie innych.
Może po prostu nie powinieneś pisać na newsy bo nie panujesz nad emocjami.

--
pozdrawiam
MD

do góry

"Dariusz Dorochowicz" <dadoro@_wp_._com_> wrote in message
news:53439e38$0$2246$65785112@news.neostrada.pl...
>> BTW - jak się poszuka, to ARM-y (ale z trochę z większą ilością nóżek)
>> są też robione w wersji 5V (a nie 3,3V), np. Kinetis E czy Toshiby.
>
> Pamiętam, że były jakieś ARMy akceptujące 5V na IO, ale zasilane były z
> 3V.

Sprawdziłem "pierwszy z brzegu",
czyli ten Cortex M4 co ja używam w projekcie:

"6.2 Pin description
I/O pins on the LPC408x/7x are 5V tolerant and have input hysteresis unless
otherwise
indicated in the table below. Crystal pins, power pins, and reference
voltage pins are not
5V tolerant. In addition, when pins are selected to be ADC inputs, they are
no longer 5V
tolerant and the input voltage must be limited to the voltage at the ADC
positive reference
pin (VREFP)."
http://www.nxp.com/documents/data_sheet/LPC408X_7X.p
df

do góry

W dniu 2014-04-08 08:59, Dariusz Dorochowicz pisze:

> Pamiętam, że były jakieś ARMy akceptujące 5V na IO, ale zasilane były z 3V.

takich jest dużo, STM32 (nie na wszystkich nogach), te z Texasa chyba też

--
Pozdr.
Michał

do góry

On Mon, 7 Apr 2014 23:17:20 +0200, Sylwester Łazar<i...@a...pl>
wrote:
> Drugi typ z kolei ma 1 000 MHz, 4 rdzenie, jest 100x droższy,
produkowany w
> 10x większym wolumenie,
> a nie potrafi uruchomić w ciągu 15 sekund skrzynki pocztowej,
> abym mógł przeczytać wiadomość w trybie ASCII i przyjemność z
korzystania
> jest marna
> i ciągle maleje.

To wina procesora, ze używasz (pewnie za karę) kiepski so z jeszcze
bardziej kiepskimi aplikacjami?

--
Marek

do góry

On 08/04/2014 00:58, Sylwester Łazar wrote:
>> Twoje rozważania na temat efektów kompilacji na PICach zostały
>> uzupełnione przez Janusza, który podał efekt kompilacji na AVR (1.6). Z
>> tego wynika, że mogą być kompilatory dające wydajniejszy kod niż te dla
>> PICów.
> Naprawdę ciężko z Tobą się rozmawia:
> Przecież masz tam specjalnie naznaczone, że porównuję do PIC18F
> Jak można wyciągnąć wniosek, że można porównywać kod C z jednego uC
> z kodem ASM z drugiego.
>
Zgrubsza ? Dlaczego nie. Nowoczene procesory, nawet male, sa
superscalarne i wykonuja instrukcje w pojedyncze cykle (to nie x51
gdzie byle g* zajmowala 50 cykli).

Upraszczajac przy dostatecznie duzej ilosci kodu mozna przyja, ze
ilosc instrukcji i taktowanie CPU determinuje czas wykonania programu.
ARM musialby miec srednio 10 cykli (a PIC 1) na instrukcje aby Twoje
przesuniecie przecinka mialo sens. A tak nie jest- zobacz sobie
ARM cycles per instruction.


> Poza tym masz JASNO i WPROST napisane, że chodzi o CYKLE,
> a nie instrukcje.
> czyli to jest porównanie czasowe jednego uC z zupełnie innym.
>
> No nie wiem jak musi pracować umysł człowieka, aby wyciągnąć wniosek,
> że w takim razie kod w C dla TEGO SAMEGO uC jest tylko 1,6x wolniejszy.
>
wyzej masz wyjasnienie.

> Przecież w tamtej dyskusji porównywane były zupełnie inne uC.
>
> Nie da sie z Tobą rozmawiać, bo wybrałeś sobie losowy współczynnik z
> dyskusji i usiłujesz wyciągnąć wniosek,
> że jak sobie napiszesz w C i skompilujesz to tylko 1,6x wolniej Ci to
> chodzi, niż napisałbyś
> na tym samym uC w ASM.
>
> Toż to bzdura.
>
Roznie bywa. Na zajeciach na PW juz nascie lat temu najszybszy okazal
sie program napisany w C(!). Powiedzmy ze na sparca sie trudno recznie
optymalizuje co nie nie zmienia sytuacji, iz w grupie 20 osob z ktorych
czesc implementowala algorytm w asm a czesc w C wygral ten napisany w C.
Fakt ze pisany byl "assemblerowo" z bardzo duzym uzycie niskopomziowych
operatorow ale nikt z reszty w asmemblerze nie napisal lepiej.
Naprawde pewne optymalizacje kompilatora wzbudzaly muj szacunek do
niego. Takze na malych uC mozna dlubac recznie i bedzie lepiej, na
duzych procesorach, sorry nie widze tego. Zbyt duzo mechanizow.
Czlowiek tego nie ogarnie. Sam fakt posiadania 32 128bitowych rejestrow
powoduje iz sie mozna pogubic. A cache i przewidywaniu skokow nie
bede nawet wspominal.


> Równie dobrze mógłbyś spojrzeć na temperaturę za oknem i jak ci wyjdzie 1,
> to oznacza, że
> nie warto pisać w ASM, bo to to samo co w C.
>
A warto ? Pytam powaznie bo mimo ze lubie assembler to nijak mi nie
wychodzi ze warto.


Pozdrawiam

Marek

do góry

On 08/04/2014 14:01, Mario wrote:
> W dniu 2014-04-08 00:58, Sylwester Łazar pisze:
>
> To ty się miotasz. Natchniony rozważaniami w innym wątku (na temat tego
> czy warto przejść na bardziej rozbudowane uC i na programowanie w C)
> wyruszyłeś na jakąś krucjatę i ogłosiłeś, że c jest 6 razy gorszy od
> asm. Wrzucasz jeszcze teksty, że razy 16 i że przechodząc na c trzeba
> przejść na co najmniej 10 razy szybszy procek żeby skompensować stratę
> wydajności generowaną przez kompilator. A przy dokładniejszch analizach
> wychodzi, że twój kod asemblerowy na PICu pędzonym 40MHz ma
> prawdopodobnie taką samą wydajność jak skompilowany z c kod na ATmegę
> 32 taktowaną 16MHz. Procek wzbudził twoje uznanie, a jest to procek
> który praktycznie znika już z rynku. Wygląda na to, że zahibernowałeś
> się w tym PIC i asm i nie widzisz co się wokół dzieje.
>
A czego oczekujesz od kogos kto ma wszytko napisane w asm na PICa ? :-)
To wlasnie najwieksza "zaleta" asmeblera ktora go IMHO calkowicie
dyskwalifikuje w komercyjnym uzyciu - nie zmienisz rodziny
mikrokontrolero chyba ze napiszesz sobie wszystko od nowa.

Pozdrawiam

Marek

do góry

ja pie..ole, to nie miało być takie długie :-)


jp


jacek pozniak wrote:

> Dobry wieczór wszystkim
>
> Na wstępie swego wywodu zaznaczam, że nie chcę wywoływać ideologicznych
> sporów, zależy mi tylko na merytorycznej dyskusji.:-)
>
> Sprawa ma sie następująco; od wielu lat programowałem uC ze stajni
> Microchipa, wcześniej 8080,Z80,51.
>
> PIC jest ok, ma fajne peryferia, etc.
>
> Od jakiegoś czasu zacząłem jednak kleić większe programy, często
> wykorzystujące jakieś fragmenty ściągnięte z internetu + własne archiwalne
> z innych czasów i platform (np. 51).
> Zawsze starałem się stosować do ANSII C.
> Ku mojemu zdumieniu, kompilacja za pomocą kopmpilatora HiTech (chodzi o
> nowsze wersje, obecnie to chyba jest Microchip) powoduje różne
> nieoczekiwane efekty, np. starsza wersja kompiluje OK; nowsza źle, lub
> odwrotnie. Działanie programu zależy od wersji kompilatora, starszą wersją
> działa, nowszą nie, lub odwrotnie.
> Prawdę mówiąc, jest to trochę irytujące.
> O ile program się pisze 'od zera' to mozna kombinować aby go uruchomić,
> ale jeśli wykorzystuje się kod źródłowy pisany kiedyś lub pisany przez
> kogoś innego, to raczej słabo.
>
> Czy Koledzy programujący uC również coś takiego zauważyli?
>
> Prawdę mówiąc skłania mnie ta sytuacja do przesiadki na AVR, który jak sie
> wydaje jest bardziej przyjazny dla kompilatora (jest na niego gcc)
>
> Proszę o jakieś opinie.
>
> Pozdrawiam
> jp

do góry