Po kilkunastu latach przerwy i rzeźbieniu głównie na ARM, muszę się przeprosić z AVR. Potrzebuję małego, jak najtańszego uC z kilkoma GPIO i jednym ADC. Mój wybór padł na attiny806.
Jako że wypadłem z obiegu, chciałem zapytać jak obecnie wygląda sprawa z narzędziami? Jakie IDE obecnie warto wybrać? Ja pamiętam czasy AVR Studio, później chyba był ATMEL Studio, a teraz chyba Microchip Studio. Jak wygląda programowanie i debugowanie tych małych AVR? Mają jakiś bootloder na UART?
Dodam tylko że Arduino mnie kompletnie nie interesuje.
Dalej jest Avr Studio, teraz 7, Mikrochip ma swoje ide.
Tu masz stronę
formatting link
Stare miały spi ten attiny który wybrałeś jest z tych nowszych i ma udpi, czyli taki szeregowy interfejs, gdzieś na elektrodzie jest opisana przejściówka usb-rs która programuje albo kupujesz snap-a
Właśnie chciałem "dopchnąć" zamówienie w Farnellu żeby mieć darmową wysyłkę i pomyślałem o prockach, ale takich starego sortu, bo takie nadal używane są w pewnym stale rotującym projekcie. Szukam sobie czegokolwiek z gatunku 89S8253 i niezłe pustki widzę. Żeby tak stare procki zeszły? Wydawało mi się, że o rodzinie '51 świat już zapomniał i nie będzie problemu, a tu proszę, niespodzianka. W TME też widzę, że nośności nowo postawionych regałów nie testują. Za pół roku skończą mi się zapasy, jak nie uda się dokupić :(
Microchip zmienił ostatnio nazwę Atmel Studio (AVR Studio) na Microchip Studio. Oprócz tego jest jeszcze Microchip MPLAB. Bezpłatny kompilator bez optymalizacji.
Zgłębiłem temat i te attiny series 0, series 1 wyglądają bardzo obiecująco.
Janusz <janusz snipped-for-privacy@o2.pl napisał(a):
Przyczym ten styl jest od AVR Studio 5, pierwszej wersji bazującej na Visual Studio Shell. Przedtem było AVR Studio 4, które było tak naprawdę innym oprogramowaniem, wymagającym doinstalowania kompilatora.
Prymitywne IDE, niewiele bardziej zaawansowane od Notatnika, bez możliwości debugowania
Biblioteki pisane na kolanie
Dziwna konstrukcja z setup/loop
Ukrycie użycia timera i wielu innych rzeczy, bo ma być przede wszystkim prosto Arduino nie powstało i nie jest rozwijane z myślą o profesjonalistach. Wywodzi się z projektu Wiring, który miał artystom pozwolić tworzyć automatyczne lub interaktywne instalacje. Nieprzypadkowo w Arduino nie ma projektów tylko szkice. Dlatego jest spoko do szybkiego prototypowania a nie poważniejszych zastosowań.
1) Możesz zostawić środowiko arduino i używać Eclipse/Netbeans/QtCreator/Atom/itd jako edytora.
2) Debugowanie jest praktycznie niemożliwe bez emulacji sprzetu. Często ta emulacja sprzetu jest milion razy trudniejsza. Dlatego wymysliliśmy techniki pisania kodu, które praktycznie redukują potrzebę debugowania na *prawdziwym* targecie, asymptotycznie do zera. Zaryzykuje że poprawnie napisany program w języku C/C++ będzie wymagał debugowania w emulatorze CPU w mniej niż promilu przypadków. Za to będzie znakomicie debugował się na hoście.
Nikt nie każe z nich korzystać. Przypomnę tylko, że firma Atmel dla SAM7 miała na kolanie napisane *wszystko* do stanu który powodował wymioty na sam widok tej niewiarygodnej fuszerki. Jak bym nie wiązał tego dziadostwa z Arduino, tylko z embedded. Tam wszystko jest dziadowskie do granic absurdu i nikomu to nie przeszkadza.
W 99% programów pojawi się taki setup/loop.
Albo abstrakcyjnie. Sugeruje nie mylić pojęć.
Problem w tym że nie padło "poważne zastosowania" u wątkotwórcy, za to padło ATTINY. Co niejako stoi bokiem do koncpecji "profesjonalnych IDE" skoro kod nie jest większy niż max kilka stron na ekranie i może być pisany w Arduino czy czymkolwiek innym, wliczając notatnik. Choć tak nisko bym nie upadał.
Idąc za ciosem można zrezygnować z Arduino zupełnie.
Moje doświadczenia są zgoła odmienne. Nie wiem do czego miałby mi być potrzebny emulator CPU. Kod pracuje w jakimś urządzeniu i komunikuje się z innymi układami. Potrzebna jest możliwość sprawdzania co się dzieje w rzeczywistym układzie. Tu przydaje się oscyloskop, analizator stanów logicznych oraz debuger.
Więc kłania się punkt 1 - można zrezygnować z Arduino całkowicie, skoro nie oferuje żadnej dużej wartości.
Dokładnie tak. Przecież to był tylko pretekst do ewaluacji "hobbystyczne" vs "profesjonalnie" gdzie oba, to tylko inna odmiana dziadostwa, typowego dla embedded.
Prawie nigdy nie jest potrzebne, przy prawidłowych abstrakcjach na poziomie kodu i unit testach. Bez najmniejszego problemu mogę napisać kod obsługujący, powiedzmy, modbusa przy pokryciu po stronie hosta na poziomie 95% coverage, gdzie po stronie AVR znajduja się juz tylko gołe read/write do rejestrów uartu. Nie wiem gdzie tu miejsce dla oscyloskopu, to ostateczność.
To kwestia bardziej jakości kodu i umiejętności pisania abstrakcyjnego, ale blisko sprzetu.
Zaznaczam, że wbrew opini niedzielnych programistów C++, ta abstrakcja przychodzi z zerowym obciązeniem dla kodu wynikowego, nie pojawi się nawet instrukcja więcej.
Dokładnie do tego dążę.
Akurat to jest prawdziwe rozjaśnianie intencji ;)
I tu wchodzi jakiś tuzin znakomitych środowisk do pisania w C/C++. Bo tylko tyle potrzeba w 99% wypadków pisania kodu embedded.
Co innego gdy to jest hobbystyczne pisanie na ATTINY. Tam można sobie pomigać diodą w symulatorze, wiadomo. Ale czy to nie jest aby własnie "hobbystyczne"?
Wiadomo, że można (i powinno się) pisać na podstawie dokumentacji i bez uruchamiania kodu po każdej napisanej linijce. Chodzi o to, że praktycznie zawsze coś potem nie działa i wcale niekoniecznie z Twojej winy.
Nie tylko Modbus jest na świecie. Poza tym mówimy o styku programowania z elektroniką. Jeśli oscyloskop nie jest potrzebny, to jest to albo prosty projekt albo embedded wysokopoziomowe (odległe od sprzętu).
Wiadomo :)
W każdym razie ta część wątku zaczęła się od emulatora CPU. Arduino i tak go nie ma, więc nie ma co tu drążyć :)
Wracamy więc do początku wątku. Jeśli ktoś wybiera znakomite środowisko zamiast Arduino IDE, to nie ze względów religijnych ale dlatego, że jest ono... znakomite :)
Nie, dalej nie rozumiesz. Ja nie mówie o pisaniu zgodnie z dokumentacją i wymagania nieomylności.
Ja mówie o pisaniu kodu w sposób, który redukuje potrzebę debugowania w sprzęcie do zera lub blisko zera. To wymaga innych technik programowania, niż stosowane w embedded, w szczególności przeproszenia sie z C++ (przez co czeka nas przeczekanie obecnego pokolenia programistów embedded, jako że to problem białkowy).
Jest śladowo prawdopodobne, abyś dał radę znaleźć nowy bug w AVR. Miliony programistów Arduino raczej by go znalazły.
Ani jedno ani drugie. Możesz napisać skomplikowany projekt blisko sprzetu, w 95% pokryty testami po stronie komputera dev. To nie jest rocket science. To normalna praktyka pisania kodu na dowolną platoformę, od superkomputerów do attiny.
Debuggery hardwareowe to ostatecznośc. Jesli podczas pisania kodu musisz ich używać, to masz kiepsko napisany kod.
Zgodzę się, że czasami mogą być przydatne przy uruchamianiu kodu, ale zazwyczaj to oznacza, że coś jest spieprzone i nieprzetestowane wcześniej, lub błąd masz w konkretyzacji abstrakcji (gdzie zwyczajowo kodu wiele nie ma).
Nie bez powodu. Dzięki temu, że ma gotowe bibliteki, taki debug jest mało potrzebny.
Ale nie jestem przekonany, czy środowiska do embedded są znakomite. Jak na razie po kontakcie z kilkoma na przestrzeni 20 lat, uciekam na same słowa "embedded IDE".
Oczywiście nie mówię o bugach w AVR. Chodzi o to, że urządzenie nie składa się z samego MCU. Masz też różne inne układy, które mogą się zachowywać inaczej niż myślałeś lub mieć błędy. Przykładowo UART w Raspberry Pi wysyłał na początku transmisji dodatkową szpilkę, która mogła być traktowana jako bit startu. Nie było to nigdzie opisane. Pracując w embedded takie i inne kwiatki spotyka się cały czas.
To jest akademicka teoria. Powiedz twórcom GDB, że zmarnowali swój czas :) Debuger jest normalnym narzędziem i sięganie po niego nie musi wcale źle świadczyć o programiście. Jego brak jest ograniczeniem środowiska.
Piszesz o nich jak o bibliotekach libc. Tymczasem mają one nieraz błędy i słabą dokumentację.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.