Nagmumungkahi ako ng opsyon sa device na awtomatikong nagre-reboot sa computer kapag nag-freeze ito.

Ito ay batay sa kilalang Arduino board na may pinakamababang bilang ng panlabas mga elektronikong bahagi. Ikinonekta namin ang transistor sa board ayon sa figure sa ibaba. Ikinonekta namin ang kolektor ng transistor sa halip na naka-on ang button na "I-reset" ng computer motherboard, sa pin na HINDI konektado sa GND.

Narito ang buong diagram:

Ang aparato ay gumagana tulad ng sumusunod: isang script ay inilunsad sa computer, na pana-panahong nagpapadala ng data sa port ng computer. Kumokonekta ang Arduino sa USB at nakikinig sa port na ito. Kung walang data sa loob ng 30 segundo, magbubukas ang Arduino ng isang transistor na kumokonekta sa I-reset sa lupa, sa gayon ay ginagaya ang pagpindot sa reset button.
Pagkatapos ng pag-reset, huminto ang Arduino ng 2 minuto, naghihintay na mag-load ang lahat ng mga programa, at pagkatapos ay magsisimulang makinig muli sa port.

Ang script at mga minero ay dapat idagdag sa startup, at ang BIOS ay dapat itakda sa awtomatikong pag-on kompyuter.

Ang paggawa ng device ay nangangailangan ng kaunting kasanayan sa pagtatrabaho sa isang soldering iron at programming ng Arduino.

Maaari mo ring gamitin ang anumang H channel transistor na may magkatulad na katangian. Ngunit siguraduhin na ang pinout ay tumutugma. Halimbawa, ginamit ko ang 9013, mayroong isang baligtad na koneksyon

Binili ko ang mga bahagi para sa pagpupulong sa Aliexpress:

Mga wire para sa pagpupulong ng breadboard http://ali.pub/22k78b

Arduino UNO (eksaktong akma) http://ali.pub/22k7dd

Arduino sketch

int LedPin = 13;
int ResetPin = 12;
int val = 0;
int bilang = 0;
void setup()
{
Serial.begin(9600);
pinMode(LedPin,OUTPUT);

//simulan ang pause 2 minuto
pagkaantala(120000);
}

void loop()
{
bilang++ ;

kung (Serial.available() > 0)
{
val = Serial.read();
kung (val == 'H')
{
digitalWrite(LedPin, LOW);
digitalWrite(ResetPin, LOW);
bilang = 0;
}
iba pa
( bilang++ ;
}
}

pagkaantala(1000);

kung (bilang > 10)
{
digitalWrite(LedPin, HIGH);
digitalWrite(ResetPin,HIGH);
}
}

Script sa pagpapadala ng data sa port:

(Get-Date).ToString('dd.MM.yyyy HH:mm') | Out-File c:\Users\miner\Desktop\reboot.txt -apend

habang($TRUE)(
Start-Sleep -s 3
$port= new-Object System.IO.Ports.SerialPort COM3,9600,Wala,8,isa
$port.open()
$port.WriteLine("H")
$port.Close()
}

Kaagad pagkatapos ng paglunsad, nagsusulat ang script sa file na reboot.txt kasalukuyang petsa at oras. Mula sa file na ito maaari mong hatulan ang bilang at oras ng mga pag-reboot. Dapat na i-edit ang path ng file at numero ng port ayon sa data ng iyong system. Ang code ay nakasulat sa isang regular na notepad at nai-save gamit ang *ps1 extension.

kasi V Patakaran sa Windows seguridad, ang pagpapatupad ng mga script ay hindi pinagana i-double click at mula sa autoload ay gumawa kami ng isang pagkukunwari sa aming mga tainga at inilunsad ang shell mula sa batch file na may sumusunod na nilalaman.

Ang Watchdog ay isang device na idinisenyo upang makita at malutas ang mga problema sa hardware. Kadalasan ito ay ginagawa gamit ang isang timer, na pana-panahong nagre-restart upang maiwasan ang pagpapadala ng signal ng pag-reboot.

Ang target na server sa Gentoo ay ginagamit ko pangunahin para sa mga eksperimento, ngunit nagpapatakbo ito ng ilang serbisyo na, kung maaari, ay dapat na magagamit nang walang pagkaantala. Sa kasamaang palad, ang mga kahihinatnan ng ilang mga eksperimento ay humantong sa kernel panic, 100% load ng CPU at iba pang mga problema sa pinaka-hindi angkop na sandali. Kaya't ang ideya ng pagdaragdag ng isang asong tagapagbantay ay matagal nang nangangailangan ng pansin at sa wakas ay natupad sa device na ito.

Matapos suriing mabuti kung ano ang magagamit at masuri ang oras na magagamit, ang pinakamahusay na pagpipilian naging isang asong tagapagbantay na pinagsama-sama Batay sa Arduino Nano. Ang listahan ng mga kinakailangan ay lumitaw nang halos pareho:

1. Pagsisimula at pagpapahinto sa daemon upang gumana sa timer, karaniwang paraan OS (OpenRC).
2. Ang aparato ay may sariling asong tagapagbantay, mayroon itong ATmega, kailangan mong gamitin ito.
3. Event log sa device para mag-record ng mga reboot at timer trigger.
4. Pag-synchronize ng oras ng device sa host upang maitala ang tamang oras sa log.
5. Pagtanggap at pagpapakita ng katayuan ng aparato at mga entry sa log nito.
6. Pag-clear sa log at pag-reset ng device sa orihinal nitong estado.

Hardware

Hindi ginustong pag-reboot ng Arduino

Mayroong ilang mga pagpipilian para sa paglutas ng problema, ngunit isa lamang ang gumana - kailangan mong mag-install ng 10µF electrolyte (C1 sa diagram sa ibaba) sa pagitan ng mga contact ng RST at GND. Sa kasamaang palad, hinaharangan din nito ang mga sketch na ma-download sa device.

Bilang isang resulta, ang diagram ay naging mga sumusunod:

Iginuhit gamit ang KiCad

Mga paliwanag para sa diagram

• R1- kasalukuyang naglilimita sa risistor, na kinakalkula ayon sa detalye para sa PC817 optocoupler: (5V - 1.2V / 0.02A) = 190Ω, ang pinakamalapit na karaniwang halaga ay 180Ω.
• U2- optocoupler para sa galvanic isolation ng Arduino at PC. Maaari kang makakuha ng sa pamamagitan ng isang transistor, dahil ang lupa ay karaniwan (sa pamamagitan ng USB connector), ngunit ito ay mas mahusay na hindi.
• JP1- ang jumper ay dapat na sarado sa nagtatrabaho posisyon. Upang i-download ang sketch sa device, dapat itong i-unlock.
• C1- capacitor, hinaharangan ang device mula sa pag-reboot bilang tugon sa signal ng DTR.
• MB_RST, MB_GND- Ang RESET ay aktibo kapag ang antas ng signal ay mababa, kaya kailangan mong i-short RST sa ground (GND). Gumagamit ang optocoupler ng transistor, kaya mahalaga na mapanatili ang polarity.
• BTN_RST, BTN_GND- isang pindutan sa katawan, kadalasan ito mekanikal na switch Samakatuwid, ang polarity ay hindi mahalaga, ngunit may mga pagbubukod.

Boot-loop (cyclic reboot) kapag nagtatrabaho sa WDT

Hindi mahabang paghahanap natagpuan na ang mga bootloader ng karamihan sa mga Arduino clone ay hindi sumusuporta sa WDT. Sa kabutihang palad, ang problemang ito ay nalutas sa alternatibong bootloader na Optiboot.

Upang i-flash ang bootloader, kailangan mo ng isang programmer na maaaring gumana gamit ang SPI protocol, kanais-nais din na alam ng Arduino IDE ang device na ito sa pamamagitan ng paningin. SA sa kasong ito Ang isa pang Arduino ay magiging perpekto.

Kung kukuha ka Arduino UNO, bilang isang programmer, at ang huli sa ngayon bersyon ng Arduino IDE v1.6.5, kung gayon ang algorithm ay magiging tulad ng sumusunod:

Pagkatapos ng pamamaraang ito, kakailanganin mong mag-upload ng mga sketch sa Arduino Nano gamit ang parehong mga setting - Lupon: Optiboot sa 32 pin cpus, Processor: ATmega328p, Bilis ng CPU: 16MHz.

Paghihinang

Dito USB plug Kailangan ko ito dahil mayroon akong mini-ITX motherboard na may isang connector lamang sa bawat pares ng USB2.0, na kailangan sa front panel, at contact pad Walang makakonekta ang USB3.0. Kung maaari, ang mga naturang device ay dapat na direktang konektado sa motherboard upang ang mga wire ay hindi dumikit.

Ang paghihinang, bilang panuntunan, ay hindi nagiging sanhi ng mga problema, ngunit sa kasong ito ang isang breadboard ay ginagamit, at ito ay may sariling mga detalye.

Paano maghinang ng mga track sa isang breadboard

Una kailangan mong maghinang ang mga bola sa mga butas (hindi mo maiinit ang mga ito sa loob ng mahabang panahon, kung hindi man ang lata ay tumagas mula sa likod na bahagi). Pagkatapos ay magsolder ng mga jumper sa pagitan ng mga pares ng katabing bola at tapusin ang track sa pamamagitan ng paghihinang sa natitirang mga segment.

Dapat itong magmukhang ganito:

Dito ay maaaring mukhang ang ilang mga contact ay hindi maganda ang soldered, ngunit ito ay flux lamang. Ang pagkonsumo ng panghinang sa mga breadboard ay medyo mataas, kaya lahat ng posible ay nabahiran ng flux. Sa katunayan, ito ay magandang halimbawa kung paano hindi iwanan ang produkto pagkatapos ng paghihinang. Ang pagkilos ng bagay ay dapat hugasan, kung hindi, maaaring may mga problema sa kaagnasan ng mga koneksyon. Tatapusin ko ang pagsusulat at maghuhugas ako... Mas mabuti ito:

Bahagi ng software

Koneksyon ng asong tagapagbantay

Una, kailangan mong biswal na mahanap ang konektadong asong tagapagbantay, halimbawa, sa pamamagitan ng pagtingin sa file ng log ng system. Pagkatapos, palitan ang /dev/ttyUSB0 ng kinakailangang aparato, isulat sa terminal:

Udevadm info -a -p "$(udevadm info -q path -n /dev/ttyUSB0)"

Halimbawang output

tumitingin sa device "/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4:1.0/ttyUSB0/tty/ttyUSB0": KERNEL=="ttyUSB0" SUBSYSTEM==" tty" ... tumitingin sa parent device "/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4:1.0/ttyUSB0": KERNELS=="ttyUSB0" SUBSYSTEMS= ="usb-serial" DRIVERS=="ch341-uart" ... tumitingin sa parent device "/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4/1-1.4:1.0 ": ... tumitingin sa parent device "/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4": SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS(idVendor) =="1a86" ATTRS(idProduct)=="7523" ATTRS(product)=="USB2.0-Serial" ...

Dapat itong ilagay sa hiwalay na file sa /etc/udev/rules.d na direktoryo, halimbawa 51-ttyrst-watchdog.rules at utusan si udev na i-reload ang mga panuntunan: udevadm control --reload-rules

Mula ngayon, kapag kumokonekta sa isang watchdog, isang link /dev/ttyrst-watchdog ang gagawin sa gustong device, na gagamitin pa.

Bash script (ttyrst-watchdog.sh)

Para sa pangunahing timer restart loop at para sa mga function command line, isang script ang ginagamit. Ang dahilan ay ang parehong mga bahagi ay gumagamit nakabahaging mapagkukunan- isang file ng device, at dapat itong ma-access nang sabay-sabay.

Ang pag-synchronize ay mahalagang binubuo ng waiting loop: habang ang fuser $(DEVICE) >/dev/null 2> ay totoo; tapos na at naka-on ang device kinakailangang oras: pusa<${DEVICE}

Malinaw, ang gayong pamamaraan ay napapailalim sa isang kondisyon ng lahi. Maaari mong harapin ito sa isang pang-adultong paraan (halimbawa, ayusin ang isang pila ng mensahe), ngunit sa kasong ito, sapat na upang itakda ang mga timeout nang tama upang matiyak na makakuha ng mga resulta sa isang katanggap-tanggap na oras. Sa katunayan, gumagana ang buong script sa mga timeout.

Ang pagdemonyo (tumatakbo sa background) ay isinasagawa gamit ang OpenRC package. Ipinapalagay na ang script na ito ay matatagpuan sa file /usr/local/bin/ttyrst-watchdog.sh, at ang OpenRC script ay nasa /etc/init.d/ttyrst-watchdog.

Kapag pinahinto ang daemon, dapat na i-deactivate nang tama ang watchdog. Upang gawin ito, isang signal handler na nangangailangan ng shutdown ay naka-install sa script: trap deactivate SIGINT SIGTERM At dito lumitaw ang isang problema - OpenRC ay hindi maaaring ihinto ang daemon, o sa halip, maaari, ngunit hindi madalas.

Ang katotohanan ay ang kill command ay nagpapadala ng signal sa script, ngunit ang sleep program, na ginagamit upang i-pause ang script, ay isinasagawa sa ibang proseso at hindi tumatanggap ng signal. Bilang resulta, ang pag-deactivate ng function ay tatakbo lamang pagkatapos makumpleto ang pagtulog, na tumatagal ng masyadong mahaba.

Ang solusyon ay ang magpatakbo ng sleep sa background at hintaying makumpleto ang proseso sa script: sleep $(SLEEP_TIME) & wait $! # variable $! naglalaman ng ID ng huling tumatakbong proseso

Mga pangunahing pare-pareho:

WATCHDOG_ACTIVE- OO o HINDI, ayon sa pagkakabanggit, magpadala ng senyales upang mag-reboot kapag ang timer ay na-trigger o hindi.
WATCHDOG_TIMER- oras sa mga segundo kung saan nakatakda ang timer.
SLEEP_TIME- oras sa mga segundo pagkatapos kung saan ang timer ay dapat na i-restart. Ito ay dapat na mas mababa kaysa sa WATCHDOG_TIMER, ngunit hindi masyadong maliit upang hindi makagawa ng labis na pagkarga sa system at device. Sa kasalukuyang mga timeout, ang isang makatwirang minimum ay humigit-kumulang 5 segundo.
DEFAULT_LOG_LINES- ang bilang ng mga kamakailang entry sa log ng device na ibinalik ng log command bilang default.

Mga utos ng script:

simulan- simulan ang pangunahing ikot ng pag-restart ng timer. Maaari kang magdagdag ng karagdagang check code sa is_alive function, halimbawa, pagsuri sa kakayahang kumonekta sa pamamagitan ng ssh.
katayuan- pagpapakita ng katayuan ng device.
i-reset- pag-clear ng EEPROM (data ng log) at pag-reboot ng device upang maibalik ang watchdog sa orihinal nitong estado.
log<число записей> - pagpapakita ng isang tinukoy na bilang ng kamakailang mga entry sa log.

Arduino sketch (ttyrst-watchdog.ino)

Ang sketch ay binubuo ng dalawang file. Ito ay dahil sa ang katunayan na ang Arduino IDE ay hindi tumatanggap ng mga istruktura (struct) na idineklara sa pangunahing file; Gayundin, upang magdeklara ng isang istraktura, ang typedef na keyword ay hindi kinakailangan, malamang na nakakapinsala ito... pagkatapos suriin ang mga karaniwang pagpipilian, hindi ko mahanap ang naaangkop na syntax. Kung hindi, ito ay higit pa o mas kaunting karaniwang C++.

Gumagana ang mga function na wdt_enable at wdt_reset sa watchdog na nakapaloob sa microcontroller. Matapos simulan ang WDT, ang pangunahing bagay ay huwag kalimutang i-reset ito sa pangunahing loop at sa loob ng mga loop ng lahat ng matagal na operasyon.

Ang mga entry sa log ay isinulat sa hindi pabagu-bago ng memorya ng EEPROM, ang magagamit na laki nito ay maaaring tukuyin sa logrecord.h, sa kasong ito ito ay ang numero 1024. Ang log ay ginawa sa anyo ng isang singsing, ang separator ay isang istraktura na may mga zero na halaga . Ang maximum na bilang ng mga entry para sa 1 KiB EEPROM ay 203.

• Tutorial

Pag-uusapan natin kung paano panatilihing laging gumagana ang Arduino. Ang mekanismo ng watchdog ay binuo sa mga controllers ng Atmega, ngunit, sa kasamaang-palad, hindi lahat ng Arduino bootloader ay humahawak sa function na ito nang tama. Subukan nating alamin ang problemang ito.

Kaya ano ang isang asong tagapagbantay? Sa simpleng salita, ito ay isang built-in na timer para sa isang tiyak na oras (hanggang sa 8 segundo depende sa chip), na maaaring simulan sa programmatically. Sa sandaling umabot sa zero ang timer, magpapadala ang controller tama reset signal (RESET) at papasok ang buong device mahirap i-reboot. Ang pinakamahalagang bagay ay ang timer na ito ay maaari ding i-reset sa paunang estado nito sa programmatically.

• Tama i-reset ang signal - sapat ang tagal para magsimulang mag-overload ang controller. Minsan may tukso na ikonekta ang ilang digital na output ng Arduino sa RST input at itakda ito sa 0 kapag kailangan mong mag-reboot. Ito ay isang masamang diskarte sa paglutas ng problema, dahil... ang naturang signal ay maaaring hindi sapat na mahaba, bagaman posible na sa ilang mga kaso ito ay gagana rin.
• mahirap Ang reboot ay isang tunay na reboot na nangyayari kapag pinindot mo ang RESET button. Ang katotohanan ay mayroon ding konsepto ng isang malambot na pag-reboot - ito ay isang paglipat ng software sa ika-0 na address. Sa prinsipyo, ito rin ay isang kapaki-pakinabang na bagay, ngunit sa tulong nito imposibleng mag-overload ang isang nakapirming Ethernet controller o isang glitchy LCD.

Mga function ng watchdog

Ang sumusunod na tatlong function ay magagamit na ngayon sa amin:

1. Simulan ang watchdog timer:
wdt_enable(WDTO_8S); /* Mga posibleng value para sa pare-parehong WDTO_15MS WDTO_30MS WDTO_60MS WDTO_120MS WDTO_250MS WDTO_500MS WDTO_1S WDTO_2S WDTO_4S WDTO_8S */
Ang timer ay bibilang nang eksakto hangga't tinukoy sa pare-pareho. Pagkatapos ng panahong ito, magkakaroon ng reboot.

2. I-reset ang watchdog timer:
wdt_reset();
Sa tingin ko ay malinaw kung bakit kailangan ang function na ito - habang tinatawag mo ito, hindi mare-reset ang controller. Sa sandaling mag-freeze ang system at huminto sa pagtawag ang function na ito, magkakaroon ng reboot pagkatapos ng isang tinukoy na panahon.

3. Huwag paganahin ang asong tagapagbantay:
wdt_disable();
Hindi pagpapagana ng watchdog timer.

Sa totoo lang, maaaring ito na ang katapusan ng aming kwento tungkol sa asong tagapagbantay... ngunit ang katotohanan ay ang lahat ng ito ay gumagana lamang sa Arduino Uno, at sa Arduino Mega, Mini at Nano lahat ito ay gumagana nang eksakto sa kabaligtaran, i.e. hindi gumana lahat :)

Bakit hindi gumagana ang asong tagapagbantay sa karamihan ng mga modernong Arduino board

Ang katotohanan ay pagkatapos ng pag-reboot, na dulot ng watchdog, ang mga controllers ng mga pinakabagong release ay iniiwan ang watchdog na naka-enable sa pinakamababang panahon, ibig sabihin. 15ms. Ito ay kinakailangan upang ang programa sa paanuman ay makilala na ang nakaraang pag-reboot ay ginawa ng asong tagapagbantay. Samakatuwid, ang unang priyoridad ng bootloader (o ang iyong programa, kung ito ay unang tatakbo) ay i-save ang impormasyon na ang pag-reboot ay "hindi inaasahan" at agad na patayin ang watchdog. Kung hindi ito nagawa, mapupunta ang system sa bootloop, i.e. ay magpakailanman ma-overload.

Tulad ng alam mo, ang Arduino ay may espesyal na bootloader na unang tatakbo pagkatapos ma-reboot ang system. At, sa kasamaang-palad, hindi nire-reset ng karaniwang bootloader ang asong tagapagbantay! Kaya, ang system ay napupunta sa isang brutal na bootloop (ang "crazy led" na estado, kung saan ang LED sa pin 13 ay kumukurap na parang baliw).

Mukhang ganito ang lahat:

Mga paraan upang malutas ang problema

Kung titingnan mo ang mga mapagkukunan ng karaniwang bootloader (kasama sila sa paghahatid ng platform), pagkatapos ay mayroong code upang huwag paganahin ang watchdog (!), Ngunit ang code na ito ay napapailalim sa conditional compilation at, tila, ang karaniwang bootloader ay pinagsama-sama nang walang watchdog suporta. Hindi bababa sa bersyon ng pakete ng platform 1.5.2 (ang pinakabago sa oras ng pagsulat), ito ang eksaktong kaso.

Upang malutas ang problema, binasa ko pa ang mga pahina ng tao ng platform mismo (:) at tila ang problemang ito ay inilarawan doon at kahit na ibinigay ang code na dapat magpasaya sa lahat:

Uint8_t mcusr_mirror __attribute__ ((section (".noinit"))); void get_mcusr(void) __attribute__((hubad)) __attribute__((section(".init3"))); void get_mcusr(void)( mcusr_mirror = MCUSR; MCUSR = 0; wdt_disable(); )
Inilalarawan nito ang get_mcusr() function na dapat tawagan kaagad pagkatapos ng pag-reset. Nakamit ito ng macro na "__attribute__((section(".init3")))". Sinubukan kong isulat ang function na ito sa lahat ng mga seksyon na posible - oo, ito ay talagang tumatakbo bago ang setup() function mula sa sketch, ngunit, sa kasamaang-palad, higit sa 15ms (ang minimum na watchdog constant) pagkatapos ng pag-reset...

Sa madaling salita, gaano man ako nagsaliksik sa Internet sa paghahanap ng madaling solusyon sa problema, walang nakita. Nakakita lang ako ng isang paraan para makapagtrabaho ang asong tagapagbantay - para i-reflash ang bootloader... na kung ano ang gagawin natin ngayon.

Sinusuri ang functionality ng watchdog

Bago mag-flash ng anuman, kailangan mong suriin kung sinusuportahan ng iyong Arduino ang watchdog. Upang gawin ito, nagsulat ako ng isang maliit na sketch ng pagsubok. I-upload lang ito, buksan ang port monitor at panoorin kung ano ang mangyayari.

Pagsusuri ng asong tagapagbantay

#isama void setup() ( wdt_disable(); // walang kwentang linya na hindi naaabot ng execution sa panahon ng bootloop Serial.begin(9600); Serial.println("Setup.."); Serial.println("Maghintay ng 5 seg..") ; void loop())( // Bawat segundo ay kumukurap kami sa LED at isinusulat ang counter value sa Serial if(!(millis()%1000))( timer++; Serial.println(timer); digitalWrite(13, digitalRead(13) ==1? 0:1);

Pagkatapos mag-reboot (o magkonekta ng monitor sa port), magbi-blink ang built-in na LED, na nagpapahiwatig na nagsimula na ang bootloader. Susunod, sa seksyon ng pag-setup, naka-on ang asong tagapagbantay na may timer sa loob ng 8 segundo. Pagkatapos nito, magbibilang ang LED sa oras na ito para sa amin at dapat magkaroon ng reboot.

Pagkatapos ay magsisimula ang pinaka-kagiliw-giliw na bahagi - kung ang isang pag-reboot ay naganap at ang lahat ay paulit-ulit sa parehong pagkakasunud-sunod, pagkatapos ay mayroon kang isang Arduino sa iyong mga kamay, kung saan ang bootloader ay tama na nagpoproseso ng asong tagapagbantay. Kung pagkatapos ng pag-reboot ang LED sa pin 13 ay magsisimulang kumurap ng walang katapusang, kung gayon ang bootloader ay hindi sumusuporta sa watchdog. Kahit na ang reset button ay hindi makakatulong dito. Para sa kasunod na firmware, kailangan mong idiskonekta ang board mula sa power supply at, pagkatapos i-on ito, magkaroon ng oras upang i-flash ito bago ang unang pag-reboot.

Sinubukan ko ang 4 na uri ng mga board at tanging ang bootloader sa Arduino Uno ang gumana ayon sa nararapat:

Mga resulta sa monitor

Ang Watchdog ay hindi sinusuportahan ng bootloader:

Ang asong tagapagbantay ay sinusuportahan ng bootloader:

Ano ang pinakamadaling paraan upang mag-flash ng bagong bootloader?

Maaari mong i-flash ang bootloader sa Arduino gamit ang hiwalay na mga programmer, o maaari kang bumuo ng iyong sariling programmer gamit ang parehong Arduino. Yung. anumang bayad Ang Arduino ay maaaring gawing isang programmer sa pamamagitan ng pag-upload ng isang espesyal na sketch doon.

Sa artikulong ito hindi ko ilalarawan ang lahat ng mga intricacies ng paglikha ng isang Arduino-based programmer, dahil... ang paksang ito ay medyo. Ginamit ko ang Arduino Uno bilang isang programmer. Tulad ng alam mo, ang firmware ay na-flash sa pamamagitan ng isang hiwalay na ICSP connector, na matatagpuan sa halos lahat ng mga board. Sa kaso ng Arduino Pro Mini firmware, na walang ICSP, ang koneksyon ay direktang ginawa sa mga pin.

Koneksyon para sa firmware bootloader

Saan ako makakakuha ng bootloader na sumusuporta sa watchdog?

Ang kabanatang ito ay nakapagpapaalaala sa pagsasayaw gamit ang tamburin at malamang na ang lahat ay maaaring gawing mas simple, ngunit, sayang, hindi ko ito magagawa sa ibang paraan.

Inirerekomenda na gumamit ng mga bootloader mula sa package ng optiboot. Sa prinsipyo, ang mga bootloader na ito ay kasama sa pag-install ng Arduino platform mismo, ngunit mas mahusay na i-download at i-install ang pinakabagong bersyon ng optiboot mula dito. Ang pag-install ay binubuo ng dalawang hakbang (marahil ito ay maaaring gawin sa ibang paraan):

1. Ang bootloaders\optiboot folder ay muling isinulat sa C:\Program Files (x86)\Arduino\hardware\arduino\avr\bootloaders\optiboot
2. Ang boards.txt file ay idinagdag sa file na C:\Program Files (x86)\Arduino\hardware\arduino\avr\boards.txt

Naturally, maaaring iba ang iyong folder ng pag-install ng platform ng Arduino.

Susunod, nire-reload ang development environment at sa Service/Board menu makikita mo ang mga bagong board na may markang . Sa kasamaang palad, kapag pumipili ng mga board na ito, nangyayari ang ilang kakaibang mga error sa compilation at lahat ng uri ng iba pang kakaiba ay lumalabas... kaya ginagawa namin itong mas simple. Buksan ang file C:\Program Files (x86)\Arduino\hardware\arduino\avr\boards.txt sa anumang text editor at baguhin ang mga sumusunod na linya:

Para sa Arduino Nano:
menu.cpu.nano.atmega328.bootloader.file=optiboot/optiboot_atmega328.hex

Para sa Arduino Mini:
menu.cpu.mini.atmega328.bootloader.file=optiboot/optiboot_atmega328.hex

Ang susunod na problema ay ang optiboot bootloader para sa Arduino Mega board ay hindi umiiral sa kalikasan, dahil... Mas maraming memory ang Mega at gumagamit ng ibang protocol. Samakatuwid, gumagamit kami ng isang karaniwang ngunit binagong bootloader, na dina-download namin mula dito. Palitan ang pangalan ng file sa stk500boot_v2_mega2560_2.hex at isulat ito sa folder na C:\Program Files (x86)\Arduino\hardware\arduino\avr\bootloaders\stk500v2.

Huwag maalarma na ang binagong file ng firmware para sa Mega ay 2 beses na mas maliit kaysa sa karaniwang isa - tila ito ang kaso.

Proseso ng firmware

Matapos ang lahat ng mga pagbabago, maaari mong i-flash ang mga bootloader sa pamamagitan ng pagpili ng mga regular na board sa menu ng board (hindi!). Sa kasong ito, ang eksaktong mga hex na file na tinukoy namin sa board.txt file ay i-flash.
Maaaring hindi magsimula ang proseso ng firmware at maaaring lumitaw ang isang error:
Upang malutas ang problemang ito, buksan ang sketch ng programmer at sa seksyon ng pag-setup, pumili ng ibang bilis ng serial port.
Habang nag-a-upload sa Arduino Mega, maaaring lumitaw ang isang error na hindi dapat pansinin:
avrdude: error sa pag-verify, unang mismatch sa byte 0x3e000 0x0d != 0xff avrdude: error sa pag-verify; hindi pagkakatugma ng nilalaman

Panghuling manipulasyon

Ang mga optiboot loader ay may isa pang tampok - pinapataas nila ang bilis ng paglo-load ng mga sketch, kaya kapag gumagamit ng mga board na may optiboot kailangan mong gawin ang mga naaangkop na pagbabago sa boards.txt:

Para sa Arduino Nano:
menu.cpu.nano.atmega328.upload.speed=115200
Para sa Arduino Mini:
menu.cpu.mini.atmega328.upload.speed=115200

Mas mahusay na tandaan ang nakaraang bilis ng port, dahil... kakailanganin itong gamitin sa mga board na may mga karaniwang bootloader. Kung ang mga naturang pagbabago ay hindi ginawa, ang proseso ng pag-upload ng mga sketch ay bubuo ng isang error tulad nito:
avrdude: stk500_getsync(): hindi naka-sync: resp=0x00

Mga link, panitikan

package optimoot
Bootloader ng firmware
Paano mag-flash ng bootloader sa Arduino Pro Mini

Mga Tag:

• arduino
• asong nagbabantay

Magdagdag ng mga tag