microgeek.eu

Witam Koleżanki i Kolegów,

Poniżej przedstawiam propozycję projektu jako systemu prototypowego firmowanego przez Microgeek. Od razu zaznaczam, że jest to niejako alternatywa, albo i pewna opcja dla pomysłu rzuconego przez Kolegę ZbeeGin. Jest to po prostu projekt widziany moimi oczami, a ponieważ trochę daleko odbiegał on od założeń opisanych przez Kolegę ZbeeGin to postanowiłem to wrzucić tutaj jako nowy temat. Przy czym chciałbym podkreślić, że o ile założenia są zgodne i względnie spójne to nie widzę problemu, żeby to spróbować robić jako jeden projekt - o ile w ogóle jest to warte robienia, etc. ta propozycja, którą przedstawię za chwilę.

Moje podstawowe założenia przy projektowaniu tej wersji były takie, żeby była ona możliwie uniwersalna z możliwie powtarzalnymi elementami, ale zarazem żeby było to skonstruowane w taki sposób, żeby wykluczyć możliwość potencjalnej pomyłki (zwłaszcza dla początkującego). Stąd pomysł z:
- rozdzieleniem na moduły - po to, że jeśli ktoś potrzebuje konkretny moduł, to buduje go (kupuje?) i dołącza
- dokładnym opisem interface'ów - żeby wykluczyć możliwość błędnego połączenia pinów. Mam tutaj na myśli opracowanie kolejności pinów, ew. kształtu slotów dla poszczególnych interface'ów, takie opracowanie pinologii dla każdego (w moim odczuciu unikalnego) portu/slotu żeby wykluczyć możliwość błędnego podłączenia modułów przez początkujących

W moim mniemaniu do podstawowego systemu prototypowego Microgeek powinny wchodzić moduły z legendy oznaczone gwiazdką przed nazwą, np. *MB, *RPSC, etc.
Moduły bez gwiazki są potrzebne, ale nie niezbędne. Zresztą nie wszystkie teraz zdążę opisać, więc to następnym razem rozwinę myśl.

Jeszcze słowo o oznaczeniach interfaców i slotów ( żółte napisy na brązowym tle wtyczek/slotów ). Metodologię nazewniczą przyjąłem postaci:
<sygnał_skąd>2<sygnał_dokąd>_<położenie_interface'u>_<typ_interfacu>, np.
MB2RPSC_MB_DI = sygnał z MB do RPSC, położony na MB, typ interface'u: DI

Oto diagram:


Legenda:
-----------------------------------------------------------------------------------------------------------
uC = mikrokontroler
SC = SYSTEM CONTROLLER (jeśli nie ma innego objaśnienia)
DI = DATA INTERFACE ( w znaczeniu = wtyczka do transferu danych )
DS = DATA SLOT ( w znaczeniu = gniazdo do transferu danych )
PI = POWER INTERFACE ( w znaczeniu = wtyczka do transferu zasilania )
PS = POWER SLOT ( w znaczeniu = gniazdo do transferu zasilania )
DB = DATA BUS ( magistrala transferu danych )
PB = POWER BUS ( magistrala transferu zasilania )
DL = DATA LINE ( pojedyńcza linia transferu danych )
PL = POWER LINE ( pojedyńcza linia transferu zasilania, np. określone napięcie, lub masa )

*MB = MAIN BOARD ( podstawowa płytka do wybranego uC, np. STM32 )
*RPSC = ROOT POWER SYSTEM CONTROLLER ( główny kontroler zasilania )
*RCOMSC = ROOT COMMUNICATION SYSTEM CONTROLLER ( główny kontroler komunikacyjny wejścia/wyjścia )

*MPSC = MAIN POWER SC ( podstawowy kontroler zasilania ), w którego skład wchodzą ACMPSC i DCMPSC
*ACMPSC = ALTERNATE CURRENT MPSC ( kontroler zasilania dla dostarczonego napięcia zmiennego, np. zasilanie sieciowe )
*DCMPSC = DIRECT CURRENT MPSC ( kontroler zasilania dla dostarczonego napięcia stałego, np. bateria )

APSC = ALTERNATIVE POWER SC ( zapasowy kontroler zasilania ), w którego skład wchodzą ACAPSC i DCAPSC
ACAPSC = ALTERNATE CURRENT APSC ( kontroler zasilania zapasowego dla dostarczonego napięcia zmiennego, np. zasilanie sieciowe )
DCAPSC = DIRECT CURRENT APSC ( kontroler zasilania zapasowego dla dostarczonego napięcia stałego, np. bateria )

XB = EXTENSION BOARD ( dodatkowa płytka do rozszerzenia zestawu, np. z sensorami )

*RCOMSC = ROOT COMMUNICATION SYSTEM CONTROLLER ( główny kontroler komunikacyjny wejścia/wyjścia )
*SICOMSC = STANDARD INPUT COMMUNICATION SC ( kontroler komunikacyjny dla standardowego wejścia )
*SOCOMSC = STANDARD OUTPUT COMMUNICATION SC ( kontroler komunikacyjny dla standardowego wyjścia )
PCOMSC = PERIPHERAL COMMUNICATION SC ( kontroler komunikacyjny dla innych urządzeń peryferyjnych, router )
XCOMSC = EXTENSION COMMUNICATION SC ( dodatkowy kontroler komunikacyjny dla innych urządzeń peryferyjnych, węzeł lub kontroler urządzenia końcowego )

Pozdrawiam! J23

rezasurmar pisze:Możesz wrzucić ten diagram w wyższej rozdzielczości... albo w załączniku (plik programu w którym go narysowałeś).
W tej formie jest nieczytelny.

Jest w dużej, otwórz go tylko w osobnej karcie i powiększ.
Nie mówię, że schemat blokowy, czy tez diagram jest nieczytelny - ale jest trudny czy tez zniechęcający przy pierwszym podejściu do analizowania prze swoje skrótowe nazewnictwo. No ale wgłębiają się w to tylko Ci co ich to interesuje.

Uff no widzę, że nie tylko ja mam odczucie, że analizowanie tego diagramu jest męczące, ale absolutnie nie chce ciebie J23 zniechęcać. Po prostu ja ze starej szkoły jestem i zwykłe prostokąty z pokazaniem głównych połączeń oraz ich kierunków w postaci strzałek, a także nazwach mówiących jaka jest główna funkcja bloku więcej mi powiedzą niż niejeden najbardziej dopieszczony obrazek.

Generalnie chcesz mieć główna płytę z możliwością wpinania tam modułów jak np https://shop.mikroe.com/easymx-pro-stm32 ? czy tez byłoby to łączone systemem złącz - jakaś firma to ma tylko za czort nie umiem sobie przypomnieć, rośnie to na boki w rożnych kierunkach jak się dopina kolejne moduły. To duże przedsięwzięcie jest i będzie drogie.

wojtek pisze:Generalnie chcesz mieć główna płytę z możliwością wpinania tam modułów jak np https://shop.mikroe.com/easymx-pro-stm32 ? czy tez byłoby to łączone systemem złącz - jakaś firma to ma tylko za czort nie umiem sobie przypomnieć, rośnie to na boki w rożnych kierunkach jak się dopina kolejne moduły.

Waveshare, serie Open...

ooooo dokładnie o to mi się rozchodziło i jeszcze jedna firma podobnie ma.

j23 to w która strone to ma zmierzać?

Cześć,

Ok, już odpowiadam (tak na szybko, schematy/diagramy później dorysuję) - w kolejności osób zadających pytania.

rezasurmar pisze:(...)

Co do nieczytelności schematu - bardzo przepraszam, wiem że to jest kawał bałaganu typu "all in one" do tego masa skrótów, ale chciałem pokazać to szybko i za jednym razem (a do tego skłoniła mnie ograniczona ilość czasu. Rozdzielczość obrazka zwiększa się po kliknięciu, ale obrazek faktycznie jest wielki, bo napisy są nieczytelne w tej /pomniejszonej/ rozdzielczości, którą wyświetla Wasza domyślna przeglądarka grafiki. Polecam póki co przeanalizować schemat od jasno-zielonej płytki - to jest MB - czyli MAIN BOARD. Ona łączy się z kontrolerami: zarządcą kontrolerów systemu komunikacyjnego (RCOMSC = ROOT COMMUNICATION SYSTEM CONTROLLER) oraz zarządcą kontrolerów systemu napięcia (RPSC = ROOT POWER SYSTEM CONTROLLER).
Teraz upraszczając nieco analizę każdego modułu można powiedzieć, że w zasadzie jest to ten sam moduł (tzn. PCB ) z powielonymi ścieżkami (UWAGA! - nie zawsze, tylko tam gdzie można ,np. prawdopodobnie inne PCB dla kontrolerów napięcia, inne dla kontrolerów danych). Innymi słowy można rozpatrywać to pod kątem, że mamy moduł typu:


lub moduł typu:


gdzie wśród takiego jednego pojedyńczego modułu można rozróżnić z całą pewnością:
- interface (unikalna wtyczka/slot) komunikacyjny wejścia danych - w celu odbioru danych do modułu
- interface (unikalna wtyczka/slot) komunikacyjny wyjścia danych - w celu informacji zwrotnej z modułu
- interface (unikalna wtyczka/slot) zasilania modułu - w celu zasilania tegoż kontrolera tegoż systemu/subsystemu

(...)

rezasurmar pisze:Zdecydowanie jestem za 'współpracą' przy bardziej 'zaawansowanej' i dużo bardziej uniwersalnej PCB, coś na kształt Mikroelektronika, lub Olimex.
Gdzie płyta bazowa pozwala na osadzenie różnych procesorów i ma złącze zgodne z arduino (5V i 3.3V). Bez stałego osadzania np. 1602.

Prawdopodobnie nie jest mi znana ani jedna ani druga konstrukcja (albo nie pamiętam) - czy Microelektronika to było coś z mikrokontrolerem 8051? -bo jeśli tak to uczyłem się w oparciu o kontrukcję Panów Piotra i Pawła Gałki (pierwsze kroki w Asemblerze, ale to na marginesie).

Wieczorem (albo teraz jak zdążę) spróbuję dodać jakiś uproszczony schemat blokowy (bez skrótów? -no, okey).
Udało się - tzn. to jest schemat bez skrótów, obrazek jest mniejszy - nie trzeba zmniejszać, powinno być bardziej czytelne (mam nadzieję):


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

Teraz odpowiadam na serię podobnych pytań typu:

wojtek pisze:(...)Generalnie chcesz mieć główna płytę z możliwością wpinania tam modułów jak np https://shop.mikroe.com/easymx-pro-stm32 ? czy tez byłoby to łączone systemem złącz - jakaś firma to ma tylko za czort nie umiem sobie przypomnieć, rośnie to na boki w rożnych kierunkach jak się dopina kolejne moduły. To duże przedsięwzięcie jest i będzie drogie.(...)ooooo dokładnie o to mi się rozchodziło i jeszcze jedna firma podobnie ma.

Tak jak napisałem jeszcze na samym początku - to jest zaledwie propozycja, nie jest już to absolutnie NIC skrystalizowanego, zamrożona i nietykalna wersja projektu i te sprawy. Nie, to jest propozycja jak ja to widzę moimi oczyma, czyli:
- żeby było to niezawodne
- żeby to było konfigurowalne (po to moduły) i tym samym względnie tanie (każdy wybiera sobie moduł jaki potrzebuje)
- żeby interface'y były zrobione jak w starych dobrych szkołach - tzn. unikalne, czyli włączysz tak a nie inaczej i dzięki temu nie pomylisz pinów. Oczywiście do każdego interface'u/systemu kontrolera trzeba opracować pinologię, ale żeby w ogóle zacząć nad tym pracować trzeba mieć pojęcie o sygnałach, o sprawach z elektroniki, w których jeszcze nie czuję się zbyt pewnie - a które lepiej z pewnością rozumieją tacy Koledzy jak Wojtek, Rez, Anty, Acid, Dambo... bardziej rasowi elektronicy a nie jakiś tam informatyk.

wojtek pisze:(...)j23 to w która strone to ma zmierzać?(...)_

Jestem zdania żeby trzymać się modularnej budowy tego systemu, bo daje to pewną gwarancję postępu prac, a nie utknięcia na etapie rozważania odwiecznego pytania:"Co ma być na płytce bazowej?..." -ALE CHCĘ DODAĆ, że bardzo istotne jest tutaj doświadczenie z elektroniki Kolegów forum, czyli jeżeli np. lepiej było zrobić większą płytkę MB (MAIN BOARD) ta zielona i teraz na niej umieścić sloty na:
- slot głównego kontrolera systemu zasilania (zamiast osobnego modułu)
- slot głównego kontrolera systemu komunikacji (zamiast osobnego modułu)
to może i w tym kierunku należałoby iść. Wszystko co powyżej odbywa się kosztem miejsca na płycie głównej (MB) oraz ukierunkowaniem się na jakąś konkretną serię procesorów, ale nie wiem - może tak by było lepiej, może byłoby opłacalne. Sens widzę wtedy, kiedy byłoby to w jakiś sposób uniwersalne i konfigurowalne. Oczywiście zakładam, że domyślnie wszystko byłoby open-source, w sensie "chcesz buduj samemu, nie chcesz dłubać to my to mamy za tyle i tyle".

Mam nadzieję, że odrobinę pomogłem odpowiedziami. Jakby coś jeszcze było to proszę pytać. Dziękuję za konstruktywną krytykę

Pozdrawiam! J23

j23 pisze:bardziej rasowi elektronicy a nie jakiś tam informatyk.

A ja jestem automatykiem :p

Powiedz mi jaką masz koncepcję połączeń? Np dla przewodów komunikacyjnych - coś typu kanda i w środku RS/SPI/I2C itp wychodzą z głównej płytki, a "slave" korzysta tylko z tego co potrzebuje? Tzn sensorek po i2c będzie się łączył tylko pod piny i2c?

Edit a co do opcji z zasilaniem - ja bym proponował jako główny moduł dać płytę z zasilaniem i ją uczynić główną i do niej wpinać moduł z prockiem jako "serduszko" systemu, ale kwestia jest bardzo do przemyślenia

dambo pisze:

j23 pisze:bardziej rasowi elektronicy a nie jakiś tam informatyk.

A ja jestem automatykiem :p

Miałem na myśli ludzi, którzy w temacie sygnałów (filtracji, stabilizacji, szpilek, etc) wiedzą więcej ode mnie.

dambo pisze:Powiedz mi jaką masz koncepcję połączeń? Np dla przewodów komunikacyjnych - coś typu kanda i w środku RS/SPI/I2C itp wychodzą z głównej płytki, a "slave" korzysta tylko z tego co potrzebuje? Tzn sensorek po i2c będzie się łączył tylko pod piny i2c?

Dokładnie. Załóżmy, że user chce sprawdzić odczyt temperatury po i2c.
1. Sygnał z np. DS18B20 dochodzi do XCOMSC ( kontroler systemu modułu rozszerzeń komunikacji ),
2. dalej sygnał jest wysyłany wspólną magistralą do PCOMSC ( kontroler systemu komunikacji peryferyjnej )
[ poprzez jakiś interface który jest skonstruowany w taki sposób, że niemożliwe jest jego błędne podłączenie (kształt gniazda/wtyku, kolorowe oznaczenie, etc.), pinów tyle ile potrzeba dla przewidzianej rodziny procesorów jeśli chodzi o sygnały GPIO ] = [poprzez interface...]
3. dalej sygnał biegnie magistralą danych do RCOMSC ( główny kontroler systemu komunikacji ), [poprzez interface...]
4. dalej sygnał biegnie magistralą danych do MB gdzie jest ostatecznie przetwarzany, a informacja zwrotna z danymi trafia do RCOMSC przez zwrotną magistralę danych.

dambo pisze:Edit a co do opcji z zasilaniem - ja bym proponował jako główny moduł dać płytę z zasilaniem i ją uczynić główną i do niej wpinać moduł z prockiem jako "serduszko" systemu, ale kwestia jest bardzo do przemyślenia

Tak jak napisałem - można tak, ale to zawsze idzie w tych dwóch kierunkach - "co ma być na płycie głównej", lub "modularna konfiguracja" (tzn. wybieram jakiego źródła zasilania potrzebuję. Popieram jak najbardziej ideę żeby "wpinać moduł z prockiem jako "serduczko" systemu" - taki slot z danym procesorem jak dobrze rozumiem (kiedyś tak były Pentiumy II wpinane w motherboard).

Pozdrawiam! J23

jakiego typu układy widziałbyś w modułach RCOMSC?

dambo pisze:jakiego typu układy widziałbyś w modułach RCOMSC?

I tutaj docieramy do miejsca, gdzie lepiej by było, żeby głos zabrali bardziej doświadczeni w Nucleo ode mnie. Odpowiadając ogólnie na pytanie musiałyby to być układy obsługujące połączenia przez przerwania sprzętowe (sygnał do odbioru na magistrali) pochodzące od:
1. Standardowe wejście - pierwszy mikrokontroler - możliwie najtańszy, ale żeby dał radę obsłużyć sygnały z SICOMSC ( kontroler systemu komunikacji standardowego wejścia )
2. Standardowe wyjście - drugi mikrokontroler - -//-
3. Magistrala danych z PCOMSC.
4. Magistrala danych do MB.
5. Mikrokontroler zarządzający 4-ma powyższymi na zasadzie, który pierwszy zgłosi przerwanie sprzętowe. Taki nadzorca przerwań.

Mam nadzieję że na chwilę obecną odpowiedziałem możliwie wyczerpująco.

tylko to podejście trochę odbiega od idei prototypowania takiego nazwijmy to "bezpośredniego" - czyli wtedy kod obsługi np DS18b20 wgrywamy do mikrokontrolera z SICOMSC, a on przesyła je dalej po jakimś interfejsie, czy źle to zrozumiałem?

dambo pisze:tylko to podejście trochę odbiega od idei prototypowania takiego nazwijmy to "bezpośredniego" - czyli wtedy kod obsługi np DS18b20 wgrywamy do mikrokontrolera z SICOMSC, a on przesyła je dalej po jakimś interfejsie, czy źle to zrozumiałem?

Źle to zrozumiałeś. Kod obsługi dla DS18B20 siedzi w XCOMSC ( tym kontrolerze ostatnim przed samym DS18B20 ). XCOMSC odbiera dane, zgłasza przerwanie na magistrali i sygnał biegnie do STM32 który siedzi w MB (biegnie tą drogą jak napisałem).
Z kolei SICOMSC to jest kontroler typu klawiatura do PC'ta, tzn. standardowe wejście (niekoniecznie klawiatura, można wysłać sygnał na magistralę z kontrolera reagującego na komendy wydawane głosem, które przez końcowy kontroler są przetwarzane za pomocą DSP na sygnał cyfrowy, który trafia na magistralę z SICOMSC do RCOMSC, a dalej do MB).

Z tego co opisałeś to wyjdzie bardzo rozbudowany i "zamknięty" system z wieloma uC w roli tylko i wyłącznie sterowników magistral lub konkretnych podsystemów, z całym szacunkiem do pomysłu, ale jak wcześniej pisał kolega Dambo mija się to bardzo z ideą prototypownia, dlaczego ?..., ponieważ w jaki sposób napisać procedurę obsługi i przetestować jej działanie dla DS18B20 na STM32 który będzie na płycie głównej skoro taka procedura będzie już w XCOMSC, oczywiście da się to zrobić wykorzystując XCOMSC i dedykowane przerwania lecz nie zaimplementujesz już tego poza tym systemem w innym projekcie gdzie będzie np. potrzeba wykorzystania tylko samego STM'a i DS18B20 i jakiegoś LCD. W zasadzie dotyczyć to będzie każdego modułu który będzie można do tego systemu podłączyć.

To prawda, faktycznie ta obsługa komunikacji dla wyżej opisanego przeze mnie sposobu jest błędna. Sygnały takie jak od DS18B20 powinny być dostępne BEZPOŚREDNIO z MB, ewentualnie jako opcja z XCOMSC. Cóż, wychodzi tutaj mój brak znajomości w temacie... niemniej intencje miałem dobre.

Pozytywny aspekt tego wszystkiego jest taki, że jest jakaś dyskusja, która być może do czegoś pozytywnego doprowadzi.

Przy okazji proszę o konstruktywną krytykę, tzn.dobrze by było przy kwestionowaniu zaproponowanych przeze mnie rozwiązań podać jakieś alternatywne, własne i napisać dlaczego tak a nie inaczej, żeby prowadziło to do jakichś kolejnych, konstruktywnych zmian.

Pozdrawiam! J23

Przede wszystkim dziękuję Rez za długą, konkretną i szczegółową wypowiedź. Jak już pisałem wcześniej zgadzam się z faktem, że sposób w jaki przedstawiłem podejście do projektu płyty firmowanej przez Microgeek jest skomplikowany, natomiast podejście komunikacji z DS18B20 także chybione i niepotrzebnie skomplikowane (chyba że później ktoś na bazie płyty Microgeek chciałby robić projekt inteligentnego domu, ale zdaje się nie takie są założenia płyty Microgeek, bo projekt ma być dla początkujących). Wszystkie te chybione i przedstawione przeze mnie nie tak jak trzeba pomysły wynikają -co by nie było, trzeba się przyznać do błędów- z braku głębszej znajomości tematu, założeń projektowych, technologii i ogólnego obeznania z różnymi innymi projektami płytek prototypowych (zestawów do nauki). Wniosek jaki w tym momencie się nasuwa co do samej MB (płyty głównej) i tylko biorąc pod uwagę przykład takiej komunikacji jak do DS18B20 (I2C) jest taki, że na płycie głównej powinny być WSZYSTKIE możliwe interface'y złącza do każdego typu komunikacji bezpośredniej oferowanego przez wybrany mikrokontroler STM32 (czy inny bazowy).

Teraz odniosę się do kilku ciekawych i ważnych aspektów, które poruszył Kolega Rezasurmar:

rezasurmar pisze:Czyli np. nucleo + moduły (na kablach) czy shieldy. Problem jak zwykle leży w tym wypadku w połączeniach kabelkowych, początkujący zawsze mają z tym problem. Czytaj, obwiniają wszystko do około, tylko nie kabelek/połączenie.

Właśnie dlatego proponowałem opracowanie UNIKALNYCH interface'ów I/O - przy czym nie miałem na myśli tworzenie kolejnego cudacznego kształtu wtyczek/gniazd, ale raczej kolejność pinów w odniesieniu do wybranej magistrali danych/zasilania. Zaprojektować właśnie w taki sposób, żeby początkujący NIE MIAŁ jak się pomylić - czy to robiąc samemu wtyczkę/gniazdo/magistralę danych, czy też podłączając gotowy produkt.

rezasurmar pisze:Jak już omawialiśmy wcześniej, dla mnie, podstawa to uniwersalność, nie tworzenie kolejnych standardów (bez wsparcia).

Teraz to albo ja czegoś nie rozumiem, albo są jakieś nieścisłości. W każdym razie uważam, że tak jak Rez pisze bez sensu jest tworzenie kolejnych standardów bez wsparcia, skoro już istnieją standardy gotowe do zastosowania (jak np. interface/protokół/sposób transmisji danych w RS232 - po co to robić na nowo?). Z drugiej strony jeśli JAKICHŚ standardów nie ma, a chce się coś zrobić dobrze i zgodnie z założeniami to nie widzę innej drogi jak usiąść i opracować te standardy + przykłady. Sorry, ale prostej, lekkiej i wypróbowanej drogi w tym wypadku nie ma, bo inaczej bezsensem byłoby w ogóle zabierać się za projektowanie, a właściwie POWIELANIE czegoś co już istnieje.

rezasurmar pisze:Czyli standard Arduino tu jest w sumie samonarzucającym się rozwiązaniem w przypadku chęci stosowania szerokiej gamy procesorów.... ewentualnie zapewnienie PCB od 8 do 32bitów, dla różnych rodzin w cenie tak niskiej, by ktoś w ogóle zechciał się nad tym nachylić.

i dalej (napisane w PS), ale ma to z tym ścisły związek..

rezasurmar pisze:Z własnych doświadczeń wiem, że na początek najlepsze przykłady to te które ruszają od razu na szerokiej gamie procesorów danej rodziny, np. HAL. Gdzie zmiana procesora nie wiąże się od razu z przepisywaniem połowy obsługi. A od razu jest wejściem na głęboką wodę.
Clue tego jest by pokazać że ARM to nic strasznego, i np. uruchomienie połączenia np. przez USB, to tak naprawdę 15minut roboty z kompilacja włącznie .

Chociaż Rez tego wprost tutaj nie pisze, jest to zarazem taki mały reasearch i z grubsza opisanie założeń projektu. Co do research odnośnie targetu jako projektu Arduino to moim zdaniem jego powodzenie leży właśnie w wymienialnych shieldach, ujednoliconym interface I/O i właśnie przykładach. Innymi słowy w tym miejscu warto byłoby zrobić listę zalet i wad Arduino i na tej podstawie formułować NASZE założenia projektowe (chociaż to byłby marny research, bo tylko Arduino brane pod uwagę, a przydałby się jeszcze przynajmniej jeden przykład/target reasearch'u który odniósł jakiś sukces - nie wiem, może właśnie nucleo, albo Rasberry?).
Co do pomysłu samych shieldów w Arduino to moim zdaniem to także nie jest żaden przełomowy i nowy pomysł, tylko -na przykład- zastosowanie kart rozszerzeń PC do płyty głównej w PC przeniesiony do skali embedded devices. Tak samo pomysł z wymienialnymi shieldami zawierającymi gniazdo pod dany typ mikrokontrolera do płyty głównej MB (tutaj w naszym projekcie). W przykładzie opisanym przeze mnie tak właśnie jest. Tak to jest narysowane i przedstawione - może niezbyt dokładnie opisane, ale miałem na myśli to żeby była możliwość "wczepiania" w płytę główną takich właśnie mini kart rozszerzeń (o wspólnym interface'ie) ale oczywiście każda z tych kart rozszerzeń (czy shieldów) posiadałaby OKREŚLONY slot na DANY TYP mikrokontrolera. Reasumując jedna i ta sama płyta główna z jednym interface'em na shield/kartę rozszerzeń, na której to byłby wlutowany, lub możliwy do wstawienia (jeśli tylko goła PCB) określony typ mikrokontrolera np. z rodziny STM32 64.

rezasurmar pisze:Sam stosuję zasadę brzytwy Okhama (nie mnóż bytów ponad potrzebę). Wg mnie lepiej było by się skupić na początek na jakiejś bazowej płycie do np. Nucleo (coś na kształt bazowej do np. Discovery F4), niż tworzenie, ogromnej płyty z przerostem formy.

Najważniejsze jest w tym momencie Target, powiedzmy ze ZbeeGin, ogarnia temat dla całkiem początkujących, coś w deseń płytki do Bascom AVR z EdW/EP + kurs/przykłady.

Tutaj kwestia czasu, kasy, czy nawet zwykłego podjęcia rękawic przez 'Lidera Projektu'.

Tak jak pisałem wcześniej - odwieczne pytanie: "co ma być na płytce?" plus to czego nie chciałem pisać "kto ma być liderem projektu"... To drugie mnie niepokoi, bo prościej jest zrobić tak jak dalej Rez pisze..

rezasurmar pisze:Na początek określenie targetu, potem reserch po istniejących rozwiązaniach (a może się uda np. wykorzystać istniejące moduły, czy standard złącz - wtedy jest zawsze większa uniwersalność i niższy koszt).

Najważniejsze wg mnie to podejście całościowe, czyli jeżeli powyższe punkty (target itd.) zostaną określone. Wtedy stworzyć listę przykładów, jakie by interesowały potencjalnych nabywców. I znowu w tym momencie, czy jest sens tworzyć setny przykład obsługi LCD1602? czy do znudzenia powtarzanego 18B20?. Chyba że mówimy tu np. o kolejnym etapie (po początkującym 'kursie' ZbeeGin). Np. dołożenie obsługi RTOS , czy wykorzystanie zaawansowanych timerów/SPI z ARM.

czyli konkretnie, przyjąć plan działania (podzielić zadania jeśli są one za trudne do jednorazowego zrealizowania):
1. Research - wybrać z rynku targety, które odniosły powodzenie, opisać ich wady i zalety.
2. Na podstawie m.in. pkt.1 sformułować założenia projektowe (przy czym już tutaj należałoby chyba jako wyznaczyć grupy osób pracujące nad dopracowaniem określonego założenia, a nie że ktoś sobie napisze założenie projektu, bo tak mu wygodnie, a potem męcz się i szukaj rozwiązania co autor miał na myśli).
3. Skupić się póki co na tym, żeby to w ogóle mogło się udać, żeby faktycznie było na tyle niezawodne na ile może być. Kwestie rynkowe zostawić do momentu gdy będzie już jakiś zarys projektu, gdzie będzie światełko że to może się udać. Wyodrębnić osobny wątek/dział zamknięty dla wybranych -jeśli tak trzeba (bo nie wiem jak tu się odnieść do kwestii market research - a pewne sprawy na tym etapie wydają się być mi sprzeczne, chyba że źle rozumiem).

Jeszcze raz dzięki wielkie Rez, że to napisałeś. Coś drgnęło - zobaczymy co dalej będzie, czy coś będzie itd.

Pozdrawiam! J23

Pozwolę sobie rzucić podwaliny pod nowy system prototypowy, zakładając że ma być możliwie uniwersalny i prosty w obsłudze oraz ma mieć o wiele więcej możliwości niż podobne systemy obecnie dostępne na rynku. Może coś z tego będzie wykorzystane, może nie , ale od czegoś trzeba wyjść. Postaram się to przybliżyć w postaci bloków funkcyjnych.

Blok zasilania z kilkoma napięciami dostępnymi w złączach w kilku punktach płytki najlepiej na jej obrzeżach np. 3V3, 5V i np. 12V pod silniki DC, silniki krokowe, serva itp. oczywiście o odpowiedniej wydajności prądowej, być może że jeszcze przyda się napięcie niższe niż 3.3V – wszystko zależy od tego co ma być nim zasilane. Dystrybucja poszczególnych napięć powinna być chociaż w części konfigurowalna np. przy pomocy zworek. Oczywiście całość zasilana z jednego zasilacza o odpowiedniej wydajności, aby wyeliminować plątaninę kabli na biurku.

Moduł procesora pod uC zaczynając od 8 bitów kończąc na 32, dowolnego producenta, dowolnej rodziny oraz FPGA i CPLD, wyposażony w generator kwarcowy, niezbędne elementy dodatkowe (wszystko zależy od producenta i rodziny) oraz gniazdo do dedykowanego programatora, całość w postaci zgrabnej małej płytki wyposażone w dwurzędowe złącza goldpin wpinane w odpowiednie gniazdo na płycie głównej coś na wzór modułów dip z Kamami.

Zespół złączy – na pewno złącze Arduino bo to dzisiaj standard, błędem by było tego nie wykorzystać, złącza pod I2C, I2S, SPI, CAN, USB, 1 wire, RS232, RS485, DMX512, MIDI IN OUT wraz z stosownymi driverami, złącze pod LCD HD44780 (to też standard), jedno lub kilka złącz pod wybrane dobrze udokumentowane GLCD (TFT) – temat do doprecyzowania, złącze pod wyświetlacze 7-mio segmentowe (dwa poczwórne, sterowane multipleksowo), złącze w standardzie NUCLEO, może kilaka złącz w innych popularnych standardach – temat do rozeznania, uniwersalne złączę, jedno lub kilka, które można sobie samemu skonfigurować (zasilanie, GND, odpowiednie sygnały, na odpowiednich miejscach), szerokość (ilość pinów) do ustalenia – chodzi o to żeby w prosty sposób, z użyciem minimalnej ilości połączeń (kabelków) móc podłączyć cały dostępny asortyment modułów na rynku.

Blok konwerterów poziomów napięć tak aby co najmniej 3 porty po 8 bit można było podłączyć w dowolnej konfiguracji i dowolnym poziomie napięciowym 5V<->3,3V<->2,8V<->1,8V (taki przykład) - jest to nieodzowne jeśli mają być stosowane procesory różnej maści .

To tyle na początek przychodzi mi do głowy, na pewno można jeszcze sporo uzupełnić i/lub zmienić.

P.S.
Zaznaczam że nie pretenduję do roli lidera, ot takie mam marzenia co do sytemu prototypownia.

Dzięki Kolego Phill2k za konkretny i szczegółowy opis modułów. Bardzo dobrze, że coś się zaczyna dziać. Odnośnie samej organizacji codziennie projektu a raczej projektów, to dzisiaj (Czwartek, 14.09) była na czacie dyskusja na ten temat, no i z tego co zrozumiałem (jeśli się mylę to proszę mnie poprawić), to mają chyba być dwa projekty, tzn.jeden dla początkujących użytkowników ( to co opisuje Kolega ZbeeGin ) oraz drugi, dla bardziej zaawansowanych - czyli wychodzi na to że ten. Jestem świeżo po tej dyskusji na czacie, a jeszcze nie wiem co miałby do powiedzenia w tej sprawie choćby Kolega Rezasurmar, którego akurat na czacie nie było. Niemniej w najbliższym czasie postaram się za radą Kolegi Mokrowskiego i Rezasurmar wykonać krótki research wśród obecnie dostępnych rozwiązań na rynku patrząc przez pryzmat, że projekt ma trafić do klienta na przynajmniej średnim poziomie zainteresowania elektroniką, technologią embedded devices. Następnie w oparciu o to postaram się nakreślić jakieś wstępne założenia projektu. Następnie a raczej jakby równolegle dobrze by było zweryfikować te założenia w oparciu o jakiś zarys kosztorysu/roboczo-godzin w odniesieniu do zaplanowania harmonogramu prac. Następnie... no właśnie nie bardzo wiem co, ale może to jest ten etap kiedy umieszcza się projekt na jakimś kickstarterze? -daje o sobie znać brak doświadczenia. Przy okazji... wcześniej czy później trzeba będzie lidera projektu jakoś wybrać. W oparciu o to co pisał na czacie, ale i w swoich tutorialach Kolega Mokrowski dzieli się te obowiązki na m.in.
PM=Project Manager=Menadżer Projektu
PO=Product Owner=Właściciel Projektu
...a dalej zapomniałem...
W każdym razie zdaje sobie sprawę, że sytuacja wygląda tak, że każdy coś tam wie, w większości każda z osób BARDZO wiele wie, ale z drugiej strony nikt nie wie absolutnie WSZYSTKIEGO. Moja propozycja na tym etapie odnośnie epickiego określenia "LIDER PROJEKTU" jest taka, że po prostu proponuje zgłaszać kandydaturę jeśli ktoś byłby zainteresowany. Zdaję sobie także sprawę że to ja jestem autorem tego wpisu i to być może mnie do czegoś zobowiązuje. Niemniej chciałbym podkreślić, że jestem osobą, która wcześniej nie miała przyjemności kierować projektem typu startup, że nie znam mechanizmów analityki rynku konsumentów, marketingu i ekonomii. Jestem programistą, no i mam wizję jakąś projektu. To tyle jeśli o mnie chodzi. Uczciwie podchodząc do sprawy, nie wiem czy byłbym najlepszym z możliwych liderów. Także -podobnie jak Kolega Phill2k- nie pretenduje do zostania liderem projektu, ale jeśli nie będzie chętnych (a nie chciałbym żeby projekt z błahych powodów upadł) to mógłbym spróbować. Moje obawy dotyczą jednak tego, że brakuje mi doświadczenia w prowadzeniu projektu i dobrze by było mieć -jak to się mówi- doradców "pod ręką" - just in case.. tak na wszelki wypadek. Liderem to w moim przekonaniu powinna zostać osoba, która ma pewne doświadczenie, ma za sobą przynajmniej jeden udany projekt, którego była Menadżerem.

Odnośnie jeszcze teraz tego co pisałeś Kolego Phill2k:

phill2k pisze:Blok zasilania(...)Oczywiście całość zasilana z jednego zasilacza o odpowiedniej wydajności, aby wyeliminować plątaninę kabli na biurku.

Jak mam to rozumieć w odniesieniu do schematu przedstawionego wyżej przeze mnie? -
1. Czy to ma być jedną płytka PCB jako jeden moduł zasilania z wszystkimi możliwymi rodzajami napięć, w tym z wyprowadzeniem ich do silników krokowych, do urządzeń o wyższym poborze mocy?
2. Czy ma to być w jednej obudowie, a w środku odseparowane od siebie PCB, coś na zasadzie górnej części mojego schematu?

phill2k pisze:Moduł procesora(...)Zespół złączy

1. Jestem jak najbardziej na tak, jeśli chodzi o przygotowanie na płytce głównej miejsc gdzie będą wpinane PCB na których będą siedziały odpowiednie mikrokontrolery. Innymi słowy -jeśli dobrze rozumiem- ilość pinów na złączu goldpin ma odpowiadać wybranej rodzinie procesora? -czyli można by to podzielić na interface'y dla mikrokontrolerów 8, 14, 16, 32, 64... etc. etc. -nóżkowych? A wielkość każdego jednego interface'u dopasować tak, żeby arbitralnie zmieścił się każdy uC z wybranej rodziny?
2. Jestem na tak, jeśli chodzi o złącze arduino + złącze dla nucleo na płycie głównej.
3. Jestem na nie, jeśli chodzi o wszelkie moduły wejścia/wyjścia, które dałoby radę (poprzez złącza interface'ów) umieścić na osobnych PCB, żeby odciążyć płytę główną, a z drugiej strony zwiększyć jej uniwersalność (wymiana np.wyświetlacza na lepszy model). Chyba że miałby to być na przykład jakiś naprawdę niezawodny i uniwersalny LCD. Kwestia wyświetlaczy w ogóle sądzę że powinna być rozważona jako osobny moduł danych wyjściowych, ale to jest tylko moje zdanie.
4. Jestem na tak, jeśli chodzi o złącza danych bezpośrednich - jak I2C, SPI, CAN,1 wire, etc. umieszczonych na płycie głównej. Dobrze by było dodać opcje rozszerzenia (dołączenia) interfejsu do peryferyjnej wymiany danych, żeby była taka furtka na wypadek zbierania większej ilości danych, lub danych z urządzeń, które JESZCZE nie powstały (inny protokół wymiany danych, które dane mogłyby docierać przez moduł pośredniczący).

phill2k pisze:Blok konwerterów(...)

czyli rozumiem dodatkowy moduł znajdujący się gdzieś poza modułem zasilania, tylko nie wiem w tym momencie czy poza płytą główną czy na niej?

phill2k pisze:Zaznaczam że nie pretenduję do roli lidera, ot takie mam marzenia co do sytemu prototypownia.

Tak na marginesie.. Przyszło mi do głowy, czy będziemy korzystać z jakichś wybranych narzędzi prototypowania? Ja z bardziej profesjonalnych to posiadam jedynie Autotrax (dostałem ostatnio na ur., więc jeszcze nie wypróbowałem za bardzo). Ponoć zacny program.

Jeżeli jakieś błędy ortograficzne/interpunkcyjne mi się trafiły, to przepraszam, ale jest noc, a ja piszę z takiego terminala jaki posiadam - czyli komórka z "podpowiadaniem" składni...

Pozdrawiam! J23

Jeszcze dodam, że jeśli chodzi o research dostępnych produktów to mam taką prośbę, może niech każdy kto chce zestawi w tabelce swoje badane produkty z rubrykami, np. Zalety, wady, propozycja zmiany? To samo tyczy się innych aspektów projektu, tzn. póki to jest w tzw."proszku" to może niech każdy doda coś od siebie, żeby wiadomo było z czego wybierać, co analizować..

j23 pisze:Odnośnie jeszcze teraz tego co pisałeś Kolego Phill2k:
phill2k pisze:
Blok zasilania(...)Oczywiście całość zasilana z jednego zasilacza o odpowiedniej wydajności, aby wyeliminować plątaninę kabli na biurku.
Jak mam to rozumieć w odniesieniu do schematu przedstawionego wyżej przeze mnie? -
1. Czy to ma być jedną płytka PCB jako jeden moduł zasilania z wszystkimi możliwymi rodzajami napięć, w tym z wyprowadzeniem ich do silników krokowych, do urządzeń o wyższym poborze mocy?
2. Czy ma to być w jednej obudowie, a w środku odseparowane od siebie PCB, coś na zasadzie górnej części mojego schematu?

Nie doprecyzowałem wcześniej, wszystkie moduły, a w zasadzie bloki funkcyjne, czyli: zasilania, złącza i blok konwerterów mają stanowić płytę główną, jedynym modułem dokładanym (wpinanym) ma być moduł procesora.

j23 pisze:W każdym razie zdaje sobie sprawę, że sytuacja wygląda tak, że każdy coś tam wie, w większości każda z osób BARDZO wiele wie, ale z drugiej strony nikt nie wie absolutnie WSZYSTKIEGO. Moja propozycja na tym etapie odnośnie epickiego określenia "LIDER PROJEKTU" jest taka, że po prostu proponuje zgłaszać kandydaturę jeśli ktoś byłby zainteresowany. Zdaję sobie także sprawę że to ja jestem autorem tego wpisu i to być może mnie do czegoś zobowiązuje. Niemniej chciałbym podkreślić, że jestem osobą, która wcześniej nie miała przyjemności kierować projektem typu startup, że nie znam mechanizmów analityki rynku konsumentów, marketingu i ekonomii. Jestem programistą, no i mam wizję jakąś projektu. To tyle jeśli o mnie chodzi. Uczciwie podchodząc do sprawy, nie wiem czy byłbym najlepszym z możliwych liderów. Także -podobnie jak Kolega Phill2k- nie pretenduje do zostania liderem projektu, ale jeśli nie będzie chętnych (a nie chciałbym żeby projekt z błahych powodów upadł) to mógłbym spróbować. Moje obawy dotyczą jednak tego, że brakuje mi doświadczenia w prowadzeniu projektu i dobrze by było mieć -jak to się mówi- doradców "pod ręką" - just in case.. tak na wszelki wypadek. Liderem to w moim przekonaniu powinna zostać osoba, która ma pewne doświadczenie, ma za sobą przynajmniej jeden udany projekt, którego była Menadżerem.

manager..., marketing..., ekonomia..., analiza rynku..., startup..., kicktarter..., poczułem się ja w korpo , nie wiem czy to dobry kierunek na początek..., ...czy w ogóle to dobry kierunek...

j23 pisze:Tak na marginesie.. Przyszło mi do głowy, czy będziemy korzystać z jakichś wybranych narzędzi prototypowania? Ja z bardziej profesjonalnych to posiadam jedynie Autotrax (dostałem ostatnio na ur., więc jeszcze nie wypróbowałem za bardzo). Ponoć zacny program.

Na tym etapie to jest sprawa wtórna, żeby myśleć o sofcie najpierw trzeba mięć hardware.

j23 pisze:Jeszcze dodam, że jeśli chodzi o research dostępnych produktów to mam taką prośbę, może niech każdy kto chce zestawi w tabelce swoje badane produkty z rubrykami, np. Zalety, wady, propozycja zmiany? To samo tyczy się innych aspektów projektu, tzn. póki to jest w tzw."proszku" to może niech każdy doda coś od siebie, żeby wiadomo było z czego wybierać, co analizować..

Albo niech każdy napisz co chciałby mieć na takiej płytce, oprócz tego co było już zaproponowane, na podstawie takich informacji będzie można skompilować ogólne założenia.

rezasurmar pisze:Tu bym bardziej poszedł, nie co kto chce mieć, a co powinno być .
Bo gotowych obsadzonych Evalboardów jest na rynku już naprawdę sporo...

To co ma być wyjdzie po tym jak każdy określi co by chciał mieć - to taki swoisty research, ja zresztą piszesz różnych Evalboardówna na rynku jest bez liku, jeden ma to, drugi tamto, trzeci siamto, ale żaden nie ma wszystkiego co każdy by chciał mieć, w każdym zawsze czegoś brakuje...

rezasurmar pisze:Bardziej bym był skłonny zaproponować coś na zasadzie bazowej z gniazdami/zasilaniem/konwenterami napięć. A reszta na złączach/Pinach.

Dokładnie o takie coś mi chodzi...

phill2k pisze:A tak na marginesie... to nie wiem czy nie prościej i na początek szybciej było by zaproponować kurs/przykłady na KAMeleona od KAMAMI.
Co prawda na nim jest 'tylko' STM, ale nie wiem, czy przypadkiem nie było by lepszym sposobem spopularyzowanie np. najpierw jakiegoś Kursu (konkretnego, nie miganie diodą ... czyli np.
Od początku, np. potrzebujemy zmierzyć temperaturę, wyświetlić ją na lokalnym wyświetlaczu i wysłać po Wifi np.
I teraz od początku cały cykl, od czego zacząć, jak podejść do wyboru części, pisania biblioteki dla czujnika/wyświetlacza. Czy np. na początek połączenie klocków w postaci bibliotek. itp.
W tym wypadku, początkujący np. chce tylko dojść do celu jak najniższym kosztem (czas, zestaw itd.)
lub bardziej ambitny chce dowiedzieć się jak zacząć, jak podejść do tematu od początku by nie szukać po omacku, ewentualnie wydawać na zestawy 500zł, by potem odłożyć na półkę... albo mieć termometr w cenie prostego smartfona

Nie wiem, czy rzucanie się na zestaw o tak dużych możliwościach, bez porządnej bazy przykładów ma sens.
To kwestia już nawet nie finansowa, ale czasu potrzebnego na wdrożenie, a 'konkurencja' nie śpi. Zalewanie rynku kolejnym zestawem hmm, Czy to ma sens?

I tu dochodzimy do sedna sprawy, czy robimy kurs na bazie istniejącego rozwiązania dostępnego na rynku, czy robimy własny Ewalboard i na jego bazie kurs...

Generalnie skłaniam się bardziej do tego co napisał Rez, tzn. sensowne wydaje się wykorzystanie złącza nucleo na płycie evalboard + złącze arduino. Reszta, no to na pewno to co zostało już napisane przez Kolegę Phill2k, tzn. wyprowadzenie interface'ów na popularne złącza do komunikcji bezpośredniej (małe moduły, małe elementy elektroniczne) - okey. A co jeśli ktoś będzie chciał doprojektować sobie coś większej mocy? -czy takiej sytuacji nie bierzemy pod uwagę, bo np. wtedy to już każdy sam sobie zewnętrzne źródło zasilania buduje?
Jak rozumiem skłaniamy się ku wykorzystaniu standardu nucleo na płycie i do tego bydlaka (??? - no w każdym razie chodzi mi o ilość dostępnych pinów) dobudowujemy resztę tego co ma być na płycie? W ogóle brane są jakieś moduły zewnętrzne pod uwagę? -(poza tym głównym modułem evalboard)? -bo po trochu się pogubiłem.

Na razie widzę, że na evalboard mają być miejsca z goldpinami (moduły wpinane W evalboard, a nie poprzez magistralę) na:
- standard nucleo
- standard arduino
- moduł(y) zasilania
- moduł dla jakiegoś modułu typu standard OUTPUT danych (LCD, OLED) - robić to na jakimś stałym rozstawie pinów?
- moduł dla jakiegoś modułu typu standard INPUT danych (klawiaturka) - robić to na jakimś stałym rozstawie pinów?
- moduł(y) dla jakiegoś modułu typu extended I/O danych (FTDI, motodriver, karta SD) - robić to na jakimś stałym rozstawie pinów?
- moduł(y) konwertera poziomów napięć (hmm... czy to nie lepiej bezpośrednio jakoś przy tych dodatkowych modułach I/O, albo i tu i tu?)
- moduł dla PSoC'a? -tego tematu jeszcze nie ogarniam :/

Co do kursu - jasne, przecież można to robić równolegle. Zresztą te początkowe lekcje i tak będą w jakiś tam sposób spójne i podobne do tego co było już napisane gdzie indziej. Tyle, że trzeba celować w to co chce się przekazać, czyli np. wdrożenie do standardu nucleo, do arduino? Dopiero te późniejsze lekcje (jak rozumiem) będą wymagały już konkretnego evalboardu - chyba. No bo jak inaczej?

A jak to się ma do projektu Kolegi ZbeeGin to ja już kompletnie nie wiem. W każdym razie koncepcja przedstawiona powyżej jest całkiem okey. Wykorzystanie nucleo jako gotowca - całkiem sensowne.