Cześć, Od jakiegoś czasu bawię się arduino i chciałbym zacząć sobie robić jakieś proste robociki sterowane, może jakieś mini drony latające coś tego typu. Obecnie posiadam: - stację lutowniczą ZHAOXIN 936AH - 3 sztuki Arudino Uno + 4 szt raspberry PI 3 i 4 - Zestaw 37 czujników Modułów Arduino Sensor KIT - 10 sztuk ESP8266 + taki zestaw
Oprócz tego rezystory, kondensatory, przewody połączeniowe, płytki stykowe, różne wyświetlacze, diody itp cuda. Większość tych rzeczy, została mi z zabawy w IoT na platformie Azure. Co jeszcze warto zakupić? Mam voucher do botland na kwotę 350zł, i chciałbym go wykorzystać. Nie ukrywam, że ogromny problem to mam np z projektowaniem płytek PCB, kompletnie tego nie ogarniam. Co najważniejsze jak się zabrać za budowanie robotów, od jakich zacząć?
Zależy czego szukasz? Jeśli mechaniki - to musisz się zastanowić jakie robociki chciałbyś tworzyć (ile osi, jaki rodzaj silników/serw). Jeśli elektroniki - to ja bym się zastanowił, czy nie lepiej pogonić większość tych klocków i kupić zestaw ATB (np. w ramach akcji OrangeBook na PolakPotrafi) - nie dość, że zestaw jest bardzo uniwersalny i kompaktowy, to masz pewność, że wszystko będzie chodzić (unikasz problemów z kontaktami, kabelkami). Sam mam 3 zestawy i nie żałuję. Co więcej możesz zestawu (jako development tool) używać z praktycznie dowolnymi procesorami 8-, 16 i 32 bity (STM32, PIC, Cypress PSoC), CPLD, FPGA itd. - kwestia nakładki montowanej zamiast/do procesora. Dużo więcej się nauczysz niż obstawanie przy Arduino (tak na marginesie to na ATB też możesz używać środowiska Arduino).
Cześć, dziękuję za odpowiedź Miałem zestaw ATB któryś, ale szczerze mówiąc nie miałem kompletnie czasu na to, aby siedzieć i uczyć się C, dlatego przerzuciłem się na prościejsze arduino. ATB naprawdę super, ale to dla kogoś kto posiada dużo więcej czasu niż ja, bo ja co najwyżej mam 3-4h tygodniowo, więc to tyle co nic.
Mój cel to jest stworzyć jakiegoś prostego drona który jest w stanie lecieć do góry i nagrać obraz min w HD, a już super gdyby się dało nim chociaż kawałek odlecieć i normalnie sterować
Tzn inaczej jestem w stanie poświęcić czas na naukę, ale patrząc czego się nauczę np w 30h pisząc pod arduino, a pod mikrokontroler w c, to jest kosmiczna różnica, patrzę pod kątem zabawy jako hobby, a nie coś co chcę robić zawodowo bo wtedy C to byłby główny kierunek. Od 8 lat pracuję jako php dev, więc tutaj tego czasu sporo musiałem poświęcić, ale teraz korzystam z gotowego frameworka, a nie piszę za każdym razem od zera.
Hej Na wstępie napisze, że zgadzam się z przedmówcami odnośnie nauki C/C++ jakie kontrolery (jakiej firmy) wybierzesz to naprawdę nie ma znaczenia, wszystkie mają jakieś swoje specyficzne cechy ale wszędzie znajdziesz model który umożliwi sterowanie dronem/robotem. Jeśli pracujesz w PHP to naprawdę ogarnięcie C/C++ nie zajmie dużo czasu, a otworzy Ci drzwi do szybszych urządzeń typu arduino STM/Intel.
W kwestii Twojego pytania.
reverse26 napisał(a):
Cześć, Od jakiegoś czasu bawię się arduino i chciałbym zacząć sobie robić jakieś proste robociki sterowane, może jakieś mini drony latające coś tego typu. ...
Jeśli chcesz sterować obiektem latającym za pomocą arduino to jest to druga, zaraz po budowie pełnowymiarowego statku powietrznego, raczej słaba koncepcja. W zależności od konstrukcji i masy aerodyny będziesz miał dość dużo operacji matematycznych do wykonania, im mniejszy obiekt tym bardziej "nerwowo" reaguje na sterowanie, jednym słowem jest mniej stabilny, z czego wynika większe zapotrzebowanie na moc obliczeniową. A arduino nie grzeszy szybkością ani optymalizacją kodu - przynajmniej tak było ładnych parę lat temu.
Minimum czujników do stabilizacji lotu to akcelerometr i żyroskop żeby obskoczyć filtr Kalmanna (najczęściej stosowany), można próbować też z AlfaBeta(podobne do Kalmanna) lub filtrami SOI/NOI i widziałem udane projekty takich filtrów w aerodynach. Kolejne to sama stabilizacja amatorsko najczęściej na regulatorze PID - nastawy się dobiera albo w oparciu o model matematyczny obiektu albo w oparciu o kryterium Z-N (doprowadzenie do granicy stabilności) druga opcja jest raczej nieosiągalna dla obiektów latających. Oczywiście nastawy regulatora PID można sobie dobrać na oko i metodą prób oraz znacznych strat w sprzęcie domowym powoli przybliżać się do właściwych nastaw. Profesjonalnie coraz częściej stosuje się regulator DeadBeat - dość trudny w projektowaniu amatorskim.
Tu ważna kwestia, ustawodawca do lotów "na zewnątrz", bez stosownych uprawnień, pozwala na zabawę dronami do 600g, powyżej papierologia i uprawnienia. Oczywiście do puki nikomu nie stanie się krzywda niby może się upiec ale czy warto ryzykować?
To nie znaczy, że nie da się zrobić czegoś na kształt stabilizacji lotu na arduino, odpowiednio dobrana konstrukcja aerodyny/aerostatu (stabilna z definicji) nie wymagająca zbyt wiele pracy przy stabilizacji mogła by być z powodzeniem sterowana nawet na 8051. Kwestia co chcesz osiągnąć.
Jeśli chcesz zacząć przygodę z robotami/dronami to wszystkie mają kilka wspólnych mianowników, to mógł by być materiał do opanowania na początek i do znalezienia gotowych bibliotek. 1. Filtracja sygnału z czujników, Kalman/AlfaBeta/SOI/NOI 2. Regulatory cyfrowe PID, jaki wpływ ma nastawa na zachowanie obiektu itp. ułatwi to dobieranie nastaw. 3. Nawet zgrubnie przybliżony model matematyczny sterowanego obiektu, znacząco skróci czas potrzebny na dobór nastaw i zmniejszy straty/szkody, większość obiektów w przyrodzie można sprowadzić do członu inercyjnego I/II rzędu. 4. Otwarty/zamknięty łańcuch kinematyczny, żeby wiedzieć czego się spodziewać po konstrukcji 5. Jakieś zupełne podstawy z PKM.
Projekty od których bym zaczął to: 1. Ramie robota, wbrew pozorom sprawienie żeby końcówka ramienia zatrzymała się w wskazanym położeniu nie jest tak trywialne jak się wydaje, szczególnie gdy mamy ramie przegubowe. 2. Robocik typu line follower, filtracja danych z czujnika koloru/kamery i sterowanie ruchem robota. 3. Robot balansujący (odwrócone wahadło matematyczne) obsługa żyroskopu i tu będzie pierwsze zderzenie z czasem odpowiedzi układu 4. Jakieś stabilne latadło w okolicach 500g.
abel11 co raz bardziej dociera do mnie, że nauka C pod programowaniem mikrokontrolerów to jedyna słuszna droga. Z tego co zauważyłem to programowanie w c mikrokontroler AVR czy STM32 wygląda bardzo podobnie. Prawda jest taka, że jak kiedyś pisałem w c pod AVR to jakoś tak czułem większą kontrolę nad tym co robi kod i miałem wrażenie, że mam większą kontrolę nad wszystkim.
Jeszcze ze 3-4 lata temu chciałem zmienić PHP na C Embedded Developer, ale wymagania na takie stanowisko nawet juniorskie mnie skutecznie odstraszyły, chociaż nie ukrywam, że lubiłem się bawić Eagle i lutować atmegi smd i inne duperelki smd. Wiec tak, powiedzmy, że olewam arduino co polecasz zakupić do nauki programowania stm32 z botland bo tutaj mam do wydania voucher 350zł. W ogóle to myślałem, że STM to bardzo drogie kontrolery, ale widzę nic droższe od atmegi.
Co potrzebuję do nauki STM32? 1. Jaki moduł gotowy z STM32 warto kupić? 2. Jaki programator?
Modułów pod arduino mam masę, więc mogę je wykorzystać. Rozumie, że wtedy projektuję płytkę tak samo jak pod AVR tylko z wykorzystaniem kontrolera stm.
Discovery jeśli chcesz się pobawić prockiem i zewnętrznymi czujnikami/urządzeniami zamontowanymi na płytce. Nucleo jeśli chcesz mieć płytkę z samym procesorem. https://www.st.com/en/evaluation-tools/ ... tools.html Który procek wybrać? Myślę, że najlepiej coś z najnowszej serii G - albo G4 który ma "pełnowartościowy" rdzeń Cortex-M4, albo G0 z okrojonym rdzeniem M0+. Jeśli chcesz MOC to coś z serii H7. Można też wziąć coś ze starszych serii F4 np. popularny F411. Seria F3 ma dużo peryferii do przetwarzania sygnałów. NIE bierz serii F1, F2! Żadnych BluePills, BlackPills itp. złomu. To nierozwijane starocie. Co gorsze sposób konfiguracji jest całkiem inny niż w pozostałych STM32.
Cytuj:
2. Jaki programator?
Na początek wystarcza programator wbudowany w płytkę rozwojową. Docelowo warto mieć J-Linka.
reverse26 napisał(a):
Modułów pod arduino mam masę, więc mogę je wykorzystać.
Chodzi o shieldy? Teoretycznie pasują do Nucleo64, przynajmniej wymiarami. Z modułami do arduino może być ten problem że są przygotowane pod logikę 5V, a więc albo wymagają konwertera poziomów logicznych, albo trzeba uważać by podłączać je pod piny Five Tolerant procka.
Co do czujników to warto poszukać jakiegoś MEMS np. LSM9DS1 (9 wymiarowy czujnik położenia), dobry czujnik do zastosowań amatorskich - sam sprawdzałem. Do tego jakieś czujniki prądu, temperatury, ciśnienia jakieś enkodery (poszukaj filmów Pana Mirka na ten temat), z takim zestawem powinieneś być w stanie zrobić kilka ciekawych projektów. Miej świadomość, że dopiero w trakcie tworzenia projektu pojawią się braki w podzespołach, o czymś się nie pomyślało, coś "się" spaliło ważne żeby wnioski wyciągnąć i się nie poddawać.
Przewaga C++ nad C to obiektowość (w C masz tylko struktury, w C++ klasy, struktury, polimorfizm, przeciążanie operatorów itd.), w dalszym ciągu większość "dużego" softu jest pisana w C++, systemy operacyjne, większe gry na PC (silniki gier szczególnie), cała masa aplikacji. Fakt faktem, C++ jest coraz częściej wypierany przez Jave/JS, C# i inne języki wiec warto uczyć się nowszych języków, pozwalających napisać to samo szybciej i z bardziej przejrzystym kodem.
1.Branża Automotive związana z mikrokontrolerami stoi w większości na C (większość) i C++. 2.Python jest używany szerzej na "bardziej wydajnych" urządzeniach typu Raspberry Pi czy bardziej wyspecjalizowanych jednostkach. 3. C++ jest stary, ale cały czas aktualizowany C++11, C++14, C++17, C++20, ale jak na razie domyślnym językiem w np. generatorach od ST jest język C.
Cytuj:
Przewaga C++ nad C to obiektowość (w C masz tylko struktury, w C++ klasy, struktury, polimorfizm, przeciążanie operatorów itd.), w dalszym ciągu większość "dużego" softu jest pisana w C++, systemy operacyjne, większe gry na PC (silniki gier szczególnie), cała masa aplikacji. Fakt faktem, C++ jest coraz częściej wypierany przez Jave/JS, C# i inne języki wiec warto uczyć się nowszych języków, pozwalających napisać to samo szybciej i z bardziej przejrzystym kodem.
1. Java a JS (JavaScript) to zupełnie inne języki. 2. Z resztą się zgodzę ale w przypadku komputerów nie mikrokontrolerów. W przypadku mniejszych mikrokontrolerów (AVR, PIC, Cortex-Mx, Cortex-Rx) jak na razie wykorzystywane są w większości języki kompilowane a nie interpretowane.
2.Python jest używany szerzej na "bardziej wydajnych" urządzeniach typu Raspberry Pi czy bardziej wyspecjalizowanych jednostkach.
tylko pyton, tylko pyton - C i C++ to starocie, nikt już tego nigdzie nie korzysta. 32-bity odchodzą do lamusa. A procek jak już to nie jakiś staroć 32-bitowy tylko 64-bitowy są spokojnie dostępne ARMv8-A 64-bit. Kto by się tam bawił w jakieś przestarzałe 32-kocie-bity.
Dziwne te porady na forum. Ciekaw jestem kto z początkujących, albo nawet średnio zaawansowanych poradziłby sobie z stm32h7. Jako ciekawostkę podpowiem, że nawet ST sobie z tymi układami nie radzi i ma w przykładach i bibliotekach mnóstwo błędów... więc doradzać coś takiego początkującym jest chyba mało eleganckie.
2.Python jest używany szerzej na "bardziej wydajnych" urządzeniach typu Raspberry Pi czy bardziej wyspecjalizowanych jednostkach.
tylko pyton, tylko pyton - C i C++ to starocie, nikt już tego nigdzie nie korzysta. 32-bity odchodzą do lamusa. A procek jak już to nie jakiś staroć 32-bitowy tylko 64-bitowy są spokojnie dostępne ARMv8-A 64-bit. Kto by się tam bawił w jakieś przestarzałe 32-kocie-bity.
1.Chwila moment a forum ma głównie tematykę 8 bitówców to skoro 32 bitowe ARMy to starocie to co dopiero 8 bitowce, na których oparte są Pana firmowe zestawy i książki ? 2.
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
- hmm a Linuxy, czy choćby teraz szumnie rozwijana sieć 5G przez firmę na N (znana kiedyś z modeli 3310 itp) (bardzo dużo ofert pracy w C++), systemy bezpieczeństwa czy ADAS (system wspomagania kierowcy) (np. procki Aurix - to tez 32 bitowce (kilku rdzeniowe)) w np. niemieckich autach. 3. Każdy język i każdy typ/rodzina procesora ma swoje zastosowanie i tyle.
tylko pyton, tylko pyton - C i C++ to starocie, nikt już tego nigdzie nie korzysta. 32-bity odchodzą do lamusa. A procek jak już to nie jakiś staroć 32-bitowy tylko 64-bitowy są spokojnie dostępne ARMv8-A 64-bit. Kto by się tam bawił w jakieś przestarzałe 32-kocie-bity.
Nie wiem jak wygląda cena 64 bitowych ARM w stosunku do 32bitowych i innych, ale tu w grę wchodzi koszt produkcji urządzenia więc jeśli 32b będą tańsze, a też sobie poradzą to urządzenie będzie na 32b albo nawet na 16b czy 8b. Procesor się dobiera do konkretnego zastosowania tak żeby możliwie w pełni wykorzystać jego potencjał. Dlatego nigdy w pralce czy lodówce nie zobaczymy wysokowydajnych FPGA np. Kintex czy Virtex, jeśli kiedykolwiek jakiekolwiek będą sterowały sprzętem AGD Do tej pory projektuje się nowe układy DSP również na 16b, musi być ku temu sensowny powód. Jedno co, to na pewno warto uczyć się obsługi nowych procków jeśli tylko są w przystępnej cenie.
elvis napisał(a):
Dziwne te porady na forum. Ciekaw jestem kto z początkujących, albo nawet średnio zaawansowanych poradziłby sobie z stm32h7. Jako ciekawostkę podpowiem, że nawet ST sobie z tymi układami nie radzi i ma w przykładach i bibliotekach mnóstwo błędów... więc doradzać coś takiego początkującym jest chyba mało eleganckie.
Na przykład Microchip nie radzi sobie z swoimi prockami od baaardzo dawna (erraty z workaround - none itp.) i jakoś nie wiele to zmienia, po prostu człowiek uczy się, że nie zawsze jest tak jak się wydaje, że powinno być. Im szybciej to do człowieka dotrze tym lepiej, w krzemie były, są i będą błędy popełniane przez producentów, w notach katalogowych również. Zanim ktoś początkujący (mający ~4 godz tygodniowo na elektronikę) dobrnie do problemów innych niż napisanie kodu działającego, na początek w symulatorze i świecenie LEDem, to już będzie dość dużo informacji na forach jak to działa i jak obejść istniejące problemy. Broń Boże nie chce tu nikogo obrażać, po prostu mam świadomość ile czasu zajmuje ogarnięcie nowego środowiska i procesorów, przy niedoborze czasu. Dlatego nie widzę nic złego w tym żeby zaczynać naukę od nie najłatwiejszej rodziny, jeśli zrazi się od razu to znaczy, że z czasem i tak by do tego doszło. Natomiast jeśli się nie zrazi, to potencjalny zysk wynikający z nauki będzie z pewnością wymierny. Nieeleganckie, a nawet złośliwe, było by doradzanie rozpoczęcia nauki od assemblera:)
Na przykład Microchip nie radzi sobie z swoimi prockami od baaardzo dawna (erraty z workaround - none itp.) i jakoś nie wiele to zmienia, po prostu człowiek uczy się, że nie zawsze jest tak jak się wydaje, że powinno być. Im szybciej to do człowieka dotrze tym lepiej, w krzemie były, są i będą błędy popełniane przez producentów, w notach katalogowych również. Zanim ktoś początkujący (mający ~4 godz tygodniowo na elektronikę) dobrnie do problemów innych niż napisanie kodu działającego, na początek w symulatorze i świecenie LEDem, to już będzie dość dużo informacji na forach jak to działa i jak obejść istniejące problemy. Broń Boże nie chce tu nikogo obrażać, po prostu mam świadomość ile czasu zajmuje ogarnięcie nowego środowiska i procesorów, przy niedoborze czasu. Dlatego nie widzę nic złego w tym żeby zaczynać naukę od nie najłatwiejszej rodziny, jeśli zrazi się od razu to znaczy, że z czasem i tak by do tego doszło. Natomiast jeśli się nie zrazi, to potencjalny zysk wynikający z nauki będzie z pewnością wymierny. Nieeleganckie, a nawet złośliwe, było by doradzanie rozpoczęcia nauki od assemblera:)
Nie chodziło mi o błędy w sprzęcie tylko o bibliotekę Cube oraz przykłady. W przypadku mniejszych mikrokontrolerów jest nieco lepiej, ale dla F7 i H7 ewidentnie producent się pogubił. A skoro oni sobie nie radzą, to trudno chyba wymagać żeby ktoś dopiero zaczynający programowanie sobie poradził. Niby można uczyć się programowania H7 na gołych rejestrach, ale ciekaw jestem ile osób z chęcią przeczyta te 3000 stron noty katalogowej (i cokolwiek zrozumie).
Znajomość, chociaż z grubsza, architektury procesora czyli również jego rejestrów, znacznie usprawnia szukanie błędów, a przecież wszyscy je czasem popełniamy. Producenci, peryferia do procków dodają trochę na kopiuj wklej z innych układów, więc jeśli ogarniesz np. UART w jednym modelu to bardzo dużo takich samych rejestrów będziesz miał w innych modelach tego samego producenta, oczywiście nie we wszystkich prockach. Rejestry konfigurujesz tylko te, które są Ci potrzebne, czyli w wersji minimum zegar oraz I/O nawet nie musisz MUX do peryferii ustawiać bo zwykle nieskonfigurowany pin jest zwykłym I/O sterowanym przez soft (nie połączony z peryferiami). Jeśli tak ograniczysz wymagania to z dokumentacji potrzebujesz 1/30 tego co w niej jest.
Zgadzam się, że jest to trochę droga przez mękę i nie po to producenci tworzą soft do ułatwienia życia, żeby z niego nie korzystać. Ale ta wiedza bywa na wagę złota, szczególnie gdy zdarzy się, że piszesz kod gdzie każdy cykl zegara się liczy, dlatego myślę że warto chociaż podstawy załapać. Potem każdy będzie lecieć z bibliotek i konfiguratorów bo tu nie o masochizm chodzi, a o zdobycie minimum wiedzy do diagnozowania błędów. Microchip w swoim MCC tez potrafi źle skonfigurować peryferia tak, że nie startują poprawnie albo włączenie UART gdy działa PWM i ADC powoduje wyłączenie PWM (błędny adres SFR w bibliotece).
Chwila moment a forum ma głównie tematykę 8 bitówców to skoro 32 bitowe ARMy to starocie to co dopiero 8 bitowce, na których oparte są Pana firmowe zestawy i książki ?
Tak to starocie nikomu niepotrzebne, po co sobie zawracać głowę jakimś 32-bitowcami - a już o 8-bitowcach nie wspomnę. Moim zdaniem trzeba spalić wszystkie książki o 8-bitowcach zaś do książek o 32-bitowcach trzeba już przygotowywać podpałkę. I to forum też spalić - bo przecież w większości o 8-bitowcach.
A wiadomo, że C i C++ to starocie ... ba 32-bitowce to też starocie - jedyne co się liczy to 64 bit i Python
- hmm a Linuxy, czy choćby teraz szumnie rozwijana sieć 5G przez firmę na N (znana kiedyś z modeli 3310 itp) (bardzo dużo ofert pracy w C++), systemy bezpieczeństwa czy ADAS (system wspomagania kierowcy) (np. procki Aurix - to tez 32 bitowce (kilku rdzeniowe)) w np. niemieckich autach.
Przestań tu o jakichś niemieckich ofertach pracy, nikt poważnie myślący nie bierze pod uwagę pracy z 32-bitowcami bo to staroć.
ARMv8 64-bit a do tego Python to jest teraźniejszość i przyszłość
ps19 napisał(a):
3. Każdy język i każdy typ/rodzina procesora ma swoje zastosowanie i tyle.
No co ty ? poważnie tak mówisz czy sobie żartujesz ? Liczy się tylko ARMv8 i jego możliwości - magistrala 64-bit to najszybsza możliwa, a Python będzie śmigał tu jak się należy ...
elvis napisał(a):
Dziwne te porady na forum. Ciekaw jestem kto z początkujących, albo nawet średnio zaawansowanych poradziłby sobie z stm32h7.
Jak to? co ty opowiadasz ? tzn kto by sobie poradził tylko ty ? nie obraź się ale to trochę śmieszne - każdy POCZĄTKUJĄCY świetnie da sobie radę z byle zestawem developerskim z płytką z ARMv8 64 bit ... jest mnóstwo przykładów no ale co tam przykłady są dataszety - i co komu więcej potrzeba? Wystarczy poczytać dataszeta i człowiek nic więcej nie potrzebuje żeby zacząć programować to w micro Pythonie
elvis napisał(a):
Jako ciekawostkę podpowiem, że nawet ST sobie z tymi układami nie radzi i ma w przykładach i bibliotekach mnóstwo błędów...
Nie obraź się proszę ale to są bajki opowiadane przez osoby, które po prostu sobie nie radzą ... troszkę nowości i już wymiękasz ? niemożliwe ... bez przesady. Bierz dataszeta w rękę i do roboty - dasz radę mówię ci - nie łam się proszę. Jak coś to na pewno ktoś ci pomoże.
elvis napisał(a):
więc doradzać coś takiego początkującym jest chyba mało eleganckie.
A co? że niby doradzanie początkującemu który NIC NIE WIE - i nawet andruino nie może się nauczyć - to od razu twój ulubiony STM32 bo się akurat nauczyłeś to jest GUT ? Pomyśl to hipokryzja w czystej postaci. Czemu nie uznajesz nowszego ? 64-bity dla początkującego są DOKŁADNIE takie same - a Python jest po 100-kroć prostszym - że nie wspomnę już że nowszym językiem - zresztą zobacz sobie to i pomyśl chwilę:
i nie mówię tego z żadnym podtekstem czy ironią w twoim kierunku - po prostu zrozum, że dużo nowsze procesory już są i świetnie działają
Nie wiem jak wygląda cena 64 bitowych ARM w stosunku do 32bitowych i innych, ale tu w grę wchodzi koszt produkcji
A produkowałeś kiedyś sam coś na większą skalę? prowadzisz firmę i masz w tym doświadczenie? czy tylko tak teoretyzujesz sobie o tej cenie ?
abel11 napisał(a):
Dlatego nigdy w pralce czy lodówce nie zobaczymy wysokowydajnych FPGA np. Kintex czy Virtex
No wiadomo że w takich starociach AGD jak pralki czy lodówki to stosuje się tylko starocie ARM/STM 32-bit - ale już niedługo i do lodówek zacznie się stosować ARMv8 bo cena leci na łeb na szyję ...
abel11 napisał(a):
Do tej pory projektuje się nowe układy DSP również na 16b, musi być ku temu sensowny powód.
To chyba niedorzeczność - albo dla jakichś inżynierów starszej daty
abel11 napisał(a):
Jedno co, to na pewno warto uczyć się obsługi nowych procków jeśli tylko są w przystępnej cenie.
Z tym się CAŁKOWICIE zgadzam i dlatego podpowiadam jakie są najnowsze
abel11 napisał(a):
Nieeleganckie, a nawet złośliwe, było by doradzanie rozpoczęcia nauki od assemblera:)
Dziwne - bo ja odkąd zacząłem w dawnych czasach zabawę z prockami Z80, 8048/49, 8051 to wtedy był tylko asembler a i do dzisiaj jak rozpoczynam poznawanie dowolnej rodziny procków to TYLKO I WYŁĄCZNIE od asemblera aby poznać chociaż możliwości - i to jak będzie wyglądał kod podczas działania debadżera
No wiadomo - kolega elvis już niejedną kolejną strukturę ARM projektował - więc wie w czym rzecz - a biblioteki HAL i programowanie przez rejestry ma w jednym paluszku - co wynika z wypowiedzi, tylko to coś się nie zgadza jak chodzi o strach przed tymi 64-bitowcami
------------------------ [ Dodano po: kilkunastu sekundach ]
grzeniu 73 napisał(a):
Ale fakt,ze ostatnio coś sporo porad rodem programistów z NASA.
No dokładnie - jak zaczynać to tylko od poziomu NASA - a resztę spalić i zapomnieć. Zresztą już w TV pokazywali gdzieś, że utylizuje się książki o 8-,16- i nawet 32-bitowcach. Jeszcze ponoć tylko nie palą dataszetów - bo ciężko to idzie - ale szukają i na to sposobu.
Pisałem już przecież, że odnoszę się tylko do bibliotek - sprzęt ST projektuje bardzo fajny, albo nie poznałem go na tyle żeby mieć zastrzeżenia. No i nie wiem gdzie niby o lęku przed 64-bitami... to nic strasznego, chociaż faktycznie na ARMv8-A trochę brak czasu, a ARMv7 staje się powoli przeżytkiem. Natomiast w świecie mikrokontrolerów 64-bity są już jak najbardziej, wystarczy pobawić się nowymi RISC-V. Nie wiem co prawda po co aż tyle bitów, ale jest, działa i nawet jest tańsze niż wiele starszych rozwiązań.
O! no widzisz i tu w końcu się zgadzamy - to rozumiem
------------------------ [ Dodano po: 1 minucie ]
elvis napisał(a):
Nie wiem co prawda po co aż tyle bitów,
Jak to po co? wiesz jak to skraca obróbkę dużych ilości danych ? toż 32-bitowce pocą się już ... a 64-bitowcem zmiziasz to w dwukrotnie krótszym czasie, ba ! jak się dobrze zaprojektuje algorytm to i większa przewaga wyjdzie
No cóż akurat w ocenie polecania H7 dla początkujących to oczywiście Kolega Elvis ma 100% racji. Większość początkujący niestety nie rozumie jak działa prościutki timer w trybie CTC, pomimo że na podstawie gotowca umieją go uruchomić. To oczywiście przywilej początkującego i żadna ujma w końcu każdy kiedyś zaczynał.
Polecam w takiej sytuacji od razu każdemu CubeMX i schemat zegarów dla F103 oraz dla przeciwwagi H750. Polecenie tego drugiego procka komukolwiek początkującemu to jawna kpina i brak wiedzy .
Dodatkowo porady dla autora, który ewidentnie ma chrapkę na programowanie uK w C jakieś linuxy, rpi czy tez pythony to są właśnie te szkodliwe porady moim zdaniem, o których pisał Elvis.
A tak w ogóle to ktoś tutaj chyba nie "zaczaił" sarkazmu Mirka
abel11 napisał(a): Nie wiem jak wygląda cena 64 bitowych ARM w stosunku do 32bitowych i innych, ale tu w grę wchodzi koszt produkcji
A produkowałeś kiedyś sam coś na większą skalę? prowadzisz firmę i masz w tym doświadczenie? czy tylko tak teoretyzujesz sobie o tej cenie ?
Tak się składa, że mam w tym pewne doświadczenie jak i w optymalizowaniu BOM z tym związanym, dlatego też zapytałem (z ciekawości) jak wyglądają owe 64bitowce cenowo (wydaje mi się, że są po prostu drogie). Aktualnie z uwagi na stosunek cena/MIPS + peryferia korzystam z dsPIC (16b + DSP). Pomimo, że mamy pewne zapasy tych układów (w firmie układającej SMD na PCB) to przy bieżącej, dość niepewnej, sytuacji rozglądam się za ewentualnymi alternatywami, nawet takimi których nie brałem nigdy wcześniej pod uwagę. Z jednej strony producent aktualnych uC twierdzi, że nie będzie problemów z dostawami, z drugiej lepiej mieć nakreślony chociaż zarys planu awaryjnego bo ewentualne przeprojektowanie urządzenia zajmie cholernie dużo czasu.
mirekk36 napisał(a):
abel11 napisał(a): Nieeleganckie, a nawet złośliwe, było by doradzanie rozpoczęcia nauki od assemblera:)
Dziwne - bo ja odkąd zacząłem w dawnych czasach zabawę z prockami Z80, 8048/49, 8051 to wtedy był tylko asembler a i do dzisiaj jak rozpoczynam poznawanie dowolnej rodziny procków to TYLKO I WYŁĄCZNIE od asemblera aby poznać chociaż możliwości - i to jak będzie wyglądał kod podczas działania debadżera
Zabawne bo przygodę z programowaniem uC zacząłem w technikum z listą rozkazów asm i wklepywaniem kodu maszynowego na przełącznikach w stary 8051, gdzie program był w RAM więc każde trącenie, mocno już doświadczonego przez uczniów, zasilacza kasowało cały program. Wtedy debugerem było się samemu i z pomocą diod LED, trzeba było przeglądać czy w każdej komórce jest zapisane to co sobie w kodzie maszynowym na kartce z listy instrukcji przepisałem. Właśnie dlatego twierdze, że nauka asm na początek to masochizm, potem jak najbardziej się przydaje ale tylko w pewnych okolicznościach. Natomiast posiadanie jakiegokolwiek wyobrażenia o tym jak peryferia i CPU się ze sobą komunikują, chociaż by przez poznanie kilku z nich, ułatwia (przynajmniej mi) pisane kodu i naprawdę nie widzę w tym nic nadzwyczajnego. Naprawdę nie ma większego znaczenia czy te peryferia będzie się organizować w układzie 8b czy 64b, koniec końców to w zasadzie niemal to samo, czasem będzie kilka rejestrów więcej i kilka dodatkowych opcji ale zawsze jest opcja uruchomienia tego w zestawie minimum, co więcej zwykle jest też najlepiej opisana.
Autor tematu twierdzi, że pracuje w PHP, czyli potrafi pisać kod, a więc analitycznie określić co chce osiągnąć i zaprojektować przepływ danych pozwalający na osiągnięcie celu. Więc jedyne czego mu brakuje to jakaś wiedza o tym jak działa uC, nauka kolejnych języków programowania idzie dość łatwo jak już się wie o co w tym chodzi więc C nie powinien być żadną przeszkodą.
Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 0 gości
Nie możesz rozpoczynać nowych wątków Nie możesz odpowiadać w wątkach Nie możesz edytować swoich postów Nie możesz usuwać swoich postów Nie możesz dodawać załączników
Kanał - ATNEL tech-forum
Zaloguj
Zarejestruj
Informacje o cookies
FAQ
Szukaj
Miałem zestaw ATB któryś, ale szczerze mówiąc nie miałem kompletnie czasu na to, aby siedzieć i uczyć się C, dlatego przerzuciłem się na prościejsze arduino. ATB naprawdę super, ale to dla kogoś kto posiada dużo więcej czasu niż ja, bo ja co najwyżej mam 3-4h tygodniowo, więc to tyle co nic. 
