Sterownik przemysłowy "GNUMASTER" - robimy ???

Prosty sterownik.
Od wielu lat projektuję specjalizowane sterowniki do różnych zadań. Są to produkty niszowe, wytwarzane w niewielkich a niekiedy pojedynczych ilościach. Z doświadczenia wiem, że wielu hobbystów i małe firmy działają w podobny sposób - wszyscy "odkrywamy koło". Każdy stara się stworzyć coś doskonałego, ale przy okazji popełnia te same szkolne błędy, które inni popełnili już wcześniej. Świat idzie do przodu, bo dawno odkrył skuteczność działań zespołowych. W tej sytuacji zdecydowałem się na wystąpienie z następującym apelem:
Zróbmy wspólnie sterownik przemysłowy na licencji "GNU".
W praktyce chodzi o to aby:
1) Zaimplementować jak najstabilniejsze rozwiązanie hardwarowe
2) Hardware musi gwarantować jak największą skalowalność
3) Zrobić ogólnodostępną, pełną dokumentację
4) Zaprojektować PCB oraz obudowę, tak aby były spełnione wymagania CE
5) Udostępnić wszystkim zainteresowanym jak największą ilość gotowych aplikacji
6) Jako mikrokontroler, proponuję zastosować ATMega128 + WinAVR
7) Proponuję rozważyć konstrukcję modułową - coś ala tego co miały pierwsze komputery, czyli płyta główna w którą można wkładać różne specjalistyczne moduły.
8) Architektura sterownika moim zdaniem powinna zapewniać możliwość uruchomienia zarówno systemów operacyjnych RTOS jak i prostych programów liniowych
9) Sterownik od strony technicznej powinien nadawać się do zastosowań jak najbardziej profesjonalnych i komercyjnych

Pytanie:
Czy ktoś z kolegów jest chętny aby razem ze mną zaangażować się w ten projekt ?
Czy taka inicjatywa ma sens ???

Pozdrawiam: www.gnumaster.pl

Teodor Otulak wrote:

Zróbmy wspólnie sterownik przemysłowy na licencji "GNU".

jestem ZA
każdy otwarty projekt - to bardzo wielka pomoc dla projektujących... nawet jeśli nie jest adaptowany jako gotowiec do...
jednak warto aby nasz gotowiec miał realną szansę powszechnego zastosowania w pewnych dziedzinach...

Teodor Otulak wrote:

6) Jako mikrokontroler, proponuję zastosować ATMega128 + WinAVR

a może jednak jakiś ARM ?
ARMy drogie nie są... soft GPL prawie "ten sam" co dla AVR został zrobiony -> WinARM

Teodor Otulak wrote:

Pytanie:
Czy ktoś z kolegów jest chętny aby razem ze mną zaangażować się w ten projekt ?

chętnie ... na ile czas pozwoli

Teodor Otulak wrote:

Czy taka inicjatywa ma sens ???

sens ma
zobaczymy ilu zbierze się robotników do prac społecznych

Ja jestem gotowy pomóc.
W zasadzie też uważam, że ARM byłby lepszy (przyzwoita cena, duży sdram i lista rozkazów doskonale przystosowana do obliczeń na bramkach)

Może Zbudować taki sterownik na zasadzie modułów, niech będzie podstawowa płyta, z kompletem I/O, optoizolacją wejść, ewentualnie wyjść, z przekaźnikami itp. poza tym układy zasilania i ewentualnie komunikacji.

Procesor niech będzie na dodatkowej płytce, która w zależności od potrzebnej aplikacji niech zawiera ARM7TDMI (Analog rozdaje je teraz za free), AVRa, Pica czy co kto lubi.

Obniży to koszty i nada projektowi elastyczności, po co komuś kto chce zrobić sterowanie klapką w kurniku RTOS, zewnętrzny RAM i hektar niewykorzystanej pamięci programu?

Trzeba określić podstawowe wymagania, ile wyjść/wejść, jakie wymiary.

PS. EKG nadal się buduje.

Hmmm a co od strony użytkownika? Planujecie jakiś specjalny soft to programowania tego sterownika? No bo jakoś uzytkownik musi sobie tą klapkę od kurnika zaimplementować.
Różnorodność procesorów...no obniża koszty...ale czy aby na pewno? Czas i wysiłek na opracowanie kilku platform chyba jednak źle się odbija na dopracowaniu projektu. Lepiej skupić się na jednej - dobrze opracowanej, przetestowanej. Ma to być w końcu profesjonalny projekt.

W każdym razie ciekawa inicjatywa i chętnię bym się dołączył w miarę możliwości, czasu, umiejętności i wiedzy.

Jestem zdecydowanie za tym ,aby procesor był dowolnego typu. Powinien być w formie modułu wkładanego do płytki bazowej. Jednocześnie, płytka powinna zapewniać obsługę wielu procesorów jednocześnie, bo na przykład:
1 procesor obsługuje ekran graficzny i touch panel
2 procesor obsługuje TCP/IP i web serwer
3 procesor obsługuje na przykład enkodery liniowe ( listwy pomiarowe)

A każdy z nich może pracować niezależnie i w czasie rzeczywistym.
W tym momencie rodzi się pytanie o magistralę systemową która umożliwi komunikację każdego procesora z każdym innym dowolnym a jednocześnie będzie 100% odporna na zakłócenia. Ja proponuję jako nośnik fizyczny zastosować RS-485 do przesyłu danych wzbogacone o dwie dodatkowe linie ___BUSY oraz ___MASTER_COMMAND, co znacznie uprości arbitraż taką magistralą
___Busy jest ustawiane przez procesor inicjujący przesył danych i jest sygnałem dla innych procesorów, że magistrala jest zajęta.
___MASTER_COMMAND jest linią sterowaną przez procesor główny i jej ustawienie powoduje natychmiastowe przejście pozostałych procesorów w tryb RX.

Ma ktoś lepszy pomysł ?

ko_rex wrote:

Hmmm a co od strony użytkownika? Planujecie jakiś specjalny soft to programowania tego sterownika? No bo jakoś uzytkownik musi sobie tą klapkę od kurnika zaimplementować.

jedna platforma - uprości... ułatwi ładowanie programu (np. SAM-BA przez USB dla atmelowego at91sam7x) i debugowanie JTAG

ko_rex wrote:

Różnorodność procesorów...no obniża koszty...ale czy aby na pewno? Czas i wysiłek na opracowanie kilku platform chyba jednak źle się odbija na dopracowaniu projektu.

zgadzam się - i głosuję za jedną platformą... najlepiej ARM
zapewne albo Philips lpc21xxx albo at91sam7xxx

Ja mam takie pytanie, jakie funkcje miałby posiadać taki sterownik?

Procesor dowolnego typu (przynajmniej w płytce głównej) mija się chyba z celem.

Są dwa główne powody:
1.Wkład pracy... jak każdy zacznie pracować na innym procesorze to pojawią się ew. niepotrzebne problemy, poza tym nagle jest kilkakrotnie więcej pracy do zrobienia...

2.Koszty - stosując jeden, nawet droższy, procesor można zrobić 100 płytek drukowanych, rozesłać między uczestników, kupić 100 procków itd. i koszty są względnie małe. Jak zaczniemy kombinować z różnymi procesorami, to taka możliwość hurtowego/pół-hurtowego zakupu częściowo odpadnie. Poza tym stosowanie dwóch płytek bazowych (płytka z we/wy i płytka z CPU) mija się chyba z celem.

Ja jednak bym proponował dobrać jakiś szybki, wszechstronny procesor i wokół niego zbudować płytke główną, która samodzielnie mogłaby robić za mały sterownik (np. taki do wymienionego kórnika). Troche wyższy koszt procesora byłby rekompensowany niższą ceną zakupu elementów.

Druga sprawa to jest ustalenie modelu komunikacji płytki głównej z innymi podzespołami.
Do komunikacji proponowałbym raczej coś w stylu I2C - przyzwoita prędkość i powinna w zupełności wystarczyć do podłączenia kilku modułów I/O (w modułach może siedzieć jakiś tani uC z dużą ilością I/O, który tylko by przekazywał dane).

Poza tym na ARMie mamy 2 UARTY. Jeden może być wykorzystywany do łączenia z komputerem w celu zaprogramowania, drugi do komunikacji z innymi modułami głównymi takimi jak ekran graficzny z panelem dotykowym.

Ewentualnie jeżeli ktoś chciałby zrobić sterownik-potwora to drugiego UARTa można przerobić na rs485 z obsługą wielu urządzeń i łączyć kilka/wiele płytek głównych razem. Pytanie tylko w ilu zastosowaniach będzie potrzebne więcej niż 1 płytka główna, 1 panel graficzny i ew. 1 łącze ethernet/radiowe/whatever ?

bardzo ciekawy pomysł. ale mam jedną wątpliwość.
procesor ARM + ekran LCD z panelem dotykowym + moduł sieciowy + modół wejścia wyjscia = bardzo duzo kasy

teraz jest pytanie czy to się opłaca robić bo koszty wyniosą pewnie w sumie z 1k PLN'ów a za tę kase to mzona by juz kupić coś gotowego.
to jest tylko moja wątpliwość.

po drugie to bardzo mi się podoba pomysł z jakimś wspólnym dziełem ze stajni elektroda.pl
chętnie też bym się włączył ale niestety na arm'ach sie nie znam wcale.
ale jak by było potrzeba coś na AVR to chętnie pomoge.

pozdrawiam

PS Atmega128 też duzo potrafi

Sterownik z punktu widzenia użytkownika jest to skrzynka do której podłącza różne druty sterujące elementami wykonawczymi. Dla niego jest ważne aby sterownik:
1) pracował stabilnie w każdych okolicznościach
2) był tani

Dla konstruktora sterownik to elementy + oprogramowanie. Dla niego ważne jest aby:
1) Hardware było odporne na zakłócenia
2) Dawało się łatwo adaptować
3) Posiadało dużo gotowych bibliotek oprogramowania
4) Było tanie

Jaki z tego wniosek ???
Ano po pierwsze: Mieszanie rodzajów procesorów nie ma jednak żadnego sensu. Płyka bazowa powinna zawierać:
a) procesor AT Mega 128 ( tani i już dopracowany)
b) zasilacz
c) we-wy cyfrowe o poziomie TTL
d) przekaźniki wyjściowe na 230V
e) We analogowe 0-10V
f) Wy analogowe 0-0 V
g) Złącze do wyświetlaczy LCD:
- 2 x 16 linii + klawiatura
- 320x240 punktów graficzny + touchpad
h) mieć na pokładzie RTC z podtrzymaniem bateryjnym
i) na płytce powinny być jeszcze dwa inne sloty na karty rozszerzające
j) uproszczona komunikacja na SPI
k) bootloder na RSie z Max232 do PC
i) RS485 do połączeń na większe odległości

Powyższe wyposażenie pozwala praktycznie na realizację sterowania dowolnym procesem.

Teraz należałoby zadać sobie pytanie do czego taki sterownik może się przydać ??? Od tego w dużej mierze zależy co tak naprawdę należałoby w nim zaimplementować.

hunterhouse wrote:

bardzo ciekawy pomysł. ale mam jedną wątpliwość.
procesor ARM + ekran LCD z panelem dotykowym + moduł sieciowy + modół wejścia wyjscia = bardzo duzo kasy

zasadnicza część projektu to płyta procesora wraz z podstawowymi peryferiami... zewnętrza typu LCD - to opcja...

hunterhouse wrote:

teraz jest pytanie czy to się opłaca robić bo koszty wyniosą pewnie w sumie z 1k PLN'ów a za tę kase to mzona by juz kupić coś gotowego.
to jest tylko moja wątpliwość.

sama płyta procesora - wyniesie mniej...

hunterhouse wrote:

...chętnie też bym się włączył ale niestety na arm'ach sie nie znam wcale.

ależ to bardzo dobra okazja aby wreszcie się ARMów nauczyć

markcomp77 wrote:

hunterhouse wrote:

...chętnie też bym się włączył ale niestety na arm'ach sie nie znam wcale.

ależ to bardzo dobra okazja aby wreszcie się ARMów nauczyć

no może i warto sie tego nauczyć, już nawet o tym myśle i troche czytałem ale żeby projekt był udany to raczej powinien być tworzny przez osoby z jakim doswiadczeniem.

jak sie zdecydujecie na Atmega to sie może przydam

ADD:

A teraz drugie pytanie. bo w sumie elektronika to pikuś ale najtrudniejsz eedzie zbudowanie jakiś sensownego oprogramowania na PC. czy ma to być tylko zestaw bibliotek w c czy ma to być jakis kompilator i całe studio??
jeśli miało by to być na AVR i mieć duzo popularność to trzeba by też napisać procedurki w bacomie.

Teodor:Jedno pytanko.. po co wyjście na panel 320x240 z ekranem dotykowym?
Jak często jest coś takiego stosowane?
No i najważniejsze... obsługa tego chyba by zjadła całą/większość mocy atmelka (chyba, że masz na myśli jakiś konkretny panel z własną pamięcią wew i procesorem obsługującym? link do dokumentacji?)

Jeżeli nie ma jakiegoś gotowego modułu LCD z własną pamięcią to zdecydowanie zostawiłbym to do podłączenia jako komponent zewnętrzny z dedykowanym procesorem i połączeniem po rs232/485

Może dobrym pomysłem byłoby przygotowanie na płytce głównej gniazda na dodatkową pamięc I2C/SPI typu fram - http://www.tme.pl/katalog/index.phtml?tme_session=kebrje4mk29co6fk1e19svpj8r9pil3m&sid=&f_szukaj=prom&f_radio=&idp=1
Mogłyby z powodzeniem być używane jako pamięc operacyjna i dodatkowo jest to pamięc nie ulotna, więc w razie resetu można wrócić do poprzedniego stanu pracy (jeżeli nastąpił tylko krótki reset) lub wejść w bezpieczny stan wyjść, jeżeli prądu nie było dłużej

W środowisku GNU - WinAVR.
Osobiście nie jestem zwolennikiem:
a) wynalazków typu BASCOM - jest nieprzewidywalne
b) skrobania w assemblerze - nikt oprócz Twórcy ( w chwili tworzenia) nie wie jak to działa

Tak więc jedyną sensowną sugestią jest C. Aplikacje napisane w tym języku są przenośne, tak więc przy zmianie typu procesora wystarczy dostosować do jego specyfiki.

Jako że sterownik ma być GNU to i programowany powinien być w dobrze się rozwijającym środowisku GNU, a takim bez wątpienia jest WinAvr.

Dodano po 6 [minuty]:

Po to aby nie trzeba było do każdej specyficznej aplikacji robić odzielnego front panelu z przyciskami. Wystarczy zmiana oprogramowania, aby użytkownik miał do dyspozycji takie przyciski, suwaki i potencjometry itd. jakich potrzebuje w danym konkretnym zastosowaniu.
Jeżeli chodzi o obsługę tego, to jest prosta i wcale nie zżera dużo pamieci. O ile dobrze pamiętam, to oprogramowanie które robiłem jakiś czas temu, miało 11 ekranów menu i zeżarło razem z innymi dodatkami coś koło 67kB. Czyli toche ponad połowę pamięci ATMegi128. A było tam praktycznie wszystko, od flashów 1Mb po dallasy DS1820S. Tak więc procesor ma duuuży zapas

zapisuję się do projektu bardzo chętnie pomogę

Teodor:
Napisz linka do tego panelu, chciałbym poznać jego datasheet no i mógłbyś podać jego cenę.
Oprogramowaniem graficznym takiego panelu mógłbym się zająć, mam w tym duże doświadczenie więc możnaby porobić wszystko włącznie z wykresami i innymi pierdołami - co kto lubi.

Co do programowania, no to chyba jedyne rozsądne rozwiązanie to tak jak podawał Teodor - język C + zestaw funkcji pomocniczych odpowiadających za oprogramowanie płytki głównej i dołączonych modułów.

A co do pamięci, to chodziło mi o pamięć operacyjną a nie flash... atmega nie ma za dużo pamięci i tutaj fram byłby dobrym dodatkiem, no i dodatkowy bonus w postaci zachowania danych mimo resetu i możliwości kontynuowania pracy.
Poza tym ta pamięc mogłaby być przylutowywana do płytki wg. potrzeb, więc wystarczy wyprowadzić kilka wyjść do obudowy so-8 i zadanie wykonane.

Jest jeszcze jeden element, nie wiem czy przydatny - komunikaty audio?
Wykorzystuje się coś takiego od czasu do czasu przy sterownikach?
Można to łatwo zrobić za pomocą jednego-dwóch pinów w mikroprocesorze i kilku-kilkunastu kb pamięci flash na przechowywanie danych ( wystarczy na zapis kilku-kilkunastu sekund dźwięku typu głos ludzki)

W najbliższym czasie opublikuję w internecie schematy, pytki i źródła oprogramowania dla maszyny do straszenia ptaków wędrownych. Odtwarza ona dźwięki audio. Do tego jest oprogramowanie na PC umożliwiające ich wgrywanie.

Nie jestem przekonany do pamięci FRAM w obudowie 8 pinowej. Przyczyna jest prosta- będzie ona zamulać pracę systemu. Jeżeli w takim RAMIE będą dane to ich odczyt ma się nijak do odczytu z normalnego RAMU. W praktyce ATMega128 potrzebuje zewnętrznego ramu dopiero przy stosowaniu RTOSA dużego kalibru. Te 8kB ramu które ma w sobie jest naprawdę optymalnie wykorzystywane przez GCC na różne zmienne. Jeżeli zachodzi koniecznośc przechowywania danych strumieniowych, to najprościej to zrobić stosując kawałek twardego dysku lub Flasha (IDE). Jeżeli są potrzebne duże ilości zmiennych o krótkim czasie dostępu, to doczepia się RAM. Tu uwaga: jak wykazuje praktyka, musi to być RAM o odpowiedni okrótkim czasie dostępu, bo wbrew pozorom, ATMega 128 pracujący na 16 MHz ma bardzo duże wymagania czasowe dla RAMu.

Teodor Otulak wrote:

Te 8kB ramu które ma w sobie jest naprawdę optymalnie wykorzystywane przez GCC na różne zmienne. Jeżeli zachodzi koniecznośc przechowywania danych strumieniowych, to najprościej to zrobić stosując kawałek twardego dysku lub Flasha (IDE). Jeżeli są potrzebne duże ilości zmiennych o krótkim czasie dostępu, to doczepia się RAM. Tu uwaga: jak wykazuje praktyka, musi to być RAM o odpowiedni okrótkim czasie dostępu, bo wbrew pozorom, ATMega 128 pracujący na 16 MHz ma bardzo duże wymagania czasowe dla RAMu.

Atmega128 ma 4kB ram(no chyba że liczysz z epromem) . a co do ramu to nigdy za wiele wiec zewnętrzny ram powienien być, można go zrobić modułowo.
PS ja dałem do atmega128 zawnętrzny ram 70ns i zwykły zatrzask z seri hc i i śmiga na 16 Mhz chociaż w sumie nie powinno.

Teodor Otulak wrote:

Płyka bazowa powinna zawierać:
a) procesor AT Mega 128 ( tani i już dopracowany)
b) zasilacz
c) we-wy cyfrowe o poziomie TTL
d) przekaźniki wyjściowe na 230V
e) We analogowe 0-10V
f) Wy analogowe 0-0 V
g) Złącze do wyświetlaczy LCD:
- 2 x 16 linii + klawiatura
- 320x240 punktów graficzny + touchpad
h) mieć na pokładzie RTC z podtrzymaniem bateryjnym
i) na płytce powinny być jeszcze dwa inne sloty na karty rozszerzające
j) uproszczona komunikacja na SPI
k) bootloder na RSie z Max232 do PC
i) RS485 do połączeń na większe odległości

Powyższe wyposażenie pozwala praktycznie na realizację sterowania dowolnym procesem.

Czy to są założenia projektowe?
Myślę, że są odpowiednio przemyślane i podparte długoletnim doświadczaniem. Jednak... jakie są jeszce argumenty, żeby nie używać jednak ARM? Sterownik byłby szybszy i odpada problem z ramem, bo za 35 zł mamy kostkę z 32kB SRAM i do tego bogatsze peryferia (np. USB).

Jeśli zostajemy jednak przy mega128, to zawsze można zostawić miejsce na zewn. RAM (nawet w DIPie, choć to tragedia powierzchniowa jest).
Magistrala 485 to chyba konieczność (jednym z założeń jest odporność na zakłócenia), a z szybkością jej też nie ma problemu, można ją mocno pogonić i bez problemu umieszczać odległe moduły I/O. Własnie... moduły można (trzeba!) opracować kilka modułów z wejściami ceyfrowymi lub/i analogowymi - jakieś małe uK na pokładzie z prostym niezawodnym softem. yyyyyyyyy zapomniałem co jeszcze...

Jak mam rozumieć sprawę programowania? Mamy bootloader w sterowniku, a użykownik pisze sobei soft na mega128 używając odpowiednich bibliotek stworzonych przez nas? Czy to aby nie jest nasjłabsze ogniwo? Jak można w ten sposób zapewnić w miarę bezpieczne zachowanie sterownika?

A może ATmega2560 ?

Czym jest spowodowany brak akceptacji ARM ?
Ja odnoszę wrażenie, iż wybór AVR spowoduje problemy... np. przy aplikacjach... przetwarzaniu video - budując taki IP-WebCam
http://212.254.22.36:8080/
http://forum.mikrokontrolery.net/viewtopic.php?t=392

Dlaczego AVR ?
bo większość z zabierających głos tak dobrze go już zna?
przecież to nie jest projekt komercyjny - "szybko i tanio"
może być trochę wolniej... a w naszym dobrze rozumianym interesie jest się nauczyć się ARMa - ja na to liczę...
aspekt edukacyjny projektów open source (hardware) to podstawa...

markcomp... jeżeli zbudujesz takiego webcama, to czy tak nie wrzucisz tego na procka będącego na płycie głównej, bo o obsłudze programu głównego mógłbyś wtedy zapomnieć.

A moduł z kamerą i analizą obrazu opartą na armie możesz podłączyc pod rs485 i stosować jako "dodatkowy czujnik". AVR na płycie głównej w tym momencie niczemu nie przeszkadza, bo on tylko dowodzi tym ustrojstwem.

wydaje mi się że narazie powiniśmy zacząć od AVR a jednego powodu. AVR wszszycy znają i mają do niego dużo sprzętu i pogramów i narzędzi i doświadczenia.
a kiedy cały system będzie gotowy można przerobić modół z CPU na ARM'a i wtedy tylko zmienić biblioteki a reszta systemu zostanie.
lepiej robić coś małymi kroczkami bo jak weżmiesz za duzy krok to ze schodów spadniesz i nic nie wyjdze.

Cześć Wszystkim

Pomysł bardzo mi się podoba !

Ze swojej strony proponuję aby uwzględnić w "genach" projektu
jeszcze jedną opcję interfejsu : Ethernet.

Najlepiej jako opcjonalny moduł.

Pozdrawiam

Zaczniemy od najważniejszego - wyboru obudowy. Jak wiadomo, jest to podstawowy problem wszelakiej "małej" elektroniki. W zasadzie wybór jest niewielki... Wydaje mi się, że optymalna będzie obudowa na szynę DIN, ponieważ:
1) jest bardzo tania
2) zapewnia wentylację
3) umożliwia budowę systemu rozproszonego, w którym każdy blok funkcjonalny znajdowałby się we własnej obudowie nawet bardzo oddalonej

W przypadku obudowy na szynę DIN kluczowa staje się sprawa zasilania, nie zbyt wiele miejsca na pakowanie tradycyjnych transformatorów, proponuję zasilacz impulsowy na bazie TOP-SWICHA. Wychodzi to finansowo dokładnie tak samo jak transformator+prostownik+stailizatory, a daje większą moc i dwa napięcia +12 i +5 bez problemu. A jeszcze lepiej, to po prostu zastosować zewnętrzny zasilacz DC, typowy dla automatyki czyli na 24V. Wtedy w sterowniku wystarczy umieścić dwa stabilizatory impulsowe, co jest dużo prostsze i zajmuje najmniej miejsca.

Tak się złożyło, że zostało mi sporo uniwersalnych klawiatur do wyświetlacza 2x16 właśnie na szynę DIN. Są one od jakiegoś projektu zdalnego manipulatora sprzed kilku lat, nawet nie bardzo pamiętam o co w nim chodziło... Ważne, że sąto przody na szynę DIN i są dostępne od ręki Jest tam bodaj 9 przycisków funkcyjnych, rozmieszczonych dookoła wyświetlacza. Może to się przyda ?

Projekty !!!
Acha, jeśli chodzi o temat postu, to należy zauważyć, że projektując coś w grupie, trzeba się posługiwać tym samym oprogramowaniem do schematów i PCB. W tym temacie mam dwie propozycje:
1) EAGLE - bo jest wersja freeware, co prawda daje tylko bardzo małe płytki PCB, ale schematy można rysować dowolnie skomplikowane.
2) DiPTrace.PL - jest po polsku i w wersji edukacyjnej nie ma ograniczenia czasowego.

Ja osobiście projektuję w EAGLU 4.17, chociaż jestem dystrybutorem DipTrace na Polskę i autorem spolszczenia w jednej osobie. W przypadku jednak tego sterownika, jestem skłonny przesiąść się na DipTrace.PL z prostej przyczyny: w ostatnim roku wiele placówek dydaktycznych rozpoczęło nauczanie DipTrace jako narzędzia do projektowania, bo jest po polsku i jest tanie. Tak więc jeżeli nasz sterownik miałby mieć walory edukacyjne, do dobrze by było aby schematy i płytki mógł sobie wykonać każdy. Unifikacja oprogramowania jest o tyle ważna, że każdy kolejny konstruktor może rozwijać dzieło od momentu w którym zostało ono przerwane, a nie wklepywać wszystko od nowa. Osobom, które zaangażują się w nasz projekt czynem a nie tylko słowem, zapewnię licencję użytkownika na DipTrace.PL taką samą jaką otrzymują placówki oświatowe. Zobaczcie o czym mówię: www.diptrace.pl

zasilanie - wydaje mi się że lepiej było by dać 24V z zewnątrz i stabilizator impulsowy (mam miłe doświadczenie z LM2576. 3,3V lub 5V lub 12V i 3A wiec powinno wystarczyć). nigdy nie lubiłem robić 220V w jednej obudowie z uP. i to niz z powodu że zakłócenia lub coś tylko juz kilka razy przy projektowaniu zostałem porażony. (nic przyjemnego ( )

wydaje mi się że układ powinien byc maxymalnie prosty bo co proste to niezawodne.

to jaki w końcu procesor ??? ATMEGA128 czy coś innego.

Osobiście stosuje darmową wersje eagle, ale jeżeli 100x80 nie wystarczy to można się pobawić diptrace, szczególnie że projekt płytki to w głównej mierze będzie rozwijać jedna osoba, a inne będą raczej mówiły swoje uwagi... inaczej byśmy chyba do niczego nie doszli =)

Teodor:może jedna uwaga.. jak już mówimy o konkretnym sprzęcie, to podawaj prosze namiary gdzie coś takiego mozna dostać/do dokumentacji. W ten sposób wszyscy możemy składać to samo z tych samych części, co bardzo ułatwi prace projektowe.

jaki CAD do PCB ?

KiCAD - do rozważań programu do PCB można dorzucić KiCADa
http://www.lis.inpg.fr/realise_au_lis/kicad/
jest GPL... a możliwe, że ktoś dorobić do niego komunikaty no polsku... jest równocześnie na Win32 i Linuksa (podobnie jak Eagle)

Eagle wszyscy znamy... wiadomo co jest wart

DipTrace - właśnie próbuję zrobić jakiś projekt... program jest całkiem fajny - choć troszeczkę inaczej idzie robota jak Eagle... częściej trzeba dorabiać coś w bibliotekach... wersja za darmo pozwala zrobić większą pcb niż Eagle - ograniczenie jest na ilość otworów (czy jakoś tak).. pracuję na wersji ściągniętej z
http://diptrace.com/
program warty rozważenie - cena jest do przełknięcia... bardziej niż Eagle

Myśle że zamiast budować od razu panele masa*masa pikseli, powinniśmy najpierw zbudować prosty moduł, niech będzie na medze128, na początek bez ramu. Do tego kilka wejść i wyjść.

Najtrudniej dojść do najprostrzego, zostawmy interfejs RS485 do kumunikacji, gdy uda się już opracować jakiś system, zajmiemy się wyświetlaczem, matrycami dotykowymi, ethernetami i innymi modułami. Na początek cokolwiek.

Proponuje moduł - 8 wejść analogowych, 8 cyfrowych, 8 wyjść przekaźnikowych. DO tego niech będzie LCD i odpowiednia ilość przycisków.

Gdy uda się dopracować i uruchomić taki sterownik, będziemy się martwić ile dołożyć ramu i jaka przekątna wyświetlacza.

Jestem za Eaglem, znam go najlepiej i nawet lubie

no to dobra.
wyjścia przekaźnikowe:. przekaźniki można by sterować przez układu ULN2803A http://www.elenota.pl/d.php?id=62999&pdf=1536 bezpośrednio z portu mikrokontrolera.

wejścia cyfrowe (standard 24V ??) trzeba by dać przez optoizolację.
w tme znalazłem np 4N26 .
na wejściu należało by dać rezystor ograniczający prąd i diodę zenera na 5,1V szeregowo z diodą w optoizolatorze żeby niskie napięcie nie powodowały włączenia tranzystora.
foto tranzystor dać bezpośrednio na wejście uP i podciągać je do +5V prze z rezystor.

wejścia analogowe ??? tu trzeba by albo dać zewnętrzny przetwornik albo skorzystać z wbudowanego w ATmege.
układ wejściowy. np. dzielnik napięcie i diodę zenera za dzielnikiem aby obciąć nadmiar napięcia w przypadku awarii.
dobrze by było dać też transile (albo jakoś tak to się nazywa) aby zabezpieczyć się przed impulsami wysokiego napięcia.

należało by sie zastanowić czy nie trzeba by zastosować jakiegoś rozszeżenia pinów mikrokontrolera np przez I\O na I2C
Ja tak to widzę.

Natomiast nigdy nie stosowałem RS-485 i nie bardzo wiem z czym to się je. Czy można wykorzystać do tego Max’a i sprzętowy UART ???

ADD:
co do programatora to mam taki dziwny pomysł. zamiast dawać bootloader który będzie wgrywał program do uP to mozna zastosować przerobiony AVR-ISP ze strony http://www.mikrocontroller-projekte.de/
oczywiście dać max232 zamiast tego dziwactwa do komunikacji przez UART. stosuje ten programator juz od długiego czasu i naprawde szybko programuje uP. w poruwnaniu z STK200 pewnie z 10razy szybszy.

A co powiecie na "kanapkę" :

płytka z I/O , zasilaniem, RS-485 i w nią wpinana
płytka z procesorem, pamięcią, interfejsem do LCD i klawiatury.

To może umożliwić wykonanie następnej wersji z innym
procesorem ( ARM ) , większą pamięcią itp.