Płytki uruchomieniowe z ATMega128

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.

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.

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.

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

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.

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.

W dniu 22.04.2026 o 09:18, WP pisze:

Fajnie, wygląda interesująco. Ale wcześniej już zamówiłem w AVT.

Pozdrawiam

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ś

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

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.

Ja myślę i wiem po sobie że 1 zaletą jest to że AVR-y znam i mogę swobodnie ustawiać rejestry i dostaję to co chciałem, z arm-ami tak nie ma, albo używam jakiegoś HAL-a czyli protezy programowej albo siedzę i studiuję 800str pdf-a od procka co patrząc na ewentualne 'zyski' kompletnie mnie odrzuca. Mam 65+ i kompletnie nie chce mi się doktoryzować nad nową architekturą mimo że kupiłem kilka procków blue-pill czy esp ale jak na razie leżą. I wielu amatorów którzy zetknęli się z avr-ami ma podobnie, stopień skomplikowania arm-ów skutecznie ich odrzuca.

Dla amatora cena nie jest barierą bo kupuje pojedyncze procki, co innego produkcja gdzie się optymalizuje koszty.

To w świetle powyższego dla kogo jest najnowsze Arduino Q? Wydawało by się, że Arduino (jako platforma) pierwotnie z założenia miała być gdzieś po środku między miganiem a kernelowaniem kompili.

Nikt tego nie wie. To produkt wymyślony przez marketoidow nie pojmujących po co komu Arduino. Kupiłem popkorn i oglądam ten cyrk.

I takie były, ale przyplątało się zborowisko pajacow od rozwałki. Myślę, że stare Arduino bedzie sobie dalej dzialalo jak działa. Nikomu nie jest potrzebny stoliz z zielonym suknem od standaryzacji.

Mylisz się. Oryginalna idea to było środowisko dla artystów którzy mają mało pojęcia o technice. Stąd numery pinów: pojęcie portu We/Wy przerasta oczekiwanych użytkowników. Arduino stało się bardziej techniczne niż oryginalny pomysł, ale duch został: bloki budulcowe mogą być skomplikowane w środku, ale powinny się dać złożyć w całość wysiłkiem porównywalnym do migania diodą. Ludzie robią poważniejsze rzeczy na Arduino, ale to _nie_ była oryginalna idea.

Jeszcze komentarz: niektóre teksty piszą że "Arduino jest bazowane na Wiring". Dokładniejszy sformułowanie to że oryginalne Arduino to po prostu była inna nazwa dla Wiring. Wiring to była praca doktorska Hernando Barragana i ramach pracy opisał on cele. Potem Barragan wrócił do swojego kraju a jego promotor zmienił nazwę na Arduino i zaczął produkcję.

Rozmiem że mogła Ci spaść motywacja na szukanie "nowego". Ale moim zdaniem to mówienie o złożoności ARM to przesada. Ja głównie używam STM32 (np. w Blue Pill). Programuję głównie na poziomie rejestrów. Pdf do powiedzmy ATmega 328 jest trochę krótszy (488 stron) niż te do STM32. Ale nie ma jakieś dramatycznej różnicy. STM32 ma więcej różnych urządzeń, te których nie potrzebujesz możesz zignorować i nie czytać opisującego je kawałka. STM często daje więcej opcji, więc są odpowiednie bity by to włączyć czy wyłączyć. Urządzenia w ATmega 328 działają w miarę fajnie, ale wydaje mi się że w STM32 jest trochę lepiej. Tzn. jak już skonfigurujesz urządzenie (co zwykle wymaga trochę więcej bitów w STM32), to obsługa jest podobna lub prostsza.

Problem może być że większość dokumentacji omawia różne nakładki. One niby mają ułatwiać, ale wprowadzają swoje komplikacje i ograniczenia. Dla mnie działanie na rejestrach wygląda prościej.

No, są ludzie którzy nie liczą pieniędzy, oni ich zwykle nie mają i nawet mały koszt może być problemem. A ci co liczą pieniądze patrzą na koszt. Dlatego jest pytanie co za to dostaniesz.