Tylko po co się masochizować takim starociem C a nawet C++ ? że o asemblerze już nie wspomnę

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Domyśliłem się, że człowiek wydający dobre książki o 8b na początek programowania może sobie kpić ale jak dla mnie, ktoś kto już jest programistą (autor) powinien znacznie łatwiej poradzić sobie z większym prockiem, więc nie wiem dlaczego niby miał by nie próbować?

A z kogo ja sobie niby kpię ? bo widzę że już zaczynają się przytyki osobiste

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

wg mnie "8 lat w dev php" to i tak za mało, żeby rzucać się na H7.
Oczywiście znajdą się talenciaki, którzy sobie ze wszystkim poradzą, ale to jest forum dla amatorów i należy ważyć porady "'na zamiary". Nie widzę też nic złego w BlackPill - F401 czy F411, to zdecydowanie lepsza baza, żeby jednak za "pół roku" wskoczyć w świat F7, a może i nawet później w H7, kto ambitnemu zabroni

C++ jeszcze przez długie lata nie będzie przeżytkiem, tam gdzie chodzi o wydajność (aplikacje na PC) to jednak króluje C++, nowsze języki są coraz lepsze ale jeszcze dużo czasu upłynie zanim go dogonią - przynajmniej tak mi się wydaje. Puki co największą zaletą nowszych języków jest przenośność, np. Java miała działać na każdym urządzeniu, jakiś czas temu Microsoft wykupił Xamarin'a żeby C# był bardziej elastyczny o ile sam język mi się podoba, to na Xamarin'a dostałem alergii po 5 minutach obcowania. Podobnie niestety jest z C w systemach wbudowanych, bardzo bym chciał mieć (dobry) kompilator C++ dla dsPIC, nawet jeśli w dalszym ciągu miał bym pisać w asm funkcje wykonujące operacje na liczbach stałoprzecinkowych to już cała reszta dobrodziejstwa C++ była by wręcz "mokrym snem"

Po co pisać cokolwiek w asm między innymi dla 40 bitowego akumulatora i operacji MPY oraz MAC (w silniku DSP). W jednym cyklu zegara pobieram dane z pod adresu przechowywanego w rejestrze, inkrementuje/dekrementuje ten adres (0/2/4/8) i mnożę dwie liczby - wynik trafia do akumulatora 40b więc 16bx16b nie daje nigdy przepełnienia, opcjonalnie w tym samy cyklu zegara mogę jeszcze drugi akumulator przepisać do rejestru. Do tego dochodzi jeszcze kilka fajnych rozkazów ułatwiających dynamiczne skalowanie danych wejściowych. Przykładowo filtr Alfa Beta napisany w C na float (32b) i w asm na _Fract(Q0.15) z skalowaniem wykonuje się znacznie (110us do 34 us) szybciej na liczbach stałoprzecinkowych, jak filtruje dane z ADC (15b) to nie ma zauważalnej utraty dokładności z uwagi na rozdzielczość danych wejściowych.
Już od kilku lat nie marze nawet, że kiedyś kompilator w C zacznie z tego korzystać... po prostu napisałem sobie własną bibliotekę funkcji w asm i tyle.

------------------------ [ Dodano po: 10 minutach ]



Nie twierdze że moja racja jest najmojsza i tyle, po prostu uważam że jak ma się jakieś doświadczenie można sobie pozwolić wypłynąć na głębsza wodę, jak będzie zbyt głęboka zawsze można wrócić tam gdzie człowiek czuje się lepiej. Ponieważ mam pewne doświadczenie w stabilizacji obiektów latających (praca dyplomowa) to uważam, że tu warto mieć nawet dużo za mocny procesor niż kombinować z odrobinę za słabym. Być może to sprawia, że dla takich zastosowań, jestem bardziej skłonny raczej polecić coś mocniejszego niż coś słabszego.
Właśnie dlatego jak kilka osób się wypowiada w temacie łatwiej o jakąś zrównoważoną konkluzje, różne punkty widzenia i różne doświadczenia.

------------------------ [ Dodano po: 15 minutach ]


To nie jest żaden przytyk - przynajmniej nie takie miałem intencje, po prostu zauważyłem, że ktoś kto jak Pan pisze dobre książki o 8 bitowcach, co za tym idzie ma nie małe doświadczenie, może sobie pozwolić na żarciki w kwestii języka i "jedynych słusznych" 64b procesorów.
Faktycznie jak spojrzałem na tamten wpis to dość beznadziejnie go napisałem (mógł być zinterpretowany zupełnie inaczej niż bym sobie tego życzył)

Zaszło nieporozumienie. Istnieje BlackPill z F103 i inny z F4xx. Ja miałem na myśli ten pierwszy. Ten czy inny, uważam, że nie warto się łakomić. Nucleo daje wyższy komfort pracy. Jest schemat, jest dokumentacja, jest programator, są wszystkie piny. Pinów napięcia jest kilka. Pinów GND jest kilkanaście. Całość działa bez zgrzytów out of the box.

Być może nie do końca w klimacie i na temat w tego tematu... być może nie do końca dla osób początkujących... ale przemknęła mi ciekawa pozycja gdzieś niedawno. Myślę, że fajnie na to przynajmniej popatrzyć. Może stanie się inspiracją :-)

Texas Instruments: An Engineer’s Guide to Industrial Robot Designs


PS. To w razie gdyby komuś znudziło się kolejne przeliczanie bitów w bajcie... tudzież cukru w cukrze... ;-)

Po waszej burzliwej dyskusji, zapytam jeszcze raz jaki sprzęt zakupić oraz jaki język programowania warto wykorzystać?

Ot właśnie z takimi dyskusjami burzliwymi spotykają się zwykle początkujący na wielu innych forach. Bo każdy kto już liznął ARM zapomniał zgodnie z przysłowiem "zapomniał wół jak cielęciem był" o co chodzi - i już każdy pręży muskuły - że w sumie to najlepsza droga od razu od ARM (każe lecieć przez ogień) - gdzie początkująca osoba nie mająca kompletnie rozeznania nawet w samym języku C ... do tego musi jeszcze przejść dość sporą drogę przez konfigurację samego środowiska pod STM, musi się nauczyć wybierać procka, musi zacząć się uczyć co to jest CubeMX ... jak to jeść w ogóle - a jak zajrzy w kod wstępnie przygotowany przez nawet Atolic True Studio - to za głowę się łapie i nie wie od czego zacząć, gdzie w ogóle pisać kod, jak użyć chociażby prostych timerów itp itd ...

Owszem są poradniki w necie jak na wszystko ... wszędzie są - tylko jakoś tak ciężko ruszyć ....

I po to powstały publikacje Atnel a do książek, poradniki wideo, do tego forum dla początkujących i artykuły na blogu - żeby móc w końcu zacząć JAK NAJPROŚCIEJ z językiem C od zwykłych 8-bitowców ....

i teraz sam popatrz sobie panie autorze wątku - większość z tych ludzi tu przekrzykujących się o 32 bity - rzuca wciąż, że a to tańsze, a to lepsze, a to 8-bit to staroć, a to język C to staroć - więc weź się od razu za C++ !!! I nawet ci książek żadnych nie potrzeba - wystarczy dataszet co już jest całkowitą głupotą i niezrozumieniem takich ludzi jak chodzi o proces dydaktyczny ....

I kończy się to właśnie tak jak widzisz - ja sam specjalnie zacząłem podjudzać tych ŚPECÓW niestety - tak muszę ich określić tzn niektóre osoby które tu wystąpiły - że aż niektórym szczęki opadły - że jak to ? To już nie liczą się na tym forum 8-bitowce? zestawy ATB? książki Atnela ? .... jak to ? C/C++ jest stary ? tylko python dobry ..... no ubaw miałem po pachy - aż zaczęli wymyślać znowu że teraz to 64-bitowce są a to za drogie, a to że mają wady fabryczne, a to że firmy które je produkują już same nad nimi nie panują - no istny cyrk na kółkach jak się czyta te porady .... aż w końcu jeden Śpec o nicku elvis - w końcu podniósł się i jednak stwierdził, że nie - dobra on daje radę z tymi ARMv7 i 8 i 64 bit - więc każdy da radę .... cyrk na kółkach


a na końcu - ten kto pytał czyli początkujący - dowiedział się tylko, jacy to ŚPECE są mądrzy, że dla nich to pikuś, że w ogóle ach i och oni są .... tylko pytający leży rozłożony na cztery łopatki i nie wie co zrobić - TAK TO SIĘ ZAWSZE KOŃCZY

Gdy zaś zaczniesz z tymi 32-bitowcami próbując od razu z C++ na dodatek - to gdy później zadasz pytanie któremuś śpecowi, żeby ci pomógł to wiesz jak będzie ? jak w tym filmiku wspaniałym:



przepiękna parafraza Śpecowania wszyscy śpece sobie klaskają, brawa biją - ... a na końcu .... sam zobacz ... a jak przyjdzie co do czego to ... eeeś żaden nie podpowie

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Ales mi ten filmik przypomniał

Bo pasuje do tego wątku jak ulał

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Bardzo interesująca teoria Panie Mirku, autor ma 8-letnie doświadczenie jako programista PHP, wiec chętnie się dowiem z czym miał by mieć problemy w C/C++: z pętlą for, while, może z instrukcjami warunkowymi, a może już deklaracja zmiennych go przerośnie? Z tego co wiem, rzeczy które częściej sprawiają początkującym problemy, to wskaźniki (mi też sprawiały problemy), przecież one również występują w PHP, więc i tu nie wiem dlaczego autor miał by mieć problemy. Chyba, że to sama składnia języka i konfiguracja środowiska (zawsze dość dokładnie opisana przez producenta) jest aż takim wyzwaniem?
Nie mam żadnego doświadczenia w uczeniu innych więc naprawdę chciał bym dowiedzieć się, bez żadnych przekąsów i złośliwości, co miało by sprawić takie trudności o których Pan pisze. Jestem po prostu ciekaw, nie przeczę że już trochę zapomniałem z czasów kiedy zaczynałem i może stąd ta ciekawość; ponieważ ma Pan na bieżąco kontakt z ludźmi zaczynającymi naukę więc chyba odpowiedniejszej osoby do zadania tego pytania nie znajdę.

Sam Pan wielokrotnie powtarzał, że zarówno książki jak i video poradniki traktują o języku C, a nie o szczególnej rodzinie mikrokontrolerów, natomiast AVR wybrał Pan jako przykład i ok - na czymś trzeba pokazać przykłady. Problem w tym, że AVR (nawet nowsze) mają dość mało do zaoferowania, przy zagadnieniach które wymienił autor na samym początku, są po prostu relatywnie wolne. Nie twierdzę, że nie ma opcji żeby coś na tym zrobić ale twierdzę, że STM ma znacznie bogatszą ofertę mikrokontrolerów spełniających kryteria autora i dlatego warto uczyć się ich środowiska od początku, jeśli ma się jasno postawiony cel, po co iść w potencjalnie ślepą uliczkę? Chyba z tego samego powodu dziś już nie zaczyna się od 8051 i assemblera prawda?

Przypomnę, że kontekstem było stosowanie procesora proporcjonalnego do problemu, który ma rozwiązywać, gdzie Pan sobie żartował "tylko 64b", natomiast cena była argumentem dlaczego nie tylko 64b. Przypuszczam, że kwestia wykorzystania procesora w możliwie dużym stopniu dla danego projektu to nie jest dla Pana żart, bo jeśli tak to mało śmieszny. Sam Pan z pewnością wie, tworząc swoje projekty, jak istotne jest budowanie możliwie taniego i elastycznego BOM i że jeszcze większym błędem jest tworzenie projektu który nie prowadzi do rozwiązania postawionego problemu. W mojej subiektywnej ocenie, właśnie tym są AVR (a szczególnie 8b) dla problemu stabilizacji lotu - okropnym błędem i nieporozumieniem, ponieważ nie prowadzą do rozwiązania problemu. Nie wiem jak miały by pomóc w procesie dydaktycznym, bo jak wspomniałem, na nauczaniu się nie znam ale pisząc w C jakoś nie dostrzegam różnicy na jaki kontroler pisze się kod funkcji, różni się tylko inicjacja peryferii, dlatego dobrze napisany kod można bez większych trudności przenosić na inne kontrolery. Co więcej warstwę sprzętową można coraz częściej wyklikać w kreatorach, znacznie przyśpieszając przenoszenie kodu, nawet nie mając zbyt wielkiego pojęcia jak te peryferia działają i jak są zbudowane, co uważam za pułapkę kreatorów.
W kwestii wad fabrycznych; być może jest Pan alfą i omegą i nigdy errata nie namieszała Panu w projekcie - jeśli tak to zazdroszczę nieomylności. Zapewne również informacja w erracie "workaround - none", nie oznacza że producent dał ciała, to tylko ładnie zakamuflowany kupon na darmowe ciastko

Widać niestety kolega abel11 z całym szacunkiem wciąż nie rozumie o co chodzi. Wiedza jest, i to duża! niezaprzeczalna i niepodważalna ... ale sposób jej przekazywania ? ... no cóż nie każdy ma talent do wszystkiego. Dlatego nawet nie będę polemizował, rozwijał tematu i zaczepek bo szkoda pary i czasu. A "mucha nie siada"

------------------------ [ Dodano po: 8 minutach ]


chociaż - nie - odniosę się tylko do tego. Dlatego, że ta wypowiedź (bez urazy też pokazuje, że jednak kolega nie ma pojęcia w tym zakresie) ...

Jak tworzę projekt który dla klienta końcowego ma kosztować 10K $$$ i jest to jednostkowy projekt albo kilka sztuk albo kilkanaście to jaki sens jest kierować się ceną procka (to czysto chore podejście) ... trzeba w ogóle wiedzieć, że są takie projekty i to nie mało. Za to zwykły przysłowiowy "kowalski" nie mający pojęcia o produkcji zawsze sobie wyobraża produkcję w miliardach egzemplarzy jak to robią np Chińczycy ... wtedy owszem - wchodzi w grę cena procka. Ale nie można zakładać takiej bzdury wierutnej - że cena procka to zawsze najwyższa waga. I myślę, że to tyle w tym temacie.


No i właśnie nie dziwię się, że kolega nie dostrzega różnicy - bo sam słusznie kolega zauważył że na nauczaniu się nie zna ... a tu jest pies pogrzebany, bo ty widzisz co innego ... i teraz krótko pokaż mi ilu ludzi udało ci się nauczyć - tak powiem to wprost ... w porównaniu do tego co mi się udało.

Dlatego szanujmy się nawzajem - ja szanuję twoją wiedzę i twoje zdolności ale ty szanuj mnie i to co ja robię i tworzę zamiast pisać bzdety że uczę na 8-bitowcach podstaw C bo to najtańsze - skoro nie masz o tym zielonego pojęcia i sam to wręcz mówisz. A zatem coś z logiką tu mocno kolega kręci (bez urazy proszę)

------------------------ [ Dodano po: 21 minutach ]

A na koniec dodam panie kolego abel11 - że nawet na tym forum są już dziesiątki jak nie setki osób, a szczególnie poza forum część obrażonych osób, że Kardaś działa wciąż na starociach 8-bit bo oni już przeszli z powodzeniem na ARM i dlaczego Kardaś nie robi poradników o ARM ....

Bo właśnie ....

1. Jak nie rozumieli w ogóle od czego zacząć - to pomogła im droga przez zwykłe 8-bit i Bluebooka, a później łatwo było zająć się i przejść na podstawy ARM bez większego problemu - trzeba było tylko wdrożyć się w inne środowisko, poznać dużo więcej zależności sprzętowych itd

2. Ba! ale okazuje się, że ARM za nich nic więcej nie zrobi więc trzeba się dalej uczyć i sprzętu i C ... Tylko przydałyby im się gotowce i przykłady w C dla ARM/STM i tu złość na Kardasia że dalej im nie pokazuje

Krótko mówiąc - moja misja to nauka podstaw C dla procków - mam swoją dobrą metodę dydaktyczną i ona działa rewelacyjnie czy tego chcesz czy nie ... i pozwala przejść dużo szybciej na 32-bity albo i na 64-bity ! byle zrozumieć takie podstawy jak np "pseudo wielowątkowość" której o dziwo NIKT nie poruszał w polskiej literaturze przed Bluebookiem a i po nim cienko z tym ...

Co to zatem za problem zacząć od 8-bitowca żeby ZROZUMIEĆ a później pięknie iść dalej

Przykro tylko że kupa ludzi tego nie rozumie i pierdzieli że Kardaś zatrzymał się na 8-bitowcach, że Kardaś chce tylko sprzedać swoje produkty ...

Tylko, że to co Kardaś pokazuje - pozwala się czegoś nauczyć - a takie rozważania które zaprezentowałeś wyżej to tylko mielenie bzdur - a początkujący co? LEŻY NA ŁOPATKACH i wie, że ty wiesz jak coś tam zrobić a on jest dalej z ręką w nocniku

i tego nie możesz zrozumieć panie Abel11 podobnie jak niektórzy inni ... rozzłoszczeni że Atnel nie robi książek o ARM'ach .... zero zrozumienia, zero wsparcia a za to tylko wymądrzanie się - za to Kardaś zakasał rękawy i wziął się do roboty zamiast pierniczyć wciąż teorię co to Kardaś nie potrafi

taka jest różnica

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Ja tylko dodam od siebie, że po pierwsze umiejętność pisania programów na PC tylko częściowo pomaga pisać na mikrokontrolery.
A po drugie: szybkość nauczenia się podstaw zabaw z uC jest zdecydowanie większa na prostych 8bitowcach (z różnych względów - m.in. z uwagi na mniejszą ilość rejestrów, które dużo latwiej ogarnąć początkującemu).
Po trzecie: posiadam większość książek dotyczących różnych mikrokontrolerów wydanych w Polsce oraz trochę książek zagranicznych i w każdej znajdę coś ciekawego, ale to u Mirka widzę najlepszą dydaktykę i rewelacyjnie podaną wiedzę praktyczną - uczy porządnego stylu programowania. Dlatego też te książki polecam każdemu, który chce zacząć z uC.

Mówimy po prostu o innych ilościach produkcyjnych. Firma w której pracuje jako R&D, produkuje około 1000 urządzeń w skali roku, może nie jest to imponująca ilość (jak miliony o których Pan wspominał) ale jeśli na same procesory można wydać nawet o 20% mniej, to naprawdę nie jest mało (dajmy na to jakieś 2-3pln na egzemplarzu), co więcej procentuje to przy każdym sprzedanym urządzeniu. Dalej, unifikowanie podzespołów pozwalające na załapanie się w kolejne progi cenowe także dużo daje, może dlatego mamy nieco odmienne podejście w tej kwestii. Dodam, że od procka uwikłany jest przecież projekt zasilania i PCB, co także przekłada się na koszt urządzenia, np. 1V8 wymaga albo całego układu na 1V8 albo zmiany napięć na I/O i kolejnych stabilizatorów/przetwornic, dlatego nieraz taniej jest działać na 3V3 jeśli pozwala to na eliminację stabilizatorów i zmiany napięć I/O. W rezultacie mam krótszy BOM, mniej elementów, a co za tym idzie niezawodność wzrasta - czyli opłacalność produkcji rośnie, bo spodziewanych gwarancji powinno być mniej.
Przyznam, że nie wiedziałem o tak dużym zapotrzebowaniu na projekty jednostkowe, gdzie faktycznie koszt jednej roboczogodziny był by większy niż oszczędności wynikające z optymalizacji BOM.

Panie Mirku nigdy nie byłem rozczarowany ani obrażony o to, że pisze Pan o języku C z przykładami dla AVR 8b, jak sam Pan wielokrotnie pisał C jest taki sam dla wszystkich uC 8/16/32/64 czy ile tam bitów człowiek wymysli. Co więcej Pańskiego BB trzymam na półce razem z m.in "Sztuką elektroniki" czyli z najlepszymi książkami technicznymi jakie posiadam, bo uważam że to kawał dobrej książki. Jakiś czas temu pożyczyłem go koledze z pracy który chciał spróbować sił z programowaniem, niestety leniowi nawet dobra literatura nie pomoże. Nie polecał bym Pana literatury współpracownikom, gdyby nie była tego warta, bo prędzej czy później odbiło by się to niekorzystnie na zakładzie pracy, a w końcu i na mnie.
Tyle w kwestii czy szanuje Pana prace, a jak Pan pisze uszczypliwości to proszę się nie dziwić, że odpowiadam tym samym.

Odnośnie wymogów autora dla procesorów to w dalszym ciągu uważam, że AVR tu się nie sprawdzą i nie mam pojęcia dlaczego ktoś, z 8-letnim stażem, kto może przecież być seniorem, miał by nie ogarnąć ARM. Chociaż mam wrażenie, że pośrednio otrzymałem odpowiedź na to pytanie, gdy pisał Pan o swojej literaturze, z tego co pamiętam jest bogato ilustrowana sprawdzonymi przykładami - może o to chodziło. Nie wiem tylko dlaczego by tych przykładów nie zastosować do innych uC, to naprawdę aż taka różnica zmienić sobie nazwy rejestrów czy dodać pin selektora? To nie jest żadna uszczypliwość ani żaden atak, po prostu jako ktoś, kto z nauczaniem nie ma nic wspólnego (talentu tym bardziej nie mam w tej materii) nie potrafię tego zrozumieć - być może tak już pozostanie.

Wracając do pytania autora o moduły, to dla samych modułów nie ma znaczenia jaki procek wybierzesz LSM9DS1 o którym pisałem wcześniej, spokojnie obsłużysz każdym prockiem (sprzętowe SPI/I2C bardzo Ci w tym pomoże), jest to moduł który posłuży zarówno do nauki jak i do projektu końcowego. Podobnie czujniki prądu/temperatury/ciśnienia, możesz je stosować zarówno do nauki jak i w projekcie końcowym, raz napiszesz sobie bibliotekę albo ściągniesz gotową i więcej nie musisz wracać do noty katalogowej. Jakie czujniki prądu, temperatury i ciśnienia wybierzesz nie ma krytycznego znaczenia, ciśnienia możesz używać do określenia przybliżonej wysokości w lotach swobodnych zamiast czujnika GPS. Czujnik temperatury może monitorować temperaturę pakietu zasilającego, jak wzrośnie za bardzo to należy obciąć moc bo inaczej będziesz miał własnego Hindenburga itp. Im więcej czujników nauczysz się wykorzystywać tym lepiej bo pozwoli Ci to na więcej ruchów w projekcie. Może warto tez się zastanowić nad jakimś modułem bezprzewodowym do komunikacji.

ale to nie chodzi o to co w dalszym ciągu kolega uważa - tylko, że kolega nie rozumie - że ktoś kto zaczyna od zera - NIC a NIC nie skorzysta na kolegi poradach bo AVR się nie sprawdzi. A jak taki początkujący to sprawdzi - zastanowiłeś się kiedyś. Najpierw trzeba zacząć się uczyć podstaw - nie na darmo w szkole podstawowej uczył się każdy z nas pisać i czytać, dodawać i odejmować - a nie budować napędu kosmicznego. Zrozum proszę tę najprostszą zasadę i pozwól mi działać wg mojego uznania na moim forum - to moja gorąca prośba. Bo dzięki takim dyskusjom NIKT nie zacznie rozumiesz ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Im więcej postów, tym większy mętlik w głowie. Czyli rozumiem, że powinienem zacząć od 8 bit AVR czy od razu ARM? Wybaczcie te wcinanie się w waszą dyskusję, ale w dalszym ciągu nic nie wiem, poza tym, kto co uważa za lepsze, a co za gorsze.... Przewinęły się procesory 8 bit, 32, 64, AVR, ARM do tego c/c++, python. assembler i jeszcze pewnie kilka innych które pominąłem

Najpierw zacznij ogarniać proste rzeczy na prostych uC a jak już zaczniesz się w nich płynnie poruszać to bierz się za platgorme docelową, która ogarnie drony (przy okazji podejrzyj na czym są robione motherboardy do dronów)

Dlatego teraz mnie nie słuchaj - bo wziąłem udział w tej bezsensownej niestety dyskusji i mogę równie dobrze nie mieć racji ...

szkoda mi tylko właśnie początkujących - bo twój przykład pokazuje ślicznie jak to właśnie jest przy takich poradach gdzie każdy przekrzykuje czyje lepsze i im tańsze to lepsze , im więcej bitowe to lepsze itd

myślę, że sam podejmiesz wg własnego uznania rozsądną decyzję

Ale gdybyś kiedyś chciał uczyć się od podstaw C na przykładach 8-bitowców to możesz być pewien jednego - TU zawsze znajdziesz pomoc tak jak wielu początkujących bo po to jest to forum i po raz ostatni DOPUŚCIŁEM do takiej dyskusji. Na drugi raz poproszę Panów od 32-bitów, od C++, od innych wodotrysków aby ew na PW kierowali swoje sugestie zamiast mieszać kijem w wiśle

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Jako wieloletni czytelnik forum pozwolę sobie odnieść się do tego fragmentu...
Wystarczy popatrzeć jak ludzie mają problem z przeniesieniem kodu z jednej ATmegi na inną albo na AT2313 czy ATTiny i już kolega nie będzie tak ochoczo twierdził, że to żaden problem A przecież w AVR jest to zbliżone, a po przejściu na zupełnie inne procesory?
Tu już potrzebne jest pewne "otrzaskanie" się z tym co się dzieje, jakie są powiązania i za co odpowiadają poszczególne peryferia.

_________________
Jestem początkujący i moje porady mogą być błędne