EdiM pisze:Bawiłem się trochę driverkami chińskimi na AMC z procesorami PIC12F629, a teraz ostatnio jest to ATtiny13V. Tzn. robiłem tam inne oprogramowanie.
No i wydaje mi się, że taki gotowy driverek jest najlepszą bazą do modyfikacji. AMC7135 nie działa źle.
Edim, w pełni się z Tobą zgadzam.
Czy mógłbyś podać namiary na te driverki z ATtiny (DX lub Kai)?
Bo to, co sobie przejrzałem i mogło wyglądać obiecująco na zdjęciach dalej ma PIC-e.
Ciekawe, czy chińczycy zrobili je "z głową" i sterują AMC`kami z pinu 5 lub 6 (sprzętowy PWM na Timer0), czy też poszli po najprostszej linii oporu i użyli pierwszy lepszy port I/O z programowym sterowaniem.
Natomiast co do kondensatora blokującego zasilanie, to da się też zrobić działające rozwiązanie bez żadnej pojemności. Oczywiście nie będzie to rozwiązanie architektonicznie eleganckie, ale chodzi mi tu raczej o inny sposób logiki sterowania, która nie wymaga podtrzymywania napięcia procka w czasie zaniku zasilania.
Bo można to zrobić co najmniej na 3 różne sposoby:
1. Zastosowany w naszym rozwiązaniu (df&cali) mechanizm podtrzymania na tantalu procesora przez min. 1 sek, przez czas w którym wykrywane są zaniki zasilania sterujące logiką softu
- zalety: zachowuje pełną ciągłość pracy MCU (stany / wartości rejestrów)
- wady: wymaga kondensatora o poj. rzędu 10uF+ i diody (najlepiej schottky z uwagi na 0,3V)
2. Zastosowanie w naszym "koncepcyjnym" minimalistycznym rozwiązanie (
najmnieszy driverek na światełkach) polegające na zapisach stanów w EEPROMie
- zalety: znikoma ilość elementów (cały driver to zaledwie 2 elementy: MCU+MOSFET)
- wady: zapisy do EEPROM`a przy każdym włączeniu i zmianie trybu (ograniczona żywotność), z czym można sobie jednak dość dobrze radzić rozpraszając zapisy po całej przestrzeni lub dokonywując addytywnych zapisów komórek bez każdorazowych cykli ich kasowania (0xFF-owania).
3. Zastosowanie zewnętrznych "elementarnych" komórek pamięci w postaci małych kondensatorów podłączanych między port, a masę. MCU może ustawiać na nich stany (I/O w trybie wyjściowym) jak i czytać z nich stany w wystarczającym do zmiany trybu czasie przerwy pracy procesora
- zalety: nie wymaga podtrzymania zasilania MCU ani persystentnych zapisów (EEPROM)
- wady: mała liczba kombinacji przechowywanych w ten sposób stanów (2^n), dodatkowe elementy, utrata stanu w czasie (co nie nadaje się do trwałego przechowywania stanu, ale jest wystarczające do zachowania chwilowej informacji na czas zmiany trybu)
Z mojego punktu widzenia rozwiązanie 1 jest najlepsze i najbardziej eleganckie.
Rozwiązanie 2-gie też działa, choć osobiście mniej mi się podoba.
Rozwiązanie 3-cie ma chyba zbyt wiele ograniczeń, choć być może jako koncepcja sama w sobie warta jest opisania.
Pozdrawiam,