Witam,

Tak się zastanawiam od czego bardziej doświadczeni koledzy zaczynacie pisanie programu? Jakieś proste to wiadomo, często nie wymagają przygotowań ale co jeśli zamierzamy napisać program mocno rozbudowany? Robicie jakieś plany, schematy poszczególnych funkcji? Czy po prostu wszystko na żywioł?

pozdrawiam

1. Złożony problem trzeba rozbić na mniejsze wtedy łatwiej nad tym zapanować.
2. Warto sprawdzić czy są jakieś gotowe biblioteki, bo nie zawsze warto wszystko wymyślać od nowa, ale wiadomo jak czegoś używać to z głową.
3. Testować program etapami. Kolejno dodając nowe funkcjonalności, nowe moduły do konkretnych zadań, peryferii czy zewnętrznych układów.
4. Pisać od razu "czysty" kod z komentarzami.

_________________
Dragonus Cracovus: Biomagia

zależy ja zaczynam od zbierania koncepcji
potem się zastanawiam nad słusznością pomysłów
rozpisuję założenia i po kolei dodaję części kodu

Piszę tak by można było każdą opcje testować na bieżąco

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Ja do słusznych uwag kolegów dodam jedno

Pisanie na żywioł (a często każdy z nas ma taką pokusę) - najczęściej prowadzi do jednego .... No bo przecież zwykle piszemy "na żywioł" żeby było szybciej - a przez to - tak naprawdę - tworzenie programu trwa zwykle MINIMUM DWA RAZY DŁUŻEJ .... niż gdyby zacząć od tego żeby

1. usiąść , odprężyć się - ew wziąć łyk piwa lub innego zacnego trunku dla rozjaśnienia umysłu (o ile oczywiście mamy ukończone 21 lat)

2. a na poważnie - to zawsze warto rozpocząć od kartki papieru i ołówka
3. opisaniu koncepcji
4. stworzeniu algorytmu - nawet na początek bardzo ogólnego
5. wcześniej warto także przetestować albo napisać biblioteki, którymi będziemy się mieli zamiar posługiwać
6. podzielić program na kawałki tak aby móc go testować od razu krok po kroku
7. przygotować szczegółowy algorytm albo algorytmy trudniejszych zagadnień

Już samo to powoduje, że w głowie inaczej się wszystko układa i z tej prostej perspektywy zobaczymy wiele rzeczy o których nawet nie mamy pojęcia podchodząc "na żywioł"

a przede wszystkim - wbrew pozorom później pisanie kodu idzie można powiedzieć jak z płatka

_________________
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 ]

No właśnie zaczynam pisać coś dużego jak na moje możliwości i co chwila łapie się na tym, że im dalej w las tym więcej grzybów

Bo tak naprawdę jak się zrobi dobry, przemyślany algortym to potem wystarczy to ubrać w słowa odpowiedniego języka ... nie ważne czy to C czy coś innego ... Ja na razie robiłem tylko kilka (dwa to już kilka? ) projektów od 0 i zdecydowanie nakreślenie algortymu moim zdaniem odgrywa kluczową rolę.

_________________
Wysłane z nowego ATB 1.05beta + ATB ETHERNET

A jak u Ciebie wygląda nakreślenie?

A ja tylko dodam jako bardzo nie doświadczony ( czyli uczący się ) , że na etapie koncepcji bardzo ważny jest wstępny schemat elektroniki, ponieważ jeżeli nie będzie dobrze przemyślana to bardzo mocno może skomplikować sam program .
I jak dla mnie te dwa zagadnienia powinny być prowadzone równolegle ...

Niestety dokładne mierzenie sił na zamiary to podstawa , ja mam tak że muszę być elastyczny
często podczas 1 etapu tworzenia projektu powstają 2 -3 platformy oparte o różne procesory
bo to niestety też istotna sprawa by dobrze wybrać odpowiedni mikrokontroler do danego zadania

U mnie nie wchodzi w rachubę tylko wybór jakiegoś AVR-a ... bo z mojego punktu widzenia
nie jest ważne czy będzie to m8 czy m128 , ale różne całkiem od siebie wymagające innego
traktowania bo i PIC i ARM i DSP ... dodatkowo muszę się szybko uczyć nowych rzeczy .

To droga poprzez mękę czasami , ale dobry wybór często procentuje lepszym efektem
końcowym, a przemyślana konstrukcja np na STM32 wcale nie jest bardziej skomplikowana
od tej na ATmedze czy PICu.

Na początek musisz sie nauczyć z góry planować zasoby z nadmiarem ... zawsze łatwiej
bazować na większym procku na początku.

np zakładając użycie M32 robisz na m644 masz więcej zasobów i łatwiej się nie wykoleisz

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Zhan - nie pokażę z prostego powodu Wstyd mi za nie, bo powstały jeszcze dużo przed Mirkową książką i peeeeełno w nich delay Teraz rozwiązałbym to inaczej więc nie będę pokazywał, bo jeszcze ktoś zacznie się na tym wzorować i pędzie klops ... no ale chyba każdy wie jak wygląda algorytm...



Jest już po 22-giej ... jeśli zbyt wulgarne to do rana można podmienić na coś lepszego

_________________
Wysłane z nowego ATB 1.05beta + ATB ETHERNET

No to i ja...
1. Biorę przed oczy schemat urządzenia
2. Zaczynam pisać funkcję _INIT() - konfiguracja wejść/wyjść, ustawienie zezwoleń na przerwania itd. itp.
3. Poniżej wpisuję sobie coś takiego:

4. Jak już to mam to wybieram timer na którym akurat nie mam PWM'a albo na którego wejścia nie wykorzystuję jako licznik sprzętowy i piszę sobie procedurę przerwania do obsługi zegara systemowego + timery programowe ustawiające flagi w odpowiednich odstępach czasu. Tutaj też ustalam listę zdarzeń jakie chcę obsłużyć i uzupełniam pętlę główną o wywołania tych zdarzeń.
5. Piszę deklaracje i szkielety funkcji np.

6. Jak już wiem co i kiedy się będzie wykonywać zabieram się za pisanie obsługi poszczególnych zdarzeń zaczynając od tych najbardziej niezbędnych do działania urządzenia...
7. Po napisaniu obsługi zdarzenia programuję procka i sprawdzam działanie. Jeżeli ok - piszę obsługę kolejnego zdarzenia.
8. i tak aż do końca dodając kolejne coraz mniej ważne, a czasem tak na prawdę zbędne funkcje
9. Wówczas zwykle okazuje się, że wybrany procesor ma za mało pamięci programu i/lub RAM i zaczyna się odchudzanie, ale nawet jak ono możliwe to funkcje podstawowe mam już napisane i przetestowane i mogę je przenieść na większy procesor dopisując kolejne.
10. Fajrant!

_________________
Czekamy na RedBook'a!

Sam robię podobnie jak Mirek, a że się dopiero uczę, to rozbijam problem na wiele mniejszych i wiecznie jestem niezadowolony .
Spisuje sobie na kartce, zeszycie (pomysłów) co i jak, tj. jaki problem i jak go ugryźć.

Ostatnio próbuję opanować skuteczną metodę pisania biblioteki obsługi układu od podstaw tj. od przeglądania datasheeta po gotową bibliotekę...
Ewentualnie jak by ktoś miał jakieś dodatkowe rady do tego tematu, przyjmę na klatę.

Nie warto na początek porywać się na zbyt duże projekty, a jak już to rozbić w czasie na mniejsze....

To jest bardzo cenna uwaga, bo czasem dodatkowo ktoś jeszcze idąc na ten "żywioł" napisze najpierw bez żadnego testowania pośredniego 5 tysięcy linii kodu - i dopiero wtedy włącza kompilację i wielkie zdziwienie że pojawiło się 1342 warnigów oraz 867 błędów .... hmmm dlaczego ????

a najlepsze jest gdy później taka osoba wpada na jakieś forum, wkleja te kilogramy kodu, i zadaje jedno proste pytanie:

"napiszcie mi proszę co tu nie działa ok?"

_________________
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 ]

A ja jako człowiek wyluzowany mam jeszcze inne podejście. Ponieważ konstruuję w 90% modułowe urządzenia zasilane bateryjnie używam z reguły wolnych zegarów. Rozdzielam projekt na 2-4 pomniejsze zadania i każdemu przydzielam oddzielne procesory bo są tanie. Np. Interfejs użytkownika ma u mnie zawsze oddzielną kostkę, która bardzo czule i niezależnie od wszystkiego zajmuje się kontaktami z otoczeniem a następnie wyświetla i wystawia wynik. Odczytuję go i biorę pod uwagę tylko wtedy kiedy mi potrzeba. Z innymi zadaniami jest podobnie. Ja po prostu traktuję procesorki jak każde inne scalaki. Moje projekty są zawsze wyluzowane, szczęśliwe i z odpowiednim dystansem, podobnie jak ich autor. Nie wiecie jak przyjemnie jest patrzeć na szczęśliwą i uśmiechniętą płytkę. Poszczułbym psami tych którzy znęcają się nad atmelkami zmuszając je do bucowatej roboty.

No ale co za problem ? każdy robi jak mu wygodnie .... czy ktoś coś komuś narzuca ? można podzielić nawet na 5-10 mniejszych zadań jak ktoś woli.

_________________
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 ]

i wszystko upchać w picach 10F dopiero wyjdą malutkie płytki uśmiechnięte

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Z doświadczenia (nie koniecznie w programowaniu) widzę że wydrukowanie/napisanie informacji o głównych "elementach" czy to wyprowadzenia uC, czy wymiary obudowy, czy średnice śrub - zawsze znacznie przyspiesza projektowanie Chodzi o to żeby mieć wszystko "na widelcu". Jeśli chodzi o programowanie/projektowanie na komputerze to dobrze mieć też drugi monitor
Ale nie wiem czy nie wyjechałem po za temat

Dla mnie drugi monitor to ostatnio podstawa....
Zbieram wszelkie materiały związane z projektem, drukuje podstawowe dane z PDFów, np. ostatnio wymiary wyświetlaczy LED, tworzę prototyp na uniwersalnej, piszę trzon programu by tylko zadziałało, następnie projektuje PCB, eksportuje do .step, daje kumplowi który w firmie zajmuje się projektowanie obudowy w solidedge, ja dalej wprowadzam poprawki w PCB związane z mocowaniem itp.
Potem dopracowuje soft, a w między czasie czekamy na obudowę...

Dodam tylko że osobiście przejechałem się kilkakrotnie na metodzie "na żywioł " - cisnąłem układem z Atmegą o ziemię , miernikiem i strzeliłem nawet raz z "barana" w ścianę, dałem sobie nawet spokój na dłuższy czas z programowaniem - zniechęciłem się na maxa.
Jak wcześniej napisał Mirek KARTKA OŁÓWEK I RYSOWANIE TU JEST METODA NO I POKORA (z tym czasami ciężko). Z tego co wyżej napisali bardziej doświadczeni programiści to zaznaczyłbym jeszcze - Zrozumienie zadania przed którym jesteśmy w momencie gdy podejmujemy się stworzenia elektroniki i programu. Jak układ ma działać czym sterujemy co jest zadajnikiem a co odpowiedzią itd. Jednym słowem Fizyka . Czasami warto bardziej rozbudować elektronikę a mniej program - tu najczęściej idę na kompromis z moim kolegą czystym elektronikiem ( jak opracowywaliśmy układ sterowania dzwonem zabrakło mi POKORY, twierdziłem że pewne aspekty obejdę programowo i 3 układy testowe poszły do "koszalina". w końcu jednak rozbudowaliśmy elektronikę a kod programu zajął kilkanaście linijek - dzwon w automacie bez zająknięcia buja się już 3 rok) Na koniec dodam co prawda może nie na temat, ale finalnie każdy układ elektroniki powinien( moim zdaniem )być wykonany na laminacie a nie na jakiejś płytce uniwersalnej w pająku z setką kabli - tzw. "odwalanie świniny" też się nie popłaca coś się przerwie ( nie mówiąc o zakłóceniach ) przy montowaniu i wtedy jest płacz i zabawa w "Indianę Jones'a poszukiwacza zaginionej Arki" - estetyka wykonanej "roboty" też się liczy. Jak mi kiedyś dr na Polibudzie powiedział jak zobaczył działający układ w pająku " I co z tego że działa ? To co odwaliłeś to jest ROSJA i dostałem 3 "

No nie wiem... pajONki są ostatnio w modzie... topic1560.html działa, u mnie kolega Jaglarz miałby 5

Ja absolutnie nie neguję robienia pająków w ramach testów - zresztą kolega Jaglarz napisał:

Na pytanie czy np. w samochodzie chciałbyś mieć tak zainstalowany dajmy na to alarm musisz odpowiedzieć sobie sam

Niestety czasem się okazuje, że wykonanie i zaprojektowanie PCB to najdroższa część całego urządzenia.
Sam często robię na uniwersalnych, ale z zachowaniem porządku, nie upycham wszystkiego w jednym miejscu.