Goto page 1, 2, 3 Next
Sebastian BiaĹy
Guest
Thu Sep 09, 2010 7:14 pm
Ile to juz czasu mineło? Ceny jakoś nie chcą spaść do sensownego
poziomu, niektóre procesory Atmela są absurdalnie drogie. SAM7S32
kosztuje tyle samo w TME co SAM7S256 czyli jakieś 3x drozej niż "przed
kryzysem". To jest wiecej niz przegięcie. Czy TME i inny wyprzedają
zapasy magazynowe czy to polityka Atmela skubania klienta?
Zaczynam coraz bardziej nerwowo rozglądac sie za czymś bardziej
stabilnym cenowo :/
Michoo
Guest
Thu Sep 09, 2010 7:42 pm
W dniu 09.09.2010 21:14, Sebastian Biały pisze:
Quote:
Ile to juz czasu mineło? Ceny jakoś nie chcą spaść do sensownego
poziomu, niektóre procesory Atmela są absurdalnie drogie. SAM7S32
kosztuje tyle samo w TME co SAM7S256 czyli jakieś 3x drozej niż "przed
kryzysem". To jest wiecej niz przegięcie. Czy TME i inny wyprzedają
zapasy magazynowe czy to polityka Atmela skubania klienta?
Mam wrażenie, że to 'duzi' sprzedawcy chcą zarobić - ceny wzrosły co
jest im wybitnie na rękę. Do tego firmy, które potrzebują większe ilości
rzuciły się robić zapasy.
Myślę, że ceny zaczną spadać jak pojawi się sporo "małych" sprzedawców z
niskimi cenami a dużą płynnością (bo większe sklepy mają 'drogie' zapasy
i jeszcze długie miesiące będą próbowali je sprzedać).
Quote:
Zaczynam coraz bardziej nerwowo rozglądac sie za czymś bardziej
stabilnym cenowo :/
Ja zacząłem spoglądać w stronę STM32 i LPC1000, ale ja hobbysta jestem.
--
Pozdrawiam
Michoo
entroper
Guest
Thu Sep 09, 2010 7:48 pm
Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:i6bbm5$s0f$1@news.onet.pl...
Quote:
Ile to juz czasu mineło? Ceny jakoś nie chcą spaść do sensownego
poziomu
ograniczyli wydobycie :)
e.
sundayman
Guest
Thu Sep 09, 2010 9:51 pm
TME to w ogóle mocno wkurzające jest czasem. Mam wrażenie, że niektóre ceny
to chyba z sufitu są...
Potrzebowałem na przykład kilkadziesiąt gniazd RCA , na panel - izolowanych.
Miałem je dorzucone do większego zamówienia, ale coś mnie tknęło, że mi suma
wyszła spora.
Patrzę - i mało mnie szlag nie trafił. W TME - 4.50 (brutto) za sztukę. W
sklepie w detalu - 2.50 dokładnie takie samo.
Cholerycznie trzeba się pilnować.
Piotr \"Curious\" Slawins
Guest
Thu Sep 09, 2010 10:15 pm
Sebastian Biały wrote:
Quote:
Ile to juz czasu mineło? Ceny jakoś nie chcą spaść do sensownego
poziomu, niektóre procesory Atmela są absurdalnie drogie. SAM7S32
kosztuje tyle samo w TME co SAM7S256 czyli jakieś 3x drozej niż "przed
kryzysem". To jest wiecej niz przegięcie. Czy TME i inny wyprzedają
zapasy magazynowe czy to polityka Atmela skubania klienta?
Zaczynam coraz bardziej nerwowo rozglądac sie za czymś bardziej
stabilnym cenowo :/
no wlasnie... a moze jakas alternatywa?
np. zakladajac ze mamy zrodlowki w C programow do atmegi32 ,
co wybrac zeby bylo podobne cenowo i dalo sie wlutowac w te same plytki?
przyznam ze atmelami interesuje sie glownie ze wzgledu na to ze sa (byly)
ogolnodostepne i tanie, reszta 'parametrow' jest drugorzedna - no moze ilsoc
ramu i sposob adresowania jest dosc silnym argumentem... a raczej proporcja
ilosc ramu vs cena...
--
Mario
Guest
Thu Sep 09, 2010 10:18 pm
W dniu 2010-09-09 23:51, sundayman pisze:
Quote:
TME to w ogóle mocno wkurzające jest czasem. Mam wrażenie, że niektóre ceny
to chyba z sufitu są...
Potrzebowałem na przykład kilkadziesiąt gniazd RCA , na panel - izolowanych.
Miałem je dorzucone do większego zamówienia, ale coś mnie tknęło, że mi suma
wyszła spora.
Patrzę - i mało mnie szlag nie trafił. W TME - 4.50 (brutto) za sztukę. W
sklepie w detalu - 2.50 dokładnie takie samo.
Cholerycznie trzeba się pilnować.
Niektóre rzeczy masz prawie dwa razy tańsze w Elfa niż w TME. A kiedyś
tak krytykowałem tu na grupie Elfę za drożyznę :)
--
Pozdrawiam
MD
entroper
Guest
Thu Sep 09, 2010 10:30 pm
Użytkownik "sundayman" <sundayman@poczta.onet.pl> napisał w wiadomości
news:i6bksn$lin$1@news.onet.pl...
Quote:
Patrzę - i mało mnie szlag nie trafił. W TME - 4.50 (brutto) za sztukę.
W
sklepie w detalu - 2.50 dokładnie takie samo.
Typowy sposób "rozwoju" polskich firm: najpierw się przykładamy a jak już
troszkę umościmy się na rynku, to tniemy sobie w ch.. (bo jesteśmy
"renomowani", jakby w takim handelku to coś znaczyło). A potem zdziwienie,
że klient poszedł do innej firmy (która jest w fazie przykładania się).
Przerobione na wielu przykładach. Wierność jednej firmie u nas nie ma
szans się przyjąć...
e.
Marcin Wasilewski
Guest
Thu Sep 09, 2010 11:18 pm
Użytkownik "Piotr "Curious" Slawinski" <curious@bwv190.internetdsl.tpnet.lp>
napisał w wiadomości news:4c895c97$0$22810$65785112@news.neostrada.pl...
Quote:
np. zakladajac ze mamy zrodlowki w C programow do atmegi32 ,
co wybrac zeby bylo podobne cenowo i dalo sie wlutowac w te same plytki?
ATMEGA16 i 644P. Przy czym 644P ma np. rozbite rejestry liczników (bardziej
rozbudowane) i flagi, które w ATMEGA16/32 są w jednym rejestrze, w 644P są w
dwóch rejestrach, wektory przerwań też się pozmieniały. Tak więc
najbezpieczniejsza jest
tylko zmiana pomiędzy ATMEGA16 i ATMEGA32.
Adam Dybkowski
Guest
Thu Sep 09, 2010 11:42 pm
W dniu 2010-09-10 00:15 Piotr "Curious" Slawinski napisał(a):
Quote:
Zaczynam coraz bardziej nerwowo rozglądac sie za czymś bardziej
stabilnym cenowo :/
no wlasnie... a moze jakas alternatywa?
np. zakladajac ze mamy zrodlowki w C programow do atmegi32 ,
co wybrac zeby bylo podobne cenowo i dalo sie wlutowac w te same plytki?
Nie pisane od razu z myślą o przenośności?
Czyli wszędzie potworki typu printf_P, strcpy_P, PSTR itd.
Przydałaby się warstwa "kompatybilności" aby to uruchomić na ARMie.
A jeżeli w programie jest wiele odwołań do I/O to trzeba będzie zmienić
diametralnie.
Dużo lepiej gdy program używał systemu operacyjnego (np. Nut/OS) - wtedy
warstwa sprzętu jest wyraźnie oddzielona a kompatybilność PSTR np.
zapewniają #define w plikach nagłówkowych systemu. Małym nakładem pracy
można wtedy przenieść program np. z AVRa na ARMa. A ARMów jak mrówków -
co się nie obejrzysz. Zresztą zobacz jaki stos $$$ zarobiła firma ARM w
ostatnim roku - a sami nie produkują scalaków, jedynie sprzedają licencje.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
Adam Dybkowski
Guest
Thu Sep 09, 2010 11:44 pm
W dniu 2010-09-10 01:18 Marcin Wasilewski napisał(a):
Quote:
np. zakladajac ze mamy zrodlowki w C programow do atmegi32 ,
co wybrac zeby bylo podobne cenowo i dalo sie wlutowac w te same plytki?
ATMEGA16 i 644P. Przy czym 644P ma np. rozbite rejestry liczników
(bardziej rozbudowane) i flagi, które w ATMEGA16/32 są w jednym
rejestrze, w 644P są w dwóch rejestrach, wektory przerwań też się
pozmieniały. Tak więc najbezpieczniejsza jest
tylko zmiana pomiędzy ATMEGA16 i ATMEGA32.
Ale to ciągle Atmel. Czyli za miesiąc może być ten sam problem z
dostępnością, tym razem ATmega644P zamiast ATmega32. Sugeruję raczej
rozejrzeć się w środowisku małych ARMów.
Dla porównania w cenie ATmegi128 można kupić dużo potężniejszego ARMa i
z większym RAMem. W takiej samej obudowie.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
Piotr \"Curious\" Slawins
Guest
Fri Sep 10, 2010 12:00 am
Adam Dybkowski wrote:
Quote:
W dniu 2010-09-10 00:15 Piotr "Curious" Slawinski napisał(a):
Zaczynam coraz bardziej nerwowo rozglądac sie za czymś bardziej
stabilnym cenowo :/
no wlasnie... a moze jakas alternatywa?
np. zakladajac ze mamy zrodlowki w C programow do atmegi32 ,
co wybrac zeby bylo podobne cenowo i dalo sie wlutowac w te same plytki?
Nie pisane od razu z myślą o przenośności?
pisane. bardziej w pytaniu chodzilo nie o to jak to zrobic, tylko
ew. ktore z armow podobnych cenowo da sie wlutowac w te same plytki
(sa jak najbardziej pin-compatible), ew czy nie ma jakichs gotowych
rozwiazan typu np. 'emulator' amtega32 .... dla amatorow atmegi w obudowach
dip byly np. bardzo ciekawym rozwiazaniem... prosto sie to lutuje...
--
Piotr \"Curious\" Slawins
Guest
Fri Sep 10, 2010 12:02 am
Adam Dybkowski wrote:
Quote:
W dniu 2010-09-10 01:18 Marcin Wasilewski napisał(a):
np. zakladajac ze mamy zrodlowki w C programow do atmegi32 ,
co wybrac zeby bylo podobne cenowo i dalo sie wlutowac w te same plytki?
ATMEGA16 i 644P. Przy czym 644P ma np. rozbite rejestry liczników
(bardziej rozbudowane) i flagi, które w ATMEGA16/32 są w jednym
rejestrze, w 644P są w dwóch rejestrach, wektory przerwań też się
pozmieniały. Tak więc najbezpieczniejsza jest
tylko zmiana pomiędzy ATMEGA16 i ATMEGA32.
Ale to ciągle Atmel. Czyli za miesiąc może być ten sam problem z
dostępnością, tym razem ATmega644P zamiast ATmega32. Sugeruję raczej
rozejrzeć się w środowisku małych ARMów.
Dla porównania w cenie ATmegi128 można kupić dużo potężniejszego ARMa i
z większym RAMem. W takiej samej obudowie.
dokladnie o to chodzi.
--
Marcin Wasilewski
Guest
Fri Sep 10, 2010 12:44 am
Użytkownik "Piotr "Curious" Slawinski" <curious@bwv190.internetdsl.tpnet.lp>
napisał w wiadomości news:4c8975b1$0$22798$65785112@news.neostrada.pl...
Quote:
Dla porównania w cenie ATmegi128 można kupić dużo potężniejszego ARMa i
z większym RAMem. W takiej samej obudowie.
dokladnie o to chodzi.
Ale zdajesz sobie sprawę, że nawet mając źródła w C program sam Ci się
nie przeportuje na inny procek. Pozostaną wszelkie odwołania do rejestrów
funkcyjnych, które będziesz musiał zmieniać sam. W rozbudowanym programie
używającym timerów, I2C itp. drobiazgi przeportowanie z ATMEGA16/32 ->
potrafi zająć kilka godzin (szczególnie gdy robi to się pierwszy raz), a co
dopiero na inny procek z całkiem inną organizacją urządzeń I/O.
Marcin Wasilewski
Guest
Fri Sep 10, 2010 12:50 am
Użytkownik "Marcin Wasilewski" <jakis@adres.pewnie.je.st> napisał w
wiadomości news:i6bv0h$ttf$1@news.task.gda.pl...
Quote:
używającym timerów, I2C itp. drobiazgi przeportowanie z ATMEGA16/32 -
Miało być ATMEGA16/32 -> 644P
Mario
Guest
Fri Sep 10, 2010 2:01 am
W dniu 2010-09-10 01:42, Adam Dybkowski pisze:
Quote:
W dniu 2010-09-10 00:15 Piotr "Curious" Slawinski napisał(a):
Zaczynam coraz bardziej nerwowo rozglądac sie za czymś bardziej
stabilnym cenowo :/
no wlasnie... a moze jakas alternatywa?
np. zakladajac ze mamy zrodlowki w C programow do atmegi32 ,
co wybrac zeby bylo podobne cenowo i dalo sie wlutowac w te same plytki?
Nie pisane od razu z myślą o przenośności?
Czyli wszędzie potworki typu printf_P, strcpy_P, PSTR itd.
Przydałaby się warstwa "kompatybilności" aby to uruchomić na ARMie.
A jeżeli w programie jest wiele odwołań do I/O to trzeba będzie zmienić
diametralnie.
Dużo lepiej gdy program używał systemu operacyjnego (np. Nut/OS) - wtedy
warstwa sprzętu jest wyraźnie oddzielona a kompatybilność PSTR np.
zapewniają #define w plikach nagłówkowych systemu. Małym nakładem pracy
można wtedy przenieść program np. z AVRa na ARMa. A ARMów jak mrówków -
co się nie obejrzysz. Zresztą zobacz jaki stos $$$ zarobiła firma ARM w
ostatnim roku - a sami nie produkują scalaków, jedynie sprzedają licencje.
No nie tylko. Zdaje się ze kupili sobie Keila.
--
Pozdrawiam
MD
Goto page 1, 2, 3 Next