Ja wiosną wreszcie przeprowadzam się do domu i planowałem, aby poza własnymi drobnymi rozwiązaniami zaimplementować system Fibaro - nasz polski autorski pomysł, no ale chyba szykuje nam się system jeszcze lepszy
Mogę służyć też dobrym poligonem doświadczalnym jeśli chodzi np. o moduły komunikacyjne bo mam dwa betonowe stropy z bardzo gęstą konstrukcją stalową.

Może jednak powinniśmy zacząć od nakreślenia realnego planu dość podstawowego systemu, składającego się z jednostki centralnej i np. kilku modułów współpracujących. Cały projekt w miarę naszych możliwości i chęci byłby z czasem rozbudowany o nowe moduły i funkcjonalności.
Wydaje mi się, że jeśli projekt będzie zbyt obszerny to niestety polegnie dość szybko z wielu przyczyn, ale obym się mylił
Jak udam nam się wspólnymi siłami zakończyć z sukcesem średniej wielkości projekt to wtedy myślę, że kolejny mógłby być bardziej rozbudowany i ambitniejszy.

EDIT:
No właśnie Kolega Mokrowski dobrze ujął fundamentalne kwestie i poruszył obawy, o których też myślałem.
Trzeba bardzo realnie spojrzeć na możliwości wykonawcze w kontekście obszerności projektu. Ja raczej preferuję metodę małych kroków.

_________________
.

Pozwolę sobie się nie zgodzić z tym.Skoro chcemy robić projekt, który ma wyglądać na "profesjonalny" to wydaje mi się że warto wprowadzić UML'e. Z tego co widzę to coraz większa liczba pracodawców przyjaźnie patrzy na znajomość tego - w kontekście pracy w większej grupie. Dzięki temu też jasno określimy funkcjonalność systemu.

Dudek1111 obawiam się, że wykazujesz nadmierną fascynację UMLem. Pokaż jacy pracodawcy i do czego potrzebują znajomości UMLa. Moja obserwacja jest taka, że w znaczącej większości wykorzystywany jest tylko diagram klas, który na niewiele się tutaj może zdać. Kolejna sprawa: UML to tylko narzędzie do którego trzeba dobrać metodykę. Co proponujesz? Zdajesz sobie sprawę, że zebranie wszystkich lub prawie wszystkich wymagań wobec tak dużego systemu będzie trudne? Zaczną powstawać projekty systemów z ogromnym budżetem. Popieram mokrowskiego, niech projekt idzie w kierunku miękkich metodyk, wcale nie ujmuje to jemu profesjonalności.

No i na koniec się jeszcze przyczepię, nie funkcjonalności systemu a jego funkcje.

To zdaje się ja wspomniałem o tym nieszczęsnym UML'u i niepotrzebnie przeze mnie są kłótnie. Przepraszam. Chodziło mi raczej o w miarę konkretne precyzowanie założeń, a nie zaraz budowę wszystkich możliwych diagramów. Zresztą nie musi to być żaden UML, ale może warto byłoby użyć jakichś schematów blokowych do spójnego opisu jakichś tam działań/funkcji/założeń projektu. Było nie było jakoś założenia trzeba jasno sformułować, zresztą nie będę powtarzał tego co bardzo ładnie napisał Kolega Krauser. W każdym razie z tego co do tej pory wynika to ma to być raczej większy niż mniejszy projekt (projekt inteligentnego domu.. ja piernicze - no napewno nie będzie to mały projekt), a w związku z tym podział zadań jest potrzebny. Potrzebny byłby też pewnie podział projektu na jakieś moduły, które potem względnie łagodnie dałyby się dopasować, lub żeby można było je dołączać do rdzenia projektu. Założę się, że jak przyjdzie do pisania kodu i łączenia tego w jedną całość to będą potrzebne jakieś testy... To wszystko można robić doświadczalnie (big bang), albo jakoś to napisać w oparciu o przynajmniej minimalną dokumentację. Pytanie jak napisać, żeby każdy kto weźmie się za pisanie kodu, czy składanie elektroniki wiedział, że robi to co powinien. Najgorszy z możliwych przypadków projektu, to gdzieś tak jak projekt jest w 60% jako-tako gotowy cofanie się do pozycji startowej. Czemu? Planowanie leży. Z UML'a możnaby wykorzystać diagram modelowania analitycznego i ew.diagram czynności, ale jeżeli wiązałoby się to z dodatkowym nakładem czasu na naukę UML'a to zgadzam się, że UML można olać. Ja nie mam zbyt wielkiego doświadczenia w UML. Wspominam o nim, bo wiem że takie coś jest. Wykorzystywałem z sukcesem UML do projektu mojej pracy dyplomowej, która była x lat temu (ale UML bardzo mi pomógł). Uważam, że jeżeli byłyby jakieś względy aby korzystać z UML, to Menadżer Projektu, a zwłaszcza analityk powinni go znać w stopniu przynajmniej dobrym. Może jednak lepiej dać sobie spokój z tym UML'em... Nie wiem... To będzie w końcu bardziej projekt elektroniczny niż programistyczny - chyba że się mylę?...
Gdyby jednak zainteresowało Kogoś w przyszłości (niekoniecznie w tym projekcie) UML, to jest taki program do UML (jeden z wielu): StarUML.

Pozdrawiam! Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

Jeśli chodzi o UMLa to chodziło mi o to co opisał kolega j23. Nikt nie mówi o wszystkich diagramach, żeby je robić. Ale do takiego projektu - tak rozbudowanego i na sporą liczbę ludzi, którzy mogą się komunikować tylko online, jakieś diagramy powinny powstać. Może rzeczywiście nie UMLe, skoro zajęłoby to sporo czasu, ale coś na wzór nich. żeby każdy kto spojrzy od razu wiedział o co chodzi, a nie musiał wczytywać się w strony tekstów. Przecież podobno jesteśmy wzrokowcami, więc łatwiej nam idzie patrzenie niż czytanie

Chętnie dołączę. Projekt dość spory, ale myślę że OK!

Hahaha aleście dołożyli
Mogą być i Kinetisy, tylko konia z rzędem temu kto potrafi to programować (taki żart). To nie jest że ja wolę STMy, ale patrząc na forum więcej ludzi próbuje swoich sił w STM niż w kinetisie. Z całym szacunkiem do AVRów, pokarz mi na który AVR wyrobi się z zaawansowaną obsługą grafiki na ekranie (mimo wszystko wypadało by coś wyświetlać po za klawiszem w postaci bitmapy).
Nie twierdzę, że jedyna słuszna droga to STM/Kinetis, ale właśnie przez to trzeba by zachować jakiś standard by można zrobić różne wersje tego samego.


Ja bym jednak cały projekt zrobił typu open source, czyli żadnych tajemnic, biblioteki owszem, np. do docelowego modułu, jakaś komunikacja, itp. np. w przypadku użycia AVR przez mniej doświadczonego, by skupić się wyłącznie na problemie, a nie na rzeźbieniu od zera.

PS. I nie popadajmy w megalomanie projekt jak projekt, całym clue, jest właśnie, że nawet maluczki może skrobnąć jakiś ciekawy czujnik.

Standardy komunikacji między modułami itp. istnieją i nie ma co wynajdywać koła na nowo vide modbus, profibus i pochodne, jest dostosowany do takich zastosowań, jest w profesjonalnych zastosowaniach mocno wspierany. No i warto go znać, jeżeli już poruszacie się w obszarze co może przydać się w CV .

Trzeba pamiętać, że to wymaga pracy, ale na początku włożona w opracowanie standardu komunikacji/protokołu zaprocentuje całkowitą niezależnością tak naprawdę, czyli dokładnie to o czym wspomina Mirek np. w poradniku o calbackach i grze snake, co mnie interesuje co np. siedzi w takim module sterującym, ja mu zapodaje adres/rozkaz a on ma mi zwrócić parametr.

Wracając do kwestii ARMów, myślę że warto je poznać, mimo wszystko. Wielu próbuje swoich sił łącznie ze mną. To że bardziej lubię STMy to nie prawda, jakieś 2miesiace temu próbowałem swoich sił w Kinetisie, ale jednak dokumentacja do STMów jest bardziej przyjazna, a pisanie w CW hmmm, powiem tak, KDS tak, CW nie . Argumentację proszę sobie samemu wystawić, oglądając cenę CodeWorriora

Kolejna kwestia przenośność kodu, czyli podstawowe założenie wyżej wspomniane C, oraz modułowość samego oprogramowania, czyli oddzielenie sprzętu od oprogramowania. Coś jak CMSIS w STMie, czyli zmieniamy procek na mocniejszy i nie trzeba przerabiać całego softu, a raptem kilka linijek. To też przydatna umiejętność, dzielenie projektu na pliki, moduły itp.

Jak mówiłem, to tylko moje luźne dygresje, moje doświadczenie w programowaniu jest mizerne. Owszem zrobiłem kilka projektów od zera tj. pomysł-schemat-PCB-soft, ale bez waszej pomocy (głównie kolega Malutki_27, Karuser, acid3 i kilku innych których nicków nie pamiętam) nie dał bym penie rady by to działało idealnie .

Tyle na tą chwilę.

PS. Kolega Wojtek "obiecał" opisanie certyfikacji, było by to idealne rozwiniecie tematu, ale to taka luźna dygresja.

PS2.
Kolega acid3, słusznie na czacie zauważył, że panowie trochę przesadzacie z tymi "zapotrzebowaniami klienta" bo to nie ma być projekt pod jednego klienta, a po prostu uniwersalny system, który każdy może zaadoptować pod siebie.
Nie popadajmy w skrajności, trzeba znaleźć złoty środek i po to właśnie jest ta dyskusja. Dowalicie UML, jakimiś wygórowanymi standardami oprogramowania czy dokumentacji .( to nie kwestia nawet pomiarów laboratoryjnych, bo w domu dokładność na poziomie np. 0,5stopnia C wystarczy).
Chyba że ktoś się czuje na siłach opracować taką dokumentację, mierzmy siły na zamiary, czy jakoś tak to leciało.

Czytając to co wyżej wydaje mi się, że założenie było nieco inne - a mianowicie chęć poznania na praktycznym przykładzie pracy nad projektem w grupie (zespole), a koledzy tu wytaczają ciężkie działa . Kolega mokrowski celnie to podsumował - zaczynacie nieco od tyłu, żeby tego mocniej nie określić (ale bez urazy bo idea jako taka jest ok). Podejście takie "scrumowe" byłoby fajną sprawą i chyba bardzo pasujące do takiego zespołu (wprawdzie nie dochodziłoby do spotkań codziennych bezpośrednich ale w świecie wirtualnym tez to można zrealizować w różny sposób). Ale najpierw odpowiedzi na pytania które mokrowski zadał

Idea jak najbardziej fajna, już kiedyś o tym wspominałem, że warto wykorzystać moc mózgów z tego forum Na początek jednak proponuję jakiś prosty projekt lub bibliotekę i skupienie się bardziej na aspektach technicznych pracy grupowej. Wdrożenie odpowiednich narzędzi (gita?) i zasad pisania kodu.

Pytanie, czy zależy nam na teoretyzowaniu, czy na praktycznych zadaniach podpartych rozwiązaniami praktycznymi.
Ewentualnie podział ról, czyli jedni (ci dobrzy w teorii) robią założenia, aczkolwiek nadal uważam że to nie ma być ściśle pod klienta, i co za różnica czy dany produkt już istnieje ? bo patrząc w ten sposób wszystko już zostało wymyślone (taki żart), chodzi o to by nauczyć się projektować, oraz współpracować w grupe programistów/projektantów. Bo to też istotne jest.
Przecież, jak np. ktoś postanowi zrobić czujnik wysyłający dane po RFM73 to trudno by np. centralka miała RFM12 .
Itd. Dlatego ok, najpierw założenia, czyli jak kolega Krauser wypisał ściśle określone, Ankieta hmmm, ale to krótka i szybka, bo tym sposobem zaczniemy w 2020 (zaczniemy jako forum ).

Czyli najpierw uzgadniamy jaką drogą idziemy, drogą kolegi Mokrowskiego, czyli najpierw założenia pod konkretnego klienta, następnie przegląd rynku gotowych rozwiązań, szukanie dziury i błędów w istniejących rozwiązaniach (przynajmniej tak to zrozumiałem), a dopiero na końcu co "robimy".

Po co?
- nauka pracy zespołowej, nauka git, opracowanie jednolitej zasady pisania kodu itd.
Dla kogo?
- ano dla siebie (nie na sprzedaż), tylko po to czy aby się przekonać, że razem udało się nam wykonać projekt i osiągnąć zakładany cel.

itd

może takie podejście na początek?

Zarządcą projektu może być kilka osób (wiem to głupie) i nie koniecznie mistrzów programowania, a bardziej kogoś kto potrafi zarządzać zasobami ludzkimi, czy zna odpowiednie techniki i zasady panujące przy pracy w zespole.

Ktoś kto zna techniki manipulacji?

Tylko kodowanie jak słusznie zauważyłeś ma mieć cel, a nie cel sam w sobie dla nauki.

Łatwiej by się operowało znając cel, czyli przykład "Inteligentnego domu" jako cel, a droga do niego jak wyżej opisałeś, czyli stworzenie założeń/zapotrzebowań na rozwiązania, następnie określenie co ma robić, jak wyglądać, w czym być lepszy od rozwiązań istniejących.
Aczkolwiek ostatni punkt bym pominął.

Dlatego j.w postawił pytanie Wojtek, dalsza droga ma wyglądać w sposób przedstawiony przez ciebie jako jedyna słuszna w tym wypadku, czyli interesuje nas sam proces, a nie docelowe urządzenie - na tą chwilę - czy jednak określamy konkretny cel w/w iDom, a drogi do niego są różne.

Bo podstawowa kwestia, czy w każdej firmie to tak wygląda (wiem, że nie), zresztą można by faktycznie skupić się na samej kwestii współpracy w zespole. Mnie źle pracuje się na modelach wirtualnych, czyli w/w teoretyzowaniu, czyli stwarzaniu założeń jakie ma spełniać sam projekt współpracy, a dopiero potem po określeniu założeń, wybrać cel.
To są dwa różne podejścia, stąd moje wątpliwości, nie twierdzę, że moja droga jest jedyna słuszna i jak dobrze kolega Wojtek zauważył, podstawowe pytanie czego chce ogół.

Widze ze temat zostal przejety

Dorzuce swoje 3 grosze Zweryfikowaliscie troche moje podejscie :

Glowne zalozenia:


-Nauka pracy w zespole bo nawet sama rozmowa o tym przekonuje mnie ze male mamy o tym pojecie
-Nauka pracy z systemem wersji i praca zdalna np.git
-open source open hardware - intetesuje nas i soft i hard, nic nie stoi na przeszkodzie by hard tez byl wersjonowany i modulowy
-prosty system - dopiero pozniej rozbudowywany ale! Nie wychodzimy z genialnym pomyslem a z mniej lub bardziej dzialajacym rozwiazaniem - jesli takiego nie ma jeszcze w projekcie to zostanie dolaczony jako kolejna opcja do wyboru i kolejny modul.

Nie ma co ankiety robic bo ten i-home zrobil najwieksza furore, pierwsze mamy juz ustalone

Teraz wybierzmy osoby odpowiedzialne - kto czuje sie na silach niech pisze pm (bedzie czytelniej i konkretniej)

Taka osoba bedzie miala ostatnie zdanie we wszystkim, lacznie ze zmiana glownych zalozen - liczymy na zdrowe podejscie szefa

Ja chce sie czegos nauczyc, pracowac w zespole w zdrowej atmosferze, mysle ze razem stworzymy takie miejsce

Też jestem za Dyktaturą, bo demokracją to narobimy tylko zamieszania .

No droga zgodna z standardem, bo mimo wszystko np. UML tworzy już jakiś standard i trzeba by się go trzymać, bo jak to w dyktaturze droga jest jedyna słuszna

Panowie ,

Tak obserwuje dyskusje z boku i mysle , ze @mokrowski i @rezasumar maja duzo racji. Pojawia sie w tym watku ogrom informacji , burze pomyslow , tony technologi etc. Natomiast powinnismy zaczac wg mnie malymi krokami od poczatku.

Ja (subiektywna opinia ) zaczalbym od listy ludzi , ktorzy chca wziac udzial w programie (projekcie) - autor watku moze wypisac uczesnikow w pierwszym poscie tak zeby nie trzeba bylo brnac do 999'tej strony zeby sie cos dowiedziec.

Majac liste osob mozemy ustalic nasze mocne i slabe strony. To daje nam szanse utworzenia zespolow w ktorych nasze umiejetnosci sie uzupelnia i bedziemy mieli szanse na powodzenie.

W dalszej kolejnosci moglibysmy przeprowadzic ankiete co chcielibysmy zrealizowac. Ja np (moze to nie jakis cud techniki) zaproponowalbym cos w rodzaju projektu wielozadaniowego z Mirka ksiazki. Dlaczego ? Bo tam jest mix wszystkiego ... od elektroniki analogowe - poprzez programowanie w C do komunikacji HTTP/UDP/TCP.

I znajac nasz cel moglibysmy wtedy modularnie oddelegowac zadania do poszczegolnych zespolow i pisac wg Mirka zasady. Tzn dajemy komus nasza biblioteke i on moze ja po prostu wykorzystac

Co myslice ?

_________________
sig off ;(

To ja dorzucę coś od siebie
Dlaczego STM (poza tym co napisał Rezasurmar)? STM daje STemwin - biblioteki graficzne z obsługą touchpanelu (bodajże), co znacznie upraszcza projektowanie interfejsu. Płytki są ogólnie niedrogie, ale podejrzewam, że gdyby podrzucić do STM (polskiego przedstawicielstwa) informację o takiej akcja jak ta (oczywiście gdy szczegóły i chętni byliby ustaleni) to jest szansa, że mogą wspomóc swoimi zasobami (np. tańszymi lub nawet darmowymi modułami). Zapytać nie zaszkodzi.

W przypadku STM mogę się dołączyć. Niestety z Atmelami mam mało do czynienia.

_________________
40-32:2=4!

Myślę, że nie było by problemu, zresztą w tym wypadku można by nawet uruchomić kontakty i spróbować zawalczyć o darmowe próbki.

Na pm prosze wysylac propozycje managerow projektu (osobiscie), platformy glownej (np. m8) oraz taktowania (np. Kwarc 16MHz).

Czekmy do piatku do 12pm.

Nie robimy na razie zadnej listy uczestnikow - wziac udzial moze kazdy, kto jednak napisze choc komentarz w kodzie staje sie automatycznie uczestnikiem.

Ta informacja znajdzie sie tez w pierwszym poscie.

Zaczynamy od coreboard - czyli procek+kwarc. Chocby i jeden modul sprawi ze projektu nie nazwie nikt klapa ! A dzieki temu projekt bedzie mogl byc dalej rozwijany i nie bedzie mial nigdy ostatecznej formy - czegos w stylu ok, wszystko jest - koniec!


To w sumie wasze sugestie - zacznijmy prosto i konkretnie

Spokojnie, wybór platformy (procek) to jest bardzo odległa kwestia, dla różnych elementów możemy wybierać różne procesory w zależności o ich możliwości.
Więc proponuję zacząć od początku. Nawet samo stworzenie "papierowej" dokumentacji jest uznawane za sukces!

_________________
Und schreien

Spring
Erlöse mich
Spring
...

Tak sobie myślę...
To co napisał Kolega Wojtek:
czyli praktyczne zastosowanie scrum'a (nie bójcie się że nie wiecie o co chodzi, ważne żeby PM wiedział-czyli bez teoretyzowania) - i projekt powinien ruszyć.
ORAZ
To co napisał Kolega Rezasurmar:

Acha.. i nie chodzi tu o jakieś manipulatorstwo -jak w cytacie Kolegi PAMPKIN'a: -dobre...
No tak, ale od czegoś trzeba zacząć i tu się zaczyna właśnie teoretyzowanie -no to może niech pomysłodawca -jak radzi Kolega Wojtek- narysuje chociaż projekt (tak, tak na kartce papieru - COKOLWIEK) i będzie wiadomo od czego zacząć, czego się chwycić, co poprawiać (co ulepszać?)...
Wydaje mi się, że na początku zawsze jest trochę teoretyzowania.

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

Najbardziej wychwalana tu propozycja - sterownik uniwersalny (e-home) - wiec szukamy uniwersalnej platformy. To nie ma byc projekt w stylu chce 2 ledy, lcd, 1 czujnik pt500, wiec wybieram np. Mege88 ......

Z reszta mi chodzi tylko (az) o baze - moduly dowolne, co komu tam pasuje

W brew pozorom to nie zaczynanie od cenzored strony, każdy wie co mniej więcej chciałby w takim projekcie i jaka platforma sprzętowa to umożliwi - wiec forsujcie swoje typy

Nie zawsze dobiera się kompa pod system, czasami dobiera sie system pod kompa

uprasza się o mniejsze niechlujstwo językowe, oraz powstrzymanie się od inwektyw w postach rezasurmar

[ kolor czerwony w postach zarezerwowany jest tylko dla moderatorów ok? - mirekk36 ]

napiszę tylko tyle .... hmmm... wielkie plany i ambitne , a bolesna rzeczywistość ....

abstrahując nieco od wszelkich zasad pytań itd ...

tak nieco może szorstkiego podejścia....

1. Praca zespołowa nad kodem ...
---- siedzimy w eclipse jest tam moduł pracy zespołowej TEAM i CVS i GIT
---- dokumentacja Doxygen
Niestety wszyscy muszą być spójni , o ile praca nad kodem nie będzie problemem to jednak:

2. Hardware
---- każdy musi mieć spójną architekturę dostęp do modułu/-ów środowiska sprzętowego by była możliwość
testowania kodu ....

To bardzo istotna sprawa , na sucho nic nie zrobisz , a przecież nie będzie nikt zmuszał do nabycia tej czy innej płytki
bo to czy tamto ...

REza woli STMY skoro woli to dobrze ja je też lubię są naprawdę ok
Kinetisy ?? Arm jak arm w sumie , ale STM dostępniejszy
przenośność kodu ?? oczywiście trzeba się trzymać standardu
-- w przypadku ARM ... proponuje trzymać się CMSIS
-- w przypadku AVR ... dobrze by było trzymać się C

Moduły ?? jest tego taka masa w dobrych cenach że z powodzeniem można by pokusić się o zdecentralizowany system rozproszony oparty o sieć WiFi (dzięki tanim ESP8266) i tu widzę już niemal waszą pomysłowość tworzenia modułów
kontrolno-pomiarowych

Ja bym sugerował rozpocząć od znanej i w miarę dostępnej każdemu platformy sprzętowej -- np ATB ma większość na forum
ale zdecydujcie się na konkretną platformę systemu ... bo na czym będą moduły niema znaczenia AVR, PIC, MSP, ARM ....

a nie przepychanki i badanie rynku ... jakiego rynku , jakie badania .... do tego jeszcze lata świetlne , pomysł ma szansę zadziałać , potem po powstaniu prototypu można będzie pomyśleć o reszcie...

I co najważniejsze .... Pamiętajcie, że ma to być przede wszystkim dobra zabawa i nauka, a nie groźba rynkowej klapy(co w PL jest normalne)

I jakby co .... to to jest posag Lusi

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

Powtarzam, to nie jest kwestia woli, a kwestia już poruszona, dostępność sprzętu, ceny platformy, oraz współpraca z dostawcami sampli (niczego nie obiecuje, a ni ja ani nikt inny).
Co nie znaczy, że na kinetisie też nie można by zawalczyć.

Czujniki to nawet na tince można ogarnąć, prostą centralkę wystarczy atmega88 (babcię mega8 może już zostawmy dla muzeum ).

SunRiver - oczywiŚcie, co do ATB - wystarczy podaĆ uC jaki ma siĘ na pŁytce i preferowane taktowanie! To chyba bardziej elastyczne rozwiazanie

KaŻdy musi mieĆ dostĘp - do bazy. Nie wyobrazam sobie Żeby kaŻdy musiaŁ mieĆ dostĘp do wszystkich moduŁÓw! Mam pc chcĘ uŻywaĆ cdrom to na co mi stacja dyskietek? Ale dla tych co je majĄ i chcĄ uŻywaĆ teŻ jest taka moŻliwoŚĆ - ja tak rozumiem moduŁowoŚĆ co ty na to?

Jak wybierzemy szefa to juŻ siĘ wtrĄcal nie bĘdĘ, ale na razie - korzystam z tego pÓki mogĘ


Posta zaatakował wirus polskus znaczkus ... jeśli chcesz uniknąć tego typu ataków włącz sprawdzanie pisowni w komputerze...
złośliwy mod. Ortograf

Co do ATB, to ja nie posiadam, ale myślę, że to nie jest jakiś wielki problem (przynajmniej dla mnie). Dokumentacja płytki jest udostępniona, więc w razie wątpliwości zawsze można tam zajrzeć. Poza tym od razu raczej nie będziemy wykorzystywać wszystkich rozwiązań, jakie daje ATB "na gotowo".

Ważne żeby znać/rozumieć schematy połączeń i kod.

_________________
Szukasz książek o elektronice i programowaniu?

Tak sobie czytam i czytam ten wątek .....

(tylko pamiętajcie proszę przed przeczytaniem kolejnych moich słów) .... jestem niepoprawnym optymistą ... nie mniej jednak jestem gotów się założyć o skrzynkę whisky .... że ten wątek owszem będzie pretendował do najdłuższych na naszym forum, być może ilość postów przebije w nim, najdłuższy serial jaki powstał do tej pory na ziemi .... ale wg mnie nie zakończy się stworzeniem żadnego projektu ....

oczywiście ABSOLUTNIE nie piszę tego, żeby kogokolwiek zniechęcać - na końcu okaże się że wręcz przeciwnie ... ale na początek to powiem wam - że próbujecie wystartować z TAK OGROMNĄ ilością zmiennych, że tego równania nie da się rozwiązać. Toż już po tej wstępnej dyskusji widać, że nie pada nawet zarys konkretnego pomysłu a jedynie pomysły na GŁOSOWANIA coraz większej ilości rzeczy ... i tak mamy już w tym wątku głosowanie na menagera, głosowanie na platformę sprzętową bo nawet w tym zakresie nie ma jednomyślności czy AVR czy STM czy PIC czy co ... ba jak wybierzecie nawet platformę to zacznie się dopiero głosowanie jaki konkretny model procesora, jakie środowisko, jakie narzędzia itp itd ... Ale to nadal nic - bo jeszcze ma być hmmm tzn trwa głosowanie w ogóle nad samym pomysłem czego projekt ma dotyczyć - a jak czytałem to padają propozycje (to tylko teraz taka moja przenośnia) od zbudowania rowerka dziecięcego po budowę sputnika 6-tej generacji ... ciekaw jestem ile jeszcze głosowań wyniknie - i oby się nie skończyło na tym że na końcu będzie głosowanie ile jeszcze ma być głosowań ....

nie piszę tego z ŻADNĄ nawet najmniejszą nutką ironii czy chęci dogryzania bo powiem tak - CHCIAŁBYM WRĘCZ PRZEGRAĆ tą skrzynkę whisky o której mówiłem na początku i z miłą chęcią kibicowałbym gdyby się jednak udało .... dlatego jak mówiłem to co piszę to takie podsumowanie tego co widać w tym wątku do tej pory - gdy ktoś tak z zewnątrz spojrzy chłodnym okiem. Jeden wielki misz-masz.

Proponowałbym tak jak już - wcześniej koledzy: mokrowski i wojtek pisali PRZEDE WSZYSTKIM NA SAMYM początku określić WYRAŹNY CEL. Przynajmniej JEDEN CEL tego projektu. Bo teraz to są one pomieszane jak groch z kapustą i absolutnie nie wybrniecie z tego nigdy. A wątek się rozciapcia ....


No DOKŁADNIE ....

próbujecie się skupiać na technikaliach bez OKREŚLENIA CELU ... tymczasem jeśli piszecie gdzieś tam po drodze, że przydałoby się nauczyć pracy grupowej - no to już na tym etapie weźcie do siebie te uwagi mokrowskiego i wojtka .... bo to nie jest wcale czcze gadanie

1. BEZ określenia WYRAŹNEGO CELU - nie ma i nie będzie projektu (to nie jest wróżba - to prawda)
2. Jak już OKREŚLICIE wyraźny cel to zobaczycie, że stanie się CUD - i nagle będzie można już spokojniej iść w dół i precyzyjnie dochodzić do poszczególnych etapów planu realizacji projektu żeby na końcu określić technikalia za pomocą których będzie to zrealizowane - to wręcz samo prawie wyjdzie

próby robienia tego "od dołu" to mniej więcej to samo co próba pisania dużego programu bez uprzedniego przygotowania sobie dokładnego algorytmu jego funkcjonalności. To już chyba każdy z was wie - że zwykle kończy się fiaskiem albo GIGANTYCZNĄ stratą czasu po to aby na końcu i tak zacząć od algorytmu .... A tu na forum o tyle może być gorzej - że jeśli dojdziecie do tego właśnie etapu na 324 stronie wątku to:

1. ponad połowa chętnych odpadnie i wcale nie dlatego że się pogubiła - ot z różnych względów - choćby tak prozaicznych jak upływ czasu i inne zajęcia
2. rzeczywiście nie przybędzie nowych osób i chętnych bo jak poczytają początek to się złapią za głowę i pomyślą "ale o co tu kaman?"
3. nikomu wręcz nie będzie chciało się zaczynać od nowa

------------------------------------------------------------------------------------------

Reasumując - życzę powodzenia i trzymam kciuki żeby się udało .... chociaż coś zacząć nawet w niewielkim zespole

------------------------ [ Dodano po: 1 minucie ]

Jeszcze jedno dodam - jak pisał z kolei SunRiver:


Od tego bym zaczął myślenie a nie od pomysłów na komercyjne projekty bo to na 1000% się nie uda - a gdyby jednak takie było parcie (czyli na projekt komercyjny) to TYM bardziej proponuję zwrócić uwagę na punkty wskazane przez mokrowskiego i to bez żadnego zmiłuj się ...

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

dokładnie ... dokładnie... dokładnie ......
eheheh...
hie hie hie

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