Po skompletowaniu narzędzi przyszedł czas na...

[mes mariusz]

Prośba o informację, do czego (jakie numery EDW) odnosi się wstęp artykułu (maj 2016, str. 34):



Pozdrawiam
Mariusz

[m75]

Witam.
Zapewne autor miał na myśli skompletowanie zestawu uruchomieniowego tj.
płytki z prockiem + programator + zasilacz + komputer PC lub laptop .
Wszystko można znaleźć na znanych portalach aukcyjnych zarówno polskich jak i zagranicznych.
Pozdrawiam.

[mes mariusz]

Zakładam, że autorowi chodziło o jakiś konkretny, omówiony w poprzednich numerach zestaw uruchomieniowy. Chciałbym wiedzieć jaki to zestaw miał autor na myśli, i w których numerach był opisywany (tak, wiem, że na rynku jest ich mnóstwo, a jednak...).

Rozpoczęcie tekstu od "mamy już narzędzia" brzmi jak kontynuacja czegoś, co miało miejsce w przeszłości. Nie wskazanie na konkretną przeszłość pozostawia niesmak.

[Jony130]

Płytka
https://sklep.avt.pl/avt3510.html
I program Atmel studio 7 02/2016
Ale w kwestii oprogramowania jest pełna dowolność.

[grzegorzn]

Zgłasza się autor

Jak najbardziej jest to kontynuacja i nie powinno być niesmaku Jest jak pisze Jony130:
EdW 1/2016 - płytka testowa do kursu
EdW 2/2016 - Atmel Studio i programatory
EdW 3/2016 - artykuł innego autora rozszerzający tekst z numeru lutowego

[Wojtek]

Witamy autora i liczymy na obecność i wyjaśnienia jeśli się takie pojawią

[grzegorzn]

Oczywiście

[mes mariusz]

Skoro udało się złapać autora... To taka moja sugestia / prośba

Praktycznie każdy kurs / poradnik programowania w języku C wspomina o możliwości współtworzenia kodu przez wielu programistów - budowania programu z wielu niezależnych bloków. Bywa, że jest to informacja wtrącana przy okazji omawiania zasięgu / widoczności zmiennych. Jako, że jest to wtrącenie / ciekawostka - zazwyczaj nie rozwija się tematu.

Przydałby się oddzielny poradnik / odcinek (z odpowiednio dużą liczbą przykładów) na temat kultury pisania / składania kodu z modułów pisanych przez "zewnętrznych programistów", wydzielania części kodu do oddzielnych plików z podaniem przykładów z życia, gdzie może to być mniej czy bardziej użyteczne.

Mam wrażenie, że zazwyczaj ucieka się od tematu, albo zostawia gdzieś na szary koniec (albo omawia niejako "przy okazji", przez co trudno temat odszukać). Tymczasem chyba dobrym pomysłem byłoby od tego zacząć (omówienie zasad fragmentacji kodu, wydzielania, inkludowania, nagłówków, źródeł, bibliotek).

A jak tam pozostali? Też macie wrażenie, że (generalnie) w poradnikach brakuje solidnego omówienia tego tematu ?

[grzegorzn]

Temat jest jak najbardziej ważny i będzie poruszony w odcinku 5. Zagadnienia organizacji kodu czy stylu pisania będą się przewijać w kursie.

Niemniej EdW jest kierowana do hobbystów, a ci z reguły nie programują w zespołach i nie tworzą dużych projektów. Dlatego też podobnie jest w innych kursach, które z reguły są dla początkujących. Tutaj założeniem jest przede wszystkim zaznajomienie z programowaniem osób, które nigdy nie programowały albo znają Bascom.

Tak naprawdę zagadnienie jest szerokie:
- architektura oprogramowania
- organizacja kodu w funkcje i biblioteki
- zarządzanie wersjami i współdzielenie kodu (np. git)
- testowanie
- tworzenie dokumentacji (np. Markdown)
- udostępnianie skompilowanych bibliotek
Trzeba by się zastanowić ile z tego powinno znaleźć się w EdW.

[mes mariusz]

Myślę, że nie chodzi o wdrażanie w stricte programowanie zespołowe (choć na pewno przyjemnie byłoby na ten temat poczytać - może po prostu to pomysł na oddzielny artykuł). Myślę, że chodzi głównie o to by nawet początkujący programista miał świadomość możliwości wydzialania kodu do zewnętrznych plików i inkludowania ich w miarę potrzeby, celem przejrzystego zarządzania i rozwoju własnego projektu. Fajnie byłoby gdyby widział w tym wymierną korzyść dla siebie (nie tylko wiedział o takiej możliwości, ale i chciał z tej możliwości korzystać.

Załóżmy sytuację, gdzie autor pisze soft dla jakiegoś sterownika automatyki, z którym za pomocą komend słanych po UART może komunikować się dowolny komputer. Załóżmy, że autor rozwija 5 równoległych wariantów urządzenia, różniących się listą obsługiwanych poleceń (możliwościami, funkcjonalnością modułu).

Niech każde polecenie będzie osobym, inkludowanym w razie potrzeby kawałkiem kodu C. Dzięki temu (inkludując wyłącznie to co potrzebne dla danego modułu) można oszczędzać pamięć mikrokontrolera (inkludując przed kompilacją co trzeba, bez grzebania się, odszukiwania fragmentów kodu, komentowania dziesiątek linii itd.

Można też znacząco ułatwić sobie życie, dodając (pisząc) kolejne polecenie / kolejną funkcjonalność w zewnętrznym pliku, a później zaledwie inkludując tę funkcjonalność do istniejącego projektu.

Nawet pisząc pliki wsadowe .bat, czy skrypty bash w linuksie często posługuję się inkludowaniem fragmentów tekstu, kodu osadzonych w zewnętrznych plikach. To samo dotyczy konfiguracji skryptów (odrębny plik config.txt w którym porsonalizujemy stałe, wykorzystywane następnie przez kod główny, którego wcale nie musimy ruszać przed zaaplikowaniem skryptu / rozwiązania na nowej maszynie / dla nowego użytkownika itd. Przykładowo jeśli mądrze podejdziemy nawet do tak prozaicznej sprawy jak napisanie pliku wsadowego .bat umieszczając wszystkie komunikaty systemowe / dialogi w zewnętrznym pliku np. lang.pl - to zmiana języka (komunikacja skryptu użytkownika ze skryptem) będzie formalnością (zainkludowanie np. lang.en w miejsce lang.pl). Jeśli programista nie pomyśli o tym od razu, wypuszenie wersji w innym języku okaże się zadaniem karkołomnym.

Moim zdaniem warto zadbać o jak najbardziej praktyczne podejście do tematu (nawet dla programisty singla, nie koniecznie zespołu), ale mimo wszystko obszernie i wyczerpująco potraktować temat, tak by młody programista potrafił pomóc sobie (sam nie zgubił się w kodzie), oszczędził sobie zbędnych wysiłków i irytacji, a równolegle nie zamęczał mało czytelnie zredagowanym kodem kolegów, których ewentualnie poprosi o pomoc.

Stąd mój głos o wyczerpujące (w miarę możliwości) potraktowanie tematu (czyli niech to nie będzie tylko kosmetyczna wstawka / wzmianka)

Pozdrawiam
Mariusz

[grzegorzn]

Jak wspomniałem, temat będzie poruszony w odcinku 5 (wrześniowym) i będzie się przewijać w kolejnych odcinkach. Przykładowe programy będą coraz większe, więc rozbijanie ich na pliki i związane z tym włączanie plików nagłówkowych będą stałym elementem kursu.

[mes mariusz]

Dobrze wiedzieć.

Zapodam jeszcze ciekawostkę - kod Kod z EDW (kurs C) 5/2016 str. 36:

Kod: Zaznacz cały

#include <avr/io.h>
#include <util/delay.h>

int main (void) {
   while(1) {
      PORTB = _BV(PB0);
      _delay_ms(250);
      PORTB = 0;
      _delay_ms(250);
   }
}

Poprawnie kompiluje się w AtmelStudio, a w Eclipce na przykład już nie. Mi jak na razie nie udało się odgadnąć dlaczego:

https://forum.elportal.pl/viewtopic.php?t=13677

[Wojtek]

Poprawnie kompiluje się w AtmelStudio, a w Eclipce na przykład już nie. Mi jak na razie nie udało się odgadnąć dlaczego:

Mam prośbę nie wprowadzaj wątków do danego tematu - a masz taką. no manierę, widzę - zakładaj po prostu temat dotyczący danego problemu, a nie mieszaj różne tematy, nawet jak jesteś autorem.

[tibosizz]

Płytka

I program Atmel studio 7 02/2016
Ale w kwestii oprogramowania jest pełna dowolność.