Płytki uruchomieniowe z ATMega128

To w tej chwili powszechna forma prototypowania i chcesz miec wymienny moduł z CPU aby użyć go w innym projekcie. Są moduły z AtMega128, przeznaczone do takich płytek uniwersalnych. Np:

Musi być AtMega128? RP2040 są absurdalnie tanie...

Chce uruchomić pewne urządzenie. Aplikacja na PC (mam źródła i kompilują się) komunikuje się m.in. przez USB z właśnie ATmega128, która steruje silnikami krokowymi w 3 osiach. I do tej ATmegi128 mam źródła w C. Chcę na podstawie tych dwóch programów (PC i Atmega128) odbudować hardware, do której nie mam żadnej dokumentacji. Oryginalny prototyp działał (do którego nie mam dostępu), ale chce zrobić taki reverse engineering. Użycie jakiegokolwiek innego procka tylko będzie utrudnieniem.

Dodatkowo, ten program na PC komunikuje się jeszcze z innym urządzeniem po WiFi.

Robert

Jasne, rozumiem.

Choć, jesli to jakiś rodaj plotera, to drukarze 3D mają na to gotowe rozwiązania software/firmware/hardware: Merlin i Klipper. Czasami warto zrobić podejście typu HAL i zamiast odtwarzać hardware co do rezystora, zaemulować inne hardware jakąś warstwą pośrednią software.

Nie jest to rodzaj plotera, choć 3 osie mogą to sugerować. W mojej ocenie, aplikacja na PC i komunikacja po WiFi i USB to około 75% włożonej pracy w całe to urządzenie. pozostałe 25% to właśnie sterowanie silnikami krokowymi. Hardware jest na tyle prosty że raczej nie wymaga odwzorowywania typu rezystor po rezystorze i ścieżka po ścieżce.

W dniu 18.04.2026 o 21:16, pytający pisze:

No to choćby płyta MKS Gen L V2.1 Jest tam atmega2560, ale to kwestia tylko przemapowania pinów i powinno działać.

W dniu 18.04.2026 o 22:45, Mirek pisze:

Fajna ale zbyt rozbudowana. Dzięki za propozycję.

W dniu 19.04.2026 o 12:59, pytający pisze:

Ewentualnie Ramps 1.4 i Arduino Mega 2560 albo płytka CNC Shield i inne Arduino - nie wiem czy jest akurat z atmega128, nie siedzę w Arduino.

W dniu 18.04.2026 o 21:51, heby pisze:

No i warto by się zainteresować co tam tym USB idzie - może zwykły G-kod.

On 18.04.2026 15:49, heby wrote: [...]

Dokładnie, AVR to umierająca platforma. Nie da tego że jest jakoś bardzo zła, tylko dlatego, że małe MCU 32-bitowe oferują więcej za tą samą cenę.

Więc jak dla mnie to raczej bez sensu wsadzać AVR do nowego produktu. Tym bardziej, że w przypadku np. CM0 nie jest się skazanym na jednego producenta.

Niestety z 5V to w sumie, poza Kinetis, nie ma nic :/

Więc AVRy zostaną napędzając stare projekty. Nie mam nic przeciwko, bardzo je lubię i szanuję za g++ i trywialność hardware. To przesympatyczny cpu z bardzo wygodnymi narzędziami.

Trochę szkoda że się nierozwinęły, rdzeń 8-bit dalej jest użyteczny, a przy ~100MHz mogłby jeszcze skopać tyłek ARMom.

On 19.04.2026 19:21, heby wrote: [...]

No, Analog ciągle ma w sprzedaży MCU na bazie MCS-51, zarówno te swoje MicroConvertery jak i te odziedziczone po Maxim/Dallas. Aczkolwiek np. „1ku List Price Starting From $15.58” sugeruje, że te kostki są adresowane do fanów retro computingu. ;-)

Chińczycy mają całą masę ARM i RISC-V zasilanych z 5V. Np. procki z WCH: CH32F103 (ARM), CH32V103 (RISCV) czy malutki CH32V003 (RISCV).

Przy danym zegarze rdzeń 8-bit przegra na obliczeniach z rdzeniem

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.

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.

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

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.

ARM dzisiaj daje przede wszystkim opłaty licencyjne. To jest bardzo bolesne dla wielu producentów. AVR jest stabilny, ma od groma narzędzi, trywialny rdzeń, Atmel/Microchip mógłby zawalczyć o kawałek rynku. 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).

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

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

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.

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ę

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

Głównie dotyczą obslugi większego RAM/ROM. Nie ma sytuacji, że masz

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.

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

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.

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

Hej, specjalnie dla Ciebie wersja limitowana 😉

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.

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.

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.