Wiem że może i zły dział, ale napewno najpopularniejszy, a zależy mi na ożywionej dyskusji Jeżeli modkowie będą mieli wielki żal to można przenieść.
Ale do rzeczy. Chciałbym się dowiedzieć jak programują forumowi wyjadacze, mianowicie czy preferujecie kolejność "od góry do dołu" bądź "od ogółu do szczegółu, czy na odwrót? Wolicie najpierw tworzyć pojedyncze funkcje działające bezpośrednio na sprzęcie, czy najpierw zająć się szkieletem programu? Sam preferuję pierwszą opcję, ale chętnie wysłucham bardziej doświadczonych progamistów Pozdrawiam.

Wysłane z mojego Transformer TF101 przy użyciu Tapatalka

_________________
sig off ;(

Ja zaczynam od algorytmu jak program ma dzialac. A pozniej tworze poszczegolne funkcje - sprawdzajac ich dzialanie. Na koniec zamykam wszystko w calosc - a w zasadzie w calosc sie samo zamyka bo konczac to co zapisalem sobie w algorytmie program jest gotowy do dzialania ;P

Oczywiście jakaś fajna muzyka w tle i coś do picia musi być
Zależy od programu:
- małe krótkie programiki siada się i pisze - ważne, żeby nie pisać całego programu na jedno podejście i kompilacja - a potem wiesz, milion błędów literówek, trzeba tak pisać, żeby po każdym kroku móc go skompilować i przetestować czy chodzi;
- programowanie dużych aplikacji zaczynam od... kartki. Większość z nas jest wzrokowcami i dobrze jest sobie zobrazować program (rozrysuj algorytm, zobacz co jest potrzebne, jakie funkcje dopisać; jeżeli to aplikacja okienkowa - ile formularzy, co na nich będzie, relacje pomiędzy nimi, wypisz sobie jakie funkcje musi program spełniać; jeżeli aplikacja opierająca się na bazach danych - jakie tabele, relacje pomiędzy nimi, kolumny i ich typy, ilość znaków w kolumnie).

Serdecznie polecam korzystanie z kartki i długopisu, nawet sobie możesz założyć duży zeszyt taki A4, będziesz miał wszystko zebrane, możesz wrócić zawsze to tego, a rysunek jest łatwiejszy do analizy niż kod nawet jeśli będzie samokomentujący

Piszę na razie z punktu widzenia programisty programów na PC, lecz niebawem siadamy do procków Jednak zasada działania będzie ta sama.

Ważne jest by dbać o porządek w kodzie. Co z tego, że program będzie jakimś cudem działał, jeżeli chęć jakiejkolwiek modyfikacji czy wytłumaczenia komuś zasady działania będzie utrudniona, bo będzie to nieczytelne. Dlatego wcięcia, odstępy, pewna swoista gramatyka kodu (np. nazwy funkcji zawsze zaczynam dużą literą itd.). Wszystko to ułatwia życie i czyni przyjemnym siedzenie przy ekranie No i oczywiście samokomentujący kod - zbieram dane w zmiennych dotyczące np. jakiejś osoby, to nazywam je: imie, nazwisko, wiek, a nie a, b, c, bo potem nie będziesz wiedział o co chodzi i się pogubisz w stosie literek. Poza tym kod programu - przynajmniej ja wychodzę z takiego założenia, nie wiem jak inni - mam czytać tak samo jak książkę, czy muzyk nuty a vista - lekko łatwo i przyjemnie

_________________
sig off ;(

Opowiem z mojego w sumie "niewielkiego" doświadczenia.

Jako w sumie słaby programista, średni elektronik bez szkół. Najpierw zbieram wszelkie materiały, założenia co ma program robić.
Następnie powstaje prototyp na który będzie powstawał program, następnie komunikacja ze światem, czyli tzw. szkielet. Biblioteki LCD/klawisze/uart itp. w 99% wykorzystuje gotowe, z modyfikacjami jeżeli jest taka potrzeba, vide modyfikacja UARTx2 dla 644PA by działały równolegle dwa uarty na eventach.
Następnie powstają kluczowe funkcje, algorytmy etc.
Potem staram się to jakoś sensownie podzielić na pliki, aczkolwiek ostatnio już na poziomie powstawania szkieletu staram się dzielić, by potem było mniej roboty.
Następnie testy na prototypie, potem projektowanie docelowego układu, czyli chwila odpoczynku od programowania. Powstaje schemat/PCB, następnie na tym etapie powstaje prototyp docelowy lub już w sumie gotowy układ na docelowym PCB.
No i testy, testy, testy .

Zawsze warto sobie zostawić kilka pinów na debugowanie diodą, lub jakiś i2c zostawiam wolny, np. by podłączyć zewnętrzny LCDek dla wyświetlania zmiennych, ewentualnie jeżeli mam wolny sprzętowy uart to po uarcie (niestety 3 uartów w atmegach nie ma ).

Już na etapie wstępnego projektowania myślę i tak robię by była możliwość podłączenia się czymś dodatkowym, dla łatwiejszego debugowania, oraz nigdy nie biorę procka którego wykorzystuje ponad 60% zasobów, gdyż okazuje się potem że coś trzeba dopisać i zonk.
Chyba że jest zgodny pinowo mniejszy. U mnie 2xUART to w sumie konieczność, przez co opieram się ostatnio na 644 głównie.