Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki

p.kaczmarek2 09 Jan 2022 06:02 1518 11
Computer Controls
  • Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Witajcie moi drodzy.
    Przedstawię tu krok po kroku jak można zacząć przygodę z mikrokontrolerem EFM32 Zero Gecko na przykładzie EFM32ZG222F32 (ARM Cortex-M0+). Mikrokontroler ten uruchomię na uniwersalnej płytce startowej pod obudowę TQFP48, program pod niego skompiluję w Simplicity Studio, a wgrywanie wsadu odbywać się będzie poprzez bootloader UART. Nie będzie potrzebny do tego żaden zewnętrzny programator, bo użyty EFM32ZG222F32 ma już fabrycznie wgrany bootloader. To będzie pierwszy temat z serii poświęconej EFM i jak na razie obejmie tylko absolutne podstawy wymagane by wystartować z EFM32ZG222F32 bądź podobnym w oparciu o język C i Simplicity Studio.

    Hardware - niezbędne minimum
    Płytkę z EFM32ZG222F32 w obudowie TQFP48 przygotowałem wedle swojego opisu stąd:
    https://www.elektroda.pl/rtvforum/topic3853189.html
    Tamten temat zawiera również informacje gdzie można zakupić taki minimalny breakout TQFP48 z gotowymi zworkami/pętlami masy i zasilania.
    Na płytce miałem EFM32ZG222F32 + LDO 3.3V + drobnica (kondensatory odsprzęgające) oraz wyprowadzone BOOT_RX/BOOT_TX na przejściówkę USB na UART.
    Dodatkowo, uzupełniłem ją o kilka niezbędnych dodatków:
    - przycisk microswitch między pinem RESET (pin 16) a masą - do resetowania układu
    - diodę LED z rezystorem 470 omów do masy z wyjściem wyprowadzonym na kabelek stykowy (by móc podpinać ją pod dowolny pin IO) - by mieć czym migać
    - kabelek stykowy żeńsko-żeński z rezystorem (tj. rezystor z żeńskimi końcówkami stykowymi) - by móc łatwo dodać rezystor pull up na DBG_SWDIO (pin 38), tj. rezystor do zasilania, by wymusić stan wysoki na tym pinie oczekiwany przez bootloader (początkowo myślałem, że to nie jest potrzebne, ale bez tego miałem kłopoty z wykryciem płytki na UART, udawało się raz na jakiś czas tylko, dodanie tego naprawiło wszystko)
    Płytka z modyfikacjami:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki

    Software - instalacja Simplicity Studio
    Simplicity Studio możemy pobrać za darmo ze strony producenta. Na moment pisania tego artykułu pobierałem je stąd:
    https://www.silabs.com/developers/simplicity-...mplicityStudio-5.iso%7CSimplicityStudio-5.iso
    Musiałem w tym celu założyć darmowe konto na Silabs - nie ma z tym żadnego problemu.
    Pobrany plik to SimplicityStudio-5.iso. Jest to obraz płyty, trzeba go odpowiednio zamontować w wirtualnym napędzie CD/DVD.
    Do działań na plikach ISO polecam program Virtual CloneDrive:
    https://www.elby.ch/pl/download.html
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    "Montujemy" ściągnięty obraz ISO tak by pokazał się jako wirtualna płyta CD w naszym wirtualnym napędzie i instalujemy.
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Instalację zasadniczo musimy "przeklikać", z tym że na pewnym etapie będzie potrzeba zalogowania się oraz wybrania komponentów które chcemy zainstalować. Użyłem tam trybu "Install by technology type" i wybrałem mikrokontrolery 32-bitowe. Na tym etapie zainstalował się automatycznie GNU Arm Toolchain (v10.2.2020.q4), Gecko SDK - 32-bit and Wireless MCUs - 4.0.0, IAR ARM Toolchain Integration - 4.2.11. Szczegóły na zrzutach ekranu, kolejno z etapów instalacji:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Instalator pobierze wybrane paczki z sieci. Powinniśmy mieć stabilne łącze internetowe i troszkę cierpliwości, bo może to zająć nieco czasu.

    Software - instalacja TeraTerm oraz pierwszy test komunikacji UART
    TeraTerm jest to terminal UART (podobnie jak używany przeze mnie częściej RealTerm), który wspiera m. in. przesyłanie danych wedle protokołu XMODEM. Będzie to potrzebne do wgrywania wsadu przez bootloader.
    TeraTerm pobieramy stąd (teraterm-4.106 bądź aktualną wersję):
    https://osdn.net/projects/ttssh2/downloads/74780/teraterm-4.106.exe/
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki

    Simplicity Studio - pierwszy projekt (miganie diodą - blink led)
    Po uruchomieniu Simplicity Studio widzimy mniej więcej taki widok:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Mniej więcej, bo ja już mam dwa utworzone projekty.
    Klikamy File->New->Project:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Konfigurujemy projekt - pod Custom Board (własna płytka) z tym mikrokontrolerem jaki mamy:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Wybieramy typ - Example (tam są gotowe projekty):
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Na początek wybierzemy Blink, ale na screenie też pokazuję jakie inne są przykłady:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Nazywamy projekt:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    UWAGA! Tworzenie projektu zajmie dość dużo czasu, a przynajmniej w moim odczuciu, dość dużo czasu. Czekamy cierpliwie.
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Po dłuższym oczekiwaniu (na 30% postępu) mamy projekt:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Jak widać utworzyło nam nieco plików, zarówno .c jak i .h (kod C, nagłówek C). Możemy poświęcić chwilę na zapoznanie się z ich zawartością.
    Projekt kompilujemy przez Build:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Przy pierwszej kompilacji powinniśmy otrzymać niepowodzenie:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Brakuje zdefiniowania:
    - SL_SIMPLE_LED_LED0_PORT
    - SL_SIMPLE_LED_LED0_PIN
    Czyli nie określiliśmy czym będziemy migać (jaki port i pin).
    Widzimy też, że mamy Warning (ostrzeżenie), które również pojawia się w widoku plików projektu.
    Quote:

    C:\Users\admin\SimplicityStudio\v5_workspace\blink_baremetal_2\config/sl_simple_led_led0_config.h:37:2: warning: #warning "Simple LED Driver GPIO pin not configured" [-Wcpp]

    Można w ten sposób trafić do pliku, który trzeba uzupełnić:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Poprawione - kompilujemy drugi raz:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Sukces - 0 errors!
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Ale to nie wszystko. W celu użycia bootloadera musimy zmienić miejsce w pamięci Flash, gdzie umieszczać będzie się generowany kod programu. To dlatego, że bootloader umieszczony jest już na początku pamięci flash a nie chcemy przecież go nadpisać. Generowany przez nas kod będziemy umieszczać nieco dalej, za bootloaderem.
    W tym przypadku bootloader oczekuje naszego wsadu na offsecie 0x800, a nie na domyślnym 0x0.
    Opcję tę znajdujemy pod "Properties" projektu, reszta ścieżki na zrzucie ekranu:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Włączamy własne offsety i wpisujemy 0x800 (oraz zmniejszamy rozmiar programu o te 0x800, logiczne):
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Po tym kompilujemy ponownie projekt (jak nie jesteśmy czegoś pewni, to można dla zasady najpierw zrobić Clean a potem pełny Build).
    Wygenerowany wsad jest pod "Binaries". Wygodną opcją jest "Show In -> Explorer", otwiera po prostu katalog z binarką w Windowsie:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Nas interesuje plik bin (nie hex!). Zapamiętujemy do niego ścieżkę....

    Wgrywanie wsadu przez bootloader UART
    Wymagane połączenia były już omawiane, ale jeszcze je przypomnę:
    - musimy mieć przycisk RESET
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    - przejściówka USB-UART z poziomami logicznymi 3.3V ma być na BOOT_TX i BOOT_RX (oczywiście RX do TX, a TX do RX... wiadomo):
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    - dodatkowo pin BOOT_RX ma też rolę DBG_SWDIO, więc go dodatkowo poprzez rezystor 4.7k lub podobny podłączamy do 3.3V (robimy pullup)
    Przy szukaniu numerów pinów upewniamy się czy sprawdzamy w odpowiedniej tabelce, numery pinów dla QFN48 są inne niż np. dla QFN32!!!
    Podłączamy wszystko do komputera, resetujemy przyciskiem płytkę, w Tera Term wysyłamy duży klawisz U przy baudzie 115200:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Jak widać, mikrokontroler nam odpowiedział.
    Następnie wysyłamy pojedynczy mały klawisz u:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Następnie wysyłamy wygenerowany plik bin z Binaries poprzez File->transfer->xmodem->Send:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Tak wygląda wysyłanie:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
    Na koniec uruchamiamy ten wsad poprzez wysłanie pojedynczego b (na które mikrokontroler już nie odpowie, chyba, że w naszym wsadzie uruchomimy UART).
    LED powinien migać:

    Nasz pierwszy blink LED dla EFM32 działa!

    Rodziny wspierane przez opisany tu bootloader
    Temat ten zrealizowałem na przykładzie EFM32ZG222F32, bo akurat go miałem na stanie, ale opisany tu bootloader wspiera więcej rodzin układów.
    Układy z rodziny EFM32 Series 0:
    • EFM32 Gecko (EFM32G)
    • EFM32 Giant Gecko (EFM32GG)
    • EFM32 Wonder Gecko (EFM32WG)
    • EFM32 Leopard Gecko (EFM32LG)
    • EFM32 Tiny Gecko (EFM32TG)
    • EFM32 Zero Gecko (EFM32ZG)
    • EFM32 Happy Gecko (EFM32HG)
    Układy z rodziny EZR32 Series 0:
    • EZR32 Wonder Gecko (EZR32WG)
    • EZR32 Leopard Gecko (EZR32LG)
    • EZR32 Happy Gecko (EZR32HG)
    Układy z rodziny EFM32 Series 1:
    • EFM32 Pearl Gecko (EFM32PG1/EFM32PG12 Rev C onwards)
    • EFM32 Jade Gecko (EFM32JG1/EFM32JG12 Rev C onwards)
    • EFM32 Giant Gecko GG11 (EFM32GG11)
    • EFM32 Tiny Gecko 11 (EFM32TG11)
    Po szczegóły oraz aktualną wersję listy wspieranych układów odsyłam do aplikacji katalogowej Silabs AN0003.

    Alternatywny bootloader - przez USB
    Silabs oferuje również bootloader do mikrokontrolerów z interfejsem USB. Szczegóły na jego temat znajdziecie w AN0042. Być może też któregoś dnia przygotuję jego demonstrację.

    Dodatkowe komendy bootloadera UART
    Bootloader UART wspiera również generowanie CRC16 dla bieżącego wsadu (komenda v i pokrewne), jak i destruktywny upload wsadu (wtedy wsad zastępuje bootloader a my zapewne tracimy dostęp do mikrokontrolera - nie polecam z tym eksperymentować początkującym). Pełna lista poniżej:
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki

    Podsumowanie
    Naprawdę nie potrzeba dużo, by zacząć przygodę z EFM32. Opisany tutaj bootloader pochodzi z noty aplikacyjnej AN0003 i wspiera znacznie więcej układów, niż wybrany przeze mnie EFM32ZG222F32. Każdy może znaleźć coś dla siebie - szczegóły w załącznikach.
    Jak na razie tylko przygotowaliśmy środowisko pracy i nauczyliśmy się kompilować program oraz wgrywać wsad, cała przygoda dopiero przed nami.
    W drugiej części z serii spróbuję przedstawić nieco bardziej zaawansowane koncepty na EFM32ZG222F32 a może nawet pokuszę się o jakiś przykładowy projekt.
    Załączam dodatkowe materiały do zapoznania się oraz kopie instalek użytych programów.

    Cool? Ranking DIY
    Can you write similar article? Send message to me and you will get SD card 64GB.
    About Author
    p.kaczmarek2
    Level 26  
    Offline 
  • Computer Controls
  • #2
    spec220
    Level 24  
    Jak dla mnie strasznie jest to skomplikowane.
    W środowisku którym ja się posługuje jest o wiele prościej. Wystarczy np. AVR studio. Wgrywam bootloadera, albo sam plik hex z programem bez bootloadra. W przypadku wgrania bootloadera program wrzucam poprzez RS232, albo konwerter USB na RS232, bądź RS485 na RS232. (są też inne konwertery, ale nie korzystam)
    Samo środowisko programistyczne chodź ubogie w porównaniu z assemblerem, to jednak zabezpieczone, i nie ma możliwości przypadkowego nadpisania kodu bootloadera. No chyba że modyfikacji dokonam z poziomu AVR studio, bądź innej aplikacji dającej taką możliwość ... :)

    Dodano po 36 [minuty]:

    P.S
    Ja to nie rozumiem tego, czemu wciąż panuje idea pisania programów?
    To było dobre 40 lat temu, kiedy to zasoby tamtejszych komputerów nie pozwalały na stworzenie odpowiedniego interfejsu graficznego...
    W Polsce były próby zrobienia naprawdę dobrego interfejsu graficznego lada 2010-2013, ale jakoś to upadło, ze względu na brak zainteresowania.... Być może dlatego, że rozwinięcie takiego środowiska, o dodatkowe opcje oraz pełne możliwości stałoby się poważną konkurencją dla ideologii pisania programów, a nie ich rysowania.

    Tutaj prosty przykład mrugnięcia diodą timerem 1s wygenerowanego przez US z zewnętrznego kwarcu.
    Bardzo Szybko i bardzo prosto. 0 błędów, 0 ostrzeżeń.

    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki


    Mrugnięcie LED, to tylko przykład, ale można np. zrobić tutaj inteligentny sterownik do pieca CO bez pisania czegokolwiek, czego nauka może trwać nawet miesiącami... Tutaj po prostu "siadasz" instalujesz i od tak robisz po prostu programy, w porównaniu z pisaniem jakiś tam klamerek, kropeczek, "słówek" nic nie mówiących itp.

    Owszem są współczesne próby tworzenia programistycznych interfejsów graficznych, ale ich czytelność oraz przejrzystość/ możliwości jest tak słaba, i tak licha, w porównaniu z tym co próbowano zapoczątkować w 2010r. ze szkoda na to czasu... Ponadto to środowisko było dedykowane na gotowe sterowniki które można było kupić, jak również w postaci licencji na tzw. gołe procki...
  • Computer Controls
  • #3
    p.kaczmarek2
    Level 26  
    spec220 wrote:
    Jak dla mnie strasznie jest to skomplikowane.

    Nic nie stoi na przeszkodzie, by np. producent płytki developerskiej (albo sam użytkownik) zautomatyzował sobie opisany tu proces wgrywania nowego wsadu.

    Wystarczy dać na pokładzie płytki jakiś konwerter USB na UART, najlepiej z pinem DTR (jego użyć do RESETowania płytki) a następnie napisać software który po prostu zrobi cały proces wgrania wsadu automatycznie. Czyli wykryje kompilacje (może jakiś on build event), potem wykona przez UART komendy, wyśle plik (XMODEM), a potem wyśle te "b" by uruchomić płytkę. Wszystko w tle, za jednym kliknięciem.

    Tak samo przecież można zorganizować IDE które samo będzie ustalać offset flash, tak samo przecież dzięki możliwościom języka C/C++ można upakować skomplikowane funkcje w ładne digitalWrite albo inputMode i analogWrite by użytkownik nie wiedział nawet, że są porty czy tam, że jest ADC...

    No cóż, chyba przez przypadek odkryłem Arduino. (Poczytajcie jak działa Arduino, czym tak naprawdę jest digitalWrite, itp. jak to wszystko ma się od zaplecza)

    Reasumując - te "skomplikowane" procesy dalej są, po prostu jak masz gotowe środowisko to ich nie widzisz.

    spec220 wrote:

    Ja to nie rozumiem tego, czemu wciąż panuje idea pisania programów?
    To było dobre 40 lat temu, kiedy to zasoby tamtejszych komputerów nie pozwalały na stworzenie odpowiedniego interfejsu graficznego...


    W przypadku blink pewnie i masz rację, ale jak dotrzesz na etap czegoś bardziej skomplikowanego to zmienisz zdanie.
  • #4
    spec220
    Level 24  
    p.kaczmarek2 wrote:
    W przypadku blink pewnie i masz rację, ale jak dotrzesz na etap czegoś bardziej skomplikowanego to zmienisz zdanie.

    A czy tego "czegoś bardziej skomplikowanego" nie można przedstawić za pomocą bloku graficznego? W środowisku w którym się posługuję też niektóre sprawy trzeba robić tzw. Tabelą zmiennych binarnych, czy też tabelą całych wartości. (Czasem można się naprawdę pogubić przy dłuższym ciągu) Ale nadal jest to blok graficzny który jak już raz zrobię, wiem jak działa to mogę sobie swobodnie go zaimplementować w określonym fragmencie programu nie wnikając co się w tym bloku znajduje i jak się "kręcą" w nim zmienne.

    Mi się tylko rozchodzi o kompleksowe przetłumaczenie C, czy też assemblera na interfejs graficzny, a 0-1 jedynkami to już sobie poradzę, bo są różne metody ich rozpisywania, o ile trzeba będzie zrobić blok graficzny posiadający tabelę wymagającą takiej funkcji... Metodą tabeli 0,1 można wszystko zrobić. Każdy sterownik, niestety środowiska graficzne mają tą funkcje mocno obkrojoną, w porównaniu do assemblera.
  • #5
    oskar777

    Level 26  
    Na własnym doświadczeniu stwierdzam, by bawić się ARM trzeba:

    1.Znać dobrze C i to sporo więcej niż podstawy
    2.Znać bardzo dobrze angielski techniczny
    3.Znać niuanse danego mikrokontrolera i czytać dobrze dokumentację.

    Długo spędziłem nad STM32F0 udało mi się uruchomić wiele modułów tego MK co sprawiło mi wiele radości ale prawda jest taka, że na prawdę wiele czasu na to poświęciłem a i tak byłem na początku drogi. Teraz siedzę głównie na Arduino i ESP i wbrew pewnym opiniom biblioteki dostarczane przez społeczność działają bardzo stabilnie na pewno lepiej niż jak by je napisał.
  • #6
    spec220
    Level 24  
    oskar777 wrote:
    Na własnym doświadczeniu stwierdzam, by bawić się ARM trzeba:

    1.Znać dobrze C i to sporo więcej niż podstawy
    2.Znać bardzo dobrze angielski techniczny
    3.Znać niuanse danego mikrokontrolera i czytać dobrze dokumentację.

    To przy graficznym programowaniu jest tak, że siadasz i programujesz z dnia na dzień... Trzeba tylko wiedzieć jak działają bramki, liczniki, przeliczniki, timery, tablice itp.... Gdyby C posiadało dobrą nakładkę graficzną, to myślę że zaoszczędziłbyś wiele czasu.... Osobiście o ile środowisko mnie do pewnych spraw nie ograniczy, to mogę zrobić w zasadzie każdy algorytm jaki jest mi potrzebny...
  • #7
    fotomh-s
    Level 23  
    oskar777 wrote:
    Na własnym doświadczeniu stwierdzam, by bawić się ARM trzeba:

    1.Znać dobrze C i to sporo więcej niż podstawy
    2.Znać bardzo dobrze angielski techniczny
    3.Znać niuanse danego mikrokontrolera i czytać dobrze dokumentację.


    W zasadzie to ja osobiście nie widzę tutaj problemu. W Arduino IDE każdy może zaprogramować STM-32, przesiadka z AVR nie jest tutaj trudna.
    Jeśli ktoś chce implementować już bardziej złożone rzeczy to zawsze może się podszkolić. Moim zdaniem ludzie unikają tych MCU i nadal stosują AVRy gdzie popadnie bo się boją przesiadki, której nie należy się obawiać.

    spec220 wrote:
    Ja to nie rozumiem tego, czemu wciąż panuje idea pisania programów?
    To było dobre 40 lat temu, kiedy to zasoby tamtejszych komputerów nie pozwalały na stworzenie odpowiedniego interfejsu graficznego...

    Ja osobiście brzydzę się tego typu programowaniem.
    Próbowałem tak programować FPGA w Quartus IDE i jakoś chyba wolę klepać kod w Verilogu, mimo tego że FPGA dużo bardziej pasują do graficznego stylu programowania niż mikrokontrolery.
    Jak dla mnie kod jest bardziej przejrzysty niż jakaś "pajęczyna". CPU wykonuje kod maszynowy instrukcja po instrukcji, w wysokopoziomowym języku programowania kod jest wykonywany linijka po linijce, więc jest to dobra analogia do tego co się dzieje w samym CPU.

    Środowisko graficzne w moim przypadku świetnie się nadaje do tworzenia GUI i właściwie niczego więcej, chociaż bez tego też da się żyć (np. GUI w Pythonie, albo BREXX na MVS 3.8 i tworzenie paneli dla terminali serii 3270).
  • #8
    spec220
    Level 24  
    fotomh-s wrote:
    Jak dla mnie kod jest bardziej przejrzysty niż jakaś "pajęczyna". CPU wykonuje kod maszynowy instrukcja po instrukcji, w wysokopoziomowym języku programowania kod jest wykonywany linijka po linijce, więc jest to dobra analogia do tego co się dzieje w samym CPU.

    Jaka pajęczyna? robisz blok po bloku, i je łączysz... W graficznym też pętle są wykonywane zgodnie z procedurą którą ustalisz od tzw. procedury START. O ile nie ustalisz kolejności pętli, kompilator sam je zadeklaruje z tym że w niektórych przypadkach program nie będzie działać jak należy... Są pętle których kolejność musisz zadeklarować, a są takie, że nie ma to większego znaczenia, chociaż możesz w symulatorze podejrzeć w jakiej kolejności je wykonuje program...

    Ponadto niechlujnie napinany program jest tak samo mało czytelny co niechcenie zrobiona grafika...

    Tutaj masz przykład grafiki timera 3 kanały możliwość ustawienia indywidualnej charakterystyki A,B,C,D oraz stanu logicznego inicjującego zegar L, lub H
    Moim zdaniem aż takiego "bajzlu", czy jak to tam nazwałeś "pajęczyny" nie ma...

    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki
  • #9
    fotomh-s
    Level 23  
    Pajęczyna jest, bajzlu faktycznie nie ma.
    Chodzi mi o pewną logiczną analogię. W przypadku kodu jest on bardziej logiczny i naturalny ze względu na to jak działa sam CPU.
    W przypadku schematów jest on naturalny i logiczny dla FPGA, bo tam tworzymy de facto połączenia sprzętowe.
    Dla mnie jednak kod jest o wiele bardziej przejrzysty, nie ważne jak czysto będzie wyglądał schemat, nawet w przypadku FPGA.
    Na schemacie który przedstawiłeś nadal nie mam pojęcia co jest w jakiej kolejności wykonywane.

    Jeśli chodzi np. o niektóre urządzenia to wolę opisy w języku Angielskim, chociaż jestem Polakiem i nigdy nie byłem ani w UK ani w USA. Z jakiegoś powodu jest jednak przyzwyczajenie do pewnych rozwiązań. Tak samo z różnicą między samolotami i samochodami. W samochodach masz kontrolki z symbolami, w lotnictwie masz opisy, kiedy ktoś zamienia tą kolejność to robi się zamieszanie wynikające ze zrywania z pewnymi standardami na siłę. To tak jakby dyskutować czy np. nie zastąpić kierownicy drążkiem, albo pedału hamulca w samochodzie dźwignią.
  • #10
    spec220
    Level 24  
    fotomh-s wrote:
    Na schemacie który przedstawiłeś nadal nie mam pojęcia co jest w jakiej kolejności wykonywane.

    Dlatego że tego nie opisałem. Jednak jest możliwość sprawdzenia z poziomu symulatora PC, albo bezpośrednio po komunikacji z US...
    Oczywiście jest możliwość zadeklarowania kolejności, bo niejednokrotnie jest to kluczowym elementem poprawności działania programu. Jeżeli nie zadeklarujesz kolejki, to kompilator zrobi to za Ciebie, z tym że nie zawsze jest to dobre.
    Kolejności też się nie oznacza z innego powodu, jakim jest wywołanie odnoszące się do określonej pętli. Możesz np. zrobić program podzielony na trzy niezależne pętle które zostaną np. wykonane w takiej kolejności w jakiej zostały zainicjowane z zewnątrz. (Przykład na schemacie to wejście 5, 7,8)

    Poniżej przykład w którym zadeklarowałem taką kolejność wykonywanych działań. Akurat w tym miejscu nie ma ona większego znaczenia, aczkolwiek program lepiej się prezentuje wizualnie...
    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki

    W programowaniu graficznym panuje nowa ideologia robienia algorytmów. Tam gdzie nie jest to konieczne po prostu nie narzuca się kolejki bo jest ona przypisywana z automatu. I jest to spore ułatwienie. W dawniejszych (starszych) kompilatorach graficznych musiałeś jechać numerowo wszystkie zmienne poczuwszy od procedury START. Było to trochę męczące, a i cały program kręcił się w jednej głównej pętli...
  • #11
    Damian_Max
    Level 15  
    Jeśli nad projektem pracuje kilka osób, to łatwiej (nie znaczy łatwo) będzie łączyć zmiany w tekście niż zmiany w graficznej reprezentacji.
    Mimo że ta graficzna reprezentacja pod spodem zapewne też jest zapisana w tekście, to łączenie tam zmian dwóch osób nie będzie intuicyjne -- chyba że autor oprogramowania dostarczyłby jakiś specjalny tool do tego (jeśli ktoś taki widział w oprogramowaniu z graficznym interface to podajcie link, z ciekawości zapoznam się z tym jak to rozwiązali).
  • #12
    spec220
    Level 24  
    Damian_Max wrote:
    Jeśli nad projektem pracuje kilka osób, to łatwiej (nie znaczy łatwo) będzie łączyć zmiany w tekście niż zmiany w graficznej reprezentacji.
    Mimo że ta graficzna reprezentacja pod spodem zapewne też jest zapisana w tekście, to łączenie tam zmian dwóch osób nie będzie intuicyjne -- chyba że autor oprogramowania dostarczyłby jakiś specjalny tool do tego (jeśli ktoś taki widział w oprogramowaniu z graficznym interface to podajcie link, z ciekawości zapoznam się z tym jak to rozwiązali).

    Ależ oczywiście że w nowoczesnych nakładkach/ środowiskach graficznych MOŻE pracować kilka osób... Zwróć uwagę na bloki;
    Menu, lcd, eep, edx, timer... Żaden z tych bloków nie znajduje się w oryginalnej bibliotece Vamrafa... Wszystkie te bloki są moim autorstwem... Jeżeli kilka osób pracowałoby nad jednym programem w tym środowisku, to każda z tych osób mogłaby pracować nad swoim blokiem w uzgodnionej wcześniej wspólnej architekturze programu... Na koniec łączysz ze sobą wszystkie bloki razem (poszczególne fragmenty kodu) i masz gotowy program... Jeżeli coś jest nie tak w którymś miejscu, to osoba która najlepiej zna architekturę tworzonego przez siebie bloku po prostu go modyfikuje, gdzie ostatecznie metodą kopiuj/ wklej nanosisz poprawki do całego programu....
    Przykład poniżej rozpakowanego bloku "timer"

    Tutorial EFM32 ARM Cortex-M0+- cz1, bootloader, pierwsze kroki

    Ten akurat jest prosty. (nie chcę z góry zniechęcać do graficznego programowania naprawdę złożoną architekturą bloków)