NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Gdzie znaleźć płytki uruchomieniowe z ATMega128? Prototypowanie i alternatywy
Waldek Hebisch
Guest
Guest
Wed Apr 22, 2026 6:25 am
heby <heby@poczta.onet.pl> wrote:
Quote:
On 20/04/2026 17:10, Waldek Hebisch wrote:
Niestety z 5V to w sumie, poza Kinetis, nie ma nic :/
Chińczycy mają całą masę ARM i RISC-V zasilanych z 5V. Np. procki
z WCH: CH32F103 (ARM), CH32V103 (RISCV) czy malutki CH32V003 (RISCV).
Maja też z rdzeniem 6502 (serio, MegaWin).
Tylko co z tego. Cieżko sie bazuje na chińskich produktach, dzisiaj są,
jutro nie ma. ZNajomy pracował w firmie, która wstawiła do swoich
produktów chińskie cpu. Pewnego dnia przyszedł mail, że dostawy nie
będzie bo wstrzymali produkcję na zawsze. Baibai.
Niestety z 5V to w sumie, poza Kinetis, nie ma nic :/
Chińczycy mają całą masę ARM i RISC-V zasilanych z 5V. Np. procki
z WCH: CH32F103 (ARM), CH32V103 (RISCV) czy malutki CH32V003 (RISCV).
Maja też z rdzeniem 6502 (serio, MegaWin).
Tylko co z tego. Cieżko sie bazuje na chińskich produktach, dzisiaj są,
jutro nie ma. ZNajomy pracował w firmie, która wstawiła do swoich
produktów chińskie cpu. Pewnego dnia przyszedł mail, że dostawy nie
będzie bo wstrzymali produkcję na zawsze. Baibai.
Chińczycy nie mają monpolu na wstrzymanie produkcji, zachodnie
firmy też to robią. W przypadku procków wyżej pozytywny aspekt
jest że szerg firm robi w dużym stopniu zgodne procki. Typowa
wymówka do użycia 8051 była taka że są niezależne źródła.
Teraz masz niezależne źródła dla ARM i RISC-V, gdzie nie tylko
rdzeń ale peryferia i pinologia się zgadza. Szukałem w sieci
informacji o prockach zgodnych z F103, wyszło mi że co najmniej
12 chińskich firm robi takie procki. Niektóre stwierdzą że im
coś nie wychodzi i wstrzymają produkcję, ale jest ich na tyle
dużo że któreś zostaną.
Quote:
Trochę szkoda że się nierozwinęły, rdzeń 8-bit dalej jest użyteczny, a
przy ~100MHz mogłby jeszcze skopać tyłek ARMom.
Przy danym zegarze rdzeń 8-bit przegra na obliczeniach z rdzeniem
32-bitowym.
Zależy co liczy. Większe słowo nie zawsze oznacza większą prędkość do
zastosowań uC. Jakbyśmy liczyli coś matematycznie to może, ale jak
sterujemy GPIO, to niekoniecznie. Tylko komplikuje rdzeń.
przy ~100MHz mogłby jeszcze skopać tyłek ARMom.
Przy danym zegarze rdzeń 8-bit przegra na obliczeniach z rdzeniem
32-bitowym.
Zależy co liczy. Większe słowo nie zawsze oznacza większą prędkość do
zastosowań uC. Jakbyśmy liczyli coś matematycznie to może, ale jak
sterujemy GPIO, to niekoniecznie. Tylko komplikuje rdzeń.
Obliczenia to rozumiem że coś się liczy: np. przeliczasz wynik
z ADC uwzględniając charakterystykę termistora.
Dłuższe słowo pomaga w konfiguracji urządzeń, nie ma zabawy w
stylu napierw dolna połówka potem górna (czy odwrotnie).
Co do komplikacji: potok wykonujący 32-bitowe instrukcje
będzie większy, z grubsza 4 razy. Ale część sterująca nie
musi się skomplikować. Część sterująca się komplikuje jak
chcesz podkręcić zegar, niezależnie czy to procek 8-bitowy
czy 32-bitowy. Przy tym ATmega by choć trochę zyskać na
szybkości ma szerg operacji 16-bitowych, a to oznacza że
de fakto część wykonawcza musi być przygotowana do operacji
16-bitowych (tzn. albo sztuczki z multipleksowanie i tracisz
na zegarze, albo dajesz dość sprzętu). 8-botowy zestaw
instrukcji oznacza że nie możesz w pełni użyć 16-bitowego
sprzętu potrzebngo by odpowiednie istrukcje działały z
maksymalną prędkością.
W MCU masz pady wejścia-wyjścia (logicznie trywialne, ale
zajmują miejsce), flasz, RAM, układy We/Wy których rozmiar
nie zależy od tego czy to procek 8-bitowy czy 32-bitowy.
Część sterująca rdzenia też na podobny rozmiar. Więc
zwiększenie rozmiaru MCU procentowo nie jest duże.
Quote:
A jak chcesz zegar 100 MHz to trzeba buforowaną
szynę i np. machanie pinami będzie w najlepszym razie tak
samo szybkie jak przy rdzeniu 32-bitowym.
Byle ARM pozwala na machanie znacznie szybciej niż AVRy. Chyba tylko z
wyjątkiem SAM7, gdzie "udało" mi się osiągnąć mniej niż AVR. Ale prawda
taka, że machaniem GPIO to się powinny zajmować dedykowane kawałki
hardware, a nie rdzeń cpu.
szynę i np. machanie pinami będzie w najlepszym razie tak
samo szybkie jak przy rdzeniu 32-bitowym.
Byle ARM pozwala na machanie znacznie szybciej niż AVRy. Chyba tylko z
wyjątkiem SAM7, gdzie "udało" mi się osiągnąć mniej niż AVR. Ale prawda
taka, że machaniem GPIO to się powinny zajmować dedykowane kawałki
hardware, a nie rdzeń cpu.
Przy tym samym zegarze AVRy często machają szybciej. Ale ta
szybkość bazuje na tym że mają wolniejszy zegar: elektronika
ma swój czas propagacji i wyrobi się przy wolnym zegarze. Jak
podkręcasz zegar to trzeba wrzucić bufory.
Przy tym mi chodziło też o trochę inne efekty. Nie znam procka
gdzie flasz chodzi z zegarem istotnie większym niż 40 MHz.
Klasyczna ATmega z zegarem 20 MHz bez problemu może pobierać
instrukcje bezpośrednio z flasza. Podobnie chińskie klony
przy 32 MHz. Ale 100 MHz wymaga bufora i np. skoki zajmą
więcej cykli niż w procku z zegarem 20 MHz.
Quote:
Procki 8-bit mogły mieć sens przy procesie 180 nm. Ale jak
robi się procek na procesie 45 nm to 8-bit daje znikome oszczędności
z powodu mniejszego rdzenia, a duże straty z powodu niższej
wydajności.
ARM dzisiaj daje przede wszystkim opłaty licencyjne. To jest bardzo
bolesne dla wielu producentów.
robi się procek na procesie 45 nm to 8-bit daje znikome oszczędności
z powodu mniejszego rdzenia, a duże straty z powodu niższej
wydajności.
ARM dzisiaj daje przede wszystkim opłaty licencyjne. To jest bardzo
bolesne dla wielu producentów.
Nie wiem jak bolesne. Jak patrzyłem to najtańsze ARM było w
podobnej cenie jak RISC-V. Bardzo możliwe że obecność RISC-V
na rynku zmusiła ARM do bardziej elastyczej polityki opłat.
Quote:
AVR jest stabilny, ma od groma narzędzi,
trywialny rdzeń, Atmel/Microchip mógłby zawalczyć o kawałek rynku.
trywialny rdzeń, Atmel/Microchip mógłby zawalczyć o kawałek rynku.
Microchip miał wydaje się że dobry rdzeń 32-bitowy (używjący
"skompresowny" wariant instrukcji MIPS). Ale wygląda że byli
zbyt chciwi i dziś chyba nikt nie chce używać tego rdzenia.
Microchip ma swoich klientów, ale na szerszą ekspansję ich własnych
(wliczając w to AVR) architektur bym nie liczył. Może trochę
inaczej: jak się płaci tak jak wymaga Microchip to w porównaniu
koszt licencji ARM nie boli.
Quote:
Raczej widziałbym zastępowanie RISCem, a nie ARMem. Na ARMy niestety
jest jakaś moda, bo sam cpu jest upierdliwy (z kilkanaście subsetów
instrukcji itp guano).
jest jakaś moda, bo sam cpu jest upierdliwy (z kilkanaście subsetów
instrukcji itp guano).
W miarę nowoczesne rdzenie do MCU chyba wszystkie potrafią wykonywać
instrukcje Cortex-M0, czyli jak chcesz pisać wspólny kod w
assemblerze dla różnych procków to się w miarę łatwo da. A jak
piszesz w C, to różne podzbiory instrukcji są problemem dla
ludzi piszących kompilator, ale gcc (a teraz chyba też clang)
ma dobre wsparcie.
Jak porównujesz z innymi to ja trochę zerknełem na AVR, różne
modele wydają się mieć różnice w zestawie instrukcji co najmniej
tak duże jak różne Cortex-y (wybierając inny typ procka rozmiar
programu zmieniał się bardziej).
Jak mówimy o RISC-V to podzbiory istrukcji są potencjanie najgorszą
cechą tej architektury. Na dziś jest zdefiniowane całkiem sporo
podzbiorów które mogą, ale nie muszą być obecne w danym procku.
Każdy producent może dodać własne rozszerzenia. Potencjalnie
może być znacznie gorzej niż z ARM. Miejmy nadzieję że rynek
ograniczy ilość wariantów.
Nie wiem co "itp guano" ma oznaczać. Podstawowa filozofia ARM
i RISC-V jest podobna, są dość istotne różnice jak się patrzy
na konkrety, ale nie bardzo widzę techniczne powody by w konteście
MCU mocno preferować jedną przeciw drugiej (przy tym w kontekście
nowoczesnych MCU ARM to różne Cortex-M czy jak to teraz nazywają).
Jeszcze jedno, ja bym powiedział że na RISC-V jest moda.
ARM to klasyka.
--
Waldek Hebisch
heby
Guest
Guest
Wed Apr 22, 2026 7:45 am
On 22/04/2026 06:25, Waldek Hebisch wrote:
Quote:
Chińczycy nie mają monpolu na wstrzymanie produkcji, zachodnie
firmy też to robią.
firmy też to robią.
Ale nie kończą z dnia na dzień. Obowiązują pewne plany produkcyjne.
Quote:
rdzeń ale peryferia i pinologia się zgadza. Szukałem w sieci
informacji o prockach zgodnych z F103, wyszło mi że co najmniej
12 chińskich firm robi takie procki.
informacji o prockach zgodnych z F103, wyszło mi że co najmniej
12 chińskich firm robi takie procki.
Dokładnie, STM32 w wersji podrabianej GD32. Wymiana "na inny" wymagała
przeprojektowania płytki, co posłusznie zrobiono.
Quote:
Zależy co liczy. Większe słowo nie zawsze oznacza większą prędkość do
zastosowań uC. Jakbyśmy liczyli coś matematycznie to może, ale jak
sterujemy GPIO, to niekoniecznie. Tylko komplikuje rdzeń.
Obliczenia to rozumiem że coś się liczy: np. przeliczasz wynik
z ADC uwzględniając charakterystykę termistora.
zastosowań uC. Jakbyśmy liczyli coś matematycznie to może, ale jak
sterujemy GPIO, to niekoniecznie. Tylko komplikuje rdzeń.
Obliczenia to rozumiem że coś się liczy: np. przeliczasz wynik
z ADC uwzględniając charakterystykę termistora.
W zupełności wystarczy 8 bit + lookuptable do tak prostej rzeczy. Co
innego obliczenia matematyczne typu PID, FFT czy Kalman. Czy jednak
wszystkie aplikacje embedded wymagają takich rzeczy? Wiele z nich to
tylko wypasione miganie diodą.
Quote:
Dłuższe słowo pomaga w konfiguracji urządzeń, nie ma zabawy w
stylu napierw dolna połówka potem górna (czy odwrotnie).
stylu napierw dolna połówka potem górna (czy odwrotnie).
Owszem, ale dokładnie odwotny argument można mieć do 32 bitów: do
sterowania pięcioma GPIO nie trzeba męczyć się z ARMowymi debilizmami z
oklic ładowania stałych z Flash.
Quote:
Co do komplikacji: potok wykonujący 32-bitowe instrukcje
będzie większy, z grubsza 4 razy.
będzie większy, z grubsza 4 razy.
Wiele rzeczy będzie wiekszych bez sensu. Rejestry. Magistrale.
Interfejsy. To kosztuje krzem. A jeszcze jak chcesz mieć to
zaprojektowane do zastosowań niskiej mocy...
Quote:
W MCU masz pady wejścia-wyjścia (logicznie trywialne, ale
zajmują miejsce), flasz, RAM, układy We/Wy których rozmiar
nie zależy od tego czy to procek 8-bitowy czy 32-bitowy.
Część sterująca rdzenia też na podobny rozmiar. Więc
zwiększenie rozmiaru MCU procentowo nie jest duże.
zajmują miejsce), flasz, RAM, układy We/Wy których rozmiar
nie zależy od tego czy to procek 8-bitowy czy 32-bitowy.
Część sterująca rdzenia też na podobny rozmiar. Więc
zwiększenie rozmiaru MCU procentowo nie jest duże.
W przypadku ARMa, machanie kilkoma GPIO zajmie o wiele więcej flasha niż
w AVR. To wynika ze specyfiki kodu.
Quote:
Byle ARM pozwala na machanie znacznie szybciej niż AVRy. Chyba tylko z
wyjątkiem SAM7, gdzie "udało" mi się osiągnąć mniej niż AVR. Ale prawda
taka, że machaniem GPIO to się powinny zajmować dedykowane kawałki
hardware, a nie rdzeń cpu.
Przy tym samym zegarze AVRy często machają szybciej.
wyjątkiem SAM7, gdzie "udało" mi się osiągnąć mniej niż AVR. Ale prawda
taka, że machaniem GPIO to się powinny zajmować dedykowane kawałki
hardware, a nie rdzeń cpu.
Przy tym samym zegarze AVRy często machają szybciej.
Zależy to chyba od tego gdzie wykonuje się kod. ARMy mają zaletę, że
może lecieć z RAMu i właśnie w SAM7 jest taka bzdura, że kod należy
przepisać do RAM z Flash, aby był szybszy. Kolejna komplikacja. Wtedy
AVR nie podskoczy. Pewnie dotyczy to wielu ARMów.
Quote:
Przy tym mi chodziło też o trochę inne efekty. Nie znam procka
gdzie flasz chodzi z zegarem istotnie większym niż 40 MHz.
gdzie flasz chodzi z zegarem istotnie większym niż 40 MHz.
I znowu: jeśli flash wydłubywał by słowa 32 bitowe, to 8-bit cpu mógłby
z tego skorzystać jako prymitywnego prefetch. Dla ARMa też się da,
przecięz po to zrobili tryb Thumb, ale on nie jest 8-bit.
Quote:
ARM dzisiaj daje przede wszystkim opłaty licencyjne. To jest bardzo
bolesne dla wielu producentów.
Nie wiem jak bolesne. Jak patrzyłem to najtańsze ARM było w
podobnej cenie jak RISC-V. Bardzo możliwe że obecność RISC-V
na rynku zmusiła ARM do bardziej elastyczej polityki opłat.
bolesne dla wielu producentów.
Nie wiem jak bolesne. Jak patrzyłem to najtańsze ARM było w
podobnej cenie jak RISC-V. Bardzo możliwe że obecność RISC-V
na rynku zmusiła ARM do bardziej elastyczej polityki opłat.
To też, ale też rynek małych CPU jest ciasny. Nie ma sensu produkować
czegoś 2x tańszego.
Ponadto są szacunki, że arm->riscv oznaca dla niektórych firm redukcję
10-20% kosztów. https://en.iclabcn.com/2221.html
Quote:
AVR jest stabilny, ma od groma narzędzi,
trywialny rdzeń, Atmel/Microchip mógłby zawalczyć o kawałek rynku.
Microchip miał wydaje się że dobry rdzeń 32-bitowy (używjący
"skompresowny" wariant instrukcji MIPS).
trywialny rdzeń, Atmel/Microchip mógłby zawalczyć o kawałek rynku.
Microchip miał wydaje się że dobry rdzeń 32-bitowy (używjący
"skompresowny" wariant instrukcji MIPS).
To nie ta nisza. Duże PICe były... duże.
Quote:
Jak porównujesz z innymi to ja trochę zerknełem na AVR, różne
modele wydają się mieć różnice w zestawie instrukcji co najmniej
tak duże jak różne Cortex-y (wybierając inny typ procka rozmiar
programu zmieniał się bardziej).
modele wydają się mieć różnice w zestawie instrukcji co najmniej
tak duże jak różne Cortex-y (wybierając inny typ procka rozmiar
programu zmieniał się bardziej).
Głównie dotyczą obslugi większego RAM/ROM. Nie ma sytuacji, że masz
*różne* zestawy *wszystkich* instrukcji i jeszcze sieczkę w postaci: w
przerwaniu takie a w runtime siakie.
Quote:
Jak mówimy o RISC-V to podzbiory istrukcji są potencjanie najgorszą
cechą tej architektury. Na dziś jest zdefiniowane całkiem sporo
podzbiorów które mogą, ale nie muszą być obecne w danym procku.
Każdy producent może dodać własne rozszerzenia. Potencjalnie
może być znacznie gorzej niż z ARM. Miejmy nadzieję że rynek
ograniczy ilość wariantów.
cechą tej architektury. Na dziś jest zdefiniowane całkiem sporo
podzbiorów które mogą, ale nie muszą być obecne w danym procku.
Każdy producent może dodać własne rozszerzenia. Potencjalnie
może być znacznie gorzej niż z ARM. Miejmy nadzieję że rynek
ograniczy ilość wariantów.
AVR nie ma się tu czego wstydzić.
Quote:
Nie wiem co "itp guano" ma oznaczać.
ARM projektowany był w czasach schyłku dominacji 8-bit, choć udawał że
czerpał z większych architektur. Mam wrażenie, że to jakaś hybryda (mały
jak 8-bit, wypasiony jak RISC). Po jakimś czasie zorientowano się, że
pewne elementy, jak ładowanie stałej immediate, są do d... wiec pojawiły
się workaroundt typu movw/movt, po czym stwierdzono że to też słabe wiec
movz.. itp. Ktoś zauważył, że gęstośc kodu jest przeciętna, więc
wymyślono thumba i to nie jednego. Warunkowość? Lepiej zastąpić to CSEL
itp. To jest procesor z dużą ilością poprawek od czasu powstania, w tym
łamiących kompatybilność. Ktoś powie, że to rozwój i ma prawo. Ktoś
powie, że nie pisze się w asm i ma prawo.
Quote:
Jeszcze jedno, ja bym powiedział że na RISC-V jest moda.
ARM to klasyka.
RISC-V wydaje się być kandydatem do skopania d... ARMowi. Jest coraz
ARM to klasyka.
RISC-V wydaje się być kandydatem do skopania d... ARMowi. Jest coraz
bardziej popularny w krajach, które przecież nie muszą się szarpać z
licencjonowaniem rdzenia, co daje do myślenia. Ponado marketshare rośnie
szybciej niż ARM. Obecnie optymiści widzą już 25% rynku embedded cpu
stojącego na RISC-V i siedmiokrotny wzrost wartości do 2032. ARM z dnia
na dzień stanie się tylko inercją napędzaną kipesko napisanymi
projektami, których nie da się migrować.
J.F
Guest
Guest
Wed Apr 22, 2026 9:12 am
On Wed, 22 Apr 2026 08:30:33 +0200, heby wrote:
Quote:
On 22/04/2026 06:25, Waldek Hebisch wrote:
Chińczycy nie mają monpolu na wstrzymanie produkcji, zachodnie
firmy też to robią.
Ale nie kończą z dnia na dzień. Obowiązują pewne plany produkcyjne.
Chińczycy nie mają monpolu na wstrzymanie produkcji, zachodnie
firmy też to robią.
Ale nie kończą z dnia na dzień. Obowiązują pewne plany produkcyjne.
Może być tak, że produkowali przez tydzień i wyprodukowali dużo, a
następna partia ... jak klient zamówi, a zamówien innych fabryka ma na
rok ...
J.
WP
Guest
Guest
Wed Apr 22, 2026 9:18 am
W dniu 2026-04-18 o 08:12, pytający pisze:
Quote:
Witam,
mam do odpalenia urządzenie w fazie prototypu i szukam jakiejś płytki
uruchomieniowej z tym właśnie procesorem. I normalnie posucha.
Tylko jeden rodzaj płytki i to produkowanej w chinach. Na Gotronik, są
fajne z dodatkowym polem lutowniczym ale już niedostępne. Chyba będę
musiał kupić to co jest + dodatkowa płytka uniwersalna, bo stykowa do
niczego się nie nadaje.
Robert
mam do odpalenia urządzenie w fazie prototypu i szukam jakiejś płytki
uruchomieniowej z tym właśnie procesorem. I normalnie posucha.
Tylko jeden rodzaj płytki i to produkowanej w chinach. Na Gotronik, są
fajne z dodatkowym polem lutowniczym ale już niedostępne. Chyba będę
musiał kupić to co jest + dodatkowa płytka uniwersalna, bo stykowa do
niczego się nie nadaje.
Robert
Hej, specjalnie dla Ciebie wersja limitowana
https://tinyurl.com/Adapter-ATMEGA128
Pozdrawiam
Marek
Guest
Guest
Wed Apr 22, 2026 10:01 am
On Wed, 22 Apr 2026 08:30:33 +0200, heby <heby@poczta.onet.pl> wrote:
Quote:
To nie ta nisza. Duże PICe były... duże.
Co masz na myśli? Za dużo RAM? Za dużo flash? Za dużo pinów? To
ostatnie rozwiazuje pic32mx 1xx/2xx dostępny w 28 pinowej
dip/qfn/ssop.
Przeraża Cię Pic32mzda z 32MB RAM w strukturze? Fakt tqfp164 trochę
upierdliwe w lutowaniu ale za to pełny mmu i możliwość urchomienia
Linuxa/BSD czy niezapomniane eksperymenty z tworzeniem własnego OSa.
--
Marek
heby
Guest
Guest
Wed Apr 22, 2026 10:13 am
On 22/04/2026 10:01, Marek wrote:
Quote:
To nie ta nisza. Duże PICe były... duże.
Co masz na myśli? Za dużo RAM? Za dużo flash? Za dużo pinów? To ostatnie
rozwiazuje pic32mx 1xx/2xx dostępny w 28 pinowej dip/qfn/ssop.
Co masz na myśli? Za dużo RAM? Za dużo flash? Za dużo pinów? To ostatnie
rozwiazuje pic32mx 1xx/2xx dostępny w 28 pinowej dip/qfn/ssop.
Te procesory odstraszały programistów od migania diodami. Nie
potrzebujesz 32 bitów do tego. Są skomplikowane i duże jak na potrzeby
wielu projektów.
Quote:
upierdliwe w lutowaniu ale za to pełny mmu i możliwość urchomienia
Linuxa/BSD czy niezapomniane eksperymenty z tworzeniem własnego OSa.
Miganie diodą z Linuxa jest jakimś argumentem, ale niekoniecznie dobrym
Linuxa/BSD czy niezapomniane eksperymenty z tworzeniem własnego OSa.
Miganie diodą z Linuxa jest jakimś argumentem, ale niekoniecznie dobrym
dla przeciętnego brodacza z lutownicą klejącego pcb w Autotraxie na
nastepny rewolucyjny domofon.
Innymi słowy, PIC32 był nieco powyżej poziomu potrzeb przeciętnego
projektu embedded.
To nie znaczy że jest zły. Na pewno lepszy niż katastrofa PIC <32.
JDX
Guest
Guest
Wed Apr 22, 2026 12:41 pm
On 22.04.2026 08:30, heby wrote:
[...]
Quote:
Jeszcze jedno, ja bym powiedział że na RISC-V jest moda.
ARM to klasyka.
RISC-V wydaje się być kandydatem do skopania d... ARMowi. Jest coraz
bardziej popularny w krajach, które przecież nie muszą się szarpać z
Tak pewnie jest, skoro MIPS (firma) już kilka lat temu zrezygnowała z
ARM to klasyka.
RISC-V wydaje się być kandydatem do skopania d... ARMowi. Jest coraz
bardziej popularny w krajach, które przecież nie muszą się szarpać z
Tak pewnie jest, skoro MIPS (firma) już kilka lat temu zrezygnowała z
MIPS (architektury) na rzecz RISC-V
JDX
Guest
Guest
Wed Apr 22, 2026 12:59 pm
On 22.04.2026 10:13, heby wrote:
Quote:
On 22/04/2026 10:01, Marek wrote:
To nie ta nisza. Duże PICe były... duże.
Co masz na myśli? Za dużo RAM? Za dużo flash? Za dużo pinów? To
ostatnie rozwiazuje pic32mx 1xx/2xx dostępny w 28 pinowej dip/qfn/ssop.
Te procesory odstraszały programistów od migania diodami. Nie
potrzebujesz 32 bitów do tego. Są skomplikowane i duże jak na potrzeby
wielu projektów.
Moim skromnym zdaniem są przyjemniejsze od ARMów, tzn. że architektura
To nie ta nisza. Duże PICe były... duże.
Co masz na myśli? Za dużo RAM? Za dużo flash? Za dużo pinów? To
ostatnie rozwiazuje pic32mx 1xx/2xx dostępny w 28 pinowej dip/qfn/ssop.
Te procesory odstraszały programistów od migania diodami. Nie
potrzebujesz 32 bitów do tego. Są skomplikowane i duże jak na potrzeby
wielu projektów.
Moim skromnym zdaniem są przyjemniejsze od ARMów, tzn. że architektura
MIPS jest przyjemniejsza od architektury ARM, chociaż w sumie są
podobne. I podobnie stare. Tak przypuszczam, że MIPS był po prostu od
początku projektowany bez kompromisów, podczas gdy ARM ma jakieś
naleciałości wynikające ze wstecznej kompatybilności, podobnie jak x86
A te małe MIPSy od Microczipa są całkiem interesujące Tylko że późno
weszły pod strzechy, gdzie ARMy w postaci MCU były już mocno
zadomowione, a na dodatek zaczęły wchodzić RISC-V.
J.F
Guest
Guest
Wed Apr 22, 2026 3:22 pm
On Wed, 22 Apr 2026 12:59:01 +0200, JDX wrote:
Quote:
On 22.04.2026 10:13, heby wrote:
On 22/04/2026 10:01, Marek wrote:
To nie ta nisza. Duże PICe były... duże.
Co masz na myśli? Za dużo RAM? Za dużo flash? Za dużo pinów? To
ostatnie rozwiazuje pic32mx 1xx/2xx dostępny w 28 pinowej dip/qfn/ssop.
Te procesory odstraszały programistów od migania diodami. Nie
potrzebujesz 32 bitów do tego. Są skomplikowane i duże jak na potrzeby
wielu projektów.
Moim skromnym zdaniem są przyjemniejsze od ARMów, tzn. że architektura
MIPS jest przyjemniejsza od architektury ARM, chociaż w sumie są
podobne. I podobnie stare. Tak przypuszczam, że MIPS był po prostu od
początku projektowany bez kompromisów,
On 22/04/2026 10:01, Marek wrote:
To nie ta nisza. Duże PICe były... duże.
Co masz na myśli? Za dużo RAM? Za dużo flash? Za dużo pinów? To
ostatnie rozwiazuje pic32mx 1xx/2xx dostępny w 28 pinowej dip/qfn/ssop.
Te procesory odstraszały programistów od migania diodami. Nie
potrzebujesz 32 bitów do tego. Są skomplikowane i duże jak na potrzeby
wielu projektów.
Moim skromnym zdaniem są przyjemniejsze od ARMów, tzn. że architektura
MIPS jest przyjemniejsza od architektury ARM, chociaż w sumie są
podobne. I podobnie stare. Tak przypuszczam, że MIPS był po prostu od
początku projektowany bez kompromisów,
No jakoś tak, ale to było 40 lat temu - od tego czasu na pewno sie
nazbierało wsteczności :-)
Quote:
podczas gdy ARM ma jakieś
naleciałości wynikające ze wstecznej kompatybilności, podobnie jak x86
naleciałości wynikające ze wstecznej kompatybilności, podobnie jak x86
Zaczynali "od początku".
Quote:
A te małe MIPSy od Microczipa są całkiem interesujące Tylko że późno
weszły pod strzechy, gdzie ARMy w postaci MCU były już mocno
zadomowione, a na dodatek zaczęły wchodzić RISC-V.
weszły pod strzechy, gdzie ARMy w postaci MCU były już mocno
zadomowione, a na dodatek zaczęły wchodzić RISC-V.
No właśnie - jakos tak ARM sie szybciej rozpowszechniał.
J.
JDX
Guest
Guest
Wed Apr 22, 2026 6:53 pm
On 22.04.2026 15:22, J.F wrote:
Quote:
On Wed, 22 Apr 2026 12:59:01 +0200, JDX wrote:
[...]
A te małe MIPSy od Microczipa są całkiem interesujące Tylko że późno
weszły pod strzechy, gdzie ARMy w postaci MCU były już mocno
zadomowione, a na dodatek zaczęły wchodzić RISC-V.
No właśnie - jakos tak ARM sie szybciej rozpowszechniał.
Dzięki Philipsowi, który jako pierwszy na początku tego tysiąclecia
[...]
A te małe MIPSy od Microczipa są całkiem interesujące Tylko że późno
weszły pod strzechy, gdzie ARMy w postaci MCU były już mocno
zadomowione, a na dodatek zaczęły wchodzić RISC-V.
No właśnie - jakos tak ARM sie szybciej rozpowszechniał.
Dzięki Philipsowi, który jako pierwszy na początku tego tysiąclecia
wprowadził pod strzechy rodzinę LPC2000, czyli małe MCU z rdzeniem
ARM7TDMI (architektura ARMv4T, ciągle wspierana przez gcc), które można
było kupić w sklepie za rogiem. Zaraz też pojawiły się do nich
niedrogie evalboard-y, np. u nas od Kamami. Parę lat później pojawiła
się rodzina SAM7 od Atmela na tym samym rdzeniu. Mniej więcej w tym
samym czasie STM też wypuścił swoje kostki, później Analog swoje i się
zaczęło.
Takich małych i łatwo dostępnych dla hobbystów MCU z rdzeniem MIPS
wówczas nie było
J.F
Guest
Guest
Wed Apr 22, 2026 8:51 pm
On Wed, 22 Apr 2026 18:53:10 +0200, JDX wrote:
Quote:
On 22.04.2026 15:22, J.F wrote:
On Wed, 22 Apr 2026 12:59:01 +0200, JDX wrote:
[...]
A te małe MIPSy od Microczipa są całkiem interesujące Tylko że późno
weszły pod strzechy, gdzie ARMy w postaci MCU były już mocno
zadomowione, a na dodatek zaczęły wchodzić RISC-V.
No właśnie - jakos tak ARM sie szybciej rozpowszechniał.
Dzięki Philipsowi, który jako pierwszy na początku tego tysiąclecia
wprowadził pod strzechy rodzinę LPC2000, czyli małe MCU z rdzeniem
ARM7TDMI (architektura ARMv4T, ciągle wspierana przez gcc), które można
było kupić w sklepie za rogiem. Zaraz też pojawiły się do nich
niedrogie evalboard-y, np. u nas od Kamami. Parę lat później pojawiła
się rodzina SAM7 od Atmela na tym samym rdzeniu. Mniej więcej w tym
samym czasie STM też wypuścił swoje kostki, później Analog swoje i się
zaczęło.
Takich małych i łatwo dostępnych dla hobbystów MCU z rdzeniem MIPS
wówczas nie było
On Wed, 22 Apr 2026 12:59:01 +0200, JDX wrote:
[...]
A te małe MIPSy od Microczipa są całkiem interesujące Tylko że późno
weszły pod strzechy, gdzie ARMy w postaci MCU były już mocno
zadomowione, a na dodatek zaczęły wchodzić RISC-V.
No właśnie - jakos tak ARM sie szybciej rozpowszechniał.
Dzięki Philipsowi, który jako pierwszy na początku tego tysiąclecia
wprowadził pod strzechy rodzinę LPC2000, czyli małe MCU z rdzeniem
ARM7TDMI (architektura ARMv4T, ciągle wspierana przez gcc), które można
było kupić w sklepie za rogiem. Zaraz też pojawiły się do nich
niedrogie evalboard-y, np. u nas od Kamami. Parę lat później pojawiła
się rodzina SAM7 od Atmela na tym samym rdzeniu. Mniej więcej w tym
samym czasie STM też wypuścił swoje kostki, później Analog swoje i się
zaczęło.
Takich małych i łatwo dostępnych dla hobbystów MCU z rdzeniem MIPS
wówczas nie było
To jest rynek hobbystyczny, czyli w można by powiedziec: bez wiekszego
znaczenia :-(
Zobacz na rynek profesjonalny: chocby wszystkie telefony, no prawie
wszystkie.
J.
JDX
Guest
Guest
Wed Apr 22, 2026 11:01 pm
On 22.04.2026 20:51, J.F wrote:
[...]
Quote:
To jest rynek hobbystyczny, czyli w można by powiedziec: bez wiekszego
znaczenia
Rynek tak, ale już ludzie nie. Bo oni gdzieś pracują i mają pośredni
znaczenia
Rynek tak, ale już ludzie nie. Bo oni gdzieś pracują i mają pośredni
bądź bezpośredni wpływ na dobór sprzętu do projektów, a tym samym zakupów.
elektroda NewsGroups Forum Index - Elektronika Polska - Gdzie znaleźć płytki uruchomieniowe z ATMega128? Prototypowanie i alternatywy