On Sat, 12 Jul 2014 10:40:14 +0200, Atlantis <m...@w...pl>
wrote:
> Ciągle się nie rozumiemy. Tak krótki czas stosuję TYLKO w procedurze
> soft resetu, żeby użytkownik nie musiał czekać na jego wykonanie.
> void soft_reset (void) {
> wdt_enable(15MS);
> while(1);
> }


No nie rozumiem zupelnie, o jakim czekaniu na reset mówisz (reset to
reset, instrukcja natychmistowa) i po co w ogóle taka funkcja? Czyżby
atmega nie ma instrukcji "reset", żeby ją użyć jak jest potrzeba
resetu i trzeba takie cuda pisać?

>Układ i tak wpadał w pętlę
> resetu po pierwszym wykonaniu tej funkcji.

Tego też nie rozumiem, po co układ ma wpadać w funkcję resetu?
Nie znam się kompletnie na atmegach i nasze nieporozumienie wynika
chyba z tego, że rozwiązujesz problemy nieistniejące w innych
systemach (czyt. mcu) ;)

--
Marek

do góry

W dniu 2014-07-12 11:01, Marek pisze:

> No nie rozumiem zupelnie, o jakim czekaniu na reset mówisz (reset to
> reset, instrukcja natychmistowa) i po co w ogóle taka funkcja? Czyżby
> atmega nie ma instrukcji "reset", żeby ją użyć jak jest potrzeba resetu
> i trzeba takie cuda pisać?

No właśnie chyba nie ma. Nawet gdzieś na stronach Atmela widziałem
tekst, w którym opisywano właśnie taki sposób na programowy reset MCU.


> Nie znam się kompletnie na atmegach i nasze nieporozumienie wynika chyba
> z tego, że rozwiązujesz problemy nieistniejące w innych systemach (czyt.
> mcu) ;)

Najwyraźniej. Dziwne jest to, że po resecie przez watchdoga, ten ostatni
ciągle pracuje. W dodatku nie da się go tak po prostu wyłączyć, tylko
trzeba najpierw wyzerować flagę.
Całkowicie nieintuicyjne rozwiązanie...

do góry

Atlantis <m...@w...pl> napisał(a):
> W dniu 2014-07-12 11:01, Marek pisze:
>> No nie rozumiem zupelnie, o jakim czekaniu na reset mówisz (reset to
>> reset, instrukcja natychmistowa) i po co w ogóle taka funkcja? Czyżby
>> atmega nie ma instrukcji "reset", żeby ją użyć jak jest potrzeba resetu
>> i trzeba takie cuda pisać?
> No właśnie chyba nie ma. Nawet gdzieś na stronach Atmela widziałem
> tekst, w którym opisywano właśnie taki sposób na programowy reset MCU.
>> Nie znam się kompletnie na atmegach i nasze nieporozumienie wynika chyba
>> z tego, że rozwiązujesz problemy nieistniejące w innych systemach (czyt.
>> mcu) ;)
> Najwyraźniej. Dziwne jest to, że po resecie przez watchdoga, ten ostatni
> ciągle pracuje. W dodatku nie da się go tak po prostu wyłączyć, tylko
> trzeba najpierw wyzerować flagę.
> Całkowicie nieintuicyjne rozwiązanie...

Pierwszy wynik z Google, chyba wyczerpuje temat :)
http://www.atmel.com/webdoc/AVRLibcReferenceManual/F
AQ_1faq_softreset.html

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 19 days, 20 hours, 50 minutes and 7 seconds

do góry

W dniu 2014-07-12 11:01, Marek pisze:

> Nie znam się kompletnie na atmegach i nasze nieporozumienie wynika chyba
> z tego, że rozwiązujesz problemy nieistniejące w innych systemach (czyt.
> mcu) ;)

Tak swoją drogą fakt, to trochę dziwne. Jednak w tej chwili przyglądam
się bliżej PIC-om i one też mają pewne słabe strony w porównaniu do
AVR-ów. Najbardziej zaskoczył mnie fakt, że nie wszystkie piny mogą
oddawać jednakowy prąd, a także nie wszystkie dysponują wewnątrznym
pull-upem. W ATmegach nie muszę się tym przejmować, co nieco ułatwia
projektowanie płytki.

Z drugiej strony chciałbym, żeby ATmel produkował ośmiobitowe MCU z
takim wachlarzem różnych interfejsów (CAN, Ethernet).

do góry

On Mon, 14 Jul 2014 09:26:53 +0200, Atlantis <m...@w...pl>
wrote:
> Najbardziej zaskoczył mnie fakt, że nie wszystkie piny mogą
> oddawać jednakowy prąd, a także nie wszystkie dysponują wewnątrznym
> pull-upem. W ATmegach nie muszę się tym przejmować, co nieco ułatwia

Tylko nie skupiaj się czasem na picach 16f czy mniej (minumum 18f). W
picach 16f i mniej najczęściej nie ma możliwości selektywnego pullapa
(wybrany pin), albo cały port (B) albo wcale.

--
Marek

do góry

W dniu 2014-07-14 13:02, Marek pisze:
> Tylko nie skupiaj się czasem na picach 16f czy mniej (minumum 18f). W
> picach 16f i mniej najczęściej nie ma możliwości selektywnego pullapa
> (wybrany pin), albo cały port (B) albo wcale.

To oczywiste. Nie mam zresztą takiej potrzeby, bo do prostszych
projektów mogę wykorzystać zgromadzony "zapas" AVR-ów. PIC-om przyglądam
się z uwagi na kilka modeli, które nie mają swoich bezpośrednich
odpowiedników wśród produktów Atmela (np. PIC18F67J60 z wbudowanym
modułem Ethernet, ewentualnie MCU w SO28 z większą ilością peryferiów).

Generalnie wychodzi na to, że wcale nie tak trudno połapać się w jednej
rodzinie, gdy poznało się jakąś inną. Filozofia obsługi podobna, pomimo
pewnych różnic, które są do opanowania. Pewnie jeszcze po drodze
przyjrzę się rodzinie XMega. Dzięki narzędziom dostarczonym przez Atmela
nie trzeba bawić się rejestrami na niskim poziomie, a mają kilka fajnych
cech (np. sprzętową obsługę AES).

do góry