ATNEL tech-forum
https://forum.atnel.pl/

Atmega32 - główny procesor + Atmega8 - koprocesor.
https://forum.atnel.pl/topic24176.html
Strona 1 z 2

Autor:  Michal7129 [ 11 mar 2022, o 05:00 ]
Tytuł:  Atmega32 - główny procesor + Atmega8 - koprocesor.

Cześć Wszystkim!

Mam taką sprawę. Otóż chciałbym zrealizować układ, w skład którego by wchodziły 2 mikrokontrolery: atmega32 i atmega8. Porozumiewałyby się one przez SPI (atmega32, jako MASTER, atmega8, jako SLAVE)*. Teraz chciałbym, aby te dwie atmegi były taktowane zewnętrznym kwarcem. No i tu dochodzę do sedna: atmegę32 chcę taktować kwarcem 20MHz, natomiast do atmegi8 nie chcę podłączać osobno, w sensie fizycznym -- drugiego kwarcu, tylko jakby dać sygnał taktujący z atmegi32 (bądź z częstotliwością te 20MHz, bądź z jakimś, nazwijmy to, rodzajem preskalera, np. /4, czyli by było teoretycznie 5MHz dla atmegi8). No i moje pytanie jest, czy po 1. to w ogóle jest możliwe, w sensie, czy AVR-y udostępniają taką, nazwijmy to, funkcjonalność; po 2., jeśli jest to możliwe, to jak to zrealizować. Zrealizować i pod względem hardware'owym (jak te atmegi podłączyć ze sobą w aspekcie sygnału taktującego), i pod względem software'wym: co potencjalnie trzeba poustawiać w nich, żeby to po prostu działało. Będę ogromnie Wam wdzięczny za wszystkie odpowiedzi.



-----------
* Nawiasem mówiąc, bawię się w stworzenie układu z jednym procesorem (m32), jako procesorem "właściwym", a drugi procek (m8) ma pracować, jako "koprocesor" (głównie chcę na nim zrealizować takie zadania, jak obsługa LCD, klawiatury matrycowej, itp. rzeczy peryferyjne).

Autor:  tonygryps [ 11 mar 2022, o 08:30 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

A weź stykówkę włóż te dwa procki i pokombinuj pdf jednej i drugiej atmegi masz ogólnie dostępny.

Autor:  Michal7129 [ 11 mar 2022, o 08:57 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

tonygryps napisał(a):
A weź stykówkę włóż te dwa procki i pokombinuj pdf jednej i drugiej atmegi masz ogólnie dostępny.


Rzecz w tym, że nie chce mi się potencjalnie po 1): wyważać "otwartych drzwi", jeśliby się okazało, że tego typu rozwiązanie/funkcjonalność jest czymś zupełnie dozwolonym i stosowanym w AVR-ach; po 2): jeśliby się okazało, że totalnie nie ma takiej możliwości, to przyznaję wprost, że szkoda mi na to zachodu. Dlatego tak piszę, bo jakiś czas temu próbowałem coś na ten temat właśnie już sprawdzić w necie, i nic zasadniczo nie mogłem znaleźć jednoznacznego ani "za", ani "przeciw" (a naprawdę szperałem i to praktycznie wszędzie na ile mi cierpliwości starczyło, po anglojęzycznych forach oczywiście też). Niby gdzieś ktoś wspominał, że teoretycznie można, ale ani schematu, ani opisu w ogóle itd. Jeśli rzeczywiście można, to oprócz kwestii połączenia w sensie hardware'u, największa "perypetie", jak czuję -- potencjalnie będą z ustawianiem fuesbitów, jeśli się tylko na fuesbitach skończy. Może dodatkowo będzie trzeba np. programowo to zrealizować jakimś przerwaniem zewnętrznym itp. No nie wiem, autentycznie nie wiem, to tylko takie moje przeczucia, wróżenie "z fusów". Dlatego do Was się tu zwracam, a w szczególności do Pana Mirka (jeśli nikt inny nie będzie wiedział), ażeby ktoś mi w tej kwestii pomógł.

Autor:  jarekt [ 11 mar 2022, o 10:15 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

Michał, co cię skłania do takiego nietypowego rozwiązania?
Kwarc i 2 kondensatorki to przecież grosze, wymiarowo też niewiele miejsca na płytce zajmują. Dlaczego nie chcesz/nie możesz ich zastosować, tym bardziej że chcesz taktować procki różnymi zegarami?

Autor:  Michal7129 [ 11 mar 2022, o 11:22 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

jarekt napisał(a):
Michał, co cię skłania do takiego nietypowego rozwiązania?
Kwarc i 2 kondensatorki to przecież grosze, wymiarowo też niewiele miejsca na płytce zajmują. Dlaczego nie chcesz/nie możesz ich zastosować, tym bardziej że chcesz taktować procki różnymi zegarami?


W dużym skrócie buduję układ, w ogólności już, wieloprocesorowy, przy czym jeden procesor nadrzędny (atmega32) będzie "mózgiem" tego układu, a pozostałe procesory (ściślej, koprocesory) oprócz m.in., jak wspomniałem zadań głównie polegających na realizacji intefejsu z użytkownikiem (jak np. LCD, czy klawiatura matrycowa), będą miały za zadnie, jakby to ująć, nazwijmy to tak: "kontrolować się wzajemnie". Chcę wprowadzić jakby pewnego rodzaju "macierz sygnałową" między tymi procesorami -- taką, że wszystkie procki będą kontrolowały pewne parametry elektryczne układu jako całości (głównie potencjalne spadki napięcia w określonych punktach układu, potencjalne zaniki komunikacji między parami wzajemnie "sprzężonych" procesorów; pojawienie się np. dodatkowej pojemności np. przez dotknięcie ręką którejś z linii sygnałowych itp. itd.). Ażeby to zrealizować i było to rzeczywiście skuteczne, jeśli chodzi o końcowy cel, który chce przez to osiągnąć, to podstawowa wiedza z zakresu teorii sygnałów podpowiada mi, że wszystkie koprocesory łącznie z procesorem nadrzędnym (atmega32) powinny być dokładnie taktowane z jednego, fizycznego, tego samego źródła, jakim będzie jeden kwarc. To, że sygnał taktujący będzie wychodził z procesora nadrzędnego (atmega32) jest zaniedbywalnie małym "zaburzeniem" w stosunku do kwarcu. Ba! Są przecież gotowe układy scalone (specjalnie właśnie dedykowane, z tego co wiem, na platformy wielomikrokontrolerowe/mikroprocesorowe), będące idealnymi generatorami przebiegu prostokątnego, do których właśnie się podłącza JEDEN rezonator kwarcowy, a z KTÓRYCH rozprowadza się sygnał taktujący do wszystkich procków w danym układzie. Rzecz w tym, że ja nie mam teraz możliwości zdobycia takiego scalonego generatora, a układ, który chcę zrobić, chciałbym zrealizować jak najszybciej. W skrócie więc tak to wygląda.

Autor:  Michal7129 [ 11 mar 2022, o 13:26 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

Ktoś wie w końcu coś na ten temat, a nie tylko pyta "do czego to" (a do ..alarmu, buduje taki alarm, że jakakolwiek "chęć" nazwijmy to, "dezintegracji" jego obwodu bądź odcięcie, któregoś z wielu źródeł jego zasilania -- spowoduje natychmiastowe wysłanie krótkiej wiadomości drogą radiową i powiadomienie mnie)? W końcu zadałem pytanie nietrywialne, nie jestem raczej typowym lamerem, więc może ktoś się pokwapi i chociaż da mi zdawkową odpowiedź: twierdzącą lub przeczącą: TAK - istnieje taka możliwość, NIE - nie istnieje taka możliwość. No ludzie!!

Autor:  Michal7129 [ 11 mar 2022, o 19:26 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

A Ty, Mirek Kardaś? Też nie wiesz nic na ten temat?

Autor:  mirekk36 [ 11 mar 2022, o 19:47 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

1.) Np procki z serii ATmega88/168/328 mają dedykowane wyjście CLKO
2.) Koprocesor to: https://pl.wikipedia.org/wiki/Koprocesor
3.) Koledzy słusznie pytają do czego tobie taki kosmiczny pomysł, bo czasem lepiej się dowiedzieć co autor ma na myśli i wtedy można mu podpowiedzieć, że np w taki sposób w ogóle nie warto działać bo robi się to prościej, albo inaczej. Tym bardziej, że u ciebie problem wspólnego taktowania urasta do rangi gigantycznego problemu albo gigantycznej potrzeby, a polegniesz za chwilę na komunikacji między prockami bo nawet o niej nie wspominasz a to o wiele ważniejszy problem niż to na czym starasz się tu skupić.

Tym bardziej, że nawet gdyby potrzeba było wielu pinów procka i większych zasobów to masz procki typu ATmega128 albo ATmega2660 z dużo większą ilością pamięci i FLASH i RAM ... i tak na pierwszy rzut oka to można na takim jednym procku zrealizować wszystkie twoje założenia i jeszcze zostanie zapewne 60% wolnych zasobów procka.

A jeśli nie potrzeba aż tyle pinów to zajrzyj sobie do noty PDF procka ATmega1284 który ma aż 16 KB RAM! i 128 KB FLASH a obudowa i pinologia zgodna w 100% z ATmega32. Można je zastąpić 1:1.

Autor:  Michal7129 [ 11 mar 2022, o 20:52 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

Dziękuję Ci, Mirek, za tę odpowiedź. Przemyślę to wszystko jeszcze raz.

Autor:  Marhef [ 11 mar 2022, o 20:54 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

Kolego Michale, na spokojnie. Nie każdy siedzi cały dzień na forum i odpisuje natychmiast na pytania. Nie popędzaj nas.
Moim zdaniem założenia są... dziwne. Ale tak taktować się da.
Na m32 robisz generator sygnału - ustawiasz odpowiedni tryb, częstotliwość dograsz sobie.
Na m8 ustawiasz w fusebitach taktowanie na zewnętrzny sygnał zegarowy.

Ale mam tu pewne obawy: możesz mieć problem ze zgraniem komunikacji. Wydaje mi się, że każdy procek taktowany osobnym kwarcem (albo nawet dla niskich prędkości komunikacji wewnętrznym oscylatorem) tak dobranym, żeby minimalizować błędy transmisji, będzie lepszym rozwiązaniem.
A nawet zrealizować wszystko na jednym procesorze, nie wygląda to na zadania przekraczające możliwości pojedynczego AVRa

Autor:  0livaw [ 11 mar 2022, o 20:56 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

mirekk36 napisał(a):
A jeśli nie potrzeba aż tyle pinów to zajrzyj sobie do noty PDF procka ATmega1284 który ma aż 16 KB RAM! i 128 KB FLASH a obudowa i pinologia zgodna w 100% z ATmega32. Można je zastąpić 1:1.


Zasoby procesora ATmega1284 pozwalają na zbudowanie takiego sterownika PLC:
https://www.e-tronix.eu/46,sterownik-pl ... u-1-7.html

Wszystko zależy od zastosowania i koncepcji.

Autor:  Michal7129 [ 12 mar 2022, o 13:40 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

Dziękuję wszystkim za te cenne rady. Bardzo mi one ułatwiły realizację mojego projektu. To będzie alarm nie do "obejścia". Jak się go już uzbroi..:) pfuuu aktywuje, np. wpisując odpowiedni pin, to jedyny sposób jego dezaktywacji będzie polegał na wpisaniu z kolei pinu ..dezaktywacyjnego :). Każda próba, nawet najprymitywniejsza w postaci trzaśnięcia np. młotkiem w płytkę PCB -- skończy się natychmiastowym wysłaniem krótkiej, jak wspomniałem, wiadomości drogą radiową, która mnie powiadomi, że ktoś się włamał.. :). A to dlatego, że mój pomysł, polegający na zastosowaniu wielu procesorów "wzajemnie się próbkujących" + wielu źródeł zasilania (oprócz z zasilacza, także z akumulatorów i ukrytych superkondensatorów) jest bardzo prosty: nikt nie jest w stanie w jednym momencie rozwalić WSZYSTKICH procesorów, czy odłączyć WSZYSTKICH źródeł zasilania: ZAWSZE się pojawi, jakaś "delta t", taka, że któryś z jeszcze niezniszczonych na parę mikrosekund przed jego zniszczeniem, procesorów, zdąży "wysterować" układ końcowy.. :). Dobrze, temat, jakkolwiek z mojej strony już, uważam za zamknięty :).

Autor:  mario2015 [ 12 mar 2022, o 18:47 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

Michal7129
Cytuj:
niezniszczonych na parę mikrosekund przed jego zniszczeniem, procesorów, zdąży "wysterować" układ końcowy..


Supr pomysł i cała koncepcja tego projektu. Nawet kiedyś popełniłem kilka systemów alarmowych ale na taki pomysł nie wpadłem.
Gratuluję pomysłu i życzę udanego projektu.

Autor:  Michal7129 [ 12 mar 2022, o 21:25 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

mario2015 napisał(a):
Michal7129
Cytuj:
niezniszczonych na parę mikrosekund przed jego zniszczeniem, procesorów, zdąży "wysterować" układ końcowy..


Supr pomysł i cała koncepcja tego projektu. Nawet kiedyś popełniłem kilka systemów alarmowych ale na taki pomysł nie wpadłem.
Gratuluję pomysłu i życzę udanego projektu.

Dziękuję Ci bardzo, że doceniłeś tę koncepcję. Jest chyba rzeczywiście nowatorska (jakkolwiek, w sieci się jeszcze z czymś takim nie spotkałem, jak sprawdzałem, czy ktoś wpadł na coś podobnego już). Jeszcze raz dzięki za miłe słowa. Pozdrawiam Cię serdecznie.

Autor:  SylwekK [ 12 mar 2022, o 23:10 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

Rozwiązanie co najmniej dziwne. Ma być niezależny system, a drugi procek chcesz zsynchronizować z zegarem pierwszego. Wg mnie absurd. Niszcząc ten główny master, drugi przestaje działać i co wtedy ma wysłać wiadomość? Też w swoim życiu zrobiłem parę różnych zabezpieczeń i alarmów. Na mój gust nie tędy droga, ale kombinuj... Chętnie zobaczę co wymyśliłeś jeśli oczywiście podzielisz się odrobina informacji z prac, bo opis całego urządzenia raczej byłby niepoważny z punktu widzenia bezpieczeństwa :) Moje najskuteczniejsze zabezpieczenia okazały się te najprostsze, o których nikt nie wiedział, że w ogóle są ;)

Autor:  embedownik [ 12 mar 2022, o 23:48 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

w wielomikrokontrolerowych urządzonkach spotkałem się z sygnałem "heartbeat" - jakiś określony pattern na pinie gdzie jego odstępstwa były wykrywane (np zależności czasowe do sprawdzenia ewentualnych rozjazdów zegarów, lub sama jego obecność jako znak, że inny uc poprawnie pracuje) itp - może bardziej o coś takiego chodzi niż o bezpośrednie taktowanie?

Dodatkowo niektóre uCki mają coś takiego jak "tamper" jeśli chodzi o zabezpieczenia - może to jakoś pomoże.

Musisz przemyśleć, czy czasem takie koncepcje zabezpieczeń jak opisujesz to nie strzał z armaty do muchy pomimo tego, że brzmią fajnie (oczywiście jak zawsze - chyba, że to ma być aspekt edukacyjny - wtedy można się bawić).

Może jakby połączyć "taktowanie" i heartbeat - może da rade nadawać przez PWM jakiś szybki sygnalik (skoro pisałeś o reakcji w mikrosekundach), a jego weryfikację załatwić jakoś sprzętowo + przerwanie w chwili zaniku? Chociaż aktualnie nie wiem czy jakaś forma tego jest możliwa do ustawienia w atmegach. Coś typu licznik, który strzeli przerwanie po ustalonej wartości, ale wcześniej "zawsze" jest kasowany przez ten sygnał z zewnątrz.

Autor:  grzeniu 73 [ 13 mar 2022, o 09:46 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

Michal7129 napisał(a):
Dziękuję wszystkim za te cenne rady. Bardzo mi one ułatwiły realizację mojego projektu. To będzie alarm nie do "obejścia". Jak się go już uzbroi..:) pfuuu aktywuje, np. wpisując odpowiedni pin, to jedyny sposób jego dezaktywacji będzie polegał na wpisaniu z kolei pinu ..dezaktywacyjnego :). Każda próba, nawet najprymitywniejsza w postaci trzaśnięcia np. młotkiem w płytkę PCB -- skończy się natychmiastowym wysłaniem krótkiej, jak wspomniałem, wiadomości drogą radiową, która mnie powiadomi, że ktoś się włamał.. :). A to dlatego, że mój pomysł, polegający na zastosowaniu wielu procesorów "wzajemnie się próbkujących" + wielu źródeł zasilania (oprócz z zasilacza, także z akumulatorów i ukrytych superkondensatorów) jest bardzo prosty: nikt nie jest w stanie w jednym momencie rozwalić WSZYSTKICH procesorów, czy odłączyć WSZYSTKICH źródeł zasilania: ZAWSZE się pojawi, jakaś "delta t", taka, że któryś z jeszcze niezniszczonych na parę mikrosekund przed jego zniszczeniem, procesorów, zdąży "wysterować" układ końcowy.. :). Dobrze, temat, jakkolwiek z mojej strony już, uważam za zamknięty :).


Dopóki agresor nie przyjdzie z zagluszaczem fal :). Co chyb najprostsze w tym wypadku będzie

Autor:  Michal7129 [ 13 mar 2022, o 14:18 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

grzeniu 73 napisał(a):
Michal7129 napisał(a):
Dziękuję wszystkim za te cenne rady. Bardzo mi one ułatwiły realizację mojego projektu. To będzie alarm nie do "obejścia". Jak się go już uzbroi..:) pfuuu aktywuje, np. wpisując odpowiedni pin, to jedyny sposób jego dezaktywacji będzie polegał na wpisaniu z kolei pinu ..dezaktywacyjnego :). Każda próba, nawet najprymitywniejsza w postaci trzaśnięcia np. młotkiem w płytkę PCB -- skończy się natychmiastowym wysłaniem krótkiej, jak wspomniałem, wiadomości drogą radiową, która mnie powiadomi, że ktoś się włamał.. :). A to dlatego, że mój pomysł, polegający na zastosowaniu wielu procesorów "wzajemnie się próbkujących" + wielu źródeł zasilania (oprócz z zasilacza, także z akumulatorów i ukrytych superkondensatorów) jest bardzo prosty: nikt nie jest w stanie w jednym momencie rozwalić WSZYSTKICH procesorów, czy odłączyć WSZYSTKICH źródeł zasilania: ZAWSZE się pojawi, jakaś "delta t", taka, że któryś z jeszcze niezniszczonych na parę mikrosekund przed jego zniszczeniem, procesorów, zdąży "wysterować" układ końcowy.. :). Dobrze, temat, jakkolwiek z mojej strony już, uważam za zamknięty :).


Dopóki agresor nie przyjdzie z zagluszaczem fal :). Co chyb najprostsze w tym wypadku będzie

No tak, zgadza się, to "pięta Achillesowa" mojego alarmu hehe :), ale któż prócz służb specjalnych/policji... :P dysponuje i używa specjalistycznych zagłuszaczy fal (jak np te do telefonii GSM, bo zwykły analogowy zagłuszacz na nie wiele się zda hehe tu również :))... hehe, no a służby specjalne, czy policja to przecież nie złodzieje, nie wpadają nagle do domu.. heh, ale chronią przed włamywaczami.. :) .

Autor:  embedownik [ 13 mar 2022, o 17:17 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

wszystko zależy w który "security grade" celujesz - jest specjalny punkt, ze włamywacz ma jakąś wiedzę o systemie + dedykowane narzędzia itp.

Autor:  Michal7129 [ 13 mar 2022, o 19:38 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

embedownik napisał(a):
wszystko zależy w który "security grade" celujesz - jest specjalny punkt, ze włamywacz ma jakąś wiedzę o systemie + dedykowane narzędzia itp.

Tak naprawdę z tymi zagłuszaczami sygnału też się da poradzić. Przemyślałem to naprawdę, przynajmniej w sensie koncepcyjnym, bardzo dobrze. Otóż wyobraźmy sobie sytuację, że wspomniany moduł alarmowy w domu (moduł "matka") będzie wyposażony nie tylko w nadajnik, a też i w odbiornik -- a moduł zdalny radiowy (nazwijmy go "córka"), który ma mnie powiadomić, nie będzie tylko odbiornikiem, ale będzie też miał nadajnik. Co za tym wszystkim idzie, to oczywiście dodatkowa komplikacja całego alarmu. Dobra, teraz koncepcja jest następująca: wciąż jest wymieniany sygnał, nazwijmy go, "bazowym" ("bazową ramką") między "matką" a córką; "matka" wysyła odpowiednią ramkę i jest tak, że w określonym czasie (czy też z jakimś marginesem błędu oczywiście; trzeba przewidzieć wiele sytuacji, np. zaburzenie, które może powstać od np. burzy, co jest i tak mało prawdopodobne itp. od zagłuszenia przez typowy zagłuszacz radiowy sygnału cyfrowego), "córka" musi odpowiedzieć z kolei swoją ramką danych, i po tym koło się powtarza. Dodatkowo, co jest bardzo ważne, obie ramki nie są stałymi zestawami danych (oprócz elementów niezmiennych, jak np. znaczniki ramki, sumy kontrolne itd.), ale zmieniają się po każdym cyklu wymiany ramek. Jak to jest zrealizowane? Na zasadzie tokenu, klucza OTP, po prostu koncepcyjnie; i "matka" i "córka" mają bardzo dokładne i sprzężone ze sobą zegary czasu rzeczywistego, i teraz jest algorytm, który po stronie zacznijmy np. od "matki" -- w oparciu o aktualną godzinę plus jakiś dodatkowy zhashowany salt wysyła określoną wiadomość, "córka" wtedy mając korelację względem zegara + mając ten sam początkowy zhashowany salt: rozpoznaje wiadomość od "matki" i wysyła z kolei wiadomość do "matki" odpowiednio skorelowaną, tak, że matka też ją rozpozna. Oczywiście, na samym początku trzeba będzie dwa moduły, "matkę" i "córkę" ze sobą skorelować, to jest wgrać ten sam salt i algorytm hashujący, co może się np. fizycznie zrealizować przez hardwarowe I PRZEWODOWE do tego połączenie dwóch modułów i zainicjowanie procesu korelacji. Od tego momentu "matka" i "córka" znają się wzajemnie. Po co takie ceregielenie się, ktoś może pomyśleć? Myślę jednak, że na tym forum nie brakuję zawodowców, a każdy z nich dokładnie wie, że w zależności od "nakładu środków i pracy odpowiedniego >>grade security<<", którego ma się ten system dotyczyć: można by po prostu przechwycić obie ramki i nagrać, a potem odpowiednio wysyłać w eter, żeby nasze moduły "oszukać". Tak to, na nic się to zda. Zatem scenariusz jest taki potencjalnie: oto ...włamywacz, dysponujący wysoko zaawansowanym generatorem radiowego szumu cyfrowego, nagle go uruchamia -- a tu nagle .."ZONK", układ wykonawczy się wyzwala, i dodatkowym jeszcze jakimś innym kanałem (nie wiem, może np. wysyła sygnał przez internet, który jest w domu światłowodowo podłączony, a "córka" już "w bezpiecznej odległości" od ..zagłuszacza, ma jeszcze dodatkowy moduł radiowy GSM z łącznością do internetu, i w ten sposób dochodzi do mnie powiadomienie). Ehhh, na razie to tylko koncepcję, ale aż sam się dziwię swojej pomysłowości :P.

Autor:  embedownik [ 13 mar 2022, o 23:55 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

Tzn to co napisałeś to mniej więcej opis jak działa każda szyfrowana bezprzewodowa komunikacja - czy to ZB, thread czy BT/BTmesh (z tym, że kluczami wymianiają się na etapie parowania, no może ZB w zależności od wersji to trochę inaczej - tam też kiedyś był motyw ze "statycznym kluczem/hasłem" itp) + użycie tam jakiejkolwiek wiadomości jako ping.

Autor:  Michal7129 [ 14 mar 2022, o 01:02 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

embedownik napisał(a):
Tzn to co napisałeś to mniej więcej opis jak działa każda szyfrowana bezprzewodowa komunikacja - czy to ZB, thread czy BT/BTmesh (z tym, że kluczami wymianiają się na etapie parowania, no może ZB w zależności od wersji to trochę inaczej - tam też kiedyś był motyw ze "statycznym kluczem/hasłem" itp) + użycie tam jakiejkolwiek wiadomości jako ping.

Oczywiście, wiem o tym dobrze. Ale ty mi zarzuciłeś, że "wystarczy tylko zagłuszacz sygnału radiowego". Otóż wykorzystanie wspomnianych protokołów daje totalną odporność na zagłuszenie. Włączasz zagłuszacz, odbiornik "matka" przestaje otrzymywać "ramkę bazową" od "córki", w związku z czym uaktywnia się alarm, wysyłając jakąś już jakąkolwiek nieradiową drogą (dałem przykład z internetem światłowodowym w domu) sygnał do pierwszego lepszego serwera, a ten już łącząc się z siecią komórkową, wysyła przez BTSa mi sygnał na moduł GSM "córki". Założenie jest logiczne, wszak zagłuszacz sygnału będzie uruchomiony w pobliżu domu, skąd ma wiedzieć włamywacz gdzie ja się aktualnie znajduję z modułem "córką"? Jeśli blisko domu, to i całego alarmu nie potrzebuję bo będę to widział na własne oczy. Oczywiście, można idąc twoim tokiem, dalej spekulować, i mówić, że np. włamywacz to przewidzi i odetnie dostęp do nieradiowego internetu w domu, owszem, jeszcze raz: można takie "piramidy logiczne" robić w nieskończoność, ale gdzieś jest "brzytwa Ockhama" i zwykły rozsądek: dajmy na to w twoim scenariuszu włamywacz by po pierwsze musiał w ogóle wiedzieć o tym, że mam taki autorski alarm (bo jak by nie wiedział, to najłatwiej by było wejść do domu i przy interfejsie z tym takim charakterystycznym wyświetlaczem, jak zwykle przy komercyjnych alarmach, pokombinować i go jakoś "zhakować", no ale właśnie się nie da, więc to odpada), dalej: by musiał wiedzieć o komunikacji modułów korelujących, wreszcie, musiałby wiedzieć o tym, że jeszcze jeden stopień zabezpieczenia jest, w przypadku kiedy zagłuszy, to przez internet nieradiowy pójdzie we wspomniany sposób wiadomość na serwer itd. Ty dasz jakiś przykład, co by jeszcze mógł wiedzieć, a ja ci dam kontrprzykład. Dajmy na to, oprócz internetu można sobie wyobrazić transmisję gdzieś w linii prostej na odległość powiedzmy 2-3 kilometrów laserem podczerwonym (a więc nawet we mgle by nie było widać wiązki) do miejsca, w którym już zagłuszacz nie będzie miał zasięgu, a z stamtąd znowu połączyć się z internetem i wysłać na serwer. I tak dalej, i tym podobne. Z każdym kolejnym krokiem tego typu rozumowania, które masz, dochodzimy do absurdu, i prawdopodobieństwa bliskiego jedności, że włamywaczowi jednak nie uda się przechytrzyć alarmu.

Autor:  embedownik [ 14 mar 2022, o 09:24 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

ale to nie ja zacząłem, że wystarczy zagłuszacz - pomyliłeś osoby :P napisałem dokładnie to co Ty później - że są tzw "grade security" i jakieś małe systemy nie muszą być odporne na totalnie wszystko i trzeba gdzieś sobie postawić kreskę żeby nie przegiąć, a ktoś z zagłuszaczem/sprzętem itp to już "wysokie" grade.

Autor:  Michal7129 [ 14 mar 2022, o 09:37 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

embedownik napisał(a):
ale to nie ja zacząłem, że wystarczy zagłuszacz - pomyliłeś osoby :P napisałem dokładnie to co Ty później - że są tzw "grade security" i jakieś małe systemy nie muszą być odporne na totalnie wszystko i trzeba gdzieś sobie postawić kreskę żeby nie przegiąć, a ktoś z zagłuszaczem/sprzętem itp to już "wysokie" grade.

Racja, racja, przepraszam, teraz zdałem sobie sprawę, że pomyliłem Twój wpis z wpisem kogoś przed chyba Tobą. Co do reszty, widzę, że się rozumiemy. Dokładnie, to co ja wymyśliłem to jest już właściwie sztuka dla sztuki, bo tego stopnia bezpieczeństwa zabezpieczenia, przypuszczam są już na poziomie jednostek wojskowych typu NORAD w USA itp.

Autor:  SylwekK [ 14 mar 2022, o 09:59 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

Nie zgadlibyście jakie zabezpieczenie do malucha wiele lat temu zrobił mój ojciec... Nawet samochodu często nie zamykał. Nikt nawet nie próbował drugi raz otwierać drzwi kiedy po pierwszym szarpnięciu klamki dostał kopa kilka tys. volt ze starej cewki zapłonowej podłączonej do tej klamki - cewka z generatorem załączana dodatkowym przełącznikiem umieszczonym przy klamce wewnątrz drzwi :)

Autor:  akenes [ 14 mar 2022, o 11:45 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

a teraz złodziejaszek założyłby mu sprawę, takie szalone czasy nastały.

Autor:  Michal7129 [ 15 mar 2022, o 01:43 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

SylwekK napisał(a):
Nie zgadlibyście jakie zabezpieczenie do malucha wiele lat temu zrobił mój ojciec... Nawet samochodu często nie zamykał. Nikt nawet nie próbował drugi raz otwierać drzwi kiedy po pierwszym szarpnięciu klamki dostał kopa kilka tys. volt ze starej cewki zapłonowej podłączonej do tej klamki - cewka z generatorem załączana dodatkowym przełącznikiem umieszczonym przy klamce wewnątrz drzwi :)


Rewelacja :) !!! Dobry numer.

Cytuj:
a teraz złodziejaszek założyłby mu sprawę, takie szalone czasy nastały.


Niestety, czasy są jakie są, czyli beznadziejne. Upośledzony człowiek ukradnie batonik ze sklepu, to idzie do pierdla na pół roku, a politycy, którzy robią mega przewały są praktycznie bezkarni.

Autor:  Michal7129 [ 17 mar 2022, o 02:53 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

mirekk36 napisał(a):
...
2.) Koprocesor to: https://pl.wikipedia.org/wiki/Koprocesor
...

Tak, Mirek, znam tą definicję na pamięć, ale ona akurat jest dość, nazwijmy to, "ortodoksyjna", i w zasadzie z chwilą, gdy choćby ogólne procesory sygnału (DSP), czy też typowe procesory kart graficznych (GPU; będące nota bene uogólnieniem i udoskonaleniem, z kolei, wspomnianych procesorów DSP), zaczęto traktować, jako: koprocesory (względem głównego procesora: CPU) -- to zasadniczo ta, wspomniana, "ortodoksyjna" definicja terminu: koprocesor, którą tu z Wiki przytoczyłeś, zaczęła po prostu tracić swój pierwotny sens. W obecnych czasach, słowo koprocesor, jest znacznie szerszym terminem, i w dużym uproszczeniu można je traktować, jako każdą jednostkę obliczeniową w systemie mikroprocesorowym, która pełni pewne pomocnicze funkcje, w ogólności niezawężające się tylko do obliczeń arytmetycznych (ALU) -- względem procesora o najbardziej uniwersalnych funkcjach, który z tego względu nie bez powodu, głównie w literaturze anglosaskiej, jest bardzo często określany, słynnym skrótem: CPU (CENTRAL Processor Unit) czyli właśnie "CENTRALNA Jednostka Obliczeniowa". Zatem, można po prostu zamiennie traktować obecnie termin: koprocesor, ze sformułowaniem np. "procesor pomocniczy".

Autor:  Michal7129 [ 17 mar 2022, o 16:45 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

embedownik napisał(a):
w wielomikrokontrolerowych urządzonkach spotkałem się z sygnałem "heartbeat" - jakiś określony pattern na pinie gdzie jego odstępstwa były wykrywane (np zależności czasowe do sprawdzenia ewentualnych rozjazdów zegarów, lub sama jego obecność jako znak, że inny uc poprawnie pracuje) itp - może bardziej o coś takiego chodzi niż o bezpośrednie taktowanie?

Dodatkowo niektóre uCki mają coś takiego jak "tamper" jeśli chodzi o zabezpieczenia - może to jakoś pomoże.

Dokładnie o tego typu mechanizmy w procesorze mi chodzi. Jeśli się już kiedyś tym zajmę, to dokładnie widzę w czym się muszę poduczyć. Widzę, swoją drogą, że moja koncepcja jednak nie jest aż tak oryginalna, jak mi się wydawało, skoro producent już zaimplementował gotowe narzędzia ułatwiające zrobienie układu pod tym kątem.

Cytuj:
Musisz przemyśleć, czy czasem takie koncepcje zabezpieczeń jak opisujesz to nie strzał z armaty do muchy pomimo tego, że brzmią fajnie (oczywiście jak zawsze - chyba, że to ma być aspekt edukacyjny - wtedy można się bawić).

Oczywiście, że to strzał z armaty. Jak wspomniałem w jednym z ostatnich wpisów, tego typu stopień, praktycznie "paranoidalny", bezpieczeństwa, może mieć jedynie realne zastosowanie gdzieś, powiedzmy, w super strzeżonych instytucjach wojskowych czy wywiadowczych (wspomniany przeze mnie amerykański NORAD, czy można do tego np. dodać jeszcze zabezpieczenie, powiedzmy, do jakichś serwerowni, np. NSA). Tak że, ustosunkowując się do tego, co piszesz -- oczywiście, że to dla mnie tylko sztuka dla sztuki, czyli walory typowo edukacyjne i po prostu radość twórcza. Ponadto, kiedyś sobie powiedziałem, bo mam iluś znajomych, którzy są totalnymi laikami jeśli chodzi o nauki techniczne, czy informatyczne, że udowodnię im, że "nie wystarczy przecież >>tylko odciąć kabelka<< od zasilania/baterii, żeby unieszkodliwić jakikolwiek alarm" -- a oni właśnie dokładnie w ten sposób argumentowali: "że przecież cała trudność, to >>dostać się tam do tych kabelków<< obczaić gdzie jest zasilanie i rozłączyć". Najlepsze jest to, że mając takie właśnie pojęcie, jak tu przytoczyłem o elektronice, w żaden sposób nie umiałem ich przekonać, czy wyperswadować im, że niekoniecznie zawsze musi to być takie trywialne. A dodam, że wiedzą, iż jestem po fizyce, no i w ogóle z wyboru zajmuję się elektroniką. Tak więc, reasumując, mam zamiar kiedyś -- ale na pewno nie w najbliższej przyszłości, bo raz że mam inne sprawy na głowie teraz, dwa, co się i z pierwszym, z resztą, wiąże, ten temat jest mega trudny, bym musiał się więc poduczyć -- otóż mam zamiar zrobić taki układzik, powiedzmy dam z trzy źródła zasilania z akumulatorków + dwa z dwóch superkondensatorów (gdzieś już przylutowanych na PCB), a jako końcowy element wykonawczy dam wyzwolenie lampy błyskowej (chodzi o to, żeby efekt był jak najszybszy, a rozładowanie kondensatora w lampach błyskowych to są chyba mikrosekundy). Jeszcze specjalnie, żeby mieć radochę na nich patrząc, te kabelki od tych akumulatorów "wyeksponuję": + czerwonym, - niebieskim, dalej do każdej pary kabli wspominanych przewodów zasilających, przykleję jeszcze karteczkę, z wyeksponowanym napisem "zasilanie nr 1/2/3" -- no i kiedy będzie wszystko gotowe, zaproszę tą moją ekipę niedowiarków, dam każdemu po jednych ucinaczkach, obok jeszcze położę jakiś młotek nawet, i powiem coś w typie: "no to dalej, róbcie co tylko chcecie, odetnijcie zasilanie, rozwalcie płytkę itp., no i patrzcie, czy w ten sposób unikniecie zapalenia się lampy błyskowej". Wprost nie mogę sobie wyobrazić min tych lamerów, jak zobaczą "natychmiastowe >>zrewidowanie<< ich wiedzy" na temat elektroniki, rodem z filmów z "MacGyverem" -- z rzeczywistością :) :). Hehehe, będę miał ubaw po pachy.

Autor:  Michal7129 [ 17 mar 2022, o 23:24 ]
Tytuł:  Re: Atmega32 - główny procesor + Atmega8 - koprocesor.

Co tak ucichliście wszyscy?

Strona 1 z 2 Strefa czasowa: UTC + 1
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/