Wszechstronny programator do TQFP64 dla ATmega128 z przystępnymi adapterami?

Sun Sep 14, 2014 8:52 pm   

no właśnie. Co za czasy jakieś zwariowane.
Kiedyś człowiek coś kupił, to zaraz się za to brał - ciekawość nie
pozwalała czekać.

A teraz tak - w zeszłym roku w grudniu kupiłem sobie radio do samochodu.
Takie z cudawiankami, żeby było fajnie
I tak leży w kartonie...

Sat Oct 11, 2014 12:18 am   

Obiecałem, że napiszę, to piszę, żeby nie było że miałem napisać, a nie
napisałem...

Właśnie jestem po zaprogramowaniu 40 procesorów w podstawkach TQFP 64 i 32.

Pominąwszy konieczność uruchomienia wszystkiego jak należy (po ostatnich
moich problemach z programowaniem via ISP) to jestem bardzo zadowolony.

Podstawki bardzo fajne, wygodne. Robiłem w połączeniu z tym USBASP, ale
bez żadnych dodatkowych switchy - po prostu przed wyjęciem atmela
wyłączam jego zasilanie, po prostu wyciągając wtyczkę z gniazda
zasilającego podstawki (jest tam takie). Programator podłączony cały czas.

Musiałem co prawda leciutko dostosować oprogramowanie, żeby po
zaprogramowaniu procesor nie poszedł w krzaki w tej podstawce (bo
przecież reszty urządzenia nie ma tam), ale jak już zrobione - to
naprawdę komfort jest.

Tak że - polecam.

Sat Oct 11, 2014 7:48 am   

On Sat, 11 Oct 2014 02:18:51 +0200, sundayman
<sundayman@poczta.onet.pl> wrote:

Przypomnij dlaczego nie mogłeś programować na płytce docelowej
poprzez ICSP?

--
Marek

Sat Oct 11, 2014 2:05 pm   

W dniu 2014-10-11 02:18, sundayman pisze:

Dzięki za informacje
Rozumiem, że po lutowaniu wszystko działa jak należy?

Pozdrawiam

DD

Sat Oct 11, 2014 5:55 pm   

Oczywiście, mogłem. Tyle, że to jest mocno utrudnione - wcześniej już
pisałem, że w urządzeniu są 2 procesory, współpracujące ze sobą, i żeby
przy "normalnym" programowaniu w urządzeniu nie wystąpiły nieporządane
sytuacje potrzebna jest specjalna procedura, co jest kłopotliwe.

Do tego oczywiście trzeba się podłączać do złącza wewnątrz procesora itp.

W przypadku "awarii" w programowaniu (przewalenie fusów) trzeba MCU
stawiać na nogi itp. W gotowym urządzeniu wszystko to jest utrudnione i
zajmuje czas.

Oczywiście, w jednostkowym urządziu nie ma kłopotu - ale tutaj mowa o
"produkcji seryjnej" - po kilkadziesiąt szt.

Przy takich ilościach każde zaoszczędzone 5 min / szt. to skarb.

Sat Oct 11, 2014 5:58 pm   

to się okaże za kilka dni - dziś wlutowuję zaprogramowane procesory.
Ale nie widzę możliwości, żeby było inaczej, bo procesor po
zaprogramowaniu w podstawce zgłasza się poprawnie (do jednego z pinów
podstawki podłączony jest led, którym program miga).

Ten sam plik oczywiście został sprawdzony przez zaprogramowanie mcu w
urządzeniu - zatem jestem pewien, że będzie OK.

Ale napiszę, jak będę uruchamiać

Sat Oct 11, 2014 6:04 pm   

Żeby było jasne - po zaprogramowaniu, program w MCU "rusza", ale po
sprawdzeniu , że jest w podstawce programatora (przez sprawdzenie stanu
niskiego na jednym z wejść) nie uruchamia się dalej, żeby nie
przeprowadzać "inicjalizacji systemu", która musi się odbyć w docelowym
urządzeniu. Czyli po stwierdzeniu że jest w podstawce, mcu tylko miga
żebym się cieszył

Sat Oct 11, 2014 10:32 pm   

On Sat, 11 Oct 2014 19:55:40 +0200, sundayman
<sundayman@poczta.onet.pl> wrote:

A czemu 2? Serio opłaca się zarządzać dwoma kodami zamiast jednym?
Jakbym miał wkładać dwa słabe mcu to wolałbym to zrealizować na
jednym ale mocnym. Zdradź co to urządzenie robi, że aż potrzebuje 2
mcu.

--
Marek

Sat Oct 11, 2014 11:09 pm   

W 2 słowach - to jest sterownik przemysłowy, który musi być bardzo mocno
niezawodny ze względów bezpieczeństwa.
Dlatego obecna wersja ma 2 procesory, które pracują niezależnie,
wymieniając się informacjami. Znaczy - żeby uruchomić dany proces, oba
muszą sprawdzić, że "kolega" jest przytomny, i pracuje poprawnie.
Dopiero jeśli oba się wymienią poprawnymi informacjami, mogą wspólnie
uruchomić proces.

Ponadto jeden może drugiego resetować, jeśli uzna, że kolega "coś nie
halo" , dzięki czemu całość jest bardziej odporna na jakieś zwiechy itp.

To fakt, że mocno komplikuje to uruchamianie i w ogóle konstrukcję, ale
- bezpieczeństwo nade wszystko tutaj.

Sat Oct 11, 2014 11:11 pm   

Oba są zresztą na różnych PCB - jeden jest przy części "wykonawczej"
(mniejszy, atmega8), przy okazji zbiera parę dodatkowych informacji z
"okolicy", a drugi (atmega128) jest w "panelu sterowania".

Komunikują się po RS232 między sobą.

Sun Oct 12, 2014 7:10 am   

On Sun, 12 Oct 2014 01:09:50 +0200, sundayman
<sundayman@poczta.onet.pl> wrote:

Jeśli jeden ogląda się na pracę drugiego to zamiast jednego pkt.
awari masz teraz możliwe dwa, gdzie tu redundancja?

--
Marek

Sun Oct 12, 2014 7:56 am   

On 12.10.2014 09:10, Marek wrote:

Nie ma redundancji. Przeczytaj jeszcze raz opis.

Sun Oct 12, 2014 8:10 am   

On Sun, 12 Oct 2014 09:56:33 +0200, Zbych <zbych@onet.pl> wrote:

No właśnie, jak bez redundancji uzyskać niezawodność?

--
Marek

Sun Oct 12, 2014 5:35 pm   

W dniu 2014-10-12 o 10:10, Marek pisze:

Wyciągasz pojedyncze słówka i się czepiasz.
"niezawodny ze względów bezpieczeństwa"

Dlatego np. przyciski dwuręczne są łączone dwoma osobnymi obwodami do
przekaźnika bezpieczeństwa nie dlatego, że ma to zapewnić redundację
tylko uniemożliwić start maszyny gdy jeden z obwodów będzie miał
zakłócenie. Tak samo mają kurtyny świetlne, skanery obszarowe, zamki
bezpieczeństwa, rolety drzwiowe itp itd. Poczytaj u takich producentów
jak SICK, Albany Door, Cedes Safety, Rockwell Automation, BANNER,
Schmersal, itp.


--
Irokez

Sun Oct 12, 2014 5:51 pm   

Koledzy mi wyciągają kogoś z KF, ale mniejsza - nie chodzi w takim
przypadku o to, żeby "jak najmniej było do uszkodzenia", tylko o to,
żeby "wykryć uszkodzenie", czyli zminimalizować ryzyko wykonania
błędnego działania. Lepiej zatrzymać cały system, niż pozwolić na
wykonanie działania "niepożądanego".


Oczywiście, nie jest to mój wynalazek, bo w końcu chyba w wahadłowcach
jest nawet system "głosowania" przez nieparzystą liczbę komputerów
Tak sobie coś przypominam...