Gdzie znaleźć płytki uruchomieniowe z ATMega128? Prototypowanie i alternatywy

Wed Apr 22, 2026 6:25 am   

heby <heby@poczta.onet.pl> wrote:

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


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.


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.


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.


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.


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

Wed Apr 22, 2026 7:45 am   

On 22/04/2026 06:25, Waldek Hebisch wrote:

Ale nie kończą z dnia na dzień. Obowiązują pewne plany produkcyjne.


Dokładnie, STM32 w wersji podrabianej GD32. Wymiana "na inny" wymagała
przeprojektowania płytki, co posłusznie zrobiono.


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


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.


Wiele rzeczy będzie wiekszych bez sensu. Rejestry. Magistrale.
Interfejsy. To kosztuje krzem. A jeszcze jak chcesz mieć to
zaprojektowane do zastosowań niskiej mocy...


W przypadku ARMa, machanie kilkoma GPIO zajmie o wiele więcej flasha niż
w AVR. To wynika ze specyfiki kodu.


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.


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.


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


To nie ta nisza. Duże PICe były... duże.


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.


AVR nie ma się tu czego wstydzić.


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.


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

Wed Apr 22, 2026 9:12 am   

On Wed, 22 Apr 2026 08:30:33 +0200, heby wrote:

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.

Wed Apr 22, 2026 9:18 am   

W dniu 2026-04-18 o 08:12, pytający pisze:

Hej, specjalnie dla Ciebie wersja limitowana

https://tinyurl.com/Adapter-ATMEGA128

Pozdrawiam

Wed Apr 22, 2026 10:01 am   

On Wed, 22 Apr 2026 08:30:33 +0200, heby <heby@poczta.onet.pl> wrote:

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

Wed Apr 22, 2026 10:13 am   

On 22/04/2026 10:01, Marek wrote:

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.


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.

Wed Apr 22, 2026 12:41 pm   

On 22.04.2026 08:30, heby wrote:
[...]

MIPS (architektury) na rzecz RISC-V

Wed Apr 22, 2026 12:59 pm   

On 22.04.2026 10:13, heby wrote:

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.

Wed Apr 22, 2026 3:22 pm   

On Wed, 22 Apr 2026 12:59:01 +0200, JDX wrote:

No jakoś tak, ale to było 40 lat temu - od tego czasu na pewno sie
nazbierało wsteczności :-)


Zaczynali "od początku".


No właśnie - jakos tak ARM sie szybciej rozpowszechniał.

J.

Wed Apr 22, 2026 6:53 pm   

On 22.04.2026 15:22, J.F wrote:

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

Wed Apr 22, 2026 8:51 pm   

On Wed, 22 Apr 2026 18:53:10 +0200, JDX wrote:

To jest rynek hobbystyczny, czyli w można by powiedziec: bez wiekszego
znaczenia :-(

Zobacz na rynek profesjonalny: chocby wszystkie telefony, no prawie
wszystkie.

J.

Wed Apr 22, 2026 11:01 pm   

On 22.04.2026 20:51, J.F wrote:
[...]

bądź bezpośredni wpływ na dobór sprzętu do projektów, a tym samym zakupów.

Fri Apr 24, 2026 12:44 pm   

On Wed, 22 Apr 2026 23:01:43 +0200, JDX wrote:

A poterm trafiają do poważnej firmy, gdzie robią miliony
telefonów/tabletów/nawigacji/routerów/telewizorów i słyszą
"my robimy na ARM i nie będziemy zmieniać" :-)

J.

Fri Apr 24, 2026 8:44 pm   

W dniu 22.04.2026 o 09:18, WP pisze:

Ale wcześniej już zamówiłem w AVT.

Pozdrawiam

Sat Apr 25, 2026 12:44 am   

heby <heby@poczta.onet.pl> wrote:

Zależy od firmy. Nie w przypadku procków, ale Maxim jest znany
z tego że różne ciekawe chipy bez ostrzeżenia znikały z oferty.


Nie wiem dlaczego "wymagała", ludzie na płytki wsadzają procki
różnych producentów i to działa.


Ja nie mam nic przeciw używania procka 8bit tam gdzie on wystarcza.
Przy tym "wystarcza" dla mnie zawiera też dobre wsparcie w
kompilatorze. AVR-y prawie się na to załapują. Piszę prawie,
bo jak rozumiem interfejs debugu AVR nie jest jawny i jak chce
się debugować to jest ograniczony wybór narzędzi. Dla ARM jest
większy wybór narzędzi.

Ale jest też kwestia tego czy są jakieś zalety AVR. Są, ale
mało. Co z tego że procek wystarczy do danego zadania, jak inny
procek jest do tego zadania co najmniej tak samo dobry a ten
drugi nadaje się do zadań których nie zrobi pierwszy.
Niekiedy argumentem jest cena procka, ja kupuję procki 32-bitowe
taniej niż 8-bitowe. Za jakie zalety 8-bitowych warto jest
płacić?


Jak piszesz o debilizmach, to ja myślę o "progmem" na AVR. To jest
mocno widoczne dla programisty. Programista C nie widzi podobnych
debilizmów używając innych procków.


Współczesne procki 32-bitowe zużywają podobnie lub mniej prądu
niż 8-bitowe. Powierzchnia krzemu wpływa na koszt, ale jakoś
32-bitowe są tańsze niż AVR. Jak 8-bitowe dają oszczędności
to może producenci nie wiedzą co robią. Jest okazja na
biznes dla Ciebie.


Machanie GPIO na ARM zajmnie więcej kodu, to fakt. Czy wiele
więcej to zależy od tego co rozumiesz przez "wiele". Co istotniejsze,
musisz jakoś dziwnie machać tym GPIO żeby to wymagało wiele kodu.
Proste programy na ARM często są poniżej kilobajta a spora ich
część to tabela wektorów przerwań która ma rozmiar niezależny od
wielkości reszty programu. Jeśli literalnie migasz diodą, to
prawdopodobnie zlicznie czasu zajmnie więcej miejsca niż operacje na
GPIO. Jak masz większy program to procentowy udział obsługi GPIO
będzie malał. No i wiekszymy programie jest spora szansa że przydają
się różne ficzery procka.


To jest ogólna cecha procków z szybkim zegarem (tzn. zakładając
że procek potrafi wykonać kod z RAM). Jak masz zegar powiedzmy
24 MHz to albo nie ma różnicy, albo flasz daje szybszy kod.
Przy 100 MHz RAM zwykle wygrywa (choć róznice nie są tak duże
by było warto to robić na większą skalę).

Niektóre procki "oszukują". Pierwszy GD32 faktycznie wykonywał
kod z RAM. Tzn. przy starcie procek kopiował kod z flasza do
specjalngo RAM, dalej ten RAM udawał że jest flaszem. Zapisy
oczywiście musiały iść zarówno do prawdziwego flasza jak i do
tego RAM.

Nowsze procki oszukują inaczej, np MH32 ma w miarę powolny
flash (chyba podłączony przez SPI) i cache 16 kB. Jak masz
w miarę małą pętlę to ona się zmieści w cache i będzie działać
nieco szybciej niż z RAM. Jak kodu nie ma w cache, to trzeba
czekać jakieś 100 taktów by pobrać 16 bajtową linię z cache.
W "dużych" MCU od ARM cache ma być standartowym ficzerem
(inaczej trudno zrobić procek powiedzmy 500 MHz).


Oczywiście że da się to rozwiązać. Słowa 32 bitowe wystarczają
przy mniejszej częstotliwości zegara. 8-bitowy STM-8 ma takie
słowa flasza. Przy 100 MHz to raczej słowa 64 czy 128 bit.
Zwykle jest prefetch, tzn. z jednego słowa flasza wykonuje się
kod, w tym czasie pobiera się następne. Ale są komplikacje
w stylu że skoki muszą czekać na pobranie kolejnego słowa
z flasza.

Przy tym nie wiem czy to czujesz: ten twój procek 8-bitowy co
miał być prosty dostaje dodatkowe układy i już nie jest taki
prosty.


Jest konkurencja cenowa. Przy zakupie w ilości coś 1000 szt
najtańsze procki 32-bitowe są na poziomie 10 centów, tego
wsześniej nie było.


Zrobienie mniejszego procka to nie problem techniczny a tylko
decyzja marketingowa.


Czy ty wiesz co oznacza "ARM" w MCU? Są jeszcze starocie z zestawem
instrukcji ARM32, ale to do istniejących produktów. Nowe MCU to
tylko Thumb (czy jak wolisz "profil M"). Oczywiści Thumb ma warianty,
ale masz wspólny podzbiór. Zestawu instrukcji po prostu nie da się
przełączyć, więc nie ma "sieczki" która jest w większych ARM.


Nie rozumiesz co to RISC: RISC oznaczał maksymalnie uproszczony
procesor, wywalając co się da i zostawiając tylko to co się
przyczynia do szybszych obliczeń. Czyli w praktyce był to
potok (pipeline) długości między 2 a 4, zwykle 32-bitowy (choć
były też 16-bitowe).

ARM od ideii RISC dorzucił parę własnych pomysłow, w szczególności
bity warunków w instrukcjach. Typowy RISC był projektowany z
założenie że programuje się go w języku wyższego poziomu. Czyli
jeśli kompilator nie potrafi wyprodukować jakieś instrukcji (a
a 1985 kompilatory potrafiły użyć tylko proste instrukcje) to
jest ona niepotrzebna. ARM był nieco bardziej przyjazny dla
programistów asemblerowych. Pierwsze procesory ARM były
projektowane tak by dało się osiągność pełną szybkość procesora
wykonując program z DRAM. To oznaczało mniejszą szybkość niż
inne procesory RISC, ale za to ARM nadawał się do tanich
maszyn.

Wszystkie procesory w miarę upływu czasu zmieniały się albo
gineły. W czasie gdy powsawał ARM bardzo popularny był VAX.
VAX nie dał rady się dostosować i zginął. 8-bitowce z tego
okresu w większości są na wymarciu. O 8086 każdy wie.


Piszesz o histori. Jak pisałeś kod na Acorn Archimedes, a teraz
się obudziłeś i chcesz go puścić na współczesnym MCU to masz problem.
Współczesne MCU od jakiś 20 lat to tylko Thumb (w wariantach) i kodowanie
instrukcji _mocno_ różni się od ARM32.

Jak rozumiem dziś większe (nie MCU) procki ARM mają 3 zestawy
instrukcji: ARM32, Thumb i ARM64. Ale zdaje się że już są na
rynku procesory które mają tylko i wyłącznie ARM64. Tak że
tendecja wydaje się prosta: do MCU któraś generacja Thumb,
do większych procków ARM64, ARM32 do wywalenia.


Nie wiem co rozumisz przez "nie muszą się szarpać z licencjonowaniem
rdzenia". Chiny np. chcą sprzedawać w krajach zachodnich. Złamanie
licencji jest podstawą by dany wyrób zakazać na rynku. W przypadku
wyrobów masowych (jak MCU i wyroby je zawierające) oznacza to duże
straty dla producenta. Chiny mają własne achitektury, jak C-Sky,
Xtensa czy ich rozwinięcie MIPS (na który nabyli licencję) więc
mogliby je używać.

Ja mam nadzieją że RISC-V rozwinie się w otwartą architekturę.
Ale widzę moim zdanie niepokojące sygnały. Np. podstawowy
schemat debugowania dla RISC-V jest otwarty. Ale producenci
procków dodają zamknięty protokół komunikacyjny. Dla mnie to
sygnał że producent dąży do monopolu. Więc jest bardzo możliwe
że RISC-V zginie z powodu małych ale istotnych niezgodności
albo na rynku RISC-V zostanie jeden lub kilka monopoli działających
podobnie jak ARM.
--
Waldek Hebisch